i18n and Pootle progress - Part 2
Kenny Meyer
Thorough this week I have been wasting too much time doing manual editions on
the HTML lessons.
Peter, I think it was going the wrong way when we said, marking the tag with a
translatable string with `class="translate"` or `class="translateTitle"`
This is just too much work and will scare off our lesson authors, and instead I
have found the `itools` Python library. [1]
Here just short a short report in chronological order:
On Wednesday I contacted Sayamindu and talked about Karma's translation
process. He gave me some useful tips.
On Thursday I heard about `itools`, I read the code and documentation and gave
it a try on a few lessons.
`itools` created the the POT file and the PO files for all languages I wanted
running a _single_ command and it also compiled the MO files on demand.
That was awesome.
I ran into bugs with UTF-8 encoding of some of the lessons and I spent some
time to get them fixed [2].
Now, I was able to create a global POT file for almost all HTML lessons in
Karma.
I started creating some Spanish translations for them and tested them. They're
OK!
[1] http://www.hforge.org
[2] http://bugs.hforge.org/show_bug.cgi?id=300
Now, the more specific topics are:
1. Talk with Sayamindu
----------------------
I talked with Sayamindu about the translation process of Karma on IRC.
The conclusions were:
* JavaScript translations and HTML translations are going separated:
I'm working toward something like having:
karma.html.pot
karma.js.pot
* Considering a `karma.core.js.pot` for core specific translations:
Reasons:
16:50 <@unmadindu> if the core karma code evolves slower (or faster) than
the lessons, there may be an advantage
16:50 <@unmadindu> also, since the reuse of those strings would be
higher, translating them first would give greater mileage (and may
encourage the translators)
16:51 <@unmadindu> (it is often good to have translators see their work
in action - it motivates them)
* A separate folder for translations in Karma's root, like locale/ or po/
where locale/ would be my preferred choice.
Please, comment.
2. `itools`
-----------
I hope you guys won't get upset with this decision, but I think it's a
reasonable solution for Karma lessons, for the following reasons:
* The code was/is tested, debugged and maintained.
* The HTML Parser is *really* great, (Surprisingly, it is based on Python's
HTMLParser module) and 10x better than the BeautifulSoup parser. BS was just
not made for our necessities.
To be sure, check out the attached POT file of Karma's lessons. It looks
great.
* The workflow is great. A translation manager will be entirely superflous :-)
* We don't need the `class="translate"`, etc. attribute anymore.
* It's super easy to use.
* It's Open-Source.
The downsides are:
* It still doesn't really support HTML5 (,but neither does BS).
I was talking with the Lead developer of `itools` on the mailing-list and he
agreed on working on that together.
* No JavaScript support. Oh, yes, have I mentioned that he'll work on that,
too? :-)
At the moment, we don't need to rely on `itools` for that. Additionally,
we're using jQuery's i18n plugin for i18n of the lessons.
* Actually, there is that bug for <canvas> elements and a bug affecting the
<script> elements in our lessons.
That disables 4 of our lessons to be properly parsed. At the moment I will
solve this manually.
Those lessons are:
lessons/quadrilaterals/index.html - <canvas> elements
lessons/6_Maths_linesAndTriangle_8_K/index.html
lessons/2_English_whatSomeoneIsDoing/index.html - <script> messes up
parsing. Bug.
I have fixed, as mentioned earlier, some UTF-8 specific issues [2] with the
parser [2], which still haven't been reviewed by the Lead developers of
`itools`, but I have tested them. So you can get my fork with the applied
patches on Github [3].
2.1. Workflow
-------------
Please check out my fork on git.olenepal.org [4] to see an example of the
workflow if you're interested.
Please, read locale/INSTRUCTIONS
Basically, for future maintainers it should be necessary to just type
./make-compile-merge-update-translations and <ENTER>.
Keep in mind, that that was just an example.
2.2. ...and the JavaScript?
---------------------------
I discussed the matters briefly with the Lead developer of `itools` of working
together on that. Well, it's a higher priority to get it running firstly, with
Karma.
On the other side, it won't be very hard to integrate JavaScript i18n within
the workflow with `itools` as it is just all "just" Python in the end.
3. JavaScript and jQuery i18n
-----------------------------
The lessons' JavaScript hasn't yet been touched by myself.
This topic needs its own thread.
4. Pootle
---------
Now, that we practically have the karma.html.pot, should I consider talking
with Sayamindu to lead in ways with Pootle integration on sugarlabs or should I
do the missing JavaScript gettext stuff first?
I think it would be no harm to ask Sayamindu, now.
What do you think?
5. Not translated lessons
-------------------------
This has been an issue since last week's mail and is until now. There are still
some non-English words in the lessons' index.html, not to talk about the other
HTML documents.
I suppose it's difficult to get people working on that, so maybe I could do the
stuff what has to be done really urgently.
What I need is a translations resources. Google's Translate service doesn't
help me out on this one. Do you have any pointers to useful resources.
Oh, yes, please checkout the attached `locale.pot`. You can just filter out the
not to English translated strings and perhaps send me the English translations
and I will just take care of them.
What next?
==========
1. Fix the pending `itools` bugs.
2. Translate lessons to English.
3. Have a karma.js.pot this week
4. Adding Spanish translations to Pootle.
Numbering does not indicate priority.
Conclusions
===========
The talk with Sayamindu was great and helpful. Really sympathetic.
It is fun to work with the flexible Python library `itools`. It really saved me
a huge amount of time; if I would only have found it earlier.
The JavaScript translation process is a big goal for the near future.
Sadly, a lot of my past time activity was just for nothing.
[1] http://www.hforge.org
[2] http://bugs.hforge.org/show_bug.cgi?id=300
[3] http://github.com/km0r3/itools
[4] http://git.olenepal.org/~km0r3/karma/km0r3-karma/trees/experimental
--
Regards,
Kenny Meyer | http://kenny.alwaysdata.net
Peter Gijsels
I'm moving this wednesday and don't have an awful lot of time, so my
answers will be brief.
On Mon, May 10, 2010 at 2:24 AM, Kenny Meyer <knny...@gmail.com> wrote:
> Estimated Karma-Team,
>
> Thorough this week I have been wasting too much time doing manual editions on
> the HTML lessons.
> Peter, I think it was going the wrong way when we said, marking the tag with a
> translatable string with `class="translate"` or `class="translateTitle"`
> This is just too much work and will scare off our lesson authors, and instead I
> have found the `itools` Python library. [1]
need to be translated? I'm not sure if it is very important, but it
might be handy.
>
> Here just short a short report in chronological order:
>
> On Wednesday I contacted Sayamindu and talked about Karma's translation
> process. He gave me some useful tips.
> On Thursday I heard about `itools`, I read the code and documentation and gave
> it a try on a few lessons.
> `itools` created the the POT file and the PO files for all languages I wanted
> running a _single_ command and it also compiled the MO files on demand.
> That was awesome.
> I ran into bugs with UTF-8 encoding of some of the lessons and I spent some
> time to get them fixed [2].
> Now, I was able to create a global POT file for almost all HTML lessons in
> Karma.
> I started creating some Spanish translations for them and tested them. They're
> OK!
>
> [1] http://www.hforge.org
> [2] http://bugs.hforge.org/show_bug.cgi?id=300
> Now, the more specific topics are:
>
> 1. Talk with Sayamindu
> ----------------------
>
> I talked with Sayamindu about the translation process of Karma on IRC.
> The conclusions were:
> * JavaScript translations and HTML translations are going separated:
>
> I'm working toward something like having:
>
> karma.html.pot
> karma.js.pot
>
> * Considering a `karma.core.js.pot` for core specific translations:
>
> Reasons:
>
> 16:50 <@unmadindu> if the core karma code evolves slower (or faster) than
> the lessons, there may be an advantage
> 16:50 <@unmadindu> also, since the reuse of those strings would be
> higher, translating them first would give greater mileage (and may
> encourage the translators)
> 16:51 <@unmadindu> (it is often good to have translators see their work
> in action - it motivates them)
>
> * A separate folder for translations in Karma's root, like locale/ or po/
> where locale/ would be my preferred choice.
>
> Please, comment.
> 2. `itools`
> -----------
>
> I hope you guys won't get upset with this decision, but I think it's a
> reasonable solution for Karma lessons, for the following reasons:
better and better supported, we should use it.
> * The code was/is tested, debugged and maintained.
> * The HTML Parser is *really* great, (Surprisingly, it is based on Python's
> HTMLParser module) and 10x better than the BeautifulSoup parser. BS was just
> not made for our necessities.
> To be sure, check out the attached POT file of Karma's lessons. It looks
> great.
> * The workflow is great. A translation manager will be entirely superflous :-)
> * We don't need the `class="translate"`, etc. attribute anymore.
> * It's super easy to use.
> * It's Open-Source.
>
> The downsides are:
>
> * It still doesn't really support HTML5 (,but neither does BS).
> I was talking with the Lead developer of `itools` on the mailing-list and he
> agreed on working on that together.
> * No JavaScript support. Oh, yes, have I mentioned that he'll work on that,
> too? :-)
> At the moment, we don't need to rely on `itools` for that. Additionally,
> we're using jQuery's i18n plugin for i18n of the lessons.
> * Actually, there is that bug for <canvas> elements and a bug affecting the
> <script> elements in our lessons.
> That disables 4 of our lessons to be properly parsed. At the moment I will
> solve this manually.
> Those lessons are:
>
> lessons/quadrilaterals/index.html - <canvas> elements
> lessons/6_Maths_linesAndTriangle_8_K/index.html
> lessons/2_English_whatSomeoneIsDoing/index.html - <script> messes up
> parsing. Bug.
>
> I have fixed, as mentioned earlier, some UTF-8 specific issues [2] with the
> parser [2], which still haven't been reviewed by the Lead developers of
> `itools`, but I have tested them. So you can get my fork with the applied
> patches on Github [3].
your patches?
> 2.1. Workflow
> -------------
> Please check out my fork on git.olenepal.org [4] to see an example of the
> workflow if you're interested.
>
> Please, read locale/INSTRUCTIONS
>
> Basically, for future maintainers it should be necessary to just type
> ./make-compile-merge-update-translations and <ENTER>.
> Keep in mind, that that was just an example.
> 2.2. ...and the JavaScript?
> ---------------------------
>
> I discussed the matters briefly with the Lead developer of `itools` of working
> together on that. Well, it's a higher priority to get it running firstly, with
> Karma.
>
> On the other side, it won't be very hard to integrate JavaScript i18n within
> the workflow with `itools` as it is just all "just" Python in the end.
>
> 3. JavaScript and jQuery i18n
> -----------------------------
>
> The lessons' JavaScript hasn't yet been touched by myself.
>
> This topic needs its own thread.
>
>
> 4. Pootle
> ---------
>
> Now, that we practically have the karma.html.pot, should I consider talking
> with Sayamindu to lead in ways with Pootle integration on sugarlabs or should I
> do the missing JavaScript gettext stuff first?
>
> I think it would be no harm to ask Sayamindu, now.
> What do you think?
I would make it the highest priority.
> 5. Not translated lessons
> -------------------------
>
> This has been an issue since last week's mail and is until now. There are still
> some non-English words in the lessons' index.html, not to talk about the other
> HTML documents.
>
> I suppose it's difficult to get people working on that, so maybe I could do the
> stuff what has to be done really urgently.
>
> What I need is a translations resources. Google's Translate service doesn't
> help me out on this one. Do you have any pointers to useful resources.
>
> Oh, yes, please checkout the attached `locale.pot`. You can just filter out the
> not to English translated strings and perhaps send me the English translations
> and I will just take care of them.
>
>
> What next?
> ==========
>
> 1. Fix the pending `itools` bugs.
> 2. Translate lessons to English.
> 3. Have a karma.js.pot this week
> 4. Adding Spanish translations to Pootle.
>
> Numbering does not indicate priority.
>
>
> Conclusions
> ===========
>
> The talk with Sayamindu was great and helpful. Really sympathetic.
> It is fun to work with the flexible Python library `itools`. It really saved me
> a huge amount of time; if I would only have found it earlier.
> The JavaScript translation process is a big goal for the near future.
> Sadly, a lot of my past time activity was just for nothing.
do the detour to arrive the simple solution...
Excellent work!
Peter