#2385 closed defect (fixed)
Turtle Art should respect locale when rendering decimal point
Reported by: | walter | Owned by: | walter |
---|---|---|---|
Priority: | Unspecified by Maintainer | Milestone: | Unspecified |
Component: | Turtleart | Version: | Unspecified |
Severity: | Unspecified | Keywords: | |
Cc: | erikos | Distribution/OS: | Unspecified |
Bug Status: | Unconfirmed |
Description
Feedback from Erikos:
a) '.' versus ',' for floating point numbers
In TA you can only use the dot to specify a floating point number. In
languages like German and Spanish floating point numbers are specified
with a ','. I think we should either make it locale dependent (can be
seen in the output of Calculate), or we just allow to use '.' and ','
(the latter might have some side effects though).
Attachments (1)
Change History (12)
comment:1 Changed 13 years ago by walter
- Cc erikos added
comment:2 Changed 13 years ago by erikos
I tested your bundle 99 on 0.84. I could not type the ',' in an number entry field. Tested with german locale. Nothing in the logs.
comment:3 Changed 13 years ago by walter
locale.localecon() was not returning the proper info. In this patch (http://git.sugarlabs.org/projects/turtleart/repos/mainline/commits/dce9973befba3e9c5f44c2b92521c45162fca870) I set the locale based on $LANG and it seems to behave as expected. (Only tested in jhbuild so far.)
comment:4 Changed 13 years ago by erikos
I did the following to reproduce the issue.
[erikos@pennylane ~]$ python
Python 2.6.4 (r264:75706, Jun 4 2010, 18:20:16)
[GCC 4.4.4 20100503 (Red Hat 4.4.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import locale
locale.getdefaultlocale()
('de_DE', 'UTF8')
locale.localeconv()decimal_point?
'.'
import os
os.environLANG?
'de_DE.utf8'
lang = os.environLANG?
locale.setlocale(locale.LC_NUMERIC, lang)
'de_DE.utf8'
locale.localeconv()decimal_point?
','
locale.getdefaultlocale()
('de_DE', 'UTF8')
I think we should find out what happens. Then we can come up with the right patch. We do not have to rush here.
comment:5 follow-up: ↓ 6 Changed 13 years ago by erikos
I did the following to reproduce the issue.
[erikos@pennylane ~]$ python Python 2.6.4 (r264:75706, Jun 4 2010, 18:20:16) [GCC 4.4.4 20100503 (Red Hat 4.4.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> >>> locale.getdefaultlocale() ('de_DE', 'UTF8') >>> locale.localeconv()['decimal_point'] '.' >>> import os >>> os.environ['LANG'] 'de_DE.utf8' >>> lang = os.environ['LANG'] >>> locale.setlocale(locale.LC_NUMERIC, lang) 'de_DE.utf8' >>> locale.localeconv()['decimal_point'] ',' >>> locale.getdefaultlocale() ('de_DE', 'UTF8')
I think we should find out what happens. Then we can come up with the right patch. We do not have to rush here.
comment:6 in reply to: ↑ 5 Changed 13 years ago by sascha_silbe
Replying to erikos:
[erikos@pennylane ~]$ python
Python 2.6.4 (r264:75706, Jun 4 2010, 18:20:16)
[GCC 4.4.4 20100503 (Red Hat 4.4.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale}}}
>>> locale.getdefaultlocale()
('de_DE', 'UTF8')
>>> locale.localeconv()['decimal_point']
'.'
This works as designed (by POSIX): all programs start in the C locale and need to call setlocale() first for any locale environment variable to take effect.
The recommended way to do that is to set LC_ALL to the empty string:
locale.setlocale(locale.LC_ALL, '')
I would expect sugar.activity.main to do that for all activities that use our framework.
comment:7 Changed 13 years ago by walter
Interesting. I'll try it and report back. Thanks. (I agree, it should be built into the framework.)
comment:8 Changed 13 years ago by walter
- seeta_dev set to unassigned
comment:9 Changed 13 years ago by walter
- Resolution set to fixed
- Status changed from new to closed
comment:10 Changed 13 years ago by erikos
Walter, can we open a general ticket to not forget about the general task, that all activities have that support? Is there a ticket already?
comment:11 Changed 13 years ago by walter
See #2433
I think the attached version 99 does this correctly. Please test.