as a side note, I'm trying to figure out what will be the best way to
create the labels for fields in spanish for example I got this widget
descripcion = TextArea(...)
in code i don't want the accent but in the label I want.
descripción
I got two possible solutions
one will be to monkey patch
tw.forms-0.8-py2.5.egg/toscawidgets/widgets/forms/fields.py ´s
name2label funcion. adding a dict of terms to replace.
another will be just to set them manually for each widget.
I was wondering if by some way it could be possible to provide
spelling "correction" how crazy is that?
TW uses the frameworks translator function for i18n so as long it is
passed when initializing the HostFramework it will use it to translate
lazystrings and pass it to FE when validating. The wireup is alerady done
for you if using Pylons/TG2 or TG1.
Example:
from tw.api import lazystring as _
class MyFields(WidgetsList):
name = TextFields(label_text=_("Name"))
....
FE doesn't need error messages to be wrapped with lazystring since it
passes all messages through a translator function if it is bound to the
state parameter to_python accepts. tw.forms takes care of setting it
before validation. However, for custom validators you need to wrap
translatable strings with a _ function so i18n tools such as gettext,
Babel or TG's i18n subsystem can collect them from the sources.
A noop function works fine:
_ = lambda s: s
class MyValidator(..):
messages = {
'foo': _("Fooo!"),
}
(IIRC FE doesn't like _ to be lazystring so use a noop)
Now you need to collect all translatable strings (including the ones in
FormEncode's sources) into a catalog, I'm using Babel for this and works
great. To collect FE's messages I include the path where a FE checkout
lives in setup.py:
message_extractors = {
'myapp' : [
('**.py', 'python', None),
('**.js', 'javascript', None),
('**.html', 'genshi', None),
],
'thirdparty/FormEncode/formencode' : [
('**.py', 'python', None),
],
},
Please consult TG's or Pylons' docs on how to configure it to use the
catalog you've just created.
> as a side note, I'm trying to figure out what will be the best way to
> create the labels for fields in spanish for example I got this widget
> descripcion = TextArea(...)
Use the label_text parameter, name2label is just there to try to provide a
sane default for fields which haven't got a label_text declared, I see no
need to make it fancier than it is right now.
Alberto
on a related note this patch seems to fix the overwriting of default
message http://pylonshq.com/project/pylonshq/ticket/296
>
> Now you need to collect all translatable strings (including the ones in
> FormEncode's sources) into a catalog, I'm using Babel for this and works
> great. To collect FE's messages I include the path where a FE checkout
> lives in setup.py:
>
> message_extractors = {
> 'myapp' : [
> ('**.py', 'python', None),
> ('**.js', 'javascript', None),
> ('**.html', 'genshi', None),
> ],
> 'thirdparty/FormEncode/formencode' : [
> ('**.py', 'python', None),
> ],
> },
now this totally got me out of place, why will I need to re-create
translations for formencode if it already provides proper
translations?
>
> Please consult TG's or Pylons' docs on how to configure it to use the
> catalog you've just created.
this is what lost me, according to formencode docs and tw code just
setting the correct lang should show the formencode error messages in
the locate assuming FE is translated of course.
>
>
> I have traced the steps and I'm
> not exactly sure what is happening in mods/pylonshf.py:125 (on
> tw0.8.4) but it seems the state method is being pass into formencode
> as it suggests.
>
> on a related note this patch seems to fix the overwriting of default
> message http://pylonshq.com/project/pylonshq/ticket/296
>
>
>> Now you need to collect all translatable strings (including the ones in
>> FormEncode's sources) into a catalog, I'm using Babel for this and works
>> great. To collect FE's messages I include the path where a FE checkout
>> lives in setup.py:
>>
>> message_extractors = {
>> 'myapp' : [
>> ('**.py', 'python', None),
>> ('**.js', 'javascript', None),
>> ('**.html', 'genshi', None),
>> ],
>> 'thirdparty/FormEncode/formencode' : [
>> ('**.py', 'python', None),
>> ],
>> },
>>
>
> now this totally got me out of place, why will I need to re-create
> translations for formencode if it already provides proper
> translations?
>
You need to have FE's translations in the catalog Pylons' translator
uses, which is the one living in yourapp/i18n/... unless you do
something like the patch you mentioned which first tries to use the
catalog in your app and if it fails then the one in FE. Both solutions
are equally unclean to my eye... :). Ideally there should be a way to
create a big catalog from all the small catalogs external eggs provide
and use that but I haven't seen such a thing yet.
>
>> Please consult TG's or Pylons' docs on how to configure it to use the
>> catalog you've just created.
>>
> this is what lost me, according to formencode docs and tw code just
> setting the correct lang should show the formencode error messages in
> the locate assuming FE is translated of course.
>
... as long as the translator being used has the translations in its
catalog... Take look here [2], this is where pylons configures its
translator with the catalog inside the i18n dir *only*, not the ones
inside the FE package.
[1]
http://pylonshq.com/project/pylonshq/browser/pylons/i18n/translation.py#L170
[2]
http://pylonshq.com/project/pylonshq/browser/pylons/i18n/translation.py#L156
On Wed, May 7, 2008 at 2:34 AM, Alberto Valverde <alb...@toscat.net> wrote:
>
> Jorge Vargas wrote:
> > On Thu, Apr 24, 2008 at 2:58 AM, Alberto Valverde <alb...@toscat.net> wrote:
> >
> >> > I remember a long time ago there was some work done to TGWidgets and
> >> > the formencode package to allow i18n'ing their message, i was
> >> > wondering if any of this was ported to TW. if it wasn't I'll like some
> >> > pointers as to how should I procede so I work on some some patches to
> >> > get it working.
> >>
> >> TW uses the frameworks translator function for i18n so as long it is
> >> passed when initializing the HostFramework it will use it to translate
> >> lazystrings and pass it to FE when validating. The wireup is alerady done
> >> for you if using Pylons/TG2 or TG1.
> >>
> >>
> > I was looking at this code and it seems to be broken somehow. in class
> > PylonsHostFramework the translator is set to pylons.translator which
> > is ok. but when I set lang = es in my development.ini I'm still
> > getting the english error messages.
> You need to call pylons.i18n.set_lang [1] in every request, usually in
> the __before__ or __call__ methods, to choose the correct language for
> that request.
>
actually this isn't needed, if you set lang = es in app:main. the only
moment where you will want to use the __before__ or __call__ hook is
when you are changing the localization in runtime, for example from
browser preferences or a cookie.
ok I have been trying to work on a hybrid solution. I added this to my
middleware TW config.
app = make_middleware(app,{
'toscawidgets.middleware.inject_resources':True,
'toscawidgets.framework':'pylons',
'toscawidgets.framework.default_view':'mako',
'toscawidgets.framework.translator':pylons_formencode_gettext,
})
and the above is the function from the patch.
this will make TW @validate behave like the patch for pylons, if you
look inside FE's _stdtrans you will see that it's setting the domain
to "FormEncode" and loading the locale data that comes with FE.
(functions get_localedir and set_stdtranslation in api.py on
formencode.
now even though that's supposed to be working as expected I'm still
getting english messages from FE's validators.
> Both solutions
> are equally unclean to my eye... :). Ideally there should be a way to
> create a big catalog from all the small catalogs external eggs provide
> and use that but I haven't seen such a thing yet.
>
the only clean way I can think of this is to implement a babel plugin
that will extract messages from installed eggs.
On May 12, 11:17 pm, "Jorge Vargas" <jorge.var...@gmail.com> wrote:
> I took a stab at this today again.
>
>
>
> On Wed, May 7, 2008 at 2:34 AM, Alberto Valverde <albe...@toscat.net> wrote:
>
> > Jorge Vargas wrote:
> > > messagehttp://pylonshq.com/project/pylonshq/ticket/296
Jorge,
The problem with FE's set_stdtranslation is that it gets called at
module import time with languages=None and sets
formencode.api._stdtrans to a gettext.NullTranslations instance.
If you don't use request language, try manually calling
set_stdtranslation with proper 'languages' argument during your app's
initialization.
However, since _stdtrans is module global, I don't see any way of
changing it in a thread-safe manner, and it is used every time
validate() doesn't get a translator function from its state argument.
> > Both solutions
> > are equally unclean to my eye... :). Ideally there should be a way to
> > create a big catalog from all the small catalogs external eggs provide
> > and use that but I haven't seen such a thing yet.
>
> the only clean way I can think of this is to implement a babel plugin
> that will extract messages from installed eggs.
>
> > >> Please consult TG's or Pylons' docs on how to configure it to use the
> > >> catalog you've just created.
>
> > > this is what lost me, according to formencode docs and tw code just
> > > setting the correct lang should show the formencode error messages in
> > > the locate assuming FE is translated of course.
>
> > ... as long as the translator being used has the translations in its
> > catalog... Take look here [2], this is where pylons configures its
> > translator with the catalog inside the i18n dir *only*, not the ones
> > inside the FE package.
>
> > [1]
> > http://pylonshq.com/project/pylonshq/browser/pylons/i18n/translation....
> > [2]
> > http://pylonshq.com/project/pylonshq/browser/pylons/i18n/translation....
>
>