Sugar Labs - User contributions [en]

Activities without Repositories

2017-05-25T10:26:06Z

Features/Save-As

2017-04-25T01:20:54Z

Tony37:

<noinclude>
[[Category:Feature Page Incomplete]]
[[Category:Feature|.]]
</noinclude>





== Summary ==
Provides the 'save' and 'save as' capabilities common to document processing applications.

== Owner ==
* Name: [[User:iamutkarshtiwari| Utkarsh Tiwari]]
* Email: Utkarsh Tiwari <iamutkarshtiwari@gmail.com>

== Current status ==
* Targeted release: 0.112
* Last updated: 24th April 2017
* Percentage of completion: complete

== Detailed Description ==
* for a new document (start new), when the user quits the activity, a popup provides an opportunity for the user to give the document a name. The user can also decide not to save it.
* for an existing document, when the user quits the activity, a popup provides an opportunity to give it a new name. In this case, it will be saved under the new name and the original will be preserved. If the user chooses not to provide a new name, the document is saved replacing the original.
* provides a setting to enable or disable the feature

== Benefit to Sugar ==
''What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''

Currently Sugar saves objects to the Journal with the name of the activity. In the original toolkit design, the name was displayed to the top left of the toolbar so that a user could enter their own name. At that time, the user had a 'keep' button on the toolbar which enabled an object to be saved while continuing to work as found on most document based applications.

Currently, there is no keep button because Sugar does that automatically. This change comes with a serious flaw. Sugar uses the existing jobject when an activity is opened so that the original is overwritten. For example, a TurtleBlocks program could be resumed and the user decide to do a new program. His previous program is lost.

With this feature, the activity creates a new object cloned from the original. If the user saves the document (Turtle Blocks program) under a different name, the original remains in the Journal.
If the name is not changed, the object replaces the original.

This feature is modeled on the behavior of the 'save' and 'save as' feature of conventional document handling programs.

''Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.''

Requested by Tony Anderson. Implemented by Utkarsh Tiwari as part of GSOC 2016.

== Scope ==

''What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?''

Feature is implemented in activity.py (sugar and sugar3).
A gsetting was added to make enabling the feature optional.

==UI Design==

''Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.''

Direct impact on work flow. A visual mockup is in https://github.com/sugarlabs/sugar-toolkit/pull/4

== How To Test ==
{{:{{PAGENAME}}/Testing}}

== User Experience ==
''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.''

When the user presses the stop button or ctrl + q, a dialog will appear giving the opportunity to name or rename the associated Journal entry.

The user can chose not to save the object.

If the document has been resumed from the Journal or the Home View, the user will be able to supply a new name so that this entry is added to the Journal instead of overwriting the original.

== Dependencies ==
''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, does your feature depend on completion of another feature owned by someone else or that you would need to coordinate, which might cause you to be unable to finish on time? Other upstream projects like Python?''

No dependencies.

== Contingency Plan ==

None necessary, revert to previous release behaviour.

== Documentation ==

''Is there upstream documentation on this feature, or notes you have written yourself? Has this topic been discussed in the mailing list or during a meeting? Link to that material here so other interested developers can get involved.''

See PR #327 at https://github.com/sugarlabs/sugar-toolkit-gtk3

== Release Notes ==

''The Sugar Release Notes inform end-users about what is new in the release. An Example is [[0.84/Notes]]. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.''

Save As

A user or deployment can enable this feature by setting gsetting 'save as' to True). This feature provides a capability comparable to the 'save' and 'save as' capabilities offered by conventional document processing programs such as those of Libre Office.

== Comments and Discussion ==

* ''Link to the discussion of this feature on lists.sugarlabs.org''
* See [[{{TALKPAGENAME}}|the discussion tab for this feature.]]

Sugar 0.110

2016-11-13T00:50:24Z

Tony37:

Release Notes: Sugar 0.110

==Overview==

Sugar 0.110 is the latest stable release of the Sugar Learning Platform. This page describes changes and new features of this list and provides instructions for downloading and installing Sugar on supported computers.

==New Features==

* Features/Proxy_Settings
* Added the "sugar-erase-bundle" script https://github.com/sugarlabs/sugar/pull/687/files User:Quozl
* Turned off Metacity compositing User:Quozl
* Add a new PopWindow module for developers https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/313#issuecomment-223776873 Abhijit Patel

==Fixes==

* fix for CVE-2015-7547, a severe remote code execution vulnerability exposed by DNS lookups,
* predictable neighbourhood view icons; now placed the same each time, #381,
* predictable frame; the frame appears or disappears more easily, #4806,
* predictable palettes; menus appear where the mouse was when they were triggered, instead of where the mouse may have moved to, #4897,

==Platform: SOAS==

