Maybe this is a hot question, but I had a strange issue (or more probably it's me :) ). I'm trying to use the new localization workflo in XCode 4.5. The procedure I'm using is the following:
Create a project
Localize MainStoryboard with the base language.
Add new language.
So now I have three folders, for example:
base.lproj
en.lproj
it.lprj
I have MainStoryboard.strings in en.lproj and it.lproj.
This is cool...
I noticed that .strings files are not auto filled while I'm modifying the layout (add, remove buttons, labels etc.).
I noticed that the .strings files are filled just when I localize the storyboard. To add new changes I need to remove localization and re-localize.
Doing so I loose my previous changes, i.e. I need to translate all the strings again.
What is wrong in my procedure?
I alos tried using a .sh in the Build Phases section, that auto-update .strings files, but the problem is the same, each time the files are update I loose my translations... (this sounds logic).
Thanks
The trick is to convert your localized strings file to a localized storyboard file in the Localization area of the File Inspector.
.
After that you can convert back to a strings file and you won't lose your translations.
You can do this two ways. It sounds like you have created localized versions of your storyboard, which is fine, but you will have to un-check the localization box for Italian if you make changes to the Default (English) storyboard. Then re-check the Italian box to make the Italian storyboard pick up any changes that you made to the English storyboard.
or...
You can just use Localizable.strings files with a single storyboard, and programmatically handle all of the text using the NSLocalizedString(#"KEY",#"comment") method. After you create your initial Localizable.strings file, just localize it and add your Italian translations to the file in it.lproj.
Hopefully this makes sense. There are really two different localizations happening here. The first is allowing the system to choose the appropriate storyboard..that is typically used when you have translated text in the storyboard. The second is using the appropriate Localizable.strings file for the text values in you app.
Check out our app which can create 40+ Localization.strings files for you (including the translations). https://itunes.apple.com/app/generate-localizable-strings/id572287184?mt=12
Related
In our project we generate multiple swift files when using the file xctemplate configuration. However, with this configuration, there is no icon displayed in Xcode when generating the files (see attached image). We did try to add two images to the template folder: TemplateIcon-png and TemplateIcon#96.png which yielded no success. Is it possible to use a custom icon for file templates in Xcode?
Not sure if you're still looking for an answer to this, but you should be able to create an .icns icon package named TemplateIcon.icns. This should contain your template image(s) to be displayed in the new project picker.
I suspect your issue was trying to use the PNG assets directly.
See the Base Acceptance Testing Bundle for an example. It is part of the OCSlimProjectXcodeTemplates repository.
This is ideally what I'd like to do:
Set up a project in Xcode using a base localization of English. Ultimately I want English and let's say Dutch versions of my Localizable.strings and Storyboards
Externalise strings in code with NSLocalizedString, using keys of the form fooViewController.barLabel, being diligent and adding proper context comments with every key
Add a Dutch localization to my Storyboard files
Mark particular labels in the Storyboard as placeholders that will be set at runtime and do not require translations
Add comments for labels in the Storyboard which do require translation
Export the "development language" xliff file (Click on Project, Editor/Export For Localization..., choose "Development Language Only")
Open the English xliff file in a tool like Counterparts or Xliffie or even something web based
Add actual English translations alongside the fooViewController.barLabel keys, and re-save the en.xliff
Create an nl.xliff file from the original en.xliff and add Dutch translations
Import both xliff files into Xcode and have it create the appropriate .strings files for both Dutch and English, for both the keys defined in code and those in the Storyboard; commit the new .strings files into my source repository
At some future point after keys have been added, removed and changed in my source and Storyboards, export the "Development language" en.xliff again as the source of truth
Update the en.xliff and nl.xliff files with current translations, having a tool highlight which keys had been added or removed
Import those xliff files back into Xcode which updates the .strings files I can then check back in to my source repository
Does this make sense? Is this a reasonable thing to want to do? I think so, but it doesn't work.
Here are the problems I ran into:
Xcode does not support step 4—the xliff format can mark a key as translate=no, but there is no way to annotate that in Xcode (ideally, Xcode wouldn't export keys marked as placeholders at all.)
Xcode does not support step 5—there is no way to set a translator comment for a label. There's not even a way to set the key independent of the placeholder text you put in the label on the Storyboard, which is a massive pain if you find filling labels with Lorem Ipsum useful when laying out your views.
When you get to step 10, Xcode complains there is no target language specified in the en.xliff file. There is a way to change the target language (or, at least, create a new file with the target language set to EN) in Counterparts but I couldn't find any way to do this with Xliffie.
Upon attempting to re-export the en.xliff file with updated keys, Xcode told me "Localization failed reading "[...]/Supporting Files/en.lproj/Localizable.strings, Please address the issue at file location 782" at which character location I found... an apostrophe. Xcode can't export an xliff file if the source .strings file contains an apostrophe. What in the actual F...?!
Step 12 and 13 got weird, and I just don't understand what was happening. Both Counterparts and Xliffie had replaced my original fooViewController.barLabel keys with the English translations and looked like they were trying to tell me I had no English translations. Upon attempting to import the en.xliff back into Xcode it told me I had no translations for all but the new keys and when I went ahead, it wiped the existing translations from the en.lproj/Localization.strings file.
This is a mess.
Translating labels in Storyboards without being able to manually set their keys, add translator comments or mark particular labels as placeholders not-for-translation just doesn't work. We've resorted to connecting every label to an #IBOutlet and setting its translation in viewDidLoad() with NSLocalizedString.
Xcode choking when it attempts to export a .strings file containing an apostrophe beggars belief.
It also seems there's an underlying assumption that if the "development language" in Xcode is English, then the developers are in charge of the English translation. I can imagine no context outside that of a single-person indie developer shop where this is true.
Finally, it also seems I'm missing something about how the tools I've attempted to use structure their workflows. If anyone could enlighten me I'd be quite grateful.
Has anyone managed to construct a workable localization workflow where the developers aren't charged with ultimate editing control over the "development language" and the .strings files checked into the repository are the source of truth?
We've resorted to connecting every label to an #IBOutlet and setting its translation in viewDidLoad() with NSLocalizedString.
You are doing that right. Seriously. Wrap your development process around it and you'll get way better off than trying to adopt the mess that the Storyboard localization evolved into.
It solves pt.4 - you decide what you put in the Localizable.strings
It solves pt.5 - comments are there by default, for everything that you decide to be localizable. Now to be honest, XCode7 has added a possibility to add notes to resources. Don't use it. For some reason only known to Apple, it is not available for all types of resources. You can't annotate e.g. table headers and footers. More on that later.
I recommend making your own NSBundle.localizedStringForKey wrapper (macro) which provides the value. NSLocalizedString sets value to empty string, essentially forcing key to be used as the fallback translation content. Of all the already existing questionable macros, NSLocalizedStringWithDefaultValue takes the value but also all other 4 required parameters - not something you would like to use often.
Step 10 is caused by you trying to import a Base localization - the fact that it's english does not make any difference. If you want to "translate english" (i.e. professional correcture), you must add english as another standalone localization on top of Base. Technically it boils down to the Base xliff missing <file target-language> and <target xml:lang> properties. Due to some strange xliff mess similar to yours, i had to add those once manually. You don't want to do that :)
Re apostrophe glitch: iOS localization is an unreal garden of wonders, but i'm prety sure it's not THAT unreal :) Try opening the file in some hexcode displaying editor - what XCode renders may be quite different from what the file really contains.
... even something web based
That's Crowdin for us and it nicely shows everything wrong with Apple's idea of Storyboard localization. Translators need 3 things to do their work professionally: context, context and context. Apple seems to think that translators will gladly install the app, play with it and ask questions to get the context. Because, by default, there is no human context in xliff export. Now with Xcode7, you can add notes, but weirdly not everywhere. Even where you can, your note is appended at the end of already long <note> string with machine context - understandably needed for storyboard import matching, but useless and obstructive for the translator. Furthermore, in reality, the translator is a pro agency, or a language enthusiast. Even if you had a luck with properly equipped enthusiast, or you paid the agency premium for getting an extra customer care, you enter The Hostile Desert Of Beta Distribution Options. Apple's funny Testflight reincarnation will either need the translator to register as an Apple developer, or waiting for Apple's beta review - depending on how early in the app life you need the translation.
BTW i like your blog. Sometimes i feel like dumping my sourness and misfeature fatigue too, but never got as far as you :)
I'm using base internationalization to internationalize my app. Once I used it, my storyboards became red in "copy bundle resources" (they were normal before I used base internationalization):
I have tried Xcode Copy Bundle Resources can't find files, Base internationalization and multiple storyboard not working right and Base Internationalization and “Could not find a storyboard named […]”. unfortunately, none of them worked for me.
how can I make it normal?
edit
this problem still exists in xcode5
Make sure you have all the "Localizable strings" checkboxes ticked in the file inspector when the MainStoryboard file is selected.
I had a problem that looks similar. I transitioned my project's main storyboard to use base internationalization. When selecting the MainStoryboard file, in the file inspector, I saw a new entry called Base, which was using the English localization. So, thinking that "Base" already accounted for the english part I unchecked the English "Localizable Strings" entry in the file inspector. Apparently that was the origin of my problems. After that, the MainStoryboard file would show up in red in the "Copy bundle resources" list. Checking again the English localizable strings entry fixed the problem.
Unchecking "Localizable Strings" may need also first copy your storyboard elsewhere, then do the uncheck and then import your storyboards again in your xcode project.
I have a simple Mac app that I want to internationalize. I know how to use NSLocalizedString etc., and this seems very convenient and well thought out.
However, I also need to internationalize a .xib file in my project. I found this post about the process.
I tried it out, and it works, but strikes me as an extremely bad idea. Is there really no better way? What following the post produces is a bunch of copies of the .xib file, one for each language:
This works fine, until you decide to change an element in the interface, because then you have to go to each language, and change the element in every single one.
Is there a better way to internationalize the xib files?
You might want to use "base internationalization". It allows you to internationalize the strings without messing with the nib files.
However, it requires iOS 6, and it works best when used with Autolayout.
There is a section about base internationalizationin the handy Internationalize Your App Guide.
If you need to support iOS 5 you have to use your way. Or, as I prefer it, connect all UIViews to a IBOutlet and replace all texts in viewDidLoad.
Stanford put out for free a series of videos and handouts for their iPhone programming course. I've played around with the first assignment, but all I get on the Simulator is a blank screen. Here's the recipe I followed; what am I missing?
In Xcode, create a new Window-Based iPhone application.
Open the project’s MainWindow.xib file with Interface Builder.
Add the following user interface elements to the view:
a text label
an image view
Set the following properties on the text label:
text value should be “Hello Stanford!” (or something suitably amusing)
text alignment should be centered
adjust the size to make the text large
Back in Xcode, add an image (.png or .jpg) to your project. You can use the Project > Add to Project... menu to select an image. Note: Be sure to check the “Copy items into desti- nation group’s folder (if needed)” checkbox.
Once your image is in the project, return to MainWindow.xib, select the image view and set the image for the image view that you dragged in previously using the Attributes Inspector.
Configure the image view’s “Mode” to be “Aspect Fit”
In Xcode, build and run your project in the simulator.
Been there, done that, but no t-shirt. Seems to me I'm missing connecting lines in the Interface Builder, but I see nothing in the recipe about that.
Since you didn't provide a link, I'll assume you're talking about this document.
Works for me on XCode 3.2.3/Snow Leopard 10.6.4. I created the project as iPhone-only, as opposed to Universal, but it shouldn't make a difference for your purposes.
Try again from scratch, or take a look at my project here.