RE: [xliff] Revised Committee Draft XLIFF 1.2 Spec

Dear Tony, all,

 

Thanks for the extensive reply.

 

My main concern was not the detail related to segmentation 
support. I was more the general feeling that we might have a challenge to ensure 
that XLIFF implementations clearly indicate what they do support and what they 
don't support.

 

Best regards,

Christian

  

  
  From: Tony Jewtushenko 
  [mailto:] 
Sent: Freitag, 12. 
  Mai 2006 19:14
To: Lieske, Christian
Cc: 
  
Subject: RE: [xliff] Revised Committee 
  Draft XLIFF 1.2 Spec

  

  
 

  
Hi Christian: 
  

  
 

  
That’s a good 
  observation, but the intent of the segmentation support was not to necessarily 
  to provide support for normalizing all segmentation operations or markup for 
  localizable content.  That would 
  be a very much out of scope for XLIFF given the complexity of the task.  Although I haven’t researched this 
  extensively, in the segmentation SC we discussed issues related to this topic 
  and concluded that additional segmentation metadata could be preserved 
  extending by XLIFF with SRX.  
  However, no additional work was done by the SC to illustrate precisely 
  how this could be accomplished, and I suggest that this would again be out of 
  scope for a normative specification.  
  Perhaps we may publish an additional non-normative on segmentation 
  process and markup at some point the future, but that’s out of scope for our 
  present TC objective.

  
 

  
As the segmentation 
  support is purely optional, no data loss would result from ignoring the 
  segmentation markup and working strictly with source / target structures.  So I propose that the spec be modified 
  with some of the language from Magnus, and add a suggestion that SRX may 
  provide additional markup for preserving segmentation 
  rules.

  
 

  
I would appreciate 
  any feedback you have on this matter especially if you have a suggested 
  alternative solution.

  
 

  
Regards,

  
Tony

  
 

  
 

  
-----Original 
  Message-----
From: Lieske, Christian 
  [mailto:] 
Sent: 11 May 2006 
  02:29
To: XLIFF TC
Subject: RE: [xliff] Revised Committee 
  Draft XLIFF 1.2 Spec

  
 

  
Dear 
  all,

  
 

  
I wonder about the 
  repurcussions of phrases like "tool makers can include the spaces in the 
  markup". How will tool 
  users be able to know what a specific tool maker really supports in his XLIFF 
  implementation?

  
 

  
Best 
  regards,

  
Christian

  
 

  

  
  

  
From: Rodolfo M. Raya 
  [mailto:] 
Sent: Mittwoch, 10. Mai 2006 
  19:20
To: Magnus Martikainen
Cc: XLIFF 
  TC
Subject: RE: [xliff] Revised Committee Draft XLIFF 1.2 
  Spec

  
On Wed, 2006-05-10 at 02:17 -0700, Magnus Martikainen 
  wrote: 

  
Hi all, 
  

Regarding point 5) 
  below I would like to clarify that the segmentation markup is entirely 
  optional and does not affect the functionality of the files as XLIFF files. 
  The filter will ignore the segment boundaries when back-converting to the 
  native format, and thus the entire content of the <target> element will 
  be used, including content appearing outside of segments. 

The segmentation markup is intended for 
  tools such as translation memories to optimize recycling of previously 
  translated content, and as such it often makes more sense to not include 
  spaces between sentences in the segments (though that is entirely up to the 
  tools). This does not in any way prevent users from editing the content 
  between the segments, removing spaces or adding additional ones as needed. In 
  fact it is fully allowed (and may frequently happen) that only part of the 
  translated content in the <target> element is part of segments.  
  

The example in point 
  5) attempts to explicitly show this by not including the space characters in 
  the segments (which normally gives better re-use when applying a TM). Perhaps 
  we need to clarify the text in the specification to make that more 
  explicit?

  

Hi Magnus,

Thanks for the explanation. 

I 
  would be happy if the text below the example is enhanced with a sentences 
  stating that tool makers can include the spaces in the markup if desired. 
  
Best regards,
Rodolfo

  
    
    

      
        
          
          

            
              
--
The information in this e-mail is 
              intended strictly for the addressee, without prejudices, as a 
              confidential document. Should it reach you, not being the 
              addressee, it is not to be made accessible to any other 
              unauthorised person or copied, distributed or disclosed to any 
              other third party as this would constitute an unlawful act under 
              certain circumstances, unless prior approval is given for its 
              transmission. The content of this e-mail is solely that of the 
              sender and not necessarily that of Heartsome.