tweak ALL_LINGUAS line of configure.ac

[cjl]

Current ALL_LINGUAS line

​http://git.sugarlabs.org/sugar/mainline/blobs/master/configure.ac#line21

ALL_LINGUAS="af am ar aym bg bi bn_IN bn ca cs da de dz el en es fa_AF fa ff fil fr gu ha he hi ht hu id ig is it ja km ko kos mg mi mk ml mn mr ms mvo nb ne nl pa pap pl ps pt_BR pt quz ro ru rw sd si sk sl sq sv sw ta te th tr tvl tzo ug ur vi wa yo zh_CN zh_TW"

1) Change aym to ayc - decision made with localizers, reflected in upstreamed glibc locale for ayc_PE

• (note ayc_PE recently added to glibc 2.17 check glibc package version).

2) Add langs to ALL_LINGUAS having a Pootle project for Glucose (without regard to completion) as long as a glibc locale exists upstream.

be
be@latin ???
bo
br
bs
cy
eu
fi
gl
hr
hy * important to OLPC
kk
kn
lg
lt
lv
nn
or
sr
sr@latin ???
st
uk
wo
zh_HK
zu

niu
(Note niu_NU and niu_NZ recently added to glibc 2.17) check glibc package version)

3) Languages in Pootle (without upstreamed glibc locales) that have a good amount of work.

Push for glibc locale development.

Add to "no locale" workaround section" and ALL_LINGUAS

As described in ​http://bugs.sugarlabs.org/ticket/4029

that is currently lines 48 to 52 of

​http://git.sugarlabs.org/sugar/mainline/blobs/master/extensions/cpsection/language/model.py

quz (locale to be submitted soon) Currently in workaround mode

hus
nah
pbs

4) IGNORE FOR NOW Languages in Pootle (without upstreamed glibc locales) that have almost no work done.

Push for glibc locale development and more L10n.

ak
bi
cpp
gn
gom
gom@latin
na
sm
son
to
tyv
tzm

[dnarvaez]

Given that the bug is 7 months old, can you please confirm you still want these changes?

[cjl]

Yes, these changes still need to be made, but configure.ac is now at

​https://github.com/sugarlabs/sugar/blob/master/configure.ac#L21

[walter]

I've updated configure.ac to the following:

ALL_LINGUAS="af am ar ayc be bg bi bn_IN bn bo br bs ca cs cy da de dz el en es eu fa_AF fa ff fi fil fr gi gu ha he hi ht hr hu hy id ig is it ja kk km ko kos lg lt lv mg mi mk ml mn mr ms mvo nb ne niu nl nn or pa pap pl ps pt_BR pt quz ro ru rw sd si sk sl sq sr st sv sw ta te th tr tvl tzo ug uk ur vi wa wo yo zh_CN zh_HK zh_TW zu"

I'm not sure what to do about be@latin? and sr@latin? Do you want these included?

Regarding Part 3 of this ticket, could you please provide the exact formats you want, e.g., for ht, we use 'Kreyol', 'Haiti', 'ht_HT.utf8' Please confirm below:

quz: 'Quechua', 'Peru', 'quz.utf8'
hus: 'Huastec', 'Mexico', 'hus.utf8'
nah: 'Nahuatl', 'Mexico', 'nah.utf8'
pbs: 'Pame', 'Mexico', 'pbs.utf8'

[walter]

BTW, all of these locales fail to build on F19: bo, eu, gi, kk, niu, or

[cjl]

What you've put down for the new locales looks good. Not sure why the others aren't building.

[walter]

here is an example of the build error:

make[1]: Entering directory `/home/walter/sugar-build/sugar/po'
file=echo nn | sed 's,.*/,,'.gmo \

&& rm -f $file && /usr/bin/msgfmt -o $file nn.po

make[1]: * No rule to make target or.po', needed by or.gmo'. Stop.
make[1]: * Waiting for unfinished jobs....
make[1]: Leaving directory `/home/walter/sugar-build/sugar/po'
make: * [all-recursive] Error 1

Are these rules generated upstream? Do we know for sure that, for example, or has glibc support? Maybe not in 2.17?

I could do the same work-around for these 5 languages as we did for quz, hus, nah, and pbs.

Also, what about be@latin and sr@latin?

[erikos]

I would split things up in separate commits.

First one would be the change from aym to ayc, like noted in the glibc announcement: ​http://upstream-tracker.org/changelogs/glibc/2.17/changelog.html

diff --git a/configure.ac b/configure.ac
index 3cb5667..5a71d2c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -18,7 +18,7 @@ PKG_CHECK_MODULES(SHELL, gtk+-3.0 gconf-2.0)
 
 # Setup GETTEXT
 #
-ALL_LINGUAS="af am ar aym bg bi bn_IN bn ca cs da de dz el en es fa_AF fa ff fil fr gu ha he hi ht hu id ig is it ja km ko kos mg mi mk ml 
+ALL_LINGUAS="af am ar ayc bg bi bn_IN bn ca cs da de dz el en es fa_AF fa ff fil fr gu ha he hi ht hu id ig is it ja km ko kos mg mi mk ml 
 
 GETTEXT_PACKAGE=sugar
 AC_PROG_INTLTOOL([0.33])

