When size matters

I created this page with one very specific idea, but the title makes room for many other ideas...

LES on 12 Feb, 2004: I am a professional translator, hobbyist programmer and have many times run into this problem: I am given a file with hundreds of software strings, almost invariably part of a GUI, and asked to translate them into Portuguese. The software can range from a desktop application to cell phone systems. And I get these following instructions: "The number of characters in each translated line should NOT be more than that in the original string in English".

After some time, I simply began to refuse such projects because it's just insane (not to mention that the software market always pays peanuts for translation work). I have plenty of experience translating strings and I can only hope that English-speaking developers will one day realize that it is IMPOSSIBLE to do a decent translation/localization work with that specific limitation. English is a very compact language. Portuguese is not. It it more than often IMPOSSIBLE to fit the Portuguese translation of a string in the same number of characters as the original string. Sometimes we can abbreviate, but half of these abbreviations will make absolutely no sense. A rough example: would you be able to guess that [t/off ex pr sy for int/dp mds cur in act] means...

"turn off external processing system for inter-dependent modules currently in activity"

How about this: [pu bu wh li on un fi/al sig giv]

...

"push button whenever the light is on, unless the fire alarm signal has been given"

These are not real cases. They couldn't be because I always translate these strings *into* Portuguese. But I feel comfortable making these up because I have a lot of experience with that kind of work and I can assure you that this is the sort of cryptography we're forced to come up with when we translate strings from English into Portuguese and are not allowed to make them any longer than the original. All my clients until now said "we don't care, do as you're told", so I did, they were happy, I was paid, but I can only wish luck to whoever is going to *use* that system. Imagine such gibberish on the screen of a cell phone or PDA (I've actually "encoded" a couple of them in Portuguese). I mean, something that is supposed to be used by the general public. Think they can crack such code? Seriously, some of it will stand a much better chance of being understood if simply left in English. I mean, seriously.

Once I was told that the software was "optimised on that". My idea of "optimization" is very different from theirs, then. If you port that application to another country and almost half of the GUI or system messages cannot be understood, how do you call that "optimized"?

Here is my plea: please don't impose unreasonable limits on your software. Think that everything may be changed in the future and that such changes are very likely to require some "room". Cell phones may be a special case and require special treatment, but... desktop applications, like the one I just turned down??? Come on...

I am almost sure I am not speaking to the right audience here, but as so many here actually work with software and have the power to change such habits, I just hope I can reach at least one developer and make a little difference somewhere.

AM Quite often I get complaints (or have complaints myself) about the text that is shown in GUIs - terse text or text that simply describes what immediate problem the software detected, rather than a useful tip on how to correct the actual problem.

For instance:

   Error reading file such-and-such

This message does not tell:

What went wrong with reading the file?
What should I, as a user, do about it?

Explaining these matters does influence the size of the message:

You need more text and quite possibly more lines
You need to be able to describe in relevant detail what to do

This is not only a matter of the natural language that is used, it is also a matter of what information is to be given to what kind of user!

So, the size of the text is a function of the natural language that is used and of the level of detail that is required. If you try to put a limitation (like the one Luciano is complaining about) on that function, when changing one of its arguments, you are bound to have to change the other as well ...

Zarutian 2007-05-18 23:40 (UTC): that reminds me of my favorite very short error message: Eh?

WJP 2007-05-16. Wow, I have heard of silly restrictions on translation, but nothing this crazy. Could it be that the programs for which LES has been asked to translate do not allocate the memory for strings dynamically, and so must keep the translations no longer than the English text because they are going to overwrite the English strings? This is the only explanation that makes sense to me, but it seems so primitive, something from the 1960s.

LV Another possible reason, besides statically allocated buffers, might be a case where reports and dialogs are hard coded for particular fonts, pixel widths, etc. and it would be non-trivial to attempt to redesign the displays, reports, etc.

DKF: It is interesting to note that such (badly-written) applications are also not formally accessible. Some people have trouble seeing small text and so need to increase the size of the fonts used substantially, and yet they don't want to use a screen reader because "We're not blind yet, thankyouverymuch!" Many web pages are just as bad.

If you have to squeeze numbers (like file sizes) into little room, see Narrow formatting