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 create the menu using the orginal
strings. The translation is only used when the label is to be
displayed.
Therefore it then calls our menu_translate functions which takes
care of appending the factory name (<Image>, <Toolbox>, ...) to
the string, passing this string to gettext and removing the factory
name from the translated result. GTK+ takes the returned string
and strips away everything up to the last '/' and puts that into
the menu_label. At least that is my impression of how it works.
Submenus are created on the fly when they are needed. Unfortunately
they have to be created before the actual menu_entry can be added.
That means if
<Image>/Filters/Render/Nature/Flame...
is to be created, the submenu
<Image>/Filters/Render/Nature
is created automatically. Unfortunately there is no such string
in the textdomain of the plugin and the lookup fails. If the lookup
order would be different, it would be easy to store the result of the
latest lookup and strip the last part. But that's fiction :-(
I have an idea how it could work, but I think the overhead is
not worth the issue: Before we build the menus, we could create a
hashtable containing translations of all menu_entries including
the menu_paths (that can be easily generated by recursively
truncating the translations after the last '/' and use that
hashtable later instead of calling gettext again.
Better ideas anyone?? If not, I'd say we move the dummy_entries
into the plugins. Whoever is interested in doing this (sorry,
I won't), insert the following line into menus.c to get a list
of the affected menus:
app/menus.c (line 979) g_print ("%s\n", entry->entry.path);
Salut, Sven
