Re: [xliff] Reformat Suggestion for XLIFF 2.0

Mat & Mark & all: 

 

In principle I'm opposed to 
adding requirements to the 1.1 spec or revisiting previously actioned upon 
recommendations.  However,  
if implementation is truly is as straight forward as Mat 
indicates in his mail,  then perhaps we should consider it, since we 
originally removed the requirement from consideration due to 
reasons of complexity.

 

Hence,  I've added the item to the issues list 
for discussion at tomorrow's meeting. Mat 
can make his pitch at the meeting,  but the item can subsequently be 
quickly and easily moved out of consideration for 1.1 by a motion from the 
floor.

 

Regards,

Tony

 

 

 

  
----- Original Message ----- 

  
From: 
  Mark 
  Levins 

  
To:  

  
Cc: XLIFF list 

  
Sent: Friday, November 29, 2002 1:04 
  PM

  
Subject: Re: [xliff] Reformat Suggestion 
  for XLIFF 2.0

  

Hi Matt, 

Is the mechanism whereby the formatting attributes in 
  <trans-unit> can be specified as the original values and overridden in 
  the <target> not sufficient? 

I think also that your proposal would also require moving all 
  formattable-type information into dedicated elements to work, for example we 
  would have to deprecate attributes such as 'coord' and create a coordinate 
  element to fit within a <reformat> element. While I consider this to be 
  in no means out of the question, I don't think we can use this approach for 
  1.1. 

Regards, 
Mark

  
  Mark Levins
IBM Software Group | 
  Dublin Software Laboratory | Airways Industrial Estate | Cloghran | Dublin 17 
  | Ireland
Phone: +353 1 7046676 | IBM Tie Line 166676 
  
  
  

  
    
    

      "Matthew.Lovatt" 
        <> 
        
29/11/2002 13:00 

      
        
          
          

            
              
To

            XLIFF list 
              <> 
          

            
              
cc

            
          

            
              
Subject

            [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