On Wed, Apr 20, 2016 at 9:12 AM, Dave Crossland <[email protected]> wrote: > (removed every cc but ieap) > > On 20 April 2016 at 02:15, Chris Leonard <[email protected]> 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 _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
