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

Fri Sep 4 13:34:16 CEST 2015

I'm agree with Matthias: IT world is mostly English based.
It's "sad" for non native English speakers like me because you must learn
English before to work in IT.
However, the positive side effect is that we can speak together in the
common language.

Ludovic Gasc (GMLudo)
http://www.gmludo.eu/
On 4 Sep 2015 09:26, "Matthias Bussonnier" <bussonniermatthias at gmail.com>
wrote:

> 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.
>
> Thanks,
> --
>
> Matthias
>
> [1]: 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
>
>
> 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>
> 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
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: 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/
>
>
>
> _______________________________________________
> 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/7545787f/attachment.html>