GNOME Bugzilla – Bug 586297
Application direction is still an issue on pygtk applications
Last modified: 2018-08-17 13:40:23 UTC
Please describe the problem: http://bugzilla.gnome.org/show_bug.cgi?id=503071 This problem is mostly gone, but applications that are built with pygtk still have the wrong behavior (application direction changes to RTL even if theres no translation). Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Please provide a short testcase.
Run a pygtk based application that doesn't have a Hebrew translation (Comix for example) with an a Hebrew locale, the application direction changes to RTL but it should not change. And please read the original bug report.
If you want things fixed, don't expect people to do research. Original bug report has over 100 comments, I have no interest in reading it. What is Hebrew locale?
>If you want things fixed, don't expect people to do research. Original bug >report has over 100 comments, I have no interest in reading it. Needless hostility, i didn't try to upset you or any thing like that. >What is Hebrew locale? Run a pygtk application with this command: "LANG=he_IL.UTF8 APPNAME" (make sure it doesn't have a Hebrew translation) if you run a non pygtk application that doesn't have a Hebrew translation the direction of the application won't change to right-to-left, but, with a pygtk application you get wrong behavior - the direction changes when it's not necessary (no translation). i really hope its more clear now.
That's not hostility. The other option is to ignore this bug report as many others. This way we are at least working on it, right? I reproduced the problem now. Is there something to look at first or do I need to try to debug it out from scratch? I mean, do you have some common recipe on how to solve this somewhere in that huge 100 comment bug?
> I mean, do you have some common recipe on >how to solve this somewhere in that huge 100 comment bug? I really wish i could help, but no. My best guess that it might be comment 90+.
This is from code of _g_dgettext_should_translate(): > if (0 != strcmp (default_domain, "messages") && > '\0' == *translator_comment && > 0 != strncmp (translate_locale, "en_", 3) && > 0 != strcmp (translate_locale, "C")) > should_translate = FALSE; In PyGTK programs (tested with 'comix' and 'pygtk-demo') 'default_domain' which is the result of 'textdomain (NULL)' is 'messages'. In GTK+ it seems to be equal to the name of the binary, though maybe the program I tested with set it itself that way. How would I change the text domain, should PyGTK do it itself or leave to programs to do (in which case it is NOTABUG) and won't it break programs if PyGTK starts doing it now? I ask because I have almost zero knowledge of translation stuff.
Paul, If you read comment 91 of the other bug, and indeed the code you quoted agrees that applications must call textdomain() before initializing Gtk+. Now, it's one of two cases: 1) Pygtk always initializes GTK+ at import time, making it hard to call textdomain() before initializing GTK+, 2) It's simply an application bug. Not sure which is the case.
At the time I've looked into pygtk code and noticed that textdomain() is called when gtk is imported. So probably (1) is the case.
Is there any hope for fixing this bug?
I looked in PyGTK code and couldn't find any textdomain() references except in the deprecated libglade wrapper. So, as far as I see, PyGTK does nothing to set it. If it starts doing it now, will it not break existing applications? I mean, will they still find their translations if text domain becomes different?
The issue I believe is that pygtk is initializing gtk at import time. Most apps import gtk, then call textdomain(). If the order is changed, the bug will go away. Alternatively, pygtk can defer initializing gtk.
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!