0

When I have an UI string with capital letters, i'm used to define them in lowercase as for all the others, and then to use uppercaseStringWithLocale:[NSLocale currentLocale].

But recently I happened to notice that the [NSLocale currentLocale] may not be the one used in your app. For example if your device is in Turkish but your app only support english, the currentLocale would be a Turkish locale while your app is localized in english.

With those settings, a direct effect of using [NSLocale currentLocale] is that my uppercaseString will be "İ LİKE İOS" instead of "I LIKE IOS".

So far, the only workaround I see is to create a category of NSLocale to add a +(NSLocale*) applicationLocale; and use it in all uppercaseStringWithLocale:.

+ (NSLocale*) applicationLocale
{
    NSMutableDictionary<NSString*,NSString*>* localeComponents = [[NSLocale componentsFromLocaleIdentifier:[NSLocale currentLocale].localeIdentifier] mutableCopy];
    localeComponents[NSLocaleLanguageCode] = NSBundle.mainBundle.preferredLocalizations.firstObject;
    return [NSLocale localeWithLocaleIdentifier:[NSLocale localeIdentifierFromComponents:localeComponents]];
}

My question is simple: am I doing this the right way or did I miss something? I indeed wonder why Apple links to currentLocale while it won't work as expected in a lot of cases.

Michael
  • 6,451
  • 5
  • 31
  • 53
Imotep
  • 2,006
  • 2
  • 25
  • 38

1 Answers1

0

The most robust way to get the application locale is to edit your Localizable.strings files. In the English localization file add an entry

"lang"="en";

in the German localization file add an entry

"lang"="de";

in the French localization file add an entry

"lang"="fr";

and so on... You can get the localization code with NSLocalizedString(@"lang").

Michael
  • 6,451
  • 5
  • 31
  • 53
  • Why isn't NSBundle.mainBundle.preferredLocalizations.firstObject robust enough? – Imotep Dec 31 '15 at 09:44
  • @Imotep: what happens if you have English, German and French in your app, but only English and French localization files? (E.g. you use the German localization just for some of the XIBs, so this isn't a totally contrived example.) - if the preferredLocalizations are robust enough depends on your particular situation. it also depends on the languages you use. E.g. if you only use English, German, French and Spanish, you can use just `-uppercaseString`, because it behaves the same as `-uppercaseStringWithLocale:` for many locales. – Michael Dec 31 '15 at 09:58
  • @Imotep: You can even create a category on `NSString` and call the method `-localizedUppercaseString`, default to `-uppercaseString`, and update that method as soon as you add Turkish (if that ever happens)... – Michael Dec 31 '15 at 09:59
  • Using a language in only specific xibs is to me either a dev error or a very specific need which is obviously not covered by the 'applicationLocale'. The only legit case that comes in my mind is when you make some sort of translator app. In this case you won't want to use the currentLocale, applicationLocale or even the "lang" localizedString. You'll use a temporary locale based on in what language you want to translate in. About creating a NSString category, I doubt it would be robust enough because it implies to handle every existing language while 'applicationLocale' already works with all – Imotep Dec 31 '15 at 10:34
  • @Imotep: are you sure you're not just wasting time? Have you found a single instance where just `-uppercaseString` didn't behave the way you wanted it to behave? You sure have found a case were `-uppercaseString` behaved well, but `-uppercaseStringWithLocale:` did not. Handling every possible case is good if you are creating a library, or a reusable component, but it just doesn't give you any additional customer satisfaction if your customers are not developers. – Michael Dec 31 '15 at 10:52