I exported the localization xliff file with no errors. I localized the file, imported back to Xcode and ran the app. Everything was good.
I exported the localization xliff file again for a second-round localization. I found many keys duplicated and they are not translated, of course. Why did this happen? Is it a bug in Xcode? How to work around it?
Side Note that might be helpful: I have test targets.
I noticed this issue the other day, I think it's due to translation not being able to differentiate between the localisations, often using localisation you can be lazy by typing something like:
NSLocalizedString(#"Blue", nil);
Using nil is valid but provides no information as to the context of the translation, if the string is more verbose and that string will only be used once then nil should be fine. In the above example though the context could have multiple meanings (colour, feelings, etc) so when writing localised code ensure that if it is used multiple times add a comment for the code and as long as its the same as another localised bit of text the translated strings should merge
Example
Creates 2 localised items
NSLocalizedString(#"Blue", #"Colour");
NSLocalizedString(#"Blue", #"Feeling");
Creates 2 localised items
NSLocalizedString(#"Blue", nil);
NSLocalizedString(#"Blue", nil);
Creates 1 localised item
NSLocalizedString(#"Blue", #"Colour");
NSLocalizedString(#"Blue", #"Colour");
As I expected, the Export XLIFF file includes localisation strings in test targets too. I am using Xcode 6.2 now and still there is no way to exclude test targets from this process.
I had to open the file using a text editor (for example, TextEdit) and remove all the localisation nodes for test targets.
Related
TLDR: Xcode generated storyboards for each language, however I want the "old"(?) *.strings files. How?
I am currently in the process of localising my storyboards. After I enabled everything, Xcode generated another storyboard alongside the original (english) one for me to localise. I was surprised, I expected a Localizable.strings file, like the apple documentation still states as of April 3, 2021:
For storyboard and XIB interfaces, select the user interface files (files with a .storyboard or .xib filename extension). Xcode adds a strings file to the localization folder that contains the text to translate, as well as comments that describe the user interface components. For example, if you add German to an iOS app that uses storyboards, LaunchScreen.storyboard becomes a group containing a LaunchScreen.storyboard (Base) and LaunchScreen.strings (German) file.
I searched around the internet, in apple developer forums, watched both WWDC18 and 19 talks about localisation in Xcode, but did not find a single mention of translated storyboards.
After the initial translation, which works great due to the simplicity of just filling everything in, it gets frustrating however, since every layout change needs to be repeated for every language. This can't be intended, there must be a better way, right? Sadly, I didn't find anything. Even a hint to a piece of documentation regarding these storyboard copies would be greatly appreciated. Thanks!
There are some screenshots of the possibility to convert these two formats via a dropdown, like the third picture in this post. However for me, there is no dropdown next to the language item when I click the storyboard, neither on the group, nor individual base or localised ones:
Is this a bug or am I missing something here? I am using macOS Big Sur 11.2.3 with Xcode 12.4 (12D4e).
Turns out, you need to use the Base Localization feature, the dropdown then appears and you can convert existing storyboards to *.strings files.
I can see that this is a recurring problem with all sorts of Xcode versions. I'm using the latest non-beta build (9.2 9C40b).
I have already localized in Spanish. Doing that involved successful exports and imports of xliff files, with same Xcode. So what changed?
I am now trying to localize to another language. This is a showstopper. Any hints? I have looked through all the posts about previous versions crashing, and have not found anything that works.
(And before you mention it, I am done and over with genstrings. If it exists anymore.)
I've discovered that large .xliff files (more than about 6,500 lines or 1,200 <trans-unit> elements) cause Xcode 10.1 to crash consistently near the end of an import operation.
The work-around is to manually split the .xliff file into two distinct .xliff files, each containing a subset of the <file> elements in the original file. You can then import the two resulting .xliff files into Xcode separately without crashing.
Do not translate "bundle name"
I wanted to translate to Greek Language and every time I was importing xliff files, Xcode was crashing.
I realized that the problem was, that I was also translating "bundle name".
If you did the same mistake, open xliff file, find:
<trans-unit id="CFBundleName">
<source>NameOfYourApp</source>
and delete the line
<target>...</target>
After that everything worked perfect for me!
Here's a workaround. Select your project icon in the Project Navigator. Select Info at top (as opposed to Build Settings). Under Localizations, click the + button and add your new language.
Xcode will create the new .strings files and fill them up with pre-existing translations. (If there are any.) Strangely, for me, some of the new .strings files were filled in with English, some with Spanish.
In any case, you have the new .strings files and can manually paste in the translations for the new language. If your app doesn't have too much user-facing text, this isn't onerous.
But really, with this problem going back to Xcode 4 (!) one would think it would be fixed by now.
it's a late answer I know, and I'm using Xcode Version 10.1 (10B61) already.
In my scenario, I added Chinese Hong Kong (zh-HK) language under Project > Info > Localization and exported successfully then sent to the agency for translations. After few days they sent to me Chinese translated text within. At that point, everything seems correct for me by eye. But I've tried 10 times to import file and it crashes 10 times without exception! Which makes me sick. I use to checked to see the difference between 2 document via Apple's File Merge App. I understand that agency geniuses added few missing <\target> tags. Hmmm, that means while exporting Xcode didn't add for some translations <\target> tag. Interesting...
I removed those unnecessarily translated tags and checked everything was equal in 2 documents except translations of the words to the Chinese language.
Tried to import again. Then BOOM! It works like a charm! I was surprised by this. It's so weird that Xcode never shows me a descriptive message about my mistake. Probably, It's just a parse error for Xcode.
Whatever, I hope this will work for someone else.
Best.
Using Xcode 7's localization export workflow, I can export to Xliff, which can be provided to translators, who will give back a translated version, which we import again.
However, how do I generate one for the original development language?
I want to do this so that I don't have to maintain my development language strings files manually by hand.
Here is the scenario:
I start with no strings file in my project, just Swift code which uses the NSLocalizedString
static let something = NSLocalizedString("something.hello", tableName: "MyStuff", value: "Hello world!", comment: "some comment")
From the project settings, I choose Editor -> Export for Localization. Because I have no existing strings files, when I export, there are no options. Just a "save as" prompt.
This will perform an Xliff export from the original source code. (Same as when you choose "Include: Development Language only" from the prompt when other localizations already present). The Xliff looks like this, with only <source> tags, and no <target> tags.
<trans-unit id="something.hello">
<source>"Hello world!</source>
<note>some comment</note>
</trans-unit>
The Xliff file is modified by translators, and translated to simplified chinese
The translated Xliff file is re-imported into project via Xcode
This creates the MyStuff.strings file for simplified chinese
Problem - when I run the app, the app will use the chinese strings file, even when language is english, because an english file doesn't exist. It doesn't seem to use the default value anymore. This means I need an english strings file too.
How can I generate an english (the development language) version of the strings files through the import/export process? Xcode doesn't let me "export" in the original development language. So I can't re-import it to create the strings files.
Note on genstrings
In the documentation for Separating User-Facing Text from Your Code, it says "Alternatively, you can generate the development language strings files from NSLocalizedString macros directly, as described in Creating Strings Files for User-Facing Text in Your Code." , which tells you to use genstrings
However that genstrings no longer works for Swift when you specify the tableName.
It's my understanding from what I've seen on SO that multiple radars have been filed, but it seems Apple is no longer supporting it.
I've worked out the problem.
It's doesn't seem necessary to generate strings files in the development language. This must be why the capability doesn't exist in Xcode.
My problem was that the app didn't think that my development language (english) was supported, so it did further fallback, and ended up picking a language that my app was localized for (in this case, chinese).
By adding a file localized for english, and ensuring there is an en.lproj folder in the bundle, it infers my app is localized for english, and will correctly use the default values specified in the NSLocalizedString calls.
This means I don't need a seperate copy of the english strings files. Which is great, because I won't need to keep that up to date as the app changes. The source of truth is the Swift source code only.
This link was helpful:
How does iOS determine the language for my app
I am learning from the iOS 9 AppCoda book on Swift (https://www.appcoda.com/swift/) and I am stuck in particular on the Localization section. So the author has gone through with changing some user-facing strings in code from just String to NSLocalizedString. That makes sense and the changes I made there were automatically updated appropriately with the XLIFF file. In the section about Localisation, the author mentions that you can also translate Storyboard user-facing Strings with the Export Localization feature of Xcode.
Because it's a book you work through, he provides an already translated XLIFF file into Chinese and German which includes the source code translated text and the Storyboard elements translated as well.
When I import the files into Xcode, I see three storyboards (Base and the Chinese/German.strings, etc) but when I run the app, none of the Storyboard elements are actually translated and only the elements from the source code.
When I click on the German Storyboard, I get the "no localized strings".
The app in his example works and the UI elements in storyboard are translated but they're not in my case. The entire app thus far has been followed with the exercises so there aren't really any differences. Or even if there are, the similarities themselves should be translated, but in the Storyboard elements, they're not.
Does anyone have any ideas on why the Storyboard elements wouldn't be updated with the Translated text in my case?
Any thoughts would be appreciated.
Here is my guess... Exporting localization strings from Storyboards works a little different from exporting those strings from code.
The localization file for strings from code gets the actual text from the NSLocalizedString macro and creates a mapping such as:
"Original string" = "Translated string".
So, you just have to use "Original string" in your code then Xcode knows it should translate it to "Translated string".
However, the storyboard localisation file uses the UI objects handles to set localized strings. For example:
/* Class = "UILabel"; text = "Ops..."; ObjectID = "fe4-zT-gjU"; */
"fe4-zT-gjU.text" = "Wait for it...";
In this example my storyboard has a UILabel, with the text "Ops...", and that label has an ObjectID equal to "fe4-zT-gjU".
The object IDs are kinda unique for each object in each project, so obviously the object IDs from the app coda tutorial will be unique for the project the author created; unless you have downloaded the author's original storyboard, your storyboard will have all different object IDs, so Xcode won't know how to associate the correct translations to the correct objects.
I don't think Xcode will import localisation for objects with objectIDs it doesn't recognise.
So what I think you should do is to perform an "Export for localisation" operation. This should update your storyboard .strings file. Then you copy each translation from the tutorial file into your .strings file using an xliff editor. Boring, I know. Welcome to the app development world. :-)
When you added your localization did you select the storyboard file?
If so, then check that your scheme is set to the correct language. This can be done under Product > Scheme > Edit Scheme
If that doesn't do it, then check that your simulator is set to the language you want to display. This can be done in the simulator's settings, same as an iPhone.
Hope this helps.
My app only supports english. I am using base internationalization (English- Development Language)
Steps I followed:
1. Separate out user-facing text using NSLocalizedString();
2. Using Genstrings command i have added Localizable.strings in base.lproj.
3. In Editor >> Export for Localization
4. Save en.xliff and provide to translator team for updating English content
5. While importing updated en.xliff file, i got below error.
Might be i doing in wrong way to export/import for English. Please suggest me the best approach for handling English content. (development language).
It is not obvious to me what you want to achieve: do you want to have your strings translated into some language other than English, or do you want to run your strings through an English linguistic review? For the first case the error message is pretty clear: check if the file element in your translated XLIFF file has a target-language attribute and add it if not. Details about this attribute can be found in the XLIFF spec here.
If adding this attribute is not enough you may also want to look at the answer to this previously asked question.
For the second case XLIFF is not really a good format.