[xliff-tools] PO references

David Fraser davidf at sjsoft.com
Thu Feb 3 01:14:35 PST 2005


Tim Foster wrote:

>Hey Folks (Hi David!)
>
>On Wed, 2005-02-02 at 09:49, David Fraser wrote:
>  
>
>>However, when using the PO format to encode certain other translation 
>>formats we use a # to indicate a non-linenumber based location within 
>>the code (we were recommended to do this on the gettext list).
>>    
>>
>Yeah, that makes sense.
>  
>
>>Its tricky to work out where this #location should go in the xliff file. 
>>Of course part of this is because the PO file format specification 
>>provided by gettext is not really a standard reference work :-)
>>    
>>
>Aah, standard reference works :-) The problem with gettext, is that it
>isn't a standard, so people have been "making it up as they go along"
>(with apologies to Monty Python) - gettext was a proposal from 
>POSIX.1b and UniForum as far as I can make out, and there was arguments
>as to whether to then ratify the XPG4 catgets() or gettext() as the
>offical way to internationalise UNIX apps. I think it all ended in tears
>ultimately, and nothing was agreed.
>
>http://www.wlug.org.nz/POSIX
>  
>
It would still be nice to make a reference to the PO file that reflects 
actual use, and (for example) describes the KDE variations etc.
The Gnu Gettext manual description of the PO format contains more 
information about what you can do with Emacs than the meaning of the 
fields...

>>Any ideas?
>>    
>>
>Well, certainly it belongs in a context group item somewhere, but the
>xliff spec doesn't seem specify where. Perhaps using an context-type
>of "x-mumble" would be needed ? (Note to self : when migrating our
>bits to xliff 1.1, convert any non-standard context-types to say
>"x-something" instead of just "something")
>  
>
For the mean time we've just left it in sourcefile.

>For what it's worth, our translation editor can display these
>context information pieces correctly, though we've some work
>to do to convert to XLIFF 1.1. As to exactly how to deal with them,
>I'm not sure the standard specifies that.
>  
>
Right. BTW I've got an initial stab at a python po2xliff and xliff2po in 
the translate cvs, I'll post more details when its working properly (and 
Asgeir has tested it :-))

David


More information about the xliff-tools mailing list