Libertés de traduction et anglicismes
MachinisteWeb opened this issue · 75 comments
Je vais essayer de tenir une liste de décisions prises en ce qui concerne la traduction des termes pour nous aider à rester consistant. Ceci n'est pas figé et peut être rediscuté à souhait.
Anglicismes admis
Vue
- runtime : runtime
- prop(s) => prop(s)
- hook(s) : hook(s)
- slot(s) : slot(s)
- template(s) => template(s)
Vuex
- store : store
Global
- framework => reste framework.
- templates => Reste templates car modèles sera réservé à la traduction de models.
- fork => reste fork (avec les mots pouvant en dériver ex : « forker » pour l'action de faire un fork)
- release => release
- build => build
- SEO => la SEO
- package => package (comme package npm)
- scope => scope (si fait référence au « scope » de Angular)
- dirty checking => dirty checking (si fait référence au « dirty checking » de Angular)
- digest cycle => digest cycle (si fait référence au « digest cycle » de Angular)
- tree-shaking => tree-shaking (si fait référence au « tree-shaking » de Angular)
Liberté de traduction
Outils externes
Tous les noms des outils doivent être utilisé avec la casse fournie par la documentation officielle :
- Npm, NPM => npm
- Webpack => webpack
Vue
- progressive => évolutif
- component => composant
- model => modèle
- directive => directive
- data => données
- scope => portée
- data binding => liaison de données
- computed properties => propriétés calculées
- event listener => écouteur d'événements
- watcher => observateur
- mount => monter
- unmount => démonter
- scoped => portée limitée
- two-way binding => bidirectionnelle
- one-way binding => unidirectionnelle
- central event bus => canal d'événements central
- cookbook => tutoriel
Vue Router
- data pre-fetching => récupération de données.
- guard => interception
- chunk(s) => fragment(s)
Vue Server Renderer
- code-splitting => scission de code.
- bundle(s) => paquetage(s).
- bundle renderer => moteur de dépaquetage
- renderer => moteur de rendu
Vuex
- state => état
- to commit => acter
- to dispatch => propager
- single state tree => arbre d'état unique
- getter(s) => accesseur(s)
Global
- getter : accesseur
- setter : mutateur
- filter => filtre
- to proxy => proxifier
- custom elements : éléments personnalisés
- custom logic => logique personnalisée
- blazing Fast => ultra-rapide
- sponsored => sponsorisé (plutôt que parrainé)
- core plugins => plugins officiels
- repos/repository => dépôt
- core team => mainteneurs
- opening an issue => ouvrant un ticket
- library => bibliothèque
- scale => adaptabilité
- scale up => utilisation avancée
- scale down => utilisation minimale
- i.e. => c.-à-d.
- e.g. => ex. :
- workflow => workflow
- third party => tierce-partie
- performance update => performance au rafraîchissement (contexte de rafraîchissement d'écran).
- bare-bone => strict minimum.
- async => asynchrone.
- lazy-load => à la volée
- single-page : monopage
- single-file : monofichier
- toggle : permuter
- shortcut : raccourci
- shorthand : abréviation
- shorthand syntax => syntaxe abrégée
- modifier : modificateur
- bundle(s) => paquet(s)
- statement : déclaration/instruction (vuejs#754)
- first-class => première classe
- parsing => analyse
Il faut établir une liste des anglicismes admis. Certains mots anglais sont très répandus parmi les professionnels français, tels que "templates" ou "callback". Je mettrais aussi "fork" dans le lot, car j'entends très souvent le verbe "forker"
http://christopheducamp.com/2013/12/16/forker-un-repo-github/
https://fr.wikipedia.org/wiki/Fork_(d%C3%A9veloppement_logiciel)
Je partage cette avis pour fork et template.
Pour callback, même si ça me parle bien, je suis plutôt de l'avis d'utiliser « fonction de retour ».
En ce qui concerne watchers je sais pas réellement quoi en faire. Quand on a des listeners on dit des écouteurs aussi pour watchers j'ai pensé à surveillants sans grandes convictions...
Sur Riot j'avais utilisé "écouteurs" pour "listeners" et "observateurs" pour "watchers". Concernant les callbacks, je laissais "callback" en nom de variable mais décrivait verbalement le rôle de cette fonction: http://riotjs.com/v2/fr/api/observable/
Mais oui ! « observateurs », je l'ai déjà vu plusieurs fois ailleurs.
J'ai déporté le pan comparison.md sur cette Pull request (#6) ou vous pouvez me relire et ou l'on peut décider de ce que l'on garde/change pour le mettre à jour sur la liste de cette issue.
Un très bon site pour aider dans les traductions : http://www.linguee.fr/
Celui-ci cherche une expression ou un groupe de mots dans des textes publics traduits par des traducteurs professionnels. Vous avez ainsi une traduction qui tient compte du contexte, et vous pouvez choisir parmi les traductions proposées laquelle est la plus adaptée. C'est le jour et la nuit comparé aux médiocres traductions de Google Translate.
Pour le vocabulaire spécifique à Vue, voilà mes propositions:
- component => composant
- template => template
- model => modèle
- directive => directive
- filter => filtre
- data => données
- props => props
- computed properties => propriétés calculées
- event listener => écouteur d'événements
- watcher => observateur
- mount => monter
- unmount => démonter
concernant "props", ça me semble sujet à confusion d'utiliser attributs qui a un sens large à la fois en français et en anglais. Exemple avec cette phrase tiré de la doc anglais par exemple :
A prop is a custom attribute for passing information from parent components
(https://vuejs.org/v2/guide/components.html)
Du coup j'aurais tendance à conserver le mot props par souci de précision.
Pour "données"; je proposerai plutôt "données réactives" (le mot reactive se retrouve plusieurs fois dans la doc anglaise) pour indiquer que ce sont les données à l'origine du "re-rendu" du html d'un composant. Ca me semble plus pédagogique pour un débutant (que je suis) par rapport aux mots "données"
Les deux mots "data" et "reactive" sont présents dans la doc anglaise et sont utilisés quand les auteurs l'estiment approprié. Je ne pense que ce soit à nous de rajouter des mots même si ça te paraît plus pédagogique. On peut débattre de la marge de liberté qu'on s'accorde mais je pense que l'équipe Vue voudrait qu'on reste le plus proche possible du texte initial.
Tu as raison, ce qui me gêne un peu c'est qu'en anglais c'est facile de faire le lien entre la propriété "data" et le mot "Data"; mais en français on se retrouve avec "données", c'est moins clair d'autant que le mot est très vague
PS : ceci dit ça me va aussi, c'est juste une question en passant
On réétudiera la question au cas par cas. "data" est un mot latin, pluriel de datum et utilisé dans la plupart des langues y compris le français, donc on peut aussi le laisser tel quel là où ça fait sens.
hook => on peut laisser comme tel: https://fr.wikipedia.org/wiki/Hook_(informatique)
j'ai appliqué les traductions suivantes sur ces mots là, à discuter
- custom elements => éléments personnalisés ?
- custom logic => logique personnalisée ?
- proxies => proxifie ? ("Each Vue instance proxies all the properties found in its data object")
aucun doute sur logique personnalisée pour "custom logic", c'est couramment employé: http://www.linguee.fr/francais-anglais/search?source=auto&query=custom+logic
à discuter pour les autres
-
Proxifier, proxifie, etc., bon pour moi. OK
-
custom elements => éléments personnalisés OK
-
Je veux bien également conserver
props, je peux changer cela danscomparaison.mdou nous utilisons actuellement « attribut ». -
Logique personnalisé pour Custom logic ça semble correcte mais j'ai pas le contexte sous les yeux.
-
Pour ma part concernant Hook(s) : j'ai longtemps eu du mal à comprendre le terme quand il était énoncé au détour d'une phrase jusqu'à ce que je me penche sur le concept (somme toute simple finalement). Je trouve que « points d'accroche » explique sa notion. Je reste sur cela pour ma part, on s'en remets à l'avis de @nyl-auster pour trancher :)
Je trouve ça très joli point d'accroche par contre je ne l'ai jamais rencontré et une recherche google sur "point d'accroche developpement" ou "point d'ancrage informatique" ne me renvoie pas à des résultats pertinents par rapport au sens qu'on veut donner.
Tandis que "hook développement" par exemple me renvoie en premier à la page wikipedia qui donnes les bonnes informations : https://fr.wikipedia.org/wiki/Hook_(informatique)
Pour cette raison je suis plus favorable à la conservation de "hook"
Je propose d'indiquer point d'accroche entre parenthèses après la première occurence de "hook", puis d'utiliser hook par la suite.
On valide donc hook sans traduction. Mettre hook entre parenthèse puis utiliser points d'ancrage aurait du sens, mais pas l'inverse du coup.
Je change ça rétroactivement dans comparison.md.
Proposition :
toggle => permuter
Je sèche sur la traduction de "pattern", dans le contexte "code pattern" : un schéma, une figure, une organisation du code à bas niveau, une manière de concevoir qui se répète à travers le code de l'application.
La meilleure traduction que j'ai jusqu'ici est "Patron de conception": https://fr.wikipedia.org/wiki/Patron_de_conception ; mais je doute qu'elle parle à beaucoup de monde. Faut-il garder "pattern" d'après vous ?
J'ai déjà utilisé "patron de conception" dans la doc française, je l'avais déjà lu plusieurs fois ailleurs et il a une page wikipedia dédiée donc pour moi c'est ok.
PS : ha tiens non, j'avais utilisé "patron d'architecture" et c'était ici : https://fr.vuejs.org/v2/guide/instance.html .
oui patron d'architecture paraît plus approprié pour un cas haut niveau comme l'approche MVVM. Mais je ne pense pas que ça soit approprié pour parler de quelques lignes de code seulement.
Oui tout à fait. Sinon "motif de conception" ça ne se dit pas ?
j'ai trouvé des traces de "motif" comme traduction alternative avec "patron", ex: https://eilgin.github.io/php-the-right-way/pages/Design-Patterns.html
Les sources plus techniques traduisent le plus souvent "code pattern" par "pattern de code" : http://www.linguee.fr/francais-anglais/search?source=auto&query=code+pattern
Bah, utilisons ça, ça me semble clair et on changera si on trouve mieux plus tard (pattern de code)
Pour ma part, je traduirais selon cette règle :
- quand un « pattern » se résume à une ou deux lignes de code à la suite la traduction « motif » est approprié.
- quand on parle d'un groupe de ligne de code, sur plusieurs niveaux « patron » est plus approprié.
Genre grossomodo le « inline » c'est du motif et le « block » c'est du patron.
Ex :
Dans
arr.map(x => x * 2)
=> peut être considéré comme un motif.
Dans
var Exemple = function () {
var privates = {},
publics = this;
publics.name = function (name) {
return (name) ? (privates.name = name) && publics : privates.name;
}
};
var test = Exemple();
test.name("bruno").name(); // "bruno"
l'utilisation de publics, privates, etc. forme un patron.
J'ai lancé un brainstorm auprès des collègues, j'ai eu comme suggestions "squelette", "code type" et "modèle de code", "schéma", "patron" et enfin "motif" après un moment de réflexion.
Si le but est d'exprimer l'idée d'un "petit bout de code récurrent", pattern et motif (respectivement) sont ceux qui m'évoquent le plus cette idée. Et vous ?
Patron m'évoque quelque chose de plus gros (genre MVC)
@sylvainpolletvillard tu peux donner un exemple de phrase qui te fait galérer ?
regarde dans cette PR, on l'a plusieurs fois : #22
Perso je comprends l'idée uniquement si on rajoute "de code", "motif de code", "patron de code". Tout seul les termes font très bizarre. C'est encore "pattern" qui parle au plus de monde parmi mes collègues.
Dans mon open space ça se bat entre motifs et patterns, mais globalement une fois immergé dans la phrase ça semble pencher plutôt pour "pattern"
Je suis toujours plus favorable à laisser le mot original quand il y a un doute sur une traduction. Cela laisse la possibilité au lecteur de se renseigner sur le mot tandis qu'une traduction approximative pose un risque de mauvaise compréhension et oblige le lecteur à comparer lui-même avec la version originale.
Quelqu'un a une traduction pour "flow control" ? Contexte :
<!-- flow control won't work either, use ternary expressions -->
{{ if (ok) { return message } }}(je suis sur syntax.md )
Contrôle de flux littéralement, mais je ne comprends ni la version anglaise ni la version française 😄
Comme l'a dit @sylvainpolletvillard il parle de « contrôle de flux » https://developer.mozilla.org/fr/docs/Web/JavaScript/Guide/Contr%C3%B4le_du_flux_Gestion_des_erreurs également appelé « structure de contrôle » https://developer.mozilla.org/fr/docs/Glossaire/Structure_de_contr%C3%B4le
C'est tout ce qui est if, else, for, while, etc. qui ne sont pas des expressions qui retourne un opérande ou qui ne sont pas des expressions de déclaration (var, function). Dans ce sens il ne peuvent pas être utiliser dans un contexte qui attends une expression.
Cependant, comme l'opérateur ternaire (condition) ? "a" : "b" est une expression qui retourne un opérande (soit "a" ou "b") il peut être évaluer dans un contexte d'expression.
Plus de détails ici sur la différence entre instruction, déclaration, contrôle de flux, expression, condition, opérande, opérateur, etc. : https://blog.lesieur.name/difference-entre-type-null-et-type-undefined-en-javascript/#comment-a-marche-
Mais du coup je traduis par "controle de flux" dans le doc ?
Oui. Les traductions appropriées selon moi sont :
<!-- ceci est une déclaration, non une expression : -->
{{ var a = 1 }}
<!-- (le contrôle de flux | les structures de contrôle) ne fonctionnerai(t | ent) pas non plus, utilisez plutôt des expressions ternaires -->
{{ if (ok) { return message } }}Car le « flux » est l'ensemble des « if, else, switch, etc. » et chaque élément indépendamment est une structure de contrôle.
Comment on traduit "statement" ? Instruction ?
déclaration
okay merci (en train de faire la review de events.md)
Si tu fais référence à « Instead of binding directly to a method name, we can also use methods in an inline JavaScript statement » je pense qu'il faut ouvrir une PR à l'original car le mot « statement » doit être remplacé par « expression » ou au pire « instruction » car comme il a clairement été défini dans la doc syntax.md les déclarations et les contrôles de flux ne peuvent pas être mis dans Vue.
<!-- this is a statement, not an expression: -->
{{ var a = 1 }}Une déclaration commence par function ou var. Si function est à droite d'un = alors c'est une affectation (expression) et non une déclaration. Donc ce ne sont pas des « statement » les expressions say('hi') et say('what').
Cependant dans la déclaration var test1 = "1", test2 = 2;, la partie test1 = "1", test2 = 2 est bien une expression.
EDIT :
Je vois que sur http://www.w3schools.com/js/js_statements.asp il utilise « statement » pour faire référence à des instructions qui sont parfois des expressions.
Il disent que ceci est un statement
document.getElementById("demo").innerHTML = "Hello Dolly.";ce qui est faux. Il n'y a aucune déclaration ici, juste une affectation. C'est simplement une expression et ça peut être évalué par Vue dans un v-.
exemple <div v-if="(test = "Hello Dolly.") === "Hello Dolly.">Coucou</div> sera affiché.
À moins qu'il y est truc que j'ai fondamentalement pas compris ?
EDIT 2 :
J'ai demandé sur Vue.org pour bien comprendre la signification réel de « statement » vuejs#754
C'est validé : statement = déclaration vuejs#754
Cela signifie que dans event l'original va devenir :
Instead of binding directly to a method name, we can also use methods in an inline JavaScript expression:
Sometimes we also need to access the original DOM event in an inline expression handler
À traduire en conséquence
UPDATE :
En réalité statement ne veut pas seulement dire déclaration. Voici l'explication FR tirée de vuejs#754
Instruction
= Une Instruction est soit un Statement soit une Expression.
Expression
L'expression est composée uniquement d'opérandes (primitive, objets, variable) et d'opérateurs qui retourne une valeur d'opérande (ou une référence vers une valeur d'opérande). Parce que void 0 retourne une valeur undefined qui peut-être affecté avec =, c'est une expression.
> void 0
<· undefinedest une expression car dans le statement suivant, il est affectable.
> var test = void 0;
<· undefinedStatement
Le Statement est composé de sous Statement ou/et d' Expression.
- (Declaration) Statement ou Block Statement ou Function Statement ou {Other} Statement est quelque chose qui retourne une valeur
undefinedmais qui ne peut pas être affectée.
> if (test) { true; } else { false; }
<· undefinedest un statement car dans le statement suivant, il n'est pas affectable.
> var test = (if (test) { true; } else { false; }); // if n'est pas un opérateur ou un opérande.
<· Uncaught SyntaxError: Unexpected token if> var test = (var test); // var n'est pas un opérateur ou un opérande.
<· Uncaught SyntaxError: Unexpected token varOn a donc en EN la description suivante :
┌──────────────────────────────────────────────────┬───────────────────────────────┬───────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Instruction │ Instruction │ Instruction │ Instruction │
├──────────────────────────────────────────────────┼──────────────────────────┬────┼──────────────┬────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ │ │ │ │ Control Flow │
│ │ │ │ │ ├────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────┤
│ (Declaration) Statement │ │ │ │ │ Block statement │ Block statement │
├─────┬───────────────────────────────────────┬────┤ │ │ │ ├──────┬────────────────┬─────┬──────────────────────┬───┼────────┬───────────────────────┬─────────────────────┬───┤
│ │ Expression │ │ Expression │ │ Expression │ │ │ Expression │ │ Instruction │ │ │ Instruction │ Instruction │ │
│ ├─────┬────┬────┬────┬──────┬────┬──────┤ ├─────┬────┬───────────────┤ ├────────┬─────┤ │ ├─────┬─────┬────┤ ├─────────────────┬────┤ │ ├──────────────────┬────┼────────────────┬────┤ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Expression │ │ │ │ Expression │ │ Expression │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├─────┬────┬──────┤ │ │ ├──────┬────┬──────┤ ├─────┬────┬─────┤ │ │
│ │ var │ op │ od │ op │ od │ op │ var │ sc │ prp │ op │ operand │ sc │ op │ var │ sc │ │ od │ op │ od │ │ var │ op │ od │ sc │ │ │ var │ op │ od │ sc │ var │ op │ od │ sc │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ var num = 20 + true , bool ; str = "Hello World" ; delete str ; if ( num === 21 ) { bool = true ; } else { bool = true ; num = 0 ; } │
└─────┴─────┴────┴────┴────┴──────┴────┴──────┴────┴─────┴────┴───────────────┴────┴────────┴─────┴────┴──────┴─────┴─────┴────┴─────┴─────────────────┴────┴───┴────────┴──────────────────┴────┴────────────────┴────┴───┘
qui devient en FR la description suivante :
┌──────────────────────────────────────────────────┬───────────────────────────────┬───────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Instruction │ Instruction │ Instruction │ Instruction │
├──────────────────────────────────────────────────┼──────────────────────────┬────┼──────────────┬────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ │ │ │ │ Contrôle de flux │
│ │ │ │ │ ├────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────┤
│ Déclaration │ │ │ │ │ Structure de contrôle │ Structure de contrôle │
├─────┬───────────────────────────────────────┬────┤ │ │ │ ├──────┬────────────────┬─────┬──────────────────────┬───┼────────┬───────────────────────┬─────────────────────┬───┤
│ │ Expression │ │ Expression │ │ Expression │ │ │ Expression │ │ Instruction │ │ │ Instruction │ Instruction │ │
│ ├─────┬────┬────┬────┬──────┬────┬──────┤ ├─────┬────┬───────────────┤ ├────────┬─────┤ │ ├─────┬─────┬────┤ ├─────────────────┬────┤ │ ├──────────────────┬────┼────────────────┬────┤ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Expression │ │ │ │ Expression │ │ Expression │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├─────┬────┬──────┤ │ │ ├──────┬────┬──────┤ ├─────┬────┬─────┤ │ │
│ │ var │ op │ od │ op │ od │ op │ var │ sc │ prp │ op │ opérande │ sc │ op │ var │ sc │ │ od │ op │ od │ │ var │ op │ od │ sc │ │ │ var │ op │ od │ sc │ var │ op │ od │ sc │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ var num = 20 + true , bool ; str = "Hello World" ; delete str ; if ( num === 21 ) { bool = true ; } else { bool = true ; num = 0 ; } │
└─────┴─────┴────┴────┴────┴──────┴────┴──────┴────┴─────┴────┴───────────────┴────┴────────┴─────┴────┴──────┴─────┴─────┴────┴─────┴─────────────────┴────┴───┴────────┴──────────────────┴────┴────────────────┴────┴───┘
On voit que le mot « Statement » disparaît en français. « Statement » peut donc vouloir dire plusieurs chose en fonction du contexte.
D'après vous, les mots "getter" et "setter" doivent-t-ils rester en anglais ou être traduits ?
Mon avis personnel : getter et setter sont des termes courants dans le monde informatique français. Je serai donc partisan de les laisser ainsi.
Votre avis ?
tl;dr => partisant de la traduction accésseur/mutateur.
Pour ma part, comme proposer à @sylvainpolletvillard dans l'API je pense que accésseur et mutateur méritent d'être promu en français.
La référence MDN nous encourage en ce sens. Je la trouve toujours très clair, accessible et traduite. Aussi les accesseurs et mutateurs y sont correctement décrit. Préciser entre parenthèse getter/setter le terme anglais une fois dans un article n'est pas dénuer de sens.
- accesseur : https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Fonctions/get
- mutateur : https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Fonctions/set
Voici mon raisonnement avec Jean. Jean est français, Jean n'est pas encore assez au point/à l'aise en anglais pour parcourir les documentations officiels de manière productive. Jean se tourne donc vers les documentations française. En ce sens, il y a de forte chance que Jean se réfère à la documentation MDN qui est, en français, la mieux fournit selon moi. Dans ce cas, ce qui parlera à Jean dans la littérature française sera l'accesseur et le mutateur. Étant convaincu que pour un développeur du niveau de Jean, Vue est la librairie de liaison de données la plus abordable et qui pourra le suivre tout au long de ses projets et de sa montés en puissance, je souhaite qu'il s'y retrouve dans son apprentissage jusqu'au jour où il nagera plus facilement dans les documentations anglaise et ou il y aura appris que accesseur et mutateur se disent getter et setter.
Ayant moi même appris le JavaScript par de la littérature anglaise, les termes getter et setter me parle plus mais je préfère utiliser leur équivalent français dans un texte français.
Un bon indicateur pour savoir si l'on garde ou non un terme en anglais est de se demander si ils respectent deux conditions :
1) il existe une traduction dans notre langue
2) il n'y a pas d'ambuïguité quand à la nature de la traduction (trop de traduction possible).
Ce qui est là clairement le cas avec accesseur et mutateur.
Ce qui n'est par exemple pas le cas pour template (doute sur la nature), fork (pas de consensus de traduction), build (doute sur la nature), etc.).
@haeresis je m'incline, tu as raison et merci d'avoir rajouter getter et setter dans l'entête de cette issue.
OK par contre pas d'accent aigu sur accesseur. Aussi en cas de doute, ajouter le terme original entre parenthèses derrière ne coûte pas cher et ne fait jamais de mal selon moi.
@haeresis @sylvainpolletvillard et mettre mutateur au singulier
Pour assets je propose ressources , il me semble que "ressource graphique" est le plus répandu en français. Qu'en pensez-vous ?
Je suis dans forms.md et les "input" et "textarea" sont souvent évoqués.
J'ai pensé à "champ de formulaire" et "zone de texte multiligne" mais je ne sais pas trop.
Le lien vers le contexte : https://vuejs.org/v2/guide/forms.html
je pense que tous les développeurs web français connaissent ces termes vu leur usage en HTML non ? Je suis d'avis de les laisser entre backticks ``
@sylvainpolletvillard c'est le plus clair, après la doc anglaise me donne l'impression de vouloir dire "champ de formulaire" en disant "input form"; c'est à dire en incluant implicitement dans "input" les checbox, select, bref tout ce qui n'est pas un textarea. C'est comme ça que vous comprenez "input" en français vous ?
Oui après ça dépend du contexte, on verra au cas par cas à la PR 😄
Pour "slots", ça me paraît être un concept spécifique à Vue et le mot est couramment utilisé en français, donc je suis d'avis de laisser tel quel.
Pour bundle, est-ce que le terme doit être laissé tel quel ?
De même pour resolve (Promise), et first-class concept.
J'ai pu rencontrer ces mots dans la pull-request vuejs-fr/vue-ssr-docs#4 (fichier routing.md).
J'ai déjà vu traduit "bundle your app" en "empaqueter votre application", donc "paquet" pourrait être une traduction valide : http://www.linguee.fr/francais-anglais/search?source=auto&query=application+bundle ; d'un autre côté les speakers français utilisent souvent le terme "bundle", donc si "paquet" n'est pas assez explicite ce n'est pas trop gênant de garder le terme d'origine selon moi.
Pour resolve de Promise, MDN parle de "tenir la promesse" : https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/Promise ; je trouve que ça sonne bizarre, je pense que "résoudre" et "rejeter" sont plus proches des termes d'origine et donc plus explicites.
Pour first-class concept, tu pourrais donner le contexte ?
Vue provides async components as a first-class concept
Cependant, je ne sais pas si first-class concept correspond à https://en.wikipedia.org/wiki/First_class_(computing) ou https://en.wikipedia.org/wiki/First-class_function...
Je penche notamment en faveur du premier lien, même si je n'en suis pas vraiment sûr.
Le concept d'objet de première classe est celui-ci : https://fr.wikipedia.org/wiki/Objet_de_premi%C3%A8re_classe
En JavaScript les fonctions sont des objets, on parle également de fonction de première classe.
« Une fonction pouvant être utilisée comme une donnée standard c.-à-d. être passée en tant qu'argument, recevoir des arguments fonctionnels ou être retournée en tant que valeur fonctionnelle est appelée une fonction de première classe. »
et pour valeur fonctionnelle (functional value ou function valued)
« Comme mentionné, une fonction peut-être non seulement passée à travers les paramètres des fonctions appelées, mais également retournée comme valeur par une autre fonction. Une fonction qui retourne une autre fonction est appelée une fonction avec valeur fonctionnelle. »
Dans le cas de Vue, cela signifie, j'imagine, que ses instances et ses composants (instances donc) font leur vie indépendamment et peuvent être bien découplé et ramené plus tard (notamment grâce au système props/event qui rende bien chaque instance de « première classe »).
Je mettrais « concept de première classe » ou « concept d'objet de première classe ».
Pour la Promesse, je préfère également résoudre et rejeter. Pour moi « tenir la promesse » est a utilisé en lieu et place de « fulfill a promise ».
Je viens de rencontre le mot parsing en traduisant le fichier essentials/getting-started.md sur le projet vue-router.
Faut-il traduire ce terme en analyse de code, évaluation de code, traitement de code, (...) ou alors le laisser tel quel ?
parsing => analyse ou traitement
ça me paraît bien 👍
Pour ma part j'étais plus sur analyse et traitement alors disons analyse :)
Ok ça marche, merci !
Traduction pour payload ?
Pour ma part je l'ai précisé une fois entre parenthèse et j'ai mis « argument additionnel » à chaque itération ce qui n'est valable que dans ce contexte précis car à priori sa se traduit par charge utile.
J'avais pensé à « poids » mais rien à voir, on parle bien de passer un argument lors de la mutation, c'est juste que cette argument est appelé « payload ».
Mais si il y a mieux je suis preneur !
You can pass an additional argument to
store.commit, which is called the payload for the mutation:
devient
Vous pouvez donner un argument additionnel (« payload ») à la fonction
store.commitlors de la mutation :
puis chaque occurence de « payload » est remplacé par argument additionnel
payload => charge utile
OK avec la proposition de @haeresis
Doit-on traduire stub ? (contexte des tests)
De même pour source map ? (https://github.com/vuejs-fr/vue-test-utils/pull/4/files#diff-c7445572fc92e5098d56898ede29918eR54)
Pour ma par pour un fichier source map je propose un fichier coordinateur de source (« source map ») ou de le laisser ainsi.
Pour stub ça me parle vraiment pas tel quel alors que le partie pris par @Yaty et terme de traduction me parle.
Je laisserai "source map"
Dans la section Global:
- release => release (et non realease => realease)
C'est corrigé, merci! 🙂
Est-ce que vous avez déjà des traductions pour "cookbook" et "client-side storage"?
Perso je garderais l'anglicisme "cookbook" plus répandu dans le milieu tech francophone que "livre de recettes"
Et "stockage côté client" pour client-side storage.