[erikos]

For (2) I am looking at the ​SUPPORTED file of glibc.

be [OK]
be@latin ??? [I see be_BY@latin/UTF-8 is it that what we need?]
bo [OK]
br [OK]
bs [OK]
cy [OK]
eu [OK]
fi [OK]
gl [OK]
hr [OK]
hy * important to OLPC [OK]
kk [OK]
kn [OK]
lg [OK]
lt [OK]
lv [OK]
nn [OK]
or [OK]
sr [OK]
sr@latin ??? [There is sr_RS@latin/UTF-8, is it that what we need?]
st [OK]
uk [OK]
wo [OK]
zh_HK [OK]
zu [OK]

niu [OK]

[erikos]

(3) I think it is fine to add the languages to the workaround as long as on glibc is worked on. Can you point us to the glibc bug that works on the inclusion of those?

Based on Walter's findings that would be:

diff --git a/extensions/cpsection/language/model.py b/extensions/cpsection/language/model.py
index b82a6e7..72c9c79 100644
--- a/extensions/cpsection/language/model.py
+++ b/extensions/cpsection/language/model.py
@@ -50,6 +50,10 @@ def read_all_languages():
     locales.append(('Kreyol', 'Haiti', 'ht_HT.utf8'))
     locales.append(('Dari', 'Afghanistan', 'fa_AF.utf8'))
     locales.append(('Pashto', 'Afghanistan', 'ps_AF.utf8'))
+    locales.append(('Quechua', 'Peru', 'quz.utf8'))
+    locales.append(('Huastec', 'Mexico', 'hus.utf8'))
+    locales.append(('Nahuatl', 'Mexico', 'nah.utf8'))
+    locales.append(('Pame', 'Mexico', 'pbs.utf8'))
 
     locales.sort()
     return locales

[cjl]

Agreed with breaking this up. aym > ayc change should be safe, by itself.

[cjl]

There are a lot of things going on here. I think part of the challenge may be caused by front-running not the glibc release, per se, but our use of that release.

According to packages.txt, OLPC Build 13.2 is using glibc 2.16, I'm not sure what glibc the current Sugar build is using, where do I find that?

a) ayc_PE and niu will be in glibc 2.17, so we may need the ayc and niu workarounda until we get to 2.17

b) ht_HT should not need a workaround, it has been in glibc since 2008. A recent rework of the locale is not going to change the name of the file that exists.

c) ps_AF was released in 2009, so a workaround should not be needed anymore

d) fa_AF still needs a workaround

e) quz_PE was only recently submitted to glibc, a work around will be needed until we are using 2.19 (probably).

hus, nah. pbs need glibc locale development, I'll work on that, I'm not sure how OLPC Mexico is using these now (assuming they are). Maybe we should chack in with them on these.

f) locales failing to build on F19
bo, eu, gi, kk, niu, or

Ok to skip all of these for now until we sort out build issues. niu may be due to glibc version (need 2.17 release for it to be there).

[erikos]

Replying to cjl:

Agreed with breaking this up. aym > ayc change should be safe, by itself.

Ok, that change has been pushed: ​https://github.com/sugarlabs/sugar/commit/871d9af44cc679ce1019d1a7dfcf97819254fb95

[erikos]

Yes, the latest OLPC build is using ​glibc-2.16-31.fc18.armv7hl.

If I am not mistaken current Sugar 0.100 needs a set of packages (webkitgtk and gwebsockets come to my mind) as recent as F19 to run. F19 includes ​glibc 2.17. I would like to hear from Daniel N. what he thinks about depending on glibc 2.17 for 0.100 before we move on and make us depend on it.

[dnarvaez]

Test

[dnarvaez]

Sorry for the noise but I had weird problems adding comments. What kind of issues do we expect or have seen with older glibc? The error Walter posted looks like missing .po file.

[cjl]

glibc before 2.17 will require workaround for ayc and niu, 2.17 and after will not.

[dnarvaez]

Ah, if it's just the workarounds I think it's fine to remove them. (I'm not convinced they should be upstream at all honestly, I'd rather have those as distro patches).

[dnarvaez]

To make it a bit more general. I think it's fine if those languages does not work with old glibc, but I'd rather avoid a strong dependency on 2.17 (i.e. breaking the build or runtime for any language).

[cjl]

I'm not sure about the distro patches idea. L10n problems always make their way back to me :-(

[dnarvaez]

I'm not suggesting we make that change now anyway, it was more a theoretical consideration.

[erikos]

I agree about not wanting a strong dependency on 2.17. I will see if we can build fine with an older glibc, 13.2.0 has 2.16.31.

Daniel do we have a list of hard 0.100 dependencies? As far as I know we depend on the F19 stack mainly, but I would like to know if it was possible to run on F18 for example, and if what it would take.

[dnarvaez]

See the recent ml thread about helping with 0.100

[erikos]

f) locales failing to build on F19
bo, eu, gi, kk, niu, or

Those fail because there is no according .po file. Are those pushed by pootle if available? Do they already exist?

[dnarvaez]

00:23 < cjl> dnarvaez: close if, a ticket like this will just need to be

created from time to time to keep ALL_LINGUAS current.

00:23 < cjl> Keeping one ticket open is not necessary