Ce projet vise à mettre à disposition sur le site de l'afpy une traduction en français de la documentation officielle de Python.

Votre aide est la bienvenue que ce soit pour maintenir les traductions à jour, les relire, les améliorer ou traduire de nouveaux blocs.

Progression de la traduction:

Pour cela récupérez les fichiers .po de la partie qui vous intéresse, d'une des façons suivantes:

• forkez ce dépôt (conseillée)
• cliquez sur l'icone "Download ZIP"

Éditer les fichiers avec l'éditeur de votre choix, il en existe beaucoup:

• Le classique: poedit
• gted
• gtranslator
• lokalize
• betterpoeditor
• vim ou emacs avec un mode PO
• Vé sur Android
• Probablement d'autres :)

Puis vous n'avez plus qu'à vous occuper du texte en français.

Une fois votre contribution écrite, transmettez-la nous :

• soit par un pull-request (si vous avez fait un fork du dépot)
• soit en la joignant à un ticket github
• soit par mail à la liste traductions

Quoi traduire, ne pas traduire, quel style ?

• Nous ne travaillons que sur la dernière version de Python, lorsqu'elle sera entièrement traduite, nous attaquerons le reste, en attendant, nous répliquons notre travail en utilisant ./scripts/replicate_translations.py
• Attention, install.po est à peu près innutile, aucun (?) lien ne pointe dessus.
• Pour le moment, nous laissons à part licence.po, voir le ticket #30 <AFPy#30>.
• Les référence :ref:`...` ne sont pas à traduire
• Les références :term:`...` sont à traduire, leur traduction se trouve dans glossary.po.
• Les mots anglais, nous les mettons en italique (en les entourant d'étoiles dans la traduction).

Si vous utilisez git et faites des pull requests, cette section est importante, pour les mails et les tickets, on s'en occupera pur vous.

Afin de ne pas générer des diff illisibles remplis de plus de différences de norme que de différences de texte, autremment dit, afin d'obtenir un historique git lisible, et des merge faciles, nous utilisons tous la même norme.

Actuellement, nous utilisons la norme proposée par msgcat, vous pouvez donc utiliser cette ligne pour remettre vos traductions en forme:

./scripts/fix_style.sh

La quantité de textes à traduire est énorme et il serait très facile de disperser notre énergie dans des textes destinés aux utilisateurs très avancés, il nous paraît nécessaire de fixer des priorités:

1. Avant tout et surtout : maintenir les textes déjà complets (tutorial.po, glossary.po). 3. les bases du langage (reference.po) 4. la notice d'installation de Python (using.po) 5. la foire aux questions (faq.po)

• Le grand dictionnaire terminologique
• Le chan IRC #python-fr sur freenode
• La liste traductions
• Vous pouvez consulter le glossaire traduc.org qui contient des traductions consolidées de plusieur projets.
• Consultez aussi le site de traduc.org qui contient de nombreuses informations pour les traducteurs.
• glossary.po tout simplement, ou le glossaire traduit

Afin d'obtenir un document cohérent cette section propose une traduction de quelques termes techniques, rappelant ainsi les anglicismes à éviter, ce n'est qu'une proposition discutable (ouvrez un ticket si vous n'êtes pas d'acord) :

• -like => -compatible (Pas toujours élégant, voir ce ticket)
• abstract data type => type abstrait
• argument => argument (et non paramètre (qui est la traduction de parameter))
• backslash => antislash
• bound => lier
• bug => bug (Bogue étant déjà pris par la châtaigne...)
• débugging => débogage (en contradiction avec le précédent ?)
• built-in => primitives, interne
• double quote => guillemet
• identifier => identifiant
• immutable => immuable
• interpreter => interpréteur
• library => bibliothèque
• list compréhension => compréhension de liste
• little/big endian => petit-boutiste et gros-boutiste
• mutable => variable
• parameter => paramètre
• prompt => invite
• regular expression => expression rationelle
• simple quote => guillemet simple
• socket => socket ("Je veux mon niveau ! Chausette ! Chausette !")
• statement => instruction
• underscore => tiret bas

Un script, ./scripts/build.sh permet de générer la doc, il s'occupera pour vous de rappatrier un clone de cpython, de le configurer, d'y appliquer éventuellement quelques patches (en attendant qu'ils soient mergés upstream), et vous vous retrouvez si tout va bien avec la doc dans www/.

Pour générer une autre version que la dernière, passer là en paramètre, comme : ./scripts/build.sh 3.2.

Un script, ./scripts/sync.sh permet de récupérer ou mettre à jour un clone de cpython dans gen/, il y fera passer un xgettext, fera les bon msgmerge qui vont bien, sur la dernière version par défaut, lancez donc plutôt:

for V in 2.7 3.2 3.3 3.4 3.5; do ./scripts/sync.sh $V; done

Tout peut être amené à bouger, mais pour le moment, rien n'est executé server side, le protocole actuel pour mettre à jour la prod est donc de lancer

for V in 2.7 3.2 3.3 3.4 3.5; do ./scripts/build.sh $V; done rsync -az www/ afpy.org:/home/mandark/www/

tout simplement.