Subject: RE: [xliff-comment] XLIFF 2.0 Comments - Ignorable
Yes, you can see it that way indeed.
You are probably correct that a segment with translate=’no’ is a better idea to encapsulate my use case. But with your explanation below, it seems that <ignorable> overlaps somewhat with <skeleton>, which is where I would expect non-modifiable codes and spaces should live. It seems that you are suggesting that <ignorable> is used like a sort of inline <skeleton> in order to give some kind of view or context between modifiable segments, is that right?
Yes, I suppose non-translatable text could be there too.
But maybe it would be better off in a segment set to translate=’no’.
I would tend to see ignorable used to store codes and whitespaces.
One also has to be careful with some languages where spaces between sentences is modified.
The ignorable element can have source and target, but it may be easier to deal with those within the segment.
I guess XLIFF has to offer support for the various cases.
So is the use case I mentioned below also valid? I’m still not sure users will understand what <ignorable> is to be used for based on the specification alone.
The content parts here are the whitespace between sentences.
Honestly, I don’t quite understand the use of the <ignorable> element. Since it can hold <source> and <target> it seems like it would be a good mechanism to contain text which could be localized at one point, but shouldn’t be at this particular point and is included purely for context (e.g. surrounding content) to a <segment> that should be localized, but I’m not sure because there is no real example given for it in section 184.108.40.206 and the example that is given in section 2.8.1 still doesn’t make its use clear to me:
Content parts between segments are represented with the <ignorable> element, which has the same content model as <segment>.
I’m not sure what “content parts” means here.