Open 1ec5 opened 6 years ago
This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.
This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.
-[NSExpression(MGLAdditions) mgl_expressionLocalizedIntoLocale:]
recurses through the expression tree, aggressively localizing any key path expression it finds. This ensures that even the most sophisticated expressions can be localized. However, a style may intentionally feature bilingual or multilingual labels, in which case this functionality would produce redundant labels. For example, “London (Londres)” might turn into “Londres (Londres)”. Theformat
expression support being added in #12624 is likely to increase the likelihood of bilingual expressions, so it’ll become more important to make the localization functionality more nuanced.We’ll have to come up with a heuristic for detecting bilingual
concat
andformat
expressions, as opposed to expressions that serve other purposes, and dealing with them:name_*
attributes being used in the expression and shuffle them around, but this would require-[NSExpression(MGLAdditions) mgl_expressionLocalizedIntoLocale:]
to take additional parameters for context.It’s worth noting that MapKit doesn’t display bilingual labels at all, while the Google Maps SDK displays localized bilingual labels.
Ultimately, we need something upstream to support localization as a first-class feature that the SDK can simply pass the current locale into. One proposal is for dedicated locale-matching expressions (mapbox/mapbox-gl-js#6197), perhaps streamlined by additions to the TileJSON format (mapbox/tilejson-spec#14) or “style components” in Studio (mapbox/mapbox-gl-js#4225).
/ref https://github.com/mapbox/mapbox-gl-native/issues/11867#issuecomment-405660217 /cc @fabian-guerra @ChrisLoer @nickidlugash