Gettext msgid's. Keys or Strings?

I tried the key-based approach for a while because I felt like it was more… correct, but I ran into the following downsides:

• In the template you don’t see the actual text anymore (you’re already keeping a mental model in your head of markup => design, so abstract keys don’t help there)
• Extra choices to make regarding naming convention, and having to maintain it / keep it consistent
• Duplication, for example: login-page-password-field-label & registration-page-password-field-label may have the same translation (“password”). (So… then you create a single translation, password-field-label, but then you deviate from the naming convention)

Hope that’s helpful:)

In addition to that, there are usually scripts available that can extract all of your gettext snippets from the code base to create the translation files for you.

When you or somebody else sits down to write the snippets in another language, having the key already be the reference language is really helpful.

Here’s a short post from about a decade ago about it dealing with the concept in CakePHP.

This is what Gettext for Elixir does as well with mix gettext.extract.

It really depends and you should test your workflow e2e before finally deciding..

I recommend using normal text as the key, that makes the developer happy, and the devs don’t have to go through the entire translation workflow every time they add a string of text.

gettext has a context metadata thing make sure you use that - and come up with some kind of naming convention for different things - that way you will have metadata for the string, and you will avoid key clashes - eg “OK” would clash - but “OK” context: “user create form missing data modal” would not clash with other "OK"s.
context also gives erhmm context to the translator and an ability to find/locate where the string is used.

check that your gettext implementation supports context.

then figure out your workflow, I’ve used poeditor.com in the past (not super happy about it, but gets the job done), you can usually integrate with your gitflow - so you gettext extract and gitpush that file, the new strings are on poeditor immediately, and then you can export through git from poeditor as well.. and finally you might need a gettext compile step depending on your gettext.

Keys have one single advantage: Somebody can correct the messages in the base language (because there is no base language). With gettext you either have to change the source code or you have to define your base language as “broken English” and provide a translation catalog for proper English.

Otherwise I know only disadvantages of keys. Apart from the ones mentioned above, these are:

• The translation files tend to contain stale messages.
• There are no standard tools that keep the translation files in sync with the sources and with each other.
• Very hard to produce gramatically correct messages for plural forms (google for “ngettext”).
• Without an extra translation cache, translations soon become unmaintainable or very expensive. Gettext has a translation cache built-in.
• Translation errors are hard to detect in key-value files. Compare that to PO, where you see the original next to the translation.
• Gettext allows you to easily mix a multitude of programming languages.
• Gettext is a well-established standard with a mature and powerful toolchain and an ever-growing user base. Open-source projects are almost exclusively localized with GNU gettext.