Python documentation translations are governed by PEP 545. They are built by docsbuild-scripts and hosted on docs.python.org. There are several documentation translations already in production; others are works in progress. See the dashboard for details.
First subscribe to the translation mailing list, and introduce yourself and the translation you're starting. Translations fall under the aegis of the PSF Translation Workgroup
Then you can bootstrap your new translation by using our cookiecutter.
The important steps look like this:
- Create the GitHub repo (anywhere) with the right hierarchy (using the cookiecutter).
- Gather people to help you translate. You can't do it alone.
- You can use any tool to translate, as long as you can synchronize with Git. Some use Transifex, and some use only GitHub. You can choose another way if you like; it's up to you.
- Ensure we update this page to reflect your work and progress, either via a PR or by asking on the translation mailing list.
- When
bugs.html,tutorial, andlibrary/functionsare 100% completed, ask on the translation mailing list for your language to be added in the language switcher on docs.python.org.
Here are the essential points of PEP 545:
- Each translation is assigned an appropriate lowercased language tag,
with an optional region subtag, and joined with a dash, like
pt-brorfr. - Each translation is under CC0 and marked as such in the README (as in the cookiecutter).
- Translation files are hosted on
https://github.com/python/python-docs-{LANGUAGE_TAG}(not mandatory to start a translation, but mandatory to land ondocs.python.org). - Translations having completed
tutorial/,library/stdtypesandlibrary/functionsare hosted onhttps://docs.python.org/{LANGUAGE_TAG}/{VERSION_TAG}/.
Discussions about translations occur on the Python Docs Discord
#translations channel, translation
mailing list, and there's a Libera.Chat IRC channel, #python-doc.
Consensus is to work on the current stable version. You can then propagate your translation from one branch to another using :pypi:`pomerge`.
Here's what we're using:
- :pypi:`pomerge` to propagate translations from one file to others.
- :pypi:`pospell` to check for typos in
.pofiles. - :pypi:`powrap` to rewrap the
.pofiles before committing. This helps keep Git diffs short. - :pypi:`potodo` to list what needs to be translated.
- :pypi:`sphinx-lint` to validate reST syntax in translation files.
There is no election; each translation has to sort this out. Here are some suggestions.
- Coordinator requests are to be public on the translation mailing list.
- If the given language has a native core dev, the core dev has their say on the choice.
- Anyone who wants to become coordinator for their native language and shows motivation by translating and building a community will be named coordinator.
- In case of concurrency between two persons, no one will sort this out for you. It is up to you two to organize a local election or whatever is needed to sort this out.
- If a coordinator becomes inactive or unreachable for a long period of time, someone else can ask for a takeover on the translation mailing list.
Ask on the translation mailing list, or better, make a PR on the devguide.
You can ask for help on the translation mailing list, and the team will help you create an appropriate repository. You can still use tools like transifex, if you like.
No, inside the github.com/python organization we’ll all have the
exact same hierarchy so bots will be able to build all of our
translations. So you may have to convert from one hierarchy to another.
Ask for help on the translation mailing list if you’re
not sure on how to do it.
As for every project, we have a branch per version. We store .po
files in the root of the repository using the gettext_compact=0
style.
Translate values in code examples (i.e. string literals) and comments. Don't translate keywords or names, including variable, function, class, argument, and attribute names.