Tips for Localizers

For those who want to hear my vague and scattered musings on the topic of localization, here are some tips:

• One thing that's important is to find everything that needs translating. The high-level things are easy; you're not going to forget to translate a whole nib, or a strings file. But there are little corners where localizable strings can lurk. (And by the way, to get inside an app wrapper to the resources it contains, control-click on the app in the Finder and choose "Show Package Contents". You can also rename the app in the Get Info panel to not have the .app extension, which should turn it into a normal folder.)

  One easy thing to forget is the titles of windows, because that text is edited in Interface Builder's inspector instead of by typing directly into the window title bar. Select the window, by clicking in it but not in any view inside of it, or by clicking on its icon in the nib window. Then go to the Attributes pane of the inspector. The title is in a textfield at the top.

  Another easy one to miss is tooltips, because they're not visible in the window you're editing. You just have to remember they're there. To see the tooltip for a view, click on the view, and then go to the Help pane of the inspector. The tooltip is in the textfield at the top. (See below for tips on how to work with tooltips more easily)

  One last one to watch out for is stray objects in the nib that aren't visible in the primary window of the nib. Nibs can contain all sorts of extraneous objects, from secondary panels to context menus. Many of those objects may need to be localized. Bring the nib window to front and make sure you have localized all of the objects shown in it.

  The one thing you don't want to localize, even though it is located inside the English.lproj language directory, is Script Terminology files (any file with a .scriptTerminology extension). These are localized to English, which is correct since they do contain English text visible to the user. However, Apple does not currently support script localizations other than English, and there is no evidence they ever intend to, so localizing these files is a waste of your time.

• If you're using Interface Builder the way it ships in the 10.1 Developer Tools release, editing tooltips is a real pain. The problem is that the textfield where the tooltip is shown is only one line high. Typical tooltips often run to two or even more lines of text, when the explanation of a control is complex. But this problem can be fixed -- after all, IB's inspectors are themselves editable nibs! An article on how to use IB to modify itself in order to give you a larger tooltip field used to be at cocoadevcentral; I'm not sure where it went now, but its easy enough to figure out for yourself if you're accustomed to using IB.

  And by the way, if you're trying to figure out how to insert a newline into a tooltip to break it into multiple lines: option-return.

• The layout of a nib is a very touchy thing. Conscientious developers tweak their layouts to be precise down to the pixel, which is a very time-consuming enterprise. Repeating that work for each localized nib is the last thing a developer wants to do; this can add days or even weeks of work to a product's development. So an important thing to strive for as a localizer is to never touch the layout of the nib unnecessarily. Be careful that when you click on things, you don't move them accidentally. Don't deliberately rearrange elements of the nib in an attempt to improve the layout. You might experiment with the Interface Builder's feature that allows you to lock the frames for objects, if you find that it's difficult to avoid doing so.

  But what about the cases where you really have to resize something, because the localized text doesn't fit? The strategy here is minimal impact. Make the object in question big enough to fit the text you've entered into it. If that makes it collide with something else, move that something else only if there is a very clear, choice-free way to move it. If there's any question about whether what you're doing is something the developer will ultimately want, don't do it. Let things overlap. Let chaos reign, but keep everything exactly where it was to begin with, unless you're quite sure you're doing the only logical thing in moving it elsewhere. The developer will thank you for it later; making the changes necessary to fix a nib is much easier if one is starting from a known good layout that just requires adjustment for text length changes.

• When you do need to move objects in a nib, use the arrow keys. This lets you move things a precise number of pixels, and lets you avoid accidental movement in unintendeddirections (slipping a pixel or two vertically while moving something horizontally, for example). Just click on the object you want to move to select it. Now each arrow key pressed moves that object one pixel in the direction indicated. Use the shift key to move 10 pixels at a time instead of one.

  Similarly, when resizing objects, use the size inspector: it's a very powerful tool. It allows you to resize objects by precisely the number of pixels you want: just enter the new width or height in pixels. In fact, it's even easier than that: you can enter a simple equation, and IB will evaluate it for you. So to make an object that is 520 pixels be 20 pixels wider, just type "+20" after the value "520" that's already in the width field, and hit return. "540" is entered for you, and the object resizes.

• A good way to see all of the objects in a window, by the way, is to turn on Layout Rectangles. This gives you a red frame around every view in the window. Some layout tasks become much easier when you can view things this way. Combined with the feature that shows you distances between objects when you press the option key, layout in IB can be done very quickly and precisely. Use these tools to try to preserve the "intent" of the nib you're working on as closely as possible, when you find that layout changes are necessary.

Resources for Localizers

• On-disk developer documentation

  If you have the Developer Tools installed (and you will need to, to do any localization), you already have lots of information at your fingertips. For example, /Developer/Documentation/DeveloperTools/InterfaceBuilder/InterfaceBuilder.help is a good introduction to Interface Builder. /Developer/Examples/InterfaceBuilder/ has a bunch of example projects that demonstrate various things. There's enough doc under the /Developer directory to stun an ox. Most developers use a third-party indexing tool like MTLibrarian or MarshmallowLibrarian to help them search the doc, as Apple has no usable solution for that right now.

• The on-line documentation

  I used to have a link here in to Apple's "Tasks and Concepts" documentation, but links in to Apple rarely stay good for long. Suffice to say that Apple has tons of stuff online about localization, and that is worth reading.

• http://developer.apple.com/intl/

  This is Apple's base page for internationalization issues. It contains Apple-sanctioned glossaries of how to translate common terms like file, disk, and so on into a variety of languages. There is also information on a tool to automate localization called AppleGlot (lovely name, eh? :->) which I haven't tried to use (I'd be curious to hear how you fare, if you try it). Lots of links to internationalization-related documentation, too.

• The cocoa-dev list

  This is the home page for a mailing list Apple hosts for discussion of issues relating to Cocoa development. Questions about using Interface Builder are welcome, as long as you have read the documentation first, and looked at any examples that might be relevant. Do search the list archives for an answer to your question before posting, though. Just lurking on the list is a great way to learn about programming in Cocoa; localization issues are only rarely touched upon.

• Cocoa Programming for Mac OS X (Aaron Hillegass)

  This is a popular book on Cocoa programming. It has a chapter on localization, according to Barnes & Noble. If all you're doing is localization, I suspect it's not worth the money, but if you're interested in learning Cocoa programming as well, or if you want more hand-holding in learning IB than Apple's resources give you, this book is probably worth the money.

If you have a tip or a resource for us to add to this page, contact us at our support email address. Thanks!

- Ben Haller