Libertés de traduction et anglicismes

[MachinisteWeb]

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 (Statement is a same word for « Instruction » or « Declaration » ? vuejs/v2.vuejs.org#754)
• first-class => première classe
• parsing => analyse

[sylvainpolletvillard]

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)

[MachinisteWeb]

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...

[sylvainpolletvillard]

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/

[MachinisteWeb]

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.

[sylvainpolletvillard]

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.

[sylvainpolletvillard]

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

[yann-yinn]

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.

[yann-yinn]

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"

[sylvainpolletvillard]

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.

[yann-yinn]

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

[yann-yinn]

PS : ceci dit ça me va aussi, c'est juste une question en passant

[sylvainpolletvillard]

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.

[sylvainpolletvillard]

hook => on peut laisser comme tel: https://fr.wikipedia.org/wiki/Hook_(informatique)

[yann-yinn]

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")

[sylvainpolletvillard]

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

[MachinisteWeb]

• Proxifier, proxifie, etc., bon pour moi. OK

• custom elements => éléments personnalisés OK

• Je veux bien également conserver props, je peux changer cela dans comparaison.md ou 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 :)

[yann-yinn]

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"

[sylvainpolletvillard]

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.

[MachinisteWeb]

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.

[Teraglehn]

Proposition :
toggle => permuter

[sylvainpolletvillard]

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 ?

[yann-yinn]

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.

[yann-yinn]

PS : ha tiens non, j'avais utilisé "patron d'architecture" et c'était ici : https://fr.vuejs.org/v2/guide/instance.html .

[sylvainpolletvillard]

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.

[sylvainpolletvillard]

parsing => analyse ou traitement
ça me paraît bien 👍

[MachinisteWeb]

Pour ma part j'étais plus sur analyse et traitement alors disons analyse :)

[Kocal]

Ok ça marche, merci !

[Kocal]

Traduction pour payload ?

[MachinisteWeb]

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.commit lors de la mutation :

puis chaque occurence de « payload » est remplacé par argument additionnel

[sylvainpolletvillard]

payload => charge utile
OK avec la proposition de @haeresis

[Kocal]

Doit-on traduire stub ? (contexte des tests)

[Kocal]

De même pour source map ? (https://github.com/vuejs-fr/vue-test-utils/pull/4/files#diff-c7445572fc92e5098d56898ede29918eR54)

[MachinisteWeb]

Pour ma par pour un fichier source map je propose un fichier coordinateur de source (« source map ») ou de le laisser ainsi.

[MachinisteWeb]

Pour stub ça me parle vraiment pas tel quel alors que le partie pris par @Yaty et terme de traduction me parle.

[forresst]

Je laisserai "source map"

[mehdibaha]

Dans la section Global:

• release => release (et non realease => realease)

[Kocal]

C'est corrigé, merci! 🙂

[sylvainpolletvillard]

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.