[ckan-dev] validation library and deform.

[David Raznick]

On Sun, Apr 3, 2011 at 9:42 PM, Friedrich Lindenberg <
friedrich.lindenberg at okfn.org> wrote:

> Hi David,
>
> On Sun, Apr 3, 2011 at 1:01 PM, David Raznick <kindly at gmail.com> wrote:
> > Thanks for the feedback and just the person I wanted to ask something of.
> > I am looking into i18n stuff at the moment.
> > I was hoping to use some built in validators however Colander only has
> these
> > translations.
> >  https://github.com/Pylons/colander/tree/master/colander/locale
> > I also can't find a way to pass custom messages or custom "translators"
> to
> > colander.  This worries me as the built in "SchemaNodes" have types (int,
> > string) and if these types throw an "Invalid" it can only throw them in
> > the languages supported.  This means we will have to effectively subclass
> > all of colanders "SchemaTypes" and rewrite parts of them.
>
> I'm not sure this is true. My guess is that translationstring would
> check out the kind of well-known locations for l10ns that gettext
> should use (locale/, LC_MESSAGES/, ...). What speaks against
> submitting more translations to colander as we go?


We could do that.  But we do not know who is going to be using ckan, so our
users will have to do that.  We could also give translations to formencode
as we go.


> Passing in custom
> translators means having to provide validation error messages in the
> CKAN namespace and I'd really like to avoid that.
>

I agree with that entirely.  That is why I think formencodes domain is the
best one as it got the most extensive set of validators/languages already.


>
> Looking at translationstring this seems to solve a problem I've had
> with WDMMG where I wanted i18n to run in different domains from the
> actual "wdmmg" core (i.e. wdmmgext.bergen). This is particularly
> interesting once you start having plugins that provide their own
> Genshi templates which need to access another domain. Basically, I
> ended up writing my own translationstring library at
>
> https://bitbucket.org/okfn/wdmmg/src/6603ba8fc04e/wdmmg/config/environment.py#cl-18
> .
>

Formencode lets you transfer to using its domain really easily.


> > The only library that does this well is formencode (mainly as it by far
> the
> > most mature).  It has
> >  https://bitbucket.org/ianb/formencode/src/703c27be52b8/formencode/i18n/
>  translations.
> >  Each translation is much more thorough too as formencode has lots of
> > validators.   My library can easily reuse formencode validators for this
> > purpose.  You can also pass on your own translator (_, ugettext) if you
> > like.
>
> Would this run in its own domain or in CKANs? If you want to separate
> domains you necessarily end up with something like my WDMMG hack or
> translationstring, I think.


I have got everything to run through formencodes domain. Apart from our own
special custom validation errors (which we have made already), which can run
on ours.

It seems a shame not to use the most mature sets of validators/translations.
 Its possible to use formencode validators in colander e.g
http://cd34.com/blog/framework/using-formencode-for-validation-with-colander-and-deform/
.
  However you need to write a wrapper for each.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110403/88c43c75/attachment-0001.html>