turbogears migration: tests: internationalization

[Alessandro Molina]

Reason is kallithea/model/forms.py using _() calls ( from tg.i18n import
ugettext as _ )
Those translate the text the moment they are called, but as they are used
in class attributes they actually get called the moment you import the
module.

As when you import the module there is no request in place TG is unable to
get the language that should be used for that request and translate those.
The proper fix is to use lazy_ugettext in place of ugettext ->
http://turbogears.readthedocs.org/en/latest/reference/classes.html#tg.i18n.lazy_ugettext

Probably my fault, I converted most of those global imports using sed, but
I have not been wise enough to convert those to the lazy version :)

On Sat, Apr 23, 2016 at 9:51 PM, Thomas De Schampheleire <
patrickdepinguin at gmail.com> wrote:

> Hi Alessandro,
>
> Parking the routes problems to let Søren look into the post/delete
> handling, the other thing I have been struggling with for a very long
> time is with internationalization in tests.
>
> I seem to fail to understand how the initialization of Kallithea is
> different in the test suite versus in the normal run. In the normal
> case, internationalization is set up 'automatically' but with the test
> suite it does not seem the case.
> Even for the original pylons based test suite, some special actions
> are made, for internationalization and for others, which do not seem
> necessary in the standard run. Can you elaborate about the cause of
> this difference?
>
> Specifically, a reproduction scenario is:
>
> - start from the lastly pushed patches in the kallithea-tg repo
> (7da2b0b701c4)
>
> - run:
>
> $ py.test kallithea/tests/functional/test_pullrequests.py
>
> - result is this:
>
> No handlers could be found for logger "tg.appwrappers.transaction_manager"
> Test session starts (platform: linux2, Python 2.7.10, pytest 2.9.1,
> pytest-sugar 0.6.0)
> rootdir: /home/tdescham/repo/contrib/kallithea/kallithea-tg, inifile:
> pytest.ini
> plugins: sugar-0.6.0
>
> ――――――――――――――――――――――――――――――――――――――――――――――――――― ERROR collecting
> kallithea/tests/functional/test_pullrequests.py
> ―――――――――――――――――――――――――――――――――――――――――――――――――――
> kallithea/tests/functional/test_pullrequests.py:7: in <module>
>     from kallithea.controllers.pullrequests import PullrequestsController
> kallithea/controllers/pullrequests.py:57: in <module>
>     from kallithea.model.forms import PullRequestForm, PullRequestPostForm
> kallithea/model/forms.py:49: in <module>
>     class LoginForm(formencode.Schema):
> kallithea/model/forms.py:57: in LoginForm
>     'empty': _('Please enter a login'),
> ../venv/kallithea-tg/lib/python2.7/site-packages/tg/i18n.py:89: in ugettext
>     return tg.translator.ugettext(value)
>
> ../venv/kallithea-tg/lib/python2.7/site-packages/tg/support/objectproxy.py:19:
> in __getattr__
>     return getattr(self._current_obj(), attr)
> ../venv/kallithea-tg/lib/python2.7/site-packages/tg/request_local.py:178:
> in _current_obj
>     return getattr(context, self.name)
>
> ../venv/kallithea-tg/lib/python2.7/site-packages/tg/support/objectproxy.py:19:
> in __getattr__
>     return getattr(self._current_obj(), attr)
> ../venv/kallithea-tg/lib/python2.7/site-packages/tg/support/registry.py:72:
> in _current_obj
>     'thread' % self.____name__)
> E   TypeError: No object (name: context) has been registered for this
> thread
>
> =======================================================================
> short test summary info
> ========================================================================
> ERROR kallithea/tests/functional/test_pullrequests.py
>
>
> So, upon executing the imports of the test (not even real test code),
> some step uses tg.translator.ugettext() which fails.
>
> I have been adding gazilions of print statements all over the place
> trying to grasping the issue, I tried editing the test.ini file to
> explicitly set a language, or even set a language in the test setup
> code, but all in vain.
>
> I hope you could spare some time to help me out here.
> (I'm still also very interested in understanding how to debug such
> issues in a more clever way than just with print statements.)
>
>
> Thanks again,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20160426/8fe4d02e/attachment.html>