RE: [xliff] TMX 2.0 does not have an inline element to store content? (RE: [xliff] Wiki Document related to "Generic Inline Markup")

[Yves Savourel <ysavourel@translate.com>]

> I guess complexity and comfort depend on what tools a developer uses. Dealing with nesting is not that
> complicated in my world.  I like to process XML source with XML tools.  That way I stand a better chance
> of not breaking things (or accidentally rendering XML to be malformed). It would be easy enough to write
> a perl script to turn fake markup into markup. But the risk is that the start and end gets miscalculated
> or separated.  That's what I consider complicated and not practical.
> 
> So I guess the question is, are we creating these standards for people with your taste, or people with
> my taste, or both?  If the answer is both, then not supporting the option I so strongly advocate for is
> probably a mistake.

I'm with Bryan for this.

The OOXML is a extreme case. In many formats, the mapping to XLIFF/TMX is much simpler. The way <itag> currently works is reducing
everything to the worst case scenario. And there is certainly a logic in supporting only that: If you have to implement that
mechanism why bother with others type of markup?

I guess it's a matter of scope: People like Rodolfo who have to deal with many very different formats may see the lowest level
solution as sufficient. While others, like Bryan, have a selected set of formats to work with and may need more elegant solutions
because of the tools they are using.

I think XLIFF/TMX/2.0 should cater to both, or at the very least, at this point, explore the solutions that could satisfy both
requirements.

After all: If you don't store the codes in the inline tags all the logic of the worst case scenario collapses.

-ys