On 09/14/2012 09:36 PM, Jérôme Fenal wrote:
2012/9/14 Petr Viktorin <pvikt...@redhat.com <mailto:pvikt...@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.
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?
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.
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.
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
Freeipa-devel mailing list