Introduction

Localizing an application is not a simple task. In Germany, the first floor is the first one above ground. In USA, it's at ground level. How do you put that into a database? If you make an integer field named floor that contains 0 for ground level and 1 for the first floor above ground, it is very easy to understand in Germany, but you'll have to modify the user interface quite a bit to make the same data accessible by Americans in a way that they understand easily.

The GNU gettext system only helps you with translating messages, but this can go wrong, too. For instance, the Math unit in Delphi has functionality to convert between different units. The names of these units can be translated, but if you translate two unit names to the same thing, all programs that use the Math unit will generate an exception during initialization. Actually, this already happened. The first Danish translation of the Borland Delphi 7 runtime library had "Hektar" as the translation for both "SquareHectometers" and "Hectares". It's the same thing, and the correct word is "Hektar", so why not use it? Now that the program doesn't work, whose fault is it?

The answer is very simple: It's the programmer's fault. He didn't live up to the responsibility of ensuring that the translator couldn't do anything to break the program. It might take unnecessary extra programming to ensure this, but it can be very, very difficult to debug the program if this is not ensured.

Let's take another example: The translator translates the application, but the users cannot find out how to operate the program. The English version works well and users know how to operate the English version. Whose fault is this?

Here, the answer is more complex: it might be the translator that made a bad translation, but it could also be the programmer that designed a user interface that is hard to translate. Often, user interfaces use concepts that can be described with one word in the programmer's own language, but if it takes 10 words to describe the same concept in another language, people that only know that other language might not understand the concept. For instance, zip-files could be represented by a zipper in English (Windows XP does that), but in other languages thsi relationship makes absolutely no sense. In Danish, zip-files are named "zip-filer", and zipper is "lynlaas". There is absolutely no relationship between "zip-filer" and "lynlaas", and whoever invented that icon definitely didn't think of internationalization.

The leader of an internationalized project has to:

• Ensure that all programmers understand the concept of internationalization.

• Ensure that translators can give feedback to the programmers in order to ensure that everything is localizable.

• Ensure that there is a release procedure with beta-testing for each language. Having debugged the program in one language doesn't mean that it is bugfree in other languages, too.

• Ensure that the beta-testers know, that they must give feedback on the translation, too.