Request advice/opinions on translations for Crunchy
Hi everyone, This message may not be of huge interest to people who don't need to use languages other than English. I've started the French translation for Crunchy. There are four types of translations that need to be done: 1. Navigation menu within Crunchy. [Done] 2. Actual documentation and tutorials. [Not done except for the intro html page - will not be done for a *long* time, at least not by me.] 3. "messages" to the user. For example, we've simplified the Python tracebacks so that the message is more user-friendly. Also "button labels" are going to be translated. This is the main part I am working on to translate. 4. [and this is what I'm mostly asking about] Graphics commands, for example circle() or set_line_color() or set_line_colour() [we support both syntax ;-)]. The strings are ready to be translated [i.e. replace circle() by cercle(), or set_line_color() by couleur_de_ligne()] but, since the documentation (and tutorials) are likely to be only in English, I'm wondering about the wisdom of translating them. Any idea? André
Hiya,
[snip other stuff]
4. [and this is what I'm mostly asking about] Graphics commands, for example circle() or set_line_color() or set_line_colour() [we support both syntax ;-)]. The strings are ready to be translated [i.e. replace circle() by cercle(), or set_line_color() by couleur_de_ligne()] but, since the documentation (and tutorials) are likely to be only in English, I'm wondering about the wisdom of translating them.
While the docs and tutorials will only be in English for now I think the infrastructure for translating the API should be present. One of the main aims of the Ubuntu project is that all the included software has full translations into as many languages as possible, so if we want Crunchy to be part of EdUbuntu at some point in the future we should to at least make it possible to translate everything.
Any idea?
André
Johannes
Hi Johannes, Now, edu-sig readers will get a feel for the kind of discussions that goes behind the scene while Crunchy is being improved upon ;-) On 8/17/06, Johannes Woolard <johannes.wollard@gmail.com> wrote:
Hiya,
[snip other stuff]
4. [and this is what I'm mostly asking about] Graphics commands, for example circle() or set_line_color() or set_line_colour() [we support both syntax ;-)]. The strings are ready to be translated [i.e. replace circle() by cercle(), or set_line_color() by couleur_de_ligne()] but, since the documentation (and tutorials) are likely to be only in English, I'm wondering about the wisdom of translating them.
While the docs and tutorials will only be in English for now I think the infrastructure for translating the API should be present. One of the main aims of the Ubuntu project is that all the included software has full translations into as many languages as possible, so if we want Crunchy to be part of EdUbuntu at some point in the future we should to at least make it possible to translate everything.
Well, as Johannes knows, everything in the code is in place for translating these graphics instructions. So, it is possible to translate everything. The actual translation process involves the creation of a "catalog" (that's the term used in i18n) for each language, where every translatable string included in Crunchy is mapped to an appropriate translation in that language. I am currently in the process of translating the various strings into French. All messages to the user, button labels, menus, etc., will definitely be translated. At this point, I am inclined to have the French catalog contain the string "color" as a translation of "color" (that's right... no actual translation performed) since there's no documentation or tutorial written that would indicate that the graphics command in French would be "couleur". I imagine someone reading the English doc and trying a program with "color" get extremely frustrated getting the message "color n'est pas une commande reconnue", not realising that he can't trust the docs but has to guess how that command has been translated in French. (Easy here ... but not so easy for other commands like set_fill_color...). Of course, when thousands of people start using Crunchy in a myriad of languages, with tutorials translated ... the decision of providing a true translation in the "catalog" of graphics commands will likely be different. André
On Aug 17, 2006, at 4:49 PM, Andre Roberge wrote:
4. [and this is what I'm mostly asking about] Graphics commands, for example circle() or set_line_color() or set_line_colour() [we support both syntax ;-)]. The strings are ready to be translated [i.e. replace circle() by cercle(), or set_line_color() by couleur_de_ligne()] but, since the documentation (and tutorials) are likely to be only in English, I'm wondering about the wisdom of translating them.
Out of curiosity, how are you going to handle translating the api? Is there some functionality for this in python itself? Are you actually emulating method accesses with __getattr__()? Are you using some other tool to translate the method names (and presumably if you were, for readability you could translate variable names, comments, etc, as well) into actual internationalized source files? - d
On 8/17/06, Dan Crosta <dcrosta@sccs.swarthmore.edu> wrote:
On Aug 17, 2006, at 4:49 PM, Andre Roberge wrote:
4. [and this is what I'm mostly asking about] Graphics commands, for example circle() or set_line_color() or set_line_colour() [we support both syntax ;-)]. The strings are ready to be translated [i.e. replace circle() by cercle(), or set_line_color() by couleur_de_ligne()] but, since the documentation (and tutorials) are likely to be only in English, I'm wondering about the wisdom of translating them.
Out of curiosity, how are you going to handle translating the api? Is there some functionality for this in python itself? Are you actually emulating method accesses with __getattr__()? Are you using some other tool to translate the method names (and presumably if you were, for readability you could translate variable names, comments, etc, as well) into actual internationalized source files?
I'll address the last question first. I am not aware of *any* program that has its source files translated. Nor do I see any reason to ever want to do so. The source code (including comments) for Crunchy is written in English and will remain as such. This is the same for the source code of the Python standard library. A good reference (with links) for understanding translations for computer programs is: http://wiki.wxpython.org/index.cgi/Internationalization In what follows, I'll provide a "simplified" description.... First, some background. Crunchy is designed to deliver interactive Python tutorials. In order to make tutorials more interesting, some basic graphics capabilities (shape drawing, function plotting, etc.) have been built-in. A simple graphics program might include things like: === circle( (100, 100), 30) set_fill_color("red") filled_circle( (200, 200), 50) === etc... This program, when executed, produces a series of javascript commands that are used to draw the corresponding shapes within an html <canvas>. The way this is done is that the user code are "exec"uted in a Python dict that contains mappings from {"circle" : actual_command_that_draws_circles, # other dict definitions here } The actual code (inside Crunchy) used to process the code entered by the user looks something like: exec user_code in graphics_dict and the resulting output is the javascript code required to produce a graphics in the browser. To allow a possible translation of the commands, the string "circle" is actually written in the code as _("circle") following the standard "gettext" notation to denote strings that can be translated. At present the function _("args") simply returns "args". When translation is introduced, _() is redefined and returns the translated value provided by the "catalog". Thus, I can have in the catalog the correspondance "cercle" <--> "circle" which will mean that the Python code _("circle"): actual_command_that_draws_circles will actually be taken to mean "cercle": actual_command_that_draws_circles Note that we've only provided translations for Crunchy-specific commands, like the graphics api. In theory, it would be possible to do the same for Python functions/methods i.e. we could have a translation of getcwd to trouver_le_repertoire_courant but that would be rather silly and not very helpful for someone who wants to learn Python. This is a rather brief description and I will gladly attempt to clarify any specific point. André
- d _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
As we learned from Plone, internationalization has much to do with "skinning", with a quick way to recustomize depending on a user's needs. (a) should we just freeze a master disk for each language, (b) or might one distro handle multiple languages through some core library reskinning service? I think interimly, the former is more practical, as these core services don't exist yet, what with unicode still being somewhat in its infancy and so on. We need the assistance of locales to get their versions defined in some electronic archive. Like, where's the gaelic version of Linux, or at least a GNU desktop thereon? One solution I've found: http://www.kde.ie/ga.php Kirby On 8/17/06, Andre Roberge <andre.roberge@gmail.com> wrote:
On 8/17/06, Dan Crosta <dcrosta@sccs.swarthmore.edu> wrote:
On Aug 17, 2006, at 4:49 PM, Andre Roberge wrote:
4. [and this is what I'm mostly asking about] Graphics commands, for example circle() or set_line_color() or set_line_colour() [we support both syntax ;-)]. The strings are ready to be translated [i.e. replace circle() by cercle(), or set_line_color() by couleur_de_ligne()] but, since the documentation (and tutorials) are likely to be only in English, I'm wondering about the wisdom of translating them.
participants (4)
-
Andre Roberge -
Dan Crosta -
Johannes Woolard -
kirby urner