Re: [Sugar-devel] wiki problems

[Tony Anderson]

Hi, Sam

Thanks for the help. I also discovered that 'edit source' works.

The recaptcha thing is probably their problem unless wikimedia or 
sugarlabs types the challenge text. I didn't really research it. The 
challenge is connected
to adding an external link. I suspect you could create it with a simple 
page just linking to google.


Tony

On 02/21/2016 02:59 PM, Sam P. wrote:

Hi Tony,

The freedom issue is related to the Visual Editor function of 
mediawiki.  Try using the edit source temporally, I will try and find 
what is wrong in the mean time.


I'm not sure about the recapatcha though.  Maybe it is a mixed content 
issue.  Is there anything in your browsers console log (the inspect 
element thing)?


Thanks,
Sam

On Sun, Feb 21, 2016 at 5:42 PM Tony Anderson > wrote:


Hi,

I am trying to edit https://wiki.sugarlabs.org/go/Translation_Proposal
which I created earlier today.

I am logged in but get the message: Error loading data from server:
parsoidserver-http-curl-error: Failed to connect to
freedom.sugarlabs.org  port 8001:
Connection refused: . Would you like to
retry?

Amusingly, when I saved the page I got a recaptcha asking for me
to type
the two words shown 'in the box below'. The only two words in the
box were
'Privacy & Terms'. However, it turns out the recaptcha wanted a house
number shown on a door.

Tony
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org

http://lists.sugarlabs.org/listinfo/sugar-devel



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] wiki problems

[Sam P.]

Hi Tony,

The freedom issue is related to the Visual Editor function of mediawiki.
Try using the edit source temporally, I will try and find what is wrong in
the mean time.

I'm not sure about the recapatcha though.  Maybe it is a mixed content
issue.  Is there anything in your browsers console log (the inspect element
thing)?

Thanks,
Sam

On Sun, Feb 21, 2016 at 5:42 PM Tony Anderson  wrote:

> Hi,
>
> I am trying to edit https://wiki.sugarlabs.org/go/Translation_Proposal
> which I created earlier today.
>
> I am logged in but get the message: Error loading data from server:
> parsoidserver-http-curl-error: Failed to connect to
> freedom.sugarlabs.org port 8001: Connection refused: . Would you like to
> retry?
>
> Amusingly, when I saved the page I got a recaptcha asking for me to type
> the two words shown 'in the box below'. The only two words in the box were
> 'Privacy & Terms'. However, it turns out the recaptcha wanted a house
> number shown on a door.
>
> Tony
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] wiki problems

[Tony Anderson]

Hi,

I am trying to edit https://wiki.sugarlabs.org/go/Translation_Proposal 
which I created earlier today.


I am logged in but get the message: Error loading data from server: 
parsoidserver-http-curl-error: Failed to connect to 
freedom.sugarlabs.org port 8001: Connection refused: . Would you like to 
retry?


Amusingly, when I saved the page I got a recaptcha asking for me to type 
the two words shown 'in the box below'. The only two words in the box were
'Privacy & Terms'. However, it turns out the recaptcha wanted a house 
number shown on a door.


Tony
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GSoC proposal status

[Tony Anderson]

Hi, Sam

Thanks for your comments. These issues need review and comment within 
the community.


"Just my 2c, but this complicates the experience a lot.  Do we show this 
temp journal entry to the user?  If so, wouldn't that be confusing?  But 
it we hide it, it becomes more complex.  Eg, a user is adding the 
finishing touches to a diagram in Paint, and adds it to Write activity, 
however since only the old version is visible they don't see the image 
they expected, and become confused.  Maybe this could be better served 
by basic git features in the journal, one of Martin's project ideas I 
believe."


What I suggest does not change the user's experience of the Journal.

When an activity is launched, it runs as activity.py. If an activity is 
resumed (associated with a data file in the Journal), activity.py loads 
that Journal object. This is the object that is saved when the activity 
terminates. What I am suggesting is that
activity.py should load a copy of the Journal object (which naturally 
does not exist in the Journal until saved). This enables the activity to 
make a decision to

overwrite the original object or to save a new object.

You may have noticed this in the Journal. When you resume and then save, 
that object is now the most recent and no longer appears in its original 
chronological position. This reflects that the original journal object 
is saved back to the Journal (normally, by write_file)


