[OSM-talk] Transcription and 'internationalization' in place names

[Claudius]

Am 16.04.2012 11:36, Andrew Errington:
> On Mon, April 16, 2012 16:54, Maarten Deen wrote:
> <snip>
>> Wouldn't it be an idea to tag the name in the characterset of the
>> country and have the renderer decide whether or not to render a name:en tag
>> with the name tag? I don't know if the renderingrules allow such a
>> decision to make. After all, the renderingrules decide how the map looks
>> like, and I can understand if countries that do not use latin script want
>> to render a "latin-clean" map. And: do not tag for the renderer. Entering
>> names twice is tagging for the renderer.
>>
>
> I'm glad this topic has come up.  I map heavily in Korea, and here the
> convention has been adopted to have name=* as "Local name (English name)".
>   This is the same as Japan, but I don't know which came first.  In
> addition we have name:en=* (Latin script) and name:ko=* (Hangul script)
> and name:ko_rm=* (Hangul spelled phonetically, in Latin script).  Not all
> tags are present for all objects.
>
> I have gone along with this for a while, but it has always bothered me.
> On one hand, it's great as it actually makes the map useful (for me).  You
> can even justify it by saying that the roadsigns are all printed in Hangul
> and English (they are) so maybe the name=* tag should have both.  On the
> other hand, it's a chore to enter things twice, it increases the
> opportunity for error, and really, it could be done programmatically.
>
> I think the root of the problem is that Mapnik didn't make a bilingual map
> at the start, so it was easier to get an army of humans to enter the data
> twice.  Now we have better renderers, with a good example from MapQuest,
> and this experiment here: http://toolserver.org/~osm/locale/
>
> I think the only problem is how does software determine which language
> name=* is in.  This should be the 'fallback' label that is rendered if no
> language is selected, or the selected language tag is missing.  Actually,
> if you describe it in those terms then it doesn't matter.  If my selected
> language is Korean, then name:ko=* will be displayed, thus overriding
> name=*.  If name:ko=* is missing, then name=* will (or should) contain
> something useful.
>
> In Korea it is most useful (to Koreans and visitors) if we carry on as we
> do, but I would like a tool that automatically constructs
> name="name:ko+<space>+(+name:en+)"

You raised some very good points here, Andrew, but again you came back 
to the argument, that "Mapnik" (I guess you are referring to the map 
rendering at www.openstreetmap.org because MapQuest is also using Mapnik 
to render their open map ;) ) should be made a bilingual map. Still in 
the code OSM is not about the map at www.openstreetmap.org, but about 
the database behind it that hundreds of other projects use. e.g. if you 
create a Garmin map file out of the korean (or even japanese) data it 
seems to be rather harmful to have the Romanization in brackets behind 
the name. If you would want to create a Korean/Japanese only map you 
would have to programmatically remove the brackets if name:ko/name:jp is 
not present.

It should actually be the other way around:
In the ideal world we could (should?) strive for the location node for 
Seoul would contain this data:
name=서울특별시
name:el=Σεούλ
name:en=Seoul
name:ko_rm=Seoulteukbyeolsi
name:ru=Сеул

So a map renderer could easily recreate the current map by using "<name> 
(<name:en>)" as location name, or "<name> (<name:ko_rm>)" to highlight 
romanization to be helpful for korean users.

We should really not follow the approach of making the map at 
www.openstreetmap.org perfect but instead the data behind it because 
that's where we're better than Google and Co.

And btw. Google Maps sometimes even has nur the Japanese location names 
and no problem with that either. See the airport and surroundings here: 
http://g.co/maps/4vu3e

Just take another look at the Mapquest rendering. For me it was an eye 
opener to emphasize on the data quality aspect and away from tagging for 
a nice www.openstreetmap.org

Claudius