Thread: [FE-discuss] German messages

hi,

The messages in validators are english, also there are some locale 
dependet validations(date, zip code etc.)

I do need some of them in german. Whats your way/plans in 
internationalization?

Should I create a german validators_de.py subclassing the classes from 
validators.py?

Are you interested in integrating it in formencode?

--
Greg

Gregor Horvath wrote:
> hi,
> 
> The messages in validators are english, also there are some locale 
> dependet validations(date, zip code etc.)
> 
> I do need some of them in german. Whats your way/plans in 
> internationalization?
> 
> Should I create a german validators_de.py subclassing the classes from 
> validators.py?
> 
> Are you interested in integrating it in formencode?

I don't really know the best way to do internationalization.  But I had 
intended it to be possible in some fashion -- probably with the logic 
somewhere in the formencode.api.Validator.message method.  The locale 
could be passed in attached to the state in some fashion (or in a 
threadlocal global or somesuch), and could translate the message before 
doing the substitutions.  The other part then would be extracting the 
messages so they can be translated.

But I've never done anything with internationalization, so I'm very open 
to advise.  For locale-related validators like date and zip code, I 
think in some cases there should be locale-dependent versions (e.g., for 
postal codes), and in some cases we can add the necessary logic (e.g., 
in the date converter).  Right now there's some configurability to the 
date converter (month_style), but it's limited, and if the locale is 
attached to the state then you could support more than one format at a time.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Ian Bicking schrieb:

> I don't really know the best way to do internationalization.  But I had 
> intended it to be possible in some fashion -- probably with the logic 
> somewhere in the formencode.api.Validator.message method.  The locale 
> could be passed in attached to the state in some fashion (or in a 
> threadlocal global or somesuch), and could translate the message before 
> doing the substitutions.  The other part then would be extracting the 
> messages so they can be translated.

for the messages there is gettext

http://docs.python.org/lib/node333.html

> 
> But I've never done anything with internationalization, so I'm very open 
> to advise.  For locale-related validators like date and zip code, I 
> think in some cases there should be locale-dependent versions (e.g., for 
> postal codes), and in some cases we can add the necessary logic (e.g., 
> in the date converter).  Right now there's some configurability to the 
> date converter (month_style), but it's limited, and if the locale is 
> attached to the state then you could support more than one format at a 
> time.
> 

So the solution would be:

1. Use gettext for the messages (seems that there is only litte change 
to the current code required)

2. locale dependend validation logic with slightly different semantics 
(e.g date) should be included in the current classes of validators.py

3. Local specialities schould be provided by seperate specialized 
classes. (e.g postal codes, telephone numbers, StateProvince)

4. The language, locale setting used should be controlled by an to be 
defined state attribute (1 & 2, 3 is a different class that has to be 
explicitly called by the user). If it is omitted the systems standard 
locale is used. I cannot say where is the best place for that attribute 
because I do not know the code of formencode that much.

If I find the time I´ll start changing validators.py to support gettext 
and create the german message file. OK?

--
Greg

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.

o Remember that you can't use a global translation instance.=20
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.=20
Hence, multiple users can use multiple languages at the same time.

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.

o Consider passing in a translation instance to FormEncode.  You can
use the NullTranslation as the default.

I hope that helps.

-jj

On 10/5/05, Gregor Horvath <g.h...@gm...> wrote:
>
> Ian Bicking schrieb:
>
> > I don't really know the best way to do internationalization.  But I had
> > intended it to be possible in some fashion -- probably with the logic
> > somewhere in the formencode.api.Validator.message method.  The locale
> > could be passed in attached to the state in some fashion (or in a
> > threadlocal global or somesuch), and could translate the message before
> > doing the substitutions.  The other part then would be extracting the
> > messages so they can be translated.
>
> for the messages there is gettext
>
> http://docs.python.org/lib/node333.html
>
> >
> > But I've never done anything with internationalization, so I'm very ope=
n
> > to advise.  For locale-related validators like date and zip code, I
> > think in some cases there should be locale-dependent versions (e.g., fo=
r
> > postal codes), and in some cases we can add the necessary logic (e.g.,
> > in the date converter).  Right now there's some configurability to the
> > date converter (month_style), but it's limited, and if the locale is
> > attached to the state then you could support more than one format at a
> > time.
> >
>
> So the solution would be:
>
> 1. Use gettext for the messages (seems that there is only litte change
> to the current code required)
>
> 2. locale dependend validation logic with slightly different semantics
> (e.g date) should be included in the current classes of validators.py
>
> 3. Local specialities schould be provided by seperate specialized
> classes. (e.g postal codes, telephone numbers, StateProvince)
>
> 4. The language, locale setting used should be controlled by an to be
> defined state attribute (1 & 2, 3 is a different class that has to be
> explicitly called by the user). If it is omitted the systems standard
> locale is used. I cannot say where is the best place for that attribute
> because I do not know the code of formencode that much.
>
> If I find the time I=B4ll start changing validators.py to support gettext
> and create the german message file. OK?

--
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.

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

Would you like to develop this in a branch?  I don't think it should go=20
in the trunk to start out with.  Anyway, I can set you up with commit=20
access; if you generate a line with htpasswd I'll add you.  I won't=20
branch it now, but when you are ready to do work you can branch with:

svn cp http://svn.colorstudy.com/FormEncode/trunk=20
http://svn.colorstudy.com/FormEncode/branches/gettext-enabled

Gregor Horvath wrote:
>=20
> Ian Bicking schrieb:
>=20
>> I don't really know the best way to do internationalization.  But I=20
>> had intended it to be possible in some fashion -- probably with the=20
>> logic somewhere in the formencode.api.Validator.message method.  The=20
>> locale could be passed in attached to the state in some fashion (or in=
=20
>> a threadlocal global or somesuch), and could translate the message=20
>> before doing the substitutions.  The other part then would be=20
>> extracting the messages so they can be translated.
>=20
>=20
> for the messages there is gettext
>=20
> http://docs.python.org/lib/node333.html
>=20
>>
>> But I've never done anything with internationalization, so I'm very=20
>> open to advise.  For locale-related validators like date and zip code,=
=20
>> I think in some cases there should be locale-dependent versions (e.g.,=
=20
>> for postal codes), and in some cases we can add the necessary logic=20
>> (e.g., in the date converter).  Right now there's some configurability=
=20
>> to the date converter (month_style), but it's limited, and if the=20
>> locale is attached to the state then you could support more than one=20
>> format at a time.
>>
>=20
> So the solution would be:
>=20
> 1. Use gettext for the messages (seems that there is only litte change=20
> to the current code required)
>=20
> 2. locale dependend validation logic with slightly different semantics=20
> (e.g date) should be included in the current classes of validators.py
>=20
> 3. Local specialities schould be provided by seperate specialized=20
> classes. (e.g postal codes, telephone numbers, StateProvince)
>=20
> 4. The language, locale setting used should be controlled by an to be=20
> defined state attribute (1 & 2, 3 is a different class that has to be=20
> explicitly called by the user). If it is omitted the systems standard=20
> locale is used. I cannot say where is the best place for that attribute=
=20
> because I do not know the code of formencode that much.
>=20
> If I find the time I=B4ll start changing validators.py to support gette=
xt=20
> and create the german message file. OK?
>=20
> --=20
> Greg


--=20
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org