The scenario you describe: using Paint and then saving to Write is 
intermediated by the Journal. Paint saves the modified image to the 
Journal. The Write activity then adds it to its document. There should 
be no confusion. Assuming the user gave the image a new name, causing a 
new object to be saved or the user saved in the same name, replacing the 
object in the Journal. If the user has doubt, as at present, he/she 
should run Image Viewer to see the image.


I really don't see git as relevant to the Journal. The proven technique 
of using file names to distinguish objects is easier to implement and 
familiar to experienced computer users. There is nothing to prevent a 
user from using classproject.1, classproject.2,  to distinguish 
versions.


"Browse save files work fine cross network connections.  I made one at 
home, and opening it at school I was able to show people all of my tabs."


This worked because in both cases you are connected to the internet. 
Browse is saving urls. Had you opened Browse without a connection, you 
would have received an error. In last year's GSOC, Richa Sehgal added a 
capability to save an html page explicitly but this capability has not 
yet been integrated with Browse.


"Using the metadata is also much harder, it is so easy to just chuck the 
json in there.  Even if we use metadata for eg, saving memorize, the 
metadata will be so activity specific that it is hard to use in a 
reflection tool.  I'm not sure what you want by this."


I am trying to distinguish saving documents from saving state. Memorize 
needs to save state so that a user can resume a game. Naturally, state 
information is specific to the activity. However, it can be saved in the 
metadata record (saved in the Journal as a file). When resumed, Memorize 
can restore its state. Saving the state information as a document 
requires that it have a mime_type. This type would need to be unique to 
Memorize since no other activity would know how to process it (e.g. if 
it were saved as application/plain-text).


As I understand reflection, the goal is to enable a user to look back at 
documents they created or worked on collaboratively. The Journal offers 
two impediments to that - clutter from non document-creating activities 
and the necessity to erase documents due to limited storage capacity. I 
think we need to distinguish between statistical analysis of a user's 
activities (the NSA use of metadata) and using the Journal to show the 
user a record of their own educational journey.



"I have to agree with you here.  Having a kind of seamless journal that 
exists partially locally and fully on the school server would be nice.  
But can a person designing this amuse that the user will have school 
server access most of the time?"


The design is to invoke a backup service when the XO connects to the 
school server. This service recognizes objects which have been modified 
or which are new and saves the associated documents to the server-based 
store. Currently, I use a modified ds_backup.py to save to the /users 
directory on the school server (by serial number of the XO). This 
program operates using datastore as the input. The suggestion of using 
OwnCloud would make the files on the school server visible to the student.


"How do you it fulfilling that need?  Are we exposing the owncloud web 
interface to children?  I pictured a seemless journal interface that 
merged the online storage and the local into one and provided means for 
pinning things locally.  I however picture the 

Re: [Sugar-devel] Translations

[Nick Doiron]

Hi everyone... I'm in the Unicode Consortium so I'm happy to help work out
i18n tech issues in our Sugary ecosystem.

On the original point, I agree with Tony that it would be valuable to hire
an i18n/l10n point person. This funding has been around for a while without
any one person responsible for shipping it. You might want additional
support or conversation, from Open Technology Fund, Localization Lab, or
Adobe, for the position and workshops.
I'd like to see some people narrowing down where they know we need a
translation. If you can say *I know a teacher who wants this *or* we use
this activity in Language A and want it in Language B, *we should be able
to deliver that.  There are interesting politics and discussions here, but
the funding is for translating and not for not-translating.

Technology side: it matters if you're translating Sugar, core Sugar
activities, additional activities, or Sugarizer. This is essential because
they're different programs at different levels of completeness, in use by
different people.
- Sugar and core activities have been ready from the beginning using
gettext and accepting translations on Pootle. I don't see that changing,
unless we want to use GitHub to reach younger developers.
- Additional activities: you would need to look on a case-by-case basis, to
see if text was hardcoded. Also you need special attention if language is
part of the activity, as in typing tutors, flipbooks, or crossword puzzles.
Tangential blog post:
https://medium.com/@mapmeld/crosswords-in-burmese-f672ae583649
- I did some research, and Sugarizer has three translation files, including
this master file: https://github.com/llaske/sugarizer/blob/master/locale.ini
Other web-based activities should use Polyglot.js from Airbnb; it's cool.

Nick

On Sat, Feb 20, 2016 at 2:57 PM, Caryl Bigenho  wrote:

> Hi Folks
>
>
> Here are some thoughts on Internationalization and Localization...
>
>
> 1) 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.
>
>
> 2) 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.
>
>
> 3) 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.
>
>
> 4) 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.
>
>
> 5) 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
> --
> Date: Sat, 20 Feb 2016 14:44:28 -0500
> Subject: Re: Translations
> From: s...@unleashkids.org
> To: h...@laptop.org
> CC: tony_ander...@usa.net; t...@timmoody.com; ndoi...@mapmeld.com;
> ca...@laptop.org; sve...@sfsu.edu; sugar-devel@lists.sugarlabs.org;
> localizat...@lists.laptop.org; wal...@sugarlabs.org;
> sl...@lists.sugarlabs.org
>
>
> 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.
>
> 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."'
>
>
>
> On Sat, Feb 20, 2016 at 7:51 AM, Adam Holt  

Re: [Sugar-devel] [SLOBS] [Localization] Translations

[Chris Leonard]

For javascript L10n, start with these links:

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/

cjl

On Sat, Feb 20, 2016 at 7:14 PM, Walter Bender  wrote:
> Another hole in the i18n infrastructure is with our Javascript activities.
> Maybe worth a GSOC project to shore it up.
>
> On Feb 20, 2016 3:58 PM, "Chris Leonard"  wrote:
>>
>> Comments included in-line below
>>
>> On Sat, Feb 20, 2016 at 3:35 AM, Tony Anderson 
>> wrote:
>> > As I understand the issue: SugarLabs has some funds available to support
>> > translation of Sugar. At the SLOBs meeting, it was proposed that
>> > SugarLabs recruit a 'translation manager', a possibly paid position. One
>> > question is the job description for this role.
>>
>> 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).
>>
>>
>> > I would like to review the translation process:
>> >
>> > 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.
>>
>> 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.
>>
>> 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.
>>
>> > The immediate focus is on using Pootle as the I18n framework with
>> > translators providing the localization.
>> >
>> > Let's divide the languages into three groups:
>> >
>> > - English (the base language)
>> >
>> > - 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)
>>
>> 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 

Re: [Sugar-devel] [SLOBS] [Localization] Translations

[Walter Bender]

Another hole in the i18n infrastructure is with our Javascript activities.
Maybe worth a GSOC project to shore it up.
On Feb 20, 2016 3:58 PM, "Chris Leonard"  wrote:

> Comments included in-line below
>
> On Sat, Feb 20, 2016 at 3:35 AM, Tony Anderson 
> wrote:
> > As I understand the issue: SugarLabs has some funds available to support
> > translation of Sugar. At the SLOBs meeting, it was proposed that
> > SugarLabs recruit a 'translation manager', a possibly paid position. One
> > question is the job description for this role.
>
> 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).
>
>
> > I would like to review the translation process:
> >
> > 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.
>
> 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.
>
> 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.
>
> > The immediate focus is on using Pootle as the I18n framework with
> > translators providing the localization.
> >
> > Let's divide the languages into three groups:
> >
> > - English (the base language)
> >
> > - 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)
>
> 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 

Re: [Sugar-devel] [Localization] Translations

[Chris Leonard]

Comments included in-line below

On Sat, Feb 20, 2016 at 3:35 AM, Tony Anderson  wrote:
> As I understand the issue: SugarLabs has some funds available to support
> translation of Sugar. At the SLOBs meeting, it was proposed that
> SugarLabs recruit a 'translation manager', a possibly paid position. One
> question is the job description for this role.

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).


> I would like to review the translation process:
>
> 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.

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.

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.

> The immediate focus is on using Pootle as the I18n framework with
> translators providing the localization.
>
> Let's divide the languages into three groups:
>
> - English (the base language)
>
> - 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)

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.

> 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.

Actually, POT template files (Pootle English master files) 

Re: [Sugar-devel] GSoC proposal status

[Lionel Laské]

Hi all,

Just added a bunch of Sugarizer projects on the page:
http://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugarizer

If some of you are interested to be co-mentor on these projects, do not
hesitate to add your name.

Best regards from France.

   Lionel.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GSoC proposal status

[Sam P.]

On Sat, Feb 20, 2016 at 6:00 PM Tony Anderson  wrote:

> Hi, Walter
>
> I have some concerns about the proposed GSOC tasks as well as some ideas
> for new tasks.
>
> I agree that the Journal needs rethinking. Below are my thoughts
> (re-thoughts?).
>
> Specifically,
>
> The Journal is the file system for Sugar. It does not use directories but
> instead was intended to collect objects by tag (a la Picasa). Currently,
> the user sees
> a scrolled list of objects in chronological order. However, selection is
> by activity or media type, not by a user defined criteria (as represented
> in other systems by the directory).
>
> The Journal acts as an activity with awkward consequences for the user. On
> the keyboard, the icon for the Journal (a magnifying glass or search icon -
> not the icon shown in the frame) is to the left of the zoom group on the
> keyboard and to the right on the frame. If the Journal is selected, it
> replaces the current activity when the activity key is pressed. It also
> appears as an activity when using alt-tab. The first makes using
> screenshots awkward. Screenshots are given a title by the system of
> 'Screenshot of '. The user needs to switch to the Journal to provide a
> meaningful name. However, the user must open the frame and click on the
> activity icon to return to it. If the Journal were viewed as a Sugar
> service, the activity key would return the user to make another screen shot
> or continue whatever the task is. Similarly, it is convenient to present
> the user with instructions to perform a task using a Sugar activity (e.g.
> Write). The instructions can be given by a web page or by a document in a
> different activity. For example, a user could show a flag as an image in
> Image Viewer and try to duplicate the flag with TurtleBlocks. However,
> using alt-tab to switch between the activities requires cycling through the
> irrelevant Journal activity or open the frame to click on the activity icon.
>
> More importantly, when a Journal object is launched from the Journal
> activity, it is immediately loaded into activity.py. Therefore, any
> subsequent action by the user will be saved and the previous object will be
> overwritten. Suppose I resume the Paint Activity to continue making a
> picture. However, I decide that after some strokes, the original picture
> was better. There is nothing as a user I can do to revert to the original.
> I suspect the reference to git may be intended to address this problem.
> When an object is launched, activity.py should make a clone. The user
> should then have the option to revert to the original or to overwrite it or
> to change it's name so that a new object is created alongside the original.
> I believe an implementation of the 'save/save as' logic of virtually all
> other systems should be provided.
>

Just my 2c, but this complicates the experience a lot.  Do we show this
temp journal entry to the user?  If so, wouldn't that be confusing?  But it
we hide it, it becomes more complex.  Eg, a user is adding the finishing
touches to a diagram in Paint, and adds it to Write activity, however since
only the old version is visible they don't see the image they expected, and
become confused.  Maybe this could be better served by basic git features
in the journal, one of Martin's project ideas I believe.


>
> Probably, in the interests of 'reflection' or possibly statistical data,
> the Journal saves every activity instance - by default with the name of the
> activity. Further,
> most activities now implement write_file to create a data file associated
> with the object. This creates clutter in the Journal and takes storage for
> meaningless data files. For example, the Browse activity saves a data file
> containing URLs of open tabs. Aside from the fact that this creates
> spurious error messages if Browse is opened in a different network
> environment, it creates the unnecessary need to save a data file. I believe
> that activities should only save a data file if the user supplies a name
> for it and that activities should save state in the metadata, not in a data
> file. Naturally, it may be desirable for Memorize to save its state so the
> user can resume the game - this can be done by a field in the metadata.
> However, when the Paint Activity saves a file, it is reasonable to assume
> it contains an image (usable, for example, by the Image Viewer).
>

Browse save files work fine cross network connections.  I made one at home,
and opening it at school I was able to show people all of my tabs.

Using the metadata is also much harder, it is so easy to just chuck the
json in there.  Even if we use metadata for eg, saving memorize, the
metadata will be so activity specific that it is hard to use in a
reflection tool.  I'm not sure what you want by this.


>
> The XO has limited storage capacity. A freshly installed XO-1 image leaves
> about 300MB free space. A freshly installed image on other models with 4GB

Re: [Sugar-devel] Translations

[Sora Edwards-Thro]

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.

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."'



On Sat, Feb 20, 2016 at 7:51 AM, Adam Holt  wrote:

