Re: [xliff] Source read only or modifiable?

["Dr. David Filip" <David.Filip@ul.ie>]

Hi Shirley, all,

looking at the discussion of source as read only or not, I think that clearly at least two different usage scenarios have been uncovered.[1][2]

I fully agree with Shirley that originating tools should not be able to prevent re-segmentation. We cannot prescribe business behavior, but on the contrary we are obliged to enable valid use cases.

[The re-importing receiving tool might however set some segmentation expectations and/or enforce engineering and quality checks on re-import. And often the receiving tool will be the same as the originating tool in two different roles in the workflow. I believe that we should allow for a reasonable descriptive set of re-import checks]

[1] Re-segmentation and source enrichment (annotations as mentioned by Yves) should be considered as valid and potentially desirable operations that should be allowed throughout the process despite their affecting source.

[2] On the other hand changing source in the sense of e.g. removing typos and/or otherwise improving readability/translatability should NOT be allowed *during translation*. Translation should be for that purpose defined as *target editing*, ergo excluding editing changes of source [should not exclude changes of type one however].

Nevertheless, the originating tool should be able to mark a state of a segment. For the described scenarios the required states are only two:

1) preprocessing

2) translation

Of course in general the segment state machine should be more complex and have dependencies with child and parent state machines. E.g. in a segment you should be able to mark separately status of source and target.

(At least manual) re-segmentation should be possible even during the translation proper to allow for translators handling of erroneous sentence breaks and non breaks.

It is clear that segmentation rules are an open ended system that can never be completed via any regular _expression_ engine (because the abbreviations causing exceptions are a productive area in most affected languages)..

Thanks for your attention

dF

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Mon, May 28, 2012 at 3:57 PM, Shirley Coady <scoady@multicorpora.com> wrote:

Hi,

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.

Shirley

-----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:
(http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/PermissionControl)
That may be related to this.


Cheers,
-yves



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