[OSM-talk] Revival: Multilingual Country-List

[Hans Schmidt]

Am 21.02.2013 12:36, schrieb Peter Wendorff:
> Well... if there's no localized name tag, then you may omit the 
> name:xx tag for that language, as there's no alternative.
> On the other hand name:de might be useful even then, as it's possible 
> to translate programmatically if the software knows about the 
> language. The German suffixes -straße, -weg, -platz could be 
> automatically transcoded to street, way and square, the afaik swedish 
> -gatan is street again, väg is way and so on.
> But if you try to translate something to another language this way 
> where you don't know the source language, it's much more difficult.
>
Why would you want to translate the street names? Do you want to 
translate Paris' “Avenue des Champs-Élysées” to “Allee der 
Champs-Élysées”? Nobody would know what it is anymore.
Also, nobody wants to translate a “Lindenallee” in some minor german 
town to “Linden avenue”.  Also, automatic translation would be error prone.

> So a recommendation might be to
> - always tag name
> - if you translate name into different languages, always add 
> name:originalLanguageCode with the same content
> - if you want, add that even if you don't translate it to different 
> languages.
>
> Yes, that's redundant - but it's easy to cut out for software (cut out 
> every language attribute that equals the plain name), if wanted; and 
> it's less error prone than a tag like "language=de" or like the lists 
> of default language areas you propose above.
> Sure: These list are helpful for all cases where only name is given, 
> and that's a necessity for great software dealing with that, but 
> that's the way defaults in OSM work: there should be a few defaults 
> for mappers, where they should decide to not add a tag, but more 
> defaults for data consumers, who could/should be able to have a best 
> guess where data is missing. 

You say that there should be few defaults for mappers. But what you 
propose is exactly the opposite: You'd have a default, meaning that you 
would need to create a name:originallanguage even if there is a name 
present. I would bet that nobody does this. And if you don’t do it like 
that, chaos will occur if you decide to display the name.

In contrast, if you do it based on region, it would simplify things much 
more:

1. You take the nodes/relation for Canada, add language=en.
2. You take the nodes/relation for Québec: language=fr

Then everybody would just continue using name=British Columbia and 
name=Montréal, and no problem. The multilingual renderer would then 
show, in case the user wants to see French names, name=Montréal and 
name:fr=Colombie-Britannique. If the user is English, he would show 
name:en=Montreal and name:British Columbia.

Tell me where this is not easier than adding a redundant name:en or 
name:fr for every town, bus stop and street in Canada. You would only 
have to change the multilangual renderer so that it would display it 
like that. This is no problem because I guess it is still in development 
– It could be done relatively easy (from a non-developer standpoint 
speaking).

Plus, most of todays nodes only have a name=... tag, not a name:xyz=... 
one. You would not need to change anything.