adding quechua and aymara to language extension

[walter]

Since quz and aym are not in glibc, we need to add them as exceptions to the list used by the language extension. In parallel, we need to continue to press the case upstream for their inclusion. The attached patch is for adding them to model.py

[cjl]

Please note that AC may have a similar patch for Dextrose already from their Peru work. I had previously recommended against landing special-case quz/aym support patches in Sugar (hoping to land glibc locales first), but perhaps that advice should be revisited.

[alsroot]

I'm not sure what was the purpose for adding hardcoded locales to shell's code.

Adding locales not supported by system (locale -a doesn't mention aym and quz) and afterward witching to this locale from CP, breaks shell's start in my env. From another side, if system supports new locales, it will appear in CP anyway.

[alsroot]

Replying to alsroot:

I'm not sure what was the purpose for adding hardcoded locales to shell's code.

Adding locales not supported by system (locale -a doesn't mention aym and quz) and afterward witching to this locale from CP, breaks shell's start in my env. From another side, if system supports new locales, it will appear in CP anyway.

Sorry, the code that prevented shell start is a side code that runs locale.setlocale(locale.LC_ALL, '') (as ​http://docs.python.org/library/locale.html suggests). After removing this code, shell starts well and gettext seems to work. But the issue still remains if any activity will run locale.setlocale(locale.LC_ALL, ''). And generally, the system is in inconsistent state since locale setting is broke.

[walter]

I guess the question is, how do we enable languages where we have translations (and users) but not yet upstream support in glibc? FWIW, we've had patches for Dari in Pashto in model.py for quite some time. Have those patches led to broken locale settings? If so, should they be removed?

[alsroot]

In my mind, adding locales that are not yet glibc streamed is more a task for downstreams (sugar distributors) rather than for shell upstream code. Obviously, if people are working on translations for new languages, they will take care about adding new locales on OS level.

For another hardcoded locales: ht_HT exists starting, at least, from f11; ps_AF from f14; fa_AF is not glibc upstreamed. Not sure how missed locales are being used in the field right now, but it will be a good idea at least avoid adding new hardcoded locales.

[walter]

As CJL has mentioned, he has been trying to get the new locales accepted upstream. But in the meantime, we have real users with real language needs. I presume that OLPC and/or AC and/or a local deployment will make a build for Quechua in the coming months for deployment in Peru. How will that work without the proposed patch?

[walter]

I reread your message more closely. You are suggesting we patch the glibc locales locally instead? That makes sense.

[alsroot]

Replying to walter:

I presume that OLPC and/or AC and/or a local deployment will make a build for Quechua in the coming months for deployment in Peru. How will that work without the proposed patch?

In the regular way, i.e., local distributor adds new locales on glibc level and they appear in language combobox in CP as regular locales.

For debian based system, the task is pretty simple: adding new /usr/share/i18n/locales files, tweak /etc/locale.gen, run locale-gen script. For fedora it is more tricky, either providing patched glibc package (like Dextrose does) or prepare a side package with prebuilt locales (how SD does, ​https://packages.sugarlabs.org/package/files?package=locales&

[alsroot]

Replying to alsroot:

Replying to walter:

I presume that OLPC and/or AC and/or a local deployment will make a build for Quechua in the coming months for deployment in Peru. How will that work without the proposed patch?

In the regular way, i.e., local distributor adds new locales on glibc level and they appear in language combobox in CP as regular locales.

For debian based system, the task is pretty simple: adding new /usr/share/i18n/locales files, tweak /etc/locale.gen, run locale-gen script. For fedora it is more tricky, either providing patched glibc package (like Dextrose does) or prepare a side package with prebuilt locales (how SD does, ​https://packages.sugarlabs.org/package/files?package=locales&

​https://packages.sugarlabs.org/package/files?package=locales&project=SweetsDistribution

[dnarvaez]

I agree with alsroot.

[cjl]

Aymara locale ayc_PE has been upstreamed. Quechua needs a little more work, but can be upstreamed soon, hopefully. At this point, I think tweaks like this can get done in OOB and not in the Sugar base code.