On Wed, Feb 8, 2017 at 11:36 AM, Hans-Peter Jansen wrote:
> As a consequence, all these packages will depend on lingua then..
Do the packages actually need to depend on lingua? I see that your PR to
deform doesn't add it, however deform expects it to in the dev environment
One more thing I should add since you mentioned jinja2 and you may not have
seen this yet:
The pyramid_jinja2 cookiecutter actually has some integrated i18n support
that works. We have thrown around some ideas on merging that into the
The issue is *usually* that the TranslationString instance hasn't been run
through `request.localizer.translate(..)`. Now, why not? I haven't dug in
to try and figure that out yet.
On Wed, Feb 8, 2017 at 3:55 PM, Hans-Peter Jansen wrote:
> I've used a good part of the
I got the renderer working via the following diff. Unfortunately the
translator is still not invoked which leads me to believe that there is
something wrong with the i18n tags in the chameleon templates, but I don't
know enough about chameleon to dive in there. Hopefully this was helpful
I've used a good part of the day for getting i18n fixed in deformdemo,
but failed so far. :(
While all debug instrumentation show green lights, the translation
strings aren't picked up for some reason:
2017-02-08 22:49:07,717 DEBUG [deformdemo:63][waitress] locale_name from
I noticed that the renderer is not being used. The
`deform.Form.set_default_renderer(render)` is commented out. Uncommenting
it doesn't solve the problem but it's definitely an issue as the
zpt_renderer isn't actually being used as a result.
On Wed, Feb 8, 2017 at 4:14 PM, Michael Merickel
On Mittwoch, 8. Februar 2017 12:22:27 Michael Merickel wrote:
> On Wed, Feb 8, 2017 at 11:36 AM, Hans-Peter Jansen wrote:
> > As a consequence, all these packages will depend on lingua then..
> Do the packages actually need to depend on lingua? I see that your PR