Re: PO-based Documentation Translation (wa Re: Weekly i18n statusupdate)

[Tim Foster <Tim Foster Sun COM>]

Hi folks,

I took some time to read this thread, and was debating whether or not to
respond, since as yet, I can't give you a better solution than you're
proposing with using .po as your localisation format.

However, I love GNOME (it runs in the family <hi Glynn!>), and want to
help if I can. I've been doing localisation engineering/translation
tools for the best part of 7 years at Sun and would like to offer my
opinion.

> just BTW: XLIFF is for what you first suggested TMX for.

I agree.

> Since you've got to segment stuff anyway to make good use of 
> translation memory content, compendia etc. leveraging and 
> terminology consistency, po's probably the smarter and faster way to 
> go here.


I disagree here. Po format wasn't designed with localisation workflow in
mind - by using .po as your main localisation file format, it'd be like
using a screwdriver to hammer in a nail (i.e. possible to do, but it'd
be much easier to use a hammer !)

That said, I appreciate that you already have tools to process .po
files, and in the absence of anything better, you might be right.

In Sun, we have tools to process po files and output an old legacy file
format, not too dissimilar to XLIFF.

I'm working on migrating these tools to output XLIFF, and also to
support the additional directives that are in GNU .po files (as opposed
to Solaris .po files)

Additionally, we already have XLIFF filters to support docbook sgml,
html, and have a generic xml handler too.

They're not quite ready for prime time yet (though our internal
translation team already use them) and there's work involved for me to
see if I can get the source released to the outside world. I
unfortunately can't promise anything yet, but I feel it's only fair to
mention that we have some tools that could help, if we were able to
release them, which may influence your decision one way or another.[2]

If this is done, you would be able to translate documentation and
software effectively in a uniform manner, and since everything would be
in XLIFF, producing reports for :

* wordcounts
* percentage change from last release
* amount of reused translations across projects

would all be extremely simple.

> If problems of the kind you suggested pop up, it's probably (?) 
> easier solving them by means of segment joining and splitting within 
> whatever tool is used.

I've mentioned this before[1] : we've an article on the advantages of
XLIFF at

http://developers.sun.com/dev/gadc/technicalpublications/articles/xliff.html

(there's an interesting screenshot on that page of an editing
application that I believe could be useful to the GNOME community :
since it edits XLIFF, you could use the same application to translate
files converted from po, html, sgml, xml, etc. Fuzzy matches from
previously translated material (across all formats) can also be shown in
a separate window, with an indication as to where the texts differ)

I apologise for the delay in determining whether these things can
released, and in the meantime, if you choose to go down a route other
than XLIFF, I can't blame you (since I don't have the power to help out
yet)

That said, I would strongly recommend at least considering a format
designed from the ground up to support the needs of localisation. XLIFF
really does fit the bill here imho. We do have technology to allow
translators to translate a range of different source formats in a single
unified manner, and I'm dying to see if you'd find it useful.

hope this helps somewhat ? - my $0.02

(though I imagine it may frustrate more than it helps[1] )

	cheers,
			tim



[1] the response of "Oh, there's that Sun guy ranting about localisation
again, but not actually doing anything constructive to help us in any
way <click delete, read next mail>" is perfectly acceptable.

[2] if I had a few mails in my inbox along the lines of "hey Tim, that
looks really useful, we'd love to try it out : do you think Sun could
send it to us" might help me out