Today I gave a little thought to the problem of translating apps. Having support for more languages than English provides you than a vastly larger market, and with the modern App Stores it’s easy to reach out to all those people out there. You just need to have the app translated. There is often a third party who is helping out by translating your app to a foreign language. This often boils down to providing the translator with text files containing various strings that you want to have translated. Hopefully the translator later sends back the files, with extra localization added. It’s crucial that this process is as smooth as possible. You may pay the translator by the hour, or it might just be a friend who’s wasting her free time to help you with your app. Either way, you don’t want the file to be corrupted because there’s missing semicolons or quotation marks and you also want to put the workload on the translator to a minimum. Multiple localizations for multiple platforms means lots of files with that each has it’s own format.
Enter twine! This is a command line tool that’s designed to simplify the process of managing localizations for apps. This is how it works: A master file containing all localizations is created from your existing strings files. This file is structured and uses a simple, easy-to-understand format that’s very forgiving with white space. The format looks like:
[[Login section]] [username_label] en = Username de = Benützername sv = Användarnamn comment = Label which describes the username textfield
You send this file to your translator, and they can add the translations. It doesn’t matter much if they mess up the formatting. When you get the file back you run a script which will convert it to the native string format used by iOS/Mac (.strings files), Android (.xml files) and jquery-localize (.json). Very neat! Here’s how you get started.
Install twine, which is a Ruby Gem, using:
$ gem install twine
First you might want to fetch all your existing strings and copy them into the master file, which we’ll call strings.txt
$ twine consume-all-string-files strings.txt folder/to/search/in --developer-language en --consume-all --consume-comments
Make sure that the strings.txt file exists first.
Go ahead and open the strings.txt file and make some small changes. From here we, in this example, choose to create strings for an iOS project. The process is very similar for other platforms.
Create the folders Resources/Localizations in the root of your project. Inside Localizations create .lproj-folders for the languages you want to support, for example en.lproj, sv.lproj, de.lproj.
Next, run the following command to generate new strings files:
$ twine generate-all-string-files strings.txt Resources/Locales/
If you check out the content you’ll see that there are newly created Localizable.strings file that contains your changes. These are the actual generated localization files that the project will use. From within Xcode, remove the old Localizable.strings file(s) and add the new ones.
Now, you may want to make sure that you always have up-to-date native strings. Do this by adding a new Run Script build phase for the target you’re using. Make sure that the shell script build phase is performed before the Copy Bundle Resources build phase. The shell script should be the same command as above to generate new strings.
Now you’ll always have the correct strings when building, and only ever have to care about the strings.txt, which contains all of your localizations.
As I said earlier, this works not only for iOS project so you can do the same for your Android or JQuery projects!