2013/1/11 John Dennis <jden...@redhat.com>
> On 01/11/2013 02:44 PM, Jérôme Fenal wrote:
>> 2013/1/11 John Dennis <jden...@redhat.com <mailto:jden...@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.
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
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:
Freeipa-devel mailing list