Re: po vs. xliff

[Tim Foster <Tim Foster Sun COM>]

Hi Elros,

On Wed, 2003-10-01 at 17:56, Elros Cyriatan wrote:
> Is XLIFF better suited for GUIs?

Not exactly - it can do both.

Some folks out there are using XLIFF for windows resources, and as such,
there are special parts in the XLIFF spec to cope with that. It works
well for both software and docs translation - and there's examples on
the web for both uses.

Right now at Sun, we use XLIFF primarily for docs translation, but are
working on software formats (we had existing tools for software message
processing since they were relatively easy to write)

With the advent of XLIFF, we were able to start looking at docs --
having solved that problem now, we're going back on the software message
file side, and fixing that too.

>  I've seen the proof that it's possible with PO, but
> really only with a hack. (I mean that strings identical in content are assumed to
> be identical in meaning, so that hacks like File->New are needed.)

Each string can have a context associated with it - so you could tell
that two instances of the same text could have different contexts, and
as such, may need to be translated differently.

> How does XLIFF work with plurals and `difficult' language properties, such as
> declinations and right-to-left writing? And without adding too much work for
> languages that don't have these hard properties?

I don't think it has anything new to offer here. What's difficult with
left to write writing : isn't that just a function of the output method
system ?

> Does XLIFF provide smart ways to prevent formatting problems (in the sense of
> printf formatting codes)? I've read that the lack of this in PO is a disadvantage,
> so I assume the answer is yes. (If so, how does it do this, in source code?)

Yes ! This is one of the good parts of XLIFF - you can mark sections of
text in a certain way as being untranslatable, or requiring special
treatment : that's something you can't easily do in po. In particular,
have a look at the <mrk> element in the XLIFF 1.1 specification at 
http://www.oasis-open.org/committees/xliff/documents/xliff-specification.htm#mrk

or the ept, bpt it elements for protecting xml-like elements from
translation.

As a consumer of XLIFF documents, it's great to be able to instantly
spot the formatting of a source sentence and take the appropriate action
(writing tools that use XLIFF can just work off these formatting
elements and don't need to be po-aware,sgml-aware,mif-aware or whatever
other source format the XLIFF document was abstracting)

> 
> If it's not simply converted to MO files:

No you're right, after translation, we convert back to the source
format, whatever that may be and the build process remains as normal.

XLIFF is a container format that's used to abstract various l10n source
message and document formats to make life easier for the translator,
rather than the source format of a whole other i18n framework (god
knows, we don't need any more of those!)

Quoting from the XLIFF spec (XML Localisation Interchange Format)

"The purpose of this vocabulary is to store localizable data and carry
it from one step of the localization process to the other, while
allowing interoperability between tools."

It's design was to make the localisation process easier by getting
placing the burden of understanding source file formats, such as .po,
.java resource bundles, sgml, xml onto the tools developer and letting
the translator concentrate on the text to be translated.

> I'm personally quite happy with the PO format, but I see its limitations and I'm
> very interested in whether XLIFF can solve them.

The problems will still be there to some extent, but XLIFF is a way of
working around those problems in an elegant manner and was designed with
exactly those problems in mind.

> (although it might be wise to
> have a pilot before actually doing the switch)

Absolutely, you can take some consolation from the fact that we're
working with it at the moment, and will probably be processing po files
before we can get parts of our solution released.

>  In the end, I think it would be preferable
> to have a single format for both messages and documentation.

That was exactly our aim internally at least !

	cheers,
			tim