Gettext tool to use the translation in one language as the key for translation in another language

Question

Is there a tool to do what I'm suggesting in the question title? Consider the following scenario, where the msgid is "%s minutes left", the msgstr in English is, well, the same, and msgstr in another Language is "bla %s bla". Someone in marketing decides that in English the string should be "%s minutes left, hurry up!". What do I do? On the one hand, I can change the msgid. On the plus side, it becomes evident that the translation in Language needs to be updated; but the string change requires a developer to update a source file, which doesn't sound like good use of the developer's time when there are so many features to implement and time is scarce. On the other hand, a translator could update the msgstr in English, so as to match the marketing person's request, but then how do I notify translators that they have to update their translation? Also, all they see is the msgid, which hasn't changed. So how to I tell them what the actual string is?

Thanks to anyone who can help.

Answer 1

This is a common situation and – for better or for worse - is pretty much built into Gettext's intended workflow.

The normal workflow being:

source code > extract to POT > generate PO > translate PO

An amend to source text would then be:

edit source > extract new POT > merge into PO > review fuzzy strings

The msgmerge command line tool allows you to merge an amended POT file with already-translated PO files. This will mark any translations that had their source language altered as Fuzzy, meaning that translators might want to check again if their translation is still accurate.

msgmerge old.po changes.pot -o new.po

The POEdit program also has this function via a "Update from POT" menu option which I suspect may be using the msgmerge program in the background.

As @deceze has pointed out, using "machine IDs" separates source strings from translations and can avoid such problems. Although this is how many other localisation platforms work, it is not really how Gettext is intended to work (square peg, round hole etc.)

Perhaps worth mentioning though is that you can use "Extracted comments" feature to convey further information to translators. In the PO/POT file they are indicated with a "#. " prefix. The xgettext program extracts these from your source code, but you could also maintain them manually.

For example, if you wanted to maintain an English PO file (for your marketing people to edit) and also use machine IDs in your code, you could have something like this:

#. %s minutes left
msgid "time-nag-minutes-left"
msgstr "%s minutes left, hurry up!"

Where line 1 is your original source code comment showing the initial English, the second line is your machine ID and the third line is your marketing people editing the "translation" without any need to edit the source code again.

I'm not recommending this - it's non-standard and your translators may be used to Gettext working the way it's supposed to. It's an option though.

Answer 2

Working with gettext, you have two options:

1. Use "string ids" in the source and provide all the UI text in PO files. E.g.:

   msgid "FRONTPAGE_SALES_CALL_TO_ACTION"
   msgstr "Buy now, buy often!"
   

   This has the advantage that you can change UI text purely by editing PO files, not needing to touch code. It has the disadvantage that your users will see nonsense in the UI for missing translations, and that the UI code is more abstract/meaningless and may make it somewhat harder to work with/prototype properly etc. It also introduces complexities in working with translators, as you mention yourself.

2. Use the literal UI text in your code and only supply translations for it in PO files.

   In this case you should not have a PO file for your source language, where each msgid and msgstr are identical. That's just redundant.

   If you're using this style (and apparently you are), then any actual change of text must happen at the source. The source code is your canonical UI; if you're changing the meaning of a message, it's actually a change in the UI so the UI code needs to be updated. You then sync that change with your PO files using xgettext (or similar tools), which propagates the change to all translation files and marks the changed string for translation (or even pulls out an existing translation if available).

You should not get into the habit of doing 2. but treating it like 1. That'll lead to a lot of confused WTF?! moments down the road.

If you want to enable "front end people" to change text without needing to touch complex source code, you need to decouple your front end code better from your backend code. This is not necessarily the task of gettext, but of a better template system or otherwise better MVC separation.