[xliff] Reformat Suggestion for XLIFF 2.0

All,

Despite the suggestion to postpone the reformat 
element in 1.1, I have still been thinking about the issue

I have been doing more work with an xliff 1.0 
implementation for Oracle, and the issue has required numerous untidy 
workarounds.

 

This is therefore a new simpler suggestion for 
2.0.

 

If it as simple as I think it may be, I have no 
objections to reinserting into 1.1

----------------------------------------------------------------------------------------------------------------------

Problem

 

One problem overlooked in reformattable elements or 
attributes, is that any structure that is changed during translation has no 
placeholder to store the original value

 

Say we have some structure that is to be modified 
during translation

 

For example 

    x-value="xxx"

 

During translation this becomes

 

    x-value="zzz"

 

But we have lost the original value of 
xxx

 

New Solution

The idea is that any 
structure that may be translated is enclosed within a reformat 
element

 

<reformat>

    <sourceval>

        
x-value="xxx"

    <\sourceval>

<\reformat>

 

is translated to 

 

<reformat>

    <sourceval>

        
x-value="xxx"

    <\sourceval>

     
<transval>

        
x-value="zzz"

    <\transval>

<\reformat>

 

Any structure not enclosed within a reformat 
element may not be changed during translation, except state etc.

 

If concerned about 
wordiness

 

<rfmt>  

    <sval> x-value="xxx"<\sval>

     
<tval> x-value="zzz" <\tval>

<\rfmt>

 

If a transunit has five reformattable elements, then we need five 
<rfmt> elements. If we tried to put all into one element, we will have 
problems matching up like with like.

 

An advantage is that any structure can be controlled in this way, 
regardless of being XLIFF standard or an extension

 

This is just an Idea. I have not checked to see if 
it is workable within the schema

 

Mat

 

Attachment:
Matthew Lovatt.vcf

Description: text/vcard