> Excellent food for thought Tony!
>
> +Sora, Tim, Nick, Caryl to see if they have ideas/suggestions below?
> On Feb 20, 2016 3:35 AM, "Tony Anderson"  wrote:
>
>> As I understand the issue: SugarLabs has some funds available to support
>> translation of Sugar. At the SLOBs meeting, it was proposed that
>> SugarLabs recruit a 'translation manager', a possibly paid position. One
>> question is the job description for this role.
>>
>> I would like to review the translation process:
>>
>> 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 immediate focus is on using Pootle as the I18n framework with
>> translators providing the localization.
>>
>> Let's divide the languages into three groups:
>>
>> - English (the base language)
>>
>> - 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)
>>
>> 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.
>>
>> 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.
>>
>> 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. Some would
>> seem to be a given - Cambodian.
>>
>> 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 be included in the Sugar image.
>>
>> 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 

Re: [Sugar-devel] Download Manager ProgressBar [DESIGN]

[Utkarsh Tiwari]

Hello everyone,
  I finally managed to pull through 50% of the
downloadManagerIcon integration task. Here is the gif of all what I did
till now -> http://imgur.com/zS0W9dG
There is still a long way to go. Reviews on this would be helpful :)

regards,
Utkarsh Tiwari



On Sat, Feb 13, 2016 at 8:36 PM, Utkarsh Tiwari 
wrote:

> I need to update a toolbutton in webtoolbar as the download progresses
> in background. Could anyone please guide me how to go about it?
>
> On 2/11/16, Utkarsh Tiwari  wrote:
> > @James As mentioned, I tried making a blend of 'progressIcon' &
> > 'ToolButton' by making some changes to the SugarToolButton code. Here is
> > how the download ProgressIcon @50% completion looks like ->
> > http://imgur.com/iBg4Ktr
> >
> > Waiting for your reviews :)
> >
> > On Thu, Feb 11, 2016 at 3:28 PM, Sam P.  wrote:
> >
> >> Hello,
> >>
> >> I believe that it passes all the key word and normal arguments to the
> >> superclass constructors.
> >>
> >> Out of interest, why are you using a Gtk drawing area as an additional
> >> base class?  Every widget (even the tool button) has the draw signal.
> Is
> >> this what you are using it for or is there something else?
> >>
> >> Thanks,
> >> Sam
> >>
> >> On Thu, Feb 11, 2016, 09:03 Utkarsh Tiwari 
> >> wrote:
> >>
> >>> What does the line "GObject.GObject.__init__(self, **kwargs)" exactly
> >>> does in the following gist?
> >>>
> >>> https://gist.github.com/iamutkarshtiwari/5024762d0e8924b52085
> >>>
> >>> On Thu, Feb 4, 2016 at 5:00 AM, James Cameron 
> wrote:
> >>>
>  Thanks.  Yes, the position is as I described.
> 
>  Your question puzzles me.  I didn't think there was any ambiguity or
>  doubt.  It is unfortunate that I'm the only one who has posted about
>  the positioning of this design change.
> 
>  Is it because you have an alternate suggestion?
> 
>  Good to hear combining the widgets worked.  Looking forward to seeing
>  a patch or pull request.
> 
>  On Thu, Feb 04, 2016 at 03:49:54AM +0530, Utkarsh Tiwari wrote:
>  > @James Is this the icon position you were talking about as shown in
>  > the
>  > attachment below? Your hint for using ProgressIcon alongwith
>  Toolbutton worked!
>  > ;)
>  >
>  > On Tue, Feb 2, 2016 at 2:17 AM, James Cameron <[1]qu...@laptop.org>
>  wrote:
>  >
>  > A ToolButton normally has an Icon.
>  >
>  > Instead of the Icon, assign the ProgressIcon?
>  >
>  > As nobody else may have done this, you may need to find and fix
>  > any
>  > bugs in ProgressIcon or ToolButton that prevent it.
>  >
>  > On Mon, Feb 01, 2016 at 11:31:28PM +0530, Utkarsh Tiwari wrote:
>  > > Is there any way to use a ProgressIcon as a Toolbutton ?
>  > >
>  > > On 2/1/16, Sam P.  wrote:
>  > > > Hello!
>  > > >
>  > > > Maybe just a large down arrow and fill it vertically?  See
>  > > > 'emblem-downloads' or 'transfer-from' in sugar-artwork.
>  > > >
>  > > > Thanks,
>  > > > Sam
>  > > >
>  > > >
>  > > > On Mon, Feb 1, 2016 at 9:15 AM, Utkarsh Tiwari <[2]
>  > iamutkarshtiw...@gmail.com>
>  > > > wrote:
>  > > >
>  > > >> How should the Icon for "Download Button" look like? Could
>  you please
>  > > >> provide me some artwork for reference. ?
>  > > >>
>  > > >> On 2/1/16, Utkarsh Tiwari <[3]iamutkarshtiw...@gmail.com>
>  wrote:
>  > > >> > Omg! I have been looking all over internet on how to
>  integrate a
>  > > >> > Gtk.ProgressBar into Gtk.Toolbutton and I even tried
> using
>  > > >> > Gtk.CssProvider styler to scale down the progressbar to a
>  button :D
>  > > >> > Now that(ProgressIcon.py) sounds really cool!
>  > > >> >
>  > > >> > Thank you :) You made my work a bit easier ;)
>  > > >> >
>  > > >> > On 2/1/16, James Cameron <[4]qu...@laptop.org> wrote:
>  > > >> >> ProgressBar from Gtk is overkill, we already have a
>  ProgressIcon
>  > > >> >> in Sugar.
>  > > >> >>
>  > > >> >> In sugar-toolkit-gtk3:
>  > > >> >>
>  > > >> >> Look at progressicon.py, you will see it does not use a
>  > ProgressBar,
>  > > >> >> but has a __draw_cb method connected to the "draw"
>  > signal.
>  > > >> >>
>  > > >> >> Look at toolbutton.py, you will see it wraps ToolButton
>  do_draw
>  > > >> >> method.
>  > > >> >>
>  > > >> >> On Mon, Feb 01, 2016 at 12:10:25AM +0530, Utkarsh Tiwari
>  wrote:
>  > > >> >>> "The button to be a blend of ProgressIcon and
>  ToolButton". How to
>  > > >> 

