Hi,
Yes. That's why I thought of ripping off a slice from both the
translation AND the original.
Consider this:
Plugin wants to create a menu Image/Filters/verynew/stupidtool.
Now we first check:
- Is there a menu Image/Filters/verynew
- if not continue ripping off until we
On 25 Feb, Sven Neumann wrote:
Which is exactly what I proposed at the end of my last mail. Despite
that I proposed to build up the menu-structure (actually only the
strings) in a hash-table before actually creating it.
For a new translation function I guess?
Would be much
faster then
Hi,
Look at the code we already have to add the tearoff menus. A similar
thing could be used to create the branches itself.
Don't waste your time at that. I already did that and I tried to explain
you why there is no way to hook into that place since GTK+ creates the
submenu on the fly.
On 25 Feb, Sven Neumann wrote:
Don't waste your time at that. I already did that and I tried to
explain you why there is no way to hook into that place since GTK+
creates the submenu on the fly. At the time we create the tearoff
menu, the submenu is already created. But when the submenu is
Hi,
I'd suggest testing for existance of the parent menu first and
if it's not there extracting the correct translation for it from
the full path and initialize it together with the tearoff menu.
On the first thought the idea looks promising, but I fear it is
not that easy. GTK+ wants to
Hi,
the new i18n implementation supports localisation of
plugins outside the gimp distribution. I'm pretty sure
that it works. I have however not yet tested if it
really does what we expect and if it solves the problems
it targets. Is there anyone out there maintaining a
seperate plugin who
Hi,
SHIRASAKI Yasuhiro [EMAIL PROTECTED] noticed:
some paths like:
Image/Video
Image/Script-Fu/*
are not translated with "The i18n solution"(TM).
Shell we move dummy_entries[] items from app/menus.c
to each appropriate plug-ins?
Eek, yes of course, that does not work any more. There
On 24 Feb, Sven Neumann wrote:
the new i18n implementation supports localisation of
plugins outside the gimp distribution. I'm pretty sure
that it works. I have however not yet tested if it
really does what we expect and if it solves the problems
it targets. Is there anyone out there
On 24 Feb, Sven Neumann wrote:
Eek, yes of course, that does not work any more. There are
two ways to solve this: Either we search in the gimp domain
if the lookup of the menupath failed (like we used to do (*))
or we move the dummies into the plugins. I prefer the latter,
since it is the
