Re: discovery: debian menu already supports l10n!

[joost witteveen <joostje@cistron.nl>]

Je 1999/12/04(6)/ 7:12, Chris Waters montris sian geniecon skribante:
> joost witteveen <joostje@mail.com> writes:
> 
> > First of all: If you try "LC_ALL=eo update-menus" as root,
> > you'll see that menu already supports internationalisation, in a
> > way that doesn't have to disadvantages described below.
> 
> No, that doesn't work.  It makes the Gnome menu entries for the
> default ("C") locale be the "eo" entries.  And if I change the locale
> within Gnome, the menu items don't change.  That's a major bug.  I
> said l10n, not i18n because I meant l10n not i18n.

OK, that is wrong in the gnome menu-method. That should be fixed.
When I proposed the current translation system, nobody mentioned
that. As a result, I admit it isn't currently possible for the
gnome menu-method to do anything better (other than get it's
maintainer complain to me).

However, it should be rather easy to add functions
  title_en()              # returns the english title, whatever the locale
  translate($lang, $text) #translate $text into $lang (es, eo, ...)
and then it is possble for gnome menu-method to create just the
same gnome menufiles as you create.

> We already have people complaining, and asking us to switch to the
> Gnome menu system because of this problem.  Especially admins with
> several users.  (Yes, they could run update-menus as user, but that
> has its own *major* disadvantages.)

Then why did nobody mention that to me?

> > Yes, what you tried works. But it has several disadvantages.
> 
> None of which are as big as the disadvantages of the current
> approach.  I'm aware of the current approach, but it's not good
> enough.

> 
> The disadvantages to my approach are all (or almost all) logistical;
> the disadvantages to the current approach are technical.  There are
> many ways to deal with logistical problems, but the only way to deal
> with a technical problem is to fix it.

Then please mention those disadvantages to me. Adding those two
functions is quite easy for me, and that fixes the technical problem.

However, I don't know how to deal with that logistical problem:
the much too low maintainer-to-maintainer communication is already
causing many problems in debian, and this will make things wors.

> The current approach *is* good for an interim measure -- we can
> collect the translations in a central place for now, and later get
> them added to individual packages.  But the current approach is
> majorly broken with respect to both Gnome and KDE, and, while I don't
> use either of those systems, I suspect that the majority of our users
> *will* be using one or the other before long.  We should prepare
> ourselves to do it right before too much longer.

Do you agree that, with the two menu-mehtod functions I proposed
above added, my approch creates gnome startup files identical
to what you propose? 

If I get a positive answer before december 5th, 0:00 GMT, I'll
probably be able to add those functions (and the one I mention
below) before december 6th.

One other function I would like to add:

  forall($array,$var,$exec)
    For each value in the colon-seperated array $list (eg "en:es:eo"),
    set $var to that value, and print $exec.
    Example:
      forall($lanuages,$lang,"name[" $lang "]=" translate($lang,title()) "\n")
        #print "Name[es]=Clock del Sol" lines for each installed language
    Then a package that installs translations for a language only
    needs to add a value to the variable $languages, and all menu-methods
    will notice the new language.

I may also add some extra feature that will allow fvwm* etc generate
menudefs.hook files for every language (menudefs-es.hook, etc).
Then maybe someone could hack something in fvwm that it will first
look for a menudefs-$locale.hook file, etc.

Thanks,

-- 
joostje