Re: [xliff] Re: XLIFF 1.2 Committee Draft Spec

[Tony Jewtushenko <tony.jewtushenko@productinnovator.com>]

Rudolfo and all:

 

 

Regarding: 

3) <seg-source> is a new element born with old bad habits. It has an optional "ts" attribute that is deprecated. I don't see a reason for adding deprecated stuff to something new.

 

It's a bit messy - yes - but ts was added since all seg-source's sibling structures support it even though its deprecated.  Anyone using sibling structures would probably need ts in seg-source as well.  It seemed logical at the time to maintain similar deprecated support for seg-source.  Remember that deprecated does not mean invalid, just that it will be unsupported in the next big release. I would prefer to keep it as is,  but if consensus goes the other way I'm flexible.

 

Regarding: 

4) <bin-target> has "restype" and "resname" attributes; <bin-source> doesn't. Those attributes are optional in <bin-unit> and I don't see a reason to override in the target something that is not required in the source. Keeping the attributes at <bin-unit> level should be enough, but if for some reason it isn't, the same reasons should be also valid for adding the attributes to<bin-source>

 

For resname,  there may be instances where language specific binary content may need require a different different identifier than the source language (ie.,  help_button vs. help_button_de,  etc).  And since source content metadata, be it  source or bin-source may never be modified by a translator - only the target - we should not extend support to override the bin-source metadata.  This same override paradigm applies to trans-unit/source/target. 

I'm firm on keeping resname as it is presently defined now for bin-target/bin-source.

 

As for restype,  I'm less firm but I have had real-life instances where a restype has changed for some binary content for specific languages- for example,  where graphical binarry source content was provided as JPG files and is returned as PNG or GIF files.  There would be little if any equivalent for textual content.  My opinion is to keep it as it is now.