So you’re checking out the Japanese localization on your latest project, and hey that’s odd — your NSDateFormatter that you set to [NSLocale currentLocale] is producing output rather unJapaneseish:
Turns out, as described here on Stack Overflow, [NSLocale currentLocale] on a system with a Japanese calendar returns en_US@calendar=japanese even if the user language is set to Japanese. That seems like a rather strange and probably incorrect default behaviour, does it not?
The solution is to set it to the locale of the user’s preferred language,
[dateFormat setLocale:[[[NSLocale alloc] initWithLocaleIdentifier:[[NSLocale preferredLanguages] objectAtIndex:0]] autorelease]];
which produces the rather more Japanese appearing
So … apparently if you want your localizations to actually work as a local user is likely to expect, you should adopt that language-based locale creation scheme. Anybody have any clue why the default works that way and if this scheme actually is the best practice?
And if you’re wondering why your NSDateFormatter date code breaks in iOS 5, why yes your NSLocale may be at fault there too:
… This is an intentional change in iOS 5. The issue is this: With the short formats as specified by z (=zzz) or v (=vvv), there can be a lot of ambiguity. For example, “ET” for Eastern Time” could apply to different time zones in many different regions. To improve formatting and parsing reliability, the short forms are only used in a locale if the “cu” (commonly used) flag is set for the locale. Otherwise, only the long forms are used (for both formatting and parsing). This is a change in open-source CLDR 2.0 / ICU 4.8, which is the basis for the ICU in iOS 5, which in turn is the basis of NSDateFormatter behavior…
Now you know!Continue Reading →