[Bug]: Alternative Route ETA difference label not localized

[JanTG1]

Mapbox Navigation SDK version

3.2.0

Steps to reproduce

1. Create a NavigationMapView
2. Calculate a Route that has multiple, equally good routes available
3. use NavigationMapView.showsAlternatives = true
4. showcase the Route including its alternatives using NavigationMapView.showcase()
5. Look for the alternative Route on the map and inspect the ETA difference label

Expected behavior

If the ETA difference is large enough, show the difference (in example -5 minutes or +5 minutes). If there is no real difference between the two eta's, show a localized label "Similar ETA" in the Apps current language.

Actual behavior

If the ETA is similar, the alternative will have a label "similar ETA", which will not be localized correctly (it aways shows in English, even if the rest of the navigation is in french, german or any other language). I would be expecting something like "gleich lang" or "ähnliche Ankunftszeit" in german for example.

Our users are reporting that issue repeatedly, as some don't speak English and don't even know what ETA means.

Is this a one-time issue or a repeatable issue?

repeatable

[kried]

Hi @JanTG1

Thank you for the report. Unfortunately, the SDK is not fully localized at the moment. The label Similar ETA is available in a limited amount of languages. We will improve the localization coverage in future releases.

At the moment, you can customize the localization by yourself. We added the support for this feature in this commit. So you can add Localizable.strings with the key SAME_TIME to your bundle and set this bundle to LocalizationManager.customLocalizationBundle. The customized localization value will then be used only for the Similar ETA label.

[JanTG1]

Thank you for pointing that out @kried. I don't understand where I can set the customLocalizationBundle, as I cannot find any reference to it on MapboxNavigationProvider, NavigationOptions or even NavigationViewController. Adding the required Key to my own Localization Bundle is easy, but I don't see how I can tell Mapbox to use my own bundle if possible.

[kried]

Hi @JanTG1

Please note that LocalizationManager was added to the main branch in the repo, but it hasn't been released in any SDK release. It will be available in v3.3.0-rc.1.

LocalizationManager.customLocalizationBundle is a static property, you can set it as simple as:

LocalizationManager.customLocalizationBundle = .main

as I cannot find any reference to it on MapboxNavigationProvider, NavigationOptions or even NavigationViewController.

LocalizationManager is used in the String extension that is used across the SDK.

[JanTG1]

@kried Thanks again for helping. I have tried what you told me to do and it works, at least kind of. I am now able to supply alternative localization for pretty much all of the labels I need to. However, I noticed an issue with it. I don't know if this should go into a separate issue but for now, I'll write it down here:

The issue is that many of the previously working localizations suddenly stopped working, but not all. For example, when opening the Steps View, the close button previously said "Schließen" in german. The Translation for it can be found when searching trough the code:

"DISMISS_STEPS_TITLE" = "Schließen";

However, after applying the custom localization, this label now shows "_NONEXISTENT_KEYVALUE". This can be fixed by adding my own localization for that label - but it shouldn'T be broken in the first place since the label clearly exists. The same can be said for a few other labels, but as I said, not all. Some are working without giving them my own custom localization, which is what I would expect.

[kried]

Hi @JanTG1

I was able to reproduce the mentioned problem with NONEXISTENT_KEY_VALUE only when the debug option “Show non-localized strings” is enabled in the Xcode.

You can disable this setting to see the localized strings.

This case-sensitive string comparison here causes it. With “Show non-localized strings” enabled, the result from NSLocalizedString() is uppercased. We will fix this in the next releases.

[JanTG1]

@kried thank you for pointing that out. I disabled that option and indeed - all lost localizations came back. The issue can be closed.