<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi all, </div><div class=""><br class=""></div>Personal opinion, base by a bit of experience:<div class=""><br class=""></div><div class="">There is one thing worse than programming in a foreign language IMHO (I’m native french) </div><div class="">It’s programming in an environment which is half translated and/or mix</div><div class="">english and native language.</div><div class=""><br class=""></div><div class="">The cognitive load and the context switching it forces the brain to do when 2 languages </div><div class="">are present is absolutely astronomical, and i guess translating the Turtle module</div><div class="">will not allow to translate the control-flow structure, the docstrings....etc and so on,</div><div class="">and so forth if you do simple `Tortue = Turtle` assignment,</div><div class=""> So while it looks nice 2 liners example you hit this problem pretty quickly. </div><div class=""><br class=""></div><div class="">Taking fort given example:</div><div class=""><br class=""></div><div class=""><div class="">import turtle # import is english, should translate to importer, ou importez. turtle should be tortue also. </div><div class="">t = turtle.Plume()</div><div class="">t.couleurplume('vert’) # plume is a female, couleur should be “verte”, “crayon” would be male, so “vert"</div><div class="">t.avant(100) # avance/avancer</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I can perfectly imagine a menu “insérer use boucle `pour ...`”, that insert a `for ....` in applications, </div><div class="">which is confusing is confusing to explain. </div><div class=""><br class=""></div><div class="">I also find it much easier to attach a programming meaning to a word that </div><div class="">have no previous meaning for a kid (for, range, if, else, print are blank slate</div><div class="">for French children), than shoehorn another concept biased by previous</div><div class="">experience into it. </div><div class=""><br class=""></div><div class="">This in particular make me think of Gibiane[1], which is basically:</div><div class="">“Hey fortran is great let’s make it in french”, which was a really bad idea[2], </div><div class="">no it’s not a joke, and yes people do nuclear physics using this language. </div><div class=""><br class=""></div><div class="">While I appreciate in general the translation effort, in general most of the </div><div class="">translated side of things (MDN, microsoft help pages, Apples ones) are much </div><div class="">worse than trying to understand the english originals. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">So just a warning that the best is the enemy of the good, and despite good intentions[3],</div><div class="">trying to translate Turtle module might not be the right thing to do. </div><div class=""><br class=""></div><div class="">Thanks, </div><div class="">-- </div><div class=""><br class=""></div><div class="">Matthias</div><div class=""><br class=""></div><div class="">[1]: <a href="https://fr.wikipedia.org/wiki/Gibiane" class="">https://fr.wikipedia.org/wiki/Gibiane</a></div><div class="">[2]: but not the worse IMHO.</div><div class="">[3]: <a href="http://www.bloombergview.com/articles/2015-08-18/how-a-ban-on-plastic-bags-can-go-wrong" class="">http://www.bloombergview.com/articles/2015-08-18/how-a-ban-on-plastic-bags-can-go-wrong</a></div><div class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 4, 2015, at 05:52, Al Sweigart <<a href="mailto:asweigart@gmail.com" class="">asweigart@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">I'd say Python is very much a kid-friendly language. It's definitely much friendlier than BASIC.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I believe some simple code at the end of turtle.py like this would be good enough:</div><div class=""><br class=""></div><div class=""> _spanish = {'forward': 'adelante'} # ...and the rest of the translated terms</div><div class=""> _languages = {'spanish': _spanish} # ...and the rest of the languages</div><div class=""><br class=""></div><div class=""> def forward(): # this is the original turtle forward() function</div><div class=""> print('Blah blah blah, this is the forward() function.')</div><div class=""><br class=""></div><div class=""> for language in _languages:</div><div class=""> for englishTerm, nonEnglishTerm in _languages[language].items():</div><div class=""> locals()[nonEnglishTerm] = locals()[englishTerm]</div><div class=""><br class=""></div><div class="">Plus the diff wouldn't look too bad.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-Al</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Sep 3, 2015 at 7:45 PM, Steven D'Aprano <span dir="ltr" class=""><<a href="mailto:steve@pearwood.info" target="_blank" class="">steve@pearwood.info</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Sep 04, 2015 at 11:05:51AM +0900, Stephen J. Turnbull wrote:<br class="">
> Al Sweigart writes:<br class="">
><br class="">
> > The idea for putting these modules on PyPI is interesting. My only<br class="">
> > hesitation is I don't want "but it's already on PyPI" as an excuse<br class="">
> > not to include these changes into the standard library turtle<br class="">
> > module.<br class="">
><br class="">
> Exactly backwards, as the first objection is going to be "if it could<br class="">
> be on PyPI but isn't, there's no evidence it's ready for the stdlib."<br class="">
<br class="">
</div></div>*cough typing cough*<br class="">
<br class="">
<br class="">
The turtle module has been in Python for many, many years. This proposal<br class="">
doesn't change the functionality, it merely offers a localised API to<br class="">
the same functionality. A bunch of alternate names, nothing more.<br class="">
<br class="">
I would argue that if you consider the user-base of turtle, putting it<br class="">
on PyPI is a waste of time:<br class="">
<br class="">
- Beginners aren't going to know to "pip install whatever". Some of us<br class="">
here seem to think that pip is the answer to everything, but if you look<br class="">
on the python-list mailing list, you will see plenty of evidence that<br class="">
people have trouble using pip.<br class="">
<br class="">
- Schools may have policies against the installation of unapproved<br class="">
software on their desktops, and getting approval to "pip install *" may<br class="">
be difficult, time-consuming or outright impossible. If they are using<br class="">
Python, we know they have approval to use what is in the standard<br class="">
library. Everything else is, at best, a theorectical possibility.<br class="">
<br class="">
One argument against this proposal is that Python is not really designed<br class="">
as a kid-friendly learning language, and we should just abandon that<br class="">
space to languages that do it better, like Scratch. I'd hate to see that<br class="">
argument win, but given our limited resources perhaps we should know<br class="">
when we're beaten. Compared to what Scratch can do, turtle graphics are<br class="">
so very 1970s.<br class="">
<br class="">
But if we think that there is still a place in the Python infrastructure<br class="">
for turtle graphics, then I'm +1 on localising the turtle module.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
<br class="">
<br class="">
<br class="">
--<br class="">
Steve<br class="">
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br class="">
Python-ideas mailing list<br class="">
<a href="mailto:Python-ideas@python.org" class="">Python-ideas@python.org</a><br class="">
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank" class="">https://mail.python.org/mailman/listinfo/python-ideas</a><br class="">
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank" class="">http://python.org/psf/codeofconduct/</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">Python-ideas mailing list<br class=""><a href="mailto:Python-ideas@python.org" class="">Python-ideas@python.org</a><br class="">https://mail.python.org/mailman/listinfo/python-ideas<br class="">Code of Conduct: http://python.org/psf/codeofconduct/</div></blockquote></div><br class=""></div></div></body></html>