On Thu, Feb 9, 2017 at 6:02 AM, Hans-Peter Jansen <h...@urpla.net> 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.

Reply via email to