[Python-bugs-list] [ python-Bugs-516412 ] Python gettext doesn't support libglade

noreply@sourceforge.net noreply@sourceforge.net
Wed, 27 Mar 2002 10:53:23 -0800


Bugs item #516412, was opened at 2002-02-12 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470

Category: Python Library
>Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christian Reis (kiko_async)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python gettext doesn't support libglade

Initial Comment:
Libglade is a library that parses XML and generates
GTK-based UIs in runtime. It is written in C and
supports a number of languages through bindings.

James Henstridge has maintained a set of bindings for
Python for some time now. These bindings work very
well, _except for internationalization_.

The reason seems now straightforward to me. Python's
gettext.py is a pure python implementation, and because
of it, bindtextdomain/textdomain are never called. This
causes any C module that uses gettext to not activate
the support, and not use translation because of it.

Using Martin's intl.so module things work great, but it
is a problem for us having to redistribute it with our
application. Any other suggestions to fix?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:53

Message:
Logged In: YES 
user_id=21627

This is fixed with

configure 1.291
configure.in 1.301
pyconfig.h.in 1.25
liblocale.tex 1.28
NEWS 1.369
_localemodule.c 2.29

Notice that applications that want to change the C library's
domain bindings will have to invoke locale.bindtextdomain; I
decided not to provide automatic forwarding from
gettext.bindtextdomain to locale.bindtextdomain, since the C
library and Python may have different message catalog
formats (e.g. on Solaris); this might confuse the C library.


----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-02-13 03:15

Message:
Logged In: YES 
user_id=146903

Some libraries (libglade in this case) translate some
messages on behalf of the application (libglade translates
messages in the input file using the default translation
domain, or some other domain specified by the programmer).

This is a case of wanting python's gettext module to
cooperate with the C level gettext library.

For libglade, this could be achieved by making the
gettext.bindtextdomain() and gettext.textdomain() calls to
call the equivalent C function in addition to what they do now.

For most messages in gtk+ itself, it will use dgettext() for
most messages already, so isn't a problem.  The exception to
this is places where it allows other libraries (or the app)
to register new stock items, which get translated with a
programmer specified domain.

As of gettext 0.10.40, there should be no license problems,
as the license for the libintl library was changed from GPL
to LGPL.

It should be a fairly simple to implement this; just needs a
patch :)


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-13 02:17

Message:
Logged In: YES 
user_id=21627

How does gtk invoke gettext? It sounds buggy in the respect
that it expects the textdomain to be set globally; a library
should not do that. Instead, the right thing (IMO) would be
if   gtk called dgettext, using an application-supplied
domain name. It would be then the matter of the Python gtk
wrapper to expose the GTK APIs for setting the text domain.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 14:52

Message:
Logged In: NO 

If what you want is a way to call bindtextdomain/textdomain
from Python, feel free to supply a patch or ask martin to
add intl.so to the distribution.

--Guido (@#$% SF always logs me out :-( )

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470