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
