15 Apr 2009
ibtool: Localization Made Easier
When I wrote the first post on localization, I hadn't discovered the full power of ibtool or the need for all that power. I figured out how to re-generate the localized XIBs from an English version and a .strings file. But soon, I needed to incrementally incorporate changes from the English XIBs, without blowing away the previous localized XIBs. The most common reason is element sizing. Text translated from English to languages like Spanish dramatically increases in length, but the UI elements in the English version are fit to the English text. Luckily, ibtool solves this problem as well.
Apple's documentation has a great explanation for solving this problem, summed up in the code below.
The ruby script from the earlier post is a little more complicated because I need multiple versions of the English XIB. The new process involves a bit of manual work, unless I incorporate SVN into it. However, it's worth it. ibtool lets me push incremental updates into localized XIBs without losing past changes to them.
I considered implementing a more dynamic interface, where a custom NSView subclass governed how the elements were laid out in any given view. Sofa, the talented group behind Checkout, Versions, and Disco, went that direction according to an Apple interview: "We generate all of Checkout's localization resources at build-time and dynamically resize views to fit oversized strings." That approach was tempting, but I wasn't sure how to deal with the many variants of views I had.
One issue I encountered before I found genstrings was not having translations for all the strings I called in NSLocalizedString. Apple has a nice argument to add to an application to point these out: NSShowNonLocalizedStrings. So, to look for non-localized strings in TextEdit, I would type: /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowNonLocalizedStrings YES
Apple has more information about this trick.