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?
I just answered a similar (much older) question here.
Short version:
The PO file format is very simple, so it is possible to generate PO/MO files from another workflow that allows the flexibility you're asking for. (your devs want identifiers, your translators want words)
You could roll this solution yourself, or use a cloud-based app like Loco to manage your translations and export a Gettext file with identifiers when your devs need them.
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