Use of the Name tag

Posted by n76 on 17 January 2020 in English (English).

My native language is a dialect of the lingua franca of the late 20th and early 21st centuries. And I live in a culture that is notorious for being adamantly monolingual. But I thought I had some understanding of the issues of mapping names in a way friendly for internationalization.

It seems pretty clear cut when you read the wiki. Put the local name, in the local language, as the value for the “name” tag. You may also put it in the “name:<lg>” tag value too.

To be clear, I am not worrying about the legal name, short name, international name, alternate name, or other various names for a place. Just “the common default name” to put in the “name” tag.

I make paper maps for myself and if traveling like to have both the local name as I will find on signs and the name in English, if available, both rendered. For example:


I may not be able to read the local language but I can compare the glyphs on my map with the glyphs on a sign to see I am entering a specific village. And if an English name exists, even if only (automatic) transliteration, I will have something to verbalize.

But my attempt to produce a map of a trekking destination in Nepal showed that it is not that simple.

First, the local mappers in Kathmandu and apparently throughout Nepal decided to put “Romanized” versions of their names in the name tag. I am not sure what “Romanized” means in this context as they did not specify what phonetics might be used when “Romanizing”. The current tagging of Kathmandu breaks Internationalization:


Please, please, don’t do this. It is specifically discouraged in the wiki. If a transliteration is needed, it can be done automatically by the data consumer. The tagging should be:


Second, even if the “name:<lg>” value is set for the local language but the “name” value does not match how can a renderer determine what the local language is to use for the area? So far the solutions are ad hoc. I have seen suggestions that this has been solved by the OSM DE people. But when I look at the tool kit I see the problem it solves is transliterating a local language if the tag for the desired language does not exist. That is a good and useful thing to do but it is not the problem I am worried about.

Another suggestion is to follow the lead of SomeoneElse who has produced maps with Welsh and Scots Gaelic names in areas where those languages are dominant. This is closer to what I am looking for.

But both the German automatic transliteration and SomeoneElse’s implementations reveal that they use internally coded polylines to define areas where a language is used. In effect they are implementing an additional geographic database to help interpret the OSM geographic database. This seems terribly wrong.

Adding language boundaries to OSM has been discussed and there are issues. So it is unlikely that it will be agreed upon.

One of the issues is that there are places that share a boundary with many localities with many languages. For example, the coast line of the Mediterranean Sea is shared with many countries where many languages are used. What name should be used for that feature? The English one I used? Probably not.

Looking at it from the point of a simple data consumer it seems the following rules would go a long ways to improving how OSM derived maps can be presented:

  • If the feature has a name in only one language, then put that value in for the “name” tag.
  • Strongly encourage mappers to also put that value in the “name:<lg>” tag where “<lg>” is the code for the local language. This will allow data consumers to identify the language used in the “name” tag.
  • If more than one “name:<lg>” tag is present, one of them must match the value of the “name” tag. This allows identification of the language of the “name” tag.
  • If the feature is on a boundary with more than one language, then there may be no local “common default name”. In that case, remove the name tag. If there is a QA tool that complains, then put a “noname=yes” tag on the feature. Yes, the feature has a name, it has multiple names. But we don’t know which is the “common default name” used by the multiple sets of locals speaking different languages.
  • Don’t try to be helpful and put multiple versions of the name in the name tag. That is almost a guarantee that the name tag should be omitted instead. I’d fix that for Mount Everest except that the values in the “name” tag don’t match any of the values in the many “name:<lg>” tags and I haven’t a clue where to move them since I read neither Nepali nor Chinese.

The above suggestions will not fix all the issues with internationalization of names. But given the OSM schema as it stands today, it will make some types of processing possible. For example, if you want to render a map in language “xx” then you can:

  • Use the “name:xx” value if it exists.
  • Otherwise determine the language of the “name” tag, possibly by looking at all the “name:<lg>” values for a match. Once the language has been determined, automatically transliterate the “name” tag to language “xx”.

Rendering a map, like the reference one at or as created by SomeoneElse where local names are used is a harder issue. If a feature has names in multiple languages (e.g. Mediterranean Sea) then which name should be used? That does not seem to have a general answer. If the communities that border the feature have mutually agreed to a common default name then that could be put in the “name” tag. But I suspect a mutually agreed upon default name is unlikely to be agreed to by the parties closest to the feature if they are using different languages.

Comment from imagico on 17 January 2020 at 12:52

I can feel your pain and your suggestions are sound as far as i can see.

A long time ago i proposed a more radical solution to the whole problem:

which unfortunately did not and probably still does not have sufficient support. So you will for the foreseeable future have to try parsing the name tag to try determining which name or what kind of name combination is put there by the mapper to be able to render a consistently labeled map.

Comment from n76 on 17 January 2020 at 18:13

Specifying a format string for how to display names in an area is an interesting concept. I will have to mull it over for a while to consider the implications. On first glance I like it. . . It seems to address the issues I’ve come across while trying to render names. But I’ve found my first impressions on how to do things often run into edge cases, thus my need to mull it over.

I can see where a proposal like that would be met with, to say it politely, “insufficient support” on the tagging email lists. I’ve pretty much given up on those lists, way to much opinionated noise and very little actual thoughtful discussion on defining changes to tagging to meet actual needs.

Comment from imagico on 17 January 2020 at 18:45

I don’t think this is a problem of specific communication channels. A proposal in a very similar direction was not successful either:

It is simply that this would be a big change that would impact a lot of people and tools both on the mapping and on the data use side and that would mean a higher level of abstraction in how names are recorded. Skepticism regarding this is fairly natural and understandable - which however does not mean it is a bad idea in the long term.

Login to leave a comment