[IAEP] [Sugar-devel] Samson's proposal to SLOBs

[Chris Leonard]

On Wed, Apr 20, 2016 at 9:12 AM, Dave Crossland <dave at lab6.com> wrote:
> (removed every cc but ieap)
>
> On 20 April 2016 at 02:15, Chris Leonard <cjlhomeaddress at gmail.com> wrote:
>>
>> As a practical matter, full-time internet connectivity is not required
>> for effective L10n work.
>
>
> I agree, and I think that generally more can be done to make "Sugar On A
> Stick" into "Sugar Local Lab On A Stick" so that sugar communities without
> active/direct internet connections can do more to self-support themselves,
> and eventually upload what they have back to the central repos.
>
> I've thus added a note about this to the vision proposal:
>
> We develop our software to run on every computer device, from desktops and
> laptops to tablets and smartphones, and to run in situations with local
> networks without direct internet connections.
>
>
> - https://wiki.sugarlabs.org/go/Vision_proposal_2016

Indeed, Tony and I have been looking into determining and breaking
down the barriers to what I refer to as L10n "bootstrapping".
Enabling the local translation (in the classroom) to the local
language and further empowering the upstreaming of such translations
to our server for sharing worldwide.

Key barriers identified, so far:

1) The need for a suitable glibc locale.  This is a small file used by
GNU/Linux systems to teach the computer that the language exists anad
how to handle certain basic things, like sorting order, date
formatting etc accvording to suitable cultural conventions and
relevant standards.  We have so far dealt with this issue by
developing our own glibc locale files and either distributing them
ourselves (OLPC Tonga being one such example)

http://wiki.laptop.org/go/OLPC_Tonga

or by upstreaming the locale ot the glibc project and waiting for it
to trickle back downstream (Quechua, Aymara being prime examples).

glibc locale development is sadly kind of complicated requiring
bringing together expertise in relatively obscure standards (ISO-639,
POSIX, etc., etc.), conversion of natural language to explicit Unicode
point representation, linguistic expertise in the language in
question, and perhaps most daunting, navigating the challenging
upstream glibc community to actually land a patch.  I have been
working with the glibc community for some time now and I have earned
committer status to reduce that last hurdle, but it is still not
inconsiderable.

2)  There are a few issues that should be relatively easy to work
around.  Getting the POT files, adapting a suitable process for PO
(and MO) file editing and placement, Modifying Sugar itself to
understand tha the language exists (an issue possibly moderated by a
change from having an ALL_LINGUAS line defined in configure.ac to
leveraging another standard method consisting of including a LINGUAS
file in the PO directory.

3) Local QA and upstreaming of the resulting translations.

It is clearly an overall goal to provide a suitable toolchain and
simple process to enable "bootstrapping', but it will take some effort
to bring it all together.

cjl