Marc Lehmann wrote:
> On Fri, Nov 26, 1999 at 09:45:21PM +0100, Sven Neumann <[EMAIL PROTECTED]> 
> > It seems your latest commit fixed the problem! Great work! Now it's
> > time for the translators to update the po files and there are still
> > a lot of plug-ins that need to be internationalized. Any volunteers?
> We still need to work the perl plug-in names in. The problem is that
> gettext does not support this (and I see no way to modify the makerules
> without re-writing them totally. Just another reason why automake is
> evil).

I don't quite get what you mean... is gettext unable to parse perl code?

> IAW: we just lost perl (although the general idea of putting the
> trabslations into the gimp is fine).
> 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 ;-)

So, for


we need:

<Image>/Filters/Whatever/foo/bar (all in


<Image>/Filters/Whatever/foo/bar/bla (in

The trick is:

- all submenus (like <Image>/Guides which is perl-only at the
  moment) are defined as dummy N_()-marked strings in menus.c.

- all plugins have to register with their english names (their "identifiers")

- app/menus.c:menu_translate() tries to find a translation in,
  then in

- to enable perl, I'll add searching in if finding a translation
  in the other two files fails.

- finally, the translations in and are
  the full paths (e.g. <"Image>/Guides/Center Guide" becomes
  "<Image>/Hilfslinien/Hilflslinie zentrieren")

But apart from the fact that the current implementation works, I'd still
vote for putting _all_ translations (not only the menus but just any string)
into _one_ file. (I don't see another way to correctly translate
string which are defined in libgimp (e.g. widgets and used by both the gimp
and it's plugins)

Don't know if this is a problem with perl, as I didn't understand (see above)
if parsing perl code works...


Reply via email to