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





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 going through gtk+ for each and every menu just to know
 if there's already a matching menu.

 It shouldn't be that complicated, but that depends on the internal
 representation of menus which I didn't look at.

 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.

 Uhm, no, that's not what I had in mind.

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

 Look at the code we already have to add the tearoff menus. A similar
 thing could be used to create the branches itself. 

 I'm leaving home in a few minutes and after spending a whole night 
 on other problems I'm very glad to have a look such an improvement.

 Don't expect a solution before 17:00 CET...

-- 

Servus,
   Daniel



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. At the time we create the tearoff menu, the submenu
is already created. But when the submenu is created, the menu_translate 
function does not know the complete path and therefore can't lookup a
matching translation. 

Unless I have overseen something obvious, the only way to go is to analyze 
the menu strings on our own before we actually build the menus using gtk+.
The more I think about it, the more I feel it might be worth to try the
implementation I've proposed. Eventually this weekend...


BTW, is there a function to unbind from a textdomain? There's actually no 
need to hold the plugins translation tables in memory after the menus are
created and we only need such a small portion of it. Or are the message 
catalogs properly shared if multiple apps use the same catalog?



Salut, Sven 




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 created,
 the menu_translate function does not know the complete path and
 therefore can't lookup a matching translation.

 Hm, but I think I nearly got it.

 Unless I have overseen something obvious, the only way to go is to
 analyze the menu strings on our own before we actually build the
 menus using gtk+. The more I think about it, the more I feel it might
 be worth to try the implementation I've proposed. Eventually this
 weekend...

 Please wait a moment. Otherwise we'll work again in different
 direction.

 BTW, is there a function to unbind from a textdomain?

 No.

 There's actually
 no need to hold the plugins translation tables in memory after the
 menus are created and we only need such a small portion of it. Or are
 the message catalogs properly shared if multiple apps use the same
 catalog?

 With gettext? You must be joking. I've never seen such a bad
 implementation of anything.

-- 

Servus,
   Daniel



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 create the menu using the orginal 
strings. 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. 

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 :-(

I have an idea how it could work, but I think the overhead is 
not worth the issue: Before we build the menus, we could create a 
hashtable containing translations of all menu_entries including
the menu_paths (that can be easily generated by recursively 
truncating the translations after the last '/' and use that 
hashtable later instead of calling gettext again.

Better ideas anyone?? If not, I'd say we move the dummy_entries
into the plugins. Whoever is interested in doing this (sorry, 
I won't), insert the following line into menus.c to get a list
of the affected menus:

app/menus.c (line 979)   g_print ("%s\n", entry-entry.path);



Salut, Sven




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

 Right.

 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

-- 

Servus,
   Daniel



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

There are a few entries in menus.c that should already be 
included in the perl domain, since Marc moved his stuff out 
into the Perl-Scripts. 

Obviously each plug-in that wants to add an extra menu
that is not build by the Gimp core has to provide its own
dummy-entry for it. We could of course build all the menus 
we need for the default plugins, but that would result in 
empty menus if stuff is uninstalled.


Salut, Sven

(*) The new solution has the advantage that we could look up
the translation in the plugins domain first where we will
most likely find a translation and only fall back to the
core if not. Before we always used the gimp domain first.




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 maintaining a 
 seperate plugin who is interested in internationalising 
 it? It would be very nice to get some feedback if the 
 current solution works under realistic circumstances. 

 I'll test a few plugins soon.

 Would be nice if someone else could take care of changing 
 gimptool and doing a little testing... 

 I'll look into that, too.

 If you need more explanations how the new system is 
 supposed to work, let me know. Anyway I'll try to add a 
 few lines to README.i18n in the next days.

 But don't correct my typoes... :)

 "The i18n solution"(TM) is a registered trademark owned by Daniel
 Egger

 Hey Sven, come on...

-- 

Servus,
   Daniel



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

 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.

-- 

Servus,
   Daniel