[xliff-tools] PO references

[David Fraser]

Asgeir Frimannsson wrote:

>On Wednesday 02 February 2005 21:55, David Fraser wrote:
>  
>
>>Asgeir Frimannsson wrote:
>>    
>>
>>>Hi,
>>>
>>>On Wednesday 02 February 2005 19:49, David Fraser wrote:
>>>      
>>>
>>>>I notice that the xliff-po-guide only refers to source file and
>>>>linenumber under PO references:
>>>>example.cpp:134 becomes this
>>>> <context-group name="x-po-reference" purpose="location">
>>>>   <context context-type="sourcefile">example.cpp</context>
>>>>   <context context-type="linenumber">134</context>
>>>> </context-group>
>>>>
>>>>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).
>>>>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 :-)
>>>>Any ideas?
>>>>        
>>>>
>>>The file-formats this is done on (only openoffice.org parsed files?) are
>>>usually file-types which would benefit from having their own XLIFF filters
>>>(And SUN might even release these soon as open source?), and I don't think
>>>we should accomodate these custom po-filters in the Representation Guide.
>>>      
>>>
>>OK fine. But I do wish there was a PO reference that was the same style
>>as your mapping guide :-)
>>    
>>
>To explain a bit further: In e.g. the translate toolkit you have filters 
>ts2po, swx2po, html2po, etc... The goal of the XLIFF Tools project is to 
>change all this to ts2xliff, swx2xliff, html2xliff, po2xliff, and use XLIFF 
>as the common file format. The guide does therefore not need to accomodate 
>any PO format that does not derive from the GNU Gettext package. 
>  
>
Right, now that I have an xliff module this shouldn't be too hard 
although we'd want to still keep po as the main format until there's a 
decent open source xliff editor. But I see the point that any variation 
for the sake of accomodating other formats is unneccessary.

>>>Similar for e.g. KDE's customized implementation of plural forms and
>>>context. Should the specification handle these? My personal opinion is
>>>no, we'll stick to the vanilla gettext implementation for the
>>>Representation Guide. For xliff-po-tools however, to accomodate KDE we
>>>can e.g. add a '--kde-style' flag to xliff2po/po2xliff, that will
>>>correctly parse KDE style plurals and context information.
>>>      
>>>
>>I think that handle these KDE styles will be important, otherwise we
>>exclude them...
>>    
>>
>Yepp, I agree that the FILTERS should include support for KDE, but not the PO 
>File Representation Guide.
>  
>
Maybe it should at least be mentioned in the guide. Otherwise anyone 
else following it might handle it in an incompatible way :-)

David