Bonjour,
Je propose de lancer un projet de traduction des docs python en français.
Dans un premier temps (disons décembre) je propose de me charger de
traduire 'Documenting Python' qui est indispensable en ce sens qu'il
explique comment réaliser une doc pour python.
Parallèlement, il faut essayer d'établir un contact pour que ces docs
traduites soient intégrées au site officiel (not very obvious indeed),
ou à défaut trouver un hébergement (le wiki fr me parait tout indiqué).
Parallèlement, il faut définir quel est l'à peu près dizaine de modules
les plus indispensables pour une traduction (Tiens, je verrais bien
'string' dans le tas). Gross m..do définir ce qu'il faut traduire en
priorité.
Les volontaires peuvent faire un pas en avant. Il faut posséder un
dictionnaire, un ordinateur, et prévoir environ 4 à 5 jours à temps
plein répartis sur 1 à 2 mois. Si votre niveau en anglais vous inquiète,
be quiet baby, I'll give you a hand. Pas sérieux s'abstenir : on
commence = on finit.
Dans un second temps (disons janvier/février) : moteur, action.
Je me propose pour la coordination, et j'ai besoin d'un backup (pour les
lendemains de fêtes pardi !).
Dans un troisième temps, fin du projet. Même si quelques modules
seulement sont traduits, it is not grave, ce serait déjà un début.
Sugestions/objections bienvenues.
Voilà. Peut-être que je rêve, mais on verra bien.
A+
jm
PS: si cette démarche a déjà été entreprise, merci de me le signaler.
Et donc, je viens de créer une page sur le wiki ça, au moins, c'est concret.
@-salutations
Michel Claveau
Andréï
Bonjour !
Il n'est pas dit qu'un template OOo fonctionne sur tous les ordinateurs. C'est trop dépendant : du système, des polices installées, et/ou prédéfinies, etc. aussi de la version de Ooo utilisée
Si j'ai bien compris, un des avantages de LaTeX, c'est que l'on peut utiliser un éditeur de texte quelconque. Quoique, AMHA, il faudrait s'entendre sur les choix d'encodages.
Oui on peut, mais c'est comme pour n'importe quel langage de prog, il y a des éditeur spécialisés. sous win xp j'utilise miktex Pour qui est de l'encodage, il suffit de fournir un fichier d'entete et voici a quoi pourrais ressembler un fichier en latex. La numérotation, la typographie, bref l'homogénéité du document est assurée par latex. L'utilisateur n'a qu'a se soucier du contenu.
documentclass[12pt,a4paper]{report} % Type de document input{mesprefs.tex} % Fichier d'entete fixant la typo
Il n'est pas dit qu'un template OOo fonctionne sur tous les ordinateurs.
C'est trop dépendant : du système, des polices installées, et/ou prédéfinies,
etc.
aussi de la version de Ooo utilisée
Si j'ai bien compris, un des avantages de LaTeX, c'est que l'on peut utiliser
un éditeur de texte quelconque. Quoique, AMHA, il faudrait s'entendre sur les
choix d'encodages.
Oui on peut, mais c'est comme pour n'importe quel langage de prog, il y
a des éditeur spécialisés. sous win xp j'utilise miktex
Pour qui est de l'encodage, il suffit de fournir un fichier d'entete et
voici a quoi pourrais ressembler un fichier en latex.
La numérotation, la typographie, bref l'homogénéité du document est
assurée par latex. L'utilisateur n'a qu'a se soucier du contenu.
documentclass[12pt,a4paper]{report} % Type de document
input{mesprefs.tex} % Fichier d'entete fixant la typo
Il n'est pas dit qu'un template OOo fonctionne sur tous les ordinateurs. C'est trop dépendant : du système, des polices installées, et/ou prédéfinies, etc. aussi de la version de Ooo utilisée
Si j'ai bien compris, un des avantages de LaTeX, c'est que l'on peut utiliser un éditeur de texte quelconque. Quoique, AMHA, il faudrait s'entendre sur les choix d'encodages.
Oui on peut, mais c'est comme pour n'importe quel langage de prog, il y a des éditeur spécialisés. sous win xp j'utilise miktex Pour qui est de l'encodage, il suffit de fournir un fichier d'entete et voici a quoi pourrais ressembler un fichier en latex. La numérotation, la typographie, bref l'homogénéité du document est assurée par latex. L'utilisateur n'a qu'a se soucier du contenu.
documentclass[12pt,a4paper]{report} % Type de document input{mesprefs.tex} % Fichier d'entete fixant la typo
À (at) Fri, 09 Dec 2005 08:34:44 +0100, "Andréï" écrivait (wrote): [...]
Le meilleur outil pour ca me semble etre latex
Je me permets de vous donner mon avis en tant que traducteur d'une partie de la documentation Perl. Évidemment, vous en faites ce que vous voulez ;-)
Le plus efficace est d'adopter le même format que la doc d'origine. Cela permet d'automatiser beaucoup de choses. Par exemple, voir en face à face la version anglaise et la version française (même traduit, un paragraphe reste un paragraphe). Faire des diffs entre version anglaise d'un côté et française de l'autre pour vérifier que tous les ajouts ont été traduits. Etc.
Il faut aussi se mettre d'accord sur la traduction du vocabulaire (celui spécifique au langage). Cela peut se faire incrémentalement : une première discussion pour les mots de base les plus évidents puis régulièrement ou à chaque fois qu'un traducteur tombe sur un os (encore faut-il qu'il s'en aperçoive).
Il faut aussi prévoir une relecture systématique (voire plusieurs) tant pour l'orthographe/grammaire que pour le style ou les non-sens ou contre-sens. Parfois, la traduction est aussi l'occasion de découvrir et de faire remonter des bugs de la version originale. Dans ce cas, en attendant l'éventuelle correction, nous ajoutions une NdT (note du traducteur).
Il faut aussi se poser la question de la traduction du code donné en exemple . Que traduire ?
1- Rien. C'est pas super ;-(
2- Juste les commentaires. C'est un peu mieux et c'est ce qui est le moins risqué.
3- Les commentaires et le contenu des chaînes de caractères. Mais il faut alors vérifier que l'exemple produit le même résultat.
4- Les commentaires, le contenu des chaînes et les noms de variables et méthodes (dans la mesure où ils ne sont pas directement liés au langage ou à un module prédéfini). C'est ce qui est le mieux (pour un pur francophone) mais aussi le plus dur. Et là encore, il faut absolument vérifier la validité du code traduit.
La doc Python est écrite en LaTeX. Donc il vous faudra sûrement quelqu'un d'assez compétent en LaTeX pour le règler afin d'utiliser les règles typographiques françaises et pour traiter d'éventuels problèmes d'accents car la plupart du temps, tous les outils, les éventuelles extensions, etc. ont été prévus uniquement pour de l'ascii de base. C'est parfois trivial à corriger... mais pas toujours. Une fois cela règler, la production des documents PDF et Postscript est très simple et automatique.
Pour la conversion en HTML, la doc originale utilise latex2html (qui est un uzine à gaz écrite en Perl) mais vous pouvez décider d'utiliser un autre convertisseur comme hevea (qui est écrit en CAML) ou tex4ht (qui est écrit presque complètement en (La)TeX mais qui ne marche pas sur toutes les plateformes). Mais ce dernier problème ne concerne que celui (ou ceux) qui auront la charge de produire les documents HTML à publier sur le Web.
En fait, la plus grosse difficulté est de maintenir la traduction à jour par rapport à l'originale. Et là, je n'ai pas (encore) la solution puisque, côté Perl, le projet de traduction est presque au point mort.
En tous cas, bravo pour cette (nouvelle) initiative de traduction de la doc Python. Et bon courage (sans mauvais esprit).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 09 Dec 2005 08:34:44 +0100,
"Andréï" <tete@toto.com> écrivait (wrote):
[...]
Le meilleur outil pour ca me semble etre latex
Je me permets de vous donner mon avis en tant que traducteur d'une
partie de la documentation Perl. Évidemment, vous en faites ce que
vous voulez ;-)
Le plus efficace est d'adopter le même format que la doc d'origine.
Cela permet d'automatiser beaucoup de choses. Par exemple, voir en
face à face la version anglaise et la version française (même traduit,
un paragraphe reste un paragraphe). Faire des diffs entre version
anglaise d'un côté et française de l'autre pour vérifier que tous les
ajouts ont été traduits. Etc.
Il faut aussi se mettre d'accord sur la traduction du vocabulaire
(celui spécifique au langage). Cela peut se faire incrémentalement :
une première discussion pour les mots de base les plus évidents puis
régulièrement ou à chaque fois qu'un traducteur tombe sur un os
(encore faut-il qu'il s'en aperçoive).
Il faut aussi prévoir une relecture systématique (voire plusieurs)
tant pour l'orthographe/grammaire que pour le style ou les non-sens ou
contre-sens. Parfois, la traduction est aussi l'occasion de découvrir
et de faire remonter des bugs de la version originale. Dans ce cas, en
attendant l'éventuelle correction, nous ajoutions une NdT (note du
traducteur).
Il faut aussi se poser la question de la traduction du code donné en
exemple . Que traduire ?
1- Rien. C'est pas super ;-(
2- Juste les commentaires. C'est un peu mieux et c'est ce qui
est le moins risqué.
3- Les commentaires et le contenu des chaînes de caractères.
Mais il faut alors vérifier que l'exemple produit le même
résultat.
4- Les commentaires, le contenu des chaînes et les noms de
variables et méthodes (dans la mesure où ils ne sont pas
directement liés au langage ou à un module prédéfini). C'est
ce qui est le mieux (pour un pur francophone) mais aussi le
plus dur. Et là encore, il faut absolument vérifier la
validité du code traduit.
La doc Python est écrite en LaTeX. Donc il vous faudra sûrement
quelqu'un d'assez compétent en LaTeX pour le règler afin d'utiliser
les règles typographiques françaises et pour traiter d'éventuels
problèmes d'accents car la plupart du temps, tous les outils, les
éventuelles extensions, etc. ont été prévus uniquement pour de
l'ascii de base. C'est parfois trivial à corriger... mais pas
toujours. Une fois cela règler, la production des documents PDF et
Postscript est très simple et automatique.
Pour la conversion en HTML, la doc originale utilise latex2html (qui
est un uzine à gaz écrite en Perl) mais vous pouvez décider d'utiliser
un autre convertisseur comme hevea (qui est écrit en CAML) ou tex4ht
(qui est écrit presque complètement en (La)TeX mais qui ne marche pas
sur toutes les plateformes). Mais ce dernier problème ne concerne que
celui (ou ceux) qui auront la charge de produire les documents HTML à
publier sur le Web.
En fait, la plus grosse difficulté est de maintenir la traduction à
jour par rapport à l'originale. Et là, je n'ai pas (encore) la
solution puisque, côté Perl, le projet de traduction est presque au
point mort.
En tous cas, bravo pour cette (nouvelle) initiative de traduction de
la doc Python. Et bon courage (sans mauvais esprit).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 09 Dec 2005 08:34:44 +0100, "Andréï" écrivait (wrote): [...]
Le meilleur outil pour ca me semble etre latex
Je me permets de vous donner mon avis en tant que traducteur d'une partie de la documentation Perl. Évidemment, vous en faites ce que vous voulez ;-)
Le plus efficace est d'adopter le même format que la doc d'origine. Cela permet d'automatiser beaucoup de choses. Par exemple, voir en face à face la version anglaise et la version française (même traduit, un paragraphe reste un paragraphe). Faire des diffs entre version anglaise d'un côté et française de l'autre pour vérifier que tous les ajouts ont été traduits. Etc.
Il faut aussi se mettre d'accord sur la traduction du vocabulaire (celui spécifique au langage). Cela peut se faire incrémentalement : une première discussion pour les mots de base les plus évidents puis régulièrement ou à chaque fois qu'un traducteur tombe sur un os (encore faut-il qu'il s'en aperçoive).
Il faut aussi prévoir une relecture systématique (voire plusieurs) tant pour l'orthographe/grammaire que pour le style ou les non-sens ou contre-sens. Parfois, la traduction est aussi l'occasion de découvrir et de faire remonter des bugs de la version originale. Dans ce cas, en attendant l'éventuelle correction, nous ajoutions une NdT (note du traducteur).
Il faut aussi se poser la question de la traduction du code donné en exemple . Que traduire ?
1- Rien. C'est pas super ;-(
2- Juste les commentaires. C'est un peu mieux et c'est ce qui est le moins risqué.
3- Les commentaires et le contenu des chaînes de caractères. Mais il faut alors vérifier que l'exemple produit le même résultat.
4- Les commentaires, le contenu des chaînes et les noms de variables et méthodes (dans la mesure où ils ne sont pas directement liés au langage ou à un module prédéfini). C'est ce qui est le mieux (pour un pur francophone) mais aussi le plus dur. Et là encore, il faut absolument vérifier la validité du code traduit.
La doc Python est écrite en LaTeX. Donc il vous faudra sûrement quelqu'un d'assez compétent en LaTeX pour le règler afin d'utiliser les règles typographiques françaises et pour traiter d'éventuels problèmes d'accents car la plupart du temps, tous les outils, les éventuelles extensions, etc. ont été prévus uniquement pour de l'ascii de base. C'est parfois trivial à corriger... mais pas toujours. Une fois cela règler, la production des documents PDF et Postscript est très simple et automatique.
Pour la conversion en HTML, la doc originale utilise latex2html (qui est un uzine à gaz écrite en Perl) mais vous pouvez décider d'utiliser un autre convertisseur comme hevea (qui est écrit en CAML) ou tex4ht (qui est écrit presque complètement en (La)TeX mais qui ne marche pas sur toutes les plateformes). Mais ce dernier problème ne concerne que celui (ou ceux) qui auront la charge de produire les documents HTML à publier sur le Web.
En fait, la plus grosse difficulté est de maintenir la traduction à jour par rapport à l'originale. Et là, je n'ai pas (encore) la solution puisque, côté Perl, le projet de traduction est presque au point mort.
En tous cas, bravo pour cette (nouvelle) initiative de traduction de la doc Python. Et bon courage (sans mauvais esprit).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
R12y
On Fri, 09 Dec 2005 10:21:52 +0000, William Dode wrote:
Ce que je vous propose, plutôt que de débattre à n'en plus finir, c'est de prendre un module chacun et de commencer à traduire avec l'outil que l'on préfère, ensuite chacun expose ses remarques et on refait un point, sur fclp.
+1 ça me convient.
-- Telephone portable "intelligent" (SmartPhone) GSM, GPRS,... Il est sous Linux, ne coute pas trop cher,... http://www.it2l.com/product_info.php?cPath&products_idE6
On Fri, 09 Dec 2005 10:21:52 +0000, William Dode wrote:
Ce que je vous propose, plutôt que de débattre à n'en plus finir, c'est
de prendre un module chacun et de commencer à traduire avec l'outil que
l'on préfère, ensuite chacun expose ses remarques et on refait un point,
sur fclp.
+1 ça me convient.
--
Telephone portable "intelligent" (SmartPhone) GSM, GPRS,...
Il est sous Linux, ne coute pas trop cher,...
http://www.it2l.com/product_info.php?cPath&products_idE6
On Fri, 09 Dec 2005 10:21:52 +0000, William Dode wrote:
Ce que je vous propose, plutôt que de débattre à n'en plus finir, c'est de prendre un module chacun et de commencer à traduire avec l'outil que l'on préfère, ensuite chacun expose ses remarques et on refait un point, sur fclp.
+1 ça me convient.
-- Telephone portable "intelligent" (SmartPhone) GSM, GPRS,... Il est sous Linux, ne coute pas trop cher,... http://www.it2l.com/product_info.php?cPath&products_idE6
