# Redesigning the \`turtle\` docstring translation process **URL:** \ **Category:** Core Development\ **Tags:** translation\ **Created:** [August 25, 2026, 8:00pm UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750 "2026-08-25T20:00:04Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Stanfromireland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stanfromireland/32/10102_2.png) [@Stanfromireland](https://discuss.python.org/u/Stanfromireland)\ **Post date:** [August 25, 2026, 8:00pm UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750/1 "2026-08-25T20:00:04Z")
`turtle` supports translation of its docstrings via [`turtle.write_docstringdict`](https://docs.python.org/3/library/turtle.html#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](https://devguide.python.org/documentation/translations/translating/#motivation), 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’d love to hear what people think! ---
**Author:** ![zware](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zware/32/58_2.png) [@zware](https://discuss.python.org/u/zware)\ **Post date:** [August 25, 2026, 11:37pm UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750/2 "2026-08-25T23:37:15Z")
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). ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [August 26, 2026, 12:01am UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750/3 "2026-08-26T00:01:11Z")
> [@zware](#): > > 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? ---
**Author:** ![zware](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zware/32/58_2.png) [@zware](https://discuss.python.org/u/zware)\ **Post date:** [August 26, 2026, 12:25am UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750/4 "2026-08-26T00:25:13Z")
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. ---
**Author:** ![maciek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/maciek/32/596_2.png) [@maciek](https://discuss.python.org/u/maciek)\ **Post date:** [August 26, 2026, 9:11am UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750/5 "2026-08-26T09:11:31Z")
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()`](https://github.com/python/cpython/blob/e2118b0ac21191bfeecdc97758a87d88ffdda154/Lib/turtle.py#L4014-L4029) 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. ---
**Author:** ![Stanfromireland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stanfromireland/32/10102_2.png) [@Stanfromireland](https://discuss.python.org/u/Stanfromireland)\ **Post date:** [August 26, 2026, 9:17am UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750/6 "2026-08-26T09:17:15Z")
> [@zware](#): > > 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). > [@maciek](#): > > 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. 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. > [@guido](#): > > In fact, do the original reasons for having turtle itself in the stdlib still hold? 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. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [August 26, 2026, 11:40am UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750/7 "2026-08-26T11:40:39Z")
> [@Stanfromireland](#): > > 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. 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. * * * 1. Whether that’s `Lib` or `Lib/site-packages`, and whether Debian will check that box or not, remains to be determined. 2. “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.) ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [August 27, 2026, 4:37am UTC](https://discuss.python.org/t/redesigning-the-turtle-docstring-translation-process/108750/8 "2026-08-27T04:37:39Z")
> [@Stanfromireland](#): > > I concur with Zach and Maciej here. The users of `turtle` benefit a great deal from that ease of access. 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. > [@Stanfromireland](#): > > 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. 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.