RE: [xliff] translate and xml:space

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo, Fredrik, all,

>> That translatable portion should be treated as 
>> a subflow and placed in its own segment.
>> Don't add  a "translate" attribute to <mrk>
> 
> I think we really need the translate attribute 
> on the <mrk> so that it can be used to mark that 
> words or phrases should not be translated. But 
> I do agree that setting translate=no on the unit 
> and then unlocking a small part inside it feels wrong,
> and it is probably better served by breaking 
> that part out as subflow. 

Assuming we have a <mrk translate='no'> to represent non-translatable spans within its content, it would be logical to be able to use <mrk translate='yes'> to represent one or more translatable spans within their content.

We could have cases like this:

a) <p translate='no'>not to translate<span translate='yes'>to translate</span></p>

b) <p><span translate='no'>not to translate<span translate='yes'>to translate</span></span></p>

Representing a) with two units and no <mrk> and b) with one unit and two <mrk> seems inconsistent.

Rodolfo's view of not having <mrk translate='yes|no'> would means to use sub-flows for translatable spans inside non-translatable ones, and inline codes for non-translatable ones.

To me that's misusing both sub-flows and inline codes. But more importantly it makes things very difficult for processes that annotate the content with translate/don't translate information after extraction. They can't create sub-flows for example as it would change the number of units.


>> There is no need to add a "lock" attribute. With
>> "translate" we have enough.
>
> In my opinion having a standard way of locking a segment 
> or unit is important.
> Locking is different from not-translatable.

I would tend to agree those are two distinct functions, and the translate='no' of 1.2 is blending both.


>> That are not currently catered for. I assume we would 
>> need to allow xml:space in <mrk> as well then.
>> Is that something we should do?
>
> Again, treat that portion that requires special space 
> handling as a subflow. 

I think it would be wrong to break apart a sentence because of a stylistic change. If we do that for xml:space why don't we do it for a span of italics inside a non-italics content? While the presence of a change in how spaces should be handled *may* indicate a true sub-flow, there is no way to be sure of it just by that.

Cheers,
-yves