[Sur] [Localization] TamTam activity Spanish locales
cjlhomeaddress en gmail.com
Vie Jul 1 14:28:47 EDT 2011
On Fri, Jul 1, 2011 at 1:47 PM, Alexandro Colorado <jza en openoffice.org> wrote:
> Actually I am more on Caryl side here. English is for better or worst a very
> vage language, not as much as japanese, but is actually hard to get
> addaptations for instruments that are also not very clear. French would be
> more strict language and more similar to Spanish, Italian, Portuguese etc.
> Example is the chimes itself, for spanish you will need to add more specific
> qualifications to get it right "tubular bells/campanas tubulares" to
> actually get the specific instrument.
In any localization effort, familiarization with the context of the
string to be translated is critical. It is very much to be hoped that
SOAS5 will assist in this task as it should be a welcome advancement
on earlier versions of SOAS, all of which (along with sugar packaging
in Linux distros) give localizers the opportunity to work with the
Activity before trying to localize it (without necessarily having XO
Being an auditory driven Activity, this is particularly important with
the TamTam suite as no textual representation will ever be as complete
as hearing with one's own ears. In contrast, I think the changes made
to add ASCII-art representation of the smileys to Chat (and some
familarity with emerging online abbreviation practices in texting ,
etc.) will probably suffice to provide sufficient context for
localization from the PO file alone.
> However the POs are different from language to languge: string number 159 in
> spanish is "Slap / Bofetada" while in Italian and French is "Band one gain".
> So here is another thing to consider when doing cross language queries.
> More to the point, I did a search on this and couldnt find "Slap" on any of
> the FR, IT POs.
Unfortunately the TamTam suite has suffered something of an incomplete
migration from it's former home on dev.laptop.org to
git.sugarlabs.org, particularly with regard to the git-Poolte
interactions involved in updating and committing. We are in the
process of trying to straighten out these issues that unfortunately
make PO file synchronization to Templates (particularly with certain
Honey activities like TamTam) somewhat problematic at the moment..
> Is a good idea but also a huge task that is out of the scope of improving
> the activity itself. I would go the other way and is to try to idenfity
> expert sites (community googling) and index them to create a glossary or
> terminology that is more focused on the muscial lingo. As developers the
> learning curve to document musical instruments is larger than to focus on
> the localization itself.
> Maybe asking around CEIBAL we can get some music teachers interested in
> participating with us.
There is no question that outreach to local communities of practice
(e.g. music teachers) will result in better localizations and better
ways to use the activities in an educational context and I encourage
you to pursue that in the Spanish-speaking community. From my
perspective, I am looking at what can be done to improve i18n and the
L10n experience for all of the over 100 languages that we host. While
using Italian names as msgids may work for the Romance language
localizers, I suspect this would be a big step backward for the many
localizers into non-European languages, we do not want to require a
degree in Music Education to locaize these strings, but *where
possible*, music educators should be engaged to improve them. Spanish
is clearly important and the L10n can be enhanced by the sort of
outreach to established deployment organizations like Ceibal that you
suggest, but we need solutions that are scalable across all of our
languages, which is what I was seeking to do by adding the Wikipedia
links in the comments. This is not a substitute for the idea of
forming a consulting group of experts as you suggest.
While my suggestion about adapting wiki pages *is* beyond the scope of
improving the activity itself, I think it is not an unreasonable
approach to take to leverage other resources by improving them to the
benefit of the upstream and the downstream. Content development is an
area where neither Sugar Labs or OLPC has the resources required for a
complete solution and so leveraging tools like Wikipedia is often the
best available choice and one that inherently supports a wide range of
More information about the olpc-Sur