|
From: Ian B. <ia...@co...> - 2005-10-05 17:09:48
|
Shannon -jj Behrens wrote:
> I had to support this in FormValid, Aquarium's form validation library
> (long story). Here are some things to keep in mind when doing this in
> FormEncode:
>
> o It's helpful to let the programmers easily pass in their own error
> messages. That way they're in complete control of these sticky
> situations.
This is already handled, e.g., DateConverter(messages={'after': "I find
it implausible you are more than 100 years old"},
earliest_date=datetime(1905, 1, 1)).
> o Remember that you can't use a global translation instance.
> Eventually, you'll need to support more than one language at the same
> time. In Aquarium, I handled this by attaching the translation
> instance to the context. Each page request has its own context.
> Hence, multiple users can use multiple languages at the same time.
You could use a threadlocal object to manage the locale, assuming a
single request is handled solely by one locale, i.e., a single thread
uses only one locale at a time. Unless you are using single-process
non-threaded serving like Nevow or somesuch.
But anyway, the state object can be passed into a validation, and
arbitrary attributes can be attached to it. So I'm guessing the locale
should be determined with:
locale = getattr(state, 'locale', None)
> o I personally would not want the FormEncode strings to have their own
> separate gettext domain. Rather, I would scan FormEncode for
> translatable strings (using gettext, of course) and translate those
> alongside all my other application's strings.
Well, that's terminology I don't understand ;) Does scanning produce
.po files? Can those be merged and extracted?
Eh, I don't know much about this stuff at all.
> o Consider passing in a translation instance to FormEncode. You can
> use the NullTranslation as the default.
If that's more convenient, then it could be done with:
translator = getattr(state, 'translator', NullTranslation)
--
Ian Bicking / ia...@co... / http://blog.ianbicking.org
|