[xliff] Proposed Changes to Reformat attribute for XLIFF 1.1.htm

All

I have (finally) created a more detailed set of 
proposals for the reformat issue

We can discuss the attached document this 
evening

 

Mat

Attachment:
Matthew Lovatt.vcf

Description: text/vcard

Title: Reformat

Proposed Changes to Reformat attribute for XLIFF 1.1

 

In
Xliff 1.0 the reformat attribute of trans-unit specifies that UI related
elements/attributes may be modified during translation.

 

Issues

1       
Unable
to specify which attributes/elements are controlled by reformat flag

2       
No
location for storing translated copy of attribute/element

3       
Unable
to specify which parts of composite attributes/elements are controlled by
reformat tag

 

Possible
elements/attributes affected

1       
Font

2       
Coord

3       
Style

4       
Colour

5       
Extended
style

6       
Alignment

7       
Extensions
from external namespaces

 

The
following discussion is for the coord attribute, but applies to all others.

 

Structure

In
XLIFF 1.0

 

reformat
= “yes”

coord=”x:y:cx:cy”

 

Proposal:
Change the
coord attribute to an element

 

<coord>

<x reformat = “yes|no”>x </x>

<y reformat = “yes|no”>y</y>

<cx reformat = “yes|no”>x </x>

<cy reformat = “yes|no”>y</y>

</coord>

 

We
can now specify the expected content of the coord and validate the content

 

 

Location 

Example from XLIFF 1.0

<trans-unit id="00001" translate="yes"  

coord=”x:y:cx;cy” reformat = “yes”>

<source>Unable to store persistent
object</source>

<target>Unable to store persistent object
translated</target>

</trans-unit>

 

The new coord structure can go in the trans-unit, but we would still
need a placeholder for the translated version.

 

 

Option 1

We
can create two new elements that are siblings of source
and target

 

<source-info>
and <target-info> 

 

 

The
new coord element can only be a child of <source-info> and
<target-info>

 

All UI
related elements are children of these info elements

 

Alternative names 

source-data, 

source-meta-data

 

Example 

 

<trans-unit id="00001"
translate="yes">

<source>Unable to store persistent
object</source>

<source-info>

<coord >

<x reformat = “no”>x
</x>

<y reformat = “no”>y</y>

<cx reformat = “yes”>cx
</x>

<cy reformat = “yes”>cy</y>

</coord>

          </source-info>

<target>Unable to store persistent object
translated</target>

          <target-info>

<coord>

<cx>cx</x>

<cy”>cy</y>

</coord>

          </
target-info>

</trans-unit>

 

The coord structure should also include a
mandatory size-unit and an optional origin attribute 

The origin can be “top-left”, “top-right” etc.

 

Note that in the above example the reformat attributes are not required
in the target-info element. Only those values that get modified are copied into
the target-info

 

 

The above option allows 1.0 files to be compatible with the new 1.1
structures

 

Option 2 

Is
less compatible, but avoids having two elements containing source and
translation information.

 

<trans-unit id="00001" translate="yes">

<source-info>

<text>Unable to store persistent
object</text>

<coord>

<x reformat = “no”>x
</x>

<y reformat = “no”>y</y>

<cx reformat = “yes”>cx
</x>

<cy reformat = “yes”>cy</y>

</coord>

          </source-info>

          <target-info>

<text>Unable to store persistent object
translated</text>

<coord>

<cx>cx </x>

<cy”>cy</y>

</coord>

          </ target-info>

</trans-unit>

 

The
source-info and target-info are again children of the trans-unit, but the
source and target elements are removed and replaced by <text>
elements.

 

The suggestion for the spec is as follows

The elements in the target-info should match
those within the source-info. An xliff compatible tool is only required to copy
modified or all modifiable elements from the source-info-to the target info

 

The reformat attribute is not required in the
target-info, but if present must take the same value in both places, or the
file is considered invalid

 

If a value is specified in both places, it can
only be different if the reformat flag is on

 

All UI related elements are modified in the same
way

Any extended element from eternal namespaces
must also conform to this pattern