I'd second what Yves says. In addition, with the new translate attribute in HTML5, which will be in ITS 2.0, the behavior Yves describes is the way it works. To require a different mechanism for XLIFF seems a strange state of things. We should be working to unify, as much as possible, some of these little oddities of behavior into consistent models. If we are going to have identically names attributes for basic functionality across different, but related, specs, having them work a bit differently and requiring totally different mechanisms to achieve the same behavior is bad design from a user-centered perspective and it also invites implementers to ignore the mandated behavior in terms of the one that makes sense. So why intentionally implement a behavior they are likely to want to change? I think part of the problem, as Yves and Fredrik point out, is that translate=no can be overloaded for two different functions: (1) don't touch this thing and lock it (for whatever reason) and (2) don't translate this thing because it shouldn't be translated (e.g., it is a brand name or a legal text that applies to only one locale). In the case of the second one, it is entirely reasonable that you might set translate=no for a block but want to set it to yes for some portion of the inside because you are providing instruction to the translator about what to do (e.g., don't translate this except for this one bit). If you are using the attribute to lock the segment, that is a different story, and I agree that it doesn't make sense to lock it but then say that part of it is unlocked, because then you haven't really locked it. So it would make sense to split the functionality and use two different mechanisms because, even though they are similar, they are not the same thing. -Arle -- Arle Lommel Phone (U.S.): +1.707.709.8650 Skype: arle_lommel LinkedIn:
http://www.linkedin.com/in/arlelommel On Apr 23, 2012, at 4:30, Yves Savourel <
ysavourel@enlaso.com> wrote: > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail:
xliff-unsubscribe@lists.oasis-open.org > For additional commands, e-mail:
xliff-help@lists.oasis-open.org >