← Prev in month ← Prev in thread

Section 2.6.7 "Target Content Modification" - Split/Merge

From
Jung Nicholas Ryoo <>
Date
2012-12-06T15:42:35+00:00
ID
Thread
Section 2.6.7 "Target Content Modification" - Split/Merge
Our Translation Infrastructure team has some
      concerns on the Section 2.6.7 "Target Content Modification".

    This mail is about one of the the concerns.

      

    Our main comments in blue, and questions in red. (For
    non-HTML mail readers, I used "==>" to start a comment, and
    brackets to mark a question).

    

      The specification says about split/merge actions in the processing
      requirements.

      

      2.6.7.1 Without an Existing Target

    
    
      
User agents may leave the existing target unchanged.  ==> This is contradictory to the title.
            No existing target.

      

      
User agents may split the segment into
          two segments.

      
 User agents may join the segment with the following one.

      

    
    2.6.7.2 With an Existing Target

    
    
      
User agents may join the segment with the following segment

      
==> No PR about splitting
            segments. Does this mean it is not allowed? If <unit>
            has one <segment>, then will it be prohibited that
            agents split the segment? [We would like to prevent any split/merge
            actions by agent. How?]

      

      
User agents may delete the existing target and start over as
        if working without an existing target  ==>

            If an existing target can be deleted, this implies the
            processing requirements in 2.6.7.2 can be completely
            ignored. [How can we
            prevent it?]

      

    
    Content in our translation kits is
      pre-segmented and an agreed processing requirement is that
      segments should not be altered (further split or merged). As it
      stands there is no mechanism at unit level in XLIFF 2 that would
      support our use case/requirement, and we would have to create a
      proprietary extension to ensure our translation vendors would
      support that PR, which implies losing xyz (standardisation,
      interoperability, etc, you name it)

      

      [Suggestions]

    
    
      
Attributes (canJoin, canMerge) at <segment> level to
        prevent changes in the number of segments inside a <unit>.
        By default such changes can be allowed.

        

        Or

      
Alternatively a validation can be designed, but I think this
        approach requires more sophisticated design.

      

    
    

      Thanks

      Oracle
← Prev in month ← Prev in thread