Re: Tons of useless translations???
Marc Lehmann wrote: On Fri, Nov 26, 1999 at 09:45:21PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: It seems your latest commit fixed the problem! Great work! Now it's time for the translators to update the po files and there are still a lot of plug-ins that need to be internationalized. Any volunteers? We still need to work the perl plug-in names in. The problem is that gettext does not support this (and I see no way to modify the makerules without re-writing them totally. Just another reason why automake is evil). I don't quite get what you mean... is gettext unable to parse perl code? IAW: we just lost perl (although the general idea of putting the trabslations into the gimp is fine). PS: does gimp now translate by component or still using the whole path? Gimp translates the whole path and gtk uses it's last component ;-) So, for Image/Filters/Whatever/foo/bar/bla we need: Image/Filters Image/Filters/Whatever Image/Filters/Whatever/foo Image/Filters/Whatever/foo/bar (all in gimp.mo) and Image/Filters/Whatever/foo/bar/bla (in gimp-std-plugins.mo) The trick is: - all submenus (like Image/Guides which is perl-only at the moment) are defined as dummy N_()-marked strings in menus.c. - all plugins have to register with their english names (their "identifiers") - app/menus.c:menu_translate() tries to find a translation in gimp.mo, then in gimp-std-plugins.mo. - to enable perl, I'll add searching in gimp-perl.mo if finding a translation in the other two files fails. - finally, the translations in gimp-std-plugins.mo and gimp-perl.mo are the full paths (e.g. "Image/Guides/Center Guide" becomes "Image/Hilfslinien/Hilflslinie zentrieren") But apart from the fact that the current implementation works, I'd still vote for putting _all_ translations (not only the menus but just any string) into _one_ gimp.mo file. (I don't see another way to correctly translate string which are defined in libgimp (e.g. widgets and used by both the gimp and it's plugins) Don't know if this is a problem with perl, as I didn't understand (see above) if parsing perl code works... bye, --Mitch
Re: Tons of useless translations???
Michael Natterer wrote:
But apart from the fact that the current implementation works, I'd still
vote for putting _all_ translations (not only the menus but just any string)
into _one_ gimp.mo file. (I don't see another way to correctly translate
string which are defined in libgimp (e.g. widgets and used by both the gimp
and it's plugins)
Better idea:
Let's create a separate "libgimp" textdomain and "libgimp/libgimp-intl.h"
which will define _() as dgettext("libgimp", (string)) instead of
gettext(string).
This is the way gtk does it and it looks like the standard solution to
translate libraries. And it would ensure that the widgets' strings are
correctly translated in both the app and plugins.
As menu_translate() is the only function which has to know more than
one domain this might be better than creating one huge file for all
translations.
What do you think?
bye,
--Mitch
Re: Tons of useless translations???
On 23 Nov, Michael Natterer wrote: I did some debugging there and noticed that gettext() returns "/Datei/tearoff1" for _any_ string which has the form "*/tearoff1" (). This is either a bug in our po-files, a bug in gettext or a feature of gettext which allows to do some magic by adding kinof identifiers after a slash? I bet it's a bug in menus.c... Seems we need a guru here... At your service... :) -- Servus, Daniel
Re: Tons of useless translations???
On 27 Nov, Marc Lehmann wrote: PS: does gimp now translate by component or still using the whole path? Componentwise... BTW: Is there any special reson I can't unsubscribe from this list and subscribe again with another address? Quite annoying -- Servus, Daniel
Re: Tons of useless translations???
On 23 Nov, Marc Lehmann wrote: (btw, can anybody tell me why redhat ignores LANG? and what is this LINGUAS thing anyway? maybe because other variables like LC_ALL are also set and take precedence?) LANG will be just used if no other LC_* is set to something... and LINGUAS are all possible languages available, although I don't really know who invented this... -- Servus, Daniel
Re: Tons of useless translations???
Nick Lamb wrote: On Fri, Nov 26, 1999 at 01:03:08AM +0100, Sven Neumann wrote: In French I can say "Fichier-New" and then choose "Type d'image RVB, OK" Resulting image is called "SansTitre-0.0" Well, if would be working correctly, it would say "Fichier/Nouveau...". ... but people are busily re-arranging all the furniture in the Gimp menu hierarchy, so "working correctly" will have to live with what it can for now. After my last compile I am now getting File-Nouveau, so hopefully tomorrow I can expect Fichier-Nouveau... at last. No Fichier-Fichier-Fichier here, if there was I would be figuring out why it was broken (even though I don't speak French) does someone who IS seeing this bug have the time to investigate it properly? Well, the Fichier-Fichier-Fichier bug is actually fixed by my last checkin. I didn't fix it by tracking down the problem but by replacing all the useless translations of the .../tearoff1 entries by entries which actually define the menu branches. (gettext returned "Fichier" for just any string ending in .../tearoff1) My installation suffered from the old problem and still is not able to look up translations from "gimp-std-plugins" So my question to the deveopers: Does anyone have the plugin names (not the paths) correctly translated in the menu hierarchy??? ciao, --Mitch
Re: Tons of useless translations???
Mitch wrote: My installation suffered from the old problem and still is not able to look up translations from "gimp-std-plugins" So my question to the deveopers: Does anyone have the plugin names (not the paths) correctly translated in the menu hierarchy??? It seems your latest commit fixed the problem! Great work! Now it's time for the translators to update the po files and there are still a lot of plug-ins that need to be internationalized. Any volunteers? Salut, Sven
Re: Tons of useless translations???
On Fri, Nov 26, 1999 at 09:45:21PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: It seems your latest commit fixed the problem! Great work! Now it's time for the translators to update the po files and there are still a lot of plug-ins that need to be internationalized. Any volunteers? We still need to work the perl plug-in names in. The problem is that gettext does not support this (and I see no way to modify the makerules without re-writing them totally. Just another reason why automake is evil). IAW: we just lost perl (although the general idea of putting the trabslations into the gimp is fine). PS: does gimp now translate by component or still using the whole path? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Tons of useless translations???
On Sat, Nov 27, 1999 at 03:23:02AM +0100, Marc Lehmann wrote: We still need to work the perl plug-in names in. The problem is that gettext does not support this (and I see no way to modify the makerules without re-writing them totally. Just another reason why automake is evil). Doesn't Perl have its own i18n mechanism which GimpPerl could use? It make sense that GimpPerl would be consistent in behaving just like any other Perl component for i18n as much as it does for everything else? If Perl doesn't have any i18n, then (1) That sucks and (2) Gimp can't do much about it. If I missed some stupidly obvious obstacle to this then I apologise, I don't use GimpPerl so I don't know very much about it. Nick.
Re: Tons of useless translations???
Sven Neumann wrote: The string gets passed through menu_translate when the labels are build, so it should work for all menus. Hmm, I have now changed this. A problem is that there is no table for "Image/Filters/Blur/tearoff1" or "Image/Filters/Blur" in gimp.pot or gimp-std-plgins.pot. The menu translating function in gtk uses only a last item of menu path... I'd vote for creating such menusentries in the core. Not only to solve this problem (that can eventually be solved another way), but so that we can put the Filter menus into a nice order with seperators etc. Right. I will checkin a patch today which defines all submenus under Image/Filters. And I've removed all predefined tearoff entries and defined the menu branches instead. This gives us proper translation for the submenus. (The tearoffs are built on the fly then). However, I still didn't find out why my installation is unable to lookup translations from "gimp-std-plugins". Marc, to add an entry to your which-distribution-is-the-evil-one: I use Suse 6.1, gettext 0.10.35 and glib, gtk and gimp from cvs (of course ;-) bye, --Mitch
Re: Tons of useless translations???
On Wed, Nov 24, 1999 at 06:10:29PM -0500, Federico Mena Quintero [EMAIL PROTECTED]
wrote:
Please note that "LANG=de" will not work
Really? It works fine on all my systems (and also some non-linux systems)
;) It does not work, though, on the redhat systems I recently saw.
Please read the libc
From the libc documentation:
"Later we will describe how to construct locales XXX."
Hmm, no help there.
and gettext documentation for information about
From the gettext documentation:
"For example, let's presume a German site. At the shell prompt, users
merely have to execute `setenv LANG de' (in `csh') or `export LANG;
LANG=de' (in `sh')."
(I should have read that part of the info docs long ago, since it also
describes LINGUAS one page earlier!)
These kind of examples are scattered throughout the gettext documentation,
e.g.:
/* Change language. */
setenv ("LANGUAGE", "fr", 1);
I have not found a formal description of what goes into LANG, though,
there.
So LANG=de is in full accordance with the gettext and libc documentation
(and unix documentation as well) AND actual reality.
[LINGUAS is used to specify which languages you care about when
installing translations; a French person may not want to have to
install Chinese translations.]
Thanks for the explanation! This sounds highly useful ;)
I18N seems so highly complicated that everybody disagrees on how it works
on not :(
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: Tons of useless translations???
For me at least, i686 based RH 6.1 on two machines (one more "out of box" than the other, but neither of them's been extensively hacked) builds a working and i18n'd Gimp no problem. In French I can say "Fichier-New" and then choose "Type d'image RVB, OK" Resulting image is called "SansTitre-0.0" Well, if would be working correctly, it would say "Fichier/Nouveau...". And this is a bad example since most people seem to have problems with the translation of the plugins. So the question is does if you get the entry Fichier in lots of places where it shouldn't be. If you'd get it, you'd know what I speak of (Fichier-Fichier-Fichier). And, yes I can reproduce this on a set of different machines. There's no need to question Marc's statement... Salut, Sven
Re: Tons of useless translations???
On Tue, 23 Nov 1999, Marc Lehmann wrote: On Tue, Nov 23, 1999 at 03:27:54PM -0500, Glyph Lefkowitz [EMAIL PROTECTED] wrote: (btw, can anybody tell me why redhat ignores LANG? and what is this LINGUAS thing anyway? maybe because other variables like LC_ALL are also set and take precedence?) You may find this interesting. Upon launching a shell (before changing my configuration as described below): [glyph@helix ~]$ echo $LC_ALL en_US [glyph@helix ~]$ echo $LANG en_US [glyph@helix ~]$ echo $LINGUAS en_US Ok, try this: LC_ALL=fr gimp I installed the Locale configuration stuff for RH, then set my locale to fr_FR. I now have this: [glyph@helix ~]$ locale LANG=fr_FR LC_CTYPE="fr_FR" LC_NUMERIC="fr_FR" LC_TIME="fr_FR" LC_COLLATE="fr_FR" LC_MONETARY="fr_FR" LC_MESSAGES="fr_FR" LC_ALL=fr_FR [glyph@helix ~]$ gimp Message: Passed serialization test Still, nothing is different! However, [glyph@helix ~]$ ls -al /opt/gimp/share/locale/ total 8 drwxr-xr-x 2 glyphusers4096 Nov 23 18:12 ./ drwxr-xr-x 5 glyphusers4096 Nov 23 18:12 ../ That can't be good. I've checked out a recent CVS ... nothing is installing into the Locale directory! BTW: I was just told that redhat 6.1 was released quite some time _before_ glibc-2.1 was released. Maybe they have used a slightly patched libc? (no flame intended) I don't believe that's true ... when was glibc 2.1 released? RH 6.1 is pretty recent. At least, if my locale is properly set (all those env vars above), I don't get any "C library does not support locale" messages. At any rate, all GNU utils print out messages in french now. Is there something I need to do to get gimp to be localized? Thanks, --glyph
Tons of useless translations???
Hello Marc, 23. Nov 1999 Marc Lehmann wrote: ML Sven, do you use redhat? anybody here with the same problem but ML not ML on redhat? no, but I use RedHat and I don't suffer from this problem... crazy, isn't it ? (RedHat 5.0, kernel 2.0.36, glibc 2.0.7, 'setenv LANG sk' actually works !) Bedo.
Re: Tons of useless translations???
Still, nothing is different! However, [glyph@helix ~]$ ls -al /opt/gimp/share/locale/ Ok... have you compiled gimp yourself to this location? If yes, maybe gimp errornously installs its locale files somewhere else (and doesn'T find it anymore). That can't be good. I've checked out a recent CVS ... nothing is installing into the Locale directory! Well: *cerebro:~# ll /usr/app/share/locale/fr/LC_MESSAGES/ -rw-r--r-- 1 root root 105113 Nov 23 02:11 gimp.mo (that's when I last typed "make install"). But, not surprisingly, LANG=fr gives me a (sparsely translated) french gimp menu. I don't believe that's true ... OK Is there something I need to do to get gimp to be localized? Thanks, In theory (and in pratcise on my machine) all you need to do is "LANG=fr gimp". This also happens to work on many machines, but it also does not work on many others. What does gettext --version (and locale --version) say on your system? (Yes, I am just seeking the difference in setups) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Tons of useless translations???
Hi all, I just studied the GtkItemFactory code... It seems we're doing _many_ useless translations in the menu system. For example all calls to menus_set_sensitive() et.al. are using strings which are marked with N_(). However it's totally sufficient to pass the untranslated (english) text to _all_ item factory functions because GtkItemFactory uses the translate function _only_ when creating the menu labels. These label are never touched after creation, as the menu paths are stored separately and untranslated. I'm quite sure that I got the semantics of the item factory code right. Could anyone verify this please? It could save us lots of work and reduce the size of the po files drastically... I think you are right that marking the strings for translation is not needed in a few places, but changing this will not significantly reduce the size of the po files since duplicate strings are only listed once in the gimp.pot file. BTW: I came to the conclusion that plug-ins should register their menu entries using the N_(...) macro, not the _(...) macro. This is now done inconsistently. As my setup still suffers from the problem that all plug-in menu paths are translated to "Datei", I can not really test if I'm correct here. What do you think? Salut, Sven
Re: Tons of useless translations???
Sven Neumann wrote: Hi all, I just studied the GtkItemFactory code... It seems we're doing _many_ useless translations in the menu system. For example all calls to menus_set_sensitive() et.al. are using strings which are marked with N_(). However it's totally sufficient to pass the untranslated (english) text to _all_ item factory functions because GtkItemFactory uses the translate function _only_ when creating the menu labels. These label are never touched after creation, as the menu paths are stored separately and untranslated. I'm quite sure that I got the semantics of the item factory code right. Could anyone verify this please? It could save us lots of work and reduce the size of the po files drastically... I think you are right that marking the strings for translation is not needed in a few places, but changing this will not significantly reduce the size of the po files since duplicate strings are only listed once in the gimp.pot file. I have already patched my local tree: - removed the menus_set_[sensitive|state]_glue() functions - changed all calls to the ones without "_glue" - removed N_() from all calls to these functions. ...and it works. The english strings are the _identifiers_ by which the GtkItemFactory finds the item to (un)sensitive. The translations are only used to create the menu labels and are totally irrelevant afterwards. BTW: I came to the conclusion that plug-ins should register their menu entries using the N_(...) macro, not the _(...) macro. This is now done inconsistently. As my setup still suffers from the problem that all plug-in menu paths are translated to "Datei", I can not really test if I'm correct here. What do you think? You're right, the plugins have to register with their english menu paths. The translation is done only in menus.c:menu_translate() which _only_ gets called from gtk_item_factory_create_item(), so we have to mark only the strings which finally are passed to this function and none of the strings which are passed to other GtkItemFactory functions. I did some debugging there and noticed that gettext() returns "/Datei/tearoff1" for _any_ string which has the form "*/tearoff1" (). This is either a bug in our po-files, a bug in gettext or a feature of gettext which allows to do some magic by adding kinof identifiers after a slash? Seems we need a guru here... bye, --Mitch
Re: Tons of useless translations???
BTW: I came to the conclusion that plug-ins should register their menu entries using the N_(...) macro, not the _(...) macro. This is now done inconsistently. I agree that for the plug-ins placed out of Image/Filters hierarchy like "Image/Layers/Rotate/180 degrees". But how will we treat menus like Image/Filters/Blur. should we use dummyMenus[] for the all menus under Image/Filters and Image/Script-Fu ? -- yasuhiro
Re: Tons of useless translations???
On Tue, Nov 23, 1999 at 06:29:42PM +0100, Michael Natterer [EMAIL PROTECTED] wrote: I did some debugging there and noticed that gettext() returns "/Datei/tearoff1" for _any_ string which has the form "*/tearoff1" (). Hmm.. ;) this could explain the problems we encounter (at least it gives a clue). This is either a bug in our po-files, a bug in gettext or a feature of gettext which allows to do some magic by adding kinof identifiers after a slash? I looked through my libc source and gettext-0.10.35, and both of these do a simple strcmp (after a hash table search) to find the translation. Well, I also do not have the duplicated menu item problem. Michael, what kind of linux distro are you using? BTW: [EMAIL PROTECTED], who reported the duplicated menu problem yesterday, uses a version of redhat 6.0+patches (fixpacks??). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
