Suite à mon message d’hier j’ai ajouté dans le forum Documentation une
première version d’un lexique francais ↔ anglais des termes RoR. Il
est sur http://www.railsfrance.org/node/167
Si vous voulez le compléter ou y apporter des corrections envoyez moi
vos contributions ou modifier le directement si vous en avez les droits.
A+
Laurent
Alain R. wrote:
Tous,
Je sens approcher une “flame-war”, mais je trouve que cette volonté de
TOUT traduire est nuisible (à la compréhension) et frise parfois le
ridicule.
Pas de quoi démarrer une guerre de cent ans… La traduction est
toujours un exercice périlleux.
Le but de ce lexique est avant tout d’uniformiser les termes
techniques utilisés dans les documents Rails qui sont traduits en
français. SI les traducteurs décident de traduire ces termes
techniques autant faire en sorte qu’ils utilisent tous les mêmes.
J’utilise moi-même les termes anglais assez souvent au quotidien par
ailleurs.
Laurent
Tous,
Je sens approcher une “flame-war”, mais je trouve que cette volonté de
TOUT traduire est nuisible (à la compréhension) et frise parfois le
ridicule.
En tant qu’informaticiens francophones, nous avons un avantage et
intérêt supplémentaire à utiliser certains termes en V.O.: leur
anglicitude signale leur caractère technique et limite leur champs de
signification (scope).
Example: une balise et un journal peuvent être beaucoup de choses, mais
un “tag” et un “log” ne présentent aucune ambiguïté.
Idem pour “log”, “helper”, “googler”, etc…
Ce qui me fait rouler en-dessous de la table:
gem : gemme
plugin : greffon
Ce qui me fait pleurer:
callback : méthode de rappel
fixture : garniture de test
foreign key: clé étrangère
Ce qui me fait sourire:
framework : framework
mix-in : mix-in
Mais aussi:
hash : tableau associatif
helper : assistant
layout : mise en page
log file : journal (=> comment traduire “journaling”?)
tag : balise
etc, etc…
Pull.
Alain
Tous,
Je sens approcher une “flame-war”, mais je trouve que cette volonté de
TOUT traduire est nuisible (à la compréhension) et frise parfois le
ridicule.
Je suis sur le principe d’accord, et je suis souvent un des premiers à
râler quand je vois des francisations (ça se dit?) inutiles et
incompréhensibles.
Toutefois, j’ai rencontré la problématique à de nombreuses reprises dans
mon écriture passée. Nous, qui écrivions en français directement, sans
avoir de réfrérence anglaise, ce sujet nous a plus qu’occupé. Autant dire
que je concois que sur une traduction, ce soit un excercice délicat et pas
simple à trancher.
Personnellement je n’aurais eu aucun remord à utiliser des termes anglais.
Ma seule directive était “que le lecteur comprenne et s’y retrouve”. La
règle prise a été :
Peu importe que le terme soit technique ou pas, l’important étant que le
lecteur comprenne de quoi on parle. Si la technicité était “le” critère
alors mon technicien lirait une doc en anglais au lieu d’une doc en
français.
Example: une balise et un journal peuvent être beaucoup de choses, mais
un “tag” et un “log” ne présentent aucune ambiguïté.
A voir. Je ne suis pas convaincu que tag ou log aient moins de sens que
leurs équivalents français. D’ailleurs on peut traduire “tag” par
“marque”, “balise”, “catégorie” … suivant le sens qu’il a.
Sans prétendre être une référence, personnellement j’avais traduit tag en
balise quand je parlais de xml/html et log en journal/journalisation la
plupart du temps. Ces deux termes sont largement employés en français,
n’importe quel français les comprendra sans hésitation, je ne voyais donc
pas l’utilité d’employer un jargon anglais.
Inversement je n’avais pas traduit socket (que certains traduisent en
fil
ou chaussette) ni template (le terme “gabarit” existe en français mais
n’est que très rarement utilisé dans le même contexte ; de mémoire on a
finalement préféré l’éviter).
Ce qui me fait pleurer:
callback : méthode de rappel
fixture : garniture de test
foreign key: clé étrangère
Exemple de problématique :
Pour clé étrangère c’est encore plus vrai. La traduction est litérale,
tous ceux qui connaissent le terme anglais comprennent le terme français
sans même hésiter. Dans quasiment tous les livres français c’est le terme
de “clé” qui est utilisé, faire un cas spécifique pour la clé étrangère
aurait été confus. On a utilisé le terme français ici aussi.
En fait dans quasiment tous tes exemples j’ai bien utilisé le terme
français. Les seules exceptions :
Il faut bien voir que garder les termes anglais n’a vraiment de sens que
pour ceux qui les connaissent, donc pour ceux qui lisent les docs
anglaises. Ceux qui achètent du français ont pour optique de pouvoir le
comprendre sans connaitre l’anglais. Parler de clé étrangère et pas de
foreign key, de base de données et pas de database, c’est justement leur
besoin.
Laisser un terme anglais là où le terme français serait mieux compris
c’est largement aussi mauvais que de traduire un terme inutilement.
Savoir
quel terme on utilise est loin d’être simple, franchement.
–
Eric D.
Ton hébergement est une initiative gentille. 
Mais on peut avoir les caractéristiques de l’hébergement sur ton site ?
On dirait une pauvre installation d’Instant Rails qui est sympa de prime
abord, mais chiant à contourner pour les problèmes de codages de
caractères ou autres… 
J’aimerais connaitre le type de BDD que tu offres, les versions dispo,
quid des gemmes installées O:-) ?
Pierre F. a écrit :
Bonjour,
J’ai mis en place un serveur d’hébergement à titre personnel que je
souhaite partager pour le bien de la communauté
Cet hébergement est destinée exclusivement à des fins de tests
d’application. En effet les performances offertes sont dérisoires :
compte limité à 100 Mo
Partage de la bande passante d’une connexion personnelle (freebox)
Serveur avec processeur à 400 Mhz (le père noel ne m’a pas gaté)
Inscription sur www.zieute.com
Ton hébergement est une initiative gentille.
Mais on peut avoir les caractéristiques de l’hébergement sur ton site ?On dirait une pauvre installation d’Instant Rails qui est sympa de prime
abord, mais chiant à contourner pour les problèmes de codages de
caractères ou autres…
Tu connais une façon d’installer rails qui ne pose aucun problème de
codage caractère ? J’ai toujours trouvé plein de problèmes avec
rails/unicode, mais pas vraiment de solution satisfaisante. Dans tous
ces
problèmes, l’installation était rarement la pièce majeure, la source était
quasiment tout le temps partagée entre ruby et l’application elle-même
–
Eric D.
Voir FAQ :
http://www.zieute.com/login/faq
Le lundi 30 janvier 2006 à 15:42 +0100, Pascal a écrit :
Je connais railsplayground, mais je rappelle que je propose un
hébergement à des fins test et non une proposition commerciale. Chacun
peut y voir un intérêt et étant donné la jeune communauté francaise de
Rails, il n’est pas certains qu’un développement d’un simple blog mérite
un hébergement chez railsplayground. Après chcun voit midi à sa porte.
Moi je propose seulement, libre aux intéressés d’en disposer.
Le lundi 30 janvier 2006 à 16:20 +0100, Alain R. a écrit :
Pierre
> J’ai mis en place un serveur d’hébergement
Connais-tu :
http://railsplayground.com/
?
Regarde ce qu’ils offrent pour le prix de 3 tickets de cinéma…
Espace disque, bande passante, paneau de contrôle pour installer Typo,
etc, etc…
Alain
(Je mets ma casquette de “méchant”)
“Moi je trouve ça bien sympa”.
Bien sûr que c’est sympa. Et c’est “gentil” aussi. Et généreux. Mais
c’est du bricolage. Au bout du compte, toutes ces offres gentillettes
sont peu inintéressantes pour les “clients” semi-sérieux: machines
faibles (pfs installées dans un salon), bande passante anémique,
infrastructure non-optimisée, zéro support et zéro garantie. C’est du
bricolage. Mais c’est gentil.
“Oui, mais c’est gratuit”.
Ton temps n’est pas gratuit. Si tu perds une nuit, un W.E. parce que le
serveur suffoque, est mal configuré, que les gems sont obsolètes, etc…
et le généreux donateur répond le lendemain parce qu’il était à la
piscine, tu auras perdus inutiliment du temps ET de l’argent. Même si tu
n’as rien payé au départ.
“DreamHost: 30$ pour 1 an”
Je conseille à tous les amateurs Rails, fauchés ou non, d’ouvrir un
compte chez DreamHost: 30$ pour 1 an, avec les coupons de réduction.
Moins que le prix du livre!!!
Je viens d’y installer ma première application Rails commerciale (pour
un client) et ça tourne sans problème. Support 24h/24, bande passante
gigantesque, espace disque itou, paneau de contrôle, etc…
(btw, un serveur dédicacé coûte 99$/mois. Oui, vous lisez bien.)
Si je dis tout ça au lieu d’un simple “merci pour ta gentille offre, et
au revoir”, c’est dans l’espoir secret de voir des passionés systèmes
prendre le taureau par les cornes et se lancer dans l’aventure du
hosting Rails à petit prix, et à l’européenne (même si les serveurs sont
aux USA).
RailsPlayground a commencé comme ça: un passioné qui avait UN compte sur
UN serveur dédicacé sous-utilisé. Mais dès le premier jour, l’offre a
été sérieuse, solide et professionelle.
Pour celui qui a les compétences systèmes requises, l’aventure est
possible:
Alain
Alain R. a écrit :
(btw, un serveur dédicacé coûte 99$/mois. Oui, vous lisez bien.)
Si je lis bien, je me demande surtout par quelle star est il
dédicacé ce
Cela dit, ce qui m’intéresse, c’est surtout un serveur dédié…
Oups.
C’est le syndrome “Jean-Claude Vandamme” : j’ai dû exagérer sur les
choux de Bruxelles avec des frites aux chicons.
Une fois.
Alain
Moi je trouve ça bien sympa! Dès que j’aurai un peu de temps je m’y
mettrai!
Pierric.
Le mercredi 01 février 2006 à 09:27 +0100, Alain R. a écrit :
(Je mets ma casquette de “méchant”)
“Moi je trouve ça bien sympa”.
Bien sûr que c’est sympa. Et c’est “gentil” aussi. Et généreux. Mais
c’est du bricolage. Au bout du compte, toutes ces offres gentillettes
sont peu inintéressantes pour les “clients” semi-sérieux: machines
faibles (pfs installées dans un salon), bande passante anémique,
infrastructure non-optimisée, zéro support et zéro garantie. C’est du
bricolage. Mais c’est gentil.
Hé !
Quelqu’un qui veut juste tester dans son coin ou monter un petit site
perso le temps de voir ce que ça donne ça lui suffit tout à fait le
bricolage.
Oui c’est zéro garantie et il est possible que ça tombe. Et alors ?
Tout dépend des besoins, laissez donc les gens qui n’ont pas besoin de
garantie s’organiser entre eux. Ils ont raison de le faire et le font
très bien.
D’ailleurs, je me permet de réagir aux hébergeurs low-cost. Je ne sais
pas ce qu’ils valent dans le milieu ruby mais coté PHP j’ai un assez bon
tour d’horizon et franchement la qualité de service n’est pas forcément
meilleure (quand on ne te dit pas que en fait non, les sauvegardes ont
grillé et où tu comprends “il y a marqué qu’il y a des sauvegardes mais
en fait ils n’en font pas”). Et le jour où un problème arrive tu te rend
compte que la garantie aussi elle est de zéro, c’est déjà bien quand tu
arrives à te faire rembourser les mois d’indisponibilité.
Entre un low-cost classique et des gens qui s’organisent entre eux dans
leur garage, la différence de qualité n’est pas si importante, la
différence de garantie est quasi nulle. Bref, on a ce qu’on paye, tout
simplement. Et entre payer très peu des gens qui prennent des bénéfices
et payer rien du tout quelqu’un qui bosse bénévolement … la différence
n’est parfois pas si importante.
(Remarque: les offres proposée dans la liste sont sincères, généreuses
et vraiment sympas. C’est un fait indiscutable.)
Ã?ric
Une fois pour toutes:
Offrir de l’hébergement dans sa cave est très instructif… pour
l’apprenti hébergeur. Il va rencontrer tous les problèmes système un par
un, et apprendre un tas de choses en cours de route. Pour ses “clients”
par contre, …
> Quelqu'un qui veut juste tester dans son coin ou monter un petit
site
> perso le temps de voir ce que ça donne ça lui suffit tout à fait
le
> bricolage.
Te viendrait-il a l’idée de ne pas acheter le libre Rails parce que
toute l’info est disponible en ligne “gratuitement”, dans les wikis et
les blogs? C’est sympa les blogs pourtant.
Je paye plus chaque mois pour ma ligne ADSL - 34â?¬/mois - que je n’ai
payé pour un an de hosting chez DreamHost.
Pour ce prix là , j’ai eu
> Oui c'est zéro garantie et il est possible que ça tombe. Et alors
?
Oublie les garanties, et regarde ton confort, ton efficacité et ta
productivité.
Tu débutes et tu déploies ta petite application, “juste pour voir”, et
rien ne va, écran blanc!? Ou elle s’éteint toutes les 30 minutes. Ou les
emails ne partent pas, sans messages d’erreurs. Ou les performances sont
épouvantables. Ou …
Si tu n’es pas un spécialiste Linux, tu te grattes la tête et tu perds
du temps.
A qui la faute?
> D'ailleurs, je me permet de réagir aux hébergeurs low-cost. Je ne
sais
> pas ce qu’ils valent dans le milieu ruby mais coté PHP j’ai un
assez bon
La liste Rails est instructive en ce domaine. C’est ce qui ma convaincu
d’essayer DH, malgré la méfiance que m’inspirait leur prix ridicules.
Nous sommes en 2006, et l’époque des BBS de quartier raccordés à 2
modems 1200 bauds est révolue.
Alain
D’ailleurs, même en france, un serveur dédié coûte moins cher que
99$/mois…
Moi, je serais bien partant pour lancer un serveur et proposer un
hébergement très très bas prix en Rails…
S’il y a suffisament de motivés (francophones) pour prendre un
hébergement, je me lance !
Disons, si on part à 20EUR/an les 500Mo, avec ce que vous voulez en
software dessus…
Bande passante illimitée (pas comme RailsPlayground).
Sous-domaines illimités.
Comptes mails illimités.
Y-a-t’il des intéressés ?
Pascal
[email protected] a écrit :
quel terme on utilise est loin d’être simple, franchement.
Bonsoir,
Pour moi la question qui se pose, pour les livres techniques, est le
décalage entre les exemples et le texte. La plupart des logiciels ou
langages on une origine et une syntaxe anglo-saxonne, pourquoi
s’acharner à vouloir traduire les termes propres à la syntaxe si on ne
traduit pas la syntaxe. Ce qui revient à maintenir 2 version de Ruby,
celle de toute la communauté et celle des français qui refusent
d’apprendre à parler anglais.
(Pour les romans il en va tout autrement bien sur !)
Je prends l’exemple de “scaffold” pour Rails. C’est peut-être très bien
de traduire ce mot, mais tous les exemples qui suivent vont contenir ce
terme et non pas “échafaudage”.
Le débutant n’aura-t-il pas du mal à s’y retrouver ? Ne serait-il pas
judicieux, de garder le terme anglais et de simplement en donner une
définition, une explication la première fois qu’on le rencontre.
Certes je lis l’anglais, j’essaie même de contribuer aux traductions
pour Railsfrance.org, mais je me mets à la place de quelqu’un capable de
décrypter une doc en anglais. Cette personne va préférer acheter et lire
la VF, mais pour des compléments d’information, elle n’a d’autre choix
que de décoder les documents anglais. Si on rajoute à sa difficulté en
ayant 2 termes différents, je ne suis pas persuader qu’on y gagne. De
même il est utopique, à mon avis, d’espérer égaler la quantité et la
qualité de la documentation anglaise avant un certain temps. Notre
spéléo de l’anglais à encore du boulot ! Autant lui faciliter la tâche.
Conclusion :
Je pense que les termes techniques faisant partie de la syntaxe ou étant
propre à un domaine ne nécessitent pas de traduction. Par contre il est
important d’expliquer ce qu’ils cachent, le périmètre qu’ils désignent.
Tremeur
trems wrote:
> La fierté (et sans doute aussi la flegme) française conduit à se
> retrouver avec des ingénieurs en informatique incapable de lire un
> document en anglais.
Une telle personne passe à côté de toute l’info contenue uniquement dans
les blogs, les wikis, les forums et les libres non-traduits.
Maillon faible.
Alain
�ric Daspet a écrit :
Tout ceci est vrai mais … si je me permet … ça n’a aucun rapport.
technique anglais sans problème.
Par contre toujours, si tu commences à laisser anglais les termes quiétrangère .
environnements anglais.
ou d’ignorer les autres langues, simplement de vouloir une interface
à ce long message je dis :
BRAVO !
Pascal
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs