Re: [pylons-devel] i18n in deformdemo dysfunctional - solved!
On Mittwoch, 8. Februar 2017 16:33:17 Michael Merickel wrote: > 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 > though. Thank you for that. I found the culprit! The call to: deform.renderer.configure_zpt_renderer() intercepts the translation handling by replacing the carefully constructed zpt_renderer with a default one, that omits any translators. Hrmpf. I'm preparing fixes for deformdemo at the moment, and will report this issue to the deform project. While at it, what is the purpose of these hidden schema nodes: _LOCALE_ = colander.SchemaNode( colander.String(), widget=deform.widget.HiddenWidget(), default=locale_name) Cheers, Pete -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
Re: [pylons-devel] i18n state of affairs
On Mittwoch, 8. Februar 2017 15:41:29 Michael Merickel wrote: > One more thing I should add since you mentioned jinja2 and you may not have > seen this yet: > > https://github.com/domenkozar/pyramid-cookiecutter-jinja2 > > The pyramid_jinja2 cookiecutter actually has some integrated i18n support > that works. We have thrown around some ideas on merging that into the > default starter scaffold [1], but I'm afraid that we don't yet have the > "best practice" defined and would want it to be synchronized with whatever > pyramid discusses in its docs [2]. > > [1] https://github.com/Pylons/pyramid_jinja2/issues/139 > [2] http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/i18n.html Thanks for the pointers. I've left a comment on the issue and invited Steve to this thread. There's one decision to make as the next step: Does the involved parties agree to leave the translation procedures somewhat outside the normal workflow and supply a i18n.sh script, accompanied with a default lingua.cfg file, that checks and proposes to install "lingua" and "babel", if missing? "lingua" will be used for extraction, "babel" provides the extraction plugins for "mako" and "jinja2" templates, that are used by lingua's pot-create script. Does anybody foresee any problems with this approach? Cheers, Pete -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
Re: [pylons-devel] i18n in deformdemo dysfunctional
Hi Michael,
I will look into this right now.
Thanks for your care. Much appreciated.
Cheers,
Pete
On Mittwoch, 8. Februar 2017 16:33:17 Michael Merickel wrote:
> 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
> though.
>
> diff --git a/deformdemo/__init__.py b/deformdemo/__init__.py
>
> > index 098046a..6f023f6 100644
> > --- a/deformdemo/__init__.py
> > +++ b/deformdemo/__init__.py
> >
> > @@ -70,7 +70,7 @@ def translator(term):
> > deform_template_dir = resource_filename('deform', 'templates/')
> > zpt_renderer = deform.ZPTRendererFactory(
> >
> > -[deform_template_dir], translator=translator)
> > +(deform_template_dir,), translator=translator)
> >
> > # the zpt_renderer above is referred to within the demo.ini file by
> >
> > dotted name
> >
> > @@ -2763,8 +2763,8 @@ def main(global_config, **settings):
> > config.include('pyramid_chameleon')
> > renderer = config.maybe_dotted(renderer)
> >
> > -#deform.Form.set_default_renderer(renderer)
> > -deform.renderer.configure_zpt_renderer(["deformdemo:custom_widgets"])
> > +deform.Form.set_default_renderer(renderer)
> > +
> > deform.renderer.configure_zpt_renderer(("deformdemo:custom_widgets",))
> >
> > config.add_static_view('static_deform', 'deform:static')
> > config.add_static_view('static_demo', 'deformdemo:static')
>
> On Wed, Feb 8, 2017 at 4:19 PM, Michael Merickel wrote:
> > 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
> >
> > wrote:
> >> 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:
> >>> Hi,
> >>>
> >>> 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
> >>> default_locale_negotiator: de
> >>> 2017-02-08 22:49:07,718 DEBUG [deformdemo:2080][waitress] locale_name:
> >>> de, request._LOCALE_: de
> >>> 2017-02-08 22:49:09,795 DEBUG [deformdemo:63][waitress] locale_name from
> >>> default_locale_negotiator: en
> >>> 2017-02-08 22:49:09,795 DEBUG [deformdemo:2080][waitress] locale_name:
> >>> en, request._LOCALE_: en
> >>> 2017-02-08 22:49:10,897 DEBUG [deformdemo:63][waitress] locale_name from
> >>> default_locale_negotiator: de
> >>> 2017-02-08 22:49:10,897 DEBUG [deformdemo:2080][waitress] locale_name:
> >>> de, request._LOCALE_: de
> >>> 2017-02-08 22:49:12,345 DEBUG [deformdemo:63][waitress] locale_name from
> >>> default_locale_negotiator: nl
> >>> 2017-02-08 22:49:12,345 DEBUG [deformdemo:2080][waitress] locale_name:
> >>> nl, request._LOCALE_: nl
> >>>
> >>> I've uploaded it here: https://github.com/frispete/deformdemo
> >>>
> >>> Could somebody more familiar with the pyramid translation machinery be
> >>> so kind to have a look into this?
> >>>
> >>> Thanks in advance,
> >>> Pete
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "pylons-devel" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> >>> an email to pylons-devel+unsubscr...@googlegroups.com.
> >>> To post to this group, send email to pylons-devel@googlegroups.com.
> >>> Visit this group at https://groups.google.com/group/pylons-devel.
> >>> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.
[pylons-devel] i18n in deformdemo dysfunctional
Hi, 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 default_locale_negotiator: de 2017-02-08 22:49:07,718 DEBUG [deformdemo:2080][waitress] locale_name: de, request._LOCALE_: de 2017-02-08 22:49:09,795 DEBUG [deformdemo:63][waitress] locale_name from default_locale_negotiator: en 2017-02-08 22:49:09,795 DEBUG [deformdemo:2080][waitress] locale_name: en, request._LOCALE_: en 2017-02-08 22:49:10,897 DEBUG [deformdemo:63][waitress] locale_name from default_locale_negotiator: de 2017-02-08 22:49:10,897 DEBUG [deformdemo:2080][waitress] locale_name: de, request._LOCALE_: de 2017-02-08 22:49:12,345 DEBUG [deformdemo:63][waitress] locale_name from default_locale_negotiator: nl 2017-02-08 22:49:12,345 DEBUG [deformdemo:2080][waitress] locale_name: nl, request._LOCALE_: nl I've uploaded it here: https://github.com/frispete/deformdemo Could somebody more familiar with the pyramid translation machinery be so kind to have a look into this? Thanks in advance, Pete -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
Re: [pylons-devel] i18n state of affairs
Hi Michael, 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 to > deform doesn't add it, however deform expects it to in the dev environment > (tests, running i18n.sh, etc). I'm just trying to clarify if you're saying > it would be a new runtime dependency. AFAICS, it's not a runtime dependency, it's needed for i18n work only (as long as the mo files are tarred up).. > > One downside of this move: jinja2 support depends on babel, and needs some > > configuration file support for pot-create, that has to be patched into > > i18n.sh > > > before: > The quick history here, as I know it: > > - Pyramid, etc shipped using babel for everything. > - Babel didn't support py3. > - For that reason and I'm sure many other reasons, Wichert created lingua > and submitted a few PRs to pyramid to start using it in the documentation. Thanks for the intro. Yeah, I know, Armin Ronacher add his Py3 crusade.. > I personally don't know what the state of the art is now that babel > supports py3 I haven't needed to write a fully i18n app myself and so my > knowledge is only limited to diving in and fixing certain bugs or reviewing > PRs. I'm just starting with Pyramid (ahem, websauna) in a project, that essentially needs full i18n support.. Therefor, I try to wrap my head around all these loose ends ATM. Not that easy, because the web is full of misleading information in this regard as well. Since I cannot depend on hearsay, I started with the simplest possible task, having a pyramid-cookiecutter-starter project localized. Since that uses jinja2 templating only, babel is sufficient. Adding deform makes lingua necessary, since babel doesn't support chameleon templates (to my knowledge). lingua depends on babel, when it comes to jinja2 extraction. Oh, well.. Sorry for not having expressed that from the beginning. > I very much appreciate your work on this and would love to see things get > standardized and modernized. I've had several people ask in #pyramid on IRC > why things are not working as our docs kinda sort of tell you to use both > babel and lingua without definitively explaining anything as I think they > were only partially updated when switching to lingua. Maybe, with your insight into Pyramid and my intention to have a properly working i18n in _all_ these packages, we can tidy up that mess a bit. As of now, I don't see the need for babel and lingua as runtime dependencies at all. babel brings in a lot of useful things, that a fully localized app can make use of, but none of that is used in the mentioned packages ATM. lingua is created for message extraction only (with a script called pot-create). I can add a test to i18n to check, if pot-create exists, and bail out with an installation hint otherwise. In order to make the translation infrastructure universally useful, we can: * add the i18n.sh script * ask for installation of babel and lingua, if one is missing * add a lingua.cfg: [extractor:xml] default-engine = tales [extractor:chameleon] default-engine = tales [extensions] .jinja2 = babel-jinja2 .mako = babel-mako Working with translations would boil down to: * create language: ./i18n.sh lang * everything else: ./i18n.sh By default, neither babel nor lingua is a runtime dependency. Cheers, Pete -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
[pylons-devel] i18n state of affairs
Hi, today, I dug into the various packages, that use i18n: deform deformdemo colander and I noticed, that they're missing a unified approach. Some use lingua, some babel, and this results in inconsistent i18n state and handling. I propose to use the current i18n.sh script of lingua for all Pylons packages, similar to https://github.com/Pylons/deform/pull/332 . Why: due to Pyramids range of supported templating systems, lingua is far better suited to fulfill our needs. It's also much easier to remember (and to document) to run a single script, then three of them in order to update translations, not to speak of the unfortunate setup integration.. The nice side of this move: $ ./i18n.sh Extract messages No changes found - not replacing deform/locale/deform.pot Update translations . done. . done. . done. . done. . done. . done. . done. . done. . done. . done. ... done. . done. . done. . done. . done. .. done. . done. . done. Compile message catalogs cs: 19 translated messages, 2 fuzzy translations, 5 untranslated messages. da: 11 translated messages, 1 fuzzy translation, 14 untranslated messages. de: 26 translated messages. el: 24 translated messages, 2 untranslated messages. es: 11 translated messages, 1 fuzzy translation, 14 untranslated messages. fi: 25 translated messages, 1 untranslated message. fr: 19 translated messages, 2 fuzzy translations, 5 untranslated messages. it: 19 translated messages, 2 fuzzy translations, 5 untranslated messages. ja: 25 translated messages, 1 untranslated message. nl: 19 translated messages, 2 fuzzy translations, 5 untranslated messages. pl: 19 translated messages, 2 fuzzy translations, 5 untranslated messages. pt: 19 translated messages, 2 fuzzy translations, 5 untranslated messages. pt_BR: 11 translated messages, 1 fuzzy translation, 14 untranslated messages. ru: 19 translated messages, 2 fuzzy translations, 5 untranslated messages. sv: 18 translated messages, 2 fuzzy translations, 6 untranslated messages. zh: 19 translated messages, 2 fuzzy translations, 5 untranslated messages. zh_CN: 21 translated messages, 1 fuzzy translation, 4 untranslated messages. zh_Hans: 21 translated messages, 1 fuzzy translation, 4 untranslated messages. As a consequence, all these packages will depend on lingua then.. One downside of this move: jinja2 support depends on babel, and needs some configuration file support for pot-create, that has to be patched into i18n.sh before: $ cat lingua.cfg [extractor:xml] default-engine = tales [extractor:chameleon] default-engine = tales [extensions] .jinja2 = babel-jinja2 What do you think? Cheers, Pete -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
Re: invalid http://docs.pylonsproject.org/projects/pyramid/dev/objects.inv
On Montag, 5. August 2013 22:50:52 Hans-Peter Jansen wrote: > Hi, > > on a crusade to provide a full pyramid stack for openSUSE, I stumbled across > an doc generation issue: > > intersphinx tries to download > http://docs.pylonsproject.org/projects/pyramid/dev/objects.inv > which in turn redirects to > http://docs.pylonsproject.org/projects/pyramid/en/latest/ The correct URL is: http://docs.pylonsproject.org/projects/pyramid/en/latest/objects.inv so it looks, like something tried to redirect the call correctly, but failed to keep the file name.. Cheers, Pete -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: some tests fail for pyramid_handlers 0.5
On Montag, 5. August 2013 19:43:16 Michael Merickel wrote: > actually > https://github.com/Pylons/pyramid_handlers/issues Thanks, did that now. Unfortunately, I'm completely overcharged ATM, hence sorry for not providing a patch/pull req.. Cheers, Pete > On Mon, Aug 5, 2013 at 7:19 PM, Steve Piercy wrote: > > On 8/5/13 at 11:57 PM, h...@urpla.net (Hans-Peter Jansen) pronounced: > > > Dear Chris, > > > > > don't know your favorite way to be informed about such issues: > > https://github.com/Pylons/pyramid/issues > > > > Ideally with a pull request that fixes it. :D > > > > Next favored would be here or in IRC. > > > > --steve > > > > > FYI, building on top of a fairly current pyramid stack, two tests of > > > pyramid_handlers fail: > > > > > > [7s] + python setup.py nosetests --with-coverage > > > [7s] running nosetests > > > [7s] running egg_info > > > [7s] writing requirements to pyramid_handlers.egg-info/requires.txt > > > [7s] writing pyramid_handlers.egg-info/PKG-INFO > > > [7s] writing top-level names to > > > > pyramid_handlers.egg-info/top_level.txt > > > > > [7s] writing dependency_links to > > > > pyramid_handlers.egg-info/dependency_links.txt > > > > > [7s] writing entry points to > > > > pyramid_handlers.egg-info/entry_points.txt > > > > > [7s] reading manifest file 'pyramid_handlers.egg-info/SOURCES.txt' > > > [7s] writing manifest file 'pyramid_handlers.egg-info/SOURCES.txt' > > > [7s] running build_ext > > > [7s] E.E. > > > [7s] > > > > == > > > > > [7s] ERROR: test_it (pyramid_handlers.tests.TestHandlerDirective) > > > [7s] > > > > -- > > > > > [7s] Traceback (most recent call last): > > > [7s] File > > > > "/home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.p > > y", line > > > > > 534, in test_it > > > [7s] _execute_actions(actions) > > > [7s] File > > > > "/home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.p > > y", line > > > > > 603, in _execute_actions > > > [7s] action['callable']() > > > [7s] File > > > > "/usr/lib/python2.7/site-packages/pyramid/config/views.py", line > > > > > 1165, in register > > > [7s] order = view_intr['order'] > > > [7s] KeyError: 'order' > > > [7s] > > > [7s] > > > > == > > > > > [7s] ERROR: test_conflict_add_handler > > > > (pyramid_handlers.tests.Test_add_handler) > > > > > [7s] > > > > -- > > > > > [7s] Traceback (most recent call last): > > > [7s] File > > > > "/home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.p > > y", line > > > > > 408, in test_conflict_add_handler > > > [7s] self.assertEqual(c[2], 'test_conflict_add_handler') > > > [7s] IndexError: list index out of range > > > [7s] > > > [7s] Name Stmts Miss Cover Missing > > > [7s] -- > > > [7s] pyramid_handlers 106 0 100% > > > [7s] pyramid_handlers.tests 475 499% 409, 535-538 > > > [7s] pyramid_handlers.zcml 26 0 100% > > > [7s] -- > > > [7s] TOTAL 607 499% > > > [7s] > > > > -- > > > > > [7s] Ran 36 tests in 0.233s > > > [7s] > > > [7s] FAILED (errors=2) > > > > > Full build log is available here: > > https://build.opensuse.org/package/live_build_log/home:frispete:python/pyt > > hon-> > > > pyramid_handlers/openSUSE_12.2/x86_64 > > > > > > It also shows signs of the intersphinx issue reported an h
some tests fail for pyramid_handlers 0.5
Dear Chris, don't know your favorite way to be informed about such issues: FYI, building on top of a fairly current pyramid stack, two tests of pyramid_handlers fail: [7s] + python setup.py nosetests --with-coverage [7s] running nosetests [7s] running egg_info [7s] writing requirements to pyramid_handlers.egg-info/requires.txt [7s] writing pyramid_handlers.egg-info/PKG-INFO [7s] writing top-level names to pyramid_handlers.egg-info/top_level.txt [7s] writing dependency_links to pyramid_handlers.egg-info/dependency_links.txt [7s] writing entry points to pyramid_handlers.egg-info/entry_points.txt [7s] reading manifest file 'pyramid_handlers.egg-info/SOURCES.txt' [7s] writing manifest file 'pyramid_handlers.egg-info/SOURCES.txt' [7s] running build_ext [7s] E.E. [7s] == [7s] ERROR: test_it (pyramid_handlers.tests.TestHandlerDirective) [7s] -- [7s] Traceback (most recent call last): [7s] File "/home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.py", line 534, in test_it [7s] _execute_actions(actions) [7s] File "/home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.py", line 603, in _execute_actions [7s] action['callable']() [7s] File "/usr/lib/python2.7/site-packages/pyramid/config/views.py", line 1165, in register [7s] order = view_intr['order'] [7s] KeyError: 'order' [7s] [7s] == [7s] ERROR: test_conflict_add_handler (pyramid_handlers.tests.Test_add_handler) [7s] -- [7s] Traceback (most recent call last): [7s] File "/home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.py", line 408, in test_conflict_add_handler [7s] self.assertEqual(c[2], 'test_conflict_add_handler') [7s] IndexError: list index out of range [7s] [7s] Name Stmts Miss Cover Missing [7s] -- [7s] pyramid_handlers 106 0 100% [7s] pyramid_handlers.tests 475 499% 409, 535-538 [7s] pyramid_handlers.zcml 26 0 100% [7s] -- [7s] TOTAL 607 499% [7s] -- [7s] Ran 36 tests in 0.233s [7s] [7s] FAILED (errors=2) Full build log is available here: https://build.opensuse.org/package/live_build_log/home:frispete:python/python-pyramid_handlers/openSUSE_12.2/x86_64 It also shows signs of the intersphinx issue reported an hour ago. Cheers, Pete -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
invalid http://docs.pylonsproject.org/projects/pyramid/dev/objects.inv
Hi, on a crusade to provide a full pyramid stack for openSUSE, I stumbled across an doc generation issue: intersphinx tries to download http://docs.pylonsproject.org/projects/pyramid/dev/objects.inv which in turn redirects to http://docs.pylonsproject.org/projects/pyramid/en/latest/ This results in: WARNING: intersphinx inventory 'http://docs.pylonsproject.org/projects/pyramid/dev/objects.inv' not readable due to ValueError: unknown or unsupported inventory version Consequently doc generation, that depends on this part fails later on. It's all public, too: https://readthedocs.org/builds/pyramid_zcml/728948/ https://readthedocs.org/builds/pyramid_xmlrpc/728946/ TBC. Also, this issue seems to persist since half a year at least... Is that to be expected? TIA, Pete -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
