My app is Base language English.
I have added German, and Xcode generated automatically a folder structure that doesn't correspond to what the documentation says. (cf screenshots from Xcode and Finder).
When I run genstrings, it only generates stuff for the english strings (the german remains empty).
I manually copy then the English strings into the German strings, but Export ignores the German strings in the cliff file
What am I missing?
Two things:
First, the de.lproj folder should be at the same level as the en.lproj folder, not a subdirectory of it. Second, you can choose when exporting to XLIFF if you want to export existing translations or the development language only. You may not be seeing that option since the folder layout is currently incorrect.
Related
I am a little confused about the implementation of localization in Xcode. I know that I can provide as many languages as I want by creating the appropriate XY.Iproj folders and inserting the .strings and Localizable.strings files into them. This all happens automatically with Xcode.
Unfortunately I have problems understanding the Base concept. As I understood it so far, the development language is to be used there. In my case this is English, so should I write in the storyboard and XIB files as text directly in English? For example the headline (a label) of the settings page with the content "Settings"?
But why do I have also the .strings file with the translation into English? That would be redundant, because I have already entered English text directly in the Base file and the .strings file contains the same text again.
Or should the storyboard and XIB files only have identifiers like "settings_page_headline" as content for labels? But that's nonsense, because these labels are good for nothing...
Or can I completely delete the .strings for the English translation if I have already inserted the English content in the storyboard and XIB files?
I hope you can enlighten me a bit. Of course I have read the documentation of Apple, there my problem of understanding is not discussed as much as I need to understand it.
Main.storyboard (Base) and Main.strings (English) contain the same content:
Content of the Main.storyboard (Base):
Content of the Main.strings (English):
"tos-eB-aJc.title" = "Send Feedback";
"S56-oM-eis.title" = "Rate this App";
From Apple documentation:
Xcode creates a Base.lproj folder in your project folder and adds to it the resource files you select. Xcode creates a language folder for the development language but only adds resources that need translation to the folder. For example, if you select English as the development language, Xcode inserts the resource file in the Base.lproj project folder but not the en.lproj folder because the resource is already in English.
link: InternationalizingYourUserInterface
As I understand it, this was done to optimize the import of localization files. Also you can not localize some .xib . If you want to understand how, by what logic and in what order the localization files are loading, read this document from Apple: LocalizingYourApp
Situation:
We use XCode exporting/importing tools to generate localizable files for our translators. This was going fine in XCode 8. Since we updated to XCode 9 we see a couple of problems.
Problems:
When exporting a localization via Editor-->Export for localization...-->Development language only, it doesn't include NSLocalizedString() key/values as it should according to this documentation: When you export localizations, Xcode searches your code for the macros and includes the strings files in the exported localization file for translation.
Comments that are added to the Localizable.strings development-language file seem to be non-existent in the export .xliff file.
When importing a translated .xliff file, XCode seems to delete all the comments that are in the file. It gets replaced by "(No Comment)"
Configuration:
XCode 9.0 (9A235)
Dev language: NL
Localized languages: Base, NL, DE, BE, LU
Objective-C & Swift hybrid project
What I've tried:
I have tried looking at XCode 9 documentation or changelog to see what has changed in Localization, though nothing I can find mentions this change
I can get my NSLocalizedString() strings to show up in the export when I first generate the development Localizable.strings file manually, by using the commandline command find ./ -name "*.m" -print0 | xargs -0 xcrun extractLocStrings -o . (I run it a second time for .swift files as my project is a swift/objc hybrid). Then combine the results, which let my strings show up in the export, however without comments, which are needed as guides for translators.
Question:
Is this an XCode 9 bug? Did I miss any documentation or new feature/option for localization exports/imports? Are there workarounds?
This is an older question, but I had this same issue with Xcode 10.
The solution is to simply place the strings files (e.g. InfoPlist.strings) in the same folder as plist.info. Only then are existing translations included in localization exports.
Previously I had them in a dedicated "Localizations" group. While this works for the localization itself (i.e. when running the app), localization exports seem to only include translations from existing strings files that are "near" plist.info.
What fixed both importing and exporting for me was turning off Base Internationalization by unchecking Use Base Internationalization under Project > Info > Localizations. I set all my translations in code, so I don't need it enabled for my .storyboard and .xib files.
Previously, when it was enabled, the "Localizable.strings (Base)" file didn't have anything in it, but Xcode 8 still seemed to work properly by using what was in my "Localizable (English)" file when exporting. For Xcode 9, if I had the source text in Localizable (Base) then exporting worked fine, but I still had problems with importing.
I am using Xcode 9.4.1.
I finally found the reason of the issue.
The issue exists because Xcode never saved files in the encoding it promised.
There are two places to set text encoding, one is "Default text encoding", which including a "convert existing files on save" checkbox.
There is also a file specified "Text Encoding" on each file when you open it. If you don't specify the text encoding on the file, the "Default text encoding" is used.
However, Xcode never saved the file as it promised. For example, if you choose a file specified text encoding, say to "UTF-16", an alert window shows with "Cancel", "Reinterpret", "Convert".
As the alert said, if you chose convert, Xcode would convert the file to the encoding. However, it didn't.
So when you exporting the translations, the file is opened with the encoding it never converted to and ignored.
You can verify that by these steps.
choose a source file.
change it to another text encoding.
in the alert window, choose convert
in Xcode, right click the file and choose Show in Finder.
quit Xcode.
open the file with another text editor that can deal with text encoding, mine is BBEdit.
in BBEdit, choose file -> save as
Now you can see, that the file is not saved in the encoding as it promised.
Solution
The solution is easy. For files that you specified the text encoding, keep it saved in the encoding that it specified. You can do that with other editors, like BBEdit, by save as and choose the right encoding.
For those files that are not specified text encoding. Be sure them are saved as "Default text encoding". If not, change the "Default text encoding" so you won't need to change each file.
While testing localization for my app I discovered that Xcode changes the traditional Chinese .lproj folder name from zh-Hant.lproj to zh-hant.lproj (notice lower case 'h') in the app bundle. Since the correct form for traditional Chinese is zh-Hant.lproj, localization won't work when the user changes their device's language to traditional Chinese therefore I have to manually load localizations when this language is set.
quick summary
folder name as seen in project:zh-Hant.lproj
folder name as seen in bundle/.app file after building:zh-hant.lproj
Why do you suppose Xcode is changing the name of this folder and of course, the most obvious question: how can I resolve it?
Thanks!
Thanks for the suggestions! I'm writing a framework which has its own localizations and turns out the app which was integrating my framework had its own localizations too, where traditional Chinese was set to zh-hant therefore even thought Xcode placed the framework's .strings file and app's .strings file in the same folder (framework's is called FrameworkLocalizable.strings while app uses default Localizable.strings), I guess Xcode has to decide which .lproj folder name to use when creating the folder for the bundle and the app's name wins.
It should be ZH_Hant or ZH_Hans - underscore.
How to add an existed folder with localization files.
I have an existed project with english as base, then have en.lproj.
And I have other localization files in file system names with ja.lproj.
However, If i directly import folder ja.lproj to xcode, seems not work, in project tab, it shows 0 files localized, and while start app, it will crash.
I know it may work, I choose one english version file, add plus in file inspector, then will add another lang version, however, it's not convenient, and new file will locate in en.lproj sub-folder, it's strange.
anybody can help me ?
Thanks a lot!
I don't think you would be able to do that with folders. Although you can do that with files. Just define different versions of the same file for different languages. Like this:
Good evening
I want to add a new year, a new volume as plist-file to my existing app. The app is localized for 4 languages, so the new file has to be localized also. The languages were "English", "German", "French" and "Italian".
But when I do this, Xcode creates a directory "de.lproj" next to the existing "German.lproj", same behaviour for French and Italian, but not English. The older localized files are now in a directory "German.lproj", the newly generated plist in a folder called "de.lproj".
Then the app will no longer recognize the localized strings, exept the english version.
How can I add a new localized file to this project without breaking the rest?
Regards
You should use Localization Suite to manage your translations. This way, you can let loc-suite to scan changes in your original .plist file and tell you which ones are translated and which ones are not. Loc-suite can also update your localized .plist file and remove dead entries.
This question is slightly off topic at stackoverflow though.
Finally I solved the problem like this:
Make a backup of each localized file (plist and strings files) in the Finder and collect them in a folder for each language.
In Xcode, remove every localization for these files so that the only remaining language is English.
In Finder, delete the old lproj directories in the project folder except English.lproj.
In Xcode, add the formerly deleted localizations for each file. Copy the contents of the files into the newly generated localized files.
Maybe this can help somebody.