RE: [xliff] translate and xml:space

["Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>]

Hi Rodolfo, Yves,

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Rodolfo M. Raya
> Sent: den 23 april 2012 02:42
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] translate and xml:space
> 
> > -----Original Message-----
> > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
> > On Behalf Of Yves Savourel
> > Sent: Sunday, April 22, 2012 5:57 PM
> > To: xliff@lists.oasis-open.org
> > Subject: [xliff] translate and xml:space
> 
> 
> Hi,
> 
> 
> 
> > While working on the library for the toolkit I've run into a few questions.
> > I'm posting on the main TC list because it's affecting more than the
> > inline content.
> >
> > --- translate
> >
> > Currently we have a translate attribute in <unit>. We also have an
> > <mrk translate='yes/no'> possible in the inline content.
> >
> > We need to specify the behavior for the case like:
> >
> > <unit id='1' translate='no'>
> >  <segment>
> >   <source>textA <mrk translate='yes'>textB</mrk></source>
> >  </segment>
> > </unit>
> >
> > Logically I assume the user agent needs to translate 'textB'.
> > Is that the behavior we all agree on?
> 
> 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. 

> 
> > Note that in 1.2 the translate='no' attribute in trans-unit has been
> > used to "lock" the <trans-unit>. Since there was no relationship
> > described between translate='yes/no' and protected='yes/no' that was not
> incorrect.
> > So my other question is: Do we need another attribute in 2.0's <unit>
> > that would "lock" the unit in read-only mode regardless of its translate
> status?
> 
> 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. This often lead to proprietary extensions
or semantics. If something is translatable or not should be a linguistic decision. If
It is locked or not is a process decision. A common case is that a file starts with some
content set to translate=no. Then it is auto translated against a TM and all perfect
matches are locked (in 1.2 by setting translate=no or proprietary way). Now it is
hard to tell the two things apart in a tool neutral way.

If we do not have a separate 'lock' attribute we should definitively define a 
state/state-qualifier pairing that means locked, or some other un-ambiguous 
solution separate from 'translate'. Looking at the draft we do not
have any state metadata in the core at the moment. It looks like this might be
covered by http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-TranslationState.A.28Y8.29TranslationState . I'm not sure if the locked state would 
be better in core though.

> > --- xml:space
> >
> > Currently we have xml:space on <source>/<target>. There are cases like
> this:
> >
> > <para>Text <span xml:space='preserve'>[  ]</span></para>
> >
> > 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 would disagree on this. All inline spanning elements in <source> and <target> must 
use the same xml:space semantics as their container. That is currently <mrk> and <pc>.
The reason for this is that they must be able to span an arbitrary portion of the content
in their container, and if they do not have the same space preservation semantics that
get difficult.

Regards,
Fredrik Estreen