What are pros and cons of using Xcode base internationalization?
Maybe it's easier to use just NSLocalizedString and set titles, labels, buttons in code?
Base internalization is a much better idea than manually setting things in code. It is much less work both to implement originally and to maintain. You just add the .strings file for a language and then edit it to translate all the strings in your UI. With NSLocalizedString you have to do this as well, but in addition you need to write special code for every UI element with a string. If you add or remove a UI element, you need to write code again. Using NSLocalizedString is probably also less efficient at run time. Your app has to completely load the UI for your development language and then go through and change all the strings in the UI to the localized versions.
There really are not any cons to using base internalization except for legacy considerations:
It requires iOS 6 or Mac OS X 10.8 or newer.
Converting a legacy project with separate .xib or storyboard files for every language can be a pain since you need to convert to auto layout. (The string extraction can be done automatically by Xcode.)
Related
I'm new to programming and I've not understood if I can use RoR in X code or if I can only program throw Swift.
It´s perfectly possible to program Ruby in XCode of course,
You can use the built in git support, .rb files will be automatically recognised for being ruby, you will have syntax highlighting and auto completion (just tested it). You can make use of the project features too, managing multiple source files etc.
Just in case: Source type can be adjusted e.g. in the right sidebar 2nd dropdown named "Type".
I use xcode for c++, python and embedded development. It´s very customisable.
We have a legacy application for iOS translated to two languages. After checking the localization files we realized, that there are a lot of strings that are not really used in the application, though, we cannot be sure which ones.
Is there some way (maybe some utility) that can check objective-c project and localization files and check which strings re really in use and which are not so we can delete the from the localization files?
Thanks
You could use genstrings to generate a new strings file from your project and then use one of the string-files comparison/merge tools to find the differences.
I have a c library of astronomical code that I'd like to make use of in several formats - a command line that reads and writes files, an iOS app with graphical output, etc.
Ideally I'd like to be able to leave the code in a format that would allow the most basic version (the CLI's) to be cross-compiled on other platforms, while remaining editable within Xcode for the iOS versions - if such a thing is possible.
Does anyone have a good guide on how to arrange projects in Xcode in order to make them easier to move between different targets like this, while avoiding platform lock-in as much as possible?
I was wondering if somebody could explain in the details how I can localize an iOS app using only 1 storyboard. I know how to localize by creating several storyboards(one storyboard for each used language), however I'd like to find out another solution.
Thanks.
The tutorial on raywenderlich.com uses two forms of localization together. The reason is he also checks the storyboard when turning on localisation in image 3:
.
So then what?
NSLocalizedString is very useful, any text set programatically can (and should) be localised using this method. Ray's tutorial is still very useful.
However, it's not very desirable to create a clone of the storyboard(s) to do translation, it's just not very maintainable in the long run.
And what about storyboards?
The magic happens using the Base Localization feature. Base localization uses the generated objectId's to 'map' different languages to the storyboard.
Do note that this feature is only available using SDK 6.0 and above. Running the app on a lower iOS version will not cause any errors, it'll simply won't work.
Go to your project, and select Base Localization, then add any other language.
Open your storyboard file and check the new language as well. Note the icon is not a storyboard icon, but a simple text file icon. That's a good thing; it won't copy the whole storyboard this time :).
Note how there is now another file 'under' the storyboard. Xcode automatically generates a file for every language you select.
You can se Localization feature for this. You need to add the Localizable.strings file for each supported language and use it for locaization.
You need to use : NSLocalizedString() for fetcing data corresponding to each key.
Check this tutorial for details.
I know how to turn on storyboard's localization. The problem is I don't know how to sync all localizaion storyboards, after main (English) storyboard is modified.
Is there any shortcut to sync them? Do I have to do all those modifies again and again in over TEN language storyboards?
My condition is: I have a project with over ten localizations. After I released it on AppStore, we have new user requirements.Then, we start program next version app. After I completed tons of improving and creating on stroyboard, I feel desperate to facing other language storyboards.
If you are using iOS version >= 6 (and Xcode >=4.5), you can use a single storyboard for multiple languages, i.e., do base localization + the usual string localization. Doing so, you have only to care about the localized strings in string files.
For a guide, see e.g. here.
If you're targeting iOS 6.0, you can use Base.lproj like Matthias mentioned.
If you're targeting a release prior to 6.0, you can use ibtool's localization merging features. They works for NIBs, XIBs and Storyboards. You can invoke them like this:
ibtool path-to/development.storyboard --local-
ize-incremental --previous-file path-to/development-storyboard-localization-was-based-on.storyboard --incremental-file path-to/previous-localized-storyboard.storyboard--write path-to/updated-localized-storyboard.storyboard
What that does is open development.storyboard, copies it, and the compares all localizable properties between path-to/development.storyboard and path-to/development-storyboard-localization-was-based-on.storyboard, if those properties are the same, the counterpart value from path-to/previous-localized-storyboard.storyboard is copied forward to path-to/updated-localized-storyboard.storyboard, otherwise the current development value is left in place.