Description of problem: trying start game, it crashes with message: 2014-08-23 18:35:51,220 - gvr.utils - ERROR - Cannot set language to 'cs_CZ' switching to English Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/gvrng/utils.py", line 169, in set_locale languages=languages) File "/usr/lib64/python2.7/gettext.py", line 471, in translation raise IOError(ENOENT, 'No translation file found for domain', domain) IOError: [Errno 2] No translation file found for domain: 'gvrng' Traceback (most recent call last): File "./gvrng.py", line 106, in <module> import gvr_gtk # the frontend to use File "gui-gtk/gvr_gtk.py", line 63, in <module> bindtextdomain(app_name, utils.get_locale(),locale_dir) TypeError: bindtextdomain() takes at most 2 arguments (3 given) and with "LANG=en_US.UTF-8" it crashes with message: Traceback (most recent call last): File "./gvrng.py", line 106, in <module> import gvr_gtk # the frontend to use File "gui-gtk/gvr_gtk.py", line 63, in <module> bindtextdomain(app_name, utils.get_locale(),locale_dir) TypeError: bindtextdomain() takes at most 2 arguments (3 given) Version-Release number of selected component (if applicable): gvrng-4.4-7.fc20.noarch How reproducible: Alvays, tested on F19 i686 and F20 x86_64
looks like we need to add Czech translations into gvrng. This patch should at least let you continue in english until I can get that translation done.
Created attachment 930573 [details] patch to properly set locale
Hi Neil, thanks for looking at this. I was little digging about, and it seems as problem is somewhere else. What I found: - patch is not needed, it works even with "lang = 'en'" in utils.py at line 143 - Czech translations is always present in gvrng - patch should be this: --- utils.py.orig 2013-02-22 13:40:22.000000000 +0100 +++ utils.py 2014-08-27 11:07:44.425492793 +0200 @@ -65,7 +65,7 @@ # Intended to make packaging easier FRONTENDDIR = os.path.join(get_rootdir(),'gui-gtk') PIXMAPSDIR = os.path.join(get_rootdir(),'gui-gtk','pixmaps') -LOCALEDIR = os.path.join(get_rootdir(),'locale') +LOCALEDIR = '/usr/share/gvrng/locale' module_logger.debug("Constant paths:") module_logger.debug("RCFILE %s" % RCFILE) because gvrng .mo files are at /usr/share/gvrng/locale/*lAnGuAgE*/LC_MESSAGES/gvrng.mo - while actual code evaluate their to /usr/lib/python2.7/site-packages/gvrng/locale/*lAnGuAgE*/LC_MESSAGES/gvrng.mo Or .mo files should be where gvrng expect them and should be changed gvrng .spec and/or makefile - it seems as both variants are acceptable. - own problem with gvrng at my system is 'bindtextdomain()' call: gvrng/gui-gtk/gvr_gtk.py expect that it will call bindtextdomain() from gvrng/gui-gtk/SimpleGladeApp.py - but instead this, (for for me unknown reason) is called bindtextdomain() from /usr/lib/python2.7/site-packages/SimpleGladeApp.py from RPM package tepache-1.1.2-4.fc19.noarch - which I have instaled because gresistor package depend on it. And these two bindtextdomain() differs - tepache version has two params, and gvrng version has three. Perhaps it is necessary to fix gvr_gtk.py to call right bindtextdomain(). (excuse for not provide patch, I'm not programmer) - finally, I translate 'WBSummary-en.txt' into Czech, result is attached. It should be located in /usr/lib/python2.7/site-packages/gvrng/po/cs/WBSummary-cs.txt (excuse for not translating other parts, my English is too bad for tolerable result)
Created attachment 931387 [details] into Czech translated WBSummary-en.txt described in previous report.
Oh, thank you! I see the problem. We don't need to change the gvrng code here, I just need to update the packaging layout. I'll have a test build for you shortly.
Created attachment 931552 [details] new gvrng build hey, could you try this package out please? I've placed the locale files where the gvrng program expects to find them. It should fix your issue. Thanks!
Still it call bad 'bindtextdomain()' (when tepache RPM installed) from '/usr/lib/python2.7/site-packages/SimpleGladeApp.py' (instead of right one from 'gvrng/gui-gtk/SimpleGladeApp.py') This patch solve it for me: --- gvrng.py.orig 2013-02-22 13:40:22.000000000 +0100 +++ gvrng.py 2014-08-28 06:16:44.702075336 +0200 @@ -101,7 +101,7 @@ Text.set_Intro(LocaleMesg[1])# and the intro text # when the frontend is not in sitepackages, as is the case for the org install -sys.path.append('gui-gtk') +sys.path.insert(0,'gui-gtk') import gvr_gtk # the frontend to use I'm not programmer and not know when it is right solution, I was only inspired by https://docs.python.org/2/reference/simple_stmts.html#the-import-statement http://legacy.python.org/dev/peps/pep-0302/
sorry, forgot that bit. yeah, I'd like to fix that in the package itself without path trickery, but theres not really a better way given the way the gtk code for this app is laid out.
gvrng-4.4-7.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gvrng-4.4-7.fc19
Neil, please, can You also include WBSummary-cs.txt (my Czech translation of WBSummary-en.txt) attached here? When I bother with it... Thanks in advance.
Package gvrng-4.4-7.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gvrng-4.4-7.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9930/gvrng-4.4-7.fc19 then log in and leave karma (feedback).
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.