https://docs.python.org/fr/ ?
o/
The french translation of the Python Documentation [1][2] has translated 20% of the pageviews of docs.python.org. I think it's the right moment to push it do docs.python.org. So there's some questions ! And I'd like feedback.
TL;DR (with my personal choices): - URL may be "http://docs.python.org/fr/" - For localized variations of languages we should use dash and lowercase like "docs.python.org/pt-br/" - po files may be hosted on the python's github - existing script to build doc may be patched to build translations - each translations may crosslink to others - untranslated strings may be visually marked as so
I also opened: http://bugs.python.org/issue26546.
# Chronology, dependencies
The only blocking decision here is the URL, (also reviewing my patch ...), with those two, translated docs can be pushed to production, and the other steps can be discussed and applied one by one.
# The URL
## CCTLD vs path vs subdomain
I think we should use a variation of "docs.python.org/fr/" for simplicity and clarity.
I think we should avoid using CCTLDs as they're sometime hard or near impossible to obtain (may cost a lot of time), also some are expensive, so it's time and money we clearly don't need to loose.
Last possibility I see is to use a subdomain, like fr.docs.python.org or docs.fr.python.org but I don't think it's the role / responsibility of the sub-domain to do it.
So I'm for docs.python.org/LANGUAGE_TAG/ (without moving current documentation inside a /en/).
## Language tag in path
### Dropping the default locale of a language
I personally think we should not show the region in case it's redundant: so to use "fr" instead of "fr-FR", "de" instead of "de-DE", but keeping the possibility to use a locale code when it's not redundant like for "pt-br" or "de-AT" (German ('de') as used in Austria ('AT')).
I think so because I don't think we'll have a lot of locale variations (like de-AT, fr-CH, fr-CA, ...) so it will be most of the time redundant (visually heavy, longer to type, longer to read) but we'll still need some locale (pt-BR typically).
### gettext VS IETF language tag format
gettext goes by using an underscore between language and locale [3] and IETF goes by using a dash [4][5].
As sphinx is using gettext, and gettext uses underscore we may choose underscore too. But URLs are not here to leak the underlying implementation, and the IETF looks like to be the standard way to represent language tags. Also I visually prefer the dash over the underscore, so I'm for the dash here.
### Lower case vs upper case local tag
RFC 5646 section-2.1 tells us language tags are not case sensitive, yet ISO3166-1 recommends that country codes (part of the language tag) be capitalized. I personally prefer the all-lowercase one as paths in URLs typically are lowercase. I searched for `inurl:"pt-br"` to see if I'm not too far away from the usage here and usage seems to agree with me, although there's some "pt-BR" in urls.
# Where to host the translated files
Currently we're hosting the *po* files in the afpy's (Francophone association for python) [6] github [1] but it may make sense to use (in the generation scripts) a more controlled / restricted clone in the python github, at least to have a better view of who can push on the documentation.
We may want to choose between aggregating all translations under the same git repository but I don't feel it's useful.
# How to
Currently, a python script [7] is used to generate `docs.python.org`, I proposed a patch in [8] to make this script clone and build the french translation too, it's a simple and effective way, I don't think we need more ? Any idea welcome.
In our side, we have a Makefile [12] to build the translated doc which is only a thin layer on top of the Sphinx Makefile. So my proposed patch to build scripts "just" delegate the build to our Makefile which itself delegate the hard work to the Sphinx Makefile.
# Next ?
## Document how to translate Python
I think I can (should) write a documentation on "how to start a Python doc translation project" and "how to migrate existing [9][10][11] python doc translation projects to docs.python.org" if french does goes docs.python.org because it may hopefully motivate people to do the same, and I think our structure is a nice way to do it (A Makefile to generate the doc, all versions translated, people mainly working on latest version, scripts to propagating translations to older version, etc...).
## Crosslinking between existing translations
Once the translations are on `docs.python.org`, crosslinks may be established so people on a version can be aware of other version, and easily switch to them. I'm not a UI/UX man but I think we may have a select box right before the existing select box about version, on the top-left corner. Right before because it'll reflect the path: /fr/3.5/ -> [select box fr][select box 3.5].
## Marking as "untranslated, you can help" the untranslated paragraphs
The translations will always need work to follow upstream modifications: marking untranslated paragraphs as so may transform the "Oh they suck, this paragraph is not even translated :-(" to "Hey, nice I can help translating that !". There's an opened sphinx-doc ticket to do so [13] but I have not worked on it yet. As previously said I'm real bad at designing user interfaces, so I don't even visualize how I'd like it to be.
[1] http://www.afpy.org/doc/python/3.5/ [2] https://github.com/afpy/python_doc_fr [3] https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html [4] http://tools.ietf.org/html/rfc5646 [5] https://en.wikipedia.org/wiki/IETF_language_tag [6] http://www.afpy.org/ [7] https://github.com/python/docsbuild-scripts/ [8] http://bugs.python.org/issue26546 [9] http://docs.python.jp/3/ [10] https://github.com/python-doc-ja/python-doc-ja [11] http://docs.python.org.ar/tutorial/3/index.html [12] https://github.com/AFPy/python_doc_fr/blob/master/Makefile [13] https://github.com/sphinx-doc/sphinx/issues/1246
Hi,
2016-03-19 17:30 GMT+01:00 Julien Palard julien@palard.fr:
The french translation of the Python Documentation [1][2] has translated 20% of the pageviews of docs.python.org. I think it's the right moment to push it do docs.python.org. So there's some questions ! And I'd like feedback.
Nice.
TL;DR (with my personal choices):
- URL may be "http://docs.python.org/fr/"
- ...
- existing script to build doc may be patched to build translations
If we choose to officially have translated documentation, I suggest to ensure that it has the same content thant the english. I don't want to read an outdated translated doc. I mean that all doc (en+fr) must be recompiled when a patch is merged.
- ...
- untranslated strings may be visually marked as so
I don't think that it's needed. It's quite easy to notice untranslated parts...
### Dropping the default locale of a language
I personally think we should not show the region in case it's redundant: so to use "fr" instead of "fr-FR", "de" instead of "de-DE", but keeping the possibility to use a locale code when it's not redundant like for "pt-br" or "de-AT" (German ('de') as used in Austria ('AT')).
IMHO we should see what PHP did, since PHP has a long history with documentation translation.
http://php.net/manual/en/function.strlen.php http://php.net/manual/fr/function.strlen.php http://php.net/manual/pt_BR/function.strlen.php
So /fr/ for french, but /pt_BR/ for Brazilian Portuguese. We can use something similar for Python.
They chose to have /en/ in the URL of the original (english) documentation, *but* http://php.net/strlen is the translated doc. I would really prefer to not move on more time the Python doc (add /en/ to the URL), since *a lot* of articles have references to the Python doc. Or if you really want to do that, please add redirection (forever?).
I'm lazy and I really like writing http://php.net/<function name> to get the documentation of a function.
It's much more difficult to get the doc of len in the Python doc...
### gettext VS IETF language tag format
gettext goes by using an underscore between language and locale [3] and IETF goes by using a dash [4][5].
PHP chose an underscore, it's more common in URLs. I prefer pt_BR.
Anyway, users will use a dropdown list rather than explicitly writing the URL, no?
# Where to host the translated files
Currently we're hosting the *po* files in the afpy's (Francophone association for python) [6] github [1] but it may make sense to use (in the generation scripts) a more controlled / restricted clone in the python github, at least to have a better view of who can push on the documentation.
We may want to choose between aggregating all translations under the same git repository but I don't feel it's useful.
Do you plan to use a web UI to allow anyone to translate easily the doc? It may have an impact on the authentication system. Should such contribution be pushed directly and become a draft which requires a review?
## Crosslinking between existing translations
Once the translations are on `docs.python.org`, crosslinks may be established so people on a version can be aware of other version, and easily switch to them. I'm not a UI/UX man but I think we may have a select box right before the existing select box about version, on the top-left corner. Right before because it'll reflect the path: /fr/3.5/ -> [select box fr][select box 3.5].
Usually (on web sites, the language is chosen at the top right.
Victor
Hi,
On 03/21/2016 11:38 AM, Victor Stinner wrote:
Hi,
If we choose to officially have translated documentation, I suggest to ensure that it has the same content thant the english. I don't want to read an outdated translated doc. I mean that all doc (en+fr) must be recompiled when a patch is merged.
I like the idea of running "msgmerge" at each patch so outdated translations are rapidly removed (marked as "fuzzy"), it's probably possible and easy. Our makefile provide a "msgmerge_all" to do that on all versions. I'll keep it in mind.
- ...
- untranslated strings may be visually marked as so
I don't think that it's needed. It's quite easy to notice untranslated parts...
It's strongly linked to your "Do you plan to use a web UI to allow anyone to translate easily": I think we should provide a simple way to propose little corrections or even whole paragraph translations, but:
- Not soon, the project does not depend on it and it's more a Sphinx-doc feature than a Python documentations feature, it should be treated separately. - From my point of view, proposed translations goes to a moderation queue, they can't be accepted directly. - Some services like crowdin (on which we have an unlimited free plan, thanks Crowdin !) provide those kind of features (and crowdin is already interfaced with poedit). However I have not used crowdin that much and still prefer poedit+git for that. We may also write a git bot auto-generating pull requests... Many ideas here, that we should probably discuss in a sphinx-related issue or mailing list.
### Dropping the default locale of a language
IMHO we should see what PHP did, since PHP has a long history with documentation translation.
So /fr/ for french, but /pt_BR/ for Brazilian Portuguese. We can use something similar for Python.
Dropping a redundant local (fr_FR -> fr) seems logic, but I still prefer "pt-br" over "pt_BR", counterbalancing the PHP doc using "pt_BR" we have some big player using pt-br like: - wordpress: https://codex.wordpress.org/pt-br:Codex_Multilingua - facebook: https://pt-br.facebook.com/login/ - msn: www.msn.com/pt-br/ - skype: www.skype.com/pt-br
I would really prefer to not move on more time the Python doc (add /en/ to the URL),
I agree, we don't have to move the actual doc under `/en/`. If setting redirections we can set them from `/en/` to `/` just in case someone modify /fr/ to /en/ manually.
I'm lazy and I really like writing http://php.net/<function name> to get the documentation of a function.
It's much more difficult to get the doc of len in the Python doc...
That's a whole other subject, but as we're on it, instead of giving a 404 for https://docs.python.org/3.5/len or even https://docs.python.org/len why not displaying a search result page with hopefully len as a first result ? I was sur I read some RFC telling that a 404 should return "relevant links" but can't find it in the 2616 :(
### gettext VS IETF language tag format
gettext goes by using an underscore between language and locale [3] and IETF goes by using a dash [4][5].
PHP chose an underscore, it's more common in URLs. I prefer pt_BR.
I can only disagree, dashes seems more common than underscores in URLs from my point of view, see typically slugs (https://en.wikipedia.org/wiki/Semantic_URL#Slug) but my link contradicts itself with a "Semantic_URL" instead of a "Semantic-URL" ... slugs (with dashes) are commonly used like at stackoverflow, yahoo, amazon, the Python doc itself (https://docs.python.org/3.5/library/stdtypes.html#numeric-types-int-float-co...),
Also the Google recommendation "We recommend that you use hyphens (-) instead of underscores (_) in your URLs." https://support.google.com/webmasters/answer/76329?hl=en
There are some updates about this topic. And I have something to discuss to get things forward.
We (Japanese translation team) and Julien start sharing one Transifex project. Please see this dashboard. We have nice progress. https://www.transifex.com/python-doc/python-35/dashboard/
Julien want hosting french documentation at https://docs.python.org/fr/ I don't have strong opinion about where to hosting, but I want to share more efforts (automated build + hosting) with Julien and other language communities.
Since Berker Peksag against about hosting translated document on docs.python.org [1], I'm considering about using github pages.
I got "python-docs" organization already for it [2]. So translated documents can be hosted on URL like https://python-docs.github.io/py35-ja/ or https://python-docs.github.io/py35/fr/ . (first part of the path should be same to repository name).
I already uses github pages for testing Japanese translation [3]. It's nice place to host webpage. We can get https and CDN for free.
[1]: https://github.com/python/docsbuild-scripts/pull/8 [2]: https://github.com/python-docs [3]: https://python-doc-ja.github.io/py35/
So I want to discuss (and get consensus) about where should we host translated document.
a) translated docs on docs.python.org / issue tracker on github.com/python-docs/ b) translated docs on python-docs.github.io / issue tracker on github.com/python-docs/ c) We shouldn't use neither "python-docs" nor "docs.python.org". Translation should be in other community. d) Other idea?
What do you think?
Regards,
On Sun, Mar 20, 2016 at 1:30 AM, Julien Palard julien@palard.fr wrote:
o/
The french translation of the Python Documentation [1][2] has translated 20% of the pageviews of docs.python.org. I think it's the right moment to push it do docs.python.org. So there's some questions ! And I'd like feedback.
TL;DR (with my personal choices):
- URL may be "http://docs.python.org/fr/"
- For localized variations of languages we should use dash and lowercase
like "docs.python.org/pt-br/"
- po files may be hosted on the python's github
- existing script to build doc may be patched to build translations
- each translations may crosslink to others
- untranslated strings may be visually marked as so
I also opened: http://bugs.python.org/issue26546.
# Chronology, dependencies
The only blocking decision here is the URL, (also reviewing my patch ...), with those two, translated docs can be pushed to production, and the other steps can be discussed and applied one by one.
# The URL
## CCTLD vs path vs subdomain
I think we should use a variation of "docs.python.org/fr/" for simplicity and clarity.
I think we should avoid using CCTLDs as they're sometime hard or near impossible to obtain (may cost a lot of time), also some are expensive, so it's time and money we clearly don't need to loose.
Last possibility I see is to use a subdomain, like fr.docs.python.org or docs.fr.python.org but I don't think it's the role / responsibility of the sub-domain to do it.
So I'm for docs.python.org/LANGUAGE_TAG/ (without moving current documentation inside a /en/).
## Language tag in path
### Dropping the default locale of a language
I personally think we should not show the region in case it's redundant: so to use "fr" instead of "fr-FR", "de" instead of "de-DE", but keeping the possibility to use a locale code when it's not redundant like for "pt-br" or "de-AT" (German ('de') as used in Austria ('AT')).
I think so because I don't think we'll have a lot of locale variations (like de-AT, fr-CH, fr-CA, ...) so it will be most of the time redundant (visually heavy, longer to type, longer to read) but we'll still need some locale (pt-BR typically).
### gettext VS IETF language tag format
gettext goes by using an underscore between language and locale [3] and IETF goes by using a dash [4][5].
As sphinx is using gettext, and gettext uses underscore we may choose underscore too. But URLs are not here to leak the underlying implementation, and the IETF looks like to be the standard way to represent language tags. Also I visually prefer the dash over the underscore, so I'm for the dash here.
### Lower case vs upper case local tag
RFC 5646 section-2.1 tells us language tags are not case sensitive, yet ISO3166-1 recommends that country codes (part of the language tag) be capitalized. I personally prefer the all-lowercase one as paths in URLs typically are lowercase. I searched for `inurl:"pt-br"` to see if I'm not too far away from the usage here and usage seems to agree with me, although there's some "pt-BR" in urls.
# Where to host the translated files
Currently we're hosting the *po* files in the afpy's (Francophone association for python) [6] github [1] but it may make sense to use (in the generation scripts) a more controlled / restricted clone in the python github, at least to have a better view of who can push on the documentation.
We may want to choose between aggregating all translations under the same git repository but I don't feel it's useful.
# How to
Currently, a python script [7] is used to generate `docs.python.org`, I proposed a patch in [8] to make this script clone and build the french translation too, it's a simple and effective way, I don't think we need more ? Any idea welcome.
In our side, we have a Makefile [12] to build the translated doc which is only a thin layer on top of the Sphinx Makefile. So my proposed patch to build scripts "just" delegate the build to our Makefile which itself delegate the hard work to the Sphinx Makefile.
# Next ?
## Document how to translate Python
I think I can (should) write a documentation on "how to start a Python doc translation project" and "how to migrate existing [9][10][11] python doc translation projects to docs.python.org" if french does goes docs.python.org because it may hopefully motivate people to do the same, and I think our structure is a nice way to do it (A Makefile to generate the doc, all versions translated, people mainly working on latest version, scripts to propagating translations to older version, etc...).
## Crosslinking between existing translations
Once the translations are on `docs.python.org`, crosslinks may be established so people on a version can be aware of other version, and easily switch to them. I'm not a UI/UX man but I think we may have a select box right before the existing select box about version, on the top-left corner. Right before because it'll reflect the path: /fr/3.5/ -> [select box fr][select box 3.5].
## Marking as "untranslated, you can help" the untranslated paragraphs
The translations will always need work to follow upstream modifications: marking untranslated paragraphs as so may transform the "Oh they suck, this paragraph is not even translated :-(" to "Hey, nice I can help translating that !". There's an opened sphinx-doc ticket to do so [13] but I have not worked on it yet. As previously said I'm real bad at designing user interfaces, so I don't even visualize how I'd like it to be.
[1] http://www.afpy.org/doc/python/3.5/ [2] https://github.com/afpy/python_doc_fr [3] https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html [4] http://tools.ietf.org/html/rfc5646 [5] https://en.wikipedia.org/wiki/IETF_language_tag [6] http://www.afpy.org/ [7] https://github.com/python/docsbuild-scripts/ [8] http://bugs.python.org/issue26546 [9] http://docs.python.jp/3/ [10] https://github.com/python-doc-ja/python-doc-ja [11] http://docs.python.org.ar/tutorial/3/index.html [12] https://github.com/AFPy/python_doc_fr/blob/master/Makefile [13] https://github.com/sphinx-doc/sphinx/issues/1246
-- Julien Palard _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 1/30/2017 4:21 AM, INADA Naoki wrote:
A followup to Julien Palard's post Mar 2016.
We (Japanese translation team) and Julien start sharing one Transifex project.
I am in favor of translations AND of making them easy to find. Sharing infrastructure seems sensible. Aside from the base url, I think each repository should mimic the current hierarchical structure of docs.python.org: .../version/document/page.html#paragraph
Please see this dashboard. We have nice progress. https://www.transifex.com/python-doc/python-35/dashboard/
Julien want hosting french documentation at https://docs.python.org/fr/
and doc.python.org/jp, es, etc, as discussed in https://bugs.python.org/issue26546
Regardless of where the pages are physically located, which is to say, what the real base url is, I presume that docs.python.org/fr could be redirected to that location. Assuming a duplicated page hierarchy as suggested above, this would mean that one could access a translation of a page by inserting the country code into the url on the url bar.
This in turn means that one could open both English original and translation on side-by-side tabs or windows by right-clicking on one of the permalinks on the page and selecting 'Open in new tab/window' and then opening translation on the current tab, as suggested above. (This could be made easier, but is good enough to start.)
I don't have strong opinion about where to hosting, but I want to share more efforts (automated build + hosting) with Julien and other language communities.
Since Berker Peksag against about hosting translated document on docs.python.org [1],
I read the discussion and Berker is understandably against having to deal with translation issues on bugs.python.org.
To mitigate against this, each translated page should have at the top the equivalent of
"This is an unofficial translation of <link to original>. It may be either incomplete or incorrect. Found a translation bug?" The last would link to a language-appropriate version of https://docs.python.org/3/bugs.html. In the page footer, "Fould a bug" and its link would be similarly replaced. If it seems necessary, use the red warning colors.
On bugs.python.org, 'Documentation' could be augmented to 'Documentation - English original' Note that this is still a character short of the longest component: '2to3 (2.x to 3.x conversion tool)'
My impression is that one of the arguments for moving to githup was that we could somehow enable people to submit doc pull requests while reading the web page. (I don't know the details.) The hope was and would be that this would mostly eliminate tracker issues for simple typo fixes, which are a nuisance in the sense of having a high overhead to improvement ratio. Any such requests generated on translated page would go to the translation site.
If in spite of the above and any other efforts, there were still misdirected reports on bugs.python.org, the translators should deal with them. In any case, Berker and anyone else could ignore them.
A last resort would be to remove the redirect links.
On Mon, Jan 30, 2017 at 12:21 PM, INADA Naoki songofacandy@gmail.com wrote:
There are some updates about this topic. And I have something to discuss to get things forward.
We (Japanese translation team) and Julien start sharing one Transifex project. Please see this dashboard. We have nice progress. https://www.transifex.com/python-doc/python-35/dashboard/
Julien want hosting french documentation at https://docs.python.org/fr/ I don't have strong opinion about where to hosting, but I want to share more efforts (automated build + hosting) with Julien and other language communities.
Since Berker Peksag against about hosting translated document on docs.python.org [1], I'm considering about using github pages.
I got "python-docs" organization already for it [2]. So translated documents can be hosted on URL like https://python-docs.github.io/py35-ja/ or https://python-docs.github.io/py35/fr/ . (first part of the path should be same to repository name).
I already uses github pages for testing Japanese translation [3]. It's nice place to host webpage. We can get https and CDN for free.
So I want to discuss (and get consensus) about where should we host translated document.
a) translated docs on docs.python.org / issue tracker on github.com/python-docs/ b) translated docs on python-docs.github.io / issue tracker on github.com/python-docs/
+1 for b) or any idea that would indicate that the Python developers don't maintain translations of the official documentation. I don't have a strong opinion on naming the GitHub organization (maybe python-docs-translations?) but that can be discussed later. Another advantage of this approach is that you can have separate issue trackers for each language (e.g. python-docs-fr) so people can easily report documentation issues in their native languages.
--Berker
On Mon, 30 Jan 2017 at 07:16 Berker Peksağ berker.peksag@gmail.com wrote:
On Mon, Jan 30, 2017 at 12:21 PM, INADA Naoki songofacandy@gmail.com wrote:
There are some updates about this topic. And I have something to discuss to get things forward.
We (Japanese translation team) and Julien start sharing one Transifex
project.
Please see this dashboard. We have nice progress. https://www.transifex.com/python-doc/python-35/dashboard/
Julien want hosting french documentation at https://docs.python.org/fr/ I don't have strong opinion about where to hosting, but I want to share more efforts (automated build + hosting) with Julien and other language communities.
Since Berker Peksag against about hosting translated document on docs.python.org [1], I'm considering about using github pages.
I got "python-docs" organization already for it [2]. So translated
documents
can be hosted on URL like https://python-docs.github.io/py35-ja/ or https://python-docs.github.io/py35/fr/ . (first part of the path should be same to repository name).
I already uses github pages for testing Japanese translation [3]. It's nice place to host webpage. We can get https and CDN for free.
So I want to discuss (and get consensus) about where should we host translated document.
a) translated docs on docs.python.org / issue tracker on
github.com/python-docs/
b) translated docs on python-docs.github.io / issue tracker on github.com/python-docs/
+1 for b) or any idea that would indicate that the Python developers don't maintain translations of the official documentation. I don't have a strong opinion on naming the GitHub organization (maybe python-docs-translations?) but that can be discussed later. Another advantage of this approach is that you can have separate issue trackers for each language (e.g. python-docs-fr) so people can easily report documentation issues in their native languages.
Does hosting on Read the Docs makes any of this easier/harder?
On 30 January 2017 at 19:03, Brett Cannon brett@python.org wrote:
On Mon, 30 Jan 2017 at 07:16 Berker Peksağ berker.peksag@gmail.com wrote:
+1 for b) or any idea that would indicate that the Python developers don't maintain translations of the official documentation. I don't have a strong opinion on naming the GitHub organization (maybe python-docs-translations?) but that can be discussed later. Another advantage of this approach is that you can have separate issue trackers for each language (e.g. python-docs-fr) so people can easily report documentation issues in their native languages.
Does hosting on Read the Docs makes any of this easier/harder?
RTD models translations as separate projects, so it should make it easier: http://docs.readthedocs.io/en/latest/localization.html#project-with-multiple...
Most importantly, because they're separate projects, each translation will get to set its own project home page and source control repo reference.
It will still be up to translation authors to make some of the manual changes that Terry mentions to point people to the right issue trackers, but it shouldn't be any worse than what we see with occasionally redirecting people to the Python Packaging Authority issue trackers for various purposes.
Cheers, Nick.
Does hosting on Read the Docs makes any of this easier/harder?
RTD models translations as separate projects, so it should make it easier: http://docs.readthedocs.io/en/latest/localization.html#project-with-multiple...
Most importantly, because they're separate projects, each translation will get to set its own project home page and source control repo reference.
I haven't know RTD supports i18n!
But we split repository of Python and *.po files. So we need Travis or other CI server.
Current our build script is here. https://github.com/python-doc-ja/py35-locale/blob/master/.travis.yml
participants (7)
-
Berker Peksağ -
Brett Cannon -
INADA Naoki -
Julien Palard -
Nick Coghlan -
Terry Reedy -
Victor Stinner