- From: Yves Savourel <ysavourel@enlaso.com>
- Date: Tue, 1 Oct 2013 05:37:45 -0600
- To: "garfieldnate@gmail.com" <garfieldnate@gmail.com>, "public-i18n-its-ig@w3.org" <public-i18n-its-ig@w3.org>
- Message-ID: <4236658BB877A542A66660614300B185015612FE29DA@orion.helios.local>
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 11:38:17 UTC