Re: Merging translations from Ubuntu, keeping fuzzy strings

[Chris Leonard <cjlhomeaddress gmail com>]

On Sun, May 13, 2012 at 11:01 AM, Chris Leonard
<cjlhomeaddress gmail com> wrote:
> On Sun, May 13, 2012 at 6:15 AM, Åsmund Skjæveland
> <asmund skjaveland bio uio no> wrote:
>> I've received some Ubuntu translations and I'm wondering how to best
>> merge them. The up-to-date translated strings look fine, but fuzzy
>> strings in the gnome PO file are untranslated in the Ubuntu PO file, and
>> also in the merged PO file.
>>
>> For example:
>>
>> In http://l10n.gnome.org/vertimus/gedit/master/po/nn , the word
>> "GTK_WRAP_CHAR" is present in some fuzzy strings in the gnome PO file,
>> but those fuzzy strings are not in the Ubuntu file or the merged file.
>> Instead, the updated msgids are untranslated. Also, the gnome file has
>> history/previous version of the string, but the ubuntu file and the
>> merged file doesn't have the previous string included.
>>
>> Is there some merging trick that preserves fuzzies?
>
> One trick I use when trying to compare two closely related PO files is
> to place the files in a folder and then use the pocompendium tool from
> Translate Toolkit.
>
> http://translate.sourceforge.net/wiki/toolkit/pocompendium
>
> pocompendium will highlight the differing strings by making them into
> fuzzy, pocompendium flagged strings.
>
> Reviewing the output file with Virtaal
>
> http://translate.sourceforge.net/wiki/virtaal/index
>
> It is quite easy to select pocompendium flagged strings.
>
> This preserves fuzzy flagging (from either file) and adds fuzzy
> flagging where there is a conflict.  This maximizes the "human review"
> element, which IMHO is all for the good.  It is not necessarily ideal
> for creating a final uploadable merged PO, but it does focus human
> attention to the strings that need review.
>
> cjl

A variation of the pocompenduim trick is that it can be run on a large
collection of PO files in a directory.  I do this to QA conflciting
translations of common strings across a language.

1) Collect all the PO files in a directory.

2) run pocompendium producing a single output.po file

3) Make and preserve a copy of the output.po file (because the next
step is destructive of the input file).

4) Run posplit on the output.po file. this destroys output.po (a bug
fixed in trunk, I think) and produces three files, one translated, one
untranslated and one fuzzy (also containing the fuzzy pocompendium
flagged strings that represent conflicts).

5) Review the pocompendium flagged strings in the fuzzy.po file for
conflicting translations.

6) Bring those translation conflicts to the attention of a native
speaker for review (in context of each PO file where they appear to
account for msgctext comments).

I recommend this as an approach to anyone concerned about maintaining
consistency of terms across a collection of Po files in their
language.  I've tried the poconflicts tool from Translate Toolkit, but
I find the out put of the above easier to review.

Regards,

cjl