RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

> We should say something like
> Matches for a source element MUST NOT be trimmed until its target 
> element is populated with translation.
> Matches for a source element SHOULD NOT be trimmed until its 
> target element is marked final.

No. You cannot come up with PRs that cover all use cases like that.

Take this customer of ENLASO: They send us XLIFF documents with the source and no target and 5 different entries for alt-trans. Each for a different language.
Their logic is: We just have to create one XLIFF and you send us 5 back; sometime the alt-trans for language ABC could be helpful for the translator XYZ.
It's logical. But it makes makes the file humongous and we can't work with it. So we create one file per language with the corresponding alt-trans.

With PRs like the one above we could not do technically do it.
We obviously would do it anyway.

My point is: Let's not define PRs users may have to be forced to not respect. It's as bad has not having any PRs at all like in 1.2.

Regards,
-yves