- From: Nathan Glenn <garfieldnate@gmail.com>
- Date: Mon, 30 Sep 2013 15:10:48 -0700
- To: Yves Savourel <ysavourel@enlaso.com>
- Cc: "public-i18n-its-ig@w3.org" <public-i18n-its-ig@w3.org>
- Message-ID: <CACs83pizaXCSvPYJ3VUZ=JuB3tAnKRRqvzUv+cZPWurw=uST+Q@mail.gmail.com>
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 Monday, 30 September 2013 22:11:21 UTC