Re: Testing and integration of The i18n solution(TM)

2000-02-25 Thread Sven Neumann
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

Re: Testing and integration of The i18n solution(TM)

2000-02-25 Thread Daniel . Egger
On 25 Feb, Sven Neumann wrote: 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. For a new translation function I guess? Would be much faster then

Re: Testing and integration of The i18n solution(TM)

2000-02-25 Thread Sven Neumann
Hi, Look at the code we already have to add the tearoff menus. A similar thing could be used to create the branches itself. Don't waste your time at that. I already did that and I tried to explain you why there is no way to hook into that place since GTK+ creates the submenu on the fly.

Re: Testing and integration of The i18n solution(TM)

2000-02-25 Thread Daniel . Egger
On 25 Feb, Sven Neumann wrote: Don't waste your time at that. I already did that and I tried to explain you why there is no way to hook into that place since GTK+ creates the submenu on the fly. At the time we create the tearoff menu, the submenu is already created. But when the submenu is

Re: Testing and integration of The i18n solution(TM)

2000-02-24 Thread Sven Neumann
Hi, I'd suggest testing for existance of the parent menu first and if it's not there extracting the correct translation for it from the full path and initialize it together with the tearoff menu. On the first thought the idea looks promising, but I fear it is not that easy. GTK+ wants to

Re: Testing and integration of The i18n solution(TM)

2000-02-24 Thread Daniel . Egger
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

Re: Testing and integration of The i18n solution(TM)

2000-02-24 Thread Sven Neumann
Hi, SHIRASAKI Yasuhiro [EMAIL PROTECTED] noticed: some paths like: Image/Video Image/Script-Fu/* are not translated with "The i18n solution"(TM). Shell we move dummy_entries[] items from app/menus.c to each appropriate plug-ins? Eek, yes of course, that does not work any more. There

Re: Testing and integration of The i18n solution(TM)

2000-02-24 Thread Daniel . Egger
On 24 Feb, Sven Neumann wrote: the new i18n implementation supports localisation of plugins outside the gimp distribution. I'm pretty sure that it works. I have however not yet tested if it really does what we expect and if it solves the problems it targets. Is there anyone out there

Re: Testing and integration of The i18n solution(TM)

2000-02-24 Thread Daniel . Egger
On 24 Feb, Sven Neumann wrote: Eek, yes of course, that does not work any more. There are two ways to solve this: Either we search in the gimp domain if the lookup of the menupath failed (like we used to do (*)) or we move the dummies into the plugins. I prefer the latter, since it is the