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>


Hi Yves,

Yves Savourel said:

> As you have said, the use of <bpt>/<ept> and other XLIFF
> inline elements rather than allowing other namespaces inside
> <source>/<target> is coming from the fact XLIFF is meant to
> handle any format not just XML. Transcribing those other
> original formats into XML is, alas, not always possible. I
> know that currently most of the data I see going through
> XLIFF in real-life projects are non-XML and would not be
> easy to transcribe to XML. Hopefully this will change as XML
> makes progress.

I agree, the thing that bugs me a bit though is that when it comes to XML
data XLIFF currently is not such a good fit because all data is currently
treated the same, as plain text with XLIFF tags in it.

As an example take:

  <b>hello</b> which would get encoded like
  <bpt>&lt;b&gt;</bpt>hello<ept>&lt;/b&gt;</ept>
  (leaving out the attributes)

Trying to check if the translator accidentally switched the b tags is a
lot more difficult then it should be. Special XLIFF tools might be able to
do this but it is beyond the reach of standard schema languages - except
maybe for some XSL based constraints checking language such as Schematron.

> It seems that the case to allow namespaces in
> <source>/<target> is gaining momentum. The TC is currently
> looking at how this could be implement and what rules the
> XLIFF tools could follow to deal with unknown elements.

Rightly so, but I also think that a kind of mental U-turn could still be
beneficial for localization of XML (ignoring tool implementation issues at
the moment). With that mindset the source XML would not be a structure of
unknown elements that are embedded in XLIFF but rather first-class XML
where 'XLIFF' elements/attributes and structures are added to (through an
annotation process). This may have to be a kind of variant because I don't
see how this  could directly fit into the current XLIFF standard. It also
means that this variant would limit itselves to XML only which is
something which may not be feasible for XLIFF proper.

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' vocabulary. 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 translated XML can
be filtered by removing all of the 'XLIFF' namespaced stuff.

In my view the source XML is king and the localization information and
structures are added to it. Maybe it's too drastic for XLIFF or XLIFF tool
implementors but I value the ability to maintain the original structure
and the ability to have localization information live in the same 'space'
with the original XML very highly. It enables us to apply standard XML
technologies on the files more easily. I think adding XML-Namespaces
should definitely be considered. Namespace aware validation is becoming a
little easier nowadays. It's still not easy but it is being worked on very
hard (see http://dsdl.org/).

> Comments such as yours are very important as they help us
> move XLIFF in a direction more in tune with the users'
> needs.

Thanks,

> Kind regards,
> -yves
>

--Marc




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