views:

291

answers:

3

Hi all, I have an app that has some non-US Localizable.strings files. They appear in the project as I expect them to: there's a Localizable.strings object, and sub objects for "en", "fr", etc. Each of those is a UTF16 text file, and I've verified that they get propagated into the build package as correct binary plist files.

When running my app, though, even when device settings are some other language, only the strings from my English Localizable.strings file come back

Preferred language from NSLocale is e.g. "fr" AND I can see that the device setting is getting through somehow, because the system toolbar buttons ("undo", etc) are translated.

But my strings are still in English. (Note that they are coming from the .strings file, as I've edited that to verify.)

So: strings files seem OK, and get built and deployed OK.

Is there something else I need to do to "tell" the project that other locales are supported?

Thanks!

A: 

For the particular problem of en_US always coming back, you need to be querying preferredLanguages for the array of preferred languages currently, not currentLocale.

Does NSLocalizedString does not return the keyed string from the correct file?

IN localization you have to be sure you are changing what you think you are changing. If you change Language in preferences then it will affect the string that comes back from your localizable.strings file. If you change settings under Region Format that's only date, currency symbol etc. This is a good simple guide I have used with success.

Adam Eberbach
Adam, thanks for the answer. When I change Language in preferences to "French", my first preferred languages is "fr" (which is right). But then NSLocalizedString returns the strings from my English .strings file. Any ideas?
quixoto
Updated the question for clarity.
quixoto
You are setting Language under the International heading to French, so it should get text from your "fr" file under localizable.strings. I would guess that it is falling back to English for some reason - could there be any problem with your strings file or selected encoding? I am not completely sure of this but perhaps mismatched quotes or semicolons in the strings file might cause this. And your keyed resource must be present of course.
Adam Eberbach
Yep, I agree that this should be working, and that it seems to be falling back to English. But the plist .strings files (the ones that are generated by the build itself into the app package) open fine with Property List Editor, and look reasonable.
quixoto
A: 

This happens (apparently) when there is a Localizable.strings file in the root of the project in addition to in the individual .lproj directories. The app seems to always prefer that if it's present. The fact that it was there was likely an artifact of mucking around trying to get the localizations working in the project.

I'm leaving this question here in case others run into this issue.

quixoto
A: 

And if you run an application with the Localizable.strings file in the root of the project, cleaning is not enough, you also need to delete the application from the simulator.

Thomas