Re: po vs. xliff

["Stephen Holmes" <sholmes novell com>]

At Novell, we've had up to 23 localisable file formats in the past due
to the diversity of platforms and technologies that we've supported. 
Most recently  we've used XLIFF in two key areas...

1.  As a container for software messages.  Development produce message
strings as XLIFF and we (localisation) use our internal localisation
tools process this XLIFF for 
     translation, validation and target file generation.  

     Is there any difference to using XLIFF to PO?  Yes, absolutely,
XLIFF captures workflow in the process as well as well structured
contextual information, historic translations,
     content and structure separation etc.  There are lots of benefits.
 It's still just a container though, you could achieve similar results
with PO files using custom comment tags, 
     but IMHO it's not as clean/.  Our translators do not ever see
XLIFF, they see the content for translation through a tools interface. 
We liken XLIFF, in this instance, to data
     in a database.

     and 

2.  As a native resource file format.  In this instance, we use an
XLIFF-lite in which the XLIFF simply replaces the .properties or .po/.mo
file format.  This has been very
     successful for is in a cross-platorm environment because we use a
UTF-8 encoding and 1 stand format based on XML.  Personaly, PO or
.properties does the same, but
     the benefit for us with XLIFF is that we don't have to change our
tools to use this subset.

In GUI space, I'm enamoured with XUL (ref: Mozilla) and would caution
the use of XLIFF in the UI space.  XLIFF is a container format that
would require a mapping from the source content and back again when the
translations are complete.  The benefit of XLIFF is that translation
tools would only ever need to work with XLIFF (meaning the more effort
is spent on the functionality/productivity of the tool rather than the
support for multiple formats).  Mapping from XLIFF to other formats is
relatively straightforward with canned stylesheets written in XSL.

Our documentation, based on SGML, is a very mature process and in
localisation we frequently get 80% leverage using a combination of
internal tools and translation via Trados.  We're not investigating
XLIFF for documentation right now, but I suspect we will be soon.


Don't know if this helps - I'm looking at doc/PO loclalisation to try
and get my head in the space.

Cheers
S.



>>> Tim Foster <Tim.Foster@Sun.COM> 01/10/2003 18:37:13 >>>
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


_______________________________________________
gnome-i18n mailing list
gnome-i18n@gnome.org 
http://lists.gnome.org/mailman/listinfo/gnome-i18n