|
Hi
all,
I like
Doug's last proposal too. If it answers Mat's requirements it would allow us to
move forward and have a 1.1 where the reformat problem would be addressed
without a major re-hauling of the structure.
For
localizable data without text, I think I would concur with Tony. RC files
are good examples of documents with such data and so far I haven't seen any
problem that would require a major structural change. It's sure not very
elegant, but I'm afraid we have given up on XLIFF grace some time
ago.
The
only thing I can think of for complex data is that I'm not sure we do have all
the attributes we would need to represent all the different properties of a
given resource, especially beyond RC files (color was mentionned, and I think I
recall some options in RC's menuex that might be also somehow problematic,
anybody looked at representing Mac or Motif resources in XLIFF?). This is why
maybe having more work done on those profiles (how various formats are
represented in XLIFF) before closing a revision heading for being formalized as
an OASIS standard would [have] be[en] nice.
kenavo,
-yves
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 -----
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
|
|