Re: discovery: debian menu already supports l10n!
Je 1999/12/04(6)/ 7:12, Chris Waters montris sian geniecon skribante:
> joost witteveen <firstname.lastname@example.org> 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
> 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:
For each value in the colon-seperated array $list (eg "en:es:eo"),
set $var to that value, and print $exec.
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.