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] ref value in translation candidates module element <mtc:match>

Hi Yoshito,

I know at least two implementations that support pointing "ref" to the "id" of a <segment>. Stating that it is equivalent to pointing to the "id" of a <mrk> element that encloses all <source> content might be the best option.

I'm not happy either with allowing <pc> as a holder of annotated text. I just mentioned it because it is a valid container for text spans. 

In any case, we need to fix all "ref" attributes providing better examples. 

Rodolfo M. Raya
Maxprograms http://www.maxprograms.com

-------- Original Message --------
Subject: RE: [xliff] ref value in translation candidates module element
From: "Yoshito Umaoka" <yoshito_umaoka@us.ibm.com>
Date: Tue, April 06, 2021 7:41 pm
To: "Rodolfo M. Raya" <rmraya@maxprograms.com>
Cc: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>

Hi Rodolfo,

>I think we need to modify current specs and clarify the three different "ref" attributes.

Yes, I agree.

> 1) if the <source> in <mtc:match> matches the whole <source> of a <segment>, "ref" should point to the "id" of that <segment>

I think we should be careful about this. As far as I know, examples found online and the book "A Practical Guide to XLIFF 2.0" (you're co-author!) use <mrk> to annotate entire source segment, and <mtc:match> refers to the <mrk> annotation. I could not find any examples pointing to segment element except broken example (missing #) in XLIFF 2.x spec. So, I suspect someone who uses the translation candidate module assume <mrk> annotation must be used. I can imagine some implementators may prefer to use <mrk> annotation for this purpose. I think we probably just state that pointing to segment is equivalent to pointing <mrk> element enclosing entire <source> element value in the segment, and avoid "should point to the "id" of that <segment>".

> 2) If the <source> in <mtc:match> matches a fragment in the <source> of a <segment>, "ref" should point to the "id" of the <mrk> or <pc> element that encloses the matched text.

I personally don't like to allow <pc> here. I feel it's just not practical, and introducing extra complexity. If we allow <pc>, we may also allow any kind of <mrk>, not limited to type="mtc:match".

>I'm ignoring the case where the <source> of <mtc:macth> points to the whole content or a fragment of <target> in <segment>. I don't think this should be allowed but there may be some use cases.

Right. I don't think many people including me to <mtc:match> pointing to a fragment of target segment. But I can imagine legitimate use case - For example, if a tentative translation is provided, and the translation is already used for different source text in the past, then translator may change translation to distinguish one from another. In general, I agree that this use case is practically ignorable.


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