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, tha
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
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
defa
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'
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
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 scri
