Opened 8 years ago

Closed 7 years ago

#4264 closed defect (fixed)

tweak ALL_LINGUAS line of configure.ac

Reported by: cjl Owned by: erikos
Priority: Urgent Milestone: 0.102.0
Component: Sugar Version: Unspecified
Severity: Unspecified Keywords:
Cc: dnarvaez Distribution/OS: Unspecified
Bug Status: New

Description

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

Change History (27)

comment:1 Changed 8 years ago by dnarvaez

  • Component changed from untriaged to sugar
  • Owner set to erikos

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

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

comment:3 Changed 8 years ago by dnarvaez

  • Bug Status changed from Unconfirmed to New
  • Priority changed from Unspecified by Maintainer to Urgent
  • Type changed from task to defect

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

comment:5 Changed 8 years ago by walter

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

comment:6 Changed 8 years ago by cjl

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

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

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

comment:9 Changed 8 years ago by 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]

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

comment:11 in reply to: ↑ 8 ; follow-up: Changed 8 years ago by cjl

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

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

comment:13 in reply to: ↑ 11 Changed 8 years ago by 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

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

comment:15 Changed 8 years ago by erikos

  • Cc dnarvaez added

comment:16 Changed 8 years ago by dnarvaez

Test

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

comment:18 Changed 8 years ago by cjl

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

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

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

comment:21 Changed 8 years ago by cjl

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

comment:22 Changed 8 years ago by dnarvaez

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

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

comment:24 Changed 8 years ago by dnarvaez

See the recent ml thread about helping with 0.100

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

comment:26 Changed 7 years ago by dnarvaez

  • Milestone changed from Unspecified to 0.102

comment:27 Changed 7 years ago by dnarvaez

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

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

Note: See TracTickets for help on using tickets.