<div>Hi.<br></div><div><br></div><div>Here's PEP 545, ready to be reviewed!<br></div><div>This is the follow-up to the "PEP: Python Documentation Translations" thread on python-ideas [1]_,<br></div><div>itself a follow-up of the "Translated Python documentation" thread on python-dev [2]_.<br></div><div><br></div><div>This PEP describes the steps to make existing and future translations of the Python documentation official and accessible on docs.python.org.<br></div><div><br></div><div>You can read it rendered here <a href="https://www.python.org/dev/peps/pep-0545/">https://www.python.org/dev/peps/pep-0545/</a> or inline here, I'll happily get your feedback.</div><div><br></div><div>========================================<br></div><div>PEP: 545<br></div><div>Title: Python Documentation Translations<br></div><div>Version: $Revision$<br></div><div>Last-Modified: $Date$<br></div><div>Author: Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>>,<br></div><div> Inada Naoki <<a href="mailto:songofacandy@gmail.com">songofacandy@gmail.com</a>>,<br></div><div> Julien Palard <<a href="mailto:julien@palard.fr">julien@palard.fr</a>><br></div><div>Status: Draft<br></div><div>Type: Process<br></div><div>Content-Type: text/x-rst<br></div><div>Created: 04-Mar-2017<br></div><div><br></div><div><br></div><div>Abstract<br></div><div>========<br></div><div><br></div><div>The intent of this PEP is to make existing translations of the Python<br></div><div>Documentation more accessible and discoverable. By doing so, we hope<br></div><div>to attract and motivate new translators and new translations.<br></div><div><br></div><div>Translated documentation will be hosted on python.org. Examples of<br></div><div>two active translation teams:<br></div><div><br></div><div>* <a href="http://docs.python.org/fr/">http://docs.python.org/fr/</a>: French<br></div><div>* <a href="http://docs.python.org/ja/">http://docs.python.org/ja/</a>: Japanese<br></div><div><br></div><div><a href="http://docs.python.org/en/">http://docs.python.org/en/</a> will redirect to <a href="http://docs.python.org/">http://docs.python.org/</a>.<br></div><div><br></div><div>Sources of translated documentation will be hosted in the Python<br></div><div>organization on GitHub: <a href="https://github.com/python/">https://github.com/python/</a>. Contributors will<br></div><div>have to sign the Python Contributor Agreement (CLA) and the license<br></div><div>will be the PSF License.<br></div><div><br></div><div><br></div><div>Motivation<br></div><div>==========<br></div><div><br></div><div>On the French ``#python-fr`` IRC channel on freenode, it's not rare to<br></div><div>meet people who don't speak English and so are unable to read the<br></div><div>Python official documentation. Python wants to be widely available<br></div><div>to all users in any language: this is also why Python 3 supports<br></div><div>any non-ASCII identifiers:<br></div><div><a href="https://www.python.org/dev/peps/pep-3131/#rationale">https://www.python.org/dev/peps/pep-3131/#rationale</a><br></div><div><br></div><div>There are a least 3 groups of people who are translating the Python<br></div><div>documentation to their native language (French [16]_ [17]_ [18]_,<br></div><div>Japanese [19]_ [20]_, Spanish [21]_) even though their translations<br></div><div>are not visible on d.p.o. Other, less visible and less organized<br></div><div>groups, are also translating the documentation, we've heard of Russian<br></div><div>[26]_, Chinese and Korean. Others we haven't found yet might also<br></div><div>exist. This PEP defines rules describing how to move translations on<br></div><div>docs.python.org so they can easily be found by developers, newcomers<br></div><div>and potential translators.<br></div><div><br></div><div>The Japanese team has (as of March 2017) translated ~80% of the<br></div><div>documentation, the French team ~20%. French translation went from 6%<br></div><div>to 23% in 2016 [13]_ with 7 contributors [14]_, proving a translation<br></div><div>team can be faster than the rate the documentation mutates.<br></div><div><br></div><div><br></div><div>Quoting Xiang Zhang about Chinese translations:<br></div><div><br></div><div> I have seen several groups trying to translate part of our official<br></div><div> doc. But their efforts are disperse and quickly become lost because<br></div><div> they are not organized to work towards a single common result and<br></div><div> their results are hold anywhere on the Web and hard to find. An<br></div><div> official one could help ease the pain.<br></div><div><br></div><div><br></div><div>Rationale<br></div><div>=========<br></div><div><br></div><div>Translation<br></div><div>-----------<br></div><div><br></div><div>Issue tracker<br></div><div>'''''''''''''<br></div><div><br></div><div>Considering that issues opened about translations may be written in<br></div><div>the translation language, which can be considered noise but at least<br></div><div>is inconsistent, issues should be placed outside `bugs.python.org<br></div><div><<a href="https://bugs.python.org/">https://bugs.python.org/</a>>`_ (b.p.o).<br></div><div><br></div><div>As all translation must have their own github project (see `Repository<br></div><div>for Po Files`_), they must use the associated github issue tracker.<br></div><div><br></div><div>Considering the noise induced by translation issues redacted in any<br></div><div>languages which may beyond every warnings land in b.p.o, triage will<br></div><div>have to be done. Considering that translations already exist and are<br></div><div>not actually a source of noise in b.p.o, an unmanageable amount of<br></div><div>work is not to be expected. Considering that Xiang Zhang and Victor<br></div><div>Stinner are already triaging, and Julien Palard is willing to help on<br></div><div>this task, noise on b.p.o is not to be expected.<br></div><div><br></div><div>Also, language team coordinators (see `Language Team`_) should help<br></div><div>with triaging b.p.o by properly indicating, in the language of the<br></div><div>issue author if required, the right issue tracker.<br></div><div><br></div><div><br></div><div>Branches<br></div><div>''''''''<br></div><div><br></div><div>Translation teams should focus on last stable versions, and use tools<br></div><div>(scripts, translation memory, …) to automatically translate what is<br></div><div>done in one branch to other branches.<br></div><div><br></div><div>.. note::<br></div><div> Translation memories are a kind of database of previously translated<br></div><div> paragraphs, even removed ones. See also `Sphinx Internationalization<br></div><div> <<a href="http://www.sphinx-doc.org/en/stable/intl.html">http://www.sphinx-doc.org/en/stable/intl.html</a>>`_.<br></div><div><br></div><div>The three currently stable branches that will be translated are [12]_:<br></div><div>2.7, 3.5, and 3.6. The scripts to build the documentation of older<br></div><div>branches needs to be modified to support translation [12]_, whereas<br></div><div>these branches now only accept security-only fixes.<br></div><div><br></div><div>The development branch (master) should have a lower translation priority<br></div><div>than stable branches. But docsbuild-scripts should build it anyway so<br></div><div>it is possible for a team to work on it to be ready for the next<br></div><div>release.<br></div><div><br></div><div><br></div><div>Hosting<br></div><div>-------<br></div><div><br></div><div>Domain Name, Content negotiation and URL<br></div><div>''''''''''''''''''''''''''''''''''''''''<br></div><div><br></div><div>Different translations can be identified by changing one of the<br></div><div>following: Country Code Top Level Domain (CCTLD),<br></div><div>path segment, subdomain or content negotiation.<br></div><div><br></div><div>Buying a CCTLD for each translations is expensive, time-consuming, and<br></div><div>sometimes almost impossible when already registered, this solution<br></div><div>should be avoided.<br></div><div><br></div><div>Using subdomains like "es.docs.python.org" or "docs.es.python.org" is<br></div><div>possible but confusing ("is it `es.docs.python.org` or<br></div><div>`docs.es.python.org`?"). Hyphens in subdomains like<br></div><div>`pt-br.doc.python.org` is uncommon and SEOMoz [23]_ correlated the<br></div><div>presence of hyphens as a negative factor. Usage of underscores in<br></div><div>subdomain is prohibited by the RFC1123 [24]_, section 2.1. Finally,<br></div><div>using subdomains means creating TLS certificates for each<br></div><div>language. This not only requires more maintenance but will also cause<br></div><div>issues in language switcher if, as for version switcher, we want a<br></div><div>preflight to check if the translation exists in the given version:<br></div><div>preflight will probably be blocked by same-origin-policy. Wildcard<br></div><div>TLS certificates are very expensive.<br></div><div><br></div><div>Using content negotiation (HTTP headers ``Accept-Language`` in the<br></div><div>request and ``Vary: Accept-Language``) leads to a bad user experience<br></div><div>where they can't easily change the language. According to Mozilla:<br></div><div>"This header is a hint to be used when the server has no way of<br></div><div>determining the language via another way, like a specific URL, that is<br></div><div>controlled by an explicit user decision." [25]_. As we want to be<br></div><div>able to easily change the language, we should not use the content<br></div><div>negotiation as a main language determination, so we need something<br></div><div>else.<br></div><div><br></div><div>Last solution is to use the URL path, which looks readable, allows<br></div><div>for an easy switch from a language to another, and nicely accepts<br></div><div>hyphens. Typically something like: "<a href="http://docs.python.org/de/">docs.python.org/de/</a>" or, by<br></div><div>using a hyphen: "<a href="http://docs.python.org/pt-BR/">docs.python.org/pt-BR/</a>".<br></div><div><br></div><div>As for the version, sphinx-doc does not support compiling for multiple<br></div><div>languages, so we'll have full builds rooted under a path, exactly like<br></div><div>we're already doing with versions.<br></div><div><br></div><div>So we can have "<a href="http://docs.python.org/de/3.6/">docs.python.org/de/3.6/</a>" or<br></div><div>"<a href="http://docs.python.org/3.6/de/">docs.python.org/3.6/de/</a>". A question that arises is:<br></div><div>"Does the language contain multiple versions or does the version contain<br></div><div>multiple languages?". As versions exist in any case and translations<br></div><div>for a given version may or may not exist, we may prefer<br></div><div>"<a href="http://docs.python.org/3.6/de/">docs.python.org/3.6/de/</a>", but doing so scatters languages everywhere.<br></div><div>Having "/de/3.6/" is clearer, meaning: "everything under /de/ is written<br></div><div>in German". Having the version at the end is also a habit taken by<br></div><div>readers of the documentation: they like to easily change the version<br></div><div>by changing the end of the path.<br></div><div><br></div><div>So we should use the following pattern:<br></div><div>"<a href="http://docs.python.org/LANGUAGE_TAG/VERSION/">docs.python.org/LANGUAGE_TAG/VERSION/</a>".<br></div><div><br></div><div>The current documentation is not moved to "/en/", insted<br></div><div>"<a href="http://docs.python.org/en/">docs.python.org/en/</a>" will redirect to "docs.python.org".<br></div><div><br></div><div><br></div><div>Language Tag<br></div><div>''''''''''''<br></div><div><br></div><div>A common notation for language tags is the IETF Language Tag [3]_<br></div><div>[4]_ based on ISO 639, although gettext uses ISO 639 tags with<br></div><div>underscores (ex: ``pt_BR``) instead of dashes to join tags [5]_<br></div><div>(ex: ``pt-BR``). Examples of IETF Language Tags: ``fr`` (French),<br></div><div>``ja`` (Japanese), ``pt-BR`` (Orthographic formulation of 1943 -<br></div><div>Official in Brazil).<br></div><div><br></div><div>It is more common to see dashes instead of underscores in URLs [6]_,<br></div><div>so we should use IETF language tags, even if sphinx uses gettext<br></div><div>internally: URLs are not meant to leak the underlying implementation.<br></div><div><br></div><div>It's uncommon to see capitalized letters in URLs, and docs.python.org<br></div><div>doesn't use any, so it may hurt readability by attracting the eye on it,<br></div><div>like in: "<a href="https://docs.python.org/pt-BR/3.6/library/stdtypes.html">https://docs.python.org/pt-BR/3.6/library/stdtypes.html</a>".<br></div><div>RFC 5646 (Tags for Identifying Languages (IETF)) section-2.1 [7]_<br></div><div>states that tags are not case sensitive. As the RFC allows lower case,<br></div><div>and it enhances readability, we should use lowercased tags like<br></div><div>``pt-br``.<br></div><div><br></div><div>It's redundant to display both language and country code if they're<br></div><div>the same, for example: "de-DE" or "fr-FR". Although it might make<br></div><div>sense, respectively meaning "German as spoken in Germany" and "French<br></div><div>as spoken in France", it's not useful information for the reader. So<br></div><div>we may drop these redundancies and only keep the country code for<br></div><div>cases where it makes sense, for example, "pt-BR" for "Portuguese as<br></div><div>spoken in Brazil".<br></div><div><br></div><div>So we should use IETF language tags, lowercased, like ``/fr/``,<br></div><div>``/pt-br/``, ``/de/`` and so on.<br></div><div><br></div><div><br></div><div>Fetching And Building Translations<br></div><div>''''''''''''''''''''''''''''''''''<br></div><div><br></div><div>Currently docsbuild-scripts are building the documentation [8]_.<br></div><div>These scripts should be modified to fetch and build translations.<br></div><div><br></div><div>Building new translations is like building new versions so, while we're<br></div><div>adding complexity it is not that much.<br></div><div><br></div><div>Two steps should be configurable distinctively: Building a new language,<br></div><div>and adding it to the language switcher. This allows a transition step<br></div><div>between "we accepted the language" and "it is translated enough to be<br></div><div>made public". During this step, translators can review their<br></div><div>modifications on d.p.o without having to build the documentation<br></div><div>locally.<br></div><div><br></div><div>From the translation repositories, only the ``.po`` files should be<br></div><div>opened by the docsbuild-script to keep the attack surface and probable<br></div><div>bug sources at a minimum. This means no translation can patch sphinx<br></div><div>to advertise their translation tool. (This specific feature should be<br></div><div>handled by sphinx anyway [9]_).<br></div><div><br></div><div><br></div><div>Community<br></div><div>---------<br></div><div><br></div><div>Mailing List<br></div><div>''''''''''''<br></div><div><br></div><div>The `doc-sig`_ mailing list will be used to discuss cross-language<br></div><div>changes on translated documentation.<br></div><div><br></div><div>There is also the i18n-sig list but it's more oriented towards i18n APIs<br></div><div>[1]_ than translating the Python documentation.<br></div><div><br></div><div>.. _i18n-sig: <a href="https://mail.python.org/mailman/listinfo/i18n-sig">https://mail.python.org/mailman/listinfo/i18n-sig</a><br></div><div>.. _doc-sig: <a href="https://mail.python.org/mailman/listinfo/doc-sig">https://mail.python.org/mailman/listinfo/doc-sig</a><br></div><div><br></div><div><br></div><div>Chat<br></div><div>''''<br></div><div><br></div><div>Due to the Python community being highly active on IRC, we should<br></div><div>create a new IRC channel on freenode, typically #python-doc for<br></div><div>consistency with the mailing list name.<br></div><div><br></div><div>Each language coordinator can organize their own team, even by choosing<br></div><div>another chat system if the local usage asks for it. As local teams<br></div><div>will write in their native languages, we don't want each team in a<br></div><div>single channel. It's also natural for the local teams to reuse<br></div><div>their local channels like "#python-fr" for French translators.<br></div><div><br></div><div><br></div><div>Repository for PO Files<br></div><div>'''''''''''''''''''''''<br></div><div><br></div><div>Considering that each translation team may want to use different<br></div><div>translation tools, and that those tools should easily be synchronized<br></div><div>with git, all translations should expose their ``.po`` files via a git<br></div><div>repository.<br></div><div><br></div><div>Considering that each translation will be exposed via git<br></div><div>repositories, and that Python has migrated to GitHub, translations<br></div><div>will be hosted on github.<br></div><div><br></div><div>For consistency and discoverability, all translations should be in the<br></div><div>same github organization and named according to a common pattern.<br></div><div><br></div><div>Given that we want translations to be official, and that Python<br></div><div>already has a github organization, translations should be hosted as<br></div><div>projects of the `Python GitHub organization`_.<br></div><div><br></div><div>For consistency, translation repositories should be called<br></div><div>``python-docs-LANGUAGE_TAG`` [22]_, using the language tag used in<br></div><div>paths: without region subtag if redundent, and lowercased.<br></div><div><br></div><div>The docsbuild-scripts may enforce this rule by refusing to fetch<br></div><div>outside of the Python organization or a wrongly named repository.<br></div><div><br></div><div>The CLA bot may be used on the translation repositories, but with a<br></div><div>limited effect as local coordinators may synchronize themselves with<br></div><div>translations from an external tool, like transifex, and loose track<br></div><div>of who translated what in the process.<br></div><div><br></div><div>Versions can be hosted on different repositories, different directories<br></div><div>or different branches. Storing them on different repositories will<br></div><div>probably pollute the Python github organization. As it<br></div><div>is typical and natural to use branches to separate versions, branches<br></div><div>should be used to do so.<br></div><div><br></div><div>.. _Python GitHub organization: <a href="https://github.com/python/">https://github.com/python/</a><br></div><div><br></div><div><br></div><div>Translation tools<br></div><div>'''''''''''''''''<br></div><div><br></div><div>Most of the translation work is actually done on Transifex [15]_.<br></div><div><br></div><div>Other tools may be used later <a href="https://pontoon.mozilla.org/">https://pontoon.mozilla.org/</a><br></div><div>and <a href="http://zanata.org/">http://zanata.org/</a><br></div><div><br></div><div><br></div><div>Contributor Agreement<br></div><div>'''''''''''''''''''''<br></div><div><br></div><div>Contributions to translated documentation will be requested to sign<br></div><div>the Python Contributor Agreement (CLA):<br></div><div><br></div><div><a href="https://www.python.org/psf/contrib/contrib-form/">https://www.python.org/psf/contrib/contrib-form/</a><br></div><div><br></div><div><br></div><div>Language Team<br></div><div>'''''''''''''<br></div><div><br></div><div>Each language team should have one coordinator responsible for:<br></div><div><br></div><div>- Managing the team.<br></div><div>- Choosing and managing the tools the team will use (chat, mailing list, …).<br></div><div>- Ensure contributors understand and agree with the CLA.<br></div><div>- Ensure quality (grammar, vocabulary, consistency, filtering spam, ads, …).<br></div><div>- Redirect issues posted on b.p.o to the correct GitHub issue tracker<br></div><div> for the language.<br></div><div><br></div><div>The license will be the `PSF License<br></div><div><<a href="https://docs.python.org/3/license.html">https://docs.python.org/3/license.html</a>>`_, and copyright should be<br></div><div>transferable to PSF later.<br></div><div><br></div><div><br></div><div>Alternatives<br></div><div>------------<br></div><div><br></div><div>Simplified English<br></div><div>''''''''''''''''''<br></div><div><br></div><div>It would be possible to introduce a "simplified English" version like<br></div><div>wikipedia did [10]_, as discussed on python-dev [11]_, targeting<br></div><div>English learners and children.<br></div><div><br></div><div>Pros: It yields a single translation, theoretically readable by<br></div><div>everyone and reviewable by current maintainers.<br></div><div><br></div><div>Cons: Subtle details may be lost, and translators from English to English<br></div><div>may be hard to find as stated by Wikipedia:<br></div><div><br></div><div>> The main English Wikipedia has 5 million articles, written by nearly<br></div><div>140K active users; the Swedish Wikipedia is almost as big, 3M articles<br></div><div>from only 3K active users; but the Simple English Wikipedia has just<br></div><div>123K articles and 871 active users. That's fewer articles than<br></div><div>Esperanto!<br></div><div><br></div><div><br></div><div>Changes<br></div><div>=======<br></div><div><br></div><div>Migrate GitHub Repositories<br></div><div>---------------------------<br></div><div><br></div><div>We (authors of this PEP) already own French and Japanese Git repositories,<br></div><div>so moving them to the Python documentation organization will not be a<br></div><div>problem. We'll however be following the `New Translation Procedure`_.<br></div><div><br></div><div><br></div><div>Patch docsbuild-scripts to Compile Translations<br></div><div>-----------------------------------------------<br></div><div><br></div><div>Docsbuild-script must be patched to:<br></div><div><br></div><div>- List the language tags to build along with the branches to build.<br></div><div>- List the language tags to display in the language switcher.<br></div><div>- Find translation repositories by formatting<br></div><div> ``github.com:python/python-docs-{language_tag}.git`` (See<br></div><div> `Repository for Po Files`_)<br></div><div>- Build translations for each branch and each language.<br></div><div><br></div><div>Patched docsbuild-scripts must only open ``.po`` files from<br></div><div>translation repositories.<br></div><div><br></div><div><br></div><div>List coordinators in the devguide<br></div><div>---------------------------------<br></div><div><br></div><div>Add a page or a section with an empty list of coordinators to the<br></div><div>devguide, each new coordinator will be added to this list.<br></div><div><br></div><div><br></div><div>Create sphinx-doc Language Switcher<br></div><div>-----------------------------------<br></div><div><br></div><div>Highly similar to the version switcher, a language switcher must be<br></div><div>implemented. This language switcher must be configurable to hide or<br></div><div>show a given language.<br></div><div><br></div><div>The language switcher will only have to update or add the language<br></div><div>segment to the path like the current version switcher does. Unlike<br></div><div>the version switcher, no preflight are required as destination page<br></div><div>always exists (translations does not add or remove pages).<br></div><div>Untranslated (but existing) pages still exists, they should however be<br></div><div>rendered as so, see `Enhance Rendering of Untranslated and Fuzzy<br></div><div>Translations`_.<br></div><div><br></div><div><br></div><div>Update sphinx-doc Version Switcher<br></div><div>----------------------------------<br></div><div><br></div><div>The ``patch_url`` function of the version switcher in<br></div><div>``version_switch.js`` have to be updated to understand and allow the<br></div><div>presence of the language segment in the path.<br></div><div><br></div><div><br></div><div>Enhance Rendering of Untranslated and Fuzzy Translations<br></div><div>--------------------------------------------------------<br></div><div><br></div><div>It's an opened sphinx issue [9]_, but we'll need it so we'll have to<br></div><div>work on it. Translated, fuzzy, and untranslated paragraphs should be<br></div><div>differentiated. (Fuzzy paragraphs have to warn the reader what he's<br></div><div>reading may be out of date.)<br></div><div><br></div><div><br></div><div>New Translation Procedure<br></div><div>=========================<br></div><div><br></div><div>Designate a Coordinator<br></div><div>-----------------------<br></div><div><br></div><div>The first step is to designate a coordinator, see `Language Team`_,<br></div><div>The coordinator must sign the CLA.<br></div><div><br></div><div>The coordinator should be added to the list of translation coordinators<br></div><div>on the devguide.<br></div><div><br></div><div><br></div><div>Create Github Repository<br></div><div>------------------------<br></div><div><br></div><div>Create a repository named "python-docs-{LANGUAGE_TAG}" (IETF language<br></div><div>tag, without redundent region subtag, with a dash, and lowercased.) on<br></div><div>the Python github organization (See `Repository For Po Files`_.), and<br></div><div>grant the language coordinator push rights to this repository.<br></div><div><br></div><div><br></div><div>Add support for translations in docsbuild-scripts<br></div><div>-------------------------------------------------<br></div><div><br></div><div>As soon as the translation hits its first commits, update the<br></div><div>docsbuild-scripts configuration to build the translation (but not<br></div><div>displaying it in the language switcher).<br></div><div><br></div><div><br></div><div>Add Translation to the Language Switcher<br></div><div>----------------------------------------<br></div><div><br></div><div>As soon as the translation hits:<br></div><div><br></div><div>- 100% of bugs.html with proper links to the language repository<br></div><div> issue tracker.<br></div><div>- 100% of tutorial.<br></div><div>- 100% of library/functions (builtins).<br></div><div><br></div><div>the translation can be added to the language switcher.<br></div><div><br></div><div><br></div><div>Previous Discussions<br></div><div>====================<br></div><div><br></div><div>- `[Python-ideas] Cross link documentation translations (January, 2016)`_<br></div><div>- `[Python-ideas] Cross link documentation translations (January, 2016)`_<br></div><div>- `[Python-ideas] <a href="https://docs.python.org/fr/">https://docs.python.org/fr/</a> ? (March 2016)`_<br></div><div><br></div><div><br></div><div>.. _[Python-ideas] Cross link documentation translations (January, 2016):<br></div><div> <a href="https://mail.python.org/pipermail/python-ideas/2016-January/038010.html">https://mail.python.org/pipermail/python-ideas/2016-January/038010.html</a><br></div><div><br></div><div>.. _[Python-Dev] Translated Python documentation (Febrary 2016):<br></div><div> <a href="https://mail.python.org/pipermail/python-dev/2017-February/147416.html">https://mail.python.org/pipermail/python-dev/2017-February/147416.html</a><br></div><div><br></div><div>.. _[Python-ideas] <a href="https://docs.python.org/fr/">https://docs.python.org/fr/</a> ? (March 2016):<br></div><div> <a href="https://mail.python.org/pipermail/python-ideas/2016-March/038879.html">https://mail.python.org/pipermail/python-ideas/2016-March/038879.html</a><br></div><div><br></div><div><br></div><div>References<br></div><div>==========<br></div><div><br></div><div>.. [1] [I18n-sig] Hello Python members, Do you have any idea about<br></div><div> Python documents?<br></div><div> (<a href="https://mail.python.org/pipermail/i18n-sig/2013-September/002130.html">https://mail.python.org/pipermail/i18n-sig/2013-September/002130.html</a>)<br></div><div><br></div><div>.. [2] [Doc-SIG] Localization of Python docs<br></div><div> (<a href="https://mail.python.org/pipermail/doc-sig/2013-September/003948.html">https://mail.python.org/pipermail/doc-sig/2013-September/003948.html</a>)<br></div><div><br></div><div>.. [3] Tags for Identifying Languages<br></div><div> (<a href="http://tools.ietf.org/html/rfc5646">http://tools.ietf.org/html/rfc5646</a>)<br></div><div><br></div><div>.. [4] IETF language tag<br></div><div> (<a href="https://en.wikipedia.org/wiki/IETF_language_tag">https://en.wikipedia.org/wiki/IETF_language_tag</a>)<br></div><div><br></div><div>.. [5] GNU Gettext manual, section 2.3.1: Locale Names<br></div><div> (<a href="https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html">https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html</a>)<br></div><div><br></div><div>.. [6] Semantic URL: Slug<br></div><div> (<a href="https://en.wikipedia.org/wiki/Semantic_URL#Slug">https://en.wikipedia.org/wiki/Semantic_URL#Slug</a>)<br></div><div><br></div><div>.. [7] Tags for Identifying Languages: Formatting of Language Tags<br></div><div> (<a href="https://tools.ietf.org/html/rfc5646#section-2.1.1">https://tools.ietf.org/html/rfc5646#section-2.1.1</a>)<br></div><div><br></div><div>.. [8] Docsbuild-scripts github repository<br></div><div> (<a href="https://github.com/python/docsbuild-scripts/">https://github.com/python/docsbuild-scripts/</a>)<br></div><div><br></div><div>.. [9] i18n: Highlight untranslated paragraphs<br></div><div> (<a href="https://github.com/sphinx-doc/sphinx/issues/1246">https://github.com/sphinx-doc/sphinx/issues/1246</a>)<br></div><div><br></div><div>.. [10] Wikipedia: Simple English<br></div><div> (<a href="https://simple.wikipedia.org/wiki/Main_Page">https://simple.wikipedia.org/wiki/Main_Page</a>)<br></div><div><br></div><div>.. [11] Python-dev discussion about simplified english<br></div><div> (<a href="https://mail.python.org/pipermail/python-dev/2017-February/147446.html">https://mail.python.org/pipermail/python-dev/2017-February/147446.html</a>)<br></div><div><br></div><div>.. [12] Passing options to sphinx from Doc/Makefile<br></div><div> (<a href="https://github.com/python/cpython/commit/57acb82d275ace9d9d854b156611e641f68e9e7c">https://github.com/python/cpython/commit/57acb82d275ace9d9d854b156611e641f68e9e7c</a>)<br></div><div><br></div><div>.. [13] French translation progression<br></div><div> (<a href="https://mdk.fr/pycon2016/#/11">https://mdk.fr/pycon2016/#/11</a>)<br></div><div><br></div><div>.. [14] French translation contributors<br></div><div> (<a href="https://github.com/AFPy/python_doc_fr/graphs/contributors?from=2016-01-01&to=2016-12-31&type=c">https://github.com/AFPy/python_doc_fr/graphs/contributors?from=2016-01-01&to=2016-12-31&type=c</a>)<br></div><div><br></div><div>.. [15] Python-doc on Transifex<br></div><div> (<a href="https://www.transifex.com/python-doc/">https://www.transifex.com/python-doc/</a>)<br></div><div><br></div><div>.. [16] French translation<br></div><div> (<a href="https://www.afpy.org/doc/python/">https://www.afpy.org/doc/python/</a>)<br></div><div><br></div><div>.. [17] French translation github<br></div><div> (<a href="https://github.com/AFPy/python_doc_fr">https://github.com/AFPy/python_doc_fr</a>)<br></div><div><br></div><div>.. [18] French mailing list<br></div><div> (<a href="http://lists.afpy.org/mailman/listinfo/traductions">http://lists.afpy.org/mailman/listinfo/traductions</a>)<br></div><div><br></div><div>.. [19] Japanese translation<br></div><div> (<a href="http://docs.python.jp/3/">http://docs.python.jp/3/</a>)<br></div><div><br></div><div>.. [20] Japanese github<br></div><div> (<a href="https://github.com/python-doc-ja/python-doc-ja">https://github.com/python-doc-ja/python-doc-ja</a>)<br></div><div><br></div><div>.. [21] Spanish translation<br></div><div> (<a href="http://docs.python.org.ar/tutorial/3/index.html">http://docs.python.org.ar/tutorial/3/index.html</a>)<br></div><div><br></div><div>.. [22] [Python-Dev] Translated Python documentation: doc vs docs<br></div><div> (<a href="https://mail.python.org/pipermail/python-dev/2017-February/147472.html">https://mail.python.org/pipermail/python-dev/2017-February/147472.html</a>)<br></div><div><br></div><div>.. [23] Domains - SEO Best Practices | Moz<br></div><div> (<a href="https://moz.com/learn/seo/domain">https://moz.com/learn/seo/domain</a>)<br></div><div><br></div><div>.. [24] Requirements for Internet Hosts -- Application and Support<br></div><div> (<a href="https://www.ietf.org/rfc/rfc1123.txt">https://www.ietf.org/rfc/rfc1123.txt</a>)<br></div><div><br></div><div>.. [25] Accept-Language<br></div><div> (<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language</a>)<br></div><div><br></div><div>.. [26] Документация Python 2.7!<br></div><div> (<a href="http://python-lab.ru/documentation/index.html">http://python-lab.ru/documentation/index.html</a>)<br></div><div><br></div><div>Copyright<br></div><div>=========<br></div><div><br></div><div>This document has been placed in the public domain.<br></div><div><br></div><div><br></div><div><br></div><div> <br></div><div>..<br></div><div> Local Variables:<br></div><div> mode: indented-text<br></div><div> indent-tabs-mode: nil<br></div><div> sentence-end-double-space: t<br></div><div> fill-column: 70<br></div><div> coding: utf-8<br></div><div> End:<br></div><div>========================================<br></div><div><br></div><div>
.. [1] [Python-ideas] PEP: Python Documentation Translations<br></div><div> (<a href="https://mail.python.org/pipermail/python-ideas/2017-March/045226.html">https://mail.python.org/pipermail/python-ideas/2017-March/045226.html</a>)<br></div><div><br></div><div>.. [2] [Python-Dev] Translated Python documentation<br></div><div> (<a href="https://mail.python.org/pipermail/python-dev/2017-February/147416.html">https://mail.python.org/pipermail/python-dev/2017-February/147416.html</a>)<br></div><div><br></div><div>Bests,</div><div>-- <br></div><div>Julien Palard<br></div><div>https://mdk.fr<br></div><div><br></div><div><br></div>