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 <[email protected]> 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 [email protected] http://lists.openstreetmap.org/listinfo/talk