[https://dl.fedoraproject.org/pub/alt/unofficial/releases/24/x86_64/Fedora-SoaS-Live-x86_64-24-20160614.n.0.iso Download the SOAS 0.110 image]

Mount a usb drive with minimum 4GB capacity, more is better. Backup as needed, it will be erased.

Find out the path to the device. One method is to use df -h. Be careful to identify the usb stick,
e.g. /dev/sdb1 - check its size to match the size of the stick. A partition of 7.3GB might be shown for an 8GB stick.

==Platform: Raspberry Pi 3==
==Platform: Raspberry Pi 2==

copy the SOAS image to the stick with the dd command:

dd if= ~/Downloads/Fedora-SoaS-Live-x86_64-24-20160614.n.0.iso of=/dev/sdb1 bs=4M

Mount the stick on your computer and reboot. It should boot to Sugar.

Sugar 0.110

2016-11-13T00:47:14Z

Tony37: Created page with " Release: Sugar 0.110 Overview Sugar 0.110 is the latest stable release of the Sugar Learning Platform. This page describes changes and new features of this list and provide..."

Release: Sugar 0.110

Overview

Sugar 0.110 is the latest stable release of the Sugar Learning Platform. This page describes changes and new features of this list and provides instructions for downloading and installing Sugar on supported computers.

A list of new features;

* Features/Proxy_Settings
* Added the "sugar-erase-bundle" script https://github.com/sugarlabs/sugar/pull/687/files User:Quozl
* Turned off Metacity compositing User:Quozl
* Add a new PopWindow module for developers https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/313#issuecomment-223776873 Abhijit Patel

Fixes

* fix for CVE-2015-7547, a severe remote code execution vulnerability exposed by DNS lookups,
* predictable neighbourhood view icons; now placed the same each time, #381,
* predictable frame; the frame appears or disappears more easily, #4806,
* predictable palettes; menus appear where the mouse was when they were triggered, instead of where the mouse may have moved to, #4897,

SOAS

[https://dl.fedoraproject.org/pub/alt/unofficial/releases/24/x86_64/Fedora-SoaS-Live-x86_64-24-20160614.n.0.iso Download the SOAS 0.110 image]

Mount a usb drive with minimum 4GB capacity, more is better. Backup as needed, it will be erased.

Find out the path to the device. One method is to use df -h. Be careful to identify the usb stick,
e.g. /dev/sdb1 - check its size to match the size of the stick. A partition of 7.3GB might be shown for an 8GB stick.

copy the SOAS image to the stick with the dd command:

dd if= ~/Downloads/Fedora-SoaS-Live-x86_64-24-20160614.n.0.iso of=/dev/sdb1 bs=4M

Mount the stick on your computer and reboot. It should boot to Sugar.

User:Tony37

Translation Proposal

2016-03-03T09:41:35Z

Tony37:

==Translation Proposal==

'''A goal of Sugar Labs is to enable our users to experience Sugar in their own native language.'''

[Note: The current mission statements focus on languages (localize to as many languages as possible with high quality). The above statement is intended to focus on users not languages. I believe our goal should be to enable our users to experience Sugar in their native language.]

This goal requires two steps - internationalization (I18n) and localization (l10n). The first step (I18n) is to provide tools and documentation to facilitate the second step (L10n).

In general, I18n is the reponsibility of the Sugar development team. Localization, l10n, requires effort by volunteers who know the native language as well as English (the language of the POT master files).

Sugar is distributed in a release (e.g. Sugar 0.108 is released in 13.2.7) with the master files updated for new and changed strings. These master files are available from http://translate.sugarlabs.org". Specifically, the files for the current releases of Sugar are identified as projects: sugar and sugar-toolkit-gtk3.

In addition, this site tracks localization of Sugar activities which support Pootle localization. There are currently seven activities which are integral to Sugar (not-erasable): Browse, Image Viewer, Log, Read, Record, Terminal, and Write (excluding Journal which is localized in Sugar). These seven activities enable Pootle localization (are projects on tranlate.sugarlabs.org).

===Localization Delegate===

SugarLabs needs a Localization delegate. This is a role which Chris Leonard has filled from 2008-2013.

=====L10n leadership tasks:=====

Monitoring new activity development and advocating for i18n of code 
(gettext formatting).

Setting up new languages for availability in Pootle.

Reaching upstream to create the glibc locales for new languages required for them to be selectable languages in Linux-based systems.

Requesting github permissions for the pootle git-hub user (to enable pull of new templates, push of completed translations).

Monitoring Pootle for currency of templates, update of templates on existing languages, commit new translations. These tasks are the responsibility of individual language team leaders, but in practice need an overseer on behalf of all languages.

Arranging 'L10n' days at deployments where teachers have students improve strings in the relevant .po or supply missing strings. The outcome of an 'L10n' day should be an updated localization for that native language.

Arrange for participating deployments to be publicly recognized for their contribution.

Suggestions by Sebastian:

* Prepare glibc locales / other similar for Web stack *
* Maintain pootle servers and databases *
* Review / update translations and repositories *
* Keep git automation scripts *
* Add new projects / languages *
* Document processes
* Respond to queries from language teams
* Coordinate upstreaming of local work

Where * marks items requiring more technical knowledge or research

Recover L10n work done in the following languages that was lost in Pootle migration:

* Bislama
* Central Pame
* Crioulo-PT
* Dari
* Huastec
* Kinyarwanda
* Kosreaean
* Marovo
* Nauruan
* Sindhi
* Songhai languages
* Tuvaluan
* Tzotzil
* Urdu

Recover L10n and repo connections to numerous missinga ctivities

===ToDo:===

Discussion in the committee shows that our I18n infrastructure is in need of urgent maintenance.
ASLO no longer provides links to the git version. Many activities were repaired by the GCI participants. These need to be reviewed to make sure that the translation files are available and current. Chris Leonard has provided a list of 'missing activities', i.e. activities which had localization files but which were misplaced in a pootle migration. Etoys has not been updated since 2009 and the localization files are no longer available. The translate.sugarlabs.org which is the repository for the localization files is missing some files.

Provide a documented process for a local deployment to localize Sugar and some activities to a local language. The goal of the deployment is to make Sugar (and use of the XO more accessible).

* Chris Leonard has suggested that we base localization by a deployment on virtaal (a component of Pootle). He has installed and run this tool on an XO in the gnome desktop.

* As Caryl has pointed out, we also need to document this process so that it can be accomplished at a school as a classroom activity. This involves training teachers and providing tutorials for students.

Identify Sugar activities in ASLO which do not support localization (are not projects in translate.sugarlabs.org). Arrange for them to use gettext. Create master files (localize) to English.

* Priority to Spanish language activities
* Other important or popular Sugar activities

Sugar development could review Sugar (Python) activities to see if they support Pootle and attempt, eg. through GSOC, to get activities upgraded to implement Pootle and to include a base set of English Pootle files.

Define a standard I18n method for Sugarizer and sugar-web-activities. Chris Leonard recommends using the procedure adopted for turtleblocks.js. We need corresponding documentation of this process to enable it to be used immediately by GSOC participants who implement or port activities as sugar-web-activities.

Determine whether a common process can be used to localize sugar-web-activities and Sugarizer and its activities. (e.g. by using polyglot.js)

Provide a tool to to test python source code for compliance with the needs of Pootle

* All strings not in comments are referenced by gettext
* All strings match a msgstr in the corresponding en.po file

This may not be feasible since some strings ought not to be localized (e.g. the gsettings schema).

Provide a tool to verify that the available localizations are included in a release.

Develop a glossary of terms needed to refer to the XO, Sugar, and actions to be taken by users (e.g. close the XO, switch to the Group View).

The range.py (needing refinement) can be used to look at the strings in a po file to be localized to ensure that they do not use conflicting words or a more technical vocabulary that necessary. Every extra string in the master file may result in 50-100 translations.

Prepare a GSOC task to develop an I18n strategy and supporting tools for JavaScript activities. The following can be a good starting point:

"http://www.localeplanet.com/"

"https://blog.mozilla.org/webdev/2011/10/06/i18njs-internationalize-your-javascript-with-a-little-help-from-json-and-the-server/"

"http://airbnb.io/polyglot.js/"

Sugarizer has three translation files, including this master file:

"https://github.com/llaske/sugarizer/blob/master/locale.ini"

Document and improve all processes to be 'run-over-by-bus-safe'

==Original Draft==

SugarLabs needs a Localization delegate. The purpose of this proposal is to document the current Internationalization/Localization process and to define the role of the Localization delegate in that process. Some proposals for expansion/modification of the process are included.

Chris Leonard is arguably the incumbent Localization delegate:

Note: this title needs comment. The 'governance' page suggests that this position should be a delegate and not a co-ordinator since SLOBs cannot name a co-ordinator. I chose localization because I believe I18n (creating the framework and base) is the responsibility of sugar-devel and localization is a community responsibility.

<blockquote>
"For quite some time (starting in 2008, as I recall) under the "title"
of Translation Team Coordinator I worked in that role (unpaid) and I
can certainly help in fleshing out details. From 2008 - 2013 I was
able to dedicate adequate time to both technical aspects of i18n
(Pootle infrastructure and i18n advocacy/assistance to developers) as
well as L10n (localization mailing list, maintain L10n wiki pages,
support to new language communities, recruiting new localizers, etc.).
The good news (for me) is that in 2013 an extended period of
unemployment ended, the bad news is that I found myself unable to
continue to provide sufficient support to the community for several
reasons (technical issues with Pootle version migration as well as
development migration to github beyond my scope to manage alone) and a
slump in L10n activity by the community (perhaps in part because of
insufficient efforts to organize and rally the troops).

My employment situation has stabilized somewhat and I would like to
continue to contribute to the i18n/L10n effort, but as many have
experienced throughout the financial crisis, my new employment
circumstances are only providing a fraction of the income I had made
in the past, so my "free time" is subject to the demands of pursuing
supplemental income. I have done some work in support of Sugar Labs
since (e.g. Awajún glibc locale drafting), for which I might be
compensated for my time and effort from the TripAdvisor grant based on
a template agreement worked out with the SFC and the prior approval of
the Sugar Labs Oversight Board. That is essentially piece-work, a
pre-agreed amount for a pre-agreed deliverable (a committed glibc
locale), I have not yet actually drawn any TripAdvsor funds for this
purpose, but I may make such requests in future (assuming necessary
pre-approvals are granted)." cjl
</blockquote>

Translation has two separate parts: internationalization(I18n) and localization (L10n).

The Sugar-Devel team is responsible for I18n (preparing the framework to support localization) and the community is responsible for L10n - providing translations (by default, from English) to other languages.

The current process is based on Pootle [[http://pootle.translatehouse.org/]] server as the means of distributing localizations [[http://translate.sugarlabs.org]]

<blockquote>
L10n leadership tasks:

Monitoring new activity development and advocating for i18n of code
(gettext formatting).

Setting up new languages for availability in Pootle.

Reaching upstream to create glibc locales for new languages.
Necessary for them to be selectable languages in Linux-based systems.

Requesting github permissions for the pootle git-hub user (to enable
pull of new templates, push of completed translations).

Monitoring Pootle for currency of templates, update of templates on
existing languages, commit of new translations. Tasks technically the
responsibility of individual language team leaders, but in practice
needing an overseer on behalf of all languages. - cjl
</blockquote>

Let's divide the languages into three groups:

* English (the base language)

<blockquote>
Note: English is the original language of many activities, but there
are also many written first in Spanish, working with developers to
make Spanish-originating activities capable of being translated to
other languages (via an English bridge) is an issue requiring
attention. - cjl
</blockquote>

* Mediums of instruction (languages used at deployments as a common language where more than one language is spoken)

* Local language (languages used by students at home)

<blockquote>
English is not always the base language of our South Amreican activity
developers, as mentioned, this requires some careful thought and
action to make these Spanish-originating activities more widely
available in other languages.

Fortunately, the Pootle system can take the ongoing Spanish
translation of an English-originating activity and show it to
indigenous language translators (e.g. for Spanish to
Aymara/Quechua/Guarani/Awajún L10n where localizers are primarily
bilingual, but not English-speaking). Similarly, French translations
(if present in Pootle) can facilitate L10n into the indigenous
languages of Francophone Africa. This helps us create bridges to
indigenous languages by localization into a "language-of-instruction",
e.g. Spanish, French) early in the development cycle. cjl
</blockquote>

When a new Sugar release is made, the Pootle English master files should be a part of the release. Sugar development should ensure that Pootle files are available for all software in the release.

<blockquote>
Actually, POT template files (Pootle English master files) need to be
generated early in the development cycle, well before release and must
be updated regularly as strings change in source. Those updated
templates need to be synched on Pootle and made available as soon as
possible.

Typically there is a "string-freeze" declared for several weeks prior
to release allowing localizers time to do their work in a stable
background. The release itself includes all localizations made up to
the release date (as PO files). cjl
</blockquote>

Sugar may want to provide localization for one or more mediums of instruction (e.g. Spanish, French, Arabic). Since this would imply that files for these localizations are available at release, SugarLabs should decide which, if any, of these languages are to be supported.

<blockquote>
Agreed that a core set of languages should be completed prior to
release, not entirely sure about declaring "supported languages", we
should release what we have to encourage further work. cjl
</blockquote>

Deployments (or deployment sponsors) may need localization of Sugar for specific local languages (e.g. Kinyarwanda, Haitian Creole,Sotho, Xhosa). I believe these localizations are most likely to come from Sugar/XO deployments where the language is used.

<blockquote>
You would think so, and we can talk about Khmer (Cambodian) at some
other time, but the reality is that you run into odd things more often
than you would think, sometimes for the reasons you mention below
(language-of-instruction), sometimes it is more complex than that. - cjl
</blockquote>

However, strange things happen. For example, Rwanda is one of the largest and most active deployments. However, there is no Kinyarwanda localization. The reason is probably that in Rwanda the OLPC laptops are part of a path to English. They are introduced at the fourth grade, the first year when the required medium of instruction is English. While Kinyarwanda is a subject in grades 4-6, the priority is using the XOs to facilitate learning in English, Mathematics, and Science.

I believe that the Pootle files are distributed and installed with the released image. This should mean that XO users who know English and the native language could provide the localization. Once it is complete, the files can be installed on the XOs at the deployment and the localization would be available at the deployment. Ideally, localization would be done by the students as a learning activity. For example, in Rwanda, localization to Kinyarwanda would help students a lot in learning English. Sameer Verma has provided an excellent tutorial on how to do localization which could become the base for a guide to be included in the release (e.g. as an xol file). [[

<blockquote>
Oh, it were only that easy... In reality, the technical means for
"bootstrapping" localization at the local level do not exist. That is
a large and complex topic that I would behappy to discuss further, at6
length. One issue ismaking it possible to touch and change PO files
on local machines (I do have some thoughts), another is capturing that
local work back at the central Pootle server for the benefit of
others.

What you describe is an ideal situation that is not currently possible
(local bootstrapping), in reality we need the L10n to happen on our
centralized Pootle server to get them back out. - cjl
</blockquote>

<blockquote>
Actually I think we would have all the pieces required for a local bootstrapping scenario. There are friendly local .po editors, or it could even be done with a spreadsheet. The issue here is it requires greater preparation from logistics/technical people, and extra work afterwards from coordinators as strings need to be guaranteed to reach Pootle in the end (this is the hard bit). [[User:Sebastian|Sebastian]] ([[User talk:Sebastian|talk]]) 02:58, 25 February 2016 (EST)
</blockquote>

So, the translation manager would be responsible to identify deployments which use specific local languages and work with them to organize 'L10n' days for new releases. The translation manager should then interface with Pootle to submit the localization files for review and acceptance by Pootle.

Sugar development could review Sugar (Python) activities to see if they support Pootle and attempt, eg. through GSOC, to get activities upgraded to implement Pootle and to include a base set of English Pootle files.

Perhaps OLPC France could be tasked to provide French localization as part of the release process. For Spanish, perhaps Sebastian Silva (Peru) or Plan Ceibal could accept responsibility for Spanish.

Other comments:

<blockquote>
The most important consideration is what the local people really want…
not what we think they want or think they should want. Maybe they are happy
with English. On the other hand, maybe they would prefer their own local
language (or dialect). Don't assume anything. Don't ask just one person.
Ask enough people to get a genuine consensus. Caryl
</blockquote>

<blockquote>
Using students to provide localization is an excellent educational
activity. However, it needs to be overseen by an "expert" (maybe their
teacher) to insure it is both accurate and appropriate before submission to
Pootle. Caryl
</blockquote>

<blockquote>
The Spanish of Mexico is slightly different from the Spanish of Peru
and/or the Spanish of Argentina (etc., etc,, etc). Using students for
localization could be helpful here and, I'm sure for other languages. Caryl
</blockquote>

<blockquote>
Again, for Spanish… why not look to our largest Sugar deployment,
Uruguay, for enlisting students to help? One of the SLOBs (José Miguel
García) is Uruguayan as is super-star teacher Rosamel Ramirez. Caryl
</blockquote>

<blockquote>
Applying to GSOC for help in any aspect with this work seems like a "no
brainer" but the deadline for applications for 2016 was yesterday! [image:
Emoji] - Caryl
</blockquote>

<blockquote>
The success of the first translation will depend on how established /
knowledgeable the local community is. Reviewing the first round of Haitian
Creole translations, which I think were done by volunteers, you notice some
obvious problems, like inconsistent terms. I've personally seen students
and teachers become confused by these issues when using the computer. They
keep using it anyway, but it definitely affects the user experience. Now,
hopefully the attitude of "this is the wrong way to say it" will inspire
the next round of volunteers to do a better translation - but that's a big
assumption to make. Sora
</blockquote>

<blockquote>
I think it's important to remember that in many of these places, language
ideology is something communities are working through. All the research
supports literacy / learning in the mother-tongue language, but in many
places the languages kids speak at home are seen as inferior to the ones
they learn in school - not just because the one they learn in school is
more widely-spoken, but because of myths that the language spoken at home
is not "advanced" enough to study something like science / math / tech.

So, basically, if the first translation is not adequate, there may not be a
second translation. People may decide "This language is not adequate for
using the computer" instead "Our translation is not adequate; let's make it
better."' Sora
</blockquote>

<blockquote>
Another hole in the i18n infrastructure is with our Javascript activities.
Maybe worth a GSOC project to shore it up. - Walter
</blockquote>

<blockquote>
For javascript L10n, start with these links:

<a href=http://www.localeplanet.com/></a>

<a href=https://blog.mozilla.org/webdev/2011/10/06/i18njs-internationalize-your-javascript-with-a-little-help-from-json-and-the-server/></a> - cjl
</blockquote>

Translation Proposal

2016-02-25T08:38:40Z

Tony37:

==Translation Proposal==

'''A goal of Sugar Labs is to enable our users to experience Sugar in their own native language.'''

[Note: The current mission statements focus on languages (localize to as many languages as possible with high quality). The above statement is intended to focus on users not languages. I believe our goal should be to enable our users to experience Sugar in their native language.]

This goal requires two steps - internationalization (I18n) and localization (l10n). The first step (I18n) is to provide tools and documentation to facilitate the second step (L10n). Sugar has adopted Pootle as the primary tool for I18n. However, there are two important elements which
do not lend themselves to this approach.
* First are the FLOSS manuals (documentation) and its Sugar activity embodiment, Help Activity.
* Second, the Sugar-web-activities (based on html5 and javascript).

In general, I18n is the reponsibility of the Sugar development team. Localization, l10n, requires effort by volunteers who know the native language as well as English (the language of the POT master files).

Sugar is distributed in a release (e.g. Sugar 0.108 is released in 13.2.7) with the master files updated for new and changed strings. These master files are available from http://translate.sugarlabs.org". Specifically, the files for the current releases of Sugar are identified as projects: sugar and sugar-toolkit-gtk3.

In addition, this site tracks localization of Sugar activities which support Pootle localization. There are currently seven activities which are integral to Sugar (not-erasable): Browse, Image Viewer, Log, Read, Record, Terminal, and Write (excluding Journal which is localized in Sugar). These seven activities enable Pootle localization (are projects on tranlate.sugarlabs.org).

===Localization Delegate===

SugarLabs needs a Localization delegate. This is a role which Chris Leonard has filled from 2008-2013.

=====L10n leadership tasks:=====

Monitoring new activity development and advocating for i18n of code 
(gettext formatting).

Setting up new languages for availability in Pootle.

Reaching upstream to create the glibc locales for new languages required for them to be selectable languages in Linux-based systems.

Requesting github permissions for the pootle git-hub user (to enable pull of new templates, push of completed translations).

Monitoring Pootle for currency of templates, update of templates on existing languages, commit new translations. These tasks are the responsibility of individual language team leaders, but in practice need an overseer on behalf of all languages.

Arranging 'L10n' days at deployments where teachers have students improve strings in the relevant .po or supply missing strings. The outcome of an 'L10n' day should be an updated localization for that native language.

Arrange for participating deployments to be publically recognized for their contribution.

Suggestions by Sebastian:

* Prepare glibc locales / other similar for Web stack *
* Maintain pootle servers and databases *
* Review / update translations and repositories *
* Keep git automation scripts *
* Add new projects / languages *
* Document processes
* Respond to queries from language teams
* Coordinate upstreaming of local work

Where * marks items requiring more technical knowledge or research

===ToDo:===

The technical means for localization at the local level do not exist.

* It must be possible to touch and change PO files on local machines in Sugar.
* It must be possible to capture that local work back at the central
Pootle server for the benefit of others.

Identify Sugar activities in ASLO which do not support localization (are not projects in translate.sugarlabs.org). Arrange for them to use gettext. Create master files (localize) to English.

* Priority to Spanish language activities
* Other important or popular Sugar activities

Sugar development could review Sugar (Python) activities to see if they support Pootle and attempt, eg. through GSOC, to get activities upgraded to implement Pootle and to include a base set of English Pootle files.

Define a standard I18n method for Sugarizer and sugar-web-activities.

Provide the I18n infrastructure to support localization of Sugarizer and sugar-web-activities.

Provide a tool to to test python source code for compliance with the needs of Pootle

* All strings not in comments are referenced by gettext
* All strings match a msgstr in the corresponding en.po file

Provide a tool to verify that the .po file for all localizations are included in a release.

Develop a glossary of terms needed to refer to the XO, Sugar, and actions to be taken by users (e.g. close the XO, switch to the Group View).

Develop a tool to parse the strings in the master files to identify the vocabulary used.
(see http://www.lextutor.ca/research/nation_waring_97.html" - interesting but not directly relevant

Paul Nation developed a simple program 'range' which scans a text and identifies words by a presence
in one or more included word lists. For example, one of the 1000 most frequently used words would be printed in the default font/color. A word not on this list would be printed in red. Such a tool could be used to check the base strings for consistent use of words and for use of common English words. The cited article explains whythis is important and links to specific lists of commonly used words.

Prepare a GSOC task to develop an I18n strategy and supporting tools for javascript activities. The following can be a good starting point:

"http://www.localeplanet.com/"

"https://blog.mozilla.org/webdev/2011/10/06/i18njs-internationalize-your-javascript-with-a-little-help-from-json-and-the-server/"

"http://airbnb.io/polyglot.js/"

Sugarizer has three translation files, including this master file:

"https://github.com/llaske/sugarizer/blob/master/locale.ini"

Document and improve all processes to be 'run-over-by-bus-safe'

==Original Draft==

SugarLabs needs a Localization delegate. The purpose of this proposal is to document the current Internationalization/Localization process and to define the role of the Localization delegate in that process. Some proposals for expansion/modification of the process are included.

Chris Leonard is arguably the incumbent Localization delegate:

Note: this title needs comment. The 'governance' page suggests that this position should be a delegate and not a co-ordinator since SLOBs cannot name a co-ordinator. I chose localization because I believe I18n (creating the framework and base) is the responsibility of sugar-devel and localization is a community responsibility.

<blockquote>
"For quite some time (starting in 2008, as I recall) under the "title"
of Translation Team Coordinator I worked in that role (unpaid) and I
can certainly help in fleshing out details. From 2008 - 2013 I was
able to dedicate adequate time to both technical aspects of i18n
(Pootle infrastructure and i18n advocacy/assistance to developers) as
well as L10n (localization mailing list, maintain L10n wiki pages,
support to new language communities, recruiting new localizers, etc.).
The good news (for me) is that in 2013 an extended period of
unemployment ended, the bad news is that I found myself unable to
continue to provide sufficient support to the community for several
reasons (technical issues with Pootle version migration as well as
development migration to github beyond my scope to manage alone) and a
slump in L10n activity by the community (perhaps in part because of
insufficient efforts to organize and rally the troops).

My employment situation has stabilized somewhat and I would like to
continue to contribute to the i18n/L10n effort, but as many have
experienced throughout the financial crisis, my new employment
circumstances are only providing a fraction of the income I had made
in the past, so my "free time" is subject to the demands of pursuing
supplemental income. I have done some work in support of Sugar Labs
since (e.g. Awajún glibc locale drafting), for which I might be
compensated for my time and effort from the TripAdvisor grant based on
a template agreement worked out with the SFC and the prior approval of
the Sugar Labs Oversight Board. That is essentially piece-work, a
pre-agreed amount for a pre-agreed deliverable (a committed glibc
locale), I have not yet actually drawn any TripAdvsor funds for this
purpose, but I may make such requests in future (assuming necessary
pre-approvals are granted)." cjl
</blockquote>

Translation has two separate parts: internationalization(I18n) and localization (L10n).

The Sugar-Devel team is responsible for I18n (preparing the framework to support localization) and the community is responsible for L10n - providing translations (by default, from English) to other languages.

The current process is based on Pootle [[http://pootle.translatehouse.org/]] server as the means of distributing localizations [[http://translate.sugarlabs.org]]

<blockquote>
L10n leadership tasks:

Monitoring new activity development and advocating for i18n of code
(gettext formatting).

Setting up new languages for availability in Pootle.

Reaching upstream to create glibc locales for new languages.
Necessary for them to be selectable languages in Linux-based systems.

Requesting github permissions for the pootle git-hub user (to enable
pull of new templates, push of completed translations).

Monitoring Pootle for currency of templates, update of templates on
existing languages, commit of new translations. Tasks technically the
responsibility of individual language team leaders, but in practice
needing an overseer on behalf of all languages. - cjl
</blockquote>

Let's divide the languages into three groups:

* English (the base language)

<blockquote>
Note: English is the original language of many activities, but there
are also many written first in Spanish, working with developers to
make Spanish-originating activities capable of being translated to
other languages (via an English bridge) is an issue requiring
attention. - cjl
</blockquote>

* Mediums of instruction (languages used at deployments as a common language where more than one language is spoken)

* Local language (languages used by students at home)

<blockquote>
English is not always the base language of our South Amreican activity
developers, as mentioned, this requires some careful thought and
action to make these Spanish-originating activities more widely
available in other languages.

Fortunately, the Pootle system can take the ongoing Spanish
translation of an English-originating activity and show it to
indigenous language translators (e.g. for Spanish to
Aymara/Quechua/Guarani/Awajún L10n where localizers are primarily
bilingual, but not English-speaking). Similarly, French translations
(if present in Pootle) can facilitate L10n into the indigenous
languages of Francophone Africa. This helps us create bridges to
indigenous languages by localization into a "language-of-instruction",
e.g. Spanish, French) early in the development cycle. cjl
</blockquote>

When a new Sugar release is made, the Pootle English master files should be a part of the release. Sugar development should ensure that Pootle files are available for all software in the release.

<blockquote>
Actually, POT template files (Pootle English master files) need to be
generated early in the development cycle, well before release and must
be updated regularly as strings change in source. Those updated
templates need to be synched on Pootle and made available as soon as
possible.

Typically there is a "string-freeze" declared for several weeks prior
to release allowing localizers time to do their work in a stable
background. The release itself includes all localizations made up to
the release date (as PO files). cjl
</blockquote>

Sugar may want to provide localization for one or more mediums of instruction (e.g. Spanish, French, Arabic). Since this would imply that files for these localizations are available at release, SugarLabs should decide which, if any, of these languages are to be supported.

<blockquote>
Agreed that a core set of languages should be completed prior to
release, not entirely sure about declaring "supported languages", we
should release what we have to encourage further work. cjl
</blockquote>

Deployments (or deployment sponsors) may need localization of Sugar for specific local languages (e.g. Kinyarwanda, Haitian Creole,Sotho, Xhosa). I believe these localizations are most likely to come from Sugar/XO deployments where the language is used.

<blockquote>
You would think so, and we can talk about Khmer (Cambodian) at some
other time, but the reality is that you run into odd things more often
than you would think, sometimes for the reasons you mention below
(language-of-instruction), sometimes it is more complex than that. - cjl
</blockquote>

However, strange things happen. For example, Rwanda is one of the largest and most active deployments. However, there is no Kinyarwanda localization. The reason is probably that in Rwanda the OLPC laptops are part of a path to English. They are introduced at the fourth grade, the first year when the required medium of instruction is English. While Kinyarwanda is a subject in grades 4-6, the priority is using the XOs to facilitate learning in English, Mathematics, and Science.

I believe that the Pootle files are distributed and installed with the released image. This should mean that XO users who know English and the native language could provide the localization. Once it is complete, the files can be installed on the XOs at the deployment and the localization would be available at the deployment. Ideally, localization would be done by the students as a learning activity. For example, in Rwanda, localization to Kinyarwanda would help students a lot in learning English. Sameer Verma has provided an excellent tutorial on how to do localization which could become the base for a guide to be included in the release (e.g. as an xol file). [[

<blockquote>
Oh, it were only that easy... In reality, the technical means for
"bootstrapping" localization at the local level do not exist. That is
a large and complex topic that I would behappy to discuss further, at6
length. One issue ismaking it possible to touch and change PO files
on local machines (I do have some thoughts), another is capturing that
local work back at the central Pootle server for the benefit of
others.

What you describe is an ideal situation that is not currently possible
(local bootstrapping), in reality we need the L10n to happen on our
centralized Pootle server to get them back out. - cjl
</blockquote>

<blockquote>
Actually I think we would have all the pieces required for a local bootstrapping scenario. There are friendly local .po editors, or it could even be done with a spreadsheet. The issue here is it requires greater preparation from logistics/technical people, and extra work afterwards from coordinators as strings need to be guaranteed to reach Pootle in the end (this is the hard bit). [[User:Sebastian|Sebastian]] ([[User talk:Sebastian|talk]]) 02:58, 25 February 2016 (EST)
</blockquote>

So, the translation manager would be responsible to identify deployments which use specific local languages and work with them to organize 'L10n' days for new releases. The translation manager should then interface with Pootle to submit the localization files for review and acceptance by Pootle.

Sugar development could review Sugar (Python) activities to see if they support Pootle and attempt, eg. through GSOC, to get activities upgraded to implement Pootle and to include a base set of English Pootle files.

Perhaps OLPC France could be tasked to provide French localization as part of the release process. For Spanish, perhaps Sebastian Silva (Peru) or Plan Ceibal could accept responsibility for Spanish.

Other comments:

<blockquote>
The most important consideration is what the local people really want…
not what we think they want or think they should want. Maybe they are happy
with English. On the other hand, maybe they would prefer their own local
language (or dialect). Don't assume anything. Don't ask just one person.
Ask enough people to get a genuine consensus. Caryl
</blockquote>

<blockquote>
Using students to provide localization is an excellent educational
activity. However, it needs to be overseen by an "expert" (maybe their
teacher) to insure it is both accurate and appropriate before submission to
Pootle. Caryl
</blockquote>

<blockquote>
The Spanish of Mexico is slightly different from the Spanish of Peru
and/or the Spanish of Argentina (etc., etc,, etc). Using students for
localization could be helpful here and, I'm sure for other languages. Caryl
</blockquote>

<blockquote>
Again, for Spanish… why not look to our largest Sugar deployment,
Uruguay, for enlisting students to help? One of the SLOBs (José Miguel
García) is Uruguayan as is super-star teacher Rosamel Ramirez. Caryl
</blockquote>

<blockquote>
Applying to GSOC for help in any aspect with this work seems like a "no
brainer" but the deadline for applications for 2016 was yesterday! [image:
Emoji] - Caryl
</blockquote>

<blockquote>
The success of the first translation will depend on how established /
knowledgeable the local community is. Reviewing the first round of Haitian
Creole translations, which I think were done by volunteers, you notice some
obvious problems, like inconsistent terms. I've personally seen students
and teachers become confused by these issues when using the computer. They
keep using it anyway, but it definitely affects the user experience. Now,
hopefully the attitude of "this is the wrong way to say it" will inspire
the next round of volunteers to do a better translation - but that's a big
assumption to make. Sora
</blockquote>

<blockquote>
I think it's important to remember that in many of these places, language
ideology is something communities are working through. All the research
supports literacy / learning in the mother-tongue language, but in many
places the languages kids speak at home are seen as inferior to the ones
they learn in school - not just because the one they learn in school is
more widely-spoken, but because of myths that the language spoken at home
is not "advanced" enough to study something like science / math / tech.

So, basically, if the first translation is not adequate, there may not be a
second translation. People may decide "This language is not adequate for
using the computer" instead "Our translation is not adequate; let's make it
better."' Sora
</blockquote>

<blockquote>
Another hole in the i18n infrastructure is with our Javascript activities.
Maybe worth a GSOC project to shore it up. - Walter
</blockquote>

<blockquote>
For javascript L10n, start with these links:

<a href=http://www.localeplanet.com/></a>

<a href=https://blog.mozilla.org/webdev/2011/10/06/i18njs-internationalize-your-javascript-with-a-little-help-from-json-and-the-server/></a> - cjl
</blockquote>

Translation Proposal

2016-02-25T07:14:07Z

2015-12-29T03:30:00Z

Tony37: Created page with "My name is Tony Anderson. I'm a retired computer professional. As an independent volunteer, I have been in full-time support of the OLPC concept and XO deployments since 2007..."

My name is Tony Anderson. I'm a retired computer professional. As an independent volunteer, I have
been in full-time support of the OLPC concept and XO deployments since 2007.

As a volunteer initially at OLE Nepal, my assignment was to support the school server and later to work with Interns preparing to make XO deployments to remote areas of Nepal.

In 2010, started work as a volunteer in Rwanda, which has a national OLPC program (the XO is shown on their currency). Working with that program increased my direct experience with the requirements to support a deployment.

Supporting Laptops to Lesotho introduced me first-hand to the problems of deployments in very remote locations, especially the need for electrical support (both schools there are solar powered because the electrical grid doesn't reach - so there is no electrical experience in the community).

Recently, have started support of two deployments on Palawan in the Philippines. One is a primary school with XO-1.5. The second is a secondary school with refurbished Dell laptops (Core Duo).
The latter provides an opportunity to see how much of the available school server content can be useful for older students. My goal is to install Sugar on Ubuntu on these laptops (Not immediately possible because James Cameron's Sugar desktop only works in 64-bit architecture),

For me, the goal of one laptop per child is to use computers to provide a more meaningful educational experience for students at community schools which are on the wrong side of the 'digital divide'. One primary assumption is that the value of the computer grows with the amount of time the student has access to it - hence, one laptop per child. This strongly contrasts with the conventional computer lab concept in which students are scheduled to use the laptops during specific periods to learn about computers. The educational value of the computer is in its support for learning across the curriculum, learning about computers is the natural result of their use (no one goes to class to learn to use a mobile).

Experience has shown that such a deployment requires a school server to provide local access to information from the internet. The economics are very favorable since very large hard drives are inexpensive (1TB for $60)and use of a server to deliver web pages and files does not require a high-powered processor. Currently a schoolserver can be provided for about the cost of two XOs.

My primary day-day effort is to strengthen the integration of Sugar on the XO with the school server and to add additional services and content. The BERNIE project is an attempt to put all of the software and content needed to deploy XOs with a school server on a single 1TB hard drive.
This has proven much more difficult than expected because of the rapid changes to the software and the wealth of new content becoming available. At a school, the software and content needs to be updated only once a year at the beginning of each school year.

Sugar must move away from a dependency on the XO and be readily available for a wide range of platforms. This is existential because SugarLabs will fail without a large and growing base of users. SOAS is a valuable step, but we to be able to deploy laptops or tablets which requires installation of Sugar on the computer. James Cameron's efforts to provide Sugar on Ubuntu is one example. Lionel Laske's effort to provide a web based Sugar experience is another.

At the same time, SugarLabs has a responsibility to provide Long Term_Support for the XOs in the field (most of which are XO-1). Most deployments depended on outside donors to acquire their laptops and do not have the funds to replace them with newer equipment. These deployments will continue to use them as long as they function. Most deployed XOs are still using the original installed software (e.g. 0.82), a consequence of the high logistical cost to service them.

SugarLabs needs to extend the OLPC concept to include deployments with only a classroom set of laptops which are moved from class to class during the week. As Walter Bender pointed out at the Malaysia Summit, one laptop per child means that there are enough so that in use there is one available for each child in the class. This implies some attention to enabling the multiple users to save and access their own work.

Sugar needs to recognize the incredibly valuable asset represented by ASLO (our app store). We need to encourage the development of new activities and to encourage the upgrade of existing ones. We need to wrestle with the decision to focus on Python or on Javascript in future development investments.

User:Tony37

2015-12-29T02:26:44Z

Tony37:

2012-06-24T10:57:45Z

Tony37: /* TinyMCE */

<noinclude>[[Category:Activities]]
</noinclude>

[[Image:Activity-learn.png‎]]

[http://activities.sugarlabs.org/en-US/sugar/addon/4430 Activity] | [ Source]

In a classroom, the Learn activity takes the role of the traditional textbook. In this analogy it is not the
textbook, it is a bound blank book. It includes an edit mode which enables a deployment to create the units and lessons (milestones and Learn activities) that make up the textbook.

Learn is a component of the Karma Learning System. When installed as a part of KLS, it is tightly integrated with the schoolserver. The primary design goal is to provide local copies of lessons as needed so that the student can use them when not connected to the school server.

Version 51 enables evaluation of the activity independently of a schoolserver by using a USB removable drive.

==Installation==

===Prepare a removable drive===

The removable drive can be a usb flash drive or an SD card.

If you run the Terminal activity and enter the command:

ls /media

,you should see /media/XXX (where XXX is the label of your removable drive).

The Learn activity requires a recent (4+) version of Firefox. While Firefox is installed on versions of
Sugar with the Gnome desktop, the version precedes version 4.

From the Firefox website, download the compressed Firefox file, e.g. firefox-*.tar.bz2, where '*' is the
version number of the latest Firefox release, e.g. 13.0. Copy this file to the XXX drive.

From this website download these files and copy them to the XXX drive:

[[Image:Kls_demo_1.tar.bz2]] is a 45mb file which contains the sample content for the Learn activity

[[File:Learn.sh]] is a script which installs Learn from the bundle.

[[File:Firefox.sh]] is a script which installs Firefox from the tar file on the XXX drive. It also
modifies two files in Sugar: sugar-launch and SimpleHTTPServer.py. These changes have no effect on
normal Sugar use.

Download learn-51.xo from the Activities.Sugarlabs.org site. Copy this bundle to the XXX drive.

When this is done, the command: ls /media/XXX should show the following:

firefox-*.tar.bz2
Firefox.sh
Kls_demo_1.tar.bz2
learn-51.xo
Learn.sh

===Execute the install scripts===
Now mount the XXX drive on the XO.

Launch the Terminal activity.

Enter the commands:

cd /media/XXX
./Learn.sh
sudo ,/Firefox.sh

Upon completion of these commands, the script shuts down the XO.
The XO is now ready. Restart to use Learn.

===Firefox Preferences===

There are some Firefox preferences that need to be set.

In View/Toolbars only Menu Bar and Navigation Toolbar should be checked.

Navigate to: about:config.

Set browser.tabs.onTop to false (A personal preference, normally students do not use Firefox tabs)
Set dom.allow_scripts_to_close_windows to true. (Enables quit button to work)
Set layout.css.dpi to 96. (better fit for XO screen resolution)

In 'Tabs', uncheck 'Always show the tab bar'. Students do not normally use tabs in Firefox.

Students are advised to set View to fullscreen. Fortunately current versions of Firefox start in fullscrren
when shut down in that mode. There is apparently no way to specify that Firefox launch in full screen mode and, currently, there is no way to access F11 on the XO (even in Gnome desktop!).

Firefox tries to refresh pages from a cache in memory. This can sometimes prevent changes in screens to be immediately visible. In this case, use alt+F5 to refresh the page from the source. Note: on the XO keyboard,
F5 is the smallest dot in the currently unused block of seven dots in the center of the top row.

==Principal Screens==

===Main Screen===

[[Image:Learn-mainscreen.png]]

All Learn screens have a header and footer. The header is used for navigation (right side) and providing special functions (left). The center provides a title for the screen. The footer is used for navigation within a Learn activity and to provides special capabilities to that activity.

The main screen has no navigation on the header. The 'Staff' button allows you to switch mode from staff (priviliged) mode to that of a student in fourth (p4), fifth (p5), or sixth grade (p6). The school icon in KLS opens a page showing the teacher a list of students and their current status. The Moodle button is a link to Moodel (http://schoolserver). The last button is the normal 'quit' button. Learn is designed to be run in the Firefox fullscreen mode. This means that Firefox navigation is available by moving the cursor to the top of the screen, but that students do not normally have to deal with 'http' addresses.

The main screen shows the available subjects. In this case English, Mathematics, and Science (the three subjects supported on the laptops by the Ministry of Education in Rwanda).

The rocket icon is the Explore subject. In this version it contains examples of mini-lessons introducing the XO and Learn. It is intended to offer students access to mini-courses on a wide range of topics outside the classroom which they are encouraged to explore. When a student completes a mini-course, they receive a badge which is shown on their page (visible by clicking the school icon on their main page).

In the context of KLS, the classroom refers to lessons aligned with the curriculum applicable to the deployment and not the physical location. Using Scratch in the physical classroom may still not be part of the curriculum, while doing an English activity at home is certainly 'in the classroom'.

===Laboratory===

[[Image:laboratory.png]]

The Laboratory subject is visible only to staff. It is set up to enable teachers (and the deployment) to build the units and lessons for the next term. In this case it is set up for Term 3 of 2012 which begins in September.
Note that the Laboratory anticipates the addition of French as a subject in Term 3. Note: also that subject menus provide a breadcrumb back to the main screen. Each of the twelve courses contains no milestones or activities.
Milestones and activities are added using the edit capability which is explained below.

===Course Menu===

[[Image:course_menu.png]]

This menu is only visible to staff members. This is the English course menu. There are three courses: sje421, sje521, and sje621. While not required, it is convenient to use a code in naming courses. In this case, sj is the Saint Jacobs school in Kigali, Rwanda. The e is English. The 4 is fourth grade (p4). The 2 represents school year 2012. The 1 represents the first term.

In student mode, the students go directly from the main screen to the next screen - the milestone ladder. Within KLS, Learn downloads milestones automatically so that the student has on his laptop enough work for about three weeks before a connection to the school server is required. Staff may need to access any milestone in any course and so need this screen.

===Milestone Ladder===

[[Image:milestone_menu.png]]

This screen shows two milestones from the beginning of Term 1. Each milestone represents about one week's work
for the student. This version of the Learn.activity contains the first two milestones in each subject and course.
These milestones were created by the teachers at the Saint Jacobs school in Kigali.

===Activity Ladder===

[[Image:activity_ladder.png]]

A milestone or unit should provide the instruction needed for a student to achieve a specific learning objective.
The lessons (or activities or tasks) which provide this instruction are shown in the activity ladder. There are two modes of presentation, open and normal. In the open mode, the student has access to any activity. Normally, the students are directed to the day's activity by the teacher. In the normal mode, students work through the activities (and milestones) in sequence. In this mode, students work independently completing the work at their own pace. This means the teacher must be able to accommodate the fact that not all students are working on the same milestone or activity.

The word activity is heavily overloaded in the Sugar environment. Learn is a Sugar activity. The Activity Ladder shows Learn activities. Often lesson will be used to refer to a Learn activity to avoid confusion with Sugar activity. This is not a good solution, since a lesson plan may involve more than one Sugar activity.

===Activity===

[[Image:activity_example.png]]

This is an example of an activity. The similarity to a textbook page is not accidental. In Rwanda, most students do not have paper textbooks and so the teacher copies the relevant material from the textbook to the blackboard. The students copy this information to their copy books. As a consequence, the teachers who were new to computers created lessons that look like what they put on the blackboard. Even this is helpful because it frees about half a period previously spent copying to and from the blackboard.

The buttons (edit and up arrow) on the right of the header are used in creating lessons which will be explained below.

==Content==

This version of the Learn activity contains sample of the content which would be available in an installation of the Karma Learning System.

===Class Subjects===

The English, Mathematics, and Science buttons show the first two milestones for Term 1 at École Saint Jacobs in courses for P4, P5, and P6. These milestones were created by the teachers at a workshop held in Nevember and December, 2011.

The Laboratory subject is visible only to staff members. It is set up to enable creation of milestones for Ennglish, Mathematics, Science, and French for Term 3 which begins in September, 2012.

===Explore===

[[Image:explore_subjects.png]]

The sample coontent in the Explore subject is organized into six courses:
#examples
#getstarted
#learn
#lesson
#quiz
#library

====Examples====

The examples course has three milestones:

=====Basic Lessons=====

This milestone illustrates the capabilities of basic lessons. These are five activities (or lessons)
in this milestone:
#text only (lesson in French from Haiti)
#text plus image (lesson from École Shalom in Haiti)
#multi-screen lesson (lesson from Siyavula)
#text + image with audio (lesson from Rwanda Curriculum Workshop 2010).
#text with interactive quiz (taken from a past P6 leaving exam in Haiti (French)).

====Sugar Activities====

The second milestone shows some examples of using a Sugar activity in a lesson. The Learn activity stores the lesson content in a bundle in the Journal and then resumes the activity from that Journal object. To return to the Learn activity, quit the 'launched' activity.
#ShowNTell - This activity launches ShowNTell with a slide show illustrating how to use Turtle Blocks to draw Vertical, Horizontal, and Oblique lines. This is an example of a 'Step-by-Step'. This concept is explained in more detail below.
#Quiz - This activity launches the Quiz activity with a quiz on body parts (in French). Look for version 6 on activities.sugarlabs.org which will support this example. The current version 5 does not work.
#Memorize - This activity launches the Memorize activity with a bundle on Roman Numerals.
#Turtle Blocks (Turtle Art) - This activity launches Turtle Blocks in support of the first example.
#Wordsearch - This example launches the Wordsearch activity with a specific wordlist. This requires a modification to Wordsearch to be able to use a bundle when resumed from the Journal. This example does not work with Version 1 (It launches Wordsearch but the word list is the default sample).
#British Council - This activity does not launch a Sugar activity. It does show an example of having students read a short story with audio. This is one of a group of thirty-four stories which can be used in a deployment by arrangement with the British Council. These stories have one or more separate exercises in reading comprehension or vocabulary development which can also be used with Learn by arrangement with the British Council.

====Khan Academy====

This milestone has two activities:

#video - This activity plays the Basic Addition video by launching the Jukebox activity. Any Khan Academy video can be used with the Learn activity, currently after conversion to .ogv format. At École Saint Jacobs, the Mathematics subject in Term 2 has about a dozen of these videos covering basic arithmetic topics.
#exercises - Many Khan Academy videos are accompanied by exercises. This example runs the exercise associated with the Basic Addition video. This exercise is in a format which is no longer used on the Khan Academy site.

===Get Started===

The getstarted course has four milestones. Each milestone is a section from the 0.82 version of the Help activity (http://laptop.org/8.2.0/manual/). This illustrates how documentation can be made into Learn activities.

===Learn===

The learn course has three milestones. The first milestone describes the use of the Gnome desktop which may be installed on an XO in recent builds of the software. The next two milestones describe building courses and milestones. Much of this material is not applicable to this version of Learn, but does illustrate how courses can be constructed. These milestones were created using the tools in Learn.

===Lesson===

The lesson course has a single milestone with a single activity. This activity launches the ShowNTell activity to show a step-by-step method to create a new activity. This step-by-step is incomplete but illustrates the procedure. When using Learn to launch Sugar activities,

===Quiz===

The quiz course has three milestones which describe how to build a question bank using Moodle and how to create quiz activities using these questions. This procedure works, but seems too complex for routine use. It is likely that an alternative using a Django will be needed to simplify this process and make it more usable. The concept of an item or question bank is very important in the context of schools which are heavily involved in preparing students for national examinations.

===Library===

The library course describes how to use the Library activity to access the school's digital library. Since this
library is maintained on the schoos server, this capability is only available in a deployment. The three activities are examples of using ShowNTell to present a 'Step-by-Step' slide show.

==Student View==

===Main Screen===

[[Image:Student_main.png]]

This is the main screen as seen by a student. Notice that the Laboratory subject is not visible. Also the school button in the top right of the header has been replaced by an xo symbol. This button in a deployment will show the student a record of his achievements and act as a portfolio in the context of the Learn activity.

=== Milestone Ladder===

[[Image:Student_milestone_ladder.png]]

In the student view, a click on a classroom subject in the main screen shows the milestone ladder. At the start of the term, the first milestone has a yellow cap showing that this is the current milestone. A completed milestone has a green cap. Notice the second milestone has a blue cap. The Learn activity automatically downloads one or more milestones for the student automatically.

The deployment sets a quota and a minimum number of milestones. When a milestone is completed, if the next milestone and those after it that are shown with a blue cap are less than the miniumum, the next milestone in the ladder is loaded. If this exceeds the quota, the first milestone already completed is removed from the XO (and the cap shows as light green (chartreuse). This system allows automatic management of the XO store.

=== Activity Ladder===

[[Image:Student_activity_ladder.png]]

The activity ladder works in a similar way. A completed activity is shown with a green flag. The current activity is shown with a yellow flag. The activities to be done are shown in blue. The Learn activity downloads milestones and so all activities in the current milestone are on the XO.

===Activity===

[[Image:Student_activity.png]]

The activity view is unchanged; however, notice that the on the right-side of the header, the student does not have an edit button. Instead the student has a check mark button. WHen the student finishes an activity, he or she clicks on this button to continue to the next activity. This button runs a script which records the results from the activity in the Journal (an object shown with the Learn icon and a title of 'Attempt'.

In a deployment, the Journal is backed up to the school server. These objects are stored in a log folder and the information is later moved to a database. It is then made available to teachers and to the student when requested.

===Independent Study===

Many teachers organize their classes so that all students are working on the same lesson. In these classrooms,
the Learn activities are worked on in class for a specific period of time (e.g. for 20 minutes in a 45 minute period). Learn supports a course being designated for independent study mode (as described above), but this is optional. When a course is not in the independent study mode, the milestone and activity ladders work exactly as they do in the staff mode. However, the activity screen still shows a check mark button and the results of the activity can be recorded in the Journal.

==Managing Educational Content==
Within the Karma Learning System, the Learn activity delivers educational content stored on the school server. From one academic year to the next, this content needs to be updated based on the experience of the teachers in using the content, changes in the curriculum, and new resources that become available. Many schools divide the academic year into semesters or terms.

One strategy is to keep the current terms content in the main menu. Content from previous years or terms are kept as Resouces on the school server but not linked to the learning system. Content for the next term can be developed in a Laboratory subject visible only to the staff.

The reality is that in most deployments, the first task will be to develop a baseline of content sufficient for the academic year. This may take some years to accomplish. Once a baseline is reached, the Laboratory can be initialized from the Resources from previous terms. The focus of the staff will be on improving the courses and incorporating new material. Until that time, the focus will be on creating lessons based on turning paper lesson plans into computer-based lessons.

The Learn activity supports this process at the milestone level. Managing subjects and courses requires the efforts of an adminstrator with technical knowledge. This intervention is very important to manage the rotation of content between terms.

This document assumes that there ia a Laboratory subject and that the courses there are the ones needed in the next academic period.
===Creating Milestones===

[[Image:empty_course.png]]

This is the fourth grade English course for term 3 in the Laboratory subject (sje423).
The course is empty, there are no milestones in the ladder. A typical course for one term will have
about ten milestones.

====Adding the Milestone====

The teacher for this course can create a new milestone by clicking on the edit button to the right of
the header.

[[Image:Adding_a_milestone_1.png]]

The teacher clicked on the + button to add a milestone. The new milestone shows in the list.

====Adding a label and description====

The teacher clicked on the edit button for this milestone. The first
entry allows the creation of a label. It is in numerical sequence by default. However, the teacher
entered 3/9 to show that the milestone will be used in week one of the term which
starts on the third of September.

The second entry contains the description of
the milestone that shows up on the milestone ladder when the cursor hovers over the milestone icon.
The teacher clicks on the third entry ('done') to complete the changes.

====Done====

[[Image:Adding_a_milestone_2.png]]

Once the teacher is satisfied, he or she clicks on the green check mark to commit the changes. A click on the X cancels the changes. Note that this screen can also be used to delete a milestone and to rearrange the sequence of milestones (when there are more than one).

===Creating Activities===

[[Image:Course_with_milestone.png]]

Now the empty course has a milestone. Note the cap of the milestone is blue since the milestone is on the XO.
Next, the teacher clicks on the milestone. Naturally, this reveals an empty milestone with no activities on
the activity ladder.

[[Image:empty_activity_ladder.png]]

A typical milestone has sufficient activities so that a typical student will take a week to
complete it. If a teacher equates an activity to a lesson requiring one class period to complete, the number of activities is likely to be four to five. If the teacher expects some or most of the activities to be completed outside of class, this number can double. The guiding concept is that completing a milestone should represent achievement of an important learning objective. The number and nature of the activities should be proportional so that the student does not become discouraged. A milestone with forty activities would certainly be daunting!

[[Image:new_activity_1.png]]

To create an activity, as before, the teacher clicks on the edit button in the header. The difference is that
the teacher has a number of choices in the type of activity. In this case, the teacher selects t00 for a basic
activity. The other options will be described below.

[[Image:new_activity_2.png]]

In a similar way, the teacher assigns a label and description to the activity. In this case, the teacher has
labeled the activity as 'I' to show the type of activity, 'introduction'. As before when the teacher is satisfied, he or she clicks on the green check mark to commit the changes.

===Creating Basic Activities===

[[Image:activity_5.png]]

The teacher clicks on the activity.

[[Image:activity_6.png]]

This is the default activity created by the Learn activity. The teacher clicks on the edit button to
enter the edit mode [ckeditor].

===Using the Editor===

[[Image:editor_1.png]]

The default lesson is loaded into the editor. The buttons on the header to the right are:

#save - click on this button to save changes
#audio - add an audio track to the lesson - explained below
#image - add an image to the lesson - explained below
#quit - quit activity, not normally used in this context

The arrow to the left of the header leaves the edit mode and returns to the activity. If the user
returns to the activity before clicking on the save button, changes will be lost.

[[Image:editor_4.png]]

The editor is WYSIWYG (What you see is what you get). However, the actual appearance of the lesson will
differ because of the different style sheets applied. In addition, images are not shown in edit mode.

The editor has a toolbar with icons. Most of these icons are common to most editors. There are three
rows:

First row:
*Source - switches the view from WYSIWYG to the html view.
*Cut, copy, and paste are the first three icons in the second block.
*The rounded arrows in the next block are for 'undo' and 'do'.
*The two in the third block are 'find' and 'find and replace'.

The remaining icons in this row are not useful in this context.

Second row:
*The first block formats text: bold, italic, underline, and strike-through. The next two set the superscript and
subscript modes, respectively.
*The icons in the second block set numbered or bullet list modes, increase or decrease indent. Skipping two icons,
there are icons to control alignment: left, center, right, and justify.
*The fourth icon in the last block inserts a horizontal rule. This is used to mark the boundary between screens in a multiple-screen lesson. The next two insert special characters such as a smiley or a division symbol. The last two are not useful in this context.

Third row:
*'styles' selects a style to use, the ones available are not very useful in this context.
*'Format' defaults to normal text. However, use this list to select various style headers. For example,
the lesson title is normally Heading 1. Sub-title may be Heading 2 and so on.
*'Font' allows selection of a font to use. Changing font is not often needed in this context.
*'Size' allows a change in the font size. To change the font size, you must first 'select' the text to
apply the change to. Move the cursor to the left of the first character to be changed. Hold the left
mouse button down while moving the cursor along the line of text. The background of the text will turn dark to
show that the text is selected. Release the left mouse key when the correct text is selected. Now change the
font-size.
*The next two icons allow change to the text color and to the background color respectively. This works the
same way as 'font-size', you select the text and then select a color.

[[Image:editor_2.png]]

This image shows the beginning of the lesson. The title could be centered by using the center icon on the toolbar. Select the title as described above and click on the center-alignment icon. The A section title
could be a Heading 2. Select the text (including the A.) and click on the second list in the bottom row. A
list of formats appears, click on Heading 2.

[[Image:editor_3.png]]

The teacher has clicked on the 'save' icon (an image of a 'floppy drive') and then clicked on the right arrow
to return to the activity. The activity now shows the text entered in the editor.

===Adding Images===

[[Image:image_1.png]]

Clicking on the camera icon in the header will (after some moments) show this screen. It shows thumbnails of all
of the images available to be added to the lesson. In this case, these are the screen shots I used in
preparing this page.

The images are those found in the Journal plus any images in /home/olpc/Documents. In recent builds of Sugar,
this folder is visible in the Journal and acts like a mounted usb drive. This means that images obtained from
the internet, a digital camera or a mobile phone can be copied to a usb drive. When this drive is mounted, it will appear at the bottom of the Journal screen along with an icon for the /home/olpc/Downloads folder. By selecting the usb drive (or SD card) containing the images, the relevant ones can be dragged to the folder. Alternatively, the images can be dragged to the Journal. In either case, a thumbnail will appear on this screen.

[[Image:image_2.png]]

In this case, the middle image in the top row was selected (click on the thumbnail). This screen allows the teacher to specify the size and location of the image. The width of 600 represents one-half of the screen. The height of 450 gives a 4:3 aspect ratio.

The next entry specifies the screen on which the image will appear. In single-screen lessons this is, of course, 1.
In multi-screen lessons, the teacher might want a different image on each screen.

An entry of 1L specifies that the image should be at the top left of the screen. An entry of 1R specifies the right side. An entry of 1 specifies the image should be centered. When the image is on the left, text will appear to its right. If right is specified, text will appear to the left. When an image is centered, text will begin
below the image.

The teacher clicks on the OK entry to commit the change.

[[Image:image_3.png]]

This shows the image in the lesson. Since 1L was entered, the image is on the left with text to the right.
Note: images currently can only be located at the top of a screen and only one image can be on each screen.

===Adding Audio Clips===

Clipping on the microphone adds an audio clip to the lesson. It works the same way as the image icon
except that the user only needs to click on the correct audio clip since no location or size information is
needed.

A lesson with an audio clip shows a play button in the left-side of the footer. It is a toggle so that
when the audio is playing it shows a 'pause' symbol. The audio continues if play is pressed after a pause.
To restart the audio, it is necessary to go back to the activity ladder and select the activity again.

===Adding Questions===

An interactive quiz can easily be added to any lesson/activity.

[[Image:quiz_in_editor.png]]

The quiz is entered in edit mode using a special format developed by Moodle called 'gift'.

The questions are entered between the following lines:

/*Quiz

questions go here

/*

The word Quiz (capitol Q) must be entered after /* with no spaces. The '*/' is on a separate line. The questions are entered between these two lines separated by a blank line. Here are some example questions:
<pre>
/*Quiz
The Learn activity is part of the Karma Learning System.{T}

The OLPC laptop is often referred to by two letters. What are they? {=XO =xo}

There {=are} many people world-wide supporting the OLPC project. [is are]

One of these organizations is not related to the others. Which one? {=CIA ~OLPC ~Sugarlabs ~Red Hat}

*/
</pre>
The first question is True-False. Answers are shown between braces '{ }'. The answer to a True-False question may be any of T, t, True, true, F, f, False, false. Note that, unlike the other answers, an equal sign '=' is not needed.

The second question is short answer. Acceptable answers (one or more) are given between braces. In this case, XO and xo will be accepted as correct. Xo and xO would be considered incorrect.

The third question is a cloze. It is identical to the short answer except the braces are within the text. The student will see a blank (underlines) where the braces are entered along with a place to enter the answer.

The fourth question is multiple-choice. The choices are given between braces. The correct answer is indicated by the equal sign '='. The incorrect choices (distractors) are indicated by the tilde sign '~'.

The quiz is created when the lesson is saved.

[[Image:quiz question.png]]

When the student opens the lesson, there will be a 'Start' button shown on the bottom right of the screen. The screen gives information (e.g. a diagram) needed to answer the questions and/or instructions on answering the questions (e.g. round your answer to two decimal places).

When the student presses the Start button, he is given the questions one at a time in the order they appear in the lesson (not randomized).

This capability is based on the jquizme library.

===Using Karma Templates===

When creating an activity, the teacher can choose among a menu of activity types from t00 - a basic activity
to t20.

[[Image:new_activity_1.png]]

The activity types are:

#t00 Basic - a normal textbook-style lesson with optional images, audio, or quiz components.
#t01 Adding up to 10 - a Karma game which currently has no options for customization.
#t02 Crossword - a crossword puzzle to find a hidden word. A teacher can create a custom crossword puzzle.
#t03 Hangman - a traditional hangman. A teacher can provide the wordlist.
$t04 Identification - not currently usable
#t05 Mad-libs - A teacher can provide the clues and story.
#t06 Matching - a Karma implementation of Concentration. The teacher can provide the words and images.
#t07 Matching Pairs - a matching activity. The teacher can provide the list of matching words.
#t08 Multiple-choice sentence - multiple choices for words in the sentence (e.g. is/are). The teacher can supply the word choices and sentences.
#t09 Puzzle - rearrange pieces of a picture in alphabetical or numerical order to see the completed picture. The teacher can supply images.
#t10 Quick Arithmetic - student is challenged to provide sums mentally. Currently customizing is not supported.
#t11 Scrambled sentences - not operational
#t14 Vocabulary - not operational
#t15 Vocabulary with game - not operational
#t16 What is this? - matching images against words. The teacher can supply words and images (images not automated).
#t17 Anagram - rearrange letters to form a word naming an image. Teacher can supply words and images (images not automated).
#t18 Maths introduction - not operational
#t19 Maths guided practice - not operational
#t20 Maths evaluation - not operational

The best way to see how these activity types work is to go to the Laboratory and in any course add a milestone.
Then add activities selecting the various types. The result is an example of the activity type. By entering
the editmode, the source.txt file defining that activity is shown. It can be edited to make a custom version
that fits the milestone. For example, a crossword could be constructed using some words from the week's vocabulary list.

Most of these templates were created by Peter Gijsels in a visit to Rwanda in 2011. They illustrate how
activities can be created using the Karma library and html5 web techniques (css, javascript, jquery). It is intended that this library be expanded to include more useful educational activity types.

===Using Sugar Activities===

There is currently no automated support for creating these lessons. It requires some command-line knowledge.
When a lesson is opened in the edit mode, the file being edited is 'source.txt'. The first line of this file
contains a directive to launch a specific Sugar activity, e.g.,



For technical reasons, this line appears in the edit mode as:

/*B:TurtleArt,lines_lesson.ta,application/x-turtle-art*/

The source.txt file uses html5 markup in which  enclose a comment. As a result, this line is
not visible in the editor. By converting the markup to /* */, the user can create and edit this line.

The B: is required to signal this comment contains a directive. There are three parts to the directive separated by commas:

#name of the Sugar activity. This is the same as the name in /home/olpc/Activities minus the activity.
So Turtle Art (Blocks) appears as /home/olpc/Activities/TurtleArt.activity.
#file name of the activity bundle (lines_lesson.ta) including the file extension. This bundle must be in
the folder for this lesson in Learn.
#mime_type of the bundle. The mime_type of a bundle is given in /home/olpc/Activities/TurtleArt.activity/activity/activity.info. For 'some.activity', look in /home/olpc/Activities/some.activity/activity/activity.info.

A Sugar activity can be launched as a new start by:

/*B:some.activity*/

The Learn.activity creates a Journal object with the bundle file as data. It then resumes the activity from this Journal object.

Note that not all activities are able to resume from a Journal object and not all activities support processing data files.

The user needs to quit the launched activity when finished to return to the Learn activity. Sugar treats the launched activity as a window opened by Learn and so gets confused if the user tries to return to Learn via the frame.

==Integration in the Karma Learning System==

When Learn is used with a school server as part of the Karma Learning System, the subjects, courses, milestones, and activities are stored on the school server. Students are assigned laptops by the school so that KLS knows the grade level of each student (and the staff status of members of the staff). Learn on the first launch downloads the content needed to start for students based on their grade. Staff see a milestone ladder where the cap may be blue as seen in the screenshots above or a light blue (cyan). Milestones with a cyan cap are not downloaded to the laptop. A click on the milestones causes the milestone to be downloaded. In this way teachers can look at and edit any activity.

As part of KLS, Learn stores the results of each activity in the Journal. When the laptop connects with the schoolserver, a backup script uploads new journal entries to the school server. Journal entries which produced documents are uploaded to the Journal. Other entries are uploaded to the log.

In KLS, the Journal is kept on the school server. The laptop has some, but not all of the entries. This offers three advantages: (1) if storage becomes full on the laptop, deleting Journal entries only deletes the local copy. The Journal item is still available when needed, (2) if a laptop becomes unusable, the student can begin working with a different one retaining full access to his Journal from the previous laptop, and (3) there are no 'empty' Journal entries with titles of xyz.activity. The user must supply a meaningful name for each Journal entry.

KLS provides the teacher with access to a class list. For each student, the list shows the current status of that student in each course (the milestone and activity last completed). The teacher can 'drill down' by clicking on the status - to see a complete list of milestones and activities completed. Click on a milestone and activity shows the number of attempts, total time spent, the result, and any other details such as questions and answers to quizzes. This information is derived from the students Journal and log stored on the school server.

As a part of KLS, Learn provides download of milestones from the school server. Milestones and activities modified by the teacher may be uploaded to the school server and, thus, become available to students. If the student has already downloaded a milestone, he or she won't see the change. A reset button is provided on the header of the activity ladder for the milestone which will delete the local copy and download the updated copy.