I maintain a set of typestubs for MicroPython, that include docstrings in English.
These makes them available as documentation in most IDEs, which is relevant as MicroPython itself does not include docstrings in the runtime to keep it “Micro”.
Educators, students, makers and professionals benefit from the availability of the docs while they code, assuming they can read English.
I have noticed that there are some efforts to translate or re-create stubs to Chinese, and the Micro:bit project has stubs in multiple languages, but have not published them.
I want to support publishing translations of the stubs I maintain, but have not been able to determine if there is a way to support more than a single language in a distribution package.
I hope there are others that have similar needs, and may have found a way to solve this without needing to multiply the amount of packages x support_languages.
This doesn’t seem to be exclusive to type stubs. It’s equally valid to ask how you would publish a normal package with docstrings available in multiple languages (and I think the answer is “you can’t”).
In principle, I support the idea of making this possible. But in practical terms, it feels like it could be a rather significant change for the packaging ecosystem (and possibly even for the Python import system itself).
Like the OP, I’d be pleased to find that I’m wrong and there is a way of doing this. Assuming there is, it would be a great addition to the documentation at packaging.python.org.
pip install -t typings micropython-rp2-stubs[zh-hans] Simplified Chinese
[project]
name = "micropython-rp2-stubs"
default-optional-dependency-keys = [
"en"
]
[project.optional-dependencies]
en = ["micropython-rp2-en-stubs","micropython-stdlib-en-stubs"]
nl = ["micropython-rp2-nl-stubs","micropython-stdlib-nl-stubs"]
zh-hans = ["micropython-rp2-zh-hans-stubs","micropython-stdlib-zh-hans-stubs"]
For stubs that could, kind-off, work.
The main issue I see is is that one can specify multiple extras, things will either break or will overwrite other language stubs and then the result will be … interesting.
Is micropython-rp2-stubs[zh-hans] really easier to explain than micropython-rp2-stubs-zh-hans? (Or swap the order around if you need to keep -stubs last - either way, someone will need to be told the name, so you don’t have to choose something guessable by someone without context.)
The bigger issue is that help() isn’t going to read stubs - hopefully ever - so your interactive docstrings won’t translate. Though if they currently don’t exist in your case, that hardly matters.
There’s another discussion I saw (yours?) about how IDEs should interpret the presence of docstrings in both stubs and source files. I’ve consistently argued that stubs should win, since installing stubs is a manual opt-in signal, and so it should take priority over the implicit signal of the installed packages (which may just be installed “merely” for running the code ). However, the team behind at least one type checker/IDE disagreed with me, and since they’re the specialists in that field, I assume they have good reasons (they never persuaded me, but they also never tried).
But being able to use separate packages is already totally viable, even though they would install conflicting files if you install multiple (“don’t do that” is a valid instruction, IMHO). The only way I think you’d try to complicate this would be to define a directory structure that lets you put all the languages in one stub package (subdirectories), which again, is totally viable, you just need to post in Editor/IDE Integration and get the IDE developers to agree to understand it.
Not if you have language neutral stubs (typically English) in the usual place, but IDEs know to look inside language code directories for docstrings. This approach would require training various tools to do things differently, and without changing the tools it wouldn’t be any better than what we have today, but there doesn’t seem much point proposing ideas that don’t require changing tools - you can already do such ideas, so why not just go ahead and do them.
And massively massively complicate install time. I strongly recommend not going down this path (as someone who works for a company that ships many many languages for much of its software). Just let users specify their language, either in their own install command or in IDE configuration.
). However, the team behind at least one type checker/IDE disagreed with me, and since they’re the specialists in that field, I assume they have good reasons (they never persuaded me, but they also never tried).