After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 589090 - Unable to set translation encoding for gtk.Builder
Unable to set translation encoding for gtk.Builder
Status: RESOLVED WONTFIX
Product: pygtk
Classification: Bindings
Component: gtk
2.14.x
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
gnome[unmaintained]
Depends on:
Blocks: 608425
 
 
Reported: 2009-07-20 08:05 UTC by Andrey Rahmatullin
Modified: 2018-08-17 13:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andrey Rahmatullin 2009-07-20 08:05:16 UTC
When gtk.Builder gets a translation for <property translatable="yes"> it
displays it correctly only in UTF-8 locale. C gtk programs are fixed by
adding bind_textdomain_codeset(domain, "utf-8"); I tried to call python
bind_textdomain_codeset, but it didn't help. Here is complete testcase:

#!/usr/bin/python
import gtk
from locale import *
from gettext import bind_textdomain_codeset

setlocale(LC_ALL, '')
bind_textdomain_codeset("libc", "UTF-8")
Builder = gtk.Builder()
Builder.set_translation_domain("libc")
Builder.add_from_string(
"""<?xml version="1.0"?>
<interface><object class="GtkDialog" id="dialog">
<property name="title" translatable="yes">Success</property>
</object></interface>""")
Dialog = Builder.get_object("dialog")
Dialog.resize(300, 100)
Dialog.show()
gtk.main()
Comment 1 Paul Pogonyshev 2009-08-10 20:10:30 UTC
How do I reproduce the bug?  I have en_US.UTF-8 locale, the following is the output of 'localedef --list-archive':

de_DE.utf8
en_GB.utf8
en_US.utf8
he_IL.utf8
ru_RU.utf8
Comment 2 Andrey Rahmatullin 2009-08-11 17:05:35 UTC
You need to generate, for example, ru_RU.KOI8-R and run the program in that locale (exporting LC_ALL=ru_RU.KOI8-R, for example).
Comment 3 Frederic Crozat 2009-09-29 14:52:08 UTC
confirming with latin1 or latin15 locale (fr_FR.ISO-8859-1)
Comment 4 Pascal Terjan 2009-09-29 15:38:16 UTC
The issue is that there is no way to define codeset for the C level gettext library that is used by gtk.

bind_textdomain_codeset will only define it for the python gettext which is useless here

Maybe Builder.set_translation_domain should enforce UTF-8 as this is what gtk needs (and this won't break python app as it uses it's own code)
Comment 5 Pascal Terjan 2009-09-29 15:50:12 UTC
And libglade binding already does this :

override glade_bindtextdomain kwargs
static PyObject *
_wrap_glade_bindtextdomain(PyObject *self, PyObject *args, PyObject *kwargs)
{
    static char *kwlist[] = { "domainname", "dirname", NULL };
    char *domainname, *dirname = NULL, *ret;

    if (!PyArg_ParseTupleAndKeywords(args, kwargs,
                                     "s|s:glade.bindtextdomain", kwlist,
                                     &domainname, &dirname))
        return NULL;
    ret = bindtextdomain(domainname, dirname);
    if (!ret) {
        PyErr_SetString(PyExc_MemoryError, "Not enough memory available.");
        return NULL;
    }
#ifdef HAVE_BIND_TEXTDOMAIN_CODESET
    bind_textdomain_codeset(domainname, "UTF-8");
#endif
    return PyString_FromString(ret);
}
Comment 6 Pascal Terjan 2010-01-29 17:57:28 UTC
Workaround: Use locale.bindtextdomain_codeset(domain, "UTF-8")
Comment 7 Pascal Terjan 2010-01-29 18:32:23 UTC
Sorry, I mean locale.bind_textdomain_codeset(domain, "UTF-8")
Comment 8 André Klapper 2018-08-17 13:36:58 UTC
pygtk is not under active development anymore and had its last code changes
in 2013. Its codebase has been archived:
https://gitlab.gnome.org/Archive/pygtk/commits/master

PyGObject at https://gitlab.gnome.org/GNOME/pygobject is its successor. See https://pygobject.readthedocs.io/en/latest/guide/porting.html for porting info.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent version of PyGObject. Thanks!