[xliff-tools] The <file> element

[Asgeir Frimannsson]

On Thu, 17 Feb 2005 00:59, Bruno Haible wrote:
> In 1.1 General Structure
>
> > "Each PO file maps to one XLIFF <file> element."
>
> Agreed. One could also use the C source code file as a <file> element,
> but then where would the line numbers be stored. The XLIFF spec wants
> source file and line information to be stored as
>
>     <context context-type="sourcefile">foobar.c</context>
>     <context context-type="linenumber">123</context>
>
> Duplicating this information in the <file> element could cause complexities
> for the preparation or extraction step if several files with the same
> basename occur.
>
> But is is possible to use <group> tags to group messages from a single
> source file together:
>
>     <group id="67423423">
>       <context context-type="sourcefile">foobar.c</context>
>       ... Here come the <trans-unit>s from foobar.c ...

In many cases we would then end up with multiple identical translation units 
(when same msgstr is used in multiple files within the same domain). 
Different translations of identical msgstr's is not supported within Gettext, 
and XLIFF editors would then need custom checks for identical translation 
units.

> It is also possible to modify xgettext to add the C function name to
> the context. This would lead to
>
>     <group id="67423423">
>       <context context-type="sourcefile">foobar.c</context>
>       <group id="copy_file">
>         ... Here come the <trans-unit>s from function copy_file() ...

or even:
     <group restype="x-sourcefile" resname="foobar.c">
       <context context-type="sourcefile">foobar.c</context>
       <group restype="x-c-function" resname="copy_file">
         ... Here come the <trans-unit>s from function copy_file() ...

This approach doesn't follow the logical structure of a PO file, so it's not 
very suited for a PO Representation (but maybe for a future XLIFF Gettext 
representation?)

In addition, it's very source-code focused. This might not be wrong, but in a 
gettext based environment, the logical group is domains, and not functions or 
sourcefiles. Functions and sourcefiles are context-information. 

> The question is: Would this lead to more translator comfort, or are XLIFF
> editors made in such a way that unnecessary <group> tags are cumbersome?

IMO <group> elements can be a help to translators if they are used in a 
translator-friendly way: To group related translation-units, and to describe 
the hierarcical structure of a set of translation units. (I think e.g. 
Alchemy Catalyst supports browsing an XLIFF file in a hierarcical fashion?)

cheers,
asgeir