On Wednesday, December 16, 2009, at 10:00AM, "Gabriel M. Beddingfield" <[email protected]> wrote: > >Manual: http://svn.assembla.com/svn/hydrogen/tags/0.9.4/data/doc/
Haha, very interesting.. That looks like a very evil abuse of gettext! :) Seriously, though, that's pretty impressive and interesting to think about breaking up the document fully into distinct strings that are compiled together for a given translation. >I share this reservation... but it's the only _free_ >solution I could find. :-) Understandable. Sticking to free solutions is definitely a requisite. Probably wouldn't be too tricky to rewrite a dependency-free po2xml if the portability were even a problem too. >It makes managing translations easier over the long-term >because: > >1. It breaks up your document into smaller chunks. > These chunks get translated one-by-one. While at the same time, it adds the at least initial burden of breaking up a document into chunks in the first place.. It's of course the same amount of translation work, but with a little extra "overhead" markup (the original english msgid and other gettext markup) per translation unit. It is definitely a nice separation of content from the Docbook markup, though, I must admit. I'm certainly having trouble reconciling the effort of breaking out tens or hundreds of thousands of msgid strings even for the original English. *shudder* :) >>2. When you update your master document, chances > are that only a few chunks will change. The > translation work you did on the other chunks > can remain untouched. I think that's pretty much true of the original Docbook too. Even via line diffs, the changes across languages are going to be pretty isolated as strings are still only grouped at best on a paragraph basis. Moreover, file formatting standards could minimize, prevent, or at least help isolate simple formatting changes to indentation/ws/etc. >3. Translators don't have to learn (much) DocBook, > they just translate phrases one-by-one. It's > my understanding that PO-files[1] is part of a > typical (human) translator's work-flow. That is certainly a benefit. Probably the strongest benefit. >He must tediously look through your changelogs to find the >changes so that you can incrementally update your >translations without starting from scratch. He has to >pour over the diffs of the master document -- and pray >that nobody has reformatted/re-indented it! Granted a limitation of the approach, updates will have to be merged but they won't necessarily have to pour over diffs, though. Plus, that's a problem I'd love to have! :) If we ever did get to that point, though, I expecting (or at least want to be prepared for) our authors to be non-technical where they will be working with current processed output (e.g., pdf) for English, their Docbook source file, and a simple process that generates their processed output so they can compare the two manually. This is basically just a slightly larger "chunking" than per statement, instead chunking per document section (which there are more than a thousand of). >By the way, I'm not trying to be overbearing -- just trying >to download what I know in case it helps. :-) I didn't take your comments to be overbearing in the least. I very much appreciate the perspective and details on the approach you've taken. It's a very interesting approach that I think would be interesting, but maybe down the road as we don't even have all of our English documentation even formatted into Docbook just yet and we've been working on that task (passively) for a few _years_. The benefit of the .po approach is that we still have to do what we're doing now on the English side, it just adds more work to break out the phrases. Good thoughts, thanks! 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
