OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
  • 1.  RE: [xliff] ref value in translation candidates module element

    Posted 04-06-2021 20:39
    Hi Yoshito, I think we need to modify current specs and clarify the three different ref attributes. For the ref attribute in Matches module: 1) if the <source> in <mtc:match> matches the whole <source> of a <segment>, ref 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'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. For the optional ref in Glossary module:  * if <gls:term> applies to the whole <source> of a segment, ref can point to the id of the segment.  * if <gls:term> applies to a fragment of text in <source> or <target> or the whole <target>,  then a ref should point to the id of a <mrk> or <pc> element. For the ref in Core module:  * I would allow its use in <note> pointing to the id of a <segment> (any part) or to the id of fragment enclosed in <mrk>. Regards, Rodolfo -- Rodolfo M. Raya Maxprograms http://www.maxprograms.com -------- Original Message -------- Subject: RE: [xliff] ref value in translation candidates module element <mtc:match> From: Yoshito Umaoka < yoshito_umaoka@us.ibm.com > Date: Tue, April 06, 2021 5:08 pm To: Rodolfo M. Raya < rmraya@maxprograms.com > Cc: xliff@lists.oasis-open.org < xliff@lists.oasis-open.org > Hi Rodolfo, >I would differentiate two cases: >1) The match applies to the whole segment Yes, I understand the idea. What I'm not sure is, as I mentioned in my previous message, <segment> is a container of <source> and <target>. It makes sense to point to <source> alone (or <target> alone) to specify relevant text for a match candidate. But if it points to <segment> and if the segment has both <source> and <target>, then suddenly it becomes ambiguous. If we can point <source> or <target>, then it makes more sense, but <source>/<target> cannot have id . If we will refine the specification, and if we really want to allow segment can be referenced directly, then we should explain the semantics. In other words: <mtc:matches> <mtc:match id = tu1 ref = #s1 similarity = 65 > <source> Please check the output. </source> <target> Veuillez vÃrifier la sortie. </target> </mtc:match> </mtc:matches> <segment id = s1 > <source> Please check the results. </source> <target> Veuillez vÃrifier les rÃsultats. </target> </segment> Above is equivalent to <mtc:match id = tu1 ref = #m1 similarity = 65 > <source> Please check the output. </source> <target> Veuillez vÃrifier la sortie. </target> </mtc:match> </mtc:matches> <segment id = s1 > <source><mrk id = m1 type = mtc:match > Please check the results. </mrk></source> <target> Veuillez vÃrifier les rÃsultats. </target> </segment> or <mtc:matches> <mtc:match id = tu1 ref = #m1 similarity = 65 > <source> Please check the output. </source> <target> Veuillez vÃrifier la sortie. </target> </mtc:match> </mtc:matches> <segment id = s1 > <source> Please check the results. </source> <target><mrk id = m1 type = mtc:match > Veuillez vÃrifier les rÃsultats. </mrk></target> </segment> or something else. -Yoshito


  • 2.  RE: [xliff] ref value in translation candidates module element

    Posted 04-06-2021 22:42
    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. -Yoshito