[Python-Dev] Re: python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Le 5/30/21 à 4:31 PM, Guido van Rossum a écrit :
> What are you trying to get from the archives? It is *possible* that I
> have a personal archive saved somewhere.

I'm not even sure I remember my initial question... But it could be:

 > is the fact some things (like generators) give iterators instead of
 > iterables as a hint they're not "rewindable" was initially thought
 > of and part of the design, or it emerged later.

Then I went yak shaving...
--
[Julien Palard](https://mdk.fr)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IMQ4ZIURLUBTXOLKNYVQJAMDSJR2XYTE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Le 5/29/21 à 11:14 PM, Guido van Rossum a écrit :
> It looks like what's left of the archives is largely spam?

Yes.

SourceForge staff has manually hidden most spam on this list a few days
ago to help see better, but the interesting discussion is no longer here.

They checked in the mbox file on disk and found no more messages, and
they don't have a backup.

Web archive did not captured the mails on sourceforge neither, but
sourceforge support found a now disapeared archive of the list were
captured by web archive [1], but it contains only subject names, not
actual messages.

[1]:
https://web.archive.org/web/*/http://www.geocrawler.com/archives/3/9283/*
--
[Julien Palard](https://mdk.fr)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UBLRBZ44TMJMFLGYPXFPQEWMTJIKFJTQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Some bad news about python-iterat...@lists.sourceforge.net, looks like
sourceforge lost a huge part of the mailing list: they have 0 message
before Sep. 2001.

So I think I'll soon drop the link(s) refering to it in the PEPs.

--
[Julien Palard](https://mdk.fr)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZF64Y53M3KEKAGROORJA6SD6GPX2HDJO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Hi,

Le 5/25/21 à 9:18 PM, Brett Cannon a écrit :
> Is there something to do here? The python-iterators mailing list is
> already marked as public.

Looks like Guido is faster than you and set it public already. But looks
like the archives are corrupted or something, it's almost empty.

I sent a mail to SourceForge support but my hope is around 0. If it's
not fixed in a few months I'll just remove the links pointing to this
archive (there's some in the PEPs).

Thanks Brett and Guido,
--
[Julien Palard](https://mdk.fr)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QD7SVDWBMAAV7DCVK5K7RPEWCZ6YJIKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Le 5/11/21 à 8:39 PM, Guido van Rossum a écrit :
> I doubt that anyone has the keys to the python project on sourceforge
> any more... :-( We've abandoned that platform nearly two decades ago.

That's right…

Sourceforge staff mentionned there's the list of current admins here:

=> https://sourceforge.net/p/python/_members/

so if someone see its login there, you can try logging in and unhide the
mailing list, else I'll try to have sourceforge unhide it by hand.

--
[Julien Palard](https://mdk.fr)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DFE7G73N6LLSVYOZBZ6BHDAOGAGORQ6I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Hi,

PEP 234 mention
https://sourceforge.net/p/python/mailman/python-iterators/ but the
project mailing list archives are marked as "hidden".

Looks like projects admin and developers can get the "hidden link", but
I think it would be nice to "unhide" the archives if someone is still
admin there and if it's possible, to "unbreak" the link from the PEP.

Bests,
--
[Julien Palard](https://mdk.fr)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SN5RMHWBWKRRP5ZKONKERJY3VQODRZMT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Julien Palard via Python-Dev]

Thanks everyone for the feedback.

I think the best way to handle this is to make the three next releases 
(3.10, 3.11, 3.12) Sphinx 2 and Sphinx 3 compatible, this would gather 
requiered benefits:

- Ease of backporting: from any dev version we can backport 
documentation changes to the previous two releases.
- Ease of packaging: We're not requiering Sphinx 3 today but in like 3 
years, a point where this could be discussed again to see if everyone is 
ready.

If this plan is OK for everyone, I'll try a PR soon™ to make this 
compatibility with Sphinx2/3 land in 3.10.

-- 
[Julien Palard](https://mdk.fr)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VQ5IZPQWJXVXRWCOS5S3Z7DH7YJCONJT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Julien Palard via Python-Dev]

Hi Matthias,

Le 2021-01-13 à 12:27, Matthias Klose a écrit :
> That's not true. Ubuntu 20.04 LTS still sees updates to subminor Python 3.8
> versions, having sphinx 1.8.5.

I do agree to *not* bump our Sphinx dependencies for already published 
Pythons.

Would it be OK to bump Sphinx to 3.2 for Python 3.10? Or would it be 
better to keep Sphinx 2 compatibility for a few years (how many?) before 
requiring Sphinx 3?

Bests,
-- 
[Julien Palard](https://mdk.fr)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PFKZ72A5HD5ZTOXKLN36RYI22Z3QGCGO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Julien Palard via Python-Dev]

Le 2021-01-13 à 00:28, Victor Stinner a écrit :
> Since documentation changes are backported to 3.8 and 3.9 stable
> branches, if we increase the minimum required Sphinx version in
> master, I would prefer to also increase it in 3.8 and 3.9 branches.

Bumping a dependency on the next release is already hard, I don't think 
we can bump dependencies on current releases like Python 3.8.

> I would prefer to not have to check manually if a doc backport PR is
> still compatible with Sphinx 2 or not.

As we're using `-W` flag of sphinx-build, the tests would spot it and 
mark the backport PR as not mergeable. The doc would diverge from a 
branch to another, but it already does, so I do not worry a lot about 
conflicts.

> The alternative is to keep Sphinx 2 support, use
> strip_signature_backslash and don't use :no-trim-doctest-flags: ?

Exact, totally doable for a few years to ease the migration, we could 
even keep Sphinx 1.8 support for a few years as it still works with 
those two "fixes" applied (it would imply reopening 
https://bugs.python.org/issue36675 but I'm not against it).

-- 
[Julien Palard](https://mdk.fr)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E77DZXH4JCQS2Y2TGUHW7QB2Q546SJCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Julien Palard via Python-Dev]

Le 2021-01-13 à 00:09, Senthil Kumaran a écrit :
> Wouldn't this a bug with Sphinx?

No, this is a documented breaking change between Sphinx 2 and Sphinx 3.

> Why would that be special cased with a flag (strip_signature_backslash)?

The strip_signature_backslash has been introduced to allow Sphinx 3 to 
behave like Sphinx 2 in respect of backslash in signatures. It would 
allow us to write Sphinx 2 and Sphinx 3 compatible doc.

> I noticed that you suggested not to backport this PR
> https://github.com/python/cpython/pull/24142

I'm against changing the major version of the Sphinx we use during the 
life of a release. It looks already hard for distrib maintainers to 
handle a Sphinx upgrade for the next release, let's not upgrade it on 
live releases.

In other words: it may or may not be OK to bump Sphinx for a minor 
Python release, but it's clearly not for a patch release (only my point 
of view).

> * Would that mean we have to careful not to use/merge sphinx features like
>`no-trim-doctest-flags` to older docs?

Exactly: backporting a Doc commit could not work, but it would be 
spotted by the tests and not mergeable, as we use `-W` flag of Sphinx 
build (treat warnings as errors).

> * What would it take to keep all active versions of Cpython docs build at the
>same min version (possibly 3.2)?

As said previously, I don't think it's OK to bump Python 3.7 to use 
Sphinx 3 now.

> As Cpython developer, I see nothing bad, but platform maintainers seem to have
> some concerns, and it will be good to see points against this.

That's exactly why I opened this thread, if it's OK for all platform 
maintainers, we'll do this, but if not, we can revert a few commits and 
postpone the Sphinx upgrade, no worries.

-- 
[Julien Palard](https://mdk.fr)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/W5QVYL5L4DMA2BR5J5NNWRJ2KDMRNGX7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Julien Palard via Python-Dev]

During the development of cpython 3.10, Sphinx was bumped to 3.2.1.

Problem is Sphinx 3 have some incompatibilities with Sphinx 2, some that 
we could work around, some are bit harder, so we may need to bump 
`needs_sphinx = '3.2'` (currently it is 1.8).

I found two incompatibilities:

- We're using :no-trim-doctest-flags:, introduced in Sphinx 3.2.0, if we 
build with Sphinx < 3.2.0 the blocks using it are dropped by Sphinx (we 
use it in library/doctest).

- double backslashes in domain directives are no longer replaced by
single backslashes. But a configuration value
(strip_signature_backslash) can be used to have the same behavior on 
Sphinx 2 and 3.

So yes, it's still possible to build the docs with Sphinx 1.8 using
`make html SPHINXERRORHANDLING=`, it "works" but:

- Doctests code blocks using no-trim-doctest-flags dissapear.
- Some functions declarations are lacking a backslash, like
   print(*objects, sep=' ', end='n', ...

Which is bad.

For the first one we could still workaround with an ugly `sed -i 
/no-trim-doctest-flags/d`, or simply stop using it (and reopen bpo-36675).
For the 2nd one we could use `strip_signature_backslash` in cpython 3.10 
to have the same behavior.

So the question is: Should we bump minimum version of Sphinx from 1.8 to 
3.2.1 along with Python 3.10? For the moment this is where we go, but if 
you're having to maintain a release of Python along with Sphinx < 3, 
please make speak.

Conversation has already started here [1] and here [2].

[1]: https://bugs.python.org/issue42843
[2]: https://github.com/python/cpython/pull/24142

-- 
[Julien Palard](https://mdk.fr)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E64YE3DQGOHLFQOJAJHS7VW3PK5KLB4W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Docs: audit event table empty

[Julien Palard via Python-Dev]

Hi Christian,

> the table with auditing events does not render on docs.python.org,
> https://docs.python.org/3.9/library/audit_events.html. Steve and I are
> going to present the auditing feature tomorrow at EuroPython. It would
> be helpful to have the table available.

This was not an easy one... and it may be a Sphinx issue, yet I'm still not 
sure, maybe Steve can shed some light on it:

It's the "-j" option of sphinx-build (to parallelize) that causes the issue. I 
double checked it (full commands at the end of the message in case someone want 
to reproduce it):

- Run with -j4 → No table
- Run without -j → Table is here
- Run again with -j4 → No table!
- Run again without -j → Table is back!

I'm patching docsbuild-scripts to stop using -j4 with is not really helpfull 
anyway as docsbuild script is parallelizing by starting multiple sphinx-build 
(for multiple languages / versions).

I also copied the file and invalidated the cache, so 
https://docs.python.org/3.9/library/audit_events.html is good again.

If I'm too slow testing locally and releasing a new docsbuild_script.py, the 
cron MAY break the file again, don't hesitate to poke me if it happen without 
me noticing first.

Full test:

docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ 
/srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize= -D latex_engine=xelatex -D latex_elements.inputenc= 
-D latex_elements.fontenc= -j4 -q -Ea -A daily=1 -A switchers=1  . build/html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint 
build/html/library/audit_events.html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ 
/srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize= -D latex_engine=xelatex -D latex_elements.inputenc= 
-D latex_elements.fontenc= -q -Ea -A daily=1 -A switchers=1  . build/html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint 
build/html/library/audit_events.html
builtins.breakpoint
breakpointhook
[1]
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ 
/srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize= -D latex_engine=xelatex -D latex_elements.inputenc= 
-D latex_elements.fontenc= -j4 -q -Ea -A daily=1 -A switchers=1  . build/html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint 
build/html/library/audit_events.html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ 
/srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize= -D latex_engine=xelatex -D latex_elements.inputenc= 
-D latex_elements.fontenc= -q -Ea -A daily=1 -A switchers=1  . build/html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint 
build/html/library/audit_events.html
builtins.breakpoint
breakpointhook
[1]

Bests,
-- 
Julien Palard
https://mdk.fr
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q23O23HXTD7MSQGQW4Z5RO4XK5XYW2LZ/

Re: [Python-Dev] Get a running instance of the doc for a PR.

[Julien Palard via Python-Dev]

> I can trivially attach the built docs as a ZIP file to the Azure
> Pipelines build, though that doesn't help the "preview on my phone"

So one can build an HTTP server that gathers doc builds from Azure and expose 
them?

-- 
Julien Palard
https://mdk.fr

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Get a running instance of the doc for a PR.

[Julien Palard via Python-Dev]

Considering feedback from Ned, what about building this as an independent 
service? We don't really need to interface with python.org at all, we just need 
some hardware, a domain, some code to interface with github API and... to start 
it's probably enough? It would be a usefull POC.

-- 
Julien Palard
https://mdk.fr

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Time for 3.4.9 and 3.5.6

[Julien Palard via Python-Dev]

Hi,

[Larry]
> 3.5 also got some doc-only changes related to the online "version switcher" 
> dropdown.

About this I have a question: the switchers for english version of 3.4 and 3.5 
are disabled (https://docs.python.org/3.5/) but not disabled for translations 
(https://docs.python.org/fr/3.5/). I don't see any mention of dropping them in 
PEP 101, and I don't think it's a good thing (UX point of view).

Should I re-enable version and language switchers on 3.5? I think so and I can 
do, just give me the go (or the argument/pointers on why it's disabled).

Bests,
​-- 
Julien Palard
https://mdk.fr​

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 545: Python Documentation Translations

[Julien Palard via Python-Dev]

Hi Brett,

On Wed, 29 Mar 2017 at 13:13 Julien Palard  wrote:

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.

[...]

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-multiple-translations)

Should we just match what Read the Docs does then?

As I prefer our notation (/pt-br/) over Read the Docs one (/pt_BR/), I'd prefer 
if we stick on our notation. They are not against changing and looks like 
they're OK with our notation: 
https://github.com/rtfd/readthedocs.org/issues/2763

--
Julien Palard
https://mdk.fr___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 545: Python Documentation Translations

[Julien Palard via Python-Dev]

Hi, little follow-up about this PEP.

Please check with the PSF that this is what we really want. In the past the 
suggestion has been to **not** use the PSF license with all of its historical 
baggage but instead use something like Apache. But since IANAL we really should 
ask the PSF what the best license for new code is.

I checked with the PSF and after a few emails with VanL (thanks), we concluded 
that we need a "Documentation Contribution Agreement" (they're working on 
writing it), then we'll *just* have to ensure contributors are understanding 
and agreeing with it.

I think we should setup a bot like "The Knights Who Say Ni" from PEP 512 [1]_ 
or The Knight Who Say Ni itself, configured for the "DCLA" what do you think? 
The bot will *only* cover contributions from actual github pull requests, other 
means of contributions like transifex can be enforced by other means, namely:

- We can write a welcome text like "By contributing to this transifex project I 
accept the Documentation Contribution Licence Agreement…".
- We can ask contributors to specifically write they accept the licence 
agreement along witht the translation independently of the way they send us 
translations. (It even work for paper…).

.. [1] PEP 512 -- Migrating from hg.python.org to GitHub
(https://www.python.org/dev/peps/pep-0512/#a-bot-to-enforce-cla-signing)

--
Julien Palard
https://mdk.fr___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 545: Python Documentation Translations

[Julien Palard via Python-Dev]

Hi Jakub,

Typos

Fixed, thanks.

* Julien Palard , 2017-03-29, 07:47:
>It's redundant to display both language and country code if they're the same,
>for example: "de-DE" or "fr-FR".

This wording is unfortunate. It seems to imply that you can meaningfully
compare a language code and a territory code for equality. This is not the
case. For example, Belarusian (language code "be") is mainly spoken in Belarus
(country code "by"), not in Belgium (country code "be").

Thanks for noticing, would the intented meaning is "when they add no 
distinguishing information", is it better like:

==
We may drop the region subtag when it does does not add
distinguishing information, for example: "de-DE" or "fr-FR".
(Although it might make sense, respectively meaning "German as
spoken in Germany" and "French as spoken in France"). But when
the region subtag actually adds information, for example "pt-BR"
for "Portuguese as spoken in Brazil", it should be kept.
==

?

Bests,
--
Julien Palard
https://mdk.fr___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 545: Python Documentation Translations

[Julien Palard via Python-Dev]

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-multiple-translations)

--
Julien Palard
[https://mdk.fr](https://mdk.fr/)___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 545: Python Documentation Translations

[Julien Palard via Python-Dev]

Hi.

Here's PEP 545, ready to be reviewed!
This is the follow-up to the "PEP: Python Documentation Translations" thread on 
python-ideas [1]_,
itself a follow-up of the "Translated Python documentation" thread on 
python-dev [2]_.

This PEP describes the steps to make existing and future translations of the 
Python documentation official and accessible on docs.python.org.

You can read it rendered here https://www.python.org/dev/peps/pep-0545/ or 
inline here, I'll happily get your feedback.


PEP: 545
Title: Python Documentation Translations
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner ,
Inada Naoki ,
Julien Palard 
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 04-Mar-2017

Abstract


The intent of this PEP is to make existing translations of the Python
Documentation more accessible and discoverable. By doing so, we hope
to attract and motivate new translators and new translations.

Translated documentation will be hosted on python.org. Examples of
two active translation teams:

* http://docs.python.org/fr/: French
* http://docs.python.org/ja/: Japanese

http://docs.python.org/en/ will redirect to http://docs.python.org/.

Sources of translated documentation will be hosted in the Python
organization on GitHub: https://github.com/python/. Contributors will
have to sign the Python Contributor Agreement (CLA) and the license
will be the PSF License.

Motivation
==

On the French ``#python-fr`` IRC channel on freenode, it's not rare to
meet people who don't speak English and so are unable to read the
Python official documentation. Python wants to be widely available
to all users in any language: this is also why Python 3 supports
any non-ASCII identifiers:
https://www.python.org/dev/peps/pep-3131/#rationale

There are a least 3 groups of people who are translating the Python
documentation to their native language (French [16]_ [17]_ [18]_,
Japanese [19]_ [20]_, Spanish [21]_) even though their translations
are not visible on d.p.o. Other, less visible and less organized
groups, are also translating the documentation, we've heard of Russian
[26]_, Chinese and Korean. Others we haven't found yet might also
exist. This PEP defines rules describing how to move translations on
docs.python.org so they can easily be found by developers, newcomers
and potential translators.

The Japanese team has (as of March 2017) translated ~80% of the
documentation, the French team ~20%. French translation went from 6%
to 23% in 2016 [13]_ with 7 contributors [14]_, proving a translation
team can be faster than the rate the documentation mutates.

Quoting Xiang Zhang about Chinese translations:

I have seen several groups trying to translate part of our official
doc. But their efforts are disperse and quickly become lost because
they are not organized to work towards a single common result and
their results are hold anywhere on the Web and hard to find. An
official one could help ease the pain.

Rationale
=

Translation
---

Issue tracker
'

Considering that issues opened about translations may be written in
the translation language, which can be considered noise but at least
is inconsistent, issues should be placed outside `bugs.python.org
`_ (b.p.o).

As all translation must have their own github project (see `Repository
for Po Files`_), they must use the associated github issue tracker.

Considering the noise induced by translation issues redacted in any
languages which may beyond every warnings land in b.p.o, triage will
have to be done. Considering that translations already exist and are
not actually a source of noise in b.p.o, an unmanageable amount of
work is not to be expected. Considering that Xiang Zhang and Victor
Stinner are already triaging, and Julien Palard is willing to help on
this task, noise on b.p.o is not to be expected.

Also, language team coordinators (see `Language Team`_) should help
with triaging b.p.o by properly indicating, in the language of the
issue author if required, the right issue tracker.

Branches


Translation teams should focus on last stable versions, and use tools
(scripts, translation memory, …) to automatically translate what is
done in one branch to other branches.

.. note::
Translation memories are a kind of database of previously translated
paragraphs, even removed ones. See also `Sphinx Internationalization
`_.

The three currently stable branches that will be translated are [12]_:
2.7, 3.5, and 3.6. The scripts to build the documentation of older
branches needs to be modified to support translation [12]_, whereas
these branches now only accept security-only fixes.

The development branch (master) should have a lower translation priority
than stable branches. But docsbuild-scripts should build it anyway so
it is