Title: Message
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
