[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PO mode is able to help the knowledgeable translator, being fluent in many languages, at taking advantage of translations already achieved in other languages she just happens to know. It provides these other language translations as additional context for her own work. Moreover, it has features to ease the production of translations for many languages at once, for translators preferring to work in this way.
An auxiliary PO file is an existing PO file meant for the same package the translator is working on, but targeted to a different mother tongue language. Commands exist for declaring and handling auxiliary PO files, and also for showing contexts for the entry under work.
Here are the auxiliary file commands available in PO mode.
po-cycle-auxiliary
).
po-select-auxiliary
).
po-consider-as-auxiliary
).
po-ignore-as-auxiliary
).
Command A (po-consider-as-auxiliary
) adds the current
PO file to the list of auxiliary files, while command M-A
(po-ignore-as-auxiliary
just removes it.
The command a (po-cycle-auxiliary
) seeks all auxiliary PO
files, round-robin, searching for a translated entry in some other language
having an msgid
field identical as the one for the current entry.
The found PO file, if any, takes the place of the current PO file in
the display (its window gets on top). Before doing so, the current PO
file is also made into an auxiliary file, if not already. So, a
in this newly displayed PO file will seek another PO file, and so on,
so repeating a will eventually yield back the original PO file.
The command C-c C-a (po-select-auxiliary
) asks the translator
for her choice of a particular auxiliary file, with completion, and
then switches to that selected PO file. The command also checks if
the selected file has an msgid
field identical as the one for
the current entry, and if yes, this entry becomes current. Otherwise,
the cursor of the selected file is left undisturbed.
For all this to work fully, auxiliary PO files will have to be normalized,
in that way that msgid
fields should be written exactly
the same way. It is possible to write msgid
fields in various
ways for representing the same string, different writing would break the
proper behaviour of the auxiliary file commands of PO mode. This is not
expected to be much a problem in practice, as most existing PO files have
their msgid
entries written by the same GNU gettext
tools.
However, PO files initially created by PO mode itself, while marking
strings in source files, are normalised differently. So are PO
files resulting of the the `M-x normalize' command. Until these
discrepancies between PO mode and other GNU gettext
tools get
fully resolved, the translator should stay aware of normalisation issues.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |