Unable to localize labels into Chinese
Style.localizeLabels(into:forLayerIds:) is unable to localize the map’s labels into Simplified Chinese or, one of the locales supported by Mapbox Streets source v8. Attempting to localize the labels into Simplified Chinese results in a symbol layer that is either unlocalized or completely blank. This issue also affects Hong Kong Traditional Chinese.
Diagnosis
As of #480, Style.getLocaleValue(locale:) hard-codes the locale codes supported by Mapbox Streets source v8:
https://github.com/mapbox/mapbox-maps-ios/blob/34ea7ada3cea926ea308d00dd003178a16d3164e/Sources/MapboxMaps/Style/Style%2BLocalization.swift#L38
However, it matches the passed-in Locale’s bare language code against that list:
https://github.com/mapbox/mapbox-maps-ios/blob/34ea7ada3cea926ea308d00dd003178a16d3164e/Sources/MapboxMaps/Style/Style%2BLocalization.swift#L40-L43
A phone may be set to a Locale with the identifier zh-Hant-HK, meaning Hong Kong Traditional Chinese. But this Locale’s language code is just zh, so despite zh-Hant being supported by the Streets source, the method ends up localizing into zh, which is just Chinese. The special logic to map zh-Hant-TW to zh-Hant does not apply to zh-Hant-HK.
Another common identifier is zh-Hans-CN, which also falls through the cracks and gets mapped to just zh.
convertExpressionForLocalization(symbolLayer:localeValue:) ends up replacing each name_en get expression with a name_zh get expression. But the Streets source no longer supports the generic zh locale as of v8; instead, only name_zh-Hans and name_zh-Hant fields are provided. Depending on the style’s fallback rules, the label will either appear in the local language rather than Chinese, or it will be blank.
Suggestion
supportedLocaleIdentifiers should be a list of locale codes that appear in the names of name_* fields in the Streets source – nothing less, nothing more.
When matching against this array, check both Locale.languageCode and Locale.regionCode.
/cc @mapbox/maps-ios @mapbox/navigation-ios
mapbox/mapbox-navigation-ios#3330 works around this issue with more robust locale selection code ported from map SDK v6.x.
This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.
On iOS 16, Locale.Language.Components take the guesswork out of locale identifier parsing, but the logic above can still be tightened up regardless.
#1602 defaults zh to zh-Hans, but it still doesn’t allow an application to pass in zh-Hans-CN, zh-Hant-HK, or zh-Hant-TW, which is what the operating system would report for Chinese.