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.
