Repository navigation
Add toggle for map label localization #6244
Description
Problem
The locale selector added in #5201 #6024 lists the languages for which we have user interface localizations. As of #4042, it also affects the MapTiler OMT layer by default, so that users have no way to see what the style originally looked like before applying label localization. The map on the homepage is partly a QA tool, so we should always have an option to see labels based on the most important name key, name=*. Moreover, some members of the community prefer an unlocalized map for ideological reasons, valuing multilingualism over reading comprehension.
Description
The locale selector could have an additional “Multilingual” option that maps to mul, the ISO 639 code for multilingual content. For non-map content that doesn’t have a generic analogue to name=*, it would be equivalent to leaving the setting blank and using the usual fallback mechanism. This is a common approach taken by other maps such as Mapbox, OSM Americana, and OpenHistoricalMap. It would also be consistent with the Wikidata integration added in #6127.
Better yet, we could add a separate option about whether to localize map labels. This would allow users to see unlocalized labels even if they want to use a custom locale for the interface. This option is available in other maps such as Apple Maps. The option could live at the bottom of either the locale selector modal or the the Map Layers panel, near the overlay options.
The option would basically disable the transformation that maplibre-gl-language does to the style. I don’t think it would be necessary to force-unlocalize a style. We can probably assume that any featured layer would be international in scope to begin with.
Screenshots
No response
Activity
tomhughes commentedon Jul 24, 2025
There is no "usual fallback mechanism" for UI languages that I'm aware of?
1ec5 commentedon Jul 24, 2025
I was thinking of the difference between the Preferred Language and Preferred Languages preferences. If I clear out the latter, we repopulate it with
navigator.languagesfrom the browser. So maybe if the Preferred Language preference ismul, it could fall back tonavigator.languagestoo. But if we can have a separate preference about localizing map labels, that would be more intuitive to users anyways.hlfan commentedon Jul 24, 2025
We have two sets of color scheme options, so why not separate localization controls?
[-]Add multilingual language option[/-][+]Add toggle for map label localization[/+]1ec5 commentedon Jul 24, 2025
By the way, for many users, the lack of this option is papering over MapLibre’s lack of support for complex writing systems: maplibre/maplibre-gl-js#50.
tomhughes commentedon Jul 24, 2025
We've only just got the ability to override the browser language settings in all contexts, which has long been requested, so we really don't want to go back to relying on it.
1ec5 commentedon Jul 25, 2025
Got it, so the separate toggle would be more realistic. I’ve retitled this issue to reflect that fact.
thany commentedon Jul 31, 2026
Sorry to butt in, but I just ran into this as well. Don't count me as an expert, but some apps that use OSM to show maps do show labels in English, but on openstreetmap.org it always shows labels in the local language. So in Japan, all labels are in Japanese. This is great for the Japanese, but not great for everyone else. Likewise, all labels outside Japan are as difficult to use for the Japanese, as Japanese labels are for me.
At least when I use the search feature, I can type placenames in English. Mostly.
I understand the localisation data has to be actually available, but can we please agree that for the big cities, that data is definitely available? And I'm pretty sure localised labels exist for an enourmous amount of Japanese places, simply because of their non-roman script.
When discussing "usual fallback mechanism" it cannot be that hard to imagine that Japanese (or Chinese, Korean, Arabic, Hebrew) is not in any of the language settings of a browser of anyone living in Europe who's born & raised in Europe, because those languages don't exist there.
The fallback should be: user setting (if logged in) -> browser language setting -> map-local labels.
Someone in Germany might already have in their browser: de -> en. So for Korean labels it would go: de -> en -> kr. If that same person for somereason has Spanish set in their user profile, it would go: es -> de -> en -> kr.
I wonder, is this somehow really difficult? No offence but there are thousands of websites doing this exactly... Can someone please outline exactly what the pain points are? Maybe it's not actually not as difficult as it's made out to be.
tomhughes commentedon Jul 31, 2026
We do now do map label localisation for those layers which support it, which is currently only the MapTiler OMT layer.
Raster tile layers like the standard layer are never going to do it - it can only work for vector tile layers where the rendering is done on the client.
Our vector layer (the Shortbread layer) doesn't currently support it but I expect it to at some point at which point we will enable it and then at some point that layer will quite likely become the default.
None of this is really anything to with this repository though, as we don't produce or manage any of the map layers, we just work with what is available to us.
1ec5 commentedon Aug 1, 2026
shortbread-tiles/shortbread-docs#106 added localized names to the schema, but the OSMF tiles still need to include them before the client-side code can switch to them. pnorman/spirit#80 is the next step, but the list of supported languages is still to be determined.