On Wed, 16 Dec 2009, Christopher Sean Morrison wrote:
>> I recently tackled this issue with Hydrogen[1]. The long >> story short: using DocBook 4.x XML with poxml from the KDE >> 4 SDK[2] works well... especially if you don't /already/ >> have a bunch of translations of your manual. > > Thanks for sharing your experience there. Can you point me at your po/ > XML source files to see how it looks in your repository? Manual: http://svn.assembla.com/svn/hydrogen/tags/0.9.4/data/doc/ Master source: manual.docbook (English) Processing chain: manual.docbook + manual_ca.po ==> manual_ca.docbook manual_ca.docbook + html stylesheet ==> manual_ca.html There is only one completed translation with the PO scheme, and that's Catalonian: manual_ca.po. The HTML files you see are cached. The idea is to only regenerate them whenever new translation work has been done. > I'm not sure I'd be too keen on a KDE/Linux centric approach (probably > works fine on BSD too), or even the idea of involving a transformed > representation that editors have to work with (the po files). Is it I share this reservation... but it's the only _free_ solution I could find. :-) To reduce the impact on the KDE-centric problem... you only need it for processing the DocBook to the new language. I believe there are plenty of free, cross-platform PO editors... and PO files are text files -- so they can even be edited directly. > some feature of po files that actually make managing translations > easier or is it just a better toolchain interface? 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. 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. 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. However, if you just copy-and-translate... keeping the documents synchronized as the master document changes will be difficult to do... requiring some manner of versioning to manage the synchronization between documents. > simplicity. Given the sheer quantity of existing documentation, > simple is good. We can tailor script to cross validate languages that Imagine that you translate 1M words to Croation. Now you do several minor, but scattered, updates to the master document. The Croatian translator (1 year later) gets some free time and decides to update the translation. 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! With PO files, the Croatian translator will make a new copy of the master translation template (e.g. copy manual.pot => manual_cr.po). He loads the (blank) manual_cr.po into his PO editor. He directs the PO editor to use the /old/ translation as a database. The PO editor then (automatically) matches all the stuff that has not changed. The Croatian translator can then focus on just the things that are new/different. > are partially translated too. Not ideal, but the the vast majority of > effort is with the translators, so that feels like a good starting > point. These are my opinions, of course... and I'm not a translator. So talking to them would be good. By the way, I'm not trying to be overbearing -- just trying to download what I know in case it helps. :-) Peace, Gabriel [1] Not just PO-files. Qt has a similar way that it manages translations for applications, but uses a different file format. Here are the GUI string translations for Hydrogen: http://svn.assembla.com/svn/hydrogen/tags/0.9.4/data/i18n/ The translators edit and submit the *.ts files. Files can be edited with the Qt Linguist GUI app. Note also that Qt Linguist can be used to edit PO files. ------------------------------------------------------------------------------ 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
