Al did post to python-ideas, with a link to a prototype.  I think a fair summary is that core-developers had at least the same reluctance to be involve with code translations as with doc translations.  We rejected doing the latter as part of cpython by pydev.  I am doing the same with respect to this specific implementation.

Looking at the prototype, I agreed with Al hard-coding translations is a "terrible way for a software module to implement internationalization,".  For one thing, mixing multiple languages does not scale.

On python-ideas, I urged Al to make this a pypi project.  I give below a different path that would also be mostly independent of cpython and this tracker.

The March 2017 pydev decision with respect to document translations, as described in the PEP, was that they should be a separate project with a separate team, team leaders, contributor agreement, infrastructure, and procedures. The pydev/cpython contribution was limited adding the language selection box and whatever html is needed to grab a translation.

Code translations should be handled the same way. One of the common issues, for instance, is trust.  Core developers are in no position to check that translations are not, for instance, 'adults-only'. The translation project leaders have worked out whatever procedure they have for vetting translators and translations.  For one thing, I believe they usually have more than one person per language team.

According to the PEP,  https://mail.python.org/mailman/listinfo/doc-sig
is used for discussion of document translations.  When I feel like revisiting the issue of translating IDLE's menus, I will discuss it with them.

I think anyone interested in turtle command translations should do the same.  When there is something to hook to and therefore a need to modify turtle, a new issue can be opened.