Re: [Po4a-devel][CVS] po4a/lib/Locale/Po4a Po.pm,1.15,1.16
On Mon, Aug 02, 2004 at 11:28:14PM +0200, Denis Barbier wrote:
On Mon, Aug 02, 2004 at 03:10:06AM -0700, Martin Quinson wrote:
>
> On Mon, Aug 02, 2004 at 09:35:41AM +0000, Martin Quinson wrote:
> >
> > Modified Files:
> > Po.pm
> > Log Message:
> > Implement a tool I dream of since a long time: msgsearch, which allows you
> > to filter out some messages of the po file and put them in another
>
> I needed it for the perl documentation project. We have to split per file.
> So, I did it ;)
>
> It works reasonably well and you can apply some complex filter.
> '(&(reference="po4a:")(msgid= ))' gives you all the strings
extracter out of
> po4a and containing a space.
>
> But:
> - the flags and the comments are not reported to the file (gasp)
> - some complex expressions still break the parser:
> '(&(reference="po4a:")(&(flags=fuzzy)(msgid= )))'
> '(|(flags=fuzzy)(!(msgstr=.)))' which should give you all the fuzzy or
> untranslated messages.
Martin, can you please explain what cannot be performed by msggrep (apart
from Perl regular expressions)?
I never managed to do filters such as (|(flags=fuzzy)(!(msgstr=toto))) with
msg* tools. Expressing the OR with command line filters is far from easy.
It'd be something like
(cat file|msgattrib --only-fuzzy;cat file |msggrep -K toto)|msgcat --use-first
And I remember having trouble when chaining commands that way. I can't
remember which, and lack the time to explore my mailbox to find it again..
I have no idea how to express the negation since msggrep -v is not valid.
Bruno Haible has recently developed a libgettextpo library (part of
gettext) containing handful functions for applications which have to
read/write/parse PO files. Maybe it is worth writing a XS module
to use this library? This way, one shouldn't care about comments and
flags, but OTOH XS modules are architecture dependent.
It would indeed be a good idea to use this library for the basic po
operations (read/write), but Po.pm can do some other things too
(gettextization comes to mind, soon filtering). Anyway. Using the C library
for the parts it can do would indeed be a major achievement. It may also
allow us to avoid forking on msgmerge to do the grunt work, maybe.
I would need to check again the offered interface to make sure it does fit
our needs.
As always, this is just a thought, I did not investigate deeply ;)
Your advice is always welcome.
Mt.
--
There is no experimental demonstration of your theorem.
-- Anonymous reviewer