RE: [xliff] Opinion: Need or not for SUB

[Yves Savourel <ysavourel@translate.com>]

Hi Arle, all,

Thanks for providing some detailed examples of the cases that seem to cause concern.

From what I can see the problem seems not to be about how to represent a sub-flow but about deciding whether something is a sub-flow
or not. I believe that decision is a tool decision: Some will decide that an alt text belong to the same segment as where the <img>
element is in, some will decide they are two separate segments.

From the abstract markup view point I can see two things: either alt is a segment or it is not.

If it is not it should be stored in the parent segment without any specific markup.

If it is a separate segment then it should be stored in its own TU.


> Hungarians eat goulash <ref value="All About Hungary, p. 2" /> and fish soup
> <ref value="Hungarian diets, p. 54" />.
> Some tools would consider this bit to be three segments but others one.
> Whatever arguments can be made from a technology standpoint, the *logical*
> argument about whether these should be treated as part of the segment or not
> for translation isn't entirely clear to me. I would prefer it to be treated
> as three segments in some ways, but in other ways that is not a satisfactory
> solution since it abstracts these items from their context and creates
> segments that in isolation may not be entirely interpretable.

I'm not sure what is the difference between that example and one paragraph with 3 sequential sentences? And in that case nobody has
any problem storing the 3 sentences in three different segments.

If tools want to provide context about the parent segment when they offer the value of alt for translation (good for them). But this
should not interfere with a logical storage in TMX.

Looking at the 2.0 TMX proposal, there are a few mechanism that allows to link or group segments together, those could be used to
'attach' the sub-flow segment to it parent.

As far as representing that link directly in the inline codes, with something like your illustration:

Hungarians eat goulash <itag x="1" type="x-reference" sub="1" />
and fish soup <itag x="2" type="x-reference" sub="1" />.

I'm not sure this would be possible: a code may have several sub-flows and then this notation would not work.

I guess my concern here is that tool-specific behavior get to bias the logical way to represent separate segments in an abstract
representation. If anything the problem of referencing sub-flow is much more an XLIFF issue than a TMX one.

Also keep in mind that such sub-flows could be a big set of several paragraphs containing several sentences (e.g. footnote in ODF).
Representing this with <sub> would be quite strange.


I also an interesting example:

Imagine a format that is like this:

<p>Hungarians eat goulash <ref value="allAboutHungary"/> and fish soup
<ref value="hungarianDiets"/>.</p>
...
<defs>
 <def id="allAboutHungary"> All About Hungary, p. 2</def>
 <def id="hungarianDiets"> Hungarian diets, p. 54</def>
</defs>

Would that means we would have to use <sub> to represent this as well?
I think nobody would want to do that.

The conditions are the same for the tools: Linking somehow the references and referents is still as important here than in your
example. But should TMX enforce some kind of referencing mechanism for this case? I think it should provide the means to implement
it for the smarter tools. And that same mechanism should be used for the sub-flows.


So to summarize my thoughts:

- if something is deemed a segment (sub-flow or not) it should be stored as such.

- yes sub-flow should have some referencing mechanism so the parent can point to its different sub-flows, but that should be a
*referencing* mechanism, not an embedding one.


Cheers (and enjoy Taiwan :)
-yves