By obsolete PO file entries, we mean those entries which are
commented out, usually by tupdate when it found that the
translation is not needed anymore by the package being localized.
The usual commands moving from entry to entry consider obsolete
entries on the same level as active entries. Obsolete entries are
easily recognizable by the fact that all their lines start with
#, even those lines containing msgid or msgstr.
Commands exist for emptying the translation or reinitializing it to the original untranslated string. Commands interfacing with the kill ring may force some previously saved text into the translation. The user may interactively edit the translation. All these commands may apply to obsolete entries, carefully leaving the entry obsolete after the fact.
Moreover, some commands are more specifically related to obsolete entry processing.
The commands M-n (po-next-obsolete-entry) and M-p
(po-previous-obsolete-entry) move forwards or backwards,
chasing for an obsolete entry. If none is found, the search is
extended and wraps around in the PO file buffer. The commands
M-SPC and M-DEL are synonymous to M-n
and M-p, respectively.
PO mode does not provide ways for un-commenting an obsolete entry
and making it active, because this would reintroduce an original
untranslated string which does not correspond to any marked string
in the program sources. This goes with the philosophy of never
introducing useless msgid values.
However, it is possible to comment out an active entry, so making
it obsolete. GNU gettext utilities will later react to the
disappearance of a translation by using the untranslated string.
The command z (po-fade-out-entry) pushes the current entry
a little further towards annihilation. If the entry is active, then
the entry is merely commented out. If the entry is already obsolete,
then it is completely deleted from the PO file. It is easy to recycle
the translation so deleted into some other PO file entry, usually
one which is untranslated. See section Modifying Translations.
Here is a quite interesting problem to solve for later development of PO mode, for those nights you are not sleepy. The idea would be that PO mode might become bright enough, one of these days, to make good guesses at retrieving the most probable candidate, among all obsolete entries, for initializing the translation of a newly appeared string. I think it might be a quite hard problem to do this algorithmically, as we have to develop good and efficient measures of string similarity. Right now, PO mode completely lets the decision to the translator, when the time comes to find the adequate obsolete translation, it merely tries to provide handy tools for helping her to do so.
Go to the first, previous, next, last section, table of contents.