[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-comment] XLIFF 2.0 Comments - Ignorable
|
I tend to agree with Josep on this statement. From: Josep Condal [mailto:pcondal@apsic.com]
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.
Regards, Josep. De: Yves Savourel [mailto:yves@opentag.com]
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. -ys From: Ryan King [mailto:ryanki@microsoft.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. Ryan From: Yves Savourel [mailto:yves@opentag.com]
The content parts here are the whitespace between sentences. -ys From: Ryan King [mailto:ryanki@microsoft.com]
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 2.2.2.7 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>. For example: <unit id="1"> <segment> <source>First sentence.</source> <target>Première phrase.</target> </segment> <ignorable> <source> </source> </ignorable> <segment> <source>Second sentence.</source> </segment> </unit> I’m not sure what “content parts” means here. Thanks, Ryan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]