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
