GNOME Bugzilla – Bug 703469
Glade UI does not show translated strings
Last modified: 2013-07-26 09:05:29 UTC
Created attachment 248236 [details] Screenshot for debug The UI created by glade does not show translated strings. I've attached a screenshot which will help you identify the problem. I inserted debug markers ("[i18n]") into translatable strings of the UI using podebug. You can see that some strings including "Advanced" and "Change edit mode" do not have the marker. It means gnome-schedule cannot show translations correspoinding to those strings. They are from gnome-schedule.glade.
Created attachment 248238 [details] [review] Make glade UI show translated strings It seems that we need to initialize i18n before importing glade. So I imported lang at the top of mainWindow.py. I checked it fixed the problem.
Created attachment 248240 [details] Screenshot after applying patch You see that some strings still do not have the debug mark, but they are from the GTK stock items. So that's no problem.
Created attachment 249159 [details] translated strings through programtically set strings Hi, I think most of those strings are set programatically in src/mainWindow.py (because of a dynamic UI), so they are indeed translated, but through Python-strings. Regards, Gaute
Hmm, I guess your localedir is /usr/share/locale. Glade seems to search /usr/share/locale for message catalogs. For now, it doesn't seem to respect the localedir specified in building gnome-schedule. In other words, if your MO file is installed in /usr/share/locale/${LANG}/LC_MESSAGES, there is no problem. However, if it is installed another directory, the glade UI won't show translated strings. It might be a bug of libglade, but I'm not sure about that. The patch which I attached works well as a workaround.
Hm, I didn't install to /usr, just an arbitrary directory.
What versions are you running of GTK+, libglade and so on? Do you have the necessary gnome-developer tools installed for registering the schemas? Might be problematic if you installed as a different user than the one you tried to run it with if it is to a non-standard location.
I use jhbuild to build GNOME modules on Fedora 19. The version of each module usually refers to HEAD of the master branch, i.e. the latest commit. Here are each of the related modules and the commit which it is besed on: - gnome-schedule: 57160d633dc1828c1d1a2dcd67cf06d2026271d6 - glib: dc2d3f77811c1247f8c46030557e4f76804bdf9e - gtk+ 9a0fb236251b40bd03873dc530b72adba5288528 - gtk+-2: 561d1c6358333732bbd11040d7fefa2a0c04031a - libglade: 8908de2289f58f5197a6877ca9d0ed042b62e5d7 - glade: 54763c43ffe8e98ecec3705f1031ca25ba793bfa If you have no problem, I'd like to know what you set the --prefix option to in configuring gnome-schedule and whether you have your mo in /usr/share/locale/${LANG}/LC_MESSAGES. Would you tell me about them?
I use: $ ./autogen --prefix=$(pwd)/inst; make; make install I have nothing in /usr/share/locale/${LANG}/LC_MESSAGES except firefox mo's. Is 'import lang' in mainWindow.py enough to fix this issue for you? Because in that case it shouldn't be a problem to apply your patch. Regards, Gaute
(In reply to comment #8) > I use: $ ./autogen --prefix=$(pwd)/inst; make; make install > > I have nothing in /usr/share/locale/${LANG}/LC_MESSAGES except firefox mo's. > Thank you for the information. > Is 'import lang' in mainWindow.py enough to fix this issue for you? Because in > that case it shouldn't be a problem to apply your patch. > Yes. I've checked the patch fixes the issue. Could you apply it? Thank you.
Yes, applied. Thanks for figuring this out. Gaute