[web2py] Re: Localising decimal values in form fields
Hi, I'm getting same error (gluaon/validators.py, line 807), version 1.97.1. Debugger says this.dot is type lazyT, so I made a test and added str(). Line now looks: def formatter(self, value): return str(value).replace('.',str(self.dot)) also line 793 try: if isinstance(value,decimal.Decimal): v = value else: v = decimal.Decimal(str(value).replace(str(self.dot),'.')) and it seems to work, but I'm new to Python and not sure it is correct. Sorry for my english Jano On 30. Jún, 11:19 h., tomtom5 wrote: > Thanks for this hint, but that doesn't seem to work. > If I apply this to the field in either model or controller, i get > following error: > > File "gluon/sqlhtml.py", line 782, in __init__ > File "gluon/dal.py", line 5247, in formatter > File "gluon/validators.py", line 807, in formatter > TypeError: expected a character buffer object > > If I use fixed value (eg .. requires=IS_DECIMAL_IN_RANGE(dot=",") ...) > the conversion seems to work. > > On 29 Jun., 17:46, Massimo Di Pierro > wrote: > > > > > > > > > IS_DECIMAL_IN_RANGE and IS_FLOAT take a an attribute called dot="." > > which you can internationalize > > > IS_DECIMAL_IN_RANGE(dot=T(".")) > > > On Jun 29, 5:39 am, tomtom5 wrote: > > > > I'm currently diving into web2py and got a problemlocalisinginput/ > > > output ofDecimal/Doubleformfields according to the users (browsers) > > > locale. I understand the mechanism of internationalising messages with > > > T(..), but that doesn't seem to help me further. What I need is, that > > > for example a german user may input adecimalvalue as 123.456,78 > > > while an american user will use 123 456.78 as input/output format. I > > > found methods to define thedecimalseparator char in the constructor > > > of the IS_DECIMAL_IN_RANGE validator, but this is very rudimentary and > > > will not be user-locale aware. Is there a way to solve the problem out > > > of the box or should I create new validators or widgets for such a > > > task? > > > Thanks for advise
[web2py] Re: Localising decimal values in form fields
Thanks for this hint, but that doesn't seem to work. If I apply this to the field in either model or controller, i get following error: File "gluon/sqlhtml.py", line 782, in __init__ File "gluon/dal.py", line 5247, in formatter File "gluon/validators.py", line 807, in formatter TypeError: expected a character buffer object If I use fixed value (eg .. requires=IS_DECIMAL_IN_RANGE(dot=",") ...) the conversion seems to work. On 29 Jun., 17:46, Massimo Di Pierro wrote: > IS_DECIMAL_IN_RANGE and IS_FLOAT take a an attribute called dot="." > which you can internationalize > > IS_DECIMAL_IN_RANGE(dot=T(".")) > > On Jun 29, 5:39 am, tomtom5 wrote: > > > > > > > > > I'm currently diving into web2py and got a problem localising input/ > > output ofDecimal/Doubleformfields according to the users (browsers) > > locale. I understand the mechanism of internationalising messages with > > T(..), but that doesn't seem to help me further. What I need is, that > > for example a german user may input adecimalvalue as 123.456,78 > > while an american user will use 123 456.78 as input/output format. I > > found methods to define thedecimalseparator char in the constructor > > of the IS_DECIMAL_IN_RANGE validator, but this is very rudimentary and > > will not be user-locale aware. Is there a way to solve the problem out > > of the box or should I create new validators or widgets for such a > > task? > > Thanks for advise
[web2py] Re: Localising decimal values in form fields
IS_DECIMAL_IN_RANGE and IS_FLOAT take a an attribute called dot="." which you can internationalize IS_DECIMAL_IN_RANGE(dot=T(".")) On Jun 29, 5:39 am, tomtom5 wrote: > I'm currently diving into web2py and got a problem localising input/ > output of Decimal/Double form fields according to the users (browsers) > locale. I understand the mechanism of internationalising messages with > T(..), but that doesn't seem to help me further. What I need is, that > for example a german user may input a decimal value as 123.456,78 > while an american user will use 123 456.78 as input/output format. I > found methods to define the decimal separator char in the constructor > of the IS_DECIMAL_IN_RANGE validator, but this is very rudimentary and > will not be user-locale aware. Is there a way to solve the problem out > of the box or should I create new validators or widgets for such a > task? > Thanks for advise