On Wed, 29 Mar 2017 at 13:13 Julien Palard
Hi Brett, thanks for the feedback!
Please check with the PSF that this is what we really want.
Gladly, but … how? I'm very new to all those process and have now idea on how I can get in touch with PSF lawyers.
What kind of support does Read the Docs have for translations? I have no active plans to push for this but it has been idea in the back of my head for a while so it would be good to know if such a move would make this easier or harder.
Read the Docs support translations [1]_, quoting them:
To support this, you will have one parent project and a number of projects marked as translations of that parent. Let’s use phpmyadmin as an example.
The main phpmyadmin project is the parent for all translations. Then you must create a project for each translation, for example phpmyadmin-spanish. You will set the Language for phpmyadmin-spanish to Spanish. In the parent projects Translations page, you will say that phpmyadmin-spanish is a translation for your project.
This has the results of serving: - phpmyadmin at http://phpmyadmin.readthedocs.io/en/latest/ - phpmyadmin-spanish at http://phpmyadmin.readthedocs.io/es/latest/
Which is nice as it's almost the same syntax the PEP proposes for paths: /{language_tag}/{version_tag}. Their language tags are simplified too (redundency removed (fr-FR → fr)) but not lowercased, and they use underscore "instead of" dashes as a separator, see for example:
- https://docs.phpmyadmin.net/fr/latest/ - https://docs.phpmyadmin.net/pt_BR/latest/
while the PEP proposes /pt-br/ instead.
.. [1] Project with multiple translations ( https://docs.readthedocs.io/en/latest/localization.html#project-with-multipl... )
Should we just match what Read the Docs does then?