[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: newdriftbok German translation



On Monday 28 March 2005 21:03, David C. Weichert wrote:
> Hi everyone,
>
> Manuela and I started translating the Newdriftbook. Based on Version
> 1.73 of newdriftbok.en.sgml as found in the CVS
> http://developer.skolelinux.no/cgi-bin/viewcvs.cgi/skolelinux/www/dokumen
>tasjon/newdriftbok/. We will later do diffs with the version current then.
great

> We are *not* using PO and Makefiles, instead we successfully used the
> Docbook XSLT Stylesheets to generate HTML and PDF previews. 
use of XSLT Stylesheets to generate the html and pdf versions is orthogonal 
to use of po and makefiles.
-> there's no reason not to use both (and several to do, see below)

> We think 
> this makes translation of large documents easier. So far we have
> translated the preface and first chapter to German.
>
> If you are interested in what we have so far please send me an email and
> I will send you a .tgz with the current version. To help coordinate
> collaboration in the future, the use of CVS would be great:
received that, will commit it later.

> BART and CHRISTIAN please tell us your preferred procedure!

preferably it goes like this:
1) master-xml-file (english) is created/updated
2) .pot file is (re)generated from new/updated master-xml-file, and is 
msgmerged with existing po-files (this means translators don't have to 
manually keep track of changes to the english version, the po-file will 
tell them what has changed, what's new, and what's gone -> _major_ feature)
3) translators update they're po-files
4) translated xml-files are generated from the po-file and master-xml-file
5) other formats are generated from the existing xml-files

(NOTE: the below make commands are obviously specific to our makefiles and 
won't work in general)
Somebody changing the master version then needs to do the following:
1) checkout latest 
2) change the english xml file
3) call 'make master-update' 
 -> regenerates the english pdf, html, txt, ... versions
 -> regenerates the <documentname>.en.pot file
 -> propagates changes to the po-files
4) checkin changes

Somebody translating then does:
1) checkout latest
2) update the translations in the po file
3) call 'make <langcode>-update'
 -> regenerates the <langcode> xml version from the po-files
 -> regenerates the pdf, html, txt files from the (re)generated xml file
4) checkin changes.

The makefile rules can be adapted to use the XSLT stylecheets to create the 
pdf, and html versions (it currently uses the docbook2pdf/docbook2html 
commands), the command used is orthogonal to the use of makefiles

Same with po-files, use of po-files is not coupled with the actual commands 
used to generate the pdf, and xml versions. 

Reasons for using po-files instead of raw html:
1) this makes it trivial for translators to keep track of what has changed, 
what is new, what is deleted. Without po-files you have to keep track of 
this manually which is a real PITA (we actually used to this for the old 
manual, and we changed it because it basically didn't work)
2) use po-files means that translators can't inadvertently introduce 
xml-errors (well they still can in non-block-level tags, but that still 
eliminates 95% (if not more) of all possible errors)
3) it gives translators a single format to work with for all translations. 
Meaning they can use the same tools for all translations, and don't need to 
be bothered learning about lot's of (ok, several :) different formats and 
asociated tool-sets.

P.S. I'm guessing we're all on the list so no need to CC. Or not?
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
    format mails to a low priority folder (they're mainly spam)

Attachment: pgp8Hde4FGRLO.pgp
Description: PGP signature


Reply to: