[Freeipa-devel] [PATCH] 0079 Update the pot file (translation source)

[Petr Viktorin]

On 09/17/2012 07:59 PM, Jérôme Fenal wrote:
> 2012/9/17 Petr Viktorin <pviktori at redhat.com <mailto:pviktori at redhat.com>>
>
>     On 09/14/2012 09:36 PM, Jérôme Fenal wrote:
>
>         2012/9/14 Petr Viktorin <pviktori at redhat.com
>         <mailto:pviktori at redhat.com> <mailto:pviktori at redhat.com
>         <mailto:pviktori at redhat.com>>>
>
>
>              I pushed the pot manually.
>              Since we have infrequent explicit string freezes I don't
>         think it's
>              necessary to configure automatic pot updates again.
>
>
>         Thanks Petr!
>
>         Actually, having the strings updated on Transifex on a regular basis
>         makes it (IMHO) more manageable for translators to update the
>         translations even before a string freeze. Translating a dozen
>         strings
>         per week is lighter than a mere 339 strings.
>
>
>     A possible problem with this approach is that the translators would
>     see and translate messages that don't make it into the final
>     version. Do you think a more even workload would be worth the
>     occasional extra work?
>
>
> Having some extra work from time to time is OK. Having a huge batch of
> strings to translate on a deadline is uneasy. Especially with day job
> ramping up... ;-)
>
>     I would like to change our i18n workflow/infrastructure. I was
>     planning to (re-)start discussing this after the 3.0 release rush is
>     done. It should be possible to do what you suggest.
>
>
> Cool, thanks.
>
>         I also don't know if pulls from Transifex or push from your side
>         has an
>         effect of keeping memory (in suggestions) of past or close enough
>         strings from the past for small modifications.
>
>
>     Sadly, I don't know much about Transifex itself. Perhaps ask the
>     team there, and request the feature if it's missing.
>
>
> This item is not that important, more a wish.
>
>         Another comment/request, I don't know given my zero-level Python-fu:
>         would it be possible to break down the huge __doc__ strings in
>         plugins
>         into smaller parts, as a small modification would impact a smaller
>         strings, easing maintenance instead of trying to track the one
>         character
>         modification in a 2000 chars text.
>
>         Does Python support concatenations of __doc___ strings?
>
>
>     That is be possible on the Python side. I'm not sure how Transifex
>     (and other translation tools) would cope with text split between
>     several messages -- sorting and filtering the messages could take
>     things out of context.
>
>
> I'm aware of this issue, translators for others languages may raise
> their hands. I could also probe trans at fp.o on that matter, to reach all
> of them.

If the answer is not in a FAQ somewhere, that would be nice.

I have a feeling that the communication between developers and 
translators could be better. It seems like many translators think 
they're given the strings on a silver platter and have to deal with 
what's there, and the developers don't really know the translators' needs.

Thanks for reaching out! We want to help (though changes may be slow, 
and won't happen during a string freeze), and definitely appreciate 
these comments so we can better plan for the future.

> That will nevertheless make changes more atomic, and overall easier to
> manage on the longer term. In the past, changes were just a matter of
> adding one paragraph, or adding one more usage example. Or fixing a
> typo. Which is way harder to spot when you have a 1000 chars strings
> tagged as changed.

Ideally Transifex would show the difference between the old and the new. 
Unfortunately the data's not there to do this automatically :(


For typos, there should be a way to leave the old translations unchanged 
(since the translations won't have the typo).
Gettext has the "fuzzy" feature for this, but it has problems so it's 
turned off for IPA. I'll quote John here (apologies for posting private 
conversation):

 > Never use fuzzy entries. The logic used to select a fuzzy entry is
 > poor, it often picks up entirely wrong translations, they are evil.
 > We've had way too many problems with message catalogs getting
 > corrupted due to the introduction of fuzzy entries. Given that fuzzy
 > entries are so seldom correct and are mostly of value to translators
 > and that translators have a lazy habit of just accepting the
 > incorrect fuzzy suggestion and promoting to a full translation they
 > should not be used at all. I've spent days in the past trying to
 > unwind corrupted files due to the incorrect application of fuzzy
 > translations. I really don't want to do that again :-)

Gettext was designed for delayed communication -- the translators would 
download the file, work for a few weeks, then mail the result back.
There could be various versions of POT and PO files floating around. The 
metadata and logic, including the fuzzy system, was built around that.
With Transifex, there's one version of everything, and we have access to 
the translations as they're written. There might be ways to exploit this 
to make things better.

> Regards,
>
> J.


-- 
Petr³