Go to the first, previous, next, last section, table of contents.
xgettext Programxgettext [option] inputfile ...
Functions found on po-subedit-mode-hook, if any, are executed after
the string has been inserted in the edit buffer and before recursive edit
is entered.
The command K (po-kill-comment) get rid of all
translator comments, while saving those comments on the kill ring.
The command W (po-kill-ring-save-comment) takes
a copy of the translator comments on the kill ring, but leaves
them undisturbed in the current entry. The command Y
(po-yank-comment) completely replaces the translator comments
by a string taken at the front of the kill ring. When this command
is immediately repeated, the comments just inserted are withdrawn,
and replaced by other strings taken along the kill ring.
On the kill ring, all strings have the same nature. There is no distinction between translation strings and translator comments strings. So, for example, let's presume the translator has just finished editing a translation, and wants to create a new translator comment to document why the previous translation was not good, just to remember what was the problem. Foreseeing that she will do that in her documentation, the translator may want to quote the previous translation in her translator comments. To do so, she may initialize the translator comments with the previous translation, still at the head of the kill ring. Because editing already pushed the previous translation on the kill ring, she merely has to type M-w prior to #, and the previous translation will be right there, all ready for being introduced by some explanatory text.
On the other hand, presume there are some translator comments already
and that the translator wants to add to those comments, instead
of wholly replacing them. Then, she should edit the comment right
away with #. Once inside the editing window, she can use the
regular GNU Emacs commands C-y (yank) and M-y
(yank-pop) to get the previous translation where she likes.
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.
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 M-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.
Go to the first, previous, next, last section, table of contents.