Re: po vs. xliff

["Elros Cyriatan" <cyriatan fastmail fm>]

On 01/10/2003 at 18:37:13, Tim Foster wrote:
> 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.

Will the work on the software message side become public once it's ready?
And if so, what types of adaptions are these, and what kind of time frame
should I think about (weeks, months, years?)?

>
> >  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.

That sounds like a very good solution!

> > 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 ?

About RTL writing: of course, you're right.

> > 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)

Ah, that sounds very good (flexible).

> >
> > 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.

Ok, that clears things up, thanks. That would make it much easier to
(possibly) gradually convert from PO to XLIFF as source format.

> > 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.

I see, thank you for the information, it clears up the matter.

>
> > (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.

Certainly. What do you mean with the last sentence? Do you mean that
PO files are used as a temporary intermediate format and that they
will disappear once the tools are ready?

> >  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 !

-- 

  Elros Cyriatan
  89D0A011957D96020E7D1D16B37D496E440D660A