Re: [Sugar-devel] GSoC proposal status

[Walter Bender]

I added a section "Sugar on the Ground". I left out the "not Sugar"
projects: flashing XOs, anti-theft. I added a few of the more controversial
UI proposals, but they merit discussion. IMHO, we made a mistake when we
removed the obligatory "commit message" when exiting activities.

-walter

On Sat, Feb 20, 2016 at 2:14 AM, Walter Bender 
wrote:

> Thanks Tony. I'll give this a careful read in the AM. I'm at the end of my
> productive energy level at the moment.
>
> -walter
>
> On Sat, Feb 20, 2016 at 2:00 AM, Tony Anderson 
> wrote:
>
>> Hi, Walter
>>
>> I have some concerns about the proposed GSOC tasks as well as some ideas
>> for new tasks.
>>
>> I agree that the Journal needs rethinking. Below are my thoughts
>> (re-thoughts?).
>>
>> Specifically,
>>
>> The Journal is the file system for Sugar. It does not use directories but
>> instead was intended to collect objects by tag (a la Picasa). Currently,
>> the user sees
>> a scrolled list of objects in chronological order. However, selection is
>> by activity or media type, not by a user defined criteria (as represented
>> in other systems by the directory).
>>
>> The Journal acts as an activity with awkward consequences for the user.
>> On the keyboard, the icon for the Journal (a magnifying glass or search
>> icon - not the icon shown in the frame) is to the left of the zoom group on
>> the keyboard and to the right on the frame. If the Journal is selected, it
>> replaces the current activity when the activity key is pressed. It also
>> appears as an activity when using alt-tab. The first makes using
>> screenshots awkward. Screenshots are given a title by the system of
>> 'Screenshot of '. The user needs to switch to the Journal to provide a
>> meaningful name. However, the user must open the frame and click on the
>> activity icon to return to it. If the Journal were viewed as a Sugar
>> service, the activity key would return the user to make another screen shot
>> or continue whatever the task is. Similarly, it is convenient to present
>> the user with instructions to perform a task using a Sugar activity (e.g.
>> Write). The instructions can be given by a web page or by a document in a
>> different activity. For example, a user could show a flag as an image in
>> Image Viewer and try to duplicate the flag with TurtleBlocks. However,
>> using alt-tab to switch between the activities requires cycling through the
>> irrelevant Journal activity or open the frame to click on the activity icon.
>>
>> More importantly, when a Journal object is launched from the Journal
>> activity, it is immediately loaded into activity.py. Therefore, any
>> subsequent action by the user will be saved and the previous object will be
>> overwritten. Suppose I resume the Paint Activity to continue making a
>> picture. However, I decide that after some strokes, the original picture
>> was better. There is nothing as a user I can do to revert to the original.
>> I suspect the reference to git may be intended to address this problem.
>> When an object is launched, activity.py should make a clone. The user
>> should then have the option to revert to the original or to overwrite it or
>> to change it's name so that a new object is created alongside the original.
>> I believe an implementation of the 'save/save as' logic of virtually all
>> other systems should be provided.
>>
>> Probably, in the interests of 'reflection' or possibly statistical data,
>> the Journal saves every activity instance - by default with the name of the
>> activity. Further,
>> most activities now implement write_file to create a data file associated
>> with the object. This creates clutter in the Journal and takes storage for
>> meaningless data files. For example, the Browse activity saves a data file
>> containing URLs of open tabs. Aside from the fact that this creates
>> spurious error messages if Browse is opened in a different network
>> environment, it creates the unnecessary need to save a data file. I believe
>> that activities should only save a data file if the user supplies a name
>> for it and that activities should save state in the metadata, not in a data
>> file. Naturally, it may be desirable for Memorize to save its state so the
>> user can resume the game - this can be done by a field in the metadata.
>> However, when the Paint Activity saves a file, it is reasonable to assume
>> it contains an image (usable, for example, by the Image Viewer).
>>
>> The XO has limited storage capacity. A freshly installed XO-1 image
>> leaves about 300MB free space. A freshly installed image on other models
>> with 4GB capacity leaves 1.9GB free space. Today, it is almost impossible
>> to buy a USB stick with 2GB storage or less. When the available storage is
>> less than 50MB, the user sees a modal dialog saying the Journal is full
>> with the only option to look at the Journal. The Journal activity shows the
>> amount of available storage which 

