Package label localization as a plugin

[1ec5]

The label localization functionality added in #578 #579 #592 #670 #753 etc. would be useful to a variety of maps, not just Americana. We should ship it as a separate plugin so that Mapbox/MapLibre GL JS–powered maps can benefit from the work we’ve done to prove out these features.

Rationale

Label localization is basic functionality for any map, but GL JS makes this task so complex that most developers don’t bother or do a half-baked job of it. Americana has proven out a robust, reasonably performant implementation that other developers have shown an eagerness to reuse. There are third-party deployments of the Americana style, such as on the OSM Wiki, that lack label localization (“Americana Lite”) because this functionality can’t be used separately from the overall Americana application.

Increased adoption will also lend us credibility when engaging with the OSM community about tagging improvements to facilitate this kind of functionality. As precedent, the German Mapnik transliteration code took on a life of its own, getting adopted by OpenMapTiles and influencing many project-wide decisions about translation and transliteration, because it relied on ICU functionality that was easily ported to different environments. (This influence came despite the approach’s serious flaws and cultural faux pas.)

Americana would complement the existing options for label localization. Mapbox GL Language gets the job done, but it doesn’t support dual language labeling or semicolon parsing. On the other hand, it’s written more generically, whereas Americana’s implementation assumes a typical map labeling context. MapTiler’s fork of MapLibre GL JS has a built-in language switcher, with a focus on location-based language switching (huh?), but its dual-language presentation is not as elegant as Americana’s.

API design

The plugin should give styles flexibility over the font details. Similar to the shield generator library, it can make assumptions about the style’s preexisting text-field expressions, such as the presence of a let expression with a localizedName variable. However, it should also have customization hooks for compatibility with tilesets that aren’t derived from OpenMapTiles.

Implementation notes

The label localization code is already centralized in label.js. There should be few dependencies on other parts of the codebase. The unit tests depend on the maplibre-gl-style-spec package.

If Americana later migrates to a server-side implementation of language resolution, the client-side localization code would be streamlined a bit. However, I suspect most of the functionality in this plugin would still be relevant, because it’s doing more than basic language switching.

/ref #146

[ZeLonewolf]

Ideally, language switching should also support server-side options to switch which languages are exposed in the tiles, as multiple unused languages can inflate tile size significantly. It's not clear to me whether that server-side switching (the code that changes tile URLs when the requested language changes) would be coupled into a label localization plugin or kept outside of it.

Either way I agree that it makes sense to split off the label localization.