<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I was thinking about roughly the same idea except the process is a
bit different. There could be an alternate usage through references.
Something like [de] in the name tag could indicate a reference to
name:de. A semicolon in the name tag could be used to indicate the
order of languages to display or backups in case the name:* in the
front of the line don't exist.<br>
<br>
- Svavar Kjarrval<br>
<br>
<div class="moz-cite-prefix">On 25/07/12 15:21, "Petr Morávek
[Xificurk]" wrote:<br>
</div>
<blockquote cite="mid:50100EEF.9080800@gmail.com" type="cite">
<pre wrap="">Lester Caine wrote:
</pre>
<blockquote type="cite">
<pre wrap="">colliar wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I also prefer the name that is on the sign, but we should think about
always
adding the name with its language tag, too, otherwise it is not clear
which
language is used and you have to get this information from some other
source.
</pre>
</blockquote>
<pre wrap="">
I'm coming to a point where I might suggest that 'name' is ONLY
populated with a language code or codes?
</pre>
</blockquote>
<pre wrap="">
This is actually pretty good idea, but...
If we start replacing the content of the name only by language
reference, we will most definitely break a lot of apps.
Taking the best of this and previous ideas, I would propose this:
*** Data producers ***
1) Deprecate bare tags name, official_name etc. (bare = without ':lang'
suffix).
2) Embrace the usage of language specific tags like 'name:en',
'name:de', ...
3) Introduce new tag 'lang', which should contain a pointer to the
locally used language. (For multilingual areas, we could use something
like lang="de / it".)
*** Data consumers ***
How to get name, official_name, etc. in default local format?
- Is there lang tag?
YES: Take its value and replace lang codes by the values of language
specific tags.
NO: Fallback to the tag value withou language suffix.
Examples:
{name="Praha", name:en="Prague"}
=>name="Praha"
{name:de="Bozen", name:it="Bolzano", lang="it - de"}
=>name="Bolzano - Bozen"
---
There are few things I really like about this solution:
1) You can apply the same logic to all language specific tags, not only
'name'.
2) There is no BC break.
3) No data duplication in the main database.
4) You are free to specify locally used multilingual format, so the
result of the algorithm above would satisfy "on the ground" rule.
5) I could imagine this algorithm implemented in osm2pgsql, it could
automatically expand this to the appropriate general tags on import
time, thus all its users would not have to change a thing in their code.
So, what do you think?
Best regards,
Petr Morávek aka Xificurk
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
talk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/listinfo/talk">http://lists.openstreetmap.org/listinfo/talk</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>