| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Documentation build overview397 files changed · + 8 added · ± 389 modified + Added
± Modified |
Sorry, something went wrong.
|
@m-aciek can you please take a look? |
Sorry, something went wrong.
There was a problem hiding this comment.
After thinking it through, I don’t think we need to change the existing loader. The turtle-translations package can provide modules such as turtle_docstringdict_pl.py containing a docsdict dictionary, which older Python versions can already load through turtle.cfg. This would let us distribute and update translations independently of Python releases while preserving compatibility with the existing loading mechanism.
Documenting the package would still help users discover and install translations, and an environment variable for selecting the language could be a convenient addition. Could we focus this PR on those improvements and keep the existing loader?
Sorry, something went wrong.
|
I'm still not convinced, however, for two reasons:
|
Sorry, something went wrong.
|
I agree that the top-level modules introduce some namespace clutter; that seems to be the main trade-off of preserving compatibility with the existing loader. For the version-compatibility issue, though, I don't think this necessarily requires separate releases of turtle-translations for older Python versions. A single release could ship version-specific docsdict data and have the turtle_docstringdict_<lang> modules select the appropriate one based on sys.version_info. The version-specific dictionaries could also be generated from the common translation catalogue against the API exposed by each supported turtle version, so entries for newer methods simply wouldn't be present when loaded by an older Python. |
Sorry, something went wrong.
|
Ok, let's try that for now, and we can always iterate since there's quite a bit of time till the feature freeze. I've made the switch, please review. |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for the update. Could we make the documentation easier to follow for beginners by leading with a complete example of enabling a translation, followed by a link to instructions for contributing a new language? The dictionary format and module lookup details could go alongside write_docstringdict().
In the introduction, “translations” would be clearer than “translation catalogues” or “docstring dictionaries”. It would also help to explain that only the help text is translated; Python function names remain unchanged.
Sorry, something went wrong.
Co-authored-by: Maciej Olko <maciej.olko@affirm.com>
|
I reshuffled some things around, thanks for the review. I'd like to wait a little before we start deprecating things, and I need to think a bit more about what to do with the eval. |
Sorry, something went wrong.
There was a problem hiding this comment.
🚀 I left yet couple of non-blocking suggestions.
Sorry, something went wrong.
Co-authored-by: Maciej Olko <maciej.olko@affirm.com>
|
After we set up the turtle-translations repository and get first translations, I think it would be worth it to backport it for supported versions. |
Sorry, something went wrong.
|
Yes, I'll selectively backport some bits then. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Uh oh!
There was an error while loading. Please reload this page.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.