Opened 12 years ago

Closed 10 years ago

#1739 closed defect (fixed)

Language switch on wxGUI doesn't affect all strings

Reported by: MilenaN Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: Translations Version: unspecified
Keywords: wxGUI, Python, underscore, _, gettext, doctest Cc:
CPU: x86-32 Platform: All

Description

Switch the language to any other (Settings > Pref > Appearance tab)
Open GRASS again
wxGUI is in the selected language, but error messages are not (try to find one).

Change History (7)

comment:1 by martinl, 12 years ago

Component: DefaultwxGUI
Keywords: wingrass added

comment:2 by marisn, 12 years ago

Component: wxGUIPython
Keywords: wingrass removed
Platform: MSWindows XPAll
Summary: Language switch on wxGUI doesn't care about all the "mo" filesLanguage switch on wxGUI doesn't affect all strings

If I understood correctly from non-helpful bug report, issue is with strings reported by Python parser preprocessor (or whatever it is).

Issue is twofold:

  • /lib/python strings are not extracted for translation
  • /lib/python/task.py isn't using gettext

First part can be solved by (diff for 6.4 svn):

Index: locale/Makefile
===================================================================
--- locale/Makefile     (revision 53236)
+++ locale/Makefile     (working copy)
@@ -39,6 +39,7 @@
 TCL_POTFILES = find ../ -name '*.tcl' ! -path '../dist*' ! -path '../visualization/nviz/*' | xargs grep -l "\\[_ \|\\[G_msg"
 NVIZTCL_POTFILES = find ../visualization/nviz/scripts \( ! -regex '.*/\..*' \) | xargs grep -l "\\[_ \|\\[G_msg"
 WXPY_POTFILES = find ../gui/wxpython -name '*.py' | xargs grep -l "_(\""
+PYLIB_POTFILES = find ../lib/python -name '*.py' | xargs grep -l "_(\""
 
 #The xgettext utility is used to automate the creation of
 #portable message files (.po)
@@ -49,6 +50,7 @@
        fi
        @echo "Generating $(LIBDOMAIN)..."
        xgettext -k_ -o ./templates/$(LIBDOMAIN).pot `$(LIB_POTFILES)`
+       xgettext -j -k_ -o ./templates/$(LIBDOMAIN).pot `$(PYLIB_POTFILES)`
        @echo "Generating $(MODDOMAIN)..."
        xgettext -k_ -o ./templates/$(MODDOMAIN).pot `$(MOD_POTFILES)`
        @echo "Generating $(TCLDOMAIN)..."
Index: lib/python/task.py
===================================================================
--- lib/python/task.py  (revision 53236)
+++ lib/python/task.py  (working copy)
@@ -32,6 +32,10 @@
 
 from core import *
 
+# i18N
+import os, gettext
+gettext.install('grasslibs', os.path.join(os.getenv("GISBASE"), 'locale'), unicode=True)
+
 class grassTask:
     """!This class holds the structures needed for filling by the
     parser

Still even after applying supplied patch, translated strings are ignored in module error dialogs. My guess - something with passing LANG to child processes. Somebody with better understanding of Python+parser magic should look into it.

Steps to reproduce issue:

  • start GRASS with non-english interface (can change in WXGUI settings)
  • start any GRASS module with required parameters and press RUN to generate "parameter missing" error
  • to see correct behaviour, testing languages grasslibs_LANG.po file must be upgraded to contain translation for "parameter missing" etc. strings.

comment:3 by cmbarton, 12 years ago

I will test again on the Mac when I get back to town in a couple days. But as of a week or 2 ago, this did not work at all on the Mac for 6.4.3.

Michael

comment:4 by MilenaN, 11 years ago

Milestone: 6.4.36.4.4

I found more examples where translated strings are ignored:

  1. Map Display buttons flags
  1. Dropdown list "Element list:" at Preferences -> Settings -> Appearance tab

comment:5 by wenzeslaus, 11 years ago

I have completely changed the gettext usage in wxGUI.

As reported by mmetz and MilenaN, the translation was active only in the files where gettext.install function was called. Adding gettext.install function call to the file enabled translation for the particular file, although according to the documentation one and only one call of gettext.install function should be enough (Python gettext localizing your application). The reason why it is not working is not known.

However, gettext.install function is adding the underscore (_("...")) function into the __builtins__ module. This makes life of tools such as pylint and pep8 (and maybe also doctest) harder and thus usage of gettext.install function is not considered as a good practice by some most notably Django project, moreover there might by also some problems with unicode which are not clear to me (see this blog post).

Now I've implemented better different practice of using gettext which is supposed to be more general since it is also usable for Python modules (in the sense of libraries). The underscore function is no longer build-in (in global namespace) and must by defined (or imported) explicitly in every file.

Code to enable translation for the file and define undescore function:

import gettext
_ = gettext.translation('grasswxpy', os.path.join(os.getenv("GISBASE"), 'locale')).ugettext

In the case when the translation is not available and exception is thrown (e.g., during compilation, maybe only with different locale). For this case I added the null translation underscore function (there is some way using gettext, but this should be enough). No error is reported in this case (I don't like it, but I don't know how to report it and not introduce some strange message during compilation).

The full code for enabling translation:

try:
    import gettext
    _ = gettext.translation('grasswxpy', os.path.join(os.getenv("GISBASE"), 'locale')).ugettext
except IOError:
    # using no translation silently
    def null_gettext(string):
        return string
    _ = null_gettext

It is possible to just import the underscore function and since the code is long the function is exposed by (gui/wxpython/)core.utils module and can be imported by others:

from core.utils import _

Some modules cannot use the import since they are imported by core.utils. These modules have to use the larger code above. (This could be changed in the future by introducing the core.translations module which needs to be on the were top of the import tree).

This was implemented in the r57219 and r57220 (first changesets contained bug, that's why committed in parts). These changesets (for trunk) fix the issue specified in the comment:4 by MilenaN. (Both changesets are hopefully easily revertable if necessary).

However, there is still issue with strings in lib/python as specified in comment:2 by marisn. For GRASS 6 the string are no even generated as noted in comment:2. For GRASS 7 the strings are generated and I'm getting the translation. However, grass.script modules are using gettext.install which could be OK (but I thing it isn't) for GRASS Python modules but it is wrong when grass.script and friends are used from wxGUI. So this should be probably changed too (very bad practice, against manual and this method did not work for wxGUI), but this means to change not only all the files. I'm not sure about GRASS Python modules and other libraries such as temporal or pygrass. However, the modules seems to work, so there is no pressure for the change.

comment:6 by marisn, 11 years ago

It should work just fine in GRASS 7 as long as specified language has its supporting locale installed. If language lacks matching locale in the system, I'm not certain if it can be solved at all. As GRASS 6 and 7 startup scripts are different, it is not possible to backport changes. I would vote for testing in 7 and closing as wontfix for 6.

in reply to:  6 comment:7 by wenzeslaus, 10 years ago

Component: PythonTranslations
Keywords: wxGUI Python underscore _ gettext doctest added
Milestone: 6.4.47.0.0
Resolution: fixed
Status: newclosed

Replying to marisn:

It should work just fine in GRASS 7 as long as specified language has its supporting locale installed. If language lacks matching locale in the system, I'm not certain if it can be solved at all. As GRASS 6 and 7 startup scripts are different, it is not possible to backport changes. I would vote for testing in 7 and closing as wontfix for 6.

No complains since then, so closing as fixed. Feel free open a new ticket if you encounter any other problems.

Related/unresolved:

  • The issue remains for library and modules, follow #2425.
  • Smaller issue related to toolboxes is inside of #2142.
  • r57219 has some code duplication (visible in r57220) which should be removed in the future (the solution is probably a separate (wxgui.)translations package/module).
Note: See TracTickets for help on using tickets.