Objective-C + Cocoa: Internationalization with Nibs. Is that really a good idea?

Question

In the Apple Docs they say that a Nib enables internationalization by just translating the Nib into many languages. I am thinking now about a worse but realistic scenario: You have made a huge user interface. Then you translate this into 25 languages. So you get 25 different Nibs. You also get a huge redundancy in styling and defining the UI: 25 times the same stuff. Same Bindings, same everything. Just text is different.

So, I really think this is a very bad approach. Instead, I would prefer to just link in all texts from a resource bundle or something like that. Just a file with text strings, which is linked in at run time from the appropriate language resource. Then you only have "trouble" linking in the text which really doesnt make any fun. But then, you can do changes on your UI ONCE without having to do the same step 25 times over and over again. A new Binding in every nib. That would be so horrible!!

Now, please tell me I got that wrong. Apple does not assume that we do something so creazy?

Answer 1

Sometimes, localization involve more than just replacing text, but changes in layout too. For example, strings in one locale/language may be significantly longer than in another, forcing a change in layout. Right-to-left language often will mean some changes in layout too.

Answer 2

The localization situation is not ideal. Although Cocoa UI elements support some dynamic flexibility in their sizing (the ausosizing flags), it's very difficult to arrange them in a view so that they will accommodate any sized text.

As Heng-Cheong points out, this usually means that some adjustment to layout is required on a per-localization basis. Apple supports a process called incremental localization with a tool called "ibtool", bundled with your developer tools. The process is far from intuitive and seems to have some subtle bugs, but it helps to make the process easier than, say, separately maintaining 25 different nibs manually. The process essentially involves mapping changes you make to your primary nib onto the other localized nibs. Apple describes the process in more detail:

http://snipr.com/ctfnx

In order to avoid this painful process, some people take a different approach. If you compromise on the layout of your views, you can achieve a situation where every UI element accommodates the largest localized string. Using the alignment features of text fields, etc., you can thus arrange an acceptable layout, though the extra spacing required for the localization with the largest strings often causes a less-than-ideal layout for the language whose strings are shortest. If you take this approach, you need to design your nibs so that a controller class populates the nib's UI elements with the correct localized strings at runtime.

Finally, some developers go so far as to apply their own relayout to the elements in a nib, optimizing them for the sizes of the strings that have been set upon them. This would be a refinement of the strategy above, where a single nib is used and manipulated at runtime to achieve the desired effect.

Answer 3

Building on the previous two answers, there's a tool called iLocalize that aims to make the process easier than ibtool does (and it's older than ibtool). I've never used it myself, but my friend Evan uses it on both Adium and Growl and loves it.