OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff-comment] re: How to embed XML in <source>


> ...but I also think that a kind of mental U-turn could
still be 
> beneficial for localization of XML (ignoring tool
> issues at the moment). With that mindset the source XML
> not be a structure of unknown elements that are embedded
> XLIFF but rather first-class XML where 'XLIFF'
> and structures are added to (through an annotation

I'm in a complete agreement with you on this. XML itself
would be better serve (providing the tools catch up) with a
different paradigm than XLIFF. I'm very much in favor of
using a specialized namespace for localization directives
within any XML document. 

> This may have to be a kind of variant because I don't see
> this  could directly fit into the current XLIFF standard. 

Very true. XLIFF is just a generic solution for 'any' type
of documents. It's not meant to be tuned-up specifically for
XML (or for any other format). The real answer for
localization of XML files lies somewhere else as you
describe it below.

> The big XML localization picture for me currently looks
like this.
> Source XML is annotated using a low-impact annotation
language for 
> localization information and then this annotated XML gets 
> progressively enriched during the localization project
with the 
> elements, attributes and structure from this 'XLIFF'
> Only as much as needed for the project (modular).
> In a light application maybe only the trans-unit, source
and target 
> elements and structure. At the end of the process the
> XML can be filtered by removing all of the 'XLIFF'
namespaced stuff.
> In my view the source XML is king and the localization
> and structures are added to it. Maybe it's too drastic for

> XLIFF or XLIFF tool implementors but I value the ability
> maintain the original structure and the ability to have 
> localization information live in the same 'space' with the
> XML very highly.

You are preaching to the choir :)

I think, to some degrees, XLIFF and that other embedded
vocabulary are separate things (obviously sharing some
elements, functions, etc.). XLIFF being dedicated to provide
a generic solution to text extracted from various formats. I
would envision that once translation tools catch up with
XML, we would directly feed the XML source files to the
tools and let the localization directives inside 'drive' the
process (by-passing the need for an intermediary XLIFF).

You should look at some of the recent developments regarding
xml:tm at LISA (localization Industry Standards
Association). The xml:tm vocabulary aims at implementing the
storage of the translation directly within the XML source
document, much like your view (see
Andrzej Zydron, who developed it, is in the XLIFF TC as well
as at LISA. LISA is currently looking at whether or not work
on this (http://www.lisa.org/oscar/issueDetails.html?id=6).

Another thing is the current re-chartering of the W3C
Internationalization working group. One of the items of work
proposed is ITS (Internationalization Tag Set).
You can see the draft of the charter for ITS here:
It's just a draft, there is no guaranty this proposed work
will happened, but it's still a big step in the right
direction. If things go well, the work on ITS should get
started before new year.
Some early work has been done to try to identify some of the
requirements for such a vocabulary
(see http://people.w3.org/rishida/localizable-dtds/), but we
need to do much more, and when ITS gets on its way it would
be nice to have your participation, or at least your


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]