On Wed, Oct 29, 2008 at 01:36:48AM +0900, Takao Fujiwara - Tokyo S/W Center 
wrote:

> I explained we use bindtextdomain, textdomain and _ in the previous mail.
> Let's use the following patch.
>
> --- pkg/src/modules/misc.py.orig
> +++ pkg/src/modules/misc.py
> @@ -38,6 +38,7 @@
>   import time
>   import calendar
>   import shutil
> +import gettext
>   from stat import *
>
>   import pkg.urlhelpers as urlhelpers
> @@ -45,6 +46,8 @@
>   from pkg.client.imagetypes import img_type_names, IMG_NONE
>   from pkg import VERSION
>
> +_ = gettext.gettext
> +

I'm completely failing to understand your argument.  I read your
explanation, and it makes no sense to me.  I apologize for being thick.

As I read gettext.py, then running gettext.install("domain") instantiates
a GNUTranslations object bound to "domain", and installs its .gettext()
method into the __builtins__ dict as "_".  Thus, once you call
gettext.install(domain) in the front-end program, _("message") will
translate "message" in domain "domain" via the .mo file that was found when
the GNUTranslations object was instantiated.

Using the top-level bindtextdomain(), textdomain(), and gettext() functions
use a completely different mechanism to maintain the notion of the current
domain.  They use the global variable _current_domain, and instantiate a
GNUTranslations object for that domain on every message lookup.  It seems
very wasteful, and I don't see why it's there.

I don't understand why we need to call bindtextdomain() at all, but that
functionality should be subsumed by the GNUTranslations object.  Calling
textdomain() shouldn't be necessary for the same reason.  And gettext()
doesn't seem to provide any benefit.

On top of which, it makes zero sense that this is absolutely required for
this one file and nowhere else.

Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to