0
votes

Suppose my app supports English and Spanish localizations to the extent that it includes en.lproj/Localizable.strings and es.lproj/Localizable.strings. Suppose also that it runs on an iPhone whose region is set to German.

In this case I want to display dates in English (not German) in order not to produce a user interface that is partly English (due to en.lproj/Localizable.strings) and partly German (due to the selected region) and that may hence include "mixed" strings such as "Weekend edition, Samstag, 10.1.".

So how can I find out programmatically from within an iOS app which localization is actually in use (e.g. English in the case of the iPhone whose region is set to Germany but where the app only supports English and Spanish localizations)?

1
Wrong, a Spaniard who doesn't speak english but knows a bit of german might have the preferred order of localisation as 1. spanish 2. german. As you don't have a Spanish localization option, the german localization is going to be used by default in this case, not english. Leave it to the user to decide what he wants to see.A-Live
@A-Live My intention is to let the user decide what she wants to see. Say he has indicated the preferred order as 1. German, 2. Spanish. My app does not support German localization, so Spanish offer to the best offer to user under the circumstances. My question is about how I can find out in the application that Spanish (not German) was chosen so that I can fit other formatting, such as for dates, accordingly.Drux
Region formats have separate settings, there's even an option to have the dates, times and whatnot format to be specifically different from the chosen primary device settings; as a user I'd expect to see these settings used as they are provided even if it sometimes lets a mix of languages. You always have an option to create a special localized value and check the result, the main issue I can foresee is that it won't be as fine-tuned and will require too much efforts to support.A-Live
@A-Live So now that I've heard what may be desirable I'm still left wondering what is technically feasible in terms of querying the "actual" localization (e.g. "es", not "de" in the running example). I'm not saying you are wrong, but my question focuses on the feasibility (of obtaining "es" in this case).Drux
How about NSLocale -preferredLanguages then, it seems to be doing the job you want.A-Live

1 Answers

0
votes

I've found that the following can do the job (based on a lead in this related question):

NSArray *preferredLanguages = NSLocale.preferredLanguages;

NSString *actualLanguage = nil;
for (actualLanguage in preferredLanguages)
    if ([NSBundle.mainBundle pathForResource:actualLanguage ofType:@".lproj"] != nil)
        break;

if (actualLanguage == nil)
    actualLanguage = @"en"; // default