[OSM-talk] Naming disputes in Ukraine

[LM_1]

2012/7/25 Miloš Komarčević <kmilos at gmail.com>:
> Hi,
>
> We had similar discussions in Serbia as well, since we need to support
> two writing systems at the same time (Cyrillic and Latin), and any
> official ethnic minority languages in areas where they are used.
>
> On Wed, Jul 25, 2012 at 11:39 AM, Volker Schmidt <voschix at gmail.com> wrote:
>> Basically the outcome - I hope I am summing up correctly - is that the name
>> tags in Italy should contain the official names, which in Italy's bi- or
>> sometimes multi-lingual areas appear in several languages on the official
>> road signs.
>> So the road sign says "Bolzano-Bozen", hence the name tag is
>> name=Bolzano/Bozen. In addition there will be name tags name:de=Bozen
>> name:it=Bolzano.
>
> While this might reflect signs on the ground, it's bad from data
> structure point of view because there is no clue to what languages are
> stored in name= and how to process them if necessary (e.g. automatic
> transliteration).
>
>> In the discussion some contributors pointed to the different approach in
>> Switzerland.
>> In Switzerland there is only one official name and that is the name in the
>> local language. So it would be name=Genève, name:de=Genf, name:it=Ginevra
>>
>
> Again, you don't know what language is stored in name=, but at least
> in this case adding also a name:fr would improve the situation.
>
> Which brings us back to the point Peteris Krisjanis made:
>
> name= without the context of a language is somewhat useless from the
> database point of view, apart from quick and dirty rendering of what
> is on the ground.
>
> A much better approach would be to dispose of it, and force having
> name:<lang> everywhere. Then one would be able to define e.g. on the
> administrative level (country, district, municipality) what languages
> to use/render on objects inside that relation.
>
> For example: for the whole of Italy relation you would have "lang=it",
> but for the South Tyrol you would have lang=de;it (or whatever order
> is appropriate) which would take precedence. For any exceptions, you
> would add lang= on the object itself which would have highest
> priority...
>
> M
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk

I agree
LM_1