[IAEP] [Sugar-devel] Samson's proposal to SLOBs
cjlhomeaddress at gmail.com
Wed Apr 20 12:42:02 EDT 2016
Certainly. Most of the discussion so far has been in a context of
exchanging some very basic information about how i18n/L10n works in
the Sugar context that could easily have been done on an open forum
(although repetitive for many), but the lessons learned or conclusions
reached will make their way to the wiki and open forums as they mature
from simple exploration of the baseline to ideas on moving forward.
My purpose in replying at greater length with the 'key hurdles" was in
fact just such a sharing of information that I think not everyone
understands at the level achieved by people like you and Sebastian who
have actually struggled with landing a new language for a Sugar
On Wed, Apr 20, 2016 at 12:20 PM, Laura Vargas <laura at somosazucar.org> wrote:
> 2016-04-20 21:33 GMT+08:00 Chris Leonard <cjlhomeaddress at gmail.com>:
>> 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.
> Chirs, Tony,
> You guys should seriously consider the benefits of open discussion for
> this/all kind of issues/challenges for/with the community to solve/share.
> Regards, LV
>> 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)
>> 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
>> 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.
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
> Laura V.
> I&D SomosAZUCAR.Org
> Identi.ca/Skype acaire
> IRC kaametza
> Happy Learning!
More information about the IAEP