Re: App opens in wrong language on some users' machines
Re: App opens in wrong language on some users' machines
- Subject: Re: App opens in wrong language on some users' machines
- From: Quincey Morris <email@hidden>
- Date: Sat, 05 Mar 2016 17:24:12 -0800
- Feedback-id: 167118m:167118agrif8a:167118sVdkOoBsgx:SMTPCORP
On Mar 5, 2016, at 15:21 , SevenBits <email@hidden> wrote:
>
> I did not, mainly because I was under the assumption that you didn't need to explicitly localize the app in its development language; you could provide translations for specific languages, and if there wasn't a translation for the user's language, then the development or Base language would be used. That would seem to make sense and since it worked for me and the majority of my users... well, I know we're not supposed to make assumptions, but what's a "base language" for, if not to accomplish this behavior?
Here’s what I see in the documentation:
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPInternational/InternationalizingYourUserInterface/InternationalizingYourUserInterface.html
Using Base Internationalization [Updated: 2015-09-16]
> Base internationalization separates user-facing strings from .storyboard and .xib files. It relieves localizers of the need to modify .storyboard and .xib files in Interface Builder. Instead, an app has just one set of .storyboard and .xib files where strings are in the development language—the language that you used to create the .storyboard and .xib files. These .storyboard and .xib files are called the base internationalization. When you export localizations, the development language strings are the source that is translated into multiple languages. When you import localizations, Xcode generates language-specific strings files for each .storyboard and .xib file. The strings files don’t appear in the project navigator until you import localizations or add languages.
(This is a fairly recently updated document, so it should be fairly technically correct, although it’s possible the the introductory material reflects an older implementation.)
The way I read this is that the contents of the base files are treated as English, your development language. Keep in mind, FWIW, that the XIB files are in the base localization. Only the corresponding strings files are in the other localizations, so there is an asymmetry between the base and other localizations.
But, according to your github repository, you have an en.lproj subdirectory *as well as* a base.lproj subdirectory. IOW, your project claims to have an *English* localization on top of the base localization. Logic says this localization would be use *instead of* the base localization on an English system. The languages are the same in this case, but the strings themselves are demonstrably different. Logic says that the nicely complete set of English strings in the base localization are ignored in favor of what’s in the en localization, which happens to be incomplete in this case. Apparently missing strings result in substitutions from a (random?) other localization.
Logic therefore says you should *either* remove the en localization, *or* you should complete the missing portions of the en localization. I don’t know what the considerations might be, one way or the other, but I think I’d probably choose the latter — generate the English XLIFF, fill in any missing bits, re-import. That’s because you might choose to send the English out to a documentation specialist in the future, for things like grammar and word usage, and what I’ve seen on the developer forums suggests that trying to customize the base localization via XLIFF doesn’t work.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden