Re: libgettextpo: Ability to parse a string

[Dwayne Bailey]

On Fri, 2007-10-19 at 02:57 +0200, Bruno Haible wrote:
> Dwayne Bailey wrote:
> > {I raised these on translation-i18n but am sending them here for more
> > formal reporting.}
> 
> Thanks; you know I have been a bit inactive on translation-i18n in the last
> few months.

Probably more active then me though :)

> > Currently you can only parse files read from stdin or from the file
> > system.  Our code mostly pushes string representations of files around.
> > It would be nice to have read and write methods that accept and output
> > strings in addition to the file based functions.  Our current work
> > around is to output to a temporary file, I haven't measured what kind of
> > overhead this is causing.
> 
> Such read and write methods from/to memory buffers are implementable.
> 
> But I'm wondering: Why do you have the string representation of the file
> in memory at all? Which operations are easier to perform with a long string
> than with a po_file_t?

That's a good question.  A few reasons really; 1) testing the tools, 2)
the toolkit is a generic framework for a number of files, it made it
easier to look at them at this level in many of the manipulations that
we do, 3) We have the ability to work with files that might have been
compressed then the output is usually a string.

The main problem I found in porting to use libgettextpo was that I had
to actually specify a real file as apposed to any sort of file handle.
So I was unable, in Python, to use for instance StringIO to pass a file
object that could then work.  What I had to do was take a string, put it
in a temporary file, then read the file using the libgettextpo
functions.  This does work I'm not sure if or what the hit is on
performance but its not clean.

-- 
Dwayne Bailey
Translate.org.za

+27-12-460-1095 (w)
+27-83-443-7114 (cell)