[xliff-tools] The <file> element

[Tim Foster]

Hi there,

On Wed, 2005-02-16 at 14:59, Bruno Haible wrote:
> In 1.1 General Structure
> 
> > "Each PO file maps to one XLIFF <file> element."
> 
> Agreed.

We were thinking along the lines of each PO domain gets
it's own file element...

> It is also possible to modify xgettext to add the C function name to
> the context. This would lead to

I'd always thought that the more context information there is, the better -
the translator doesn't have to look at it, it just might be nice.
In general, the more information a translator has to go on, the
better. You can do context groups in XLIFF, so something like :

<trans-unit id="a1">
       <source>This is message so there</source>
       <count-group name="word count">
          <count count-type="word count" unit="word">5</count>
       </count-group>
      <context-group name="translator-info">
          <!-- the message key - for po files, this is just the message text
               but other formats, like .properties have the key in here -->
          <context context-type="record">This is a message so there</context>
          <context context-type="x-sourcefile">foobar.c</context>
          <context context-type="x-function">copy_file</context>
      </context-group>
 </trans-unit>

> 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?

Hmm, I guess it depends on the implementation : we only track grouped
trans-unit elements in ours (to denote related translations) but there's
no reason why we couldn't change that...

	cheers,
			tim

-- 
Tim Foster - Tools Engineer, Software Globalisation
http://sunweb.ireland/~timf http://blogs.sun.com/timf
http://www.netsoc.ucd.ie/~timf