Preferred language order not used

[mbuchetics]

If the current language (set in iOS Settings) is not available in translations, the plugin falls back to the development language instead of the next "prefereed language" (as defined in iOS Settings).

Example: iPhone language: Spanish Preferred language order: Spanish, English

Translations available for: German (development language), English, French.

Expected: "English" translation is used. Actual: "German" is used.

When switching back to "NSLocalizedString", the fallback to "English" works as desired.

[mbuchetics]

Manually setting the language fixes the problem and switches back to the correct language (English in this case)

let language = Bundle.main.preferredLocalizations.first!
OneSkyOTAPlugin.setLanguage(language)

[siburb]

Good solution @mbuchetics.

We are having the same issue with new Portuguese translations. We've had the app translated in to pt-BR, however using the OTA plugin, our users with only pt-PT set in their system languages are seeing translations in English.

Using NSLocalizedString, they'd be correctly seeing those translations in pt-BR - indeed, NSDateFormatter and -[NSCalendar weekdaySymbols] etc are all in pt-BR, so we have an odd mixture.

Your tip fixes this, but should be unnecessary.

[rubyluk]

Fixed in https://github.com/onesky/plugin-ios-ota/releases/tag/0.10.1

[siburb]

Hi @rubyluk. Unfortunately, this isn't fixed. The workaround shown above is still necessary to have the same behaviour as NSLocalizedString, and also all the other localized methods e.g. NSDateFormatter etc.

For testing, try the following example:

1. Create an app with a base language of English. Also add pt-BR translations - even just placeholder text to demonstrate the issue.
2. Localize some of the labels using NSLocalizedString, and some using OSLocalizedString. Perhaps also list the [[NSCalendar currentCalendar] weekdaySymbols] to show another example of how the system chooses which language to use.
3. Run the app on a device that only has "pt-PT" (of course this issue isn't only relevant for Portuguese, but it is a good example).

You'll notice that those labels localized using NSLocalizedString are shown correctly in Portuguese, whereas OSLocalizedString has fallen back to the base language of English.

Using the workaround above, we can force the OneSky plugin to use the correct language because we can query the system to see which language it deems most appropriate, and therefore which language it will be using elsewhere. This way, we don't end up with a mixture of multiple languages - English when using OSLocalizedString, and pt-BR when using any of the other localized methods.

As an example, on the system with only the language "pt-PT" configured in the "Language & Region" settings, when we list the preferred languages (NSLog(@"Preferred Localizations: %@", [NSBundle mainBundle].preferredLocalizations);), we see "pt-BR" listed.

Of course, we can continue to use the workaround, but this issue should be reopened.

I hope this helps.

[bretdabaker]

I was able to reproduce the issue (NSLocalizedString vs OSLocalizedString) and have fixed in https://github.com/onesky/plugin-ios-ota/releases/tag/0.10.2. The behaviour should be the same as NSLocalizedString now.

Basically it now uses:

[[NSBundle preferredLocalizationsFromArray:self.availableLanguages] firstObject];

Where available languages are the ones from both local bundles (main and registered fallback bundles) and the OneSky project.