Re: [xliff-comment] Re: [xliff] FW: [xliff-comment] Purpose of name attribute for <context-group>

["Asgeir Frimannsson" <asgeirf@gmail.com>]

Hi all,

On 8/31/06, Rodolfo M. Raya <rmraya@heartsome.net> wrote:
> > The PO representation guide currently uses the same name for multiple
> > context-groups, this will need to be fixed in the following sections
> > to be consistent with the XLIFF 1.2 context-group "interpretation":
> > 5.3. Translator Comments
> > 5.4. Extracted Comments
> > 5.5. References
>
>
>
> Examples in sections 5.3 and 5.4 show only one <trans-unit> element.

From Section 5.4 of the PO guide:
"The surrounding <context-group>element (same context group as the
Translator Comment as described above) would have the name attribute
set to po-entry and..."

The name cannot be set to 'po-entry', as this will not be unique, and
the file will not be able to validate against the 1.2 schema. Hence
the example in both 5.3 and 5.4 should also be changed.

> Section 5.5 should be updated to comply with the uniqueness requirement.

Yes, I agree.

>
> > Also note that the XLIFF 1.1 Whitepaper make use of multiple
> > <context-group> elements with the same name in Section 6.1, I vaguely
> > remember that being the reason we used same-name groups in the PO
> > guide in the first place.
>
>
>
> A new white paper should be prepared for XLIFF 1.2.
>
>
> > I would like to ask for a
> > clarification of the following statement in the XLIFF specification:
> > "Because the <context-group> element may occur at a very high level, a
> > default context can be established for all  <trans-unit> elements
> > within a file. This default can be overridden at many subsequent
> > levels.". How does this overriding work, if not by matching on the
> > name attribute?
>
>
>
> The <context-group> element holds context elements relating to the level
> in the tree in which it occurs. Thus context can be set at a <group>
> level, a <trans-unit>  level, or a <alt-trans> level.
>
> Context can be overridden by adding a new <context-group> at the desired
> level. It is not necessary to set the same value for the "name"
> attribute, as context applies to the level where it is present and does
> not require to be matched with anything..

That does however imply that you only have one <context-group> element
at each level. What happens if you have multiple named groups at each
level for different purposes? E.g. what if I have one context-group
that gives further info to the translator about the context, and one
that is for TM matching. Quoting the XLIFF 1.2 spec (2.3. Named
Groups): "A different named group could be stored by the client,
translator, reviewer, and localization engineer. Processing
instructions could inform a system which of these <count-group> to
update during the localization process." Sounds good to me, but this
is practically impossible! You would have to write a separate
processing instruction for each and every named group (e.g. for each
translation unit).

I am fully aware about the fact that the current spec enforces
uniqueness on the name attribute, but what I'm after is *a reasoning
behind this* from the XLIFF TC. Why is this strictly enforced now at
1.2, breaking compatibility with all existing examples of named-group
usage in XLIFF TC examples, documents, presentations etc.
Specifically, what was the reasoning behind changing the context-group
'name' attribute to 'optional' and enforcing uniqueness in the schema?
Isn't it enough to have unique <group>s and <trans/bin-units> elements
and fetching the unique named-groups based on these?

cheers,
asgeir


> Best regards,
> Rodolfo M. Raya
> Heartsome
> --
> The information in this e-mail is intended strictly for the addressee,
> without prejudices, as a confidential document. Should it reach you, not
> being the addressee, it is not to be made accessible to any other
> unauthorised person or copied, distributed or disclosed to any other
> third party as this would constitute an unlawful act under certain
> circumstances, unless prior approval is given for its transmission. The
> content of this e-mail is solely that of the sender and not necessarily
> that of Heartsome.
>
>


-- 
Asgeir Frimannsson
PhD Candidate
School of Software Engineering and Data Communications
Queensland University of Technology
126 Margaret Street, Level 3
Brisbane QLD 4001, Australia

Phone: (+61) 7 3864 9332 Mob: (+61) 405 412 696
Email: a.frimannsson@qut.edu.au