OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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. 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. 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 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)

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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]