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 608425 - Can't start in non UTF-8 locale
Can't start in non UTF-8 locale
Status: RESOLVED FIXED
Product: gnome-games-superseded
Classification: Deprecated
Component: glchess
2.29.x
Other Linux
: Normal major
: ---
Assigned To: GNOME Games maintainers
GNOME Games maintainers
Depends on: 589090
Blocks:
 
 
Reported: 2010-01-29 10:31 UTC by Pascal Terjan
Modified: 2010-04-07 13:46 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch avoiding the crash (978 bytes, patch)
2010-01-29 18:37 UTC, Pascal Terjan 		none Details | Review

Description Pascal Terjan 2010-01-29 10:31:10 UTC 
[pterjan@plop ~]$ glchess       
/usr/lib/python2.6/site-packages/glchess/gtkui/gtkui.py:42: GtkWarning: Invalid input string
  ui.add_from_file(os.path.join(UI_DIR, name))

It works fine is started as LC_ALL=fr_FR.UTF-8 glchess
Comment 1 Pascal Terjan 2010-01-29 18:37:53 UTC 
Created attachment 152598 [details] [review]
Patch avoiding the crash
Comment 2 Robert Ancell 2010-01-30 23:59:33 UTC 
Hi Pascal,

I can't reproduce the problem but is it solved by adding
gettext.bind_textdomain_codeset(DOMAIN, LOCALEDIR)
to src/lib/defaults.py.in instead?
Comment 3 Pascal Terjan 2010-01-31 09:18:53 UTC 
No it would not, gettext module will change it for python implementation of gettext, while it needs to be done for the C version.

I had already faced this issue and commented on https://bugzilla.gnome.org/show_bug.cgi?id=589090#c4

I found the solution in python doc, at the boftom of http://docs.python.org/library/locale.html

=====
The locale module exposes the C library’s gettext interface on systems that provide this interface. It consists of the functions gettext(), dgettext(), dcgettext(), textdomain(), bindtextdomain(), and bind_textdomain_codeset(). These are similar to the same functions in the gettext module, but use the C library’s binary format for message catalogs, and the C library’s search algorithms for locating message catalogs.

Python applications should normally find no need to invoke these functions, and should use gettext instead. A known exception to this rule are applications that link use additional C libraries which internally invoke gettext() or dcgettext(). For these applications, it may be necessary to bind the text domain, so that the libraries can properly locate their message catalogs.
=====
Comment 4 Takao Fujiwara 2010-02-01 02:08:15 UTC 
I think bug 589090 is for glibc mo files.
I think almost GNOME .po has the following line in the header:

"Content-Type: text/plain; charset=UTF-8\n"

So probably it's no problem when fr_FR.ISO8859-1 .po has the UTF-8 encoding without bind_textdomain_codeset().
Comment 5 Takao Fujiwara 2010-02-01 03:13:25 UTC 
(In reply to comment #4)
> So probably it's no problem when fr_FR.ISO8859-1 .po has the UTF-8 encoding
> without bind_textdomain_codeset().

Sorry, I confirmed bind_textdomain_codeset() is needed in this bug.
Comment 6 Pascal Terjan 2010-04-07 12:45:36 UTC 
Any news ?

This is sad that 2.30 still has this major bug for people not in UTF-8 locale...
Comment 7 Robert Ancell 2010-04-07 13:44:28 UTC 
Sorry, this got forgotten about.  I've fixed it now, please check if it works.

The reason I didn't take the patch immediately:
- There were no instructions on how to reproduce, I think this would have done it?
$ LC_ALL=fr_FR.ISO8859-1 glchess
- The patch set the locale a long way after the start of the application.  I've applied it in defaults.py where the other locale settings are done at program initialization.

Thanks!