Opened 14 years ago
Last modified 9 years ago
#1649 new enhancement
calculate support for arabic numbers
Reported by: | javedkhan | Owned by: | garycmartin |
---|---|---|---|
Priority: | Unspecified by Maintainer | Milestone: | Unspecified |
Component: | Calculate | Version: | Unspecified |
Severity: | Unspecified | Keywords: | patch |
Cc: | cjl | Distribution/OS: | OLPC |
Bug Status: | Unconfirmed |
Description
Creating support for Arabic numbers۰۱۲۳۴۵۶۷۸۹(for Pashto and Dari) in the interface and the entered text in Calculate Activity.
Change History (6)
comment:1 Changed 14 years ago by cjl
- Component changed from sugar to Calculate
comment:2 Changed 13 years ago by garycmartin
- Type changed from defect to enhancement
comment:3 Changed 12 years ago by cjl
comment:4 Changed 12 years ago by cjl
- Cc cjl added
comment:5 Changed 9 years ago by godiard
comment:6 Changed 9 years ago by godiard
- Keywords patch added
Note: See
TracTickets for help on using
tickets.
I beleive gettext can help with this by using %Id in place of %d when translating the UI strings into Arabic. I'm not sure how much work is needed on the backend.
http://www.gnu.org/software/gettext/manual/gettext.html#c_002dformat
"As a special feature for Farsi (Persian) and maybe Arabic, translators can insert an ‘I’ flag into numeric format directives. For example, the translation of "%d" can be "%Id". The effect of this flag, on systems with GNU libc, is that in the output, the ASCII digits are replaced with the ‘outdigits’ defined in the LC_CTYPE locale category. On other systems, the gettext function removes this flag, so that it has no effect.
Note that the programmer should not put this flag into the untranslated string. (Putting the ‘I’ format directive flag into an msgid string would lead to undefined behaviour on platforms without glibc when NLS is disabled.)"