Quarter Life Crisis
The world according to Sven-S. Porst
« A few pixels more or less will matter • Main • Localisations are a hassle »
« A few pixels more or less will matter • Main • Localisations are a hassle »
1546 words on Software
As a matter of principle I am a big fan of localised software. With the exception of many localised applications, that is.
I am a fan because, obviously, not everybody can use applications in English, German, Chinese or whatever language they were created for. As an application should help the person using it - rather than creating another language or cultural burden - presenting itself in a properly localised version helps a lot in that respect: The user will feel more welcome and comfortable about it.
That’s the theory anyway. In practice, it is hard to get localisations right and very hard to do them in a spot-on way. If people are aiming for quality localisations, creating them is a huge amount of work and maintaining them across updates will add to that.
The first thing that is needed for having localisations is awareness by the developer. The programming has to be free of assumptions about the language used which means that none of the strings appearing the user interface should be in code but they should reside in external resources. When dealing with Cocoa, nib/xib files are your friends as is NSLocalizedString. I’m sure other APIs have similar techniques in place. Furthermore you’ll want to make sure that things as date or number formats use the user’s preferred localisation and the corresponding formats (hello NSFormatter). Even more involved aspects of this such as the sort order of strings aren’t a big deal in environments like Cocoa. All that isn’t really hard to do but it can be a pain to retrofit an application, so it’s worth having it in mind from the beginning.
The next aspect is the GUI. Usually you shouldn’t make assumptions about the size and position of strings on screen. If you are designing your GUI in English, you need to keep in mind that nasty languages like German can need significantly more space for the same labels and messages. This has led to ugliness and usability problems (say, checkboxes with two-line labels or inspector windows becoming so wide that they cover too much on the main window on a medium size screen) in many places.
In a way these preparations on the side of the main developer are obvious and trivial. The hard part comes for the localiser. Ideally you want the localiser to be
It’s hard to find such people. There are plenty of native speakers and some may even use your application. But then things start being difficult. Very few people are actually familiar, or intimately familiar, with the terminology of the OS in question. And that’s not just about the terminology right (say, by using Sichern
for Save
in German on the Mac rather than Speichern
) but it’s also about knowing which styles of phrases and senteces are adequate and fit in with the rest of the OS.
This is hard to formalise, but if you look at the preferences window of VLC in German it’s mostly an incomprehensible mess that doesn’t fit in at all. Compare that to the preferences window of Transmit in German which seems to be done by someone with just the right skills, awareness and care for detail.
The next crucial issue is the awareness and full understanding of what an application does and what the localised strings are used for by the localiser. Many applications come with localisations clearly lacking that. And it’s a difficult thing to get right! Most applications do have somewhat obscure features and bunches of strings that are used very rarely (error messages for when an initial import of data goes wrong, say). The context when those come up may not be clear at all from the string resource files the localiser uses. And even if it is reasonably clear, the localiser may still have the wrong impression of the situation the string is used in.
While NSLocalizedString helps a lot when doing localisations, the next question is how good the descriptions are which developers put along with their strings. Cocoa developers: Do a count of No comment provided by engineer.
lines in your .strings files. Now! And even when there is a comment, will it be a useful one? I find that it often requires quite a detailed explanation to pin the usage of a string down precisely. Imagine that the person translating this doesn’t have your code to go by and may have never seen the UI part in question in the original language. For an extra challenge consider that you may be using the same strings in menus (NIB files), in code (Localized.strings files) and in your help. As you can’t pin down cross references between these, changing terminology a bit requires great care to catch all the places that need updating.
Wich hints at the last point that the localiser should really use and test the application and its localisation to see all the localised strings used. With complex applications and even slightly non-trivial applications that can be hard to achieve and it requires a lot of time. And it’d also require a clearly described testing plan of which situations to check. Which applications have that? In a way that covers all possible UI constellations?
Getting these finer points right can be exhausting for both the localiser and the developer because they first need to agree on how close a localisation needs to be to the original (I tend to think that localised versions feel more natural if the localiser has a bit of freedom to change expressions away from literal translations, but if such changes go too far it may be very hard to talk about an application and its features across language barriers) and then invariably there will be terms in the original language which can be interpreted in different ways each of which would get a different translation. Often it’s necessary to check back with the developer what the intent of the command is to find the most adequate translation.
Altogether that’s not a huge amount of fun (and that’s before even looking at the laborious process of translating things like read me files, help books and release notes) and it has many places in which it can go wrong.
This also explains why there are so many bad localisations around. Only very few people can do the job and only a few of those have the patience to do it well. Now imagine there’s an open source project and an enthusiastic user contributes a home-made localisation. To make things easy let’s assume that it’s a good localisation. The problem with that is what happens when the next update ships. Will that user still be around to contribute any strings that were added and update the read me and help accordingly? How long will he need to provide those changes? You certainly can’t expect him to do all that quickly and for free, so you’re stuck in a difficult situation there.
Now assume the more realistic situation of someone contributing a localisation that’s not perfect. There are many ways in which a localisation can be imperfect: From poor alignment of UI elements, to some strings not being localised (tooltips or accessibility strings in nib files are easily overlooked when working in Interface Builder which probably is why more ‘pro’ localisers prefer tools like iLocalize), to problems with the language (how can I know whether the localiser uses terminology that fits in with the OS and uses ‘good’ translations of the original terminology when I don’t know the target language very well?) to simple typos. Many things can and will go wrong in that process. And it will require a lot of extra testing, particularly if you don’t know the localiser long and well enough to trust them on doing a good job and all the necessary testing on their side already.
Perhaps a bad localisation will help some users, but I usually consider it ‘half-assed’ and find working in a poorly done German version which still has the stink of English terminology all over it much worse than working in the properly done English original (early localisations of Sandvox always made me deactivate the German localisation and loads of open source software trigger the same reflex).
What makes this situation particularly difficult is when people offer to do localisations for you. Even if they do all the translation work, just including the localisation will leave a chunk of extra work with you of which you won’t a priori know whether it actually improves the application and whether you’ll be able to co-operate on future versions as well.
As localisations are a good thing and some users just like your application enough to want to have a localisation for themselves, that’s a really nice thing of them to do and you don’t want to turn them down. But at the same time it’s hard to be enthusiastic about including such a third party localisation when you know all the ‘buts’ I listed above. Which is a little dilemma.