W3C home > Mailing lists > Public > public-i18n-its@w3.org > April to June 2006

RE: Inheritance in DITA / XLIFF

From: Yves Savourel <yves@opentag.com>
Date: Sat, 1 Apr 2006 13:24:36 -0700
To: "Felix Sasaki" <fsasaki@w3.org>
Cc: <public-i18n-its@w3.org>
Message-ID: <000001c655ca$4d17fbd0$0300a8c0@Breizh>

Hi Felix, all,

> You mentioned at the editor's call the difference of inheritance 
> in DITA  / XLIFF versus ITS.
> I had a short look at
> http://www-306.ibm.com/software/globalization/topics/dita/transdtd.jsp
> and my impression is that it is the role of defaults from the 
> general DITA DTD or a a specialized one is which you were mentioning.
> Do you have the impression that ITS does s.t. different than DITA 
> / XLIFF, or is it just s.t. "additional"? If the later is the case, 
> we don't need to restructure our inheritance / default descriptions, 
> but just add s.t. for translatability, e.g.

=== For XLIFF:

I think we are OK. Because there are no translatable attributes xliff:translate ends up working like its:translate.

=== For DITA: 

I'm still trying to figured out the behavior of DITA's translate. The case of declaring translate='yes|no' in the DTD as illustrated
in the article you read should be OK (as long as the translation tools can process the DTD, which is not a given, but that's not
ITS's problem).

I think the issue will come from the translatable attributes. A <whatever translate='no'> is a bit like the <del> of XHTML: a user
would expect that no attribute usually translatable stays translatable if it's within a <del> element. So it is a bit different from
a pure its:translate scope. In the case of ,del> we can resolve this by setting "//h:del/descendant-or-self::*/@*" to
non-transltable. And that is the end of it because nothing in a <del> would make us revert back the text to translatable.

But with <dita:whatever translate='no'> we always can have a <dita:whatever translate='yes'> inside, and then comes the crux of the
issue: how to restore translatable attributes to their original to-translate state?

The following example illustrate such case:

<p translate="no">Palouse horses<fn translate="yes">A palouse horse is the same as an Appalosa.<image href="appalosa.png"
alt="Appalosa horse"></image></fn> have spotted coats.</p>

The alt attribute is expected to be translatable.

One can do this:

<its:translateRule its:selector="//*/@alt" its:translate="yes"/>
<its:translateRule its:selector="//*[@translate='no']" its:translate="no"/>
<its:translateRule its:selector="//*[@translate='no']/descendant-or-self::*/@*" its:translate="no"/>
<its:translateRule its:selector="//*[@translate='yes']" its:translate="yes"/>
<its:translateRule its:selector="//*[@translate='yes']/descendant-or-self::*/@alt" its:translate="yes"/>

But solving the problem for all attributes (there are 10 translatable attributes in DITA) may require quite a few rules, or one
quite complicated. I guess this is yet another reason to avoid transltable attributes. The good news is that they (maybe all?) are
becoming obsolete in DITA, replaced by elements.

So, to answer your question: No I don't think we have to re-think the translatability mechanism. It seems we can deal with both
XLIFF and DITA with what we have now.

Received on Saturday, 1 April 2006 20:24:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:07 UTC