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

[Philip Barnes]

On Mon, 2012-04-16 at 14:26 +0200, Claudius wrote:
> 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
> 
http://www.openstreetmap.org does seem to be rendering multiple names
for Welsh towns, separating them with a /. Hence giving the Welsh
Jubilee city of St Asaph as Llanelwy/St Asaph. Strangely the Welsh name
disappears at certain zoom levels, http://osm.org/go/eufQoa2--.

It is using the tags name:cy and name:en. It works for a lot of places
in Wales, buy not for Cardiff. Maybe it can only cope with 2 languages.

Phil