[OSM-talk] Transcription and 'internationalization' in place names
a.errington at lancaster.ac.uk
Mon Apr 16 10:36:43 BST 2012
On Mon, April 16, 2012 16:54, Maarten Deen wrote:
> 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
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
More information about the talk