[xliff-tools] PO references

[Asgeir Frimannsson]

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. 

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

> >So what should filters do in this situation. I think they should include
> > the information after '#' in the sourcefile attribute, and not introduce
> > any special parsing rules. E.g.
> >
> >#: dlgresid.src#RID_STR_BRWTITLE_NO_PROPERTIES.string.text
> >
> >becomes:
> >
> ><context-group name="x-po-reference" purpose="location">
> >  <context
> >context-type="sourcefile">dlgresid.src#RID_STR_BRWTITLE_NO_PROPERTIES.stri
> >ng.text</context> </context-group>
> >
> >Am I on the right track here?
>
> Yes that sounds right to me. Will not introduce any hassles. Have done
> that in my python implementation.

Sounds good.

cheers,
asgeir