Eloquent JavaScript - Clap premiere
aka framasoft
Ce premier message inaugure donc le projet de traduction du livre
Eloquent JavaScript.
http://eloquentjavascript.net/
Pour rappel, le message sur Linuxfr :
http://linuxfr.org/~akauffmann/30746.html
Tout d'abord évidemment grand merci à tous pour votre participation ;-)
Nous sommes 7 inscrit à la liste pour le moment.
Retenir le mail de liste : eloquent-...@googlegroups.com
En fait vous êtes plutôt 6 car je ne pourrais participer directement à
ce projet.
C'était d'ailleurs ça l'idée de lancer un appel sur DLFP, aussi bien
trouver des volontaires qui s'y connaissent en programmation que de
décharger le boulot en interne à Framasoft où les traducteurs ont trop
de boulot par ailleurs.
Ce que Framasoft va apporter se situera en tout fin de chaîne. Une
relecture globale attentive et appronfondie (on a une petite équipe
pour ça dans le projet Framabook) ainsi que la mise en forme dans la
Poule ou l'Oeuf en vue de l'édition en ligne et papier chez
InLibroVeritas.
L'idée c'est donc d'en faire un volume de plus à notre collection
Framabook (en cohérence avec l'effort didactique que l'on fait
actuellement avec le Unix, le C et le Produire du logiciel libre),
mais comme c'est de la licence libre, il n'y évidemment aucune
exclusive.
http://www.framabook.org/
J'ai évoqué la Poule ou l'Oeuf en fin de cycle car là encore ce serait
un peu trop compliqué en l'état actuel des choses et de notre
disponibilité de vous faire travailler directement dedans pour ce
projet.
Donc pour l'outil de travail vous pouvez faire des propositions et des
choix. C'est vraiment comme vous voulez.
Personnellement je suggère un wiki sur Mediawiki mais c'est comme vous
le souhaitez.
Si le choix d'un Mediawiki vous semble bon alors on en a un chez nous
à Framasoft :
http://wiki.framasoft.org/
Mais ça peut aussi pourquoi pas se faire sur Wikibooks (avantages :
tout le monde en profitera / inconvénient : il est difficile de suivre
et d'arrêter la traduction quand tout le monde peut potentiellement
intervenir dessus) :
http://fr.wikibooks.org/
Enfin à la liste de se mettre d'accord.
Dans un premier temps je vous invite à vous présenter succinctement
ainsi qu'à nous dire a priori votre disponibilité (haute, faible...)
et votre degré d'implication sur le projet (traduction, relecture). Et
si vous avez déjà fait des traduction collectives et que vous avez un
outil de prédilection, n'hésitez pas à nous en faire part également.
Dans un autre topic, on pourra livrer nos premières impressions sur le
bouquin, évoquer un glossaire commun, etc.
Amicalement,
Alexis
PS : Si il y a qui sont allegiques aux listes Google, ce que je
comprendrai fort bien, ils peuvent aussi faire une proposition pour
déporter cette liste de discussion ailleurs sur un serveur moins
surveillé ;-)
Krazy Bug
Je vais donc déclencher les hostilités.
Tout d'abord, je suis ravi de participer à ce projet et ce pour
plusieurs raisons:
- Bien que mon niveau d'anglais, notamment technique, soit correct, je
dispose d'une marge de progression certaine (euphémisme inside) et cet
exercice devrait s'avérer profitable, au moins pour moi (égoïstement
bien à vous).
Je compte sur les plus aguerris d'entre vous pour me soutenir sur les
quelques hésitations ou contresens que je ne manquerai pas de
commettre (uniquement pour tester votre vigilance, évidemment)
- Coté bagage technique, je pense, modestie mise à part, être
suffisamment armé pour affronter un ouvrage d'initiation à la
programmation, du moment qu'il ne traite pas de Perl ;-)
La traduction d'un ouvrage Javascript me motive d'autant plus que je
n'ai jamais fait que survoler ce langage pourtant incontournable et
que j'aurais plus d'une fois voulu me lancer dans un petit plugin FF/
Greasemonkey.
- Coté expérience, je n'ai pas participé à beaucoup d'entreprises dans
le domaine du libre (trolling DLFPien mis à part) même si j'en fais un
usage intensif et que j'affectionne ce mouvement.
Je contribue autrement et ce genre d'opération convient à mon ambition
et à ma disponibilité.
Concrètement, j'ai un peu participé à la relecture du bouquin "Maven,
the definitive guide" et "Snake Wrangling for Kids" (http://
linuxfr.org/2009/12/02/26227.html)
- Coté implication, j'aimerais participer à la traduction de quelque
chapitres ... paragraphes et à la relecture (dispo 4 ou 5 h par
semaine)
Maintenant quelques suggestions et idées en vrac:
De part mes précédentes expériences, j'en ai retiré que la traduction
en groupe avait quelques inconvénients lorsqu'il s'agit de ménager les
susceptibilités avec un résultat ... parfois imparfait sur la
qualité.
(appréciation subjective et syndrome "not invented here" sans doute)
Toujours est-il que j'ai trouvé le mode dictateur bienveillant un peu
décourageant, quelquefois.
Ce projet est <s>peut-être</s> certainement l'occasion de revoir mes
jugements (je ne sais pas si Framasoft est coutumier de l'exercice de
traduction collégiale)
Tout ce baratin pour y aller de ma petite proposition d'organisation:
Que pensez vous de l'idée de se répartir la traduction de paragraphes/
chapitres dans un premier temps. (tableau avec la table des matières
où chacun s'inscrit)
Une fois le premier jet effectué, le traducteur soumet l'avancement de
son travail à de séances de relecture collectives afin d'apporter de
la cohérence au tout (genre: ne pas mélanger la formulation à la 2e
personne du pluriel et l'infinitif, ...).
Il en découlera assez naturellement un "coding style" qu'on pourra
regrouper sur une page comme ici:
http://github.com/ehsavoie/maven-guide-fr/wiki/Termes-r%C3%A9currents-%C3%A0-traduire
Rien d'original me direz-vous ?
Niveau outillage: le wiki me va assez bien même si j'appréciais assez
le fait d'utiliser un forge comme github (ou mieux bitbucket pour les
hg fans ou Google Code on a tous notre compte)
L'avantage est la possibilité de facilement formuler des contre-
propositions ou des corrections dans sa branche et de les intégrer
rapidement par merge pour les plus aguerris.
Pour les autres les corrections dans le système de suivi sont
possibles et les tâches plus transverses mieux suivies (ex: "refaire
une passe sur la traduction de tel terme")
https://github.com/ehsavoie/maven-guide-fr/issues
Le wiki a l'avantage d'être plus simple à appréhender, propose une
historisation rudimentaire et la page de discussion peut servir pour
les contre-proposition et les tâches.
Je termine par un grand merci à Alexandre pour son implication, même
si on comprend tous parfaitement qu'il ne puisse nous chapeauter en
permanence.
Voilà,
Merci de m'avoir lu si vous avez tenu jusque là
Amicalement,
Thierry
On 7 fév, 20:43, aka framasoft <aka.framas...@gmail.com> wrote:
> Bonjour à tous,
>
> Ce premier message inaugure donc le projet de traduction du livre
> Pour rappel, le message sur Linuxfr :http://linuxfr.org/~akauffmann/30746.html
>
> Tout d'abord évidemment grand merci à tous pour votre participation ;-)
>
> Nous sommes 7 inscrit à la liste pour le moment.
> Retenir le mail de liste : eloquent-...@googlegroups.com
>
> En fait vous êtes plutôt 6 car je ne pourrais participer directement à
> ce projet.
>
> C'était d'ailleurs ça l'idée de lancer un appel sur DLFP, aussi bien
> trouver des volontaires qui s'y connaissent en programmation que de
> décharger le boulot en interne à Framasoft où les traducteurs ont trop
> de boulot par ailleurs.
>
> Ce que Framasoft va apporter se situera en tout fin de chaîne. Une
> relecture globale attentive et appronfondie (on a une petite équipe
> pour ça dans le projet Framabook) ainsi que la mise en forme dans la
> Poule ou l'Oeuf en vue de l'édition en ligne et papier chez
> InLibroVeritas.
>
> L'idée c'est donc d'en faire un volume de plus à notre collection
> Framabook (en cohérence avec l'effort didactique que l'on fait
> actuellement avec le Unix, le C et le Produire du logiciel libre),
> mais comme c'est de la licence libre, il n'y évidemment aucune
Krazy Bug
Tu me pardonneras Alex, ca ne fait que 2 impairs en 2 j ;-)
> Rien d'original me direz-vous ?
>
> Niveau outillage: le wiki me va assez bien même si j'appréciais assez
> le fait d'utiliser un forge comme github (ou mieux bitbucket pour les
> hg fans ou Google Code on a tous notre compte)
> L'avantage est la possibilité de facilement formuler des contre-
> propositions ou des corrections dans sa branche et de les intégrer
> rapidement par merge pour les plus aguerris.
> Pour les autres les corrections dans le système de suivi sont
> possibles et les tâches plus transverses mieux suivies (ex: "refaire
Serge Julien
Tout d'abord, je voudrais signaler que je suis ravi de participer à un tel projet, c'est une première pour moi. J'ai 41 ans, je suis belge et je vis dans le sud du pays (c'est-à-dire au nord pour la plupart d'entre vous ;-), plus précisément au point de rencontre de la Belgique, de la France et du Grand-Duché de Luxembourg.
Je n'ai jamais participé que très ponctuellement au libre, et c'est une occasion de mettre en pratique l'esprit de partage qui en est une des idées maîtresses.
- Pour avoir survolé très succinctement quelques pages de l'ouvrage, je pense que mon niveau d'anglais sera suffisant. Je ne suis pas développeur web, mais j'ai souvent fait joujou avec JavaScript et ce sera donc l'occasion de consolider mes connaissances sur le sujet.
- Mes contributions au libre sont jusqu'ici plutôt d'ordre "politique": lobbying, information... J'ai aussi apporté une participation financière à quelques projets, j'ai traduit des chaînes pour une ancienne version d'Ubuntu; en terme de code, j'ai un seul (micro-)patch (de 2 lignes) à mon actif, c'était pour la version 3.0 de Python. Je suis développeur dans le monde propriétaire (informatique interne dans une boîte au Grand-Duché de Luxembourg, avec des outils obscurs), mais sur le plan personnel, je ne mange que du libre.
- Pour ce qui est de l'organisation, je n'ai pratiquement pas d'expérience des systèmes de contrôle de version, aussi le Wiki me conviendrait-il très bien, mais je peux m'adapter si la majorité préfère autre chose. L'idée de Thierry de se répartir les chapitres / paragraphes et de relire en commun par la suite me paraît excellente, puisque j'ai eu la même! ;-) Un glossaire commun me paraît indispensable, de même qu'un accord préalable sur certains points (par exemple, faut-il traduire les variables dans les exemples de code?).
- En ce qui concerne le style, je suis plutôt partisan de "l'idée avant la lettre", et je pense que vouloir coller de trop près au mot à mot a pour résultat un style ampoulé et artificiel, car des tournures qui sont naturelles dans une langue ne le sont pas dans une autre.
- Ma disponibilité serait de 6 à 7 heures par semaine, en soirée principalement. La mailing list me convient très bien: je ne suis pas un adepte de la communication en direct (je n'ai pas de compte de chat ou irc), mais je pourrais m'y mettre si c'était _vraiment_ indispensable. Par contre, il est hors de question que je m'inscrive sur Facebook ou Twitter, ce sera le seul point sur lequel je serai intransigeant.
- Pour répondre à Alexis sur la question des listes Google, je n'y suis pas allergique. Google a des côtés obscurs et d'autres très lumineux, mais je ne pense pas que la paranoïa soit de mise dans le cas d'échanges à propos d'un ouvrage qui sera finalement rendu public, a fortiori sous une licence libre. Que les serveurs de Google en conservent une trace ne me dérange donc pas.
Ce sera tout pour aujourd'hui!
Merci à tous et à bientôt, amicalement,
-Serge-
Killruana
J'ai 20 ans, et je vis à Montpellier. Donc le sud pour beaucoup, et l'extrême sud pour Serge ;-)
Mes contributions au Libre sont minimes : je suis utilisateur, trolleur, occasionnellement propagandiste et parfois rapporteur de bugs. Mais sinon je n'ai jamais traduit, ni proposé de patch, ni bla...
Mon niveau d'anglais n'est pas exceptionnel : j'arrive à comprendre une "RTFM", et ça s'arrête là... Je n'ai pas l'oreille, mon accent est à couper au couteau... C'est pour cette raison que je m'embarque dans cette aventure, mon niveau ne peut pas être pire après que avant...
Mes connaissances en JavaScript sont deux mois à bouffer du jQuery à toutes les sauces en Web Agency. Mais je n'ai jamais fait de JavaScript "de base", sans passer par un framework.
Je n'ai pas de préférence sur l'organisation. Un cours sur git ne me ferais pas de mal, mais un wiki permettrait de suivre plus facilement l'avancé du projet à Mme Michue.
En tant qu'étudiant, ma disponibilité est très variables : j'ai le rapport de mon projet à rendre pour la mi-février, donc je serai pas trop présent. Libre jusqu'à début mars donc beaucoup de temps. Et après stage jusqu'en juin, disponibilité à géométrie variable dépendant de ma motivation à retourner derrière un écran après avoir passé la journée dessus...
Pour les moyens de communications, la mailing list me va, quelque soit son fournisseur (y compris Google). Je pense qu'un salon irc ne pourrait pas faire de mal pour pouvoir avoir des réponses et retours en temps réel, mais n'est pas obligatoire non plus..
Bon, il est l'heure pour moi d'aller en cours.
Amicalement,
Jonathan
Émilien Tlapale
J'ai 26 ans et je suis chercheur en neurosciences dans le sud est (mais
je partirais � l'�tranger d'ici quelques mois).
J'utilise l'anglais pour �crire, lire et parler de fa�on quotidienne, y
compris sur des sujets informatiques. J�appr�cie �norm�ment les langues
de fa�on g�n�rale, et je suis bilingue (mais pas en anglais).
Je connais le JavaScript "ancien" mais j'ai aussi utilis�s des
biblioth�ques r�centes comme jQuery.
J'ai contribu� � quelques projets libres et non-libre, dans diff�rents
langages.
J'utilise tr�s souvent git, mais utiliser un wiki me convient aussi.
Utiliser Facebook/Twitter/Google Code ne m'est pas possible. Je peux
mettre � disposition des serveurs et des comptes de toutes sortes par
contre. Pas de probl�me avec SF/gitorious/github/gna/... par contre.
Je suis disponible pour traduire quelques dizaines de milliers de mots
par mois, mais le travail, les enfants, etc. ne me permettent pas
d'avoir des horaires pr�visibles.
--
�milien
On 02/08/2011 10:48 AM, Killruana wrote:
> Bonjour � tous,
>
> J'ai 20 ans, et je vis � Montpellier. Donc le sud pour beaucoup, et
> l'extr�me sud pour Serge ;-)
>
> Mes contributions au Libre sont minimes : je suis utilisateur,
> trolleur, occasionnellement propagandiste et parfois rapporteur de
> bugs. Mais sinon je n'ai jamais traduit, ni propos� de patch, ni bla...
>
> Mon niveau d'anglais n'est pas exceptionnel : j'arrive � comprendre
> une "RTFM", et �a s'arr�te l�... Je n'ai pas l'oreille, mon accent est
> � couper au couteau... C'est pour cette raison que je m'embarque dans
> cette aventure, mon niveau ne peut pas �tre pire apr�s que avant...
>
> Mes connaissances en JavaScript sont deux mois � bouffer du jQuery �
> toutes les sauces en Web Agency. Mais je n'ai jamais fait de
> JavaScript "de base", sans passer par un framework.
>
> Je n'ai pas de pr�f�rence sur l'organisation. Un cours sur git ne me
> ferais pas de mal, mais un wiki permettrait de suivre plus facilement
> l'avanc� du projet � Mme Michue.
>
> En tant qu'�tudiant, ma disponibilit� est tr�s variables : j'ai le
> rapport de mon projet � rendre pour la mi-f�vrier, donc je serai pas
> trop pr�sent. Libre jusqu'� d�but mars donc beaucoup de temps. Et
> apr�s stage jusqu'en juin, disponibilit� � g�om�trie variable
> d�pendant de ma motivation � retourner derri�re un �cran apr�s avoir
> pass� la journ�e dessus...
>
> Pour les moyens de communications, la mailing list me va, quelque soit
> son fournisseur (y compris Google). Je pense qu'un salon irc ne
> pourrait pas faire de mal pour pouvoir avoir des r�ponses et retours
> en temps r�el, mais n'est pas obligatoire non plus..
Bernard Adrian
Pour ce qui me concerne, la présentation sera courte :
- 50 ans, j'habite en Lorraine, jamais reçu de cours d'informatique,
mais passionné par le monde libre, les scripts, elisp, php,
javascript, etc.
- emacsophile,
- j'ai bidouillé une application en javascript en 2002-2004 qui est
utilisée par mes collègues de boulot.
- passable à très moyen en anglais
- ai fait de la relecture pour les paquets debian
- pas de préférence quant aux outils.
- un emploi du temps assez chargé, comme tout le monde, mais l'envie
de participer à ce projet
voilà, voilà,
--
Bernard Adrian
Le 7 février 2011 22:54, Krazy Bug <kraz...@gmail.com> a écrit :
--
Bernard Adrian
http://www.bernadrian.net
Maxime
Moi aussi ce sera très bref :
J'ai 36 ans, à Tours. Je suis ingénieur en informatique de formation.
J'apprécie la philosophie du logiciel libre et Linux.
Je bosse entre autres en PHP, javascript, jQuery.
Je découvre le livre "eloquent javascript" grâce à la nouvelle sur
linuxfr, et je le trouve très bon. Bien meilleur que ce qu'on peut
voir
en librairies spécialisées, du moins pour les ouvrages en français.
Ma disponibilité est incertaine, mes compétences en anglais et en
français sûrement très moyennes. J'espère progresser à l'occasion.
En ce qui concerne les outils, mediawiki me va très bien, ainsi que ce
groupe google, mais pas de facebook !
Maxime
Krazy Bug
Merci à tous pour vos suggestions.
Je m'apercois à ce stade que j'ai un peu négligé quelques civilités et je vais donc corriger le tir.
J'ai 40 ans et je vis en région toulousaine. Je travaille dans une DSI d'une grande entreprise en qualité d'ingénieur support.
Concernant la logistique, Alexis vous a fait suivre un mail de Christophe Masutti, coordinateur du projet Framabook, en réponse à certaines de mes interrogations.
J'avoue tout, j'ai lâchement profité de mon inscription par erreur à la liste Framalang pour pêcher quelques infos auprès de nos grands frères ... après quelques pérégrination sur leur sites.
Je vous invite à aller faire un tour sur le projet de traduction su SVN Book initié sur leur site ici:
http://www.framalang.org/wiki/Version_control_with_subversion
Pour le reste, il semble que leur infrastructure soit plus dédiée à la traduction d'articles avec la possibillité d'éditer à plusieurs en même temps un document:
les fameux "Pads"
Exemple:
http://framapad.org/Interview-with-Richard-Stallman-2011-
Ceci semble correspondre à un besoin de réactivité mais me parait moins adapté pour un cycle plus long comme celui que nous envisageons.
Au niveau de leur wiki, j'ai trouvé assez sympathique le fait de disposer de macros/boutons pour confronter l'original et la traduction comme ici:
http://www.framalang.org/wiki/SVNBOOK_Chap1_Fundamental_Concepts
mais hormis ça, je ne crois pas qu'ils proposent d'outillage particulier pour récupérer une copie de l'original et la préparer pour la traduction en la découpant en fragments "prêts à traduire".
Il semble aussi que l'assemblage en un document unique pour la prise en charge dans la chaîne de publication (La Poule) ne soit pas automatique.
Du fait que la Poule accepte un document unique au format odt et qu'il ait besoin d'être "harmonisé", j'en déduis qu'un outil de gestion de version serait un plus au moins pour cette phase.
Enfin, je note que leur plateforme ne dispose pas d'un outil de suivi qui peut parfois s'avérer bien pratique.
Ils pallient en consignant les items dans un tableau comme sur la page d'accueil
http://www.framalang.org/wiki/Accueil
mais il faut reconnaître qu'un vrai outil de suivi avec la possibilité d'ajouter des étiquettes et de s'affecter des tâches me paraitrait plus confortable.
cf. Maven Guide par exemple:
http://github.com/ehsavoie/maven-guide-fr/issues
Alexis, merci de me rectifier si je me suis fourvoyé.
De nos propres échanges, j'en retire que vous n'êtes pas des accrocs de Twitter, Facebook et autres réseaux sociaux ou IMs (moi non plus d'ailleurs).
, que la simplicité d'un wiki sied à tout le monde et évite de rajouter un obstacle technique et que la syntaxe Mediawiki semble faire l'unanimité (je préfère XWiki mais suis disposé à faire des concessions)
Alors voici ma proposition:
Toutes les forges modernes couvrent nos besoins, a savoir:
- 1 wiki, de préférence qui supporte la syntaxe Mediawiki
- integration avec un outil de gestion de conf. (Si je devais m'occuper de la phase d'assemblage post-traduction, j'incline plus pour Mercurial que Git mais c'est ouvert)
- une outil de suivi
- si possible configurable avec des états et des champs différents de ceux de la production de logiciel
- si possible avec des étiquettes (permet de pallier le point précédent)
Vous l'aurez compris, j'aimerais m'orienter vers une forge à notre disposition:
Nous avons:
Google Code, bitbucket, github, gitorious, gna, SF, InDefero (un ptit gars sympa de chez DLFP) ....
Concernant Google Code, les avantages que j'y vois:
- presque toute l'équipe dispose déjà d'un compte Google
- Mercurial
Inconvénients:
- syntaxe wiki propre à Google (à verifier si support mediawiki)
- proprio
@Emilien: Si tu pouvais nous detailler tes objections concernant Google Code qui n'est pas plus propriétaire que Github ou SF, après tout.
Si tu pouvais également préciser lorsque tu parles de mettre à dispo serveurs et comptes.
Sinon bitbucket a ma préférence pour mercurial mais une forge multi VCS ferait l'affaire
Concernant l'organisation du wiki, j'imaginais assez bien une page d'accueil avec
- la présentation du projet et de l'ouvrage original
- la liste des participants
- un lien vers une page de conventions (typographies, styles, glossaire, ...)
- un tableau qui renvoie sur les pages de chapitres/sections, l'état d'avancement (non traduit, traduction en cours, traduit, relecture en cours, ...) et une colonne ou chacun s'inscrit pour la traduction
Ca s'inspire assez de ce qui est fait pour le SVN Book
Pour chaque page qui renvoie à une section à traduire, on conserve en haut la traduction originale avec un style particulier à défaut de bénéficier des macros de Framalang.
Je vous propose de faire un petit tour des forges à notre dispo et de prendre une décision ce WE si vos claviers ne vous demangent pas trop (Désolé Maxime de te couper dans ton élan)
Amicalement,
Thierry
Serge Julien
J'ai visité les liens que Thierry nous a envoyés, et c'est effectivement intéressant. Comme il le dit, les "pads" ne me semblent pas adaptés à notre projet, même si c'est une technologie intéressante.
N'ayant pas la moindre expérience des systèmes de gestion de version, je ne me prononcerai pas sur les outils à employer, je laisse décider ceux qui maîtrisent. Mais quand le choix sera fait, je m'y mettrai, ça ne me fait pas peur. Un outil de suivi me paraît indispensable également.
Au delà des choix techniques, je crois qu'il serait également utile que chacun précise quelles compétences précises il peut apporter, afin de se répartir efficacement le travail. Il ne s'agit bien sûr pas de se comparer, chacun a ses forces et ses faiblesses et c'est très bien ainsi.
Pour ma part, j'ai la chance d'être tombé dans une marmite de potion orthographique quand j'étais petit, et j'ai des facilités pour l'expression écrite. Je suis aussi un maniaque de la typographie (mais nous n'en sommes pas encore là). Ma faiblesse principale est mon manque d'expérience avec JavaScript: j'ai souvent intégré quelques petits scripts dans des pages (vérification des saisies, etc), j'ai fait un tout petit peu d'Ajax et j'ai utilisé très ponctuellement jQuery pour les facilités offertes en termes de manipulation du DOM, mais ça s'arrête là.
Pour revenir sur un plan un peu plus concret, voici les questions auxquelles je propose que l'on réponde pour la suite:
1 - lesquelles de vos compétences seront particulièrement utiles au projet?
2 - quelles ressources techniques pouvez-vous éventuellement mettre à disposition?
3 - quelle forge et quels outils choisissons-nous?
4 - par quel élément commençons-nous: conventions, glossaire, liste des tâches...?
5 - [insérez ici les autres questions qui vous turlupinent]
Et je le répète, je pose ces questions sans esprit de comparaison: si l'un d'entre nous a la chance de pouvoir mettre des serveurs à notre disposition, par exemple, cela ne dévalorise en rien la contribution des autres. Et la réponse "ne se prononce pas" est tout à fait acceptable à mes yeux: c'est celle que je donne à la question 3, par exemple, car je n'ai pas suffisamment d'expérience pour choisir.
Bonne journée à tous,
-Serge-
Émilien Tlapale
J'aime beaucoup le wiki de Framalang, et il me semble qu'il n'y ait pas
besoin d'utiliser d'autre outil pour faire la traduction. Le mod�le �
SVN book � me semble �tre un bon point de d�part pour l'infrastructure �
utiliser, et on pourrait leur demander si le wiki leur a sembl� adapt� �
la traduction, m�me si la structure du livre � Eloquent JavaScript � est
sensiblement diff�rente.
A-t-on acc�s aux sources du livre ?
Oui, j'ai des serveurs � disposition sur lesquelles je peux installer
des logiciels, mais j'avoue ne pas trop en voir l'int�r�t pour
l'instant, surtout par rapport � l'existant.
Je porte moi-aussi un grand int�r�t � la typographie, et j'avoue �tre
d��u par les rendus PDF sur le site de Framabook.
--
�milien
On 02/10/2011 12:32 PM, Serge Julien wrote:
> Bonjour,
>
> J'ai visit� les liens que Thierry nous a envoy�s, et c'est
> effectivement int�ressant. Comme il le dit, les "pads" ne me semblent
> pas adapt�s � notre projet, m�me si c'est une technologie int�ressante.
>
> N'ayant pas la moindre exp�rience des syst�mes de gestion de version,
> je ne me prononcerai pas sur les outils � employer, je laisse d�cider
> ceux qui ma�trisent. Mais quand le choix sera fait, je m'y mettrai, �a
> ne me fait pas peur. Un outil de suivi me para�t indispensable �galement.
>
> Au del� des choix techniques, je crois qu'il serait �galement utile
> que chacun pr�cise quelles comp�tences pr�cises il peut apporter, afin
> de se r�partir efficacement le travail. Il ne s'agit bien s�r pas de
> se comparer, chacun a ses forces et ses faiblesses et c'est tr�s bien
> ainsi.
>
> Pour ma part, j'ai la chance d'�tre tomb� dans une marmite de potion
> orthographique quand j'�tais petit, et j'ai des facilit�s pour
> l'expression �crite. Je suis aussi un maniaque de la typographie (mais
> nous n'en sommes pas encore l�). Ma faiblesse principale est mon
> manque d'exp�rience avec JavaScript: j'ai souvent int�gr� quelques
> petits scripts dans des pages (v�rification des saisies, etc), j'ai
> fait un tout petit peu d'Ajax et j'ai utilis� tr�s ponctuellement
> jQuery pour les facilit�s offertes en termes de manipulation du DOM,
> mais �a s'arr�te l�.
>
> Pour revenir sur un plan un peu plus concret, voici les questions
> auxquelles je propose que l'on r�ponde pour la suite:
>
> 1 - lesquelles de vos comp�tences seront particuli�rement utiles au
> projet?
> 2 - quelles ressources techniques pouvez-vous �ventuellement mettre �
> disposition?
> 3 - quelle forge et quels outils choisissons-nous?
> 4 - par quel �l�ment commen�ons-nous: conventions, glossaire, liste
> des t�ches...?
> 5 - [ins�rez ici les autres questions qui vous turlupinent]
>
> Et je le r�p�te, je pose ces questions sans esprit de comparaison: si
> l'un d'entre nous a la chance de pouvoir mettre des serveurs � notre
> disposition, par exemple, cela ne d�valorise en rien la contribution
> des autres. Et la r�ponse "ne se prononce pas" est tout � fait
> acceptable � mes yeux: c'est celle que je donne � la question 3, par
> exemple, car je n'ai pas suffisamment d'exp�rience pour choisir.
>
> Bonne journ�e � tous,
>
> -Serge-
>
> Le 10 f�vrier 2011 00:09, Krazy Bug <kraz...@gmail.com
> <mailto:kraz...@gmail.com>> a �crit :
>
> Bonjour,
>
> Merci � tous pour vos suggestions.
>
> Je m'apercois � ce stade que j'ai un peu n�glig� quelques
> civilit�s et je vais donc corriger le tir.
> J'ai 40 ans et je vis en r�gion toulousaine. Je travaille dans une
> DSI d'une grande entreprise en qualit� d'ing�nieur support.
>
> Concernant la logistique, Alexis vous a fait suivre un mail de
> Christophe Masutti, coordinateur du projet Framabook, en r�ponse �
> certaines de mes interrogations.
> J'avoue tout, j'ai l�chement profit� de mon inscription par erreur
> � la liste Framalang pour p�cher quelques infos aupr�s de nos
> grands fr�res ... apr�s quelques p�r�grination sur leur sites.
>
> Je vous invite � aller faire un tour sur le projet de traduction
> su SVN Book initi� sur leur site ici:
> http://www.framalang.org/wiki/Version_control_with_subversion
>
> Pour le reste, il semble que leur infrastructure soit plus d�di�e
> � la traduction d'articles avec la possibillit� d'�diter �
> plusieurs en m�me temps un document:
> les fameux "Pads"
> Exemple:
> http://framapad.org/Interview-with-Richard-Stallman-2011-
>
> Ceci semble correspondre � un besoin de r�activit� mais me parait
> moins adapt� pour un cycle plus long comme celui que nous envisageons.
>
> Au niveau de leur wiki, j'ai trouv� assez sympathique le fait de
> disposer de macros/boutons pour confronter l'original et la
> traduction comme ici:
> http://www.framalang.org/wiki/SVNBOOK_Chap1_Fundamental_Concepts
> mais hormis �a, je ne crois pas qu'ils proposent d'outillage
> particulier pour r�cup�rer une copie de l'original et la pr�parer
> pour la traduction en la d�coupant en fragments "pr�ts � traduire".
> Il semble aussi que l'assemblage en un document unique pour la
> prise en charge dans la cha�ne de publication (La Poule) ne soit
> pas automatique.
>
> Du fait que la Poule accepte un document unique au format odt et
> qu'il ait besoin d'�tre "harmonis�", j'en d�duis qu'un outil de
> gestion de version serait un plus au moins pour cette phase.
>
> Enfin, je note que leur plateforme ne dispose pas d'un outil de
> suivi qui peut parfois s'av�rer bien pratique.
> Ils pallient en consignant les items dans un tableau comme sur la
> page d'accueil
> http://www.framalang.org/wiki/Accueil
> mais il faut reconna�tre qu'un vrai outil de suivi avec la
> possibilit� d'ajouter des �tiquettes et de s'affecter des t�ches
> me paraitrait plus confortable.
> cf. Maven Guide par exemple:
> http://github.com/ehsavoie/maven-guide-fr/issues
>
> Alexis, merci de me rectifier si je me suis fourvoy�.
>
> De nos propres �changes, j'en retire que vous n'�tes pas des
> accrocs de Twitter, Facebook et autres r�seaux sociaux ou IMs
> (moi non plus d'ailleurs).
> , que la simplicit� d'un wiki sied � tout le monde et �vite de
> rajouter un obstacle technique et que la syntaxe Mediawiki semble
> faire l'unanimit� (je pr�f�re XWiki mais suis dispos� � faire des
> concessions)
>
> Alors voici ma proposition:
>
> Toutes les forges modernes couvrent nos besoins, a savoir:
> - 1 wiki, de pr�f�rence qui supporte la syntaxe Mediawiki
> - integration avec un outil de gestion de conf. (Si je devais
> m'occuper de la phase d'assemblage post-traduction, j'incline plus
> pour Mercurial que Git mais c'est ouvert)
> - une outil de suivi
> - si possible configurable avec des �tats et des champs diff�rents
> de ceux de la production de logiciel
> - si possible avec des �tiquettes (permet de pallier le point
> pr�c�dent)
>
> Vous l'aurez compris, j'aimerais m'orienter vers une forge � notre
> disposition:
>
> Nous avons:
>
> Google Code, bitbucket, github, gitorious, gna, SF, InDefero (un
> ptit gars sympa de chez DLFP) ....
>
> Concernant Google Code, les avantages que j'y vois:
> - presque toute l'�quipe dispose d�j� d'un compte Google
> - Mercurial
>
> Inconv�nients:
> - syntaxe wiki propre � Google (� verifier si support mediawiki)
> - proprio
>
> @Emilien: Si tu pouvais nous detailler tes objections concernant
> Google Code qui n'est pas plus propri�taire que Github ou SF,
> apr�s tout.
> Si tu pouvais �galement pr�ciser lorsque tu parles de mettre �
> dispo serveurs et comptes.
> Sinon bitbucket a ma pr�f�rence pour mercurial mais une forge
> multi VCS ferait l'affaire
>
>
> Concernant l'organisation du wiki, j'imaginais assez bien une page
> d'accueil avec
> - la pr�sentation du projet et de l'ouvrage original
> - la liste des participants
> - un lien vers une page de conventions (typographies, styles,
> glossaire, ...)
> - un tableau qui renvoie sur les pages de chapitres/sections,
> l'�tat d'avancement (non traduit, traduction en cours, traduit,
> relecture en cours, ...) et une colonne ou chacun s'inscrit pour
> la traduction
> Ca s'inspire assez de ce qui est fait pour le SVN Book
>
> Pour chaque page qui renvoie � une section � traduire, on conserve
> en haut la traduction originale avec un style particulier � d�faut
> de b�n�ficier des macros de Framalang.
>
> Je vous propose de faire un petit tour des forges � notre dispo et
> de prendre une d�cision ce WE si vos claviers ne vous demangent
> pas trop (D�sol� Maxime de te couper dans ton �lan)
>
>
> Amicalement,
> Thierry
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2011/2/8 Maxime <maxi...@gmail.com <mailto:maxi...@gmail.com>>
>
> Bonjour,
>
> Moi aussi ce sera tr�s bref :
>
> J'ai 36 ans, � Tours. Je suis ing�nieur en informatique de
> formation.
> J'appr�cie la philosophie du logiciel libre et Linux.
> Je bosse entre autres en PHP, javascript, jQuery.
>
> Je d�couvre le livre "eloquent javascript" gr�ce � la nouvelle sur
> linuxfr, et je le trouve tr�s bon. Bien meilleur que ce qu'on peut
> voir
> en librairies sp�cialis�es, du moins pour les ouvrages en
> fran�ais.
>
> Ma disponibilit� est incertaine, mes comp�tences en anglais et en
> fran�ais s�rement tr�s moyennes. J'esp�re progresser � l'occasion.
>
> En ce qui concerne les outils, mediawiki me va tr�s bien,
Maxime
1 - lesquelles de vos compétences seront particulièrement utiles au
projet?
frameworks qui font l'actualité du langage (backbone.js, knockout.js,
etc...) sur le site programming.reddit.com
2 - quelles ressources techniques pouvez-vous éventuellement mettre à
disposition?
Aucune, désolé.
3 - quelle forge et quels outils choisissons-nous?
du Maven Guide me parait un peu compliqué.
4 - par quel élément commençons-nous: conventions, glossaire, liste
des tâches...?
le tout sur un wiki.
Je ne vois pas trop ce que pourraient être les conventions.
5 - [insérez ici les autres questions qui vous turlupinent]
Rien de plus.
Maxime