all _() defines for i18n

[Gediminas Paulauskas <menesis delfi lt>]

On 21 Apr 2001 11:54:18 +0200, Keld J¸rn Simonsen wrote:
> 9. What features do we need in gettext?
> 
> Can we make gettext more helpful to translators?
>     eg msgid "file \[noun\]"
>         msgid "file \[verb\]"
> 
> Both giving a hint to the translator on what is meant,
> and also prepared for machine translation. text in \[\]
> should then be ignored when the string is written.   

This idea was talked about here for several times, but nothing decided
or done. There were several proposals for how to mark "qualifier" part
of text:

"#noun#file"
"!noun!file"
"[noun]file"
"noun|file"
"noun:file"

The "translate this \[or die\]" proposal is the worst of all:
1) The comment is at the end, so the string must be copied! It means a
major slowdown and increased memory usage!
2) Why backslashes are needed?
3) It uses 4 not-useful characters

Others are OK. If beginning is not marked (i.e. there is no starting
"["), the function can be much faster because fewer operations need to
be done. OTOH, then it is easier to determine if string has comment, but
I don't see a point in checking that.

Nautilus uses "[Items ]completed in '%s' seconds", but the
implementation of extracting that string is quite complex (81 line of
code!), because it checks if brackets are balanced, also, there can be
multiple bracketed text in one string
("[Program ]was running for %d[ time units]"). Again, I can't think of
example when it can be useful. The main requirement is just to have
equal strings be different, depending on context.

What's left? Popular characters (like ':', '[', ']', '!') should not be
used, because that can make bad things happen and prevents
optimizations. Grepping through my CVS tree, I have not found a single
po file which contained '|', so I assume this will never be used.

So, summary of all that is:
msgid "verb|file"
msgstr "put"
or 
msgstr "action|put"

Translators not always understand what happens here and translate what
they do not need to :)
 
> We recommended a wrapper function to gettext, with
> a macro name of Q_() for this. It should probably be a wrapper
> function, so gnome was not dependent on the new gettext library.
> But it could be implemented in gettext too.

This needs patching po/Makefile.in.in file to include  "--keyword\=Q\_"
xgettext argument.

Also, if this is added to gnome-libs, it makes package depend on that
version. Well, it can be added to 2 version (i.e. libgnome), but I
suggest moving such generally useful code into glib. That is, half of
libgnome/gnome-i18n.h goes into glib/gi18n.h (all _(), N_(), Q_(), D_()
and L_() defines).

The last two, D_() and L_(), are ideas used in
libgnomeui/gnome-app-helper.[ch], and are useful for libraries.
L_(string) is used where N_("something") can be passed both from library
and from application, and there is no way to determine which domain to
use. So both are tried. I used this in gal/widgets/e-popup-menu.c.
D_() means explicit default domain, i.e. gettext() in case of
#define _(x) dgettext(PACKAGE, x)
Which should be used in libraries.

This is so common problem that libraries have copied versions of
libgnome/gnome-i18nP.h, because they do not want to depend on gnome-libs
(oaf/liboaf/oaf-i18n.h, gal/gal/util/e-i18n.h).

Bonobo 1.0 uses
#define GNOME_I18N_EXPLICIT_TRANSLATION_DOMAIN PACKAGE
#include <libgnome/gnome-i18n.h>
which is the right thing to do.

I suggest renaming it to G_I18N_LIBRARY_DOMAIN, or, better, have a
#define G_I18N_THIS_IS_A_LIBRARY 1

and in glib/gi18n.h have:

#ifdef G_I18N_THIS_IS_A_LIBRARY
#define D_(x) gettext (x)
#define L_(x) g_i18n_gettext_unknown (x)
#define _(x) dgettext (PACKAGE, x)
#else
#define _(x) gettext (x)
#endif

L_() and D_() are useful only in libraries, and PACKAGE is defined in
every package which uses autoconf anyway.

Also, there can be a simple trick
#ifndef PACKAGE
#error "You MUST #include <config.h> at the top of your c file"
#endif

because programmers forget to do that :)

-- 
Gediminas Paulauskas
´

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers