#1739: Language switch on wxGUI doesn't affect all strings
---------------------+------------------------------------------------------
Reporter: MilenaN | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Python | Version: unspecified
Keywords: | Platform: All
Cpu: x86-32 |
---------------------+------------------------------------------------------
Comment(by wenzeslaus):
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
([http://docs.python.org/2/library/gettext Python gettext]
[http://docs.python.org/2/library/gettext#localizing-your-application
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
[https://docs.djangoproject.com/en/dev/topics/i18n/translation/ Django
project], moreover there might by also some problems with unicode which
are not clear to me (see [http://www.wefearchange.org/2012/06/the-right-
way-to-internationalize-your.html 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.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1739#comment:5>
GRASS GIS <http://grass.osgeo.org>