iPhone en_* sublanguage localization

Question

I want to localize strings in my iphone app for en_GB and other \'en\' sub-languages, but XCode and the iphone refuse to let this happen. I have created a localization of \"Loca

Answer 1

Create a separate string resource, say UKLocalization.strings, and create localizations for each of your supported languages. For all localizations other than en this file is empty. For en, it contains only the strings that have unique en_GB spelling.

Next, you create a replacement for NSLocalizationString that will first check the UKLocalization table before falling back to the standard localization table.

e.g.:

static NSString* _locTable = nil;
void RTLocalizationInit()
{
    _locTable = nil;

    NSString* country = [[NSLocale currentLocale] objectForKey:NSLocaleCountryCode];
    if ([country isEqual:@"GB"])
    {
        _locTable = @"UKLocalization";
    }
}

NSString* RTLocalizedString(NSString* key, NSString* ignored)
{
    NSString* value = nil;
    value = [[NSBundle mainBundle] localizedStringForKey:key value:nil table: _locTable];
    if (value == key)
    {
        value = NSLocalizedString(key, @"");
    }
    return value;
}

Answer 2

I found the same problem.

BTW, if you look at the iPhone Settings -> General -> International menu, it makes the distinction between language and region quite clear:

Languages:
-English

Region Format:
-United States
-United Kingdom

The localization framework only appears to pay attention to the language, not the region.

I'm tempted to raise an enhancement request for this with Apple, as IMO it is reasonable that a user might want to use British English (for the text) whilst being in the United States (where, say, phone numbers should be in US format).

Answer 3

I’m not sure in which version of iOS it was introduced, but iOS 7 definitely has a ‘British English’ language preference that will pick up resources from the en_GB.lproj directory. The various hacks floating around the web shouldn’t be necessary unless you’re after a more specialised* dialect.

*see what I did there ;)

Answer 4

What you're doing should work according to the docs. But it appears that the iPhoneOS implementation is at odds with the documentation. According to Radar 6158876, there's no support for en_GB language, only locale (date formats and the like).

Answer 5

This can actually be done - check my solution here - iPhone App Localization - English problems?

Answer 6

When you choose 'English' from the list of languages on the iPhone preferences, that actually means the 'en_US' language.

So until apple update their software with additional sublanguages like "English (British)" etc. we are left with going by the locale region setting, and loading strings manually from another string table.

However, the language and regional locale are separated for a reason: a Spanish user in the UK may want dates/times formatted according to the local customs, but program strings in their native tongue. It would be incorrect to detect the regional locale (UK) and therefore display UK strings.

So basically there is no way to do this currently.