I keep getting questions about multilingual names in OpenStreetMap, so I want to state my position clearly in one place.

I understand the OSM data-model argument: name:xx should normally represent a name that actually exists in that language, not simply a machine-generated translation. My mapping practice has evolved accordingly.

However, as a product person, I care primarily about the user experience.

A map is a product used by real people. If I travel to a country whose writing system I cannot read, a map that shows me only the local script may be technically pure but practically much less useful.

For example, an English-, Russian-, or Georgian-speaking traveller should not need to read Arabic, Chinese, Thai, or another unfamiliar script just to understand what street, station, church, village, or other place they are looking at.

There are several ways to solve this:

• verified names in the user’s language;
• standardized transliteration;
• localized rendering;
• automatic transliteration or translation at the application layer;
• sensible fallback rules when no localized name exists.

I do not particularly care which layer solves the problem.

What I care about is the outcome:

the user should be able to understand the map.

Database purity is useful when it improves data quality. It should not become an excuse for poor UX.

OpenStreetMap is a geographic database, but the value of that database ultimately comes from people being able to use it.

For OSM naming guidance, see:

• Names
• Multilingual names

This post also reflects the lessons I took from my earlier discussion about AI-assisted multilingual tagging. I no longer treat automatically generated translations as sufficient evidence that a name:xx exists.

But my broader position has not changed:

when data modelling and usability pull in different directions, I will keep advocating for a solution that gives users both accurate data and a usable map.

… See full entry