OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC