Render names according to the language the user is using?

[SteveLz]

Is it possible to add a language switch option on the home page and render the map according to the language selected by the user?

[danrademacher]

Good question. Currently we show the Name tag in whatever language it is provided:

Example: https://www.openhistoricalmap.org/node/2091139302#map=14/37.4742/35.0409&layers=OD&date=1922-01-01&daterange=1922-01-01,2022-12-31

Providing a user switch here is an interesting challenge since within any given map view, we might have an unknown number of languages available in the tags of the items in view, and that might change based on zoom level.

I wonder how the big map providers handle this. We know they do! But they probably rely on locale setting rather than a map specific interface element

[SteveLz]

Tracesmap, an OSM-based layer provides the option to switch languages. Because it is using a raster layer, a name layer is rendered for each supported language. And OHM uses vector rendering, maybe it won't be so complicated?

[1ec5]

OHM’s vector tile stack is similar enough to OSM Americana’s that it might be possible to leverage some of the work that went into automatic language switching (ZeLonewolf/openstreetmap-americana#578) and local language glosses (ZeLonewolf/openstreetmap-americana#592) in that style. The functionality is based on language-qualified name:* tags that Planetiler includes in the tiles per the OpenMapTiles schema and this Planetiler configuration. The Americana stylesheet includes some complex expressions to choose which name tags to include in the labels.

At a glance, there are two obstacles to localized labels in OHM:

• Only name is included in the vector tiles, but no name:* key is included, as you can see by clicking on “Éire / Ireland” in this inspector and comparing to this node.
• The Historic, Woodblock, and Japanese Scroll styles all use the deprecated {token} syntax in text-field properties. This syntax doesn’t support fallback logic, so if a particular feature lacks a name:* in the user’s language, they’ll see nothing. The Mapbox GL Language plugin requires expressions, as does the more sophisticated code that Americana uses to label features. Maputnik includes a rudimentary expression editor (maputnik/editor#620), though progress seems to have stalled on something more sophisticated (maputnik/editor#622). If that doesn’t work for some reason, there’s always Mapbox Studio.

This would be a minimum viable path to localized labels:

• [x] If we’re still using osm2pgsql, this tag transform needs to include name:* keys.
• [x] The tiler should include arbitrary name:* keys, or at least the most common name:* keys, in its TOML configuration.
• [x] The Historic, Woodblock, and Japanese Scroll styles need to migrate text-field properties from the legacy style function and token syntaxes to expressions. This can happen layer by layer; it doesn’t have to happen all at once.
• [ ] Pick out the relevant changes from openstreetmap/openstreetmap-website#4042, specifically the parts that install Mapbox GL Language and configure it to prefer the logged-in user’s language preference.

Americana plans to eventually split out its more sophisticated bilingual labeling as a plugin (ZeLonewolf/openstreetmap-americana#914), but Mapbox GL Language is a decent starting point.

[jeffreyameyer]

@danrademacher - can we get this broken out appropriately as an example of a tile styling pipeline improvement, per our weekly meeting today?

[jeffreyameyer]

IMO, it would be best to have a 2-line labeling system of some sort - first line is viewer's language, second line (smaller) is the local language.

e.g.,

[danrademacher]

@danrademacher - can we get this broken out appropriately as an example of a tile styling pipeline improvement, per our weekly meeting today?

Here's what I see in the notes there:

Tile styling pipeline / processing to help improve cartography? Label points? (polygon points, etc.) Multilingual labeling

Last line links back to this ticket.

I can guess that we need two tickets here, one for vector tile creation changes for DevSeed and the other for style changes by Greeninfo to come after.

But I am not sure what the DevSeed part looks like.

@batpad can you add some details? Then I can see how to best split this up.

[1ec5]

IMO, it would be best to have a 2-line labeling system of some sort - first line is viewer's language, second line (smaller) is the local language.

This is blocked on ZeLonewolf/openstreetmap-americana#914, but I think even just labeling in the user’s language would be an improvement in the meantime.

My breakdown in https://github.com/OpenHistoricalMap/issues/issues/481#issuecomment-1676049823 assumes client-side language filtering, but ideally the client could just pass its preferred language(s) to the server as a URL query parameter and the server would resolve the languages down to a single name field. The OSM Americana project is working on something like this for its Planetiler- and AWS-based stack, but I don’t know if it would be compatible with OHM’s Tegola-based stack. Regardless, client-side filtering does work for any tileset, so we’ll try to package that up for OHM to use.

[jeffreyameyer]

Let's disregard the 2-line labeling requirement for this ticket and see what we can do to enable the original request of rendering labels in the viewer's language, using either of the methods @1ec5 describes above – client-side language filtering or passing the viewer's language as a URL-query parameter.

[jeffreyameyer]

@danrademacher - is there anything we are blocked in from Minh's comment above? https://github.com/OpenHistoricalMap/issues/issues/481#issuecomment-1676049823

[batpad]

@Rub21 @geohacker - can we add all name:* keys to the vector tiles?

[jeffreyameyer]

Moved the request above to #679

[jeffreyameyer]

Breaking apart the 2-line labels into a separate ticket: #799

[jeffreyameyer]

Per @1ec5's comment above, I'd say the Historic style layer is the most critical here, followed by the Rail style, and I'm not sure if the Japanese Scroll or Woodblock styles should or shouldn't have the localization for effect.

Most important: no other style layer should be a blocker to getting the Historic style pushed to production first.

[ ] The Historic, Woodblock, and Japanese Scroll styles need to migrate text-field properties from the legacy style function and token syntaxes to expressions. This can happen layer by layer; it doesn’t have to happen all at once.

[jeffreyameyer]

For the rest of Minh's checklist, I believe the first 2 items are covered by #679, so why don't we make this ticket solely for:

• [ ] Pick out the relevant changes from https://github.com/openstreetmap/openstreetmap-website/pull/4042, specifically the parts that install Mapbox GL Language and configure it to prefer the logged-in user’s language preference.

We can put the stylesheet stuff in a separate ticket.

[danrademacher]

Ok, so looking at the changes and comments in the PR https://github.com/openstreetmap/openstreetmap-website/pull/4042/files, there's a lot to process here.

As far as we know, is the PR to OSM fully functional but just subject to debate about desireability? I see based on the comments over there that it might be working at https://osm.openmaptiles.org/#map=5/25.364/92.153&layers=V, though when I use my locale switcher to test different languages, I don't see labels changing (tried French, Arabic, Chinese, Vietnamese), though maybe they are changing in some cases I'm not noticing. I thought maybe I needed to log in to see it work, but I couldn't get my OSM login to work on the OMT clone, and also couldn't make an account there. I might be missing something!

Anyway, question stands: Is that PR working code we need to mine for insights into how we would do it, or maybe we don't know? Either answer is fine, but I'll frame our approach differently depending.

[1ec5]

Yes, openstreetmap/openstreetmap-website#4042 is functional last I checked. However, MapTiler recently removed support for backfilling translations from Wikidata over concerns about misleading mappers into thinking the translations are coming from OSM. So in practice, you’re going to see far fewer translated labels on that site. Fortunately, we don’t use MapTiler-hosted tiles. At some point we may want to have our labels fall back to Wikidata also, but that’ll be independent of this effort. (It may require more substantial work such as migrating away from Tegola.)

The only interesting aspect of that PR from our perspective is hooking up the language selection to your account preferences. Otherwise, it’s just a straightforward installation of the mapbox-gl-language plugin. But it won’t work until the tiles contain the localized names (#679) and the styles migrate to expressions (#775) so that they can read those localized names with an appropriate fallback.

[danrademacher]

Update on this ticket:

• The main historic style in #775 is close to fully converted to expressions, though not the most important part for this ticket (text labels). But Tim has a clear path and that should happen shortly.
• Then we can prioritize #679 for getting name:* into vector tiles.

Regarding the frontend for this, since @1ec5 wrote his original todo list for this last October, we moved away from old MapboxGL to new MapLibre.

Do we know if https://github.com/mapbox/mapbox-gl-language/ works with Maplibre? First line of the README is that it requires mapbox-gl-js, but we also use the RTL plugin with MapLibre and overall I know Mapbox GL plugins tend to work in MapLibre, so probably this is fine.

[1ec5]

Yes, mapbox-gl-language works with MapLibre GL JS too.