Why do people use plain english as translation placeholders?

Question

This may be a stupid question, but here goes.

I\'ve seen several projects using some translation library (e.g. gettext) working with plain english placeholders. So f

Answer 1

I like your second approach. When translating texts you always have the problem of homonyms. Like 'open' can mean a state of a window but also the verb to perform the action. In other languages these homonyms may not exist. That's why you should be able to add meaning to your placeholders. Best approach is to put this meaning in your text library. If this is not possible on the platform the framework you use, it might be a good idea to define a 'development language'. This language will add meaning to the text entries like: 'action_open' and 'state_open'. you will off course have to put extra effort i translating this language to plain english (or the language you develop for). I have put this philosophy in some large projects and in the long run this saves some time (and headaches).

The best way in my opinion is keeping meaning separate so if you develop your own translation library or the one you use supports it you can do something like this:

_(i18n("Please enter your name", "error_please_enter_name"));

Where:

i18n(text, meaning)

Answer 2

Yes, you have to alter the existing translation files, and that is a good thing.

If you change the English wording, the translations probably need to change, too. Even if they don't, you need someone who speaks the other language to check.

You prep a new version, and part of the QA process is checking the translations. If the English wording changed and nobody checked the translation, it'll stick out like a sore thumb and it'll get fixed.

Answer 3

There's a fallback hierarchy, from most specific locale to the unlocalised version in the source code.

So French in France might have the following fallback route:

1. fr_FR
2. fr
3. Unlocalised. Source code.

As a result, having proper English sentences in the source code ensures that if a particular translation is not provided for in step (1) or (2), you will at least get a proper understandable sentence than random programmer garbage like “error_file_not_found”.

Plus, what do you do if it is a format string: “Sorry but the %s does not exist” ? Worse still: “Written %s entries to %s, total size: %d” ?

Answer 4

1. The main language is already existent: you don't need to translate it.
2. Translators have better context with a real sentence than vague placeholders.
3. The placeholders are just the keys, it's still possible to change the original language by creating a translation for it. Because when the translation doesn't exists, it uses the placeholder as the translated text.

Answer 5

Well it probably is just that it's easier to read, and so easier to translate. I'm of the opinion that your way is best for scalability, but it does just require that extra bit of effort, which some developers might not consider worth it... and for some projects, it probably isn't.

Answer 6

Interesting question. I assume the main reason is that you don't have to care about translation or localization files during development as the main language is in the code itself.