So I have a project that has been already localized in the past. But we created some new keys and we want to get them translated seperately.
Also in some languages some keys are missing, so I wanted to find those too. So what I did was to export the xliff files for translation using Xcode's export tool. I've using NSLocalizedString everywhere in my project, so theoretically that should have me covered.
But when I open an exported xliff file (let's say for Italian) I have the following problems:
The section in the xliff file for the localizable file is listed twice. The first time it's like this:
Translations for projectName/Localizable.strings
In this part of the xliff file ALL the translations are missing, even though the localizable file contains translated values for most of the keys.
Then the same localizable file is listed twice as:
Translations for projectName/en.lproj/Localizable.strings
In this case the keys all have their translated values, but if a key is missing from the English localizable file then it's also missing from here.
This is making it a huge pain for me because I'm just looking for the keys that are missing translations, and yet this way it means I have to go through the English list again to make sure no keys are missing.
This doesn't seem normal or practical to me. Anyone have any idea what I might be doing wrong?
The translated keys all work fine on the app itself by the way, tried it both on devices and the simulator.
Thank you for your help.
I do not use xliff exported files to manage my translations so I cannot give you an answer using this.
However, you may be able to solve your problem of finding missing localizations using Localization.strings files.
What you can do is use the genstrings command to generate a Localizable.strings file which will contain all the NSLocalizedString from your code.
To do this, you must pass all for your source files to genstrings.
For example, if you have a swift only project, you can just run this command at the root of your project:
find . -name "*.swift" | xargs genstrings
This will generate a Localizable.strings file you can then compare to your existing Localizable.strings file with a file compare tool like FileMerge. To make this effective, you may need to sort the keys in all the Localizable.strings files, I know a lot of editors can do this (SublimeText is one).
As you can see, the above solution is manual and will prove error prone if you need to do this more than once. In the past, I've automated this using a python script which did the following given the generated Localizable.strings and a localized strings file:
parse the Localizable.strings to get all the reference keys
parse a given localized strings file to get the localized keys
output the unused keys and the ones not translated
Hope this helps!
Related
I have an intent definition file for a Siri shortcut. When I click on localize Xcode does very well create a localization file, each string beeing used is present with an ID.
But how do I refresh this if I added a new intent in the same file or just added a new possible response to the same file?
I currently only found two ways:
Delete localization and set up new again (which makes you loose all translated strings in all languages besides default).
Export all translations for the whole app and reimport (which leads to problems if your complete app is not yet ready for new localization export/import).
So, does anybody know a way to refresh the auto-localization of an intents definition file?
I ran into the same problem lately, and I managed to fix it with a simple workaround and two small, quick and dirty scripts:
Be sure to have your old localizations .strings files in your git repository
Uncheck all your .intendefinition localizations (and delete them)
Check back all your localizations, it will recreate the .strings files, but without your old translations (hopefully, they are safe in git)
DO NOT COMMIT THEM (yet)
For each .strings file run my little script this way: {script-path}/update-modified-strings-file.sh {project-path}/xx.lproj/YourIntents.strings
Check if everything is ok
Commit
Live long and prosper...
Please be sure to put both scripts in the same directory:
Shell script to call: https://gist.github.com/letatas/221ea3d04e70996d026362de57c1b084
Swift script called by the first: https://gist.github.com/letatas/9a58ad4f0a979b19579334bd80516f4a
The first script checks out the old version of the strings with your existing translations, the second merges the new file containing new entries with the old existing translations.
Hope this helps.
I wish Apple would fix with this.
In the meantime, the easiest way of dealing with it that I've found is this...
Add support for a new language in your project. For example, add Australian English. Then you'll get a new .strings file with all the new keys in it with the values from your intents definition.
Paste the contents of that into your existing English version and delete support for that new language.
If you want to get the new keys merged into your existing localised .strings files then you can use this https://github.com/Flinesoft/BartyCrouch Once it's installed you can run bartycrouch update and it'll sync the changes into all your .strings files.
I have the same question, i played around with this exact thing tonight. From what i can see, i have to remove all localized files and recreate them, just like you said...
I'm having an issue when importing translated strings from XLIFF back to Xcode (Editor > Import Localizations ...)
Xcode is giving me the following error message with no detailed description so It's difficult figuring out what is wrong.
I'm using Lokalise.co to translate texts and then export them to XLIFF (the texts were imported from XLIFF too).
It's possible that some keys were removed in localise so the XLIFF has fewer keys than the file exported from Xcode. However, I have no idea what keys it might be.
Any ideas how to proceed on this problem?
I had the same error message when importing a XLIFF into XCode.
You need to ensure in the file tag , the original attribute is not empty. It needs to point to the path of the string file.
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.
I am trying to use localisation inside my App. I followed Apple's documentation and various blog posts.
I created the Localizable.strings file where I put my English and German translated strings, and replacing all of the hard coded string occurrences with NSLocalizedString(#"key", nil) but after running the application in the Simulator only the key value is shown.
I also checked if it's copied to the bundle but everything seems to be fine.
My intention is to add localization to only one submodule inside my workspace which consists of multiple submodules.
Any help would be appreciated.
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.