Title: Message
Hi Bryan,
Thank you for your input. I am definitely
interested in hearing your opinions. Would you mind providing the reasons why
you disagree with 4 and 5?
Thanks,
Magnus
From:
[mailto:]
Sent: Friday, September 23, 2005
9:50 AM
To: Magnus
Martikainen; ;
Subject: RE: [xliff] Suggested additional
changes for XLIFF 1.2
Hi Magnus,
These are all thought provoking.
I agree with 1, 2, and 3.
I disagree with 4.
And I strongly disagree with 5.
Perhaps these points are worthy of some
debate. I have my opinions, but I'm willing to hear more.
Thanks,
Bryan
-----Original Message-----
From: Magnus
Martikainen [mailto:]
Sent: Tuesday, September 20, 2005
10:51 AM
To: ;
Tony Jewtushenko
Subject: [xliff] Suggested
additional changes for XLIFF 1.2
Hi Tony etc.,
Following up on the conference call today, here are my
suggestions for additional changes of the XLIFF 1.2 specification:
1) The following attributes seem to be used only for file
format specific purposes. I propose deprecating them, as we should rather use
the extension mechanism for such things:
extradata
menu
menu-option
menu-name
coord
css-style
style
exstyle
extype
In addition to this I have the following proposals:
2) The name attribute for <context-group> is currently
marked as REQUIRED. (The specification indicates that this attribute should
only be used for processing instructions.) I propose to relax this rule and
allow the name attribute for a <context-group> to be optional.
3) I propose to add an extension point at the <xliff>
level. This would be useful for providing information that is common to all the
files in the XLIFF document. Some examples of what this could be used for:
Job / project information
Contact details
Tool settings
Copyright information
General instructions,
Embedded style guides
Analysis reports
Pricing information
4) I propose to deprecate the <sub> element in
favour of using the xid attribute and putting the embedded
translatable content inside a separate <trans-unit>. Reasons:
The two mechanisms are used for
the same purpose.
The xid mechanism is superior
to the <sub> mechanism.
The <sub> element content
disrupts the text flow. It requires tricky special processing by XLIFF
compliant tools, and can also be distractive during translation. Removing
it will make it easier to create good XLIFF compliant tools.
The content of the <sub>
is a separate unit for translation, and as such is much better represented
in its own <trans-unit>.
More context information can be
provided for a separate <trans-unit>. E.g. length restrictions for
the embedded content can be expressed.
Keeping the embedded
translatable content in a separate <trans-unit> will yield better
recycling. Both the surrounding text and the embedded content can be
treated as separate units. One can be re-used if the other changes, and if
the same embedded content appears in different text it can be re-used
independently.
5) I propose to deprecate the restype attribute in
favour of using the <context> element to provide context
information. Reasons:
The two mechanisms serve a
similar purpose and can be used for the same thing. Providing two ways to
do the same thing makes interoperability more difficult.
The <context> mechanism
is more powerful than the restype attribute
The restype values in the
current specification are highly file format specific.
If multiple contexts apply it
is not clear if one can specify more than one value for a restype
attribute.
Best regards,
Magnus Martikainen
