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. 


> 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....



Reply via email to