[Python-ideas] Non-English names in the turtle module.

Matthias Bussonnier bussonniermatthias at gmail.com
Fri Sep 4 09:26:08 CEST 2015

Hi all, 

Personal opinion, base by a bit of experience:

There is one thing worse than programming in a foreign language IMHO (I’m native french) 
It’s programming in an environment which is half translated and/or mix
english and native language.

The cognitive load and the context switching it forces the brain to do when 2 languages 
are present is absolutely astronomical, and i guess translating the Turtle module
will not allow to translate the control-flow structure, the docstrings....etc and so on,
and so forth if you do simple `Tortue = Turtle` assignment,
 So while it looks nice 2 liners example you hit this problem pretty quickly. 

Taking fort given example:

import turtle   # import is english, should translate to  importer, ou importez. turtle should be tortue also. 
t = turtle.Plume()
t.couleurplume('vert’)  # plume is a female, couleur should be “verte”, “crayon” would be male, so “vert"
t.avant(100)  # avance/avancer

I can perfectly imagine a menu “insérer use boucle `pour ...`”, that insert a `for ....` in applications, 
which is confusing is confusing to explain. 

I also find it much easier to attach a programming meaning to a word that 
have no previous meaning for a kid (for, range, if, else, print are blank slate
for French children), than shoehorn another concept biased by previous
experience into it. 

This in particular make me think of Gibiane[1], which is basically:
“Hey fortran is great let’s make it in french”, which was a really bad idea[2], 
no it’s not a joke, and yes people do nuclear physics using this language. 

While I appreciate in general the translation effort, in general most of the 
translated side of things (MDN, microsoft help pages, Apples ones) are much 
worse than trying to understand the english originals. 

So just a warning that the best is the enemy of the good, and despite good intentions[3],
trying to translate Turtle module might not be the right thing to do. 



[1]: https://fr.wikipedia.org/wiki/Gibiane <https://fr.wikipedia.org/wiki/Gibiane>
[2]: but not the worse IMHO.
[3]: http://www.bloombergview.com/articles/2015-08-18/how-a-ban-on-plastic-bags-can-go-wrong <http://www.bloombergview.com/articles/2015-08-18/how-a-ban-on-plastic-bags-can-go-wrong>

> On Sep 4, 2015, at 05:52, Al Sweigart <asweigart at gmail.com> wrote:
> Thinking about it some more, yeah, having a separate module on PyPI would just be a waste of time. This isn't changing functionality or experimenting with new features, it's just adding new names to existing functions. And installing stuff with pip is going to be insurmountable barrier for a lot of computer labs.
> I'd say Python is very much a kid-friendly language. It's definitely much friendlier than BASIC.
> I'd advise against using the _() function in gettext. That function is for string tables, which is set up to be easily changed and expanded. The turtle API is pretty much set in stone, and dealing with separate .po files and gettext in general would be more of a maintenance headache. It is also dependent on the machine's localization settings.
> I believe some simple code at the end of turtle.py like this would be good enough:
>     _spanish = {'forward': 'adelante'} # ...and the rest of the translated terms
>     _languages = {'spanish': _spanish} # ...and the rest of the languages
>     def forward(): # this is the original turtle forward() function
>         print('Blah blah blah, this is the forward() function.')
>     for language in _languages:
>         for englishTerm, nonEnglishTerm in _languages[language].items():
>             locals()[nonEnglishTerm] = locals()[englishTerm]
> Plus the diff wouldn't look too bad.
> This doesn't prohibit someone from mixing both English and Non-English names in the same program, but I don't see that as a big problem. I think it's best to have all the languages available without having to setup localization settings.
> -Al
> On Thu, Sep 3, 2015 at 7:45 PM, Steven D'Aprano <steve at pearwood.info <mailto:steve at pearwood.info>> wrote:
> On Fri, Sep 04, 2015 at 11:05:51AM +0900, Stephen J. Turnbull wrote:
> > Al Sweigart writes:
> >
> >  > The idea for putting these modules on PyPI is interesting. My only
> >  > hesitation is I don't want "but it's already on PyPI" as an excuse
> >  > not to include these changes into the standard library turtle
> >  > module.
> >
> > Exactly backwards, as the first objection is going to be "if it could
> > be on PyPI but isn't, there's no evidence it's ready for the stdlib."
> *cough typing cough*
> The turtle module has been in Python for many, many years. This proposal
> doesn't change the functionality, it merely offers a localised API to
> the same functionality. A bunch of alternate names, nothing more.
> I would argue that if you consider the user-base of turtle, putting it
> on PyPI is a waste of time:
> - Beginners aren't going to know to "pip install whatever". Some of us
> here seem to think that pip is the answer to everything, but if you look
> on the python-list mailing list, you will see plenty of evidence that
> people have trouble using pip.
> - Schools may have policies against the installation of unapproved
> software on their desktops, and getting approval to "pip install *" may
> be difficult, time-consuming or outright impossible. If they are using
> Python, we know they have approval to use what is in the standard
> library. Everything else is, at best, a theorectical possibility.
> One argument against this proposal is that Python is not really designed
> as a kid-friendly learning language, and we should just abandon that
> space to languages that do it better, like Scratch. I'd hate to see that
> argument win, but given our limited resources perhaps we should know
> when we're beaten. Compared to what Scratch can do, turtle graphics are
> so very 1970s.
> But if we think that there is still a place in the Python infrastructure
> for turtle graphics, then I'm +1 on localising the turtle module.
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org <mailto:Python-ideas at python.org>
> https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas>
> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150904/65b44ff0/attachment-0001.html>

More information about the Python-ideas mailing list