On Wednesday, December 16, 2009, at 05:07PM, "Gabriel M. Beddingfield" 
<[email protected]> wrote:
>
>Not exactly... that's what POXML does.  POXML breaks up your 
>document into msgid strings (the .pot file).  Translators 
>copy the .pot file to a .po file to start their translation.
>
>Then, POXML will merge the .po files back with your original 
>DocBook... matching msgid strings and making substitutions.
>
>So, you don't have to do any of the breaking-up, manually.

Aha!  That is definitely a huge timesaver then.  I'm definitely liking the 
option more then.

I could see an issue where some technical writer does a review of a large 
document, restructuring and rippling changes throughout, causing tons of msgid 
string changes.  But then I suppose that's no worse or additional effort for 
the translators than if they were file-chunked (other than having the option to 
ignore some of the changes, forking the document).  Sort of sounds like it 
boils down to whether the translations would eventually turn into separately 
managed forks of the English version or whether keeping them tightly in sync is 
a desirable requirement.

The only remaining issues then are the limitations of the 
docbook-to-po-to-docbook round trip, which I see there are a few you've 
documented already.  That and the platform limitation.  I'd want to break out 
po2xml and xml2po from the KDE SDK so they have minimal/no dependencies as well 
as need a few other (command-line) tools to cross-verify languages with the 
english (replicating the GUI tools you mentioned) for comparisons and coverage 
testing. 

Cheers!
Sean


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Reply via email to