Re: Tons of useless translations???
On Sat, Nov 27, 1999 at 03:32:52AM +, Nick Lamb <[EMAIL PROTECTED]> wrote: > Doesn't Perl have its own i18n mechanism (if you call gettext "perls own i18n mechanism" then yes. The problem is that xgettext cannot scan perl source). > which GimpPerl could use? No, since the plug-ins cannot translate their menu names (at least it would not be sane to let the plug-ins do it, given the current plug-in architecture). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Tons of useless translations???
On Sat, Nov 27, 1999 at 02:06:25PM +0100, Michael Natterer <[EMAIL PROTECTED]>
wrote:
> I don't quite get what you mean... is gettext unable to parse perl code?
Not only that, look at how the gettext scanning is implemented in automake
(I was unable to use any automake/autoconf support for gettext in perl,
since all of it assumes a rigid directory structure and c source, nothing
else).
I have written my own xgettext replacement (plug-ins/perl/xgettext), so if
anybody knows a good way to merge two distinct .pot files into a common
one, we could just scan using xgettext, scan using pxgettext and merge the
two catalogs.
> > 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 ;-)
Oh, fine, that's just how I'd do it myself ;->>
> - to enable perl, I'll add searching in gimp-perl.mo if finding a translation
> in the other two files fails.
That would, of course be a workaround. I detest, though :(
But wait: how about being able to configure additional text domains for
menu searches throuhg the config file? That would allow to install not
only perl but also other extensions (that have this problem), even after
gimp was installed.
(It might not be workable to have one mo file per plug-in, but it is at
least possible to install plug-ins later, then).
> Don't know if this is a problem with perl, as I didn't understand (see above)
> if parsing perl code works...
No, it doesn't. I could make it work by using N_("") as an exception for
the menu paths, but that's somewhat silly (the perl lingo for this should
be N_"")
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: i18n of menupaths - perl
On 25 Nov, Michael Natterer wrote: > Well, I don't know how to solve this... > ...but I'd vote to put the gimp + plugin + perl + > whatever-is-in-cvs-gimp into _one_ catalog. Hm, but how would you do this... don't forget that some of the plugins are built conditionally > What do you think? Getting translations from the std. "gimp" > textdomain doesn't seem to be a problem for anybody, so this would > also solve the problems with different distributions. You are solving one problem together with introducing a dozen new ones... -- Servus, Daniel
Re: i18n of menupaths - perl
On 24 Nov, Marc Lehmann wrote: > How do I get the perl menupaths into the gimp .po file? it is no > problem to mark them, but the standard xgettext program is not able to > parse perl source. > Should these go into the gimp-std-plugins-file? Should I put all > translations into that file then? Please don't do that... don't even think about it as an temporary solution. If you really want I'll have a closer look on the problems you seem to have discoverd and look for an proper solution... -- Servus, Daniel
Re: Toolbox bug
On 23 Nov, Steinar H. Gunderson wrote: > There seems to be a bug in the toolbox. If you simply make the window > taller (on my system, the threshold seems to be about 380 pixels > high), the gradient selector (and half the color selector) seems to go > under the visible area, and out of sight. Should I look into this > myself, or is there anybody here who could fix this quickly? This bug appeared with the the widget that GIMP uses for its toolbox. IMO this one is too broken to stay for release, the old one approach instead is not that flexible but it actually works... I hereby offer to revert the code to the old behaviour -- Servus, Daniel
Re: Tons of useless translations???
On 25 Nov, Michael Natterer wrote: > However, I still didn't find out why my installation is unable to > lookup translations from "gimp-std-plugins". In GIMP core? I don't know why it should... you are in the wrong doamin -- Servus, Daniel
Re: Tons of useless translations???
On 23 Nov, Marc Lehmann wrote: > When you mean that the translation must be done inside the gimp, then > you are right. One obvious reason is that the plug-in is only queried > once. The translation of menupaths into another language MUST be done by gtk! > However, we need a way to communicate a translation to the gimp. I could extend gtk+ with a function returning the displayed label of a menu Just an idea, though I don't quite know what you'll use it for... --- 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???
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, 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 23 Nov, Michael Natterer wrote: > 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_(). Note: A N_ mark is just a mark and as such an pseudo op. It can't cause bigger executables or alike... But of course you are right that marking such items is senseless since they are already marked somewhere > 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. We DO pass untranslated strings! N_ is a macro which gets replaced by nothing > 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... It'll just save a little bit of preprocessing time and a few bytes is the .po file which won't influence the .mo file... -- Servus, Daniel
Re: Tons of useless translations???
On Thu, 25 Nov 1999, Marc Lehmann wrote: > > 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). Yes. My install procedure goes something like this: ./configure --prefix=/opt/gimp --disable-perl make su -c "rm -rf /opt/gimp; mkdir /opt/gimp; chown glyph /opt/gimp" make install su -c "chown root /opt/gimp -R" (also this option-to-GCC message frequently appears during the compile: -DLOCALEDIR=\""/opt/gimp/share/locale"\" I think that indicates it thinks that's where the locale files should be...) I don't think it could install them anywhere else ... also, 'locate gimp.mo' yeilds nothing. Some discussion on this list has referred to the LINGUAS variable as having something to do with installation of translations, so I tried re[configur|mak|install]ing with LINGUAS set to fr_FR. Nothing happens here. At least, there are no translations installed. > > 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? $ gettext --version gettext (GNU gettext) 0.10.35 Copyright C 1995, 1996, 1997 Free Software Foundation, Inc. Ce progiciel est libre. Consulter les sources pour plus de dtail sur les permissions de copie. Il est distribu SANS AUCUNE GARANTIE de QUALIT LOYALE ET MARCHANDE ou d'ADQUATION POUR UN BUT PARTICULIER. crit par Ulrich Drepper. (Apologies for the lack of accented characters. PINE won't let me type or paste them...) $ locale --version locale (GNU libc) 2.1.2 [same message as above] The bug for me is just that I can't get the translations installed though ... is there a 'manual' way to do this?
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???
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 /Filters/Whatever/foo/bar/bla we need: /Filters /Filters/Whatever /Filters/Whatever/foo /Filters/Whatever/foo/bar (all in gimp.mo) and /Filters/Whatever/foo/bar/bla (in gimp-std-plugins.mo) The trick is: - all submenus (like /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 "/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
