Quarter Life Crisis

The world according to Sven-S. Porst

« Localisations are hardMainKeyboard Equivalents »

Localisations are a hassle

1253 words on

Dan Wood shares his experiences with localising software. While I detailed a few of the difficulties of the localisation process right on a language and ‘social’ level, yesterday, Dan focuses on the technical difficulties of doing it. Even with the tools we get for that task in Mac OS X and additional tools like iLocalize which are considered to be above average in the software world at large, the whole process is a rather huge effort and it’s easy to see why people don’t like going through it.

The issue Dan focuses on is that the current Interface Builder model of doing localisations puts a very high price on GUI changes. Changing things like positioning may require you to go through each localisation of the NIB files and adjust the positioning there. The same for establishing new Connections or Actions. And - with InterfaceBuilder’s rather sucky editor for editing Bindings, I’d say changing the key path for the bindings of something like an NSSlider in eight languages should be enough to drive you nuts in terms of the clicks that need to be done and the possibility for failure you get. (Will you really test each of these localisations to see that all bindings do work as intended?)

I think that Dan’s idea to clearly separate the text, layout and application logic in a nib file from one another sounds like a good one (and like an opportunity Apple missed with Interface Builder 3). This way one might hope that at least the application logic part - which is the most error prone one - could be edited in one go for all localisations. While the wording and positioning would still be handled on a per-language basis.

I do not think that fully automating the other steps will be a good idea. Translating words automatically has plenty of pitfalls because errors happen there easily. My classic example being Apple’s handling of the word ‘extensions’ which can be used for for ‘system extensions’ and the asinine ‘file name extension’. In German they call one of them ‘Erweiterungen’, while using the word ‘Suffix’ for the other. Automatic translation FAIL ensued and was only fixed years later. Of course one can have better dictionaries that take all these cases into account, but it appears to be a bad idea to use dictionaries only. They can give you a headstart but you will need (a qualified person) to proofread things for whether they make sense.

The same is true for GUI layout. Often you can ‘feel’ that a window or dialogue box has been laid out automatically. Things frequently have a rougher look when being done in that way. The positioning isn’t quite right, there may be excessive white space, text may not be fully visible, elements can overlap. While I guess that one could find a formal language that describes the UI elements precisely enough to give a decent layout automatically, I suspect that this language would need to be so complex that using it wouldn’t actually simplify things.

Dan’s Sandvox web site making application gives another example for that. It has an inspector window which contains a load of settings that you can make to your site, each page and elements within the page. As inspectors go, this one is annoying. Because it is too large and even a MacBook screen can be too narrow to show the Sandvox window and the Inspector without overlap if you have your Dock at the side of the screen (and who wouldn’t). With German words and user interfaces running a bit wider than the English ones, the inspector is a bit wider in German. And here literally every pixel counts and every single manual tweak to reduce the inspector’s width is highly appreciated.

English speakers - and thus most software developers - may not care about these differences, but they do exist and it’s hard to understand why user interfaces shouldn’t be good in other languages as well. I am always tempted to suggest that English speaking software developers should learn another language and use their machine in that language, simply so they can appreciate the second class treatment and become aware of more of the pitfalls. Of course they’d need to learn the other language really well for this to be constructive which makes it rather unlikely that we see this happening. But perhaps setting up non-standard number and date formats may be a first step towards immediately spotting problems that would otherwise not even raise an eyebrow for potentially requiring care.

Just to illustrate typical problems of automated (or coded) user interface localisation, look at Delicious Library 2 which immediately struck me as half-assedly localised (confirmed by Dan’s statement that they do so automatically) and which sports UI elements like this:

Button with cut off text in Delicious Library 2, German

Another coded localisation FAIL which annoys me pretty much every day can be seen in Apple’s Mail. It appears that the minimum distance of the search progress indicator from the right edge of the window is coded in a fixed amount of pixels there (rather than using the width of the Save button which has to fit into the space). As I like my Mail window narrow (how many e-mails have content that cannot be displayed in 80 characters of Monaco 10pt per line?), overlap happens:

Mail progress indicator reaching into the Save button

The thing is that both these failures are blatantly obvious if you actually use the application. And in a way that is the real problem: Once you automate more of your UI work, you reduce the number of eyes seeing it before being shipped. As a consequence bad UI experiences will increase as users get to use an absolutely virgin UI. As long as you have to edit each NIB file, you are at least forced to look at it (minus programmatically inserted strings which can be problematic enough) and you can easily spot the obvious problems. Interface Builder 3’s info window will even try helping you do that.

Interface Builder 3's Info window

July 17, 2008, 0:10

Tagged as cocoa, development, interface builder, localisation, nib, os x, sandvox, software, ui.


Comment by LKM: User icon

Excellent post. Related issue: The main problem I have with US application is command keys that don’t exist on my keyboard.

July 17, 2008, 10:37

Comment by dt: User icon

English-mono-lingual software developers can create a build of their app that uses double-byte/full-width Roman text from a Japanese font:

Doube−byte, full−(kanji)width Roman text using Kotoeri input method.

Simple enough to create a script that converts your original English strings to full-width Roman, enabling testing your UI in a “foreign” script. A bit exaggerated in the inflation of string length but better than nothing—plus, this will catch dumb assumptions about all text being single-byte.

July 17, 2008, 11:26

Comment by ssp: User icon

@LKM: I can totally relate to that. In fact I added another post on the issue of keyboard equivalents alone in the vain hope that it may actually illustrate the problem and raise awareness in the people who are aware already.

July 18, 2008, 2:16

Add your comment

« Localisations are hardMainKeyboard Equivalents »

Comments on




This page

Out & About

pinboard Links