W3C home > Mailing lists > Public > public-i18n-its-ig@w3.org > October 2013

Re: ITS rules in XLIFF

From: Nathan Glenn <garfieldnate@gmail.com>
Date: Tue, 1 Oct 2013 17:14:25 -0700
Message-ID: <CACs83pjh5DNuwJD-_rv_yjW-Nv3ELHjw_0EGywecfPn9B3JqbQ@mail.gmail.com>
To: Yves Savourel <ysavourel@enlaso.com>
Cc: "public-i18n-its-ig@w3.org" <public-i18n-its-ig@w3.org>
That makes sense. I think it's good to keep anything ID-like off of the
<source> element, too, since it might end up getting copied and renamed as
<target>, which could lead to a duplicate ID. The XLIFF standard seems to
agree,  only allowing for an id value on <trans-unit>. For a part of WICS
we wondered if we needed to parse documents invalidated by a duplicate
xml:id value.
Nathan


On Tue, Oct 1, 2013 at 12:07 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

> > The other category that has the same source/
> > target confusion problem is idValue, which is
> > currently mapped to resname on trans-unit.
>
> For that one I think maybe it's a case of non-mapping.
>
> We use idValue to link the content in the source document and the XLIFF
> document. In the vast majority of the case, the source text is replaced by
> the target text, so they have the same ID, and it make sense to use resname
> for this in XLIFF.
>
> For the cases where the translation goes to a different node which has
> also an ID, as in your case, maybe it make sense to say that the idValue
> mapping applies only to source content ID because you are still likely to
> be able to use targetPointer to merge back the translation at the right
> node.
>
> The important part is to be able to identify the couple source/target by
> an ID that is unlikely to change. I would say that even if the id of the
> source is not the id of the target, it still provides a unique way of
> identifying the pair.
>
> Cheers,
> -yves
>
>
Received on Wednesday, 2 October 2013 00:14:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:11:30 UTC