[Grok-dev] grok.i18n reloaded

[Uli Fouquet]

Hi there,

regarding to Philipps last posting about i18n in Grok, I examined that
topic a bit closer and came to the following problems/suggestions:

There might be a consensus, that i18n-support for Grok in general would
be fine. IMHO this should include (1) autogenerated i18nextract script,
(2) Python-based i18n-configuration possibilities (directives, classes),
(3) documentation.

It should, from my point of view, provide as little boilerplate stuff as
possible. If someone does not want to support i18n for his/her
component/application this should be respected and as i18n is basically
an 'add-on', such stuff might be disturbing and confusing especially for
beginners with Grok.

If, however, someone explicitly wants i18n, we should provide some
helpers.

lovely.recipe or zope.app.locales
---------------------------------

The first of the three topics mentioned above might come down to the
question lovely.recipe or zope.app.locales. It is a question related to
grokproject only. 

While I agree, that using entry points in zope.app.locales is the
technical cleaner way to go, lovely.recipe has the advantage to provide
i18nextract out of the box with the already released version. The latter
is not true for zope.app.locales (please correct me, if I am wrong).

Using lovely.recipe for the time being, therefore would mean less hassle
with buildout configurations. This is the reason, why I would prefer it
currently. We could quickly support i18nextract generation.

Furthermore there would be no harm done to existing projects, because
the kind of script generation could be changed later on without breaking
existing projects (again, I might be wrong here).

Anyway, I would love to have some i18nextract support for grokproject.
Please tell, if I can do something to let things happen-

BTW: I have no problem with 'suddenly appearing' locales directories
when I explicitly run a script. Contrary this is, what I expect a script
to do: create, modify and/or delete files and directories. It is not
magic from my point of view. At least less magical than bin/buildout ;-)


Python-based i18n-configuration
-------------------------------

To provide helpers for people who want i18n for their apps/components, I
only found the ZCML-directive i18n:registerTranslations to be
considerable. It is the only ZCML directive (I found) you certainly want
to use when i18ning an app and that could also be declared in Python.

Other ZCML-stuff like i18n:domain is related to other ZCML
configurations and it sounds weird to me, to do such things in Python.

For registerTranslations I just implemented (with input from Philipp,
many thanks!) an

	grok.i18n.registerTranslations(directoryname)

directive, which registers directories with translations pretty the same
way, the according ZCML directive does.

The repository location is:

        http://svn.zope.org/grok/branches/ulif-i18n

A review would be appreciated.

I am not sure, whether this directive really makes sense, as it does not
tackle any DRY violation. It only helps to keep your project 'ZCML-free'
and makes it possible to notate translation directory locations and code
that uses translations in the same file.

Included with the above implementation is a GlobalGrokker, that
registers a translation directory with every module grokked. If none is
given (using the above directive), 'locales' is assumed as default and
if no such directory exists (or does not contain translations, i.e.
appropriate .mo-files), silently no registration happens.

This means, that you do not have to give a translations directory at
all, but can simply generate translations in a local 'locales' dir and
the translations will be registered automatically at startup, pretty
much like static dir (but with the possibility to change the default).

Therefore 'grok.localesdir', as Philipp suggested, might be a better
name for this directive.


I18n documentation
------------------

There is a lot of i18n documentation already out there in the wild, but
we might want to have a specialized tutorial/trail for Grok-related
i18n, when there come special directives like the one above and similar
with Grok.

Regarding i18n-related boilerplates: I currently see no need for it. The
above directive does not complain about missing locales-dirs, except you
explicitly declared one, so even an autogenerated 'locales' dir is not
neccessary.

What do you think?

Kind regards,

-- 
Uli