On Jan 1, 2011, at 2:30 AM, Martin Weissenboeck wrote: > > > 2010/12/31 Jonathan Lundell <jlund...@pobox.com> > On Dec 31, 2010, at 11:20 AM, Martin Weissenboeck wrote: >> No, I did not not want to translate these sentences manually. >> The error_message=T(..) does not work, because there are some if-statements >> inside the class IS_INT_IN_RANGE (and in some other classes). >> >> One solution could be a list of error messages for these classes. > > You don't need a list, because for any given instance, only one of the error > messages is used, depending on which combination of min & max you set. > > But if you have five different instances of IS_INT_IN_RANGE you have to write > five different error_messages. And you have to do it for each new website > again. > > Regards, Martin >
I'm not arguing that it's ideal, just that there's a working solution. Here's the way I think it should work. * T(), or a similar variant, should work in gluon. * The translation string finder should look in gluon as well as the application. * But the translations become part of the application (that is, there's no central gluon languages directory). Alternatively, we could treat gluon translations specially, so that the translator would look first in app/languages, and if the string isn't found, check gluon/languages, so we could build up a translation database for gluon but it could be overridden. A consequence of this would be that a developer would have to re-check translation strings when upgrading web2py, since the strings would be subject to change. A second consequence is that you'd see *all* the gluon T strings, not just the ones your application used. That's an advantage for the current scheme of passing your own T string to the validator: you'll have a much smaller set of strings to translate.
