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 t hat 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