turtle supports translation of its docstrings via turtle.write_docstringdict, however no catalogues have ever been widely distributed (from what I can tell), and the documentation still directs requests to a personal email address (Gregor Lingl) for German and Italian dictionaries, which are now unobtainable.
This feature matters more for turtle than for other modules because its users are largely children and beginners for whom English help() output and IDE calltips are a barrier (see also the motivation for the docs translations, which also applies here).
As such, I propose creating a new python/turtle-translations a repository to store the catalogues, which would then be released to PyPI. A teacher could then pip install turtle-translations and set a PYTHON_TURTLE_LANG envvar on their student’s computers for translated docstrings (note that this would require some minor changes to turtle, however my patch is +17/-2 which I think is reasonable).
I considered keeping the catalogues in CPython itself, but that would complicate translation contribution options and automatic updates, and block us from using Transifex or another such tool. It would also not be particularly lightweight.
I’m in favor of however you want to accomplish this
I would suggest that bundling the translations with turtle itself, without requiring the separate step of installing from PyPI, would be good (though the ability to update outside of our release cycle is definitely enticing).
Another reason to keep it outside the stdlib is that we don’t want to burden the core maintainers with responsibility for these translations. There’s not much we can do if we get issues in the CPython tracker about the Chinese translation of turtle.
In fact, do the original reasons for having turtle itself in the stdlib still hold?
Definitely agree that maintenance of the translations should be kept separate from the cpython repository, similar in spirit if not workflow to how existing docs translations are handled, regardless of how they are distributed. I could imagine a workflow where we pull in translation updates as part of the release process, for example.
I think ease of access is still a very strong argument for including beginner-friendly modules like turtle, though it in particular does come with significant maintenance burden in the form of the Tcl/Tk dependency. I wouldn’t like to see it disappear from our Windows or macOS distributions, even if it is already not available by default on most Linux distributions and isn’t even applicable to most other platforms.
I think the original rationale for keeping turtle in the standard library still largely holds.
Turtle graphics is still used for teaching programming, and Python is arguably one of the dominant text-based languages for introductory programming. turtle still appears explicitly in school curricula, teaching materials, and books, while many of the standalone Logo/turtle environments that used to fill this niche have faded from mainstream use. So I think the “available as part of Python, with no third-party installation step” argument is still particularly strong here.
What seems more dated to me is not the turtle model itself, but the hard dependency on Tk/tkinter; separating the turtle API from its rendering backend could make it easier to support browsers and other platforms without changing the beginner-facing API.
On the translation side, I think having translated IDE calltips and help() output — perhaps following the system locale by default, with an explicit override — could be a significant usability improvement for students and educators who are less comfortable working in English.
The current translation mechanism also seems somewhat dated from a security and packaging perspective. Translation dictionaries are imported as Python modules, and read_docstrings() additionally uses eval() when applying entries. Moving translations to a non-executable format such as gettext .mo files would seem preferable.
Perhaps there is a middle ground between bundling everything permanently in CPython and requiring a separate package from the start. CPython could ship a baseline set of turtle translations, while updated translations could also be distributed through the proposed turtle-translations package, which would contain only gettext catalogues and no executable code.
turtle could prefer translations from the installed package when available, while falling back to the bundled ones, allowing translations to be updated independently of CPython releases.
If we have a PyPI package, I think it would be possible to add a checkbox to the installers to automatically install it as part of the installation process, effectively “bundling” it for those users.
That said, I think we can leave this discussion for now and revisit it once we have a reasonable mechanism in place.
I concur with Zach and Maciej here. The users of turtle benefit a great deal from that ease of access.
I’d also note that the Tcl/Tk dependency will remain for as long as we continue to ship IDLE and tkinter, so removing turtle wouldn’t eliminate that dependency on its own.
The checkbox would go to the build process for the installers, effectively downloading and extracting the contents into the Lib directory before it gets packed.[1] I’m not sure we have any install-time options anymore (certainly not on Windows - there’s a choice of three packages,[2] but no further options - and I haven’t heard of any install checkboxes on Mac, Android or WASI).
FWIW, I’m very much in favour of splitting out maintenance and distribution of some stdlib packages like this. Provided we are sure that someone installing their own (newer) version of them will get the newer one, I think it’s a great way to handle long-term security patches and general maintenance, as well as making it easier for new contributors.
Whether that’s Lib or Lib/site-packages, and whether Debian will check that box or not, remains to be determined. ↩︎
“Default” (py install 3.15), “testing” (py install PythonTest\3.15; includes debug symbols and test suite) and “embeddable” (py install PythonEmbed\3.15; minimal zipped stdlib, no docs/testing/pip/etc.) ↩︎
And yet we’re proposing to put the translations in a PyPI package (with the exception of some baseline translations). That weakens the argument considerably. Also I don’t believe that installing 3rd party packages is quite the barrier to entry that it used to be.
I didn’t say I wanted turtle out because of the Tcl/Tk dependency. I wanted it out because it effectively can’t evolve (whether by growing translations or switching to a different backend or something else) while it’s in the stdlib.
