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