On Sat, Nov 27, 1999 at 02:06:25PM +0100, Michael Natterer <mitschel@xxxxxxxxxxxxxxx> wrote:
> I don't quite get what you mean... is gettext unable to parse perl code?
Not only that, look at how the gettext scanning is implemented in automake
(I was unable to use any automake/autoconf support for gettext in perl,
since all of it assumes a rigid directory structure and c source, nothing
else).
I have written my own xgettext replacement (plug-ins/perl/xgettext), so if
anybody knows a good way to merge two distinct .pot files into a common
one, we could just scan using xgettext, scan using pxgettext and merge the
two catalogs.
> > PS: does gimp now translate by component or still using the whole path?
> Gimp translates the whole path and gtk uses it's last component ;-)
Oh, fine, that's just how I'd do it myself ;->>
> - to enable perl, I'll add searching in gimp-perl.mo if finding a translation
> in the other two files fails.
That would, of course be a workaround. I detest, though :(
But wait: how about being able to configure additional text domains for
menu searches throuhg the config file? That would allow to install not
only perl but also other extensions (that have this problem), even after
gimp was installed.
(It might not be workable to have one mo file per plug-in, but it is at
least possible to install plug-ins later, then).
> Don't know if this is a problem with perl, as I didn't understand (see above)
> if parsing perl code works...
No, it doesn't. I could make it work by using N_("") as an exception for
the menu paths, but that's somewhat silly (the perl lingo for this should
be N_"")
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
