On 24 Feb, Sven Neumann wrote:
> 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.
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 found a menu which is
already there.
Let's assume we do have the menu <Image>/Filters already which
translates into the German <Image>/Filter. We detected that
the next instance we have to create is <Image>/Filters/verynew.
Unfortuntely we don't have a translation handy but we can get
this one by taking the translation from
<Image>/Filters/verynew/stupidtool and strip off the same number of
instances. The full translation would be
<Image>/Filters/ganzneu/dummesteil <Image>/Filters/ganzneu and this
is the menu to create.
The really trick is to sell this to Gtk+. The only think we can supply
to Gtk+ is the menuname (the shortened one in this case) and a function
which translates it. Thus we'd have to create a function which is able
to do a translation although we can not directly pass the original.
> The translation is only used when the label is to be displayed.
Right.
> 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.
Right, too.
> 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 :-(
Right again.
I'll think about this issue and since we got that far I'm nearly
certain that we get a solution for this one also....
--
Servus,
Daniel
