Hi Tony,
I guess I may have jumped the gun slightly
and perhaps should have verified and clarified my thoughts further before
sending them.
Your described approach will indeed
work in the absence of text, though I still think it is somewhat inelegant.
This is mainly due to the fact that the source information for translation
is contained in the <trans-unit> as opposed to the <source>.
Also I consider an empty <source> to be misleading and un-intuitive.
However, its much to late for this discussion
now, especially in the light of Doug's recent proposal to solve the 'reformat'
requirement.
Regards,
Mark Levins
IBM Software Group,
Dublin Software Laboratory,
Airways Industrial Estate,
Cloghran,
Dublin 17,
Ireland.
Phone: +353 1 704 6676
IBM Tie Line 166676
Tony Jewtushenko <>
24/01/2003 15:44
To
Mark Levins/Ireland/IBM@LOTUSINT,
cc
Subject
Re: [xliff] reformat discussion
Hi Mark and all:
"XLIFF does not currently provide a mechanism for
the localization of localizable data in the absence of text. It is
also inelegant and unintuitive in its approach to modifiable data
associated with text and lacks the ability to indicate the presence
of modifiable or, more importantly, non-modifiable data".
Unless I'm missing something, XLIFF already provides
an adequate means for localizing localizable data in the absence
of text. If a trans-unit is marked as "translate=no",
and the source and target are left empty of text (ie,
absent of text), then why can't the coord, style, css-style,
etc., attributes be specified at the trans-unit (indicating source value) and,
if different, the target (indicating localized value) level?
Some of this issue was covered by the recent xliff comments
mailing list discussion, but I thought the only issue remaining
unresolved is identifying attributes that could or couldn't be changed
in the target. There were some additional discussions about defining
standard profiles to be used as templates for specific resource types,
but that doesn't specifically preclude support for "localizable
data in the absence of text".
Can you please expand on your statement? We (at
Oracle) make frequent use of text-absent trans-units,
and once the reformat issue is resolved (per, say, Doug's
suggestion) I don't grok any remaining limitations that would
limit XLIFF from supporting any "localizable data in the absence
of text". In fact, the solution is quite elegant and easy
to read, in my opinion, and I'm not sure that significant architectural
changes at any point in the future would improve it. Why doesn't </source
translate="no"></target coord=x,y,x1,y1> work?
Regards,
Tony
----- Original Message -----
From: Mark
Levins
To:
Sent: Thursday, January 23, 2003 6:00 PM
Subject: [xliff] reformat discussion
Following the recent emails from Yves, John and Matt (via
Tony) and Tony I figured I'd add a few of my own thoughts...
Both Yves and John have tabled very strong arguments
for the deferral of the changes to our next major release. I fully
agree with the need to get XLIFF out there and published formally as soon
as possible. However, in the light of the amount of time it has taken to
'rubber-stamp' XLIFF 1.0 under the umbrella of OASIS as XLIFF 1.1,
I am concerned as to when the specification might formally address
the problem of localization of non-linguistic data. Somehow we managed
to overlook this requirement in the original specification and this
omission is also out of line with our mission statement. I would
very much like to include a new method for handling meta-data in
XLIFF 1.1 as I see it as providing for richer support of the whole
localization process than just 're-formatting'.
John mentioned that the problem we are trying to
address has not been properly formally expressed. This is how I would
state it: "XLIFF does not currently provide a mechanism for the localization
of localizable data in the absence of text. It is also inelegant and
unintuitive in its approach to modifiable data associated with text and
lacks the ability to indicate the presence of modifiable or, more
importantly, non-modifiable data".
Extending then from Matt's recent reformat summary
I think we can use a slight variation of option 4 as stated in his
mail (i.e. 'Combined'). I would like to use more intuitive naming
though, for example, something along the lines of <extended-source>
and <extended-target> or <ex-source> and <ex-target>
etc instead of <source-info> and <target-info>.
Matt had stated that this option would require the
most complex schema definition but I don't think that there's any
real obstacle here.
I have included a modified excerpt from the schema for
the <trans-unit> element to demonstrate that the changes are
not exorbitant.
<xsd:complexType
name="ElemType_trans-unit">
<xsd:sequence>
<xsd:choice>
<xsd:sequence>
<xsd:element name="source" type="xlf:ElemType_source"/>
<xsd:element name="target" type="xlf:ElemType_target"
minOccurs="0"/>
</xsd:sequence>
<xsd:sequence>
<xsd:element name="ex-source" type="xlf:ElemType_ex_source"/>
<xsd:element name="ex-target" type="xlf:ElemType_ex_target"
minOccurs="0"/>
</xsd:sequence>
</xsd:choice>
...rest of sequence removed for brevity
</xsd:sequence>
<xsd:attribute name="id" type="xsd:NMTOKEN"
use="required"/>
... removed attributes for brevity ...
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
Finally, as I've just received Shigemichi's mail,
I would like to second his thoughts and change my previously stated
preferred option from #2 to #4. I also think Shigemichi summarizes
the backward/forward compatibility issue very well and the combined
option fits here (IMHO).
Regards,
Mark Levins
IBM Software Group,
Dublin Software Laboratory,
Airways Industrial Estate,
Cloghran,
Dublin 17,
Ireland.
Phone: +353 1 704 6676
IBM Tie Line 166676
