Opened 8 years ago

Closed 7 years ago

Last modified 6 years ago

#3692 closed enhancement (wontfix)

adding quechua and aymara to language extension

Reported by: walter Owned by: erikos
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: Git as of bugdate
Severity: Unspecified Keywords:
Cc: cjl, alsroot Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

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

Attachments (1)

0001-Add-quechua-and-aymara-since-they-are-not-in-glibc.patch (964 bytes) - added by walter 8 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 8 years ago by cjl

  • Cc alsroot added

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.

comment:2 follow-up: Changed 8 years ago by 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.

comment:3 in reply to: ↑ 2 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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?

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by 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?

comment:7 Changed 8 years ago by walter

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

comment:8 follow-up: Changed 8 years ago by 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&

comment:9 in reply to: ↑ 8 Changed 8 years ago by 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=sweets-locales&project=SweetsDistribution

Last edited 6 years ago by alsroot (previous) (diff)

comment:10 Changed 7 years ago by dnarvaez

  • Resolution set to wontfix
  • Status changed from new to closed

I agree with alsroot.

comment:11 Changed 7 years ago by 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.

Note: See TracTickets for help on using tickets.