Re: [pylons-devel] i18n state of affairs

2017-02-09 Thread Michael Merickel 
On Thu, Feb 9, 2017 at 6:02 AM, Hans-Peter Jansen  wrote:

> 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?
>

I don't see any problem with this. It sounds great. A few requests below
(not requirements, just my picture of what the i18n story would ideally
turn into as we move forward).

1) Update the pyramid documentation to explain what's going on and how
things fit together, including an example i18n.sh or i18n.py.

2) Try to support windows as much as possible and so i18n.py might be worth
considering instead, along with an attempt to explain what is necessary to
get things to work on windows.

3) I'd like things to work for arbitrary projects and not just colander and
deform. It'd be great if they served as best practice examples.

- Michael

-- 
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 - solved!

2017-02-09 Thread Hans-Peter Jansen 
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

2017-02-09 Thread Hans-Peter Jansen 
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

2017-02-09 Thread Hans-Peter Jansen 
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.