OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] Source read only or modifiable?


I disagree with an originating tool being able to express whether alterations to <source> are allowed or not allowed. If it's a part of the agreed-upon standard, it should be allowed with no discussion; if it's not allowed, it should be forbidden. The same holds for re-segmentation - at least a significant part of any leverage lost between tools is because of re-segmentation. If a tool routinely generates XLIFF files forbidding re-segmentation, it's a good way to force users to only use the tools/translation memories/etc provided by that original tool.

I would personally prefer to see file permissions restricted to optional modules / attributes / elements.


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, May 23, 2012 7:20 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Source read only or modifiable?

>>> There should not be any extra element added during the translation 
>>> process. Neither in <source> nor in <target>.
>> I disagree. We must be able to add/remove inline codes in the target.
>> It's a basic requirement.
> Then the tool creating the XLIFF file should be able to indicate 
> whether those additions are acceptable or not.
> This can be indicated with an attribute at <file> level. The original 
> tool should have a way to express that <target> must have the same 
> structure as the original <source> (that should be the default case 
> IMO). It also should be able to express that alterations to <source> 
> are not allowed. And, for completeness sake, it should be able to 
> indicate whether re-segmentation is allowed.

I agree that being able to set different permissions at the file level may be useful.
Permission for adding/removing inline codes can be set at the code level, but a file-level flag could complement (or override that).
Permission to re-segment could be useful too.

I think there is an item in the features list:
That may be related to this.


To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]