[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gettext] the manual is incomplete about using a compendium PO f
Re: [bug-gettext] the manual is incomplete about using a compendium PO file
Thu, 11 Apr 2019 01:59:31 +0200
KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; )
> As the nano PO file recently "acquired" some messages from gnulib,
> I looked at the gettext manual to see how to quickly fill in their
> translations from another PO file. I read this page (section 8.4.2):
> info gettext editing compendium using
> plus subsection 188.8.131.52 on the preceding page.
Maybe Akim (CCed) knows a better way? Or maybe
is the better way?
> With those suggestions, I ran the following:
> msgcat --use-first extracted.po nano-4.0-pre1.nl.po >melded.po
> The resulting PO file has all the gnulib messages translated, as
> expected, *however*... the header of this new PO file is the one from
> the grep PO file, not the one from nano. This is not what is wanted.
If you pass the PO files to msgcat in opposite order, you obtain the
right header entry.
> I can manually chop the header from extracted.po and then run the
> msgcat and msgmerge again, and then the resulting PO file has the
> wanted old nano header. But this is not mentioned in the manual,
> so I would say that the given recipe is incomplete.
The given recipe is directed at translators who want a translation
memory of what they (or their team) have already translated. In such
a PO file, the header entry is irrelevant.
> However, instead of msgcat plus msgmerge, one can also simply do:
> msgmerge --compendium=extracted.po nano-4.0-pre1.nl.po \
> nano-4.1-pre1.pot >directly.po
> It gives the wanted result (nano header and all gnulib messages
> translated) in a simpler command and without needing to cut the
> header off extracted.po.
Yes, this is another way to implement the operation you need.
> But that only works when using the old version of the nano PO file,
> not when using the new 4.1 version from the TP that already has
> several of gnulib's messages filled in with fuzzy matches:
> wget https://translationproject.org/PO-files/nl/nano-4.1-pre1.nl.po
> msgmerge --compendium=extracted.po nano-4.1-pre1.nl.po \
> nano-4.1-pre1.pot >from-latest.po
> The fuzzy matches are not overridden by the exact matches from extracted.po.
So, you should better preprocess the nano-4.1-pre1.nl.po with
'msgattrib --no-fuzzy' or 'msgattrib --translated'.
> I think this is not how most people would expect a compendium to work: an
> exact match from a compendium surely is better than any vague, fuzzy match,
> and msgmerge should replace the fuzzy match and clear the fuzzy flag, no?
This is not necessarily so. A translator may want to prefer her own translation,
even if it is fuzzied, to the translation by another translator for another
package (because that may be using different terms or a different style).
I am reluctant to change the compendium feature, because
- It is directed to translators, but you are not using it from the perspective
of a translator.
- Translation tools nowadays have a better mechanism than the PO compendia.