localization support for alternate digits (arabic and south/east asian locales)

[dupuy]

I'm splitting off a new ticket for an issue I raised in #7800 about the use of local-language digit forms in applications. The context in that ticket is Arabic locales, but the issue applies to many other south- and east- asian locales (e.g. Nepali, Khmer, etc.)

I wrote:

While you're editing these translations, I wonder if you should use %Id rather than %d to get Arabic-Indic digits (۰۱۲۳۴۵۶۷۸۹) rather than Latin digits (0123456789). Hmmm...just tried that out, and although C's sprintf (on my Fedora 7 system) uses the Arabic-Indic digits for %Id when the locale is set to "fa_IR" (but not "fa" or "ar"), Python just spits out:

ValueError: unsupported format character 'I' (0x49)

so I guess the answer to this is no. If using Arabic-Indic digits would make the Journal more kid-friendly, you might want to file a separate (low-priority) ticket about this, since it would require extra locale-specific work (for Arabic, Thai, Devanagari, and other languages with their own digits).

Khaled Hosny replied:

%Id isn't supported in python, also Arabic glibc locale definitions lack the needed support (can be fixed though). IIRC some one had a patch for this in python, I'll try to check this.

Yes this is important for children in Egypt and the rest of Arabic world to the east of it, I don't know why I forgot this.

There are several parts to adding support for these digits:

1. patch to python to support %Id format flag for Sugar apps

2. add LC_CTYPE locale support for alternate digit sets for Arabic, Nepali, Khmer, etc. (we might want to have variant locales with and without these, since some users may prefer to always use European digits)

3. changes to localizations in Pootle to use %Id

4. in the case of some applications (e.g. SocialCalc), additional internationalization may be necessary to allow alternate digit forms for both input and output, and possibly user-selection of alternate digit forms at a per-application, per-document, or per-field level (locale switching can be used to enable/disable alternate digits system-wide)

The first two are significant hurdles (and require changes to upstream packages: python, glibc-i18n) but especially for children who have just learned the numbers in their native language, forcing them to learn the European digit systems as well is far from ideal, and Sugar/OLPC should strive to make it easier for them to become numerate.

@alex

[sayamindu]

Initial attempt at getting this in Python

[sayamindu]

It looks like the I flag character is not defined in C99 or POSIX, and is only specific to glibc based machines. I have attached an initial patch (some more work needed to make this robust) for Python 3.x - and can make one for Python 2.x as well, but I'm not very hopeful that upstream will accept it. I'll try though.