Re: [PATCH] improving on i18n
On Wed, 2000-12-06 at 15:24:58, Zbigniew Chyla wrote:
> (...)
> Thanks tor this! It should be no problem for translators - I have another
> patch, that doesn't _require_ modified translations. If you replace
> _("File") with Q_("!menu!File") in your code, old translations (containing
> only "File") will still work. I'll send improved patch tomorrow.
Attached patch implements new version of the Q_() macro. As I said before,
adding new prefixes to strings doesn't break existing translations.
This time I don't include whole po/Makefile.in.in but only small patch
adding "--keyword=Q_" to the list of xgettext options. Patch is being
applied by autogen.sh after running gettextize. Many GNOME apps
(eg. gnumeric) modify po/Makefile.in.in this way.
Zbigniew
diff -ruN /home/cyba/gcvs/gimp/ChangeLog gimp/ChangeLog
--- /home/cyba/gcvs/gimp/ChangeLog Sun Dec 3 20:16:03 2000
+++ gimp/ChangeLog Wed Dec 6 19:32:58 2000
@@ -1,3 +1,33 @@
+2000-12-06 Zbigniew Chyla <[EMAIL PROTECTED]>
+
+ I18n improvement - added support for Q_() macro (replacement for _()
+ allowing to add a prefix of the form "!some_prefix!" to the
+ string and thus making it possible to translate it differently in
+ different contexts).
+
+ * libgimp/gimpintl.h, libgimp/libgimp-intl.h: included "gimputils.h",
+ defined Q_() macro.
+
+ * libgimp/gimputils.h: added functions declarations:
+ gimp_i18n_qualifier_prefix_gettext(),
+ gimp_i18n_qualifier_prefix_dgettext(),
+ gimp_i18n_qualifier_prefix_noop().
+
+ * libgimp/gimputils.c: included "gimpintl.h", added functions:
+ gimp_i18n_qualifier_prefix_gettext(),
+ gimp_i18n_qualifier_prefix_dgettext(),
+ gimp_i18n_qualifier_prefix_noop().
+
+ * autogen.sh: patching po/Makefile.in.in (with
+ po/Makefile.in.in.i18npatch) after running gettextize.
+
+ * po/Makefile.in.in.i18n: new file - patch for po/Makefile.in.in (file
+ provided by gettextize), adds "--keyword=Q_" to the list of xgettext
+ options.
+
+ * po-libgimp/Makefile.in.in, po-plug-ins/Makefile.in.in: added
+ "--keyword=Q_" to the list of xgettext options.
+
2000-11-30 Andy Thomas <[EMAIL PROTECTED]>
* app/curves.c
diff -ruN /home/cyba/gcvs/gimp/libgimp/gimputils.h gimp/libgimp/gimputils.h
--- /home/cyba/gcvs/gimp/libgimp/gimputils.hThu Nov 23 12:38:50 2000
+++ gimp/libgimp/gimputils.hWed Dec 6 19:32:58 2000
@@ -45,13 +45,12 @@
const gchar *exceptions);
gchar * gimp_strcompress (const gchar *source);
#endif /* GLIB <= 1.3 */
-
+gchar *gimp_i18n_qualifier_prefix_gettext (const gchar *string);
+gchar *gimp_i18n_qualifier_prefix_dgettext (const gchar *domain, const gchar *string);
+gchar *gimp_i18n_qualifier_prefix_noop (const gchar *string);
#ifdef __cplusplus
}
#endif /* __cplusplus */
#endif /* __GIMPUTILS_H__ */
-
-
-
diff -ruN /home/cyba/gcvs/gimp/libgimp/libgimp-intl.h gimp/libgimp/libgimp-intl.h
--- /home/cyba/gcvs/gimp/libgimp/libgimp-intl.h Thu Nov 23 12:38:50 2000
+++ gimp/libgimp/libgimp-intl.h Wed Dec 6 19:32:58 2000
@@ -22,10 +22,12 @@
#ifndef __LIBGIMP_INTL_H__
#define __LIBGIMP_INTL_H__
+#include "gimputils.h"
#ifdef ENABLE_NLS
#include
#define _(String) dgettext ("gimp-libgimp", String)
+#define Q_(String) gimp_i18n_qualifier_prefix_dgettext ("gimp-libgimp", String)
#undef gettext
#define gettext(String) dgettext ("gimp-libgimp", String)
#ifdef gettext_noop
@@ -37,6 +39,7 @@
/* Stubs that do something close enough. */
#define gettext(String) (String)
#define _(String) (String)
+#define Q_(String) gimp_i18n_qualifier_prefix_noop (String)
#define N_(String) (String)
#endif
diff -ruN /home/cyba/gcvs/gimp/libgimp/gimpintl.h gimp/libgimp/gimpintl.h
--- /home/cyba/gcvs/gimp/libgimp/gimpintl.h Thu Nov 23 12:38:48 2000
+++ gimp/libgimp/gimpintl.h Wed Dec 6 19:32:58 2000
@@ -25,6 +25,8 @@
#include
#include
+#include "gimputils.h"
+
/* Copied from gnome-i18n.h by Tom Tromey <[EMAIL PROTECTED]>
* Heavily modified by Daniel Egger <[EMAIL PROTECTED]>
* So be sure to hit me instead of him if something is wrong here
@@ -40,6 +42,7 @@
#ifdef ENABLE_NLS
#include
#define _(String) gettext (String)
+#define Q_(String) gimp_i18n_qualifier_prefix_gettext (String)
#ifdef gettext_noop
#define N_(String) gettext_noop (String)
#else
@@ -53,6 +56,7 @@
#define dcgettext(Domain,Message,Type) (Message)
#define bindtextdomain(Domain,Directory) (Domain)
#define _(String) (String)
+#define Q_(String) gimp_i18n_qualifier_prefix_noop (String)
#define N_(String) (String)
#endif
diff -ruN /home/cyba/gcvs/gimp/libgimp/gimp
Re: [PATCH] improving on i18n
On Wed, 2000-12-06 at 14:19:02, Sven Neumann wrote:
> I have discussed your patch with Mitch and it really looks safe. The
> problem we see is that most likely translators will find a lot of
> collisions and each string marked with your Q_ macro will end up being
> untranslated in all languages until translators change the po-files
> (...)
Thanks tor this! It should be no problem for translators - I have another
patch, that doesn't _require_ modified translations. If you replace
_("File") with Q_("!menu!File") in your code, old translations (containing
only "File") will still work. I'll send improved patch tomorrow.
> I'd still prefer a clean solution that would give every translator the
> chance to apply different translations for every string without the need
> to change the original string. This would make it possible to work around
> (...)
So do I :-)
Believe me, I _hate_ gettext, but it's the only thing we have _now_.
Zbigniew
Re: [PATCH] improving on i18n
Zbigniew Chyla <[EMAIL PROTECTED]> writes: > This patch _fixes_ GIMP translations. Currently it's _impossible_ to > correctly translate GIMP to any slavic language (and probably many others). > Polish GIMP users keep saying "Can you speak Polish? Translation is broken!" > and the only thing we can say is "Sorry, it's developers' fault, but please > wait another 1-2 years for GIMP 1.4/2.0 release and hopefully it will be > useable". > Patch is extremely simple, it doesn't touch existing code at all. Why don't > you like it? I have discussed your patch with Mitch and it really looks safe. The problem we see is that most likely translators will find a lot of collisions and each string marked with your Q_ macro will end up being untranslated in all languages until translators change the po-files again. Since we want to release 1.2.0 real soon now this change would significantly degrade the status of i18n we have reached so far. I suggest we reconsider applying your patch after 1.2.0 so it could become part of the 1.2.x series but early enough before a release to give translators a chance to update translations. To do so we'd need a list of colliding strings from all translators as soon as possible. I'd still prefer a clean solution that would give every translator the chance to apply different translations for every string without the need to change the original string. This would make it possible to work around collisions without breaking the translation for all other supported languages. Salut, Sven
Re: [PATCH] improving on i18n
On Tue, Dec 05, 2000 at 09:40:28PM +, Nick Lamb <[EMAIL PROTECTED]> wrote: > > And givne that a large amount of similar fixes went into the gimp not too > > long ago this patch really should be considered. > > Those fixes made Gimp have more bugs. No more patches like that thanks. Well, those patches actually made i18n work again. so if they added new bugs the patches were problematic. so this means a patch must be looked at on a per-patch-basis. Anyway, if Sven *still* does not want that that's reason enough for me to also now want it ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [PATCH] improving on i18n
On Tue, Dec 05, 2000 at 07:39:11PM +0100, Marc Lehmann wrote: > > This patch _fixes_ GIMP translations. Currently it's _impossible_ to > > And givne that a large amount of similar fixes went into the gimp not too > long ago this patch really should be considered. Those fixes made Gimp have more bugs. No more patches like that thanks. Nick.
Re: [PATCH] improving on i18n
On Tue, Dec 05, 2000 at 05:34:18PM +0100, Zbigniew Chyla <[EMAIL PROTECTED]> wrote: > > Probably a good idea, but I doubt we can count this as a bugfix. We > > should consider integrating a fix like this after the 1.2 release. > > This patch _fixes_ GIMP translations. Currently it's _impossible_ to And givne that a large amount of similar fixes went into the gimp not too long ago this patch really should be considered. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [PATCH] improving on i18n
Hi, Zbigniew Chyla <[EMAIL PROTECTED]> writes: > On Tue, 2000-12-05 at 16:01:17, Sven Neumann wrote: > > > Probably a good idea, but I doubt we can count this as a bugfix. We > > should consider integrating a fix like this after the 1.2 release. > > This patch _fixes_ GIMP translations. Currently it's _impossible_ to > correctly translate GIMP to any slavic language (and probably many others). > Polish GIMP users keep saying "Can you speak Polish? Translation is broken!" > and the only thing we can say is "Sorry, it's developers' fault, but please > wait another 1-2 years for GIMP 1.4/2.0 release and hopefully it will be > useable". > Patch is extremely simple, it doesn't touch existing code at all. Why don't > you like it? Because we are very close to the stable release we are working towards for over a year now. I18n is its final state for months and noone complained about it recently. Every time we changed stuff with respect to i18n, it produced lots of problems and I'm very happy that it seems to be working for most people now. We are not going to change anything here before 1.2. > > But actually I would prefer a real solution instead of something hacked > > around gettext. > > What do you expect me to do? Create replacement for gettext? Actually yes. I hope that a better system than gettext evolves so we can use it for the 1.3.x series. > I want GIMP _1.2_ to be correctly translated and I don't see any other > proposals besides my patch. Sorry, I don't see any solution either. It's simply too late to fix this know. Salut, Sven
Re: [PATCH] improving on i18n
On Tue, 2000-12-05 at 16:01:17, Sven Neumann wrote: > Probably a good idea, but I doubt we can count this as a bugfix. We > should consider integrating a fix like this after the 1.2 release. This patch _fixes_ GIMP translations. Currently it's _impossible_ to correctly translate GIMP to any slavic language (and probably many others). Polish GIMP users keep saying "Can you speak Polish? Translation is broken!" and the only thing we can say is "Sorry, it's developers' fault, but please wait another 1-2 years for GIMP 1.4/2.0 release and hopefully it will be useable". Patch is extremely simple, it doesn't touch existing code at all. Why don't you like it? > But actually I would prefer a real solution instead of something hacked > around gettext. What do you expect me to do? Create replacement for gettext? Actually I _am_ going to create one, but I doubt whether it could be done before the 1.2 release and even if I manage to do this, I'm sure you wold say "I doubt we can count this as a bugfix". I want GIMP _1.2_ to be correctly translated and I don't see any other proposals besides my patch. Zbigniew -- "GNOME is an open, free, and productive desktop environment that sparks innovation and excitement among users and developers worldwide. Microsoft Windows is not." -- Sun Microsystems
Re: [PATCH] improving on i18n
Zbigniew Chyla <[EMAIL PROTECTED]> writes: > As you probably already know there are lots of problems with current i18n > tools. Every genuine inscription can have only one equivalent in particular > language when using gettext. In the case of GIMP this is really serious > problem because of huge .po files (and thus many collisions). > The authors of Freeciv worked out an easy method of the partial solving this > problem. My patch is based on code from Freeciv. > Every string marked for translation can be preceded with a prefix in the > form "!prefix!". Thanks to this prefix, two appearances of the same > string can have different meanings. The prefix can be omited in > translated string, but leaving it will not influence displayed text because > it will be always stripped (it is helpful for translators who don't know > this solution). You should just use Q_() macro instead of _() in your code > to use this feature. Probably a good idea, but I doubt we can count this as a bugfix. We should consider integrating a fix like this after the 1.2 release. But actually I would prefer a real solution instead of something hacked around gettext. Salut, Sven
[PATCH] improving on i18n
As you probably already know there are lots of problems with current i18n tools. Every genuine inscription can have only one equivalent in particular language when using gettext. In the case of GIMP this is really serious problem because of huge .po files (and thus many collisions). The authors of Freeciv worked out an easy method of the partial solving this problem. My patch is based on code from Freeciv. Every string marked for translation can be preceded with a prefix in the form "!prefix!". Thanks to this prefix, two appearances of the same string can have different meanings. The prefix can be omited in translated string, but leaving it will not influence displayed text because it will be always stripped (it is helpful for translators who don't know this solution). You should just use Q_() macro instead of _() in your code to use this feature. Please take a look at the first attached patch and tell me if you like it. The only problem I can see is setting "--force" option when calling gettextize from autogen.sh. I added po/Makefile.in.in file to my patch (version provided by gettextize doesn't contain "--keyword=Q_" option for xgettext) and calling "gettextize --copy --force" would overwrite my po/Makefile.in.in. I removed "--force" from autogen.sh, but someone put there a comment saying "(...) otherwise things don't get added reliably". Is really something wrong with calling gettextize without "--force" option? If yes, what would you suggest instead? If you accept this patch, I'm going to commit another one, using newly defined Q_() macro (second attachment). Ofcourse there will be more patches like this one in the future as we (translators) detect more collisions. Zbigniew -- "GNOME is an open, free, and productive desktop environment that sparks innovation and excitement among users and developers worldwide. Microsoft Windows is not." -- Sun Microsystems diff -ruN /home/aliens/cyba/gcvs/current/gimp/ChangeLog gimp/ChangeLog --- /home/aliens/cyba/gcvs/current/gimp/ChangeLog Mon Dec 4 16:55:30 2000 +++ gimp/ChangeLog Tue Dec 5 14:00:14 2000 @@ -1,3 +1,27 @@ +2000-12-05 Zbigniew Chyla <[EMAIL PROTECTED]> + + I18n improvement - added support for Q_() macro (replacement for _() + allowing to add a prefix of the form "!some_prefix!" to the + string and thus making it possible to translate it differently in + different contexts). + + * libgimp/gimputils.c: added gimp_i18n_skip_qualifier_prefix() + function. + + * libgimp/gimputils.h: included , added + gimp_i18n_skip_qualifier_prefix function declaration. + + * libgimp/gimpintl.h, libgimp/libgimp-intl.h : included + "gimputils.h", added Q_() macro. + + * po-libgimp/Makefile.in.in, po-plug-ins/Makefile.in.in: using + "--keyword=Q_" option when executing xgettext. + + * po/Makefile.in.in: new file, using "--keyword=Q_" option when + executing xgettext. + + * autogen.sh: executing gettextize without "--force" option. + 2000-12-03 Sven Neumann <[EMAIL PROTECTED]> * app/gimpimage.c: when merging layers, do not set the layer mode diff -ruN /home/aliens/cyba/gcvs/current/gimp/autogen.sh gimp/autogen.sh --- /home/aliens/cyba/gcvs/current/gimp/autogen.sh Sun Nov 12 03:51:51 2000 +++ gimp/autogen.sh Tue Dec 5 13:41:06 2000 @@ -100,10 +100,7 @@ fi echo "Running gettextize... Ignore non-fatal messages." -# Hmm, we specify --force here, since otherwise things dont' -# get added reliably, but we don't want to overwrite intl -# while making dist. -echo "no" | gettextize --copy --force +echo "no" | gettextize --copy autogen_dirs="." #if test -z "$NO_GCG"; then diff -ruN /home/aliens/cyba/gcvs/current/gimp/libgimp/gimpintl.h gimp/libgimp/gimpintl.h --- /home/aliens/cyba/gcvs/current/gimp/libgimp/gimpintl.h Tue Oct 31 18:10:59 2000 +++ gimp/libgimp/gimpintl.h Tue Dec 5 13:41:06 2000 @@ -25,6 +25,8 @@ #include #include +#include "gimputils.h" + /* Copied from gnome-i18n.h by Tom Tromey <[EMAIL PROTECTED]> * Heavily modified by Daniel Egger <[EMAIL PROTECTED]> * So be sure to hit me instead of him if something is wrong here @@ -40,6 +42,7 @@ #ifdef ENABLE_NLS #include #define _(String) gettext (String) +#define Q_(String) gimp_i18n_skip_qualifier_prefix (gettext (String)) #ifdef gettext_noop #define N_(String) gettext_noop (String) #else @@ -53,6 +56,7 @@ #define dcgettext(Domain,Message,Type) (Message) #define bindtextdomain(Domain,Directory) (Domain) #define _(String) (String) +#define Q_(String) gimp_i18n_skip_qualifier_prefix (String) #define N_(String) (String) #en
Re: Gimp + Solaris + i18n
On Fri, Nov 10, 2000 at 07:31:35PM +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: these issues aside...: > Ehm, this is AFAIK not a valid locale setting. For which OS, distribution and local configuration? The problems with perl (perl is the only component that warns by default when it cannot set the locale requested by the user) made me aware of the fact that most linux distributions set LANG or LC_ALL to something like "fr" or "de" without actually havig such a locale (e.g. it was never effective). That glibc uses the LC_MESSAGE settings regardless of wether setlocale was called or wether setlocate even succeded does not improve on this. > know if my working locale stuff comes from some mystic environment > variables that were set when compiling gtk+ and gimp. (there are > lots of mystic variables set in the university's heterogeneous > network) ;) And it's far from clear what the semantics of setlocale should be (as this depends on the local configuration, e.g. I do have a full de locale, but who else has?). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Gimp + Solaris + i18n
[EMAIL PROTECTED] (Raphael Quinet) writes: > On Fri, 10 Nov 2000, David Monniaux <[EMAIL PROTECTED]> wrote: > > I compiled Gimp under Solaris with --with-included-gettext. Trying to run > > it with LANG=fr... does not yield anything translated. Nevertheless, Gimp > > seems to load the translation file (seen in strace). > > > > Has anyone else noticed this behavior, or is it my setup? > > I compiled Gimp 1.1.29 under Solaris 2.6 without the included gettext > (I have GNU gettext 0.10.35 installed in my path, and "configure" is > happy with it). I had never tried to set LANG=fr under Solaris, so I > just tried to see if I had any problems. Well, I got the answer in > less than 2 seconds... > > csh> setenv LANG fr > csh> gimp Ehm, this is AFAIK not a valid locale setting. LC_ALL=fr_FR gimp or LC_MESSAGES=fr_FR gimp works fine for me. OTOH it took me days to get the beast running on Solaris and I don't know if my working locale stuff comes from some mystic environment variables that were set when compiling gtk+ and gimp. (there are lots of mystic variables set in the university's heterogeneous network) ;) Another important point to mention is that GIMP wants to be compiled with the same version of gettext that GTK was compiled with, which should not be solaris gettext (didn't work for me) but GNU gettext. So compiling GTK with some GNU gettext lying around (not linking against it because that's the job of the app which links against GTK) _and_ GIMP with --with-included-gettext should do the job because then GTK will use the GNU gettext that ships with the GIMP tarball. bye, --Mitch
Re: Gimp + Solaris + i18n
On Fri, 10 Nov 2000, Raphael Quinet wrote: > I compiled Gimp 1.1.29 under Solaris 2.6 without the included gettext > (I have GNU gettext 0.10.35 installed in my path, and "configure" is I was referring to CVS Gimp _with_ the included gettext. 1.1.29 with the Solaris gettext runs into memory corruption and segfaults when building the list of file loading procedures. Try 1.1.29 with the included gettext. It should work fine. David Monniauxhttp://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France
Re: Gimp + Solaris + i18n
On Fri, 10 Nov 2000, David Monniaux <[EMAIL PROTECTED]> wrote: > I compiled Gimp under Solaris with --with-included-gettext. Trying to run > it with LANG=fr... does not yield anything translated. Nevertheless, Gimp > seems to load the translation file (seen in strace). > > Has anyone else noticed this behavior, or is it my setup? I compiled Gimp 1.1.29 under Solaris 2.6 without the included gettext (I have GNU gettext 0.10.35 installed in my path, and "configure" is happy with it). I had never tried to set LANG=fr under Solaris, so I just tried to see if I had any problems. Well, I got the answer in less than 2 seconds... csh> setenv LANG fr csh> gimp gimp: fatal error: Segmentation Fault gimp (pid:15480): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0xef560cb8 in g_on_error_stack_trace (prg_name=0xec24 "gimp") #1 0xef560ba8 in g_on_error_query (prg_name=0xec24 "gimp") at gerror.c:133 #2 0x801d4 in gimp_fatal_error (fmt=0xef30e916 "Segmentation Fault") #3 0xdf2a4 in gimp_sigfatal_handler (sig_num=11) at main.c:464 #4 #5 0xef29c2c4 in key_2_text () #6 0xef29c188 in dcgettext_u () #7 0xef29ba0c in gettext () #8 0x343f8 in make_initialization_status_window () at app_procs.c:373 #9 0x34970 in app_init () at app_procs.c:502 #10 0x33c40 in gimp_init (gimp_argc=0, gimp_argv=0xeb20) at app_procs.c:138 #11 0xdf238 in init () at main.c:430 #12 0x140228 in user_install_verify (user_install_callback=0xdf220 ) #13 0xdf1fc in main (argc=1, argv=0xeb1c) at main.c:396 It crashed before opening any windows. I tried "truss" to see the list of system calls that are done before crashing, and I see that it crashes soon after opening and mmap'ing ".../lib/locale/fr/LC_MESSAGES/gimp.mo". So it does open the file, but it crashes immediately afterwards. -Raphael
Gimp + Solaris + i18n
I compiled Gimp under Solaris with --with-included-gettext. Trying to run it with LANG=fr... does not yield anything translated. Nevertheless, Gimp seems to load the translation file (seen in strace). Has anyone else noticed this behavior, or is it my setup? David Monniauxhttp://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France
Re: Gimp Wishes (i18n and jpeg)
On Wed, Apr 05, 2000 at 06:56:43PM +0100, Nick Lamb wrote: >Have now, it makes no difference, so that's another factor eliminated. >In fact, the integer code seems to produce the same image data as the >float code On my machine, the FP code usually generates _slightly_ (think 40-50 bytes) smaller files than the integer version. (I'm unable to find any quality improvement.) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: Gimp Wishes (i18n and jpeg)
On Wed, Apr 05, 2000 at 12:38:45PM +0100, Nick Lamb wrote: > I suspect that choosing a non-integer implementation (which might be > faster on modern Intel hardware) would increase the damage from > subsequent cycles, but I've never tested that. Have now, it makes no difference, so that's another factor eliminated. In fact, the integer code seems to produce the same image data as the float code, unless Gimp's JPEG UI doesn't work how I think it does. Nick.
Re: Gimp Wishes (i18n and jpeg)
On Wed, Apr 05, 2000 at 04:40:37PM +1000, Ian Boreham wrote: > From my understanding of JPEG (which is not expert), I would have thought > that although there might be a small loss of quality on subsequent cycles, > due to rounding-type errors, there would not be anywhere near the same as > the initial loss due to discarding high-order, low-coefficient data. > Discarding this data is effectively setting the coefficients to zero, so > you would be roughly discarding zero on subsequent cycles. You are correct, but only when the same implementation is being used. It is quite possible that rounding errors will be introduced by varying the algorithm, so although this will often work IN PRACTICE, it is not something to be relied upon. > Has anyone tried cycling and differencing to see the effect? Yes. Marc is right only in principle, not in practice. In tests on real photo data (which is the only thing you should be shoving through a JPEG codec anyway) I found that ~1% of tiles were damaged during the second cycle, and much fewer if any were changed by subsequent cycles. This is testing with RH 6.2's libjpeg package, Gimp defaults, 75% quality. I suspect that choosing a non-integer implementation (which might be faster on modern Intel hardware) would increase the damage from subsequent cycles, but I've never tested that. For my purposes it is enough that guessing the Q factor is a win, though not one we can easily automate. I have said all this before, is there a problem with the list? Or is Marc ignoring everything I say? Nick.
Re: Gimp Wishes (i18n and jpeg)
At 06:21 AM 4/5/00 +0200, Marc Lehmann <[EMAIL PROTECTED]> wrote: >You got it wrong: saving a jpeg in ANY quality (higher or lower) causes loss >of quality. Saving in the same quality as the original image causes quality >loss depending on the selected quality. > >As I said, the only effect is a similar(!) file size, and that every save >would cause about the same amount of quality loss. >From my understanding of JPEG (which is not expert), I would have thought that although there might be a small loss of quality on subsequent cycles, due to rounding-type errors, there would not be anywhere near the same as the initial loss due to discarding high-order, low-coefficient data. Discarding this data is effectively setting the coefficients to zero, so you would be roughly discarding zero on subsequent cycles. >Jpeg is lossy, in whatever quality you save your files. If you save your >file in 75% percent, load it again, and cycle you will loose quality >_every_ time you save, not just the first time. Are you talking about compressing to 75% of the previous cycle's file size, perhaps? If not, then I'd be surprised to see a large loss each subsequent time. Has anyone tried cycling and differencing to see the effect? Ian
Re: Gimp Wishes (i18n and jpeg)
On Mon, Apr 03, 2000 at 05:24:37PM +0200, Stanislav Brabec <[EMAIL PROTECTED]> wrote: > Saving in higher quality means vaste of disk space. Saving with less quality > will cause loss of quality. So the best is to save certain jpeg in the same > quality all times. You got it wrong: saving a jpeg in ANY quality (higher or lower) causes loss of quality. Saving in the same quality as the original image causes quality loss depending on the selected quality. As I said, the only effect is a similar(!) file size, and that every save would cause about the same amount of quality loss. Jpeg is lossy, in whatever quality you save your files. If you save your file in 75% percent, load it again, and cycle you will loose quality _every_ time you save, not just the first time. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Gimp Wishes (i18n and jpeg)
On Sat, Apr 01, 2000 at 07:46:03PM +0200, Marc Lehmann wrote:
> That could be done before 1.2, with added stress for the translators, but...
> I think using optional(!) tags (which will be more verbose) will be even more
> useful: Not much added strain on the programmer, not much strain on
> translators (we need one more translator for the en mapping).
On Mon Apr 3 15:06:25 2000 Daniel Egger wrote:
>> Tell it the programmers; they will have to add "prifixes" to make the
>> strings different; e.g.:
> That's not meant to be serious, is it? It would be really a
> pain-in-the-ass to maintain this, even in the most simple case.
I am thinking about less stressing version:
Little change in gettext (or some post-code), creating two catalogs:
gimp.pot and gimpR.pot.
gimp.pot will not be affected by any post/prefix.
gimpR.pot will contain only post/prefixed messages in full version.
So, gimp.pot will be translated in standard way, gimpR.pot will stay
untranslated unless one actually need difference between strings.
Both can be merged during compilation.
This affects:
-- gettexting mechanism in code (we need two lookups - with and without
post/prefix).
-- needs extra code in addition to standard "gettextize".
-- definition of __ in header (or optionally redefinition of _ - see lower)
Don't affects:
-- Already existing translation.
For example:
code.c:
__("selection~Free")
gimp.pot
#: code.c:111
msgid "Free"
gimpR.pot
#: code.c:111
msgid "selection~Free"
There are two ways to create pre/postfixes: "preventive" (do it for
all possible problematic strings) and "on demand" (if any translation
in any language looks ugly, one (the translator) will do it).
I see also one chance: Automatic prefix generation on c-filename basis.
It's sufficient for most cases (but not all), and requires only re-defining
of _ macro. __ macro (and prefix) will be used explicitly only for places, where
per-filename prefix is not sufficient.
For example:
code.c:
_("Free")
gimp.pot
#: code.c:111
msgid "Free"
gimpR.pot
#: code.c:111
msgid "code.c~Free"
>
> > -- Jpeg: There is a problem to guess compression and some save options
> >from jpeg data. So we load image compressed in 98% quality,
> >and consequent Save will default to 75% quality.
>
> I don't think this really is so much of a problem. Saving a jpeg in the same
> quality as it was originally saved will do no good to your quality. The only
> thinvg it will ensure is that the file-size will be similar.
>
Saving in higher quality means vaste of disk space. Saving with less quality
will cause loss of quality. So the best is to save certain jpeg in the same
quality all times.
--
Stanislav Brabec
i18n patch
remove blurb,help _() www.geocities.com/art_pl/gimp/gimp-art-003-1.patch.gz po files: www.geocities.com/art_pl/gimp/gimp-art-003-0.patch.gz __ ___ |/ _, | __ | | __ \ |_ _| -- Artur Polaczynski -- | __ | | _/| | -- mail: [ [EMAIL PROTECTED] ]--- |_| |_| |_|\_\|_| -- www: ---[ www.geocities.com/art_pl/ ]---
Re: Testing and integration of "The i18n solution"(TM)
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)
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)
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)
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 /Filters/verynew/stupidtool. > Now we first check: > - Is there a menu /Filters/verynew >-> if not continue ripping off until we found a menu which is > already there. > Let's assume we do have the menu /Filters already which > translates into the German /Filter. We detected that > the next instance we have to create is /Filters/verynew. > Unfortuntely we don't have a translation handy but we can get > this one by taking the translation from > /Filters/verynew/stupidtool and strip off the same number of > instances. The full translation would be > /Filters/ganzneu/dummesteil /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: Coding style (was: PROPOSAL: New i18n solution)
> :set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
>
> Works most of the case.. (maybe not perfect, but..)
Thanks a lot! I just put it in the programming guidelines.
Federico
Re: Testing and integration of "The i18n solution"(TM)
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 /Filters/verynew/stupidtool. Now we first check: - Is there a menu /Filters/verynew -> if not continue ripping off until we found a menu which is already there. Let's assume we do have the menu /Filters already which translates into the German /Filter. We detected that the next instance we have to create is /Filters/verynew. Unfortuntely we don't have a translation handy but we can get this one by taking the translation from /Filters/verynew/stupidtool and strip off the same number of instances. The full translation would be /Filters/ganzneu/dummesteil /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 (, , ...) 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 > /Filters/Render/Nature/Flame... > is to be created, the submenu > /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)
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 (, , ...) 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
/Filters/Render/Nature/Flame...
is to be created, the submenu
/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)
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
Re: Testing and integration of "The i18n solution"(TM)
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)
Hi, SHIRASAKI Yasuhiro <[EMAIL PROTECTED]> noticed: > some paths like: > > /Video > /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.
Testing and integration of "The i18n solution"(TM)
Hi,
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.
One thing definitely needs to be done before the new
framework is really usable: gimptool should provide the
LOCALEDIR definition (together with the cflags?) so
plug-ins that want to put their compiled message
catalogs at the same place where the default gimp catalogs
are located, can easily bind their textdomain using:
bindtextdomain ("gimp-plugin-foobar", LOCALEDIR);
and notify the gimp about its textdomain by calling:
gimp_plugin_domain_add ("gimp-plugin-foobar");
Would be nice if someone else could take care of changing
gimptool and doing a little testing...
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.
Salut, Sven
"The i18n solution"(TM) is a registered trademark owned by Daniel Egger
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > One of us defintely works too much and too fast. Uhm, but who? I think its you... :)) Sven, you are doing great work > I have just checked > in a working solution which gets rid of the annoying > iterate-through-all-domains problem. Great > Sorry, but when I had the idea how it could work (actually Mitch > helped a little) I just had to try it. Since the changes are so small > and no new files are necessary at all, I just had to check them in. > The overall idea is of course still yours and we owe you much for > solving the i18n problem. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
Hi, > Back to work: > > New patch, also containing a proper cleanup function and the necessary > call in app_procs.c appended. One of us defintely works too much and too fast. I have just checked in a working solution which gets rid of the annoying iterate-through-all-domains problem. Sorry, but when I had the idea how it could work (actually Mitch helped a little) I just had to try it. Since the changes are so small and no new files are necessary at all, I just had to check them in. The overall idea is of course still yours and we owe you much for solving the i18n problem. Salut, Sven
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: >> I sent a newer patch in my last mail. It should do everything we >> need for now. > No, it will most likely crash the Gimp (explanation of the usage > of GSList in a private mail) No, it won't. Since g_slist_append COULD change the value of the the beginning but does not. Anyway, I have had it in my code the recommended way but it got lost while cutting and pasting. No it's there again. > and it won't work the first time the plug_in is started. That's right, was a braino, is changed now. > I'll check my code in in a few minutes. Should provide a framework > to add the rest upon. Great. > Ok, I'll try: Right now we will have to iterate through all domains > when trying to translate the menus. Since we know what domain the > plugin is in, we are able to choose the right one when its procedures > try to install the menupath. Since that is done from plug_in.c it > would be possible to pass the domain to the menu_item_factory code. Of > course we will still have to bind to all domains in our list. Hm, makes sense to me. Will look at this later. I'd also recommend getting rid of this "let's add the submenus for the plugins" hack. I have something more dynamic in mind which will also work for external plugins and possibly reduce code size and bugprobability. > PS: BTW, I did not ment you and Marc in my comment about the print > plugin. Okay, sorry then. > Why do you think so? Well, you are quite offensive in the last time concerning me and you mailed Marc and me concering a patch which was wrong not too long ago. Back to work: New patch, also containing a proper cleanup function and the necessary call in app_procs.c appended. -- Servus, Daniel diff33.gz
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > No, that won't work. Of course you need to hook somewhere into > plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins > won't be able to register their domain on the first call. Of course you are right, just a braino. >> The only thing missing now is the pluginrc write code. > Huh? The info is already written into the pluginrc! I didn't say what I mean (TM), I meant the PDB code. New patch appended. -- Servus, Daniel diff32.gz
Re: Coding style (was: PROPOSAL: New i18n solution)
Glyph Lefkowitz wrote: > On Wed, 23 Feb 100, Miles O'Neal wrote: > > [snip thought GNU style was bad but it's OK] > > > I still don't. Two spaces just isn't enough. Three > > or four is much better. And I like space before the > > paren only if it isn't after a function or procedure > > name. > > And I firmly believe that if God had intended we format our code with > spaces, He would have made them wider. In my own projects, I use a > one-tab-per-indent style. (I have no idea if my style is analagous to > someone else's; I wrote my own .emacs files.) This drives some of my > developers nuts, but it's my perogative, just as it's the GIMP community's > perogative to enforce GNU style. Quantitative studies have shown that from 2 through 6 spaces is optimal. -- "My new computer's got the clocks, it rocks But it was obsolete before I opened the box" - W.A.Y.
Re: PROPOSAL: New i18n solution
Hi, > I'd recommend gimp_plugin_domain_add (gchar *domain_name) > and gimp_plugin_domain_add_with_path (gchar *domain_name, > gchar *domain_path) > > because it IMHO fits better into the namespace and is more obvious > than to have just 1 function with two meanings. Ok, I'll change it then and provide two wrappers for one PDB call. > I sent a newer patch in my last mail. It should do everything we need > for now. No, it will most likely crash the Gimp (explanation of the usage of GSList in a private mail) and it won't work the first time the plug_in is started. > I totally agree with this solution, so let's finalize it and get it > into the tree. I'll check my code in in a few minutes. Should provide a framework to add the rest upon. > > While working on the code I came across a new idea which would > > simplify things quite a bit eventually: The plugins create their > > menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why > > not use the knowledge about the domain_name the translated string is > > to be found in and only look it up in that domain by passing it to > > menus_create_item_() ? You'd only have to change the code to iterate > > through the plug_in_defs instead of proc_defs since the domain is > > stored with the plug_in definition. > > I'm afraid I don't understand that. Could you please explain it again? Ok, I'll try: Right now we will have to iterate through all domains when trying to translate the menus. Since we know what domain the plugin is in, we are able to choose the right one when its procedures try to install the menupath. Since that is done from plug_in.c it would be possible to pass the domain to the menu_item_factory code. Of course we will still have to bind to all domains in our list. Salut, Sven PS: BTW, I did not ment you and Marc in my comment about the print plugin. Why do you think so? But I might be at least partly guilty ...
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > gimp_plugin_add_locale_domain (gchar *domain_name, > gchar *domain_path) > and can only be called in the query function of a plug-in. The > domain_path may optionally be NULL. Proposals for a better name are > welcome. I'd recommend gimp_plugin_domain_add (gchar *domain_name) and gimp_plugin_domain_add_with_path (gchar *domain_name, gchar *domain_path) because it IMHO fits better into the namespace and is more obvious than to have just 1 function with two meanings. > Daniel, if we can agree on this solution, I would like to check this > code in, so that you can work on adapting your code to the framework. I sent a newer patch in my last mail. It should do everything we need for now. I totally agree with this solution, so let's finalize it and get it into the tree. > While working on the code I came across a new idea which would > simplify things quite a bit eventually: The plugins create their > menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why > not use the knowledge about the domain_name the translated string is > to be found in and only look it up in that domain by passing it to > menus_create_item_() ? You'd only have to change the code to iterate > through the plug_in_defs instead of proc_defs since the domain is > stored with the plug_in definition. I'm afraid I don't understand that. Could you please explain it again? -- Servus, Daniel
Re: PROPOSAL: New i18n solution
Hi, > I added a few lines to your modified gimprc.c to support that. No, that won't work. Of course you need to hook somewhere into plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins won't be able to register their domain on the first call. > The only thing missing now is the pluginrc write code. Huh? The info is already written into the pluginrc! Salut, Sven
Re: PROPOSAL: New i18n solution
Hi, I have some working code that does use the pluginrc to store the additional locale info for plugins (as described in my earlier mail). Additionally the framework for setting the domain (and optionally a path) from a plugin through a PDB call is complete and tested. The new PDB call would be (in its wrapped form): gimp_plugin_add_locale_domain (gchar *domain_name, gchar *domain_path) and can only be called in the query function of a plug-in. The domain_path may optionally be NULL. Proposals for a better name are welcome. Daniel, if we can agree on this solution, I would like to check this code in, so that you can work on adapting your code to the framework. While working on the code I came across a new idea which would simplify things quite a bit eventually: The plugins create their menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why not use the knowledge about the domain_name the translated string is to be found in and only look it up in that domain by passing it to menus_create_item_() ? You'd only have to change the code to iterate through the plug_in_defs instead of proc_defs since the domain is stored with the plug_in definition. Salut, Sven
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > You will find the patch at > http://sven.gimp.org/files/locale_parse.patch. OK, looks fine to me. I changed my files accordingly. libgimp/gimpdomain.* is now futile. And the gimpgettext.* file were changed to support that scheme. I added a few lines to your modified gimprc.c to support that. The only thing missing now is the pluginrc write code. I added the libgimp and gimp-std-plugins to the default domains, so no need to specify them elsewhere. Also everything works fine like before. Patch against CVS gimp and Sven's patch appended. -- Servus, Daniel diff31.gz
Re: Coding style (was: PROPOSAL: New i18n solution)
On Wed, 23 Feb 100, Miles O'Neal wrote: [snip thought GNU style was bad but it's OK] > I still don't. Two spaces just isn't enough. Three > or four is much better. And I like space before the > paren only if it isn't after a function or procedure > name. And I firmly believe that if God had intended we format our code with spaces, He would have made them wider. In my own projects, I use a one-tab-per-indent style. (I have no idea if my style is analagous to someone else's; I wrote my own .emacs files.) This drives some of my developers nuts, but it's my perogative, just as it's the GIMP community's perogative to enforce GNU style. [snip consistent style important] > I use to feel this way. But now, so long as each file has a > consisten, reasonable style (or preferably, package of files, say a > directory), I'm happy. If it's a requirement of a project that one adhere to a specific coding style, I think it's pretty rude to ignore such a request in contributions to that code, regardless of one's personal beliefs on the matter. > I handle perl as closely as possible to how I handle C. I think Perl should standardize on only 10 or 20 different ways to write a loop before you start worrying about indentation. And people wonder why Python has the whitespace enforcement rules... ::runs from Marc :-):: __ __ __ _ _ _ | | \_/ |_] |_| |_| |_ || | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > Ok, one shouldn't just bitch about other people's code, so here is my > patch that adds an optional locale_domain and locale_path to the > plugin structure and extends the pluginrc code to read and write that > information from/into the pluginrc. This code is obviously a few > lines longer than what Daniel proposes, but it seems to work very > well here. Great! I'll have a look. > The locale information is optional and if the locale_domain is given, > there _can_ be an additional locale_path entry. The code handles the > case that pluginrc registers the locale_domain twice (by using the > last given entry), but that should never happen unless the user edits > the pluginrc by hand. Hm, I don't really now whether this assumption is safe, but anyway it's a thing we don't have to fiddle with right now. > You will find the patch at > http://sven.gimp.org/files/locale_parse.patch. > It only contains the code to read, store and write the locale info for > the plug-ins. This will have to be extended to do build a list out of > this entries (eventually checking for the existence of the given > paths). Other necessary parts can be taken from Daniels patch. The code for building the list is also there. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > Huh? Daniel, stop spreading FUD and read the code. The parser in > gimprc is actually pretty flexible. No, it isn't. It supposes a fixed order and fixer number of arguments (except the pdbargs of course), that anything but flexible. A tag based system on let's say XML would be a lot more flexible and allow us to save some bytes in the pluginrc. > Well, I have no problem to discuss the arguments, I just had the > impression that you simply ignored them... No, I wouldn't ever do that. > A PDB call is actually no harm. IMO libgimp should not fiddle with > configuration files at all. Since the localisation of the menuentries > is a problem in the core and not one of each and every plugin, putting > the functionality into libgimp is actually bad style. But simple. I have no problem with a more complex solution as long as is seems reasonable and maintainable in a "frozen" tree. > I am proposing exactly the same solution, with a little difference: > Instead of doing the work in libgimp which is not suited to work > with configuration files, make the libgimp call be a PDB wrapper > and let the application handle the dirty work. Okay. > The advantage I see is that we will not need another configuration > file and we have the information about a plugins gettext-domain > in the plugin structure where it belongs and where it is automatically > kept in sync with the list of installed plug-ins. Let's sync our ideas. We add two optional entries after the PDB args in pluginrc which get's parsed by the normal parser and inserted in a list and then my code does the rest. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
Hi, Ok, one shouldn't just bitch about other people's code, so here is my patch that adds an optional locale_domain and locale_path to the plugin structure and extends the pluginrc code to read and write that information from/into the pluginrc. This code is obviously a few lines longer than what Daniel proposes, but it seems to work very well here. The locale information is optional and if the locale_domain is given, there _can_ be an additional locale_path entry. The code handles the case that pluginrc registers the locale_domain twice (by using the last given entry), but that should never happen unless the user edits the pluginrc by hand. You will find the patch at http://sven.gimp.org/files/locale_parse.patch. It only contains the code to read, store and write the locale info for the plug-ins. This will have to be extended to do build a list out of this entries (eventually checking for the existence of the given paths). Other necessary parts can be taken from Daniels patch. What is missing right now is a function to add the locale_domain and locale_path information from a plugin using a PDB call. This will follow later. Salut, Sven
Re: PROPOSAL: New i18n solution
Hi, > It was meant such, but from your description it seemed to me that > you'd like to add those entries to ALL plugins. From your answer > I can see that this was just a misunderstanding. Sorry, Sven. > > But this make it even harder to modify the parser like you'd like > since it's only usable for a fixed number of arguments. It would work > to insert those parameters before the pdb-args but that would > a) be incompatible and b) mean that every plugin must have such an entry. Huh? Daniel, stop spreading FUD and read the code. The parser in gimprc is actually pretty flexible. > Of course I try to wipe them away if they seem not reasonable or > correct to me, that's how argumentation works. HOWEVER this > doesn't mean that I don't care about your thoughts, they are > really helpful and result in new ideas in my head. Well, I have no problem to discuss the arguments, I just had the impression that you simply ignored them... > Just to clarify what I do think of: > I'd like to have this done as simple as possible that means: > - No PDB calls A PDB call is actually no harm. IMO libgimp should not fiddle with configuration files at all. Since the localisation of the menuentries is a problem in the core and not one of each and every plugin, putting the functionality into libgimp is actually bad style. > - No wire protocol changes There is no need for one, I was wrong here. > There should be a simple libgimp call which allows plugins to > register themselves in a new domain. If the domain is already > available, check whether the path matches (not done in my patch > yet!), if not simply add it. > The GIMP on the other side should simply be able to get all the > registered domains and to do the right things when gimpgettext() > is called. I am proposing exactly the same solution, with a little difference: Instead of doing the work in libgimp which is not suited to work with configuration files, make the libgimp call be a PDB wrapper and let the application handle the dirty work. The advantage I see is that we will not need another configuration file and we have the information about a plugins gettext-domain in the plugin structure where it belongs and where it is automatically kept in sync with the list of installed plug-ins. Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
Raphael Quinet said... | |I did not like the GNU style at first (especially the space before the |opening parenthesis) I still don't. Two spaces just isn't enough. Three or four is much better. And I like space before the paren only if it isn't after a function or procedure name. |but now I understand that it is very important to |keep a consistent coding style in each project, because it keeps the |code manageable and maintainable. So I always use whatever coding |style is recommended for the each project, even if this means that I |have to format my patches differently for the Gimp and for a Linux |driver, for instance. Since the Gimp uses the GNU style, I think that |it is important to follow the GNU coding guidelines faithfully. I use to feel this way. But now, so long as each file has a consisten, reasonable style (or preferably, package of files, say a directory), I'm happy. |While we are on the subject of coding style, there are two areas of |the Gimp that are not using a consistent coding style: the Script-Fu |scripts and, to a lesser extent, the Perl scripts. Is there a |recommended style for these? I handle perl as closely as possible to how I handle C. -Miles
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > The core would then have to try to bindtextdomain() to all > possible paths until success (or total failure if no message > catalog was found). You can't find out whether bindtextdomain failed or not. The only way to get the information whether a catalog is available in a path or not is to find the files yourself and then register them with the right path. :( Welcome to the nice world of gettext. Anyway, I'd really like to leave the decision where to install a catalog to the plugin. Considering that most of the external plugins will get their own configure script it would be simple to find a convinient place for the catalog, assign it to a #define and use this define in the sourcecode of the plugin. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > The current solution for the plugins > distributed with The GIMP works reasonably good. Really? I wouldn't call "we have to pre-add the menuentries to GIMPs core source otherwise it wouldn't work" working good. Actually my patch doesn't really address those problems, but the current code for plugin localisaing is more or lass an evil hack. > I don't see why we > should ditch the hardcoded path in favor of a config file the user > will be able to mess with. I thought your proposal would only be a > hook for additional plugins?! It was meant such, but from your description it seemed to me that you'd like to add those entries to ALL plugins. From your answer I can see that this was just a misunderstanding. Sorry, Sven. But this make it even harder to modify the parser like you'd like since it's only usable for a fixed number of arguments. It would work to insert those parameters before the pdb-args but that would a) be incompatible and b) mean that every plugin must have such an entry. > I was speaking about the fact that whatever solution we come up > with will not be backward compatible. Of course it will or at least should try to be. My current solution for example is. And your suggested solution will also as long as you don't touch the wire protocol. > I will have to look through the code in app/plug_in.c a little more, > but I think I was wrong in my last mail and there's no need to change > the wire protocol at all. It would be really bad to do so. And even worse: This code is very simple to break, just look at it and it won't compile on DEC Alpha anymore; another look and it will cause every plugin under Solaris to fail. :( > The amount of code-changes is IMHO more or less equal. The small > feature you want to add should be well-thought and I don't see > why you simply wipe away the arguments have I put up against your > solution. Of course I try to wipe them away if they seem not reasonable or correct to me, that's how argumentation works. HOWEVER this doesn't mean that I don't care about your thoughts, they are really helpful and result in new ideas in my head. Just to clarify what I do think of: I'd like to have this done as simple as possible that means: - No PDB calls - No wire protocol changes There should be a simple libgimp call which allows plugins to register themselves in a new domain. If the domain is already available, check whether the path matches (not done in my patch yet!), if not simply add it. The GIMP on the other side should simply be able to get all the registered domains and to do the right things when gimpgettext() is called. Sven, your ideas are very nice but they are neither simple nor so easy to implement like mine. Please consider that we have already feature freeze, are trying to get a stable version out and just don't have the time for a fullfeatured platinum solution. > Don't tell me that you have spent days to create your patch > and don't want your hard work to be discarded. GOD, I spend days without anything to eat and drink in my room just to get this idea into a working patch. PLEASE don't blow it away! Sven, if you have good ideas, tell them to me and the world, any ideas are really appreciated. My only goal is to do my very best to get a new stable release of this great project done ASAP. I don't care about anything else at the moment and would rather like to concentrate on the GIMP instead of wasting time with flaming. -- Servus, Daniel
Re: Coding style (was: PROPOSAL: New i18n solution)
On 23 Feb, Marc Lehmann wrote: > Then, most probably, you have a very very old or broken version of vim > (or maybe you use another editor, or vim in vi-emulation mode). Actually it's the latest stable version of vim. > The whole point of these options is to make indentation automatic and > more-or-less gnu-style. I was told that the style I used before is not acceptable as GNU style so I guess it's the less in "more-or-less". > In any case, giving "my editor does indent differently" is a very poor > reply to a request to follow a specific coding style. Well, Marc, if you followed this list then you'd know that I already posted an well indented and improved version of my patch. It was just a kind of a BTW note that I can't bring my editor to automatically create this indention style. > You can write > gnu-style using any non-broken editor! So if your editor does indent > differently, use the keys of your keyboard to correct your editor, or > read the docs on how to persuade your editor to do it for you. This seems impossible, but fortunately indent is working quite nice for me so this is now just an annoyance no "problem" anymore. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
Hi, I have thought about the problem a little more and there's one question that has not been addressed until now. How should the plugin now where its mo-file will be installed? If we want to stay with the existing procedure that the plug-in may be installed in a configured list of paths, it does IMHO not make sense to hardcode the path to the mo-file into the plugin so that it can register it together with its domain. The only solution I came with up until now is to have a configurable list of po-paths defaulting to the standard path for message catalogs $prefix/share/locale and to ~/gimp/locale. The core would then have to try to bindtextdomain() to all possible paths until success (or total failure if no message catalog was found). Is there another solution for this? Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 February, 2000 - [EMAIL PROTECTED] sent me these 0.6K bytes:
> On 22 Feb, Federico Mena Quintero wrote:
>
> > I don't know if this will be useful at all, but the GNOME Programming
> > Guidelines has a snippet for .vimrc to set the Linux kernel
> > indentation style.
>
> This is the standard vim style.
>
> > If you tweak it a bit it may work for GNU indentation style.
>
> No, unfortunately I couldn't get vim used to GNU indention style.
:set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
Works most of the case.. (maybe not perfect, but..)
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
Re: PROPOSAL: New i18n solution
Hi, > > Actually I don't see hundreds > > of internationalized plugins in addition to the ones that come with > > gimp > > But even those will have their own entry. One entry per plugin. > Considering the amount of plugins we ship with GIMP nowadays this > would alone lead above hundred entries. Why should they have an entry? The current solution for the plugins distributed with The GIMP works reasonably good. I don't see why we should ditch the hardcoded path in favor of a config file the user will be able to mess with. I thought your proposal would only be a hook for additional plugins?! > > There's no way to avoid this. > > There is a way, my way. I was speaking about the fact that whatever solution we come up with will not be backward compatible. It should however be robust and shouldn't keep old plugins from running. I will have to look through the code in app/plug_in.c a little more, but I think I was wrong in my last mail and there's no need to change the wire protocol at all. > > I just do not see your point in keeping this very plug-in-specific > > info out of pluginrc where it belongs. app/plug_in.c contains all > > the code you need to parse and write the pluginrc. Additionally > > there's code to keep the plugin info in sync with the actually > > installed binaries. Your solution is very weak when it comes to > > that point and I see some substantial problems in that weakness. > > And I see bigger problems in changing all the parse and wireprotocol > code to add such a small "feature" (it's more a bugfix). The amount of code-changes is IMHO more or less equal. The small feature you want to add should be well-thought and I don't see why you simply wipe away the arguments have I put up against your solution. Don't tell me that you have spent days to create your patch and don't want your hard work to be discarded. Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
> > If you tweak it a bit it may work for GNU indentation style. > > No, unfortunately I couldn't get vim used to GNU indention style. > > > Please tell me if this works or if you had to change something; I'd > > like to keep that part of the programming guidelines as accurate as > > possible. > > It'd work, but not for GIMPs code. :/ Oh, well. Thanks anyway. Please tell me if you find a way to make it work; other people may find it useful. Federico
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, Feb 22, 2000 at 11:54:03PM +0100, [EMAIL PROTECTED] wrote:
> Well, that the thing I'm talking about.
> I tried this options and think that it doesn't match it very good.
> After the first { of a function the source isn't indented for example.
Then, most probably, you have a very very old or broken version of vim
(or maybe you use another editor, or vim in vi-emulation mode). The whole
point of these options is to make indentation automatic and more-or-less
gnu-style.
Anyway, read the docs. It's not black magic to get a little help from your
editor. Or, maybe, change your editor ;)
In any case, giving "my editor does indent differently" is a very poor
reply to a request to follow a specific coding style. You can write
gnu-style using any non-broken editor! So if your editor does indent
differently, use the keys of your keyboard to correct your editor, or read
the docs on how to persuade your editor to do it for you.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 Feb, Federico Mena Quintero wrote: > I don't know if this will be useful at all, but the GNOME Programming > Guidelines has a snippet for .vimrc to set the Linux kernel > indentation style. This is the standard vim style. > If you tweak it a bit it may work for GNU indentation style. No, unfortunately I couldn't get vim used to GNU indention style. > Please tell me if this works or if you had to change something; I'd > like to keep that part of the programming guidelines as accurate as > possible. It'd work, but not for GIMPs code. :/ -- Servus, Daniel
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 Feb, Marc Lehmann wrote:
> vim, like vi and emacs, has a manual and can be configured quite
> freely ;)
Yes, I read the manual and tried a whole hour to get it the GNU
way but I couldn't manage to get that.
> set formatoptions=croql cindent cinkeys={,},:,0#,!^F,o,O,e
> cinoptions={.5s,}0,g0,^-2 sw=2 comments=sr:/*,mb:*,el:*/,://
> (However, that's not exactly gnu-style).
Well, that the thing I'm talking about.
I tried this options and think that it doesn't match it very good.
After the first { of a function the source isn't indented for example.
--
Servus,
Daniel
Re: PROPOSAL: New i18n solution
On 22 Feb, Sven Neumann wrote: > IMHO adding lines into the pluginrc is much easier than to add > code to parse another file. Well, my code is there, now you'll have the chance to prove that this assertion is true, I don't think so BTW after thouroughly studying the code. > Which just means adding another token to the parser code. You can't do > much wrong here. The pluginrc Parser is something I touched once and then never again. The parser GIMP relies on is rather complicated.Passing arguments needs the introduction of new structures for which special code has to be written. Maybe I just haven't found a simple way but IMHO this would need at least 200 lines of fresh and buggy code. >> - need to check the domainlist for duplicated entries on >>every addition of a new domain otherwise we'd have possibly >>hundreds of gettext calls for a translation lookup. > Which you will have to do in any case. Yes, but at the moment I do this at registering time thus avoiding duplicated entries in the localerc file. > Actually I don't see hundreds > of internationalized plugins in addition to the ones that come with > gimp But even those will have their own entry. One entry per plugin. Considering the amount of plugins we ship with GIMP nowadays this would alone lead above hundred entries. > and even if there were hundreds, iterating through a list of > strings and comparing them is pretty fast. But it's additional code. > If that's not enough, we could always a hash... Yes, but all I wanted was a small and simple solution for a stupid problem with gettext not a full featured framework. I'm really sure we'll get away from gettext in 1.3 so this will get obsolete sooner or later. >> - need to add parsing functionality to libgimp to write the entries >>to pluginrc. > Eeek, no! Libgimp doesn't have to know much about this at all. Where would you like to add this call then? > The plugin would just call a second special gimp_install_domain() > procedure if it needs to register a domain. Of course this means > adding a new type to the gimpprotocol, but I see no substantial > problem in doing so. IMHO changing the wire protocol and doing all this with PDB is no great idea. It's complicated, a lot of work and unnecessary. > Your additional libgimp function introduces the same incompatibility. No, it doesn't. Apply the patch and run GIMP. Everything will work fine just by compiling this five files and relinking the GIMP of course your ~/gimp-1.1/localerc should contain: :gimp gimp-std-plugins /usr/local/share/locale No need to change or compile anything else. Of course adding the line gimp_domain_add (gimp-std-plugins) to at least one of the running plugins would circumvent the need to add those 2 lines manually. I could even think of registering gimp-std-plugins in source to avoid having to add the line to any of the standard plugins. > There's no way to avoid this. There is a way, my way. > I just do not see your point in keeping this very plug-in-specific > info out of pluginrc where it belongs. app/plug_in.c contains all > the code you need to parse and write the pluginrc. Additionally > there's code to keep the plugin info in sync with the actually > installed binaries. Your solution is very weak when it comes to > that point and I see some substantial problems in that weakness. And I see bigger problems in changing all the parse and wireprotocol code to add such a small "feature" (it's more a bugfix). -- Servus, Daniel
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, Feb 22, 2000 at 07:59:21PM +0100, [EMAIL PROTECTED] wrote:
> Uhm, I use vim and vim uses tabs by default and doesn't indent
vim, like vi and emacs, has a manual and can be configured quite freely ;)
> the { after an if like GNU suggests. Du you have working settings to
> achieve this?
One of my 99 config lines is:
set formatoptions=croql cindent cinkeys={,},:,0#,!^F,o,O,e cinoptions={.5s,}0,g0,^-2
sw=2 comments=sr:/*,mb:*,el:*/,://
(However, that's not exactly gnu-style).
HTH,
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: PROPOSAL: New i18n solution
Hi, > [ ... many thought about localerc deleted ... ] > > Well, you are right in all your points. I just decided > to use a new file because I don't need much functionality > and therefore could keep it simple as well as the functions > in GIMP and libgimp to deal with it. IMHO adding lines into the pluginrc is much easier than to add code to parse another file. > > So why, I ask you, don't we just put the locale information > > into the pluginrc. It should be trivial to extend the parser > > to optionally read two additional lines after the proc-args > > in the form of: > > (locale-domain "funky_plugin") > > (locale-path "~/.gimp-1.1/po") > > Yes, this was an idea, too. But like you said: > We'd > - need to expand the parser. Which just means adding another token to the parser code. You can't do much wrong here. > - need to check the domainlist for duplicated entries on >every addition of a new domain otherwise we'd have possibly >hundreds of gettext calls for a translation lookup. Which you will have to do in any case. Actually I don't see hundreds of internationalized plugins in addition to the ones that come with gimp and even if there were hundreds, iterating through a list of strings and comparing them is pretty fast. If that's not enough, we could always a hash... > - need to add parsing functionality to libgimp to write the entries >to pluginrc. Eeek, no! Libgimp doesn't have to know much about this at all. The plugin would just call a second special gimp_install_domain() procedure if it needs to register a domain. Of course this means adding a new type to the gimpprotocol, but I see no substantial problem in doing so. > or instead of the last point we'd need to change the wire protocol > and add additional fields to the plugin structures and thus introduce > an imcompatibility. Your additional libgimp function introduces the same incompatibility. There's no way to avoid this. To make it clear, I don't speak about changing the gimp_install_procedure(). I totally agree with you that adding a function like gimp_set_domain() to the query() part of the plug-ins is the way to go. I just do not see your point in keeping this very plug-in-specific info out of pluginrc where it belongs. app/plug_in.c contains all the code you need to parse and write the pluginrc. Additionally there's code to keep the plugin info in sync with the actually installed binaries. Your solution is very weak when it comes to that point and I see some substantial problems in that weakness. Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
> Uhm, I use vim and vim uses tabs by default and doesn't indent
> the { after an if like GNU suggests. Du you have working settings to
> achieve this?
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation style. If you tweak it a bit it may work for GNU
indentation style. You can look at it here:
http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html
Please tell me if this works or if you had to change something; I'd
like to keep that part of the programming guidelines as accurate as
possible.
Sorry if this is not of any help, I don't do vi :-)
Federico
Re: PROPOSAL: New i18n solution
On 22 Feb, Sven Neumann wrote: [ ... many thought about localerc deleted ... ] Well, you are right in all your points. I just decided to use a new file because I don't need much functionality and therefore could keep it simple as well as the functions in GIMP and libgimp to deal with it. > So why, I ask you, don't we just put the locale information > into the pluginrc. It should be trivial to extend the parser > to optionally read two additional lines after the proc-args > in the form of: > (locale-domain "funky_plugin") > (locale-path "~/.gimp-1.1/po") Yes, this was an idea, too. But like you said: We'd - need to expand the parser. - need to check the domainlist for duplicated entries on every addition of a new domain otherwise we'd have possibly hundreds of gettext calls for a translation lookup. - need to add parsing functionality to libgimp to write the entries to pluginrc. or instead of the last point we'd need to change the wire protocol and add additional fields to the plugin structures and thus introduce an imcompatibility. > Since this entries would be optional and > only used for plug-ins added on top of the standard distribution, > I doubt it would hurt us much. But it would be a lot harder to implement this. I made some experiments with the pdb solution and can now state that it's really hopeless. Adding parsing functionality to libgimp just to add the entries at the right place and only if they aren't already there doesn't make much sense to me but would be possible. I wanted it to stay as simple as possible (KISS method) because of the late date. I'd rather rebuild the database from time to time to keep it clean instead of introducing a lot of new stuff. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
Hi, well there seems to be a consensus that your changes make sense. I have however a few questions about the implementation: You want the plug-ins to register their domain and a path to the catalog. If I understand you correctly, this is done by calling gimp_domain_add () in the query function of the plug-in. This query function is usually only run when the plug-in is found for the first time, afterwards the information is read in from the pluginrc. I guess that's why you want to add that info to a new file called localerc. When gimp reads in the known plugins from the pluginrc, it checks for removed plug-ins and removes them from its list. It also checks the modification time and queries the plugin again if it has changed since the last time the pluginrc was written. What will happen if you remove a plugin that has added a new domain to the localerc? The entry in the localerc will stay. What will happen if the plugin is changed and uses another domain name or another domain path? What will happen if people delete the localerc, but not the pluginrc? This is something people are used to do. Deleting a file in your ./gimp dir normally resets everything back into a sane state. Well, it wouldn't work that good for your localerc. So why, I ask you, don't we just put the locale information into the pluginrc. It should be trivial to extend the parser to optionally read two additional lines after the proc-args in the form of: (locale-domain "funky_plugin") (locale-path "~/.gimp-1.1/po") This will mean a slight drawback in startup time, since of course it should check for the presence of the mo-file at the given location to avoid having gettext doing that lookup every time a menu entry is translated. Since this entries would be optional and only used for plug-ins added on top of the standard distribution, I doubt it would hurt us much. Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 Feb, Marc Lehmann wrote:
> "Standard vi indentation" is fine. Just follow the GNU coding style on
> when to indent, and when not (and when to add spaces, when not...)
> ;)
Uhm, I use vim and vim uses tabs by default and doesn't indent
the { after an if like GNU suggests. Du you have working settings to
achieve this?
--
Servus,
Daniel
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, Feb 22, 2000 at 03:56:44PM +0100, [EMAIL PROTECTED] wrote: > Okay, will turn from the Standard vi indention into GNU coding style. "Standard vi indentation" is fine. Just follow the GNU coding style on when to indent, and when not (and when to add spaces, when not...) ;) The idea, however, is very sane. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: PROPOSAL: New i18n solution
On Tue, Feb 22, 2000 at 10:50:55AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > I'm not yet convinced that this goal is worth all the hassle. What do > other people on this list think about this? Being able to add plug-ins with i18n support is _extremely_ important. Unless the release would be delayed it should be given priority. Remember that gimp-1.2 will be there to stay for a long time, presumably. If the obvious problems with that solution is fixed (rc-format...), it looks feasible to me. Especially since the original "solution" to the i18n problems "officially" has the status of an imperfect hack. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, Feb 22, 2000 at 02:59:18PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: > scripts and, to a lesser extent, the Perl scripts. Is there a > recommended style for these? Yes, just copy mine ;) For perl-only-syntax-questions, the reference should be "perldoc perlstyle". All the remaining questions (which excludes syntax, and includes things like "how to add documentation", "how to name fucntions etc.." should go into it's own style-document that I plan to write since, well, years or so). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: PROPOSAL: New i18n solution
[EMAIL PROTECTED] wrote: > Hi developers, > > as you might know that gettext solution works quite nice for > GIMP itself but may cause trouble with plugins. To circumvent > the problem that every plugin must have it's domain registered > within the GIMP source, I'll offer you a new idea here: > > 0. Foreword > Basically we can't get away from gettext and switch to a better > system (which would have to be written first, too) that short before a > release like at the moment. Thus my goal was to change as little as > possible. Like you'll see, we'll just have to add a line to every > plugin outside the GIMP distribution to make this work; everything > else stays the same like it is now, even the catalogs remain untouched. > > 1. Ideas > > 1.1 The config file > The current system is a very static one i.e. nothing can be changed > neither without the sourcecode nor after compilation. What we need > is a dynamic system to remove that deficiencies. A good way to bring > some dynamic into a system is to make it configurable for example by > having a config file. > This configfile of course shouldn't have to be modified by an editor > but automatically by the GIMP resp. libgimp. > > 1.2 Plugins with libgimp > To get this information in there we'll provide a funtion call in > libgimp which registers the domain from the name and path the plugin > CAN provide. If the domain hasn't been registered yet it'll its way > into the configfile > > 1.3 The GIMP core > The GIMP uses the information from this file to bind the necessary > catalogs to itself. To actually use this bound domains we'll have to > provide a function which won't look up a message in one catalog but > recurse through all of them. This function will replace the gettext > call just in places where the GIMP would lookup a menuentry which > is sometimes not in its own catalog. > > 2. Implementation > > 2.1 The configfile > Like all other configfiles this one will stay in ~/.gimp-. > The first line contains ":gimp" to ensure that no one messed up this file. > The next lines contain the name of the domain, a withespace and the > location of the catalog. One catalog per line. > > 2.2 Plugins with libgimp > For the plugins we'll have two new functions in libgimp/gimpdomain.c > which have the selfexplaining prototypes. > > gimp_domain_add (gchar *) > and > gimp_domain_add_with_path (gchar *, gchar *) > > Every plugin may register a domain but don't has to necessarily. > The functions call another static one which checks whether the files > already exists and whether the domain is already registerd. If so it > won't be registered again else it will. > > 2.3 The GIMP core > GIMP will call initgettext() at startup which will initialise i18n > if compiled with it and setup a default (and fallback) domain "gimp" > and every domain that it'll read from localerc. > Every occurence of gettext which had been used to translate menunames > will be changed to gimpgettext which consists of a loop which checks > for a possible translation in all domains which were read from > localerc. > At the end GIMP'll call freegettext() to clean up everything. > > 3. Conclusion > This idea will cirumvent most of the problems which gettext alone > just can't deal with. It's little and as such not very likely to > introduce many new bugs. It would allow us to ship GIMP 1.2 with > the possibility to add plugins which will also benefit from > localisation without any hassle. > > Patch against current CVS is appended. Please feel free to contribute > further ideas and to comment this stuff. Well, for quite a while I haven't liked gettext, and consider it very outdated. Problem is, a good replacement with a good license would need to be out there to switch to. This is sounding better, but maybe you should take a look at the work Taligent did on this front. Their work went into Java 1.1 for it's internationalization support. What you're proposing sounds very similar to Java's PropertyResourceBundles. You should review this lesson in The Java Tutorial to get an overview: http://java.sun.com/docs/books/tutorial/i18n/resbundle/index.html One of it's features that is very useful is it's hierarchical lookup and fallback. So it first looks for/in the most specific file (e.g. resources_fr_CA_UNIX) then starts trimming the extensions until it finds the resource. IBM also has the same functionality released as the IBM Components for Unicode (ICU). Unfortunately it was initially under a license that was not friendly to GNU. http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html Hmmm. It's now under a license that has been approved by OSI. Maybe it's a good candidate for Gimp use now? http://www10.software.ibm.com/developer/opensource/license10.html Even if it's not directly useable, the manner in which they do certain things might be good to think about.
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 Feb, Raphael Quinet wrote: > I did not like the GNU style at first (especially the space before the > opening parenthesis) but now I understand that it is very important > to keep a consistent coding style in each project, because it keeps > the code manageable and maintainable. So I always use whatever coding > style is recommended for the each project, even if this means that I > have to format my patches differently for the Gimp and for a Linux > driver, for instance. Since the Gimp uses the GNU style, I think that > it is important to follow the GNU coding guidelines faithfully. Okay, will turn from the Standard vi indention into GNU coding style. BTW: While browsing the code I saw some file not matching ANY standard like xcf.h. It has neither a GNU header nor any guardings >> > It's not that much code, and does fix a gaping hole in the i18n >> > framework for plugins not distributed with gimp. Especially if we >> > want 1.2 to last a while.. >> That's absolutely right. > Yup! Me too (tm). Glad to hear that. -- Servus, Daniel
PROPOSAL: New i18n solution (2nd try)
On 22 Feb, Sven Neumann wrote: > With the usage of static array and buffer lengths you demonstrated in > your patch it will most likely introduce one or two new bugs, but > that could easily be hacked up a little cleaner Okay, I took some of the comments and updated the files. I'm now using a single linked list to store the domains and I reindented the source to match the other files. Patch attached... -- Servus, Daniel diff30.gz
Re: PROPOSAL: New i18n solution
On Tue, 22 Feb 2000, Sven Neumann wrote: > I also don't like the format of the localerc you proposed since it doesn't > look like the other files in ~/.gimp-1.1. Why not use the scheme-like > syntax people are used to use and that the gimp can parse anyway? I agree strongly with this... there are already too many different configuration styles; although I don't like scheme, it's consistent (and as sven says, there are libs to handle it already) > I'm not yet convinced that this goal is worth all the hassle. What do > other people on this list think about this? I think that the current quality of localization support could reasonably considered a 'bug'. (Replying in the negative here is my way of avoiding saying "me too" to the rest of this thread. Whoops, said it anyway...) --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu PS: please prune my address from your reply headers. I *DO* subscribe to this list.
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, 22 Feb 2000, [EMAIL PROTECTED] wrote: > On 22 Feb, Manish Singh wrote: > > True, although we have a couple other inconsistencies already. The > > coding style needs to be the same as the rest of gimp though. > > I tried to bring it as near as possible. Of course a lot things could > be better I noticed two obvious differences in your code: it does not use two spaces for indentation (the default in Emacs and the recommended GNU style) and there is no space between the function names and the opening parenthesis for the arguments. I suggest that you use a recent version of GNU indent to process your source code and re-indent everything automatically, or that you use Emacs with the default settings (no modifications in a ~/.emacs file) and call indent-region on the whole file. I did not like the GNU style at first (especially the space before the opening parenthesis) but now I understand that it is very important to keep a consistent coding style in each project, because it keeps the code manageable and maintainable. So I always use whatever coding style is recommended for the each project, even if this means that I have to format my patches differently for the Gimp and for a Linux driver, for instance. Since the Gimp uses the GNU style, I think that it is important to follow the GNU coding guidelines faithfully. While we are on the subject of coding style, there are two areas of the Gimp that are not using a consistent coding style: the Script-Fu scripts and, to a lesser extent, the Perl scripts. Is there a recommended style for these? > > It's not that much code, and does fix a gaping hole in the i18n > > framework for plugins not distributed with gimp. Especially if we want > > 1.2 to last a while.. > > That's absolutely right. Yup! Me too (tm). -Raphael
Re: PROPOSAL: New i18n solution
On 22 Feb, Manish Singh wrote: > True, although we have a couple other inconsistencies already. The > coding style needs to be the same as the rest of gimp though. I tried to bring it as near as possible. Of course a lot things could be better > It's not that much code, and does fix a gaping hole in the i18n > framework for plugins not distributed with gimp. Especially if we want > 1.2 to last a while.. That's absolutely right. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 22 Feb, Sven Neumann wrote: > With the usage of static array and buffer lengths you demonstrated in > your patch it will most likely introduce one or two new bugs, but > that could easily be hacked up a little cleaner Of course I could have used a linked list, but I'm not sure if it's worth using it. > I also don't like the format of the localerc you proposed since it > doesn't look like the other files in ~/.gimp-1.1. Why not use the > scheme-like syntax people are used to use and that the gimp can parse > anyway? I'd like to avoid having to extend the parser from GIMP because I don't need much functionality and this would surely introduce more bugs. But if this is a real concern, then I'll do it together with point 1. > I'm not yet convinced that this goal is worth all the hassle. What do > other people on this list think about this? If we don't change it know we'll be shipping 1.2 with crippled localisation support, since the number of plugins is increasing constantly and we're trying to get rid of some in the main distribution I really thing that something like this is a really must-have. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On Tue, Feb 22, 2000 at 10:50:55AM +0100, Sven Neumann wrote: > Hi, > > > This idea will cirumvent most of the problems which gettext alone > > just can't deal with. It's little and as such not very likely to > > introduce many new bugs. > > With the usage of static array and buffer lengths you demonstrated in > your patch it will most likely introduce one or two new bugs, but that > could easily be hacked up a little cleaner > > I also don't like the format of the localerc you proposed since it doesn't > look like the other files in ~/.gimp-1.1. Why not use the scheme-like > syntax people are used to use and that the gimp can parse anyway? True, although we have a couple other inconsistencies already. The coding style needs to be the same as the rest of gimp though. > > It would allow us to ship GIMP 1.2 with the possibility to add plugins > > which will also benefit from localisation without any hassle. > > I'm not yet convinced that this goal is worth all the hassle. What do > other people on this list think about this? It's not that much code, and does fix a gaping hole in the i18n framework for plugins not distributed with gimp. Especially if we want 1.2 to last a while.. -Yosh
Re: PROPOSAL: New i18n solution
Hi, > This idea will cirumvent most of the problems which gettext alone > just can't deal with. It's little and as such not very likely to > introduce many new bugs. With the usage of static array and buffer lengths you demonstrated in your patch it will most likely introduce one or two new bugs, but that could easily be hacked up a little cleaner I also don't like the format of the localerc you proposed since it doesn't look like the other files in ~/.gimp-1.1. Why not use the scheme-like syntax people are used to use and that the gimp can parse anyway? > It would allow us to ship GIMP 1.2 with the possibility to add plugins > which will also benefit from localisation without any hassle. I'm not yet convinced that this goal is worth all the hassle. What do other people on this list think about this? Salut, Sven
PROPOSAL: New i18n solution
Hi developers, as you might know that gettext solution works quite nice for GIMP itself but may cause trouble with plugins. To circumvent the problem that every plugin must have it's domain registered within the GIMP source, I'll offer you a new idea here: 0. Foreword Basically we can't get away from gettext and switch to a better system (which would have to be written first, too) that short before a release like at the moment. Thus my goal was to change as little as possible. Like you'll see, we'll just have to add a line to every plugin outside the GIMP distribution to make this work; everything else stays the same like it is now, even the catalogs remain untouched. 1. Ideas 1.1 The config file The current system is a very static one i.e. nothing can be changed neither without the sourcecode nor after compilation. What we need is a dynamic system to remove that deficiencies. A good way to bring some dynamic into a system is to make it configurable for example by having a config file. This configfile of course shouldn't have to be modified by an editor but automatically by the GIMP resp. libgimp. 1.2 Plugins with libgimp To get this information in there we'll provide a funtion call in libgimp which registers the domain from the name and path the plugin CAN provide. If the domain hasn't been registered yet it'll its way into the configfile 1.3 The GIMP core The GIMP uses the information from this file to bind the necessary catalogs to itself. To actually use this bound domains we'll have to provide a function which won't look up a message in one catalog but recurse through all of them. This function will replace the gettext call just in places where the GIMP would lookup a menuentry which is sometimes not in its own catalog. 2. Implementation 2.1 The configfile Like all other configfiles this one will stay in ~/.gimp-. The first line contains ":gimp" to ensure that no one messed up this file. The next lines contain the name of the domain, a withespace and the location of the catalog. One catalog per line. 2.2 Plugins with libgimp For the plugins we'll have two new functions in libgimp/gimpdomain.c which have the selfexplaining prototypes. gimp_domain_add (gchar *) and gimp_domain_add_with_path (gchar *, gchar *) Every plugin may register a domain but don't has to necessarily. The functions call another static one which checks whether the files already exists and whether the domain is already registerd. If so it won't be registered again else it will. 2.3 The GIMP core GIMP will call initgettext() at startup which will initialise i18n if compiled with it and setup a default (and fallback) domain "gimp" and every domain that it'll read from localerc. Every occurence of gettext which had been used to translate menunames will be changed to gimpgettext which consists of a loop which checks for a possible translation in all domains which were read from localerc. At the end GIMP'll call freegettext() to clean up everything. 3. Conclusion This idea will cirumvent most of the problems which gettext alone just can't deal with. It's little and as such not very likely to introduce many new bugs. It would allow us to ship GIMP 1.2 with the possibility to add plugins which will also benefit from localisation without any hassle. Patch against current CVS is appended. Please feel free to contribute further ideas and to comment this stuff. -- Servus, Daniel diff -P -r -u gimp/app/Makefile.am gimpnew/app/Makefile.am --- gimp/app/Makefile.amMon Feb 21 23:26:00 2000 +++ gimpnew/app/Makefile.am Tue Feb 22 00:11:35 2000 @@ -198,6 +198,8 @@ gimpcontextpreview.h\ gimpdnd.c \ gimpdnd.h \ + gimpgettext.c \ + gimpgettext.h \ gimphelp.c \ gimphelp.h \ gimphelp_cmds.c \ diff -P -r -u gimp/app/gimpgettext.c gimpnew/app/gimpgettext.c --- gimp/app/gimpgettext.c Thu Jan 1 01:00:00 1970 +++ gimpnew/app/gimpgettext.c Tue Feb 22 01:02:10 2000 @@ -0,0 +1,188 @@ +/* The GIMP -- an image manipulation program + * Copyright (C) 1995 Spencer Kimball and Peter Mattis + * + * gimpgettext.c + * Copyright (C) 2000 Daniel Egger <[EMAIL PROTECTED]> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should ha
Re: gimp && i18n == segfault
On Wed, Feb 09, 2000 at 08:59:43PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > I haven't beeen able to reproduce the problem, so I depend on more You recent patch completely fixes the problem for me. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Let's squeeze this i18n bug (quoting by heart) -> bug report #6 052
On Wed, Feb 09, 2000 at 11:45:24PM +0100, [EMAIL PROTECTED] wrote: > This, however, is no answer to the question: Why the hell does my > system not crash although using the same catalogs? Maybe because of the very same reason _you_ system behaved incorrectly when others couldn't reproduce the bug? Come on, admit it: You are not using gtk+, but some other toolkit ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Let's squeeze that i18n bug!
On 9 Feb, Tor Lillqvist wrote: > Could this be related to this bug that I found in GTk+ in November. It is and this is also the reason why my system doesn't suffer from this problem :/ It's time for the translators to get back to their work. If any language crashes then it's because a menu patch is badly translated i.e. it doesn't have an '/' at the beginning -- Servus, Daniel
Re: Let's squeeze this i18n bug (quoting by heart) -> bug report #6052
On 9 Feb, Mike wrote: > Here is the file log you requested in order to have an easier > debugging. Hopefully it can be useful, so that you fix this bug! BTW: > On my box, not all locales (as Mark said in his report) are broken. I > tested out them all, and I found that only it and de crash gimp.- Any > particular reason for that?? Now I do know the reason for YOUR crash: The output shows that your GIMP crashes just before initialising the menu "/Layer Boundary Size" which is obviously not correct translated in the Italian catalog. There seem to be a few more maybe also in the German catalog. This, however, is no answer to the question: Why the hell does my system not crash although using the same catalogs? -- Servus, Daniel
Re: Let's squeeze that i18n bug!
Hi! I recompiled just now gtk+ with the patch in gtkitemfactory.c suggested by Tor Lillqvist in the message #9933 on gimp-developer. Both italian and deutsch locales run perfectly now ;) It really seems the problem was due to some fuzzy (?) translations... Thank you Tor. Regards all Mike
Re: Let's squeeze this i18n bug (quoting by heart) -> bug report #6052
Hi! Here is the file log you requested in order to have an easier debugging. Hopefully it can be useful, so that you fix this bug! BTW: On my box, not all locales (as Mark said in his report) are broken. I tested out them all, and I found that only it and de crash gimp.- Any particular reason for that?? Salut Mike --- Prof. M. Gherlone Liceo "G. Berchet" Via Commenda, 26 - 20122 Milano (Italy) http://berchet.enet.it e-mail: [EMAIL PROTECTED] --- Created: /File Created: /File/tearoff1 Created: /File/New... Created: /File/Open... Created: /File/--- Created: /File/Acquire Created: /File/Acquire/tearoff1 Created: /File/--- Created: /File/Preferences... Created: /File/--- Created: /File/Dialogs Created: /File/Dialogs/tearoff1 Created: /File/Dialogs/Layers & Channels... Created: /File/Dialogs/Tool Options... Created: /File/Dialogs/--- Created: /File/Dialogs/Brushes... Created: /File/Dialogs/Patterns... Created: /File/Dialogs/Gradients... Created: /File/Dialogs/Palette... Created: /File/Dialogs/Indexed Palette... Created: /File/Dialogs/--- Created: /File/Dialogs/Input Devices... Created: /File/Dialogs/Device Status... Created: /File/Dialogs/--- Created: /File/Dialogs/Document Index... Created: /File/Dialogs/Error Console... Created: /File/Dialogs/Display Filters... Created: /File/--- Created: /File/---MRU Created: /File/Quit Created: /Xtns Created: /Xtns/tearoff1 Created: /Xtns/Module Browser... Created: /Xtns/--- Created: /Help Created: /Help/tearoff1 Created: /Help/Help... Created: /Help/Context Help... Created: /Help/Tip of the Day... Created: /Help/About... Created: /Help/Dump Items (Debug) Created: /File/MRU01 Created: /File/MRU02 Created: /File/MRU03 Created: /File/MRU04 Created: /tearoff1 Created: /File Created: /File/tearoff1 Created: /File/New... Created: /File/Open... Created: /File/Save Created: /File/Save As... Created: /File/Revert Created: /File/--- Created: /File/Close Created: /File/Quit Created: /File/---moved Created: /Edit Created: /Edit/tearoff1 Created: /Edit/Undo Created: /Edit/Redo Created: /Edit/--- Created: /Edit/Cut Created: /Edit/Copy Created: /Edit/Paste Created: /Edit/Paste Into Created: /Edit/Paste as New Created: /Edit/Buffer Created: /Edit/Buffer/tearoff1 Created: /Edit/Buffer/Cut Named... Created: /Edit/Buffer/Copy Named... Created: /Edit/Buffer/Paste Named... Created: /Edit/--- Created: /Edit/Clear Created: /Edit/Fill Created: /Edit/Stroke Created: /Edit/--- Created: /Select Created: /Select/tearoff1 Created: /Select/Invert Created: /Select/All Created: /Select/None Created: /Select/Float Created: /Select/--- Created: /Select/Feather... Created: /Select/Sharpen Created: /Select/Shrink... Created: /Select/Grow... Created: /Select/Border... Created: /Select/--- Created: /Select/Save to Channel Created: /View Created: /View/tearoff1 Created: /View/Zoom In Created: /View/Zoom Out Created: /View/Zoom Created: /View/Zoom/tearoff1 Created: /View/Zoom/16:1 Created: /View/Zoom/8:1 Created: /View/Zoom/4:1 Created: /View/Zoom/2:1 Created: /View/Zoom/1:1 Created: /View/Zoom/1:2 Created: /View/Zoom/1:4 Created: /View/Zoom/1:8 Created: /View/Zoom/1:16 Created: /View/Dot for Dot Created: /View/--- Created: /View/Info Window... Created: /View/Nav. Window... Created: /View/Undo History... Created: /View/--- Created: /View/Toggle Selection Created: /View/Toggle Rulers Created: /View/Toggle Statusbar Created: /View/Toggle Guides Created: /View/Snap to Guides Created: /View/--- Created: /View/New View Created: /View/Shrink Wrap Created: /View/--- Created: /Image Created: /Image/tearoff1 Created: /Image/Mode Created: /Image/Mode/tearoff1 Created: /Image/Mode/RGB Created: /Image/Mode/Grayscale Created: /Image/Mode/Indexed... Created: /Image/Mode/--- Created: /Image/Colors Created: /Image/Colors/tearoff1 Created: /Image/Colors/--- Created: /Image/Colors/Desaturate Created: /Image/Colors/Invert Created: /Image/Colors/--- Created: /Image/Colors/Auto Created: /Image/Colors/Auto/tearoff1 Created: /Image/Colors/Auto/Equalize Created: /Image/Colors/--- Created: /Image/Alpha Created: /Image/Alpha/tearoff1 Created: /Image/Alpha/Add Alpha Channel Created: /Image/Transforms Created: /Image/Transforms/tearoff1 Created: /Image/Transforms/Offset... Created: /Image/Transforms/Rotate Created: /Image/Transforms/Rotate/tearoff1 Created: /Image/Transforms/--- Created: /Image/--- Created: /Image/Canvas Size... Created: /Image/Scale Image... Created: /Image/Duplicate Created: /Image/--- Created: /Layers Created: /Layers/tearoff1 Created: /Layers/Layers & Channels... Created: /Layers/Stack Created: /Layers/Stack/tearoff1 Created: /Layers/Stack/Previous Layer Created: /Layers/Stack/Next Layer Created: /Layers/Stack/Raise Layer Created: /Layers/Stack/Lower Layer Created: /Layers/Stack/Layer to Top Created: /Layers/Stack/Layer to Bottom Created: /Layers/Stack/--- Created: /Layers/Rotate Created: /Layers/Rotate/tearoff1 Created: /Layers/Layer to Image
Let's squeeze that i18n bug!
Could this be related to this bug that I found in GTk+ in November. Tue Nov 16 10:15:54 1999 Owen Taylor <[EMAIL PROTECTED]> * gtk/gtkitemfactory.c (gtk_item_factory_parse_path): If translation does not include a '/', use entire translation instead of crashing. (That was after GTK+ 1.2.6 was released.) From: Owen Taylor <[EMAIL PROTECTED]> To: Tor Lillqvist <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: gtk_item_factory_parse_path() problem with incorrect translations Date: 16 Nov 1999 10:30:51 -0500 Tor Lillqvist <[EMAIL PROTECTED]> writes: > Hi, > > There is a problem with gtk_item_factory_parse_path() if it encounters > a bogus translation string (typically one of those fuzzy translations > I assume the gettext tools generate as more or less pathetic > guesstimates by themselves?). If the translation doesn't contain any Hmmm, but fuzzy matches are disabled by default until someone hand-edits them in... > slash, the code at the end of gtk_item_factory_parse_path() obviously > will crash. This can be demonstrated by running the GIMP with > LANG=ru, for instance. > > It might be argued that translations are supposed to be correct, and > that crashing is thus OK? Anyway, suggested fix below. Hmmm, sort of embarassing. I've been saying for a long time that the translations do _not_ need to contain the full path, since everything but the last component is simply ignored. So, the change that makes it do what I thought it was doing is: Index: gtkitemfactory.c === RCS file: /cvs/gnome/gtk+/gtk/gtkitemfactory.c,v retrieving revision 1.21.2.5 retrieving revision 1.21.2.6 diff -u -r1.21.2.5 -r1.21.2.6 --- gtkitemfactory.c1999/10/07 21:29:41 1.21.2.5 +++ gtkitemfactory.c1999/11/16 15:25:48 1.21.2.6 @@ -968,7 +968,10 @@ translation = str; p = strrchr (translation, '/'); - p++; + if (p) +p++; + else +p = translation; *item = g_strdup (p); Thanks for pointing this out, Owen
Re: gimp && i18n == segfault
> Since about two weeks, setting LANG to any value results on a segmentation > fault on startup. > > Program received signal SIGSEGV, Segmentation fault. > 0x4015822d in g_strdup (str=0x81e8273 "help_page") at gstrfuncs.c:56 > gstrfuncs.c:56: No such file or directory. > (gdb) bt > #0 0x4015822d in g_strdup (str=0x81e8273 "help_page") at gstrfuncs.c:56 > #1 0x40107f18 in __DTOR_END__ () > #2 0x88b4b30 in ?? () > #3 0x42207265 in ?? () > There's only one place where the string "help_page" is ever used and that's around line 1564 in menus.c: gtk_object_set_data (GTK_OBJECT (menu_item), "help_page", (gpointer) entry->help_page); which is called shortly after gtk_item_factory_create_item (item_factory, (GtkItemFactoryEntry *) entry, callback_data, callback_type); This is the function other people reported to crash, so I think you are observing the same problem. I thought I would found the problem when I found out that the german catalog had a multiline help-line string with linebreaks etc. as the translation for a plugin menu_path. Up till today only people using the german catalogs reported this problem. But now you are the second one to claim that it is not related to the german catalog. I have today introduced a patch that should guard us from using unintentionally wrong translations. I haven't beeen able to reproduce the problem, so I depend on more bugreports. Please update your gimp tree and recompile (everything!), then tell us if the problem remains. Salut, Sven
Let's squeeze that i18n bug!
Okay people,
since there seems to be some i18n which I can't reproduce but
a lot of people seem to experience it's time to take the next step.
According to the bug report #6052 and the inline stacktrace it seems
that menus_create_item in menus.c calles gtk_item_factory_create_item
which then calles gtk_item_factory_parse_path which seems to cause the
segfault. This leads to my assumption that an invalid path is being
used OR a GtkItemEntry has a pointer to a not valid memory region.
To aid debugging please send me your output from GIMP compiled with the
little patch attached. Compile it, and run GIMP with gimp 2>log and
send an mail with log attached to [EMAIL PROTECTED]
I assume this bug is introduced by a broken gettext behaviour which
my system doesn't suffer from. I tried all the hints given to reproduce
this but my system stays stable (bastard :)) and GIMP runs like
expected in the set language.
--
Servus,
Daniel
--- app/menus.c.origWed Feb 9 15:39:07 2000
+++ app/menus.c Wed Feb 9 15:46:40 2000
@@ -1555,6 +1555,8 @@
menu_item = gtk_item_factory_get_item (item_factory,
((GtkItemFactoryEntry *) entry)->path);
+ fprintf(stderr,"Created: %s\n",((GtkItemFactoryEntry *) entry)->path);
+
if (menu_item)
{
gtk_signal_connect_after (GTK_OBJECT (menu_item), "realize",
Re: gimp && i18n == segfault
On 9 Feb, Marc Lehmann wrote: > Since about two weeks, setting LANG to any value results on a > segmentation fault on startup. Since I cannot reproduce this (i.e. GIMP works just fine) I'd need more input on this. Your stacktrace seems like it crashes when initialising the help_pages but I can guess that only from the arguments to the g_str function. Could you please compile libgimp with debugging information and report again? -- Servus, Daniel
gimp && i18n == segfault
Since about two weeks, setting LANG to any value results on a segmentation fault on startup. Program received signal SIGSEGV, Segmentation fault. 0x4015822d in g_strdup (str=0x81e8273 "help_page") at gstrfuncs.c:56 gstrfuncs.c:56: No such file or directory. (gdb) bt #0 0x4015822d in g_strdup (str=0x81e8273 "help_page") at gstrfuncs.c:56 #1 0x40107f18 in __DTOR_END__ () #2 0x88b4b30 in ?? () #3 0x42207265 in ?? () (The stack-trace option, btw, outputs:) /usr/app/bin/gimp: fatal error: sigsegv caught /usr/app/bin/gimp (pid:23146): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 g_on_error_stack_trace ( #1 0x4016110c in __DTOR_END__ () #2 0x7070612f in ?? () (i.e. the same output you always get with that option ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
i18n patch
gettext support for plugins: http://www.geocities.com/SiliconValley/Software/gimp/gimp-1.1.15-art- i18n.patch.gz Polish updates: http://www.geocities.com/SiliconValley/Software/gimp/gimp-1.1.15-art- pl.patch.gz Fix all broken po: http://www.geocities.com/SiliconValley/Software/gimp/gimp-1.1.15-art- plugins-i18n.patch.gz __ _ _ , | __ | | __ \ |/ |_ _| Artur Polaczynski <[EMAIL PROTECTED]> | __ | | _/ | | <[EMAIL PROTECTED]><[EMAIL PROTECTED]> |_| |_| |_|\_\ |_| #Poland/Warsaw/Mila College# -- Oferta nie do odrzucenia. Serwery www, konta e-mail. NAJWYZSZA JAKOSC, NAJNIZSZE CENY. ZAPRASZAMY.http://alpha.pl
i18n patch
gettext support for plugins: http://www.geocities.com/SiliconValley/Software/gimp/gimp-1.1.15-art-i 18n.patch.gz Polish updates: http://www.geocities.com/SiliconValley/Software/gimp/gimp-1.1.15-art-p l.patch.gz Fix all broken po: http://www.geocities.com/SiliconValley/Software/gimp/gimp-1.1.15-art-p lugins-i18n.patch.gz __ _ _ , | __ | | __ \ |/ |_ _| Artur Polaczynski <[EMAIL PROTECTED]> | __ | | _/ | | <[EMAIL PROTECTED]><[EMAIL PROTECTED]> |_| |_| |_|\_\ |_| #Poland/Warsaw/Mila College# -- Oferta nie do odrzucenia. Serwery www, konta e-mail. NAJWYZSZA JAKOSC, NAJNIZSZE CENY. ZAPRASZAMY.http://alpha.pl
Re: undo.c [i18n problems]
On Thursday, 13 Jan 2000, David Monniaux wrote: > #: app/undo.c:2874 > msgid "FS to layer" > msgstr "FS vers calque" > > #. ok > #: app/undo.c:2875 > msgid "gimage" > msgstr "gimage" > > #: app/undo.c:2876 > msgid "FS rigor" > msgstr "" > > #: app/undo.c:2877 > msgid "FS relax" > msgstr "" > > What do these options mean? FS is floating selection. I agree, the messages are not exactly very clear. "FS to layer" is what happens when you convert a floating selection into a full, proper layer. "gimage" is a pretty non-descriptive catch-all undo type used in many places, mostly when pushing an entire tile manager on the undo stack. Ideally, we'd go round all the places "gimage" is used, and give a more meaningful undo type (eg paint or fill or whatever). Ditto for "gimage mod" and "paint core". "FS rigor" and "FS relax" are used in pairs to temporarily hide the floating sel and display what's under it (eg during floating selection moves). They should never actually appear as undos by themselves, but as part of a larger group. I don't think there's any need to translate them. In my opinion, floating selections should be taken out and shot, since we now have proper layers. They cause much confusion to users, and require lots of special-case code. Austin
undo.c [i18n problems]
#: app/undo.c:2874 msgid "FS to layer" msgstr "FS vers calque" #. ok #: app/undo.c:2875 msgid "gimage" msgstr "gimage" #: app/undo.c:2876 msgid "FS rigor" msgstr "" #: app/undo.c:2877 msgid "FS relax" msgstr "" What do these options mean? General note to programmers: please document the meaning of some obscure abbreviations and sentences, especially if you coin words yourselves... --- David MonniauxFax: +33 1 44 32 20 80 Laboratoire d'informatique de l'École Normale Supérieure, 45 rue d'Ulm - 75230 PARIS cedex 5 - FRANCE
i18n patch
http://www.di.ens.fr/~monniaux/download/monniaux-i18n-fr-000109.patch.gz More to come when I have spare time. --- David MonniauxFax: +33 1 44 32 20 80 Laboratoire d'informatique de l'École Normale Supérieure, 45 rue d'Ulm - 75230 PARIS cedex 5 - FRANCE
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: i18n of menupaths - perl
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. Well, I don't know how to solve this... > Should these go into the gimp-std-plugins-file? Should I put all > translations into that file then? ...but I'd vote to put the gimp + plugin + perl + whatever-is-in-cvs-gimp into _one_ catalog. 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. bye, --Mitch
i18n of menupaths - perl
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? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: the ultimate solution to the i18n problem...
On Mon, Nov 15, 1999 at 12:11:19PM +0100, David Monniaux <[EMAIL PROTECTED]> wrote: > I have an easy solution. Let us change gettext a little so that it takes > another argument, context. This argument would be ignored when no i18n > takes place, but would be taken into account for the indexing in the .po > files. For instance, we could have: This sounds (technically) ugly. However, if you can embed that info in the string (i.e. technically only one arguments), then it sounds nice. > free | beer-> gratuit i.e. "free\0beer" (although C will have problems with \0 so we might need some other delimiter). OTOH, if the extra argument is a string I could only do this in perl and leave the ugly C detals to Daniel ;) Another way to view this would be to embed some meta-comment into the string, which is in addition used to key the translation. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
