Localizable.strings override custom strings file

[bddq]

I've spent too much time trying to understand why my app doesn't use my custom french language.

My app is only localized in french but my testing phone is in english. I've set my native development region to french in order to make the default language in french but running my app on my english phone will use the english localizable.strings file made by ShareKit. My app doesn't include an english localizable.strings file.

In consequence, my french language is not displayed because the phone found an english localizable.strings file and use it in place of french one!
The only one solution to use just French is deleting localizations files provided by ShareKit (or translating a complete one in french).

Maybe the ShareKit will use a bundle (like in Three20) in order to provide ShareKit UI translations.

Thanks. Benoit

[steipete]

I implemented localization as a bundle, but this code was later changed to use NSLocalizedString instead of my custom localization code. I don't know why... but anyway - you can find the original code in the history.

[blackjack75]

I'd recommend using a macro for all translations with a separate SharekitLocalizable.strings:

#define SHK_TRANS(key) NSLocalizedStringFromTable(key, @"ShareKitLocalizable", nil)

So far to prevent sharekit from overwriting my apps localization I actually used that Macro in my apps and let sharekit use the 'standard' name.

[memmons]

Completely agree with blacjack75 above. Frameworks should always use the NSLocalizedStringFromTable(key, filename, comment) function for localization. Otherwise, if you use it in your project which already has a Localizable.strings file either your project won't localize or ShareKit won't localize -- depending on which one gets copied to the app container last.

I'm surprised more people haven't commented on this bug. Either almost no one that uses ShareKit has localized code or almost no one is testing that their localization is working.

[postmechanical]

Just ran into this issue myself. I concur with the previously recommended solution. Shared components should be designed to be truly reusable. The present situation is the reverse in that users of this great library nonetheless have to tweak the code or rework their own app.

[lexar]

Man, I got some grey hair over this! Couldn't figure out why my localizations weren't working. Strangely, only after I deleted Localizable.strings and ran genstrings again, I got a warning from XCode that there were multiple build targets for that file, which eventually led me here. blackjack75, thanks a lot for that solution, worked perfectly. I agree that it's odd that so few people stumbled upon this!