RE: [xliff-inline] 1.16 Inline codes should have a way to store information about the effect on the segmentation

[Yves Savourel <ysavourel@enlaso.com>]

Hi david, all,

> ...I would think that segmentation-related information 
> in inline elements should be defined with a separate 
> attribute and not combined with an existing attribute.
>  For example: 
> 1. A way of defining an inline XLIFF element as 
> causing a break in the segmentation. 
> 2. A way of defining that a period is not a sentence 
> delimiter (i.e. product -unique abbreviations). 
> 3. A way of defining that an inline XLIFF element 
> should be handled as whitespace.

I'm not sure #2 is relevant directly to XLIFF. My guess is that things like that may be better stored in whatever segmentation rules the system is using.

For #1: sounds good. Something like break='yes' or whatever.

For #3: I suppose that could be use for content where things like tabs are seen as inline codes, etc. We may also want something to indicate that a code should simply be ignored. This relates to the equiv attribute we have. Are we being redundant here?

As a general note, I'm a bit worried about implementation for segmentation using XLIFF itself. XLIFF is by definition just a transport format. I'm not sure how those information can be easily taken into account when actually executing the segmentation, except if the tools internal format on which the segmentation rules are applied is also some kind of markup itself. But that's a different issue.

-ys