Re: ITS rules in XLIFF from Nathan Glenn on 2013-10-01 (public-i18n-its-ig@w3.org from October 2013)

From: Nathan Glenn <garfieldnate@gmail.com>
Date: Tue, 1 Oct 2013 11:11:25 -0700
To: Yves Savourel <ysavourel@enlaso.com>
Cc: "public-i18n-its-ig@w3.org" <public-i18n-its-ig@w3.org>
Message-ID: <CACs83pjpft7BeoE9Sv1JgzdQvMwSVWZLJcTLTHBWo7xY_qW-hg@mail.gmail.com>
I'm glad the example helped here! Now I know I didn't understand that you
didn't understand:) In my implementation I'll just localize everything as
shown in the mapping.
The other category that has the same source/target confusion problem is
idValue, which is currently mapped to resname on trans-unit.
locQualityRating and mtConfidence make sense in trans-unit, since they
refer to the quality of the source-target relationship.
Nathan



On Tue, Oct 1, 2013 at 4:37 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

>  Hi Nathan, all, ** ****
>
> ** **
>
> Thanks for the example. Now I’m know sure I didn’t understand :)****
>
>
>
> I was talking about “skeleton”-like methods to ways to carry the ITS
> global rules from the source XML to the translated one, not to carry the
> information they are pointing too.****
>
> ** **
>
> You example helps a lot.****
>
>
>
> The problem with doing something like that is that it forces the XLIFF
> processor to be an ITS processor too.****
>
> ** **
>
> Obviously an ITS processor can read and understand ITS info in an XLIFF
> document, but to really process XLIFF it would have to also have
> XLIFF-specific process added: dealing with states for example, etc. The aim
> of the mapping is to allow developers to add support for ITS data
> categories in their XLIFF tool by just adding support for a few attributes.
> ****
>
> ** **
>
> In your case you are demonstrating tells me that maybe the mapping for
> External Resource is not OK and perhaps that is what we need to fix.****
>
> ** **
>
> There is a mechanism in XLIFF to carry non-textual data needing
> localization: <bin-unit>. So we could change itsxlf:externalResourceRef to
> point to the <bin-unit> rather than directly to the external resources.
> Like this:****
>
> ** **
>
> <xliff****
>
>  xmlns="urn:oasis:names:tc:xliff:document:1.2"****
>
>  xmlns:itsxlf="http://www.w3.org/ns/its-xliff/"****
>
>  its:version="2.0">****
>
>  <file original="blah.xml" source-language="en" datatype="plaintext">****
>
>   <body>****
>
>    <bin-unit id='x1' mime-type='video/mp4'>****
>
>     <bin-source><external-file href='en_vid.mp4'/></bin-source>****
>
>     <bin-target><external-file href='jp_vid.mp4'/></bin-target>****
>
>    </bin-unit>****
>
>    <trans-unit itsxlf:externalResourceRef='#x1'>****
>
>     <source xml:id="1">Some text</source>****
>
>     <target xml:id="2">テキスト</target>****
>
>    </trans-unit>****
>
>   </body>****
>
>  </file>****
>
> </xliff>****
>
> ** **
>
> And to address Felix’s remark about having several external references in
> the same element (like the <video> element in the specification’s example):
> we could still make the value of itsxlf:externalResourceRef a
> space-separated list or IRIs (and maybe call the attribute
> externalResourceRefs).****
>
> ** **
>
> Thoughts?****
>
> -yves****
>
> ** **
>
> ** **
>
> ** **
>
> From: Nathan Glenn [mailto:garfieldnate@gmail.com] ****
>
> Sent: Monday, September 30, 2013 4:11 PM****
>
> To: Yves Savourel****
>
> Cc: public-i18n-its-ig@w3.org****
>
> Subject: Re: ITS rules in XLIFF****
>
> ** **
>
> You've understood me perfectly, actually. If you don't think it's a bad
> idea, then I'm happy :) I was just worried because the mapping explicitly
> makes everything local.****
>
> Here's an example anyway that highlights one reason to do this. Anytime
> the mapping puts something in the <trans-unit> element, it means that you
> can't locally differentiate between application to source and target. Let's
> say the original document had a <targetPointerRule> and so source and
> target were extracted into one <trans-unit>. Localizing an
> <externalResourceRefRule> would mean putting itsxlf:externalResourceRef in
> the <trans-unit> element, but this is incorrect if the source and target
> have different external resources (let's say one video was dubbed in the
> target language). Instead of localizing it, I would just save the
> referenced text in the header in <its:span> elements.****
>
> ** **
>
> Original:****
>
> <xml xmlns:its="http://www.w3.org/2005/11/its">****
>
>   <its:rules version="2.0">****
>
>     <its:externalResourceRefRule selector="x|y" ****
>
>         externalResourceRefPointer="@foo">****
>
>     <its:targetPointerRule ****
>
>         selector="/xml/x" ****
>
>         targetPointer="/xml/y"/>****
>
>   </its:rules>****
>
>   <x foo="en_vid.mp4">text</x>****
>
>   <y foo="jp_vid.mp4">テキスト</y>****
>
> </xml>****
>
> ** **
>
> Extracted:****
>
> <xliff****
>
>     xmlns="urn:oasis:names:tc:xliff:document:1.2"****
>
>     xmlns:its="http://www.w3.org/2005/11/its"****
>
>     its:version="2.0">****
>
>   <file original="blah.xml" source-language="en" datatype="plaintext">****
>
>     <header>****
>
>       <its:rules>****
>
>         <its:targetPointerRule selector="//source"****
>
>             targetPointer="../target"/>****
>
>         <its:externalResourceRefRule selector="id('1')" ****
>
>             externalResourceRefPointer="id('span1')">****
>
>         <its:externalResourceRefRule selector="id('2')" ****
>
>             externalResourceRefPointer="id('span2')">****
>
>       </its:rules>****
>
>       <its:span xml:id="span1">en_vid.mp4</its:span>****
>
>       <its:span xml:id="span2">jp_vid.mp4</its:span>****
>
>     </header>****
>
>     <body>****
>
>       <trans-unit>****
>
>         <source xml:id="1">Some text</source>****
>
>         <target xml:id="2">テキスト</target>****
>
>       </trans-unit>****
>
>     </body>****
>
>   </file>****
>
> </xliff>****
>
> ** **
>
> Nathan****
>
> ** **
>
> On Mon, Sep 30, 2013 at 2:03 PM, Yves Savourel <ysavourel@enlaso.com>
> wrote:****
>
> Hi Nathan,****
>
>  ****
>
> I’m afraid I’m still not sure what is the scenario. Sorry to be slow.****
>
>  ****
>
> If you are talking about how to re-create the part of your source file
> that has the global rules into the translated XML (so essentially to ‘move’
> those rules from the source XML to the translated XML, through XLIFF), then
> yes, you can use whatever mechanism you want, and storing thing in the
> skeleton is usually your best chances to get things preserved.****
>
>  ****
>
> But I’m not sure this is the scenario you are talking about.****
>
> Maybe a short example with the source XML and the created XLIFF would help
> me (and everyone) to get the idea.****
>
>  ****
>
>  ****
>
> -yves****
>
>  ****
>
>  ****
>
>  ****
>
> From: Nathan Glenn [mailto:garfieldnate@gmail.com] ****
>
> Sent: Monday, September 30, 2013 2:48 PM****
>
> ** **
>
> To: Yves Savourel****
>
> Cc: public-i18n-its-ig@w3.org****
>
> Subject: Re: ITS rules in XLIFF****
>
>  ****
>
> Actually, please tell me if you think that is a bad idea. The XLIFF
> mapping seems to be designed to make everything absolutely localizable, and
> this sort of strategy seems to be avoided there. It just happens to look
> like the shortest path from A to B (preserving global rules with the least
> work) for me.****
>
> Nathan****
>
>  ****
>
> On Mon, Sep 30, 2013 at 1:05 PM, Nathan Glenn <garfieldnate@gmail.com>
> wrote:****
>
> Thanks! I see now how extensible XLIFF is. I can put extra elements in the
> elements listed in 2.5.1 of the spec. The issue for me was that I already
> have code that can preserve ITS rules and their matches during a document
> transformation, but it requires re-pasting all of those pointer values and
> I didn't know where to put them in XLIFF. I guess I can just put each of
> them in their own <its:span> element in the XLIFF <head>.****
>
> Nathan****
>
>  ****
>
> On Mon, Sep 30, 2013 at 8:10 AM, Yves Savourel <ysavourel@enlaso.com>
> wrote:****
>
> Hi Nathan,****
>
>  ****
>
> Not sure if I understand the issue.****
>
>  ****
>
> In general the global rules that carry data in your XML file will be seen
> as ITS ‘properties’ attached to the pointed node, when processing the XML
> input for extraction. So, that’s correct that you cannot tell where they
> are coming from, and therefore you cannot really update them when merging
> back.****
>
>  ****
>
> As you pointed out, the current mapping uses elements like <note> or
> attributes like comment to store the data. That is because it tries to
> re-use what the XLIFF 1.2 format provides.****
>
> In a few cases like Terminology you could use xlfits:termInfoRef to point
> to an elements in the XLIFF that is from your own namespace and hold
> additional info about how to feedback the potentially modified info.****
>
>  ****
>
> I’m not sure if that helps,****
>
> -yves****
>
>  ****
>
>  ****
>
> From: Nathan Glenn [mailto:garfieldnate@gmail.com] ****
>
> Sent: Sunday, September 29, 2013 2:07 PM****
>
> To: Yves Savourel****
>
> Cc: public-i18n-its-ig@w3.org****
>
> Subject: Re: ITS rules in XLIFF****
>
>  ****
>
> Thanks. I wonder if it's worth even trying to preserve global rules in my
> application. If I were to create an XLIFF file for a given XML file, and
> also try to preserve the global rules by making them point to new nodes in
> the XLIFF file, is there any generic place where I could put the contents
> contained by nodes selected through *Pointer attributes in the rules, or
> would I have to use the specific locations that differ for each type of ITS
> (e.g. its:termInfo, itsxlf:domains or a <note> element)?****
>
>  ****
>
> Nathan****
>
>  ****
>
> On Sun, Sep 29, 2013 at 4:35 AM, Yves Savourel <ysavourel@enlaso.com>
> wrote:****
>
> Hi Nathan, ****
>
>  ****
>
> Yes, the mapping doesn’t use global rules. The idea is that an XLIFF
> processor should be able to add support for ITS by just implementing
> support for the attributes defined by the mapping.****
>
>  ****
>
> This doesn’t prevent an ITS processor to support XLIFF by having global
> rules describing the XLIFF features, just like for any other XML format.**
> **
>
>  ****
>
> -ys****
>
>  ****
>
>  ****
>
> From: Nathan Glenn [mailto:garfieldnate@gmail.com] ****
>
> Sent: Sunday, September 29, 2013 12:18 AM****
>
> To: public-i18n-its-ig@w3.org****
>
> Subject: ITS rules in XLIFF****
>
>  ****
>
> Hi all (especially Yves),****
>
> I'd like to confirm an observation on ITS in XLIFF. At least judging by
> the mapping documentation, it seems that ITS in XLIFF does not allow for
> global rules of any kind, and that during mapping all rule matches must be
> turned into local attributes of some kind. Is this correct?****
>
> Nathan****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>
Received on Tuesday, 1 October 2013 18:11:53 UTC