[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-comment] XLIFF 2.0 Comments - Ignorable
In my opinion, if there is any tag or atrribute that can be fully implemented with another item (or set of items), then it should be removed, even if it existed in XLIFF 1.2.
I'm thinking in the lines of cases such as "ignorable" being possibly implemented with the translate="no" attribute, or the "approved" attribute that can be better implemented with states. This is just a couple of examples that have been recently mentioned, but there might be more.
If XLIFF is intended to be a nexus, I think that the main focus should be on implementability, not on expressiveness and availablity of options. This means that it is very important to reduce at the very minimum the options available to accomplish the same thing, so that implementations have better chances to work without (too many) flaws.
De: Yves Savourel [mailto:email@example.com]
Enviado el: miércoles, 29 de mayo de 2013 20:22
Para: 'Ryan King'; firstname.lastname@example.org
Asunto: RE: [xliff-comment] XLIFF 2.0 Comments - Ignorable
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.
From: Ryan King [mailto:email@example.com]
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 188.8.131.52 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.