[OSM-talk] Naming disputes in Ukraine

["Petr Morávek [Xificurk]"]

Lester Caine wrote:
> colliar wrote:
>> 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.
> 
> I'm coming to a point where I might suggest that 'name' is ONLY
> populated with a language code or codes?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20120725/f1f5d2af/attachment.pgp>