>  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

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
is to be created, the submenu 
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

Reply via email to