Re: [Sugar-devel] Translations

[Gonzalo Odiard]

>
>
> Meanwhile, being on the other side of the world, I have not made progress
> on getting a committee to help put their two cents in on this. Clearly,
> this scenario must be reviewed for Floss Manuals, Sugarizer, and other
> SugarLabs products which don't fit in this one. Also, how to provide
> localization of IIAB-2 content is, at least, a formidable question.
>
>
The updated manuals are no longer in FOSS manuals, but in the Help
activity,
and are published in help.sugarlabs.org.
Have a process to translate them, and are already translated to Spanish.

Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Translations

[Adam Holt]

Excellent food for thought Tony!

+Sora, Tim, Nick, Caryl to see if they have ideas/suggestions below?
On Feb 20, 2016 3:35 AM, "Tony Anderson"  wrote:

> As I understand the issue: SugarLabs has some funds available to support
> translation of Sugar. At the SLOBs meeting, it was proposed that
> SugarLabs recruit a 'translation manager', a possibly paid position. One
> question is the job description for this role.
>
> I would like to review the translation process:
>
> 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 immediate focus is on using Pootle as the I18n framework with
> translators providing the localization.
>
> Let's divide the languages into three groups:
>
> - English (the base language)
>
> - 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)
>
> 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.
>
> 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.
>
> 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. Some would
> seem to be a given - Cambodian.
>
> 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 be included in the Sugar image.
>
> 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.
>
> Meanwhile, being on the other side of the world, I have not made progress
> on getting a committee to help put their two cents in on this. Clearly,
> this scenario must be reviewed for Floss Manuals, Sugarizer, and other
> SugarLabs products which don't fit in this one. Also, how to provide
> localization of IIAB-2 content is, at least, a formidable question.
>
> Tony
>
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Translations

[Tony Anderson]

As I understand the issue: SugarLabs has some funds available to support 
translation of Sugar. At the SLOBs meeting, it was proposed that
SugarLabs recruit a 'translation manager', a possibly paid position. One 
question is the job description for this role.


I would like to review the translation process:

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 immediate focus is on using Pootle as the I18n framework with 
translators providing the localization.


Let's divide the languages into three groups:

- English (the base language)

- 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)

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.


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.


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. Some would

seem to be a given - Cambodian.

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 be included in the Sugar image.


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.


Meanwhile, being on the other side of the world, I have not made 
progress on getting a committee to help put their two cents in on this. 
Clearly, this scenario must be reviewed for Floss Manuals, Sugarizer, 
and other SugarLabs products which don't fit in this one. Also, how to 
provide localization of IIAB-2 content is, at least, a formidable question.


Tony


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel