MHonArc v2.5.0b2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: [xliff] Suggested additional changes for XLIFF 1.2
Dear Maguns,
here is my feedback to your suggestions:
1) is fine because these attributes are too specific. But for the WinRes
profile we have to define extended attributes. May be coord is something
that should be generic enough to keep it.
5) I would like to keep restype because it is used heavily in the WinRes
profile and is very handy. I don't believe that it will as easy with
<context>.
For the other points I don't have preferences right now.
Best regards from Bonn,
Florian
-----Ursprungliche Nachricht-----
Von: Magnus Martikainen [mailto:Magnus@trados.com]
Gesendet: Dienstag, 20. September 2005 19:51
An: xliff@lists.oasis-open.org; Tony Jewtushenko
Betreff: [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
<<attachment: winmail.dat>>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]