Sorry, the example may not have been clear. It was simple an example of a bilingual tag that might be used in a place where signs show the name in Chinese characters, plus a latin alphabet version. This might happen in an overseas Chinese community. I was mainly looking for a combination of two tags that might be found, one of which uses a standard ISO code and the other of which is used in OSM but is non-standard, just to show the possible format.
In most cases there is going to be one language, just like most name tags are currently in one language, and that will be the local or official language, in the script used on signs. Brussels, Belgium, and Morocco and a few other places are unusual exceptions. So I think it should work the way you would like; the locally used name, in the local script, should be displayed. Joseph On Sun, Sep 16, 2018 at 9:51 PM Paul Allen <pla16...@gmail.com> wrote: > On Sun, Sep 16, 2018 at 12:21 PM, Joseph Eisenberg < > joseph.eisenb...@gmail.com> wrote: > [...] > > I don't (yet) have an opinion either way on the feasibility or > desirability of tagging languages used in a region. But this... > > It should be interpreted with the individual language name tags. >> If the default language is zh;zh_pinyin (Chinese and romanized Chinese), >> there should be a name:zh and name:zh_pinyin tag on each feature within the >> boundary, in theory, and these two name tags should be combined in an >> international map rendering. >> >> In theory, this should look similar to what we currently get with the >> name=* tag >> > > This is something I strongly disagree with. For most objects, name=* > should not be translated because, for most > objects it should be, in my opinion, an opaque representation of signage. > If I don't speak the local language I need to > know what to look for on the street sign or the shopfront sign as > represented on the signage. Knowing what it would > say if the locals had decided to put up signage in English is not very > helpful. An IPA rendering of the local pronunciation > of the name might be beneficial for those with text-to-speech. > > If a sign is bilingual then using name=xx: and name=yy: are perhaps of > merit in breaking down the components of the > full name. E.g., a sign near me says "Heol Napier / Napier Street" (the > slash isn't actually present, the name is broken > up into two lines) and so name="Heol Napier / Napier Street" + > name:cy="Heol Napier" + name:en="Napier Street" is > one possible way of representing it in a meaningful way. > > But how are you going to handle a house name like "Duncavin" which is > about a mile from me? The "Dun" is > Scottish for "fort." It's a house in Wales which is bilingual > English/Welsh. And the name is a bad pun. Displaying > the name phonetically might help somebody asking a local where the place > is. Displaying a translation (even if > the pun works in the other language) isn't useful. What's needed is what > the sign actually displays, not what it would > display if it were in a different language. > > Yes, knowing the language(s) spoken in a particular region might be > useful. Yes, having the query tool display tag names > like "shop" and "amenity" in the user's preferred language would be very > useful. Rendering a house name like "Penrallt" > or "Y Felin" in Cryrilic or Arabic or Hebrew script isn't really going to > help anyone because house and street names are > often labels whose meaning is opaque. Is 在米爾路上 (blame Google Translate, > not me) really going to help somebody > looking for a sign that has these literal characters on it: "Garnon's Mill > Road"? Conversely, if I were in China and I > were looking for a road signed "在米爾路上" would it help me to know it meant > "Garnon's Mill Road"? > > -- > Paul > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
