Hi,
> 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
