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

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. Would be much faster then 
going through gtk+ for each and every menu just to know if there's already
a matching menu. We'd end up with a hash containing all possible 
menu-strings with their translations as key-value pairs and would use that
table later instead of calling gettext again.

This could be hacked in about 20 lines of code using a GHashTable, but
I still consider this unnecessary bloat...

Salut, Sven

Reply via email to