Source code not English; which (natural) language to display to the user?

Question

I'm creating an English translation for a program written in German (i.e. all strings within tr("...") are German). Users who are in a non-English non-German locale will probably want to see the English translation, but with the program as it is now they will see German.

There are some ways to solve this problem:

• Check if it's a German locale and force to English otherwise.
• Present an option to the user.
• Make the programmers change their source code to English.

What is considered best-practice for internationalizing where the source code is not in English?

Answer 1

I think the best option is asking the user (during installation probably).

Change the source to English is too costly and not worth it. I live in Brazil, we have tons of codes in Portuguese and translating to English wan't necessary one time (we do make software to english speakers). Unless you have a client that requires you to do so (usually when you are selling the source also).

Hope it helps

Answer 2

These are two separate questions.

The best practice is to not use any kind of hard-coded string in the sources. Strings should be stored in external files and loaded by ID.

But what you have there does not sound like the best practice. Might be too much work to get it there.

What you describe (the tr("...") stuff) sounds like gettext (or something similar). That approach for gettext (and similar libraries) is that "the stuff in the sources is the ultimate fallback", used if the strings for the desired language are not present.

In this case I would go with "Present an option to the user." You can't assume the user knows English.

Real example: in Switzerland the official languages are Italian, German, French and Romansh. If I ask for French and it is not present, then the next best option is probably German, not English. I Canada the official languages are French and English, so if I as for French and is not available, the next best option is probably English.

Answer 3

OK, so I guess the three options are:

Recompile the program with translated strings.
This is fraught with danger as you'll end up with two copies of the source. Bug-fixes in one will need to be done in the other. And then, what happens if you need French? Italian? Spanish? The only advantage of this approach is that it's feasible for a non-developer to do the work. (Just about.)

Resource out the strings, and automatically check what the UI locale is on load.
Here the strings are replaced with GetResource("key") or similar. On load the program automatically translates to the user's culture. This might work, but I know plenty of German-speakers who have English-language culture installed on their PCs but who would prefer German language programs at some points.

Resource out the strings and give the user the choice on load
In general it's always best to give the user control. This might be a prompt on load, although if the application is used often this can be an annoyance. Perhaps a balance is to ask the user during installation for their preference and then give then an option in a dialog to later change this setting.

Note, by the way, that translation is not localisation. For instance: number formats are quite different in Germany (e.g. 1.233,44) from English (e.g. 1,233.44). Icons and suchlike often have national characteristics.