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