[Freeipa-devel] i18n infrastructure improvements

Jérôme Fenal jfenal at gmail.com
Fri Jan 11 21:00:16 UTC 2013


2013/1/11 John Dennis <jdennis at redhat.com>

> On 01/11/2013 02:44 PM, Jérôme Fenal wrote:
>
>> 2013/1/11 John Dennis <jdennis at redhat.com <mailto:jdennis at redhat.com>>
>>
>
> Thank you Jérôme for your insights as a translator. We have a lop-sided
> perspective mostly from the developer point of view. We need to better
> understand the translator's perspective.


You're welcome.
I'm not an expert at Transifex though.
I've yet to schedule a lunch with Kevin Raymond (he works a few kms away
from the French Red Hat office) who is coordinating the whole Fedora
translation effort, but customers first, yada yada... :)






     I'm not sure how splitting text into smaller units gives more
>     context but I can see the argument for each msgid being a logical
>     paragraph. We don't have too many multi-paragraph strings now so it
>     shouldn't be too involved.
>
>
> One issue also discussed on this list is the problem of 100+ lines
> strings in man pages generated from ___doc___ tags in scripts.
> Those are a _real_ pain for translators to maintain when only one line
> is changed.
>

I still think TX should attempt to match the msgid from a previous pot with
> an updated pot and show the *word* differences between the strings along
> with an edit window for the original translation. That would be so useful
> to translators I can't believe TX does not have that feature. All you would
> have to do is make a few trivial edits in the translation and save it.
>

I agree with you.
But transifex developers seem to be overloaded at the moment.
I can check with Kevin (and internally) if Zanata would provide a better
home to host the translation effort.


> But heck, I'm not a translator and I haven't used the translator's part of
> the TX tool much other than to explore how it works (and that was a while
> ago).


I can understand that... :)
Hopefully, the IPA dev team is mutllingual ;)

 I'd see a few remarks here:
> - this massive .po file would grow wildly, especially when a typo is
> corrected in huge strings (__doc___), when additional sentences are
> added to those, etc.
> - breaking down bigger strings in smaller ones will certainly help here
> in avoiding duplicated content,
>

 - in Transifex, it is easy to upload a .po onto another branch, and only
> untranslated matching strings would be updated. I used it on ananconda
> where there are multiple branches between Fedora & RHEL5/6 & master,
> that worked easily without breaking anything.
>

When you say easy to upload a .po onto another branch I assume you don't
> mean branch (TX has no such concept) but rather another TX resource. Anyway
> this is good to know, perhaps the way TX handles versions is not half as
> bad as it would appear.


You're right. See how anaconda is organized, for instance:
 https://fedora.transifex.com/projects/p/fedora/language/en/?project=2059

Regards,

J.
-- 
Jérôme Fenal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130111/96452606/attachment.htm>


More information about the Freeipa-devel mailing list