RE: ITS rules in XLIFF

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 21:03:57 UTC