Combining keys and full text when working with gettext and .po files

Question

I am looking at gettext and .po files for creating a multilingual application. My understanding is that in the .po file msgid is the source and msgstr is the translation. Accordingly I see 2 ways of defining msgid:

Using full text (e.g. "My name is %s.\n") with the following advantages:

• when calling gettext you can clearly see what is about to be translated
• it's easier to translate .po files because they contain the actual content to be translated

Using a key (e.g. my-name %s) with the following advantages:

• when the source text is long (e.g. paragraph about company), gettext calls are more concise which makes your views cleaner
• easier to maintain several .po files and views, because the key is less likely to change (e.g. key of company-description far less likely to change than the actual company description)

Hence my question:
Is there a way of working with gettext and .po files that allows combining the advantages of both methods, that is:
-usage of a keys for gettext calls
-ability for the translator to see the full text that needs to be translated?

Answer 1

gettext was designed to translate English text to other languages, and this is the way you should use it. Do not use it with keys. If you want keys, use some other technique such as an associative array.

I have managed two large open-source projects (50 languages, 5000 translations), one using the key approach and one using the gettext approach - and I would never use the key approach again.

The cons include propagating changes in English text to the other langauges. If you change

msg_no_food = "We had no food left, so we had to eat the cats"

to

msg_no_food = "We had no food left, so we had to eat the cat's"

The new text has a completely different meaning - so how do you ensure that other translations are invalidated and updated?

You mentioned having long text that makes your scripts hard to read. The solution to this might be to put these in a separate script. For example, put this in the main code

print help_message('help_no_food')

and have a script that just provides help messages:

switch ($help_msg) {
...
case 'help_no_food': return gettext("We had no food left, so we had to eat the cat's");
...
}

Another problem for gettext is when you have a full page to translate. Perhaps a brochure page on a website that contains lots of embedded images. If you allow lots of space for languages with long text (e.g. German), you will have lots of whitespace on languages with short text (e.g. Chinese). As a result, you might have different images/layout for each language.

Since these tend to be few in number, it is often easier to implement these outside gettext completely. e.g.

brochure-view.en.php
brochure-view.de.php
brochure-view.zh.php