-
Notifications
You must be signed in to change notification settings - Fork 164
Glossaire
| anglais | français |
|---|---|
| App | Appli (plus court et « réel » que « application ») |
| Arbitrary | Quelconque (« arbitraire » sous-entend généralement une décision humaine) |
| Arrow function | Fonction fléchée |
| Assign | Affecter (mais pour “assign the initial value of X”, on dira plutôt « initialiser X » |
| Assume, Assumption | Supposer, Supposition |
| Boilerplate (code) | Code générique |
| Bug | Bug (en aucun cas le moche et inutilisé bogue, mais on dira déboguer) |
| Callback | Fonction de rappel |
| Caveats | Limitations |
| Class component(s) | Composant(s) à base de classe |
| Click me | Cliquez ici (un élément d'interface n'est pas une entité animée, sujet, capable d'exprimer une telle demande) |
| Closure | Fermeture lexicale (NdT initiale, VF à favoriser) |
| Confusing | Déroutant, déconcertant. Voir aussi Confusion dans la liste qui suit. |
| Context | Contexte (au sens React : avec une majuscule) |
| Debug, Debugging | Déboguer, Débogage |
| Error Boundaries | Périmètre d’erreur (NdT initiale, VO à favoriser) |
| Escape hatch | Échappatoire |
| Event | Événement (on conserve les deux accents aigus malgré l'autorisation d'un accent grave de la dernière réforme) |
| Event handler | Gestionnaire d’événement (au pluriel, les deux mots prennent un « s ») |
| Feature | Fonctionnalité / Aspect (suivant le contexte) |
| Function component(s) | Fonction(s) composant(s) |
| Higher-Order Components / Functions | Composant / Fonction d’Ordre Supérieur (pour l’abréviation, favoriser le “HOC” de la VO) |
| Hook | Hook (pas de VF) |
| Immutability, Immutable, Mutable, Mutation | Immutabilité, Immuable, Modifiable, Mutation |
| Input | Si on parle d'un champ, on dira "champ" ou "champ de saisie" ou "champ textuel". Si on parle d'une action de l'utilisateur qui sert d'entrée aux rendus etc., on dira "action" (si ça peut inclure des entrées souris) ou "saisie" (si c'est juste dans des champs). Si on parle vraiment d'une donnée abstraite (notion d'E/S), en entrée d'un algorithme par exemple, on dira « entrée » |
| In the future | À l’avenir (surtout pas « dans le futur ») |
| Lifecycle | Cycle de vie |
| Lift(ing) state up | Faire remonter l’état |
| Linter | Linter (pas de VF) |
| Listener, Event Listener, Event Handler | Écouteur, Écouteur d’événement, Gestionnaire d’événement (au pluriel, les deux mots prennent un « s ») |
| “looks like this” | « ressemble à ceci » |
| Markup | Balisage |
| Next steps | Et maintenant ? (en fin de page, pour lier vers la suite des docs) |
| Note | Remarque (blocs jaunes des docs) |
| Notice | Remarquez / Voyez comme (début de phrase, suite à un extrait de code ou une sandbox) |
| Online playground | Terrain de jeu en ligne |
| Parameter | Le plus souvent employé pour désigner la valeur réellement passée, donc « argument ». Si on parle formellement du paramètre de la signature, dans l'abstrait, on gardera « paramètre » |
| Piece (of code/logic/JSX) | Bout (de code / logique / JSX) plutôt que "morceau", trop "physique" |
| Placeholder | Valeur suggérée |
| Playground | Bac à sable |
| Predictible | Prévisible |
| Prevent | Éviter (« prévenir » est plus juste mais d'un registre de langage trop recherché / soutenu, et peut être ambigu vis-à-vis du sens « avertir », ce qui est déroutant) |
| Prop drilling | Faire percoler les props |
| Portals | Portails |
| Prop(s) | Prop(s) (féminin) |
| Race condition | Race condition, en italiques (aucune VF bien établie ; l'éventuel lien Wikipedia pointera toutefois sur la page FR) |
| Reconcilation / Reconciler | Réconciliation / Réconciliateur |
| Reducer | Réducteur |
| Ref | Ref (pas de VF) |
| Render(ing) | Affichage / Afficher (cas général) -- Renderer / Rendering (mécanisme technique du moteur React, décrit spécifiquement) |
| Render Props | Props de rendu |
| Repository | Dépôt |
| Réspond | Réagir (plutôt que "répondre"), la plupart du temps ("réagir aux événements") |
| Return | Renvoyer (« retourner » est une notion spatiale de rotation) |
| Sandbox | Bac à sable |
| Side effect(s) | Effet(s) de bord (on n'accorde pas « bord ») |
| Subscription, Subscribe, Unsubscribe | Abonnement, S’abonner, Se désabonner |
| Support(ed) | Prise en charge / pris(e) en charge (en aucun cas « Support(er) » / « Supporté(e) ») |
| Tag | Balise |
| Throw (an error/exception) | Lever (une erreur/exception). En particulier, pas « lancer » ni « générer » |
| Timer | Horloge (contexte des API web type setTimeout, setInterval). En aucun cas « minuteur » ou « compte à rebours » |
| Tutorial | Tutoriel (éviter Didacticiel) |
| Typechecking | Validation de types |
| UI | Interface utilisateur |
| Web Components | Web Components (VF inutilisée, favoriser la VO) |
| What's next? | Et maintenant ? (notamment en bas des pages d'intro de chapitre / section) |
| Widget | Chaque fois que possible, « élément d’interface ». Si c'est ampoulé dans le contexte, on garde mais en italiques : widget |
| Wrapper | … d'enrobage / enrobant (ex. "wrapper node" → "nœud enrobant", "wrapper element / tag" → "élément enrobant") |
| Wrapping | Enrobage (pas englobage) |
Les termes et tournures ci-dessous ont besoin de plus de contexte pour choisir leur bonne traduction, ou les choix de traduction que nous avons fait peuvent parfois nécessiter une justification…
Asynchrone / Asynchronicité. On ne dit en effet pas, en français, « asynchronisme ».
On dit qu’une fonction / portée “closes over” un identifiant lorsqu’elle référence un identifiant présent dans une de ses fermetures lexicales (closures).
En français, on traduira généralement “closes over X” par « récupère X depuis la fermeture lexicale ».
C’est être à l’aise avec quelque chose. “If you’re not comfortable with callbacks” se traduirait par « si vous n’êtes pas à l’aise avec les fonctions de rappel », par exemple.
Voir aussi “Familiar” plus bas
On ne traduira presque jamais par « confusion », qui n’a pas le même sens en français. Les docs tech l’emploient surtout dans des phrases du type *“It can cause/create some confusion.”, qu’on traduira plutôt par quelque chose comme « Ça peut s’avérer déconcertant. »
Voir aussi “Confusing” dans la première liste.
Tout dépend du contexte. Si ça fait référence à la conception visuelle de quelque chose, on gardera design, bien établi en français (au sens de designer).
Pour le design d’une API, d’un bloc de code, etc., on parlera de « conception ».
L’expression “by design” est le plus souvent traduite par « volontaire », « voulu » ou « intentionnel ».
Enfin, les design patterns ont une traduction assez établie, même si je n’en suis pas hyper fan : « motifs de conception ».
Le MDN parle de « décomposition », ce qui est juste en soi mais ne correspond pas à l’usage établi en français, pas plus que pour les types spécifiques. Voici un petit récap’ :
| anglais | MDN FR | Préférer… |
|---|---|---|
| destructuring | décomposition | déstructuration |
| array destructuring | décomposition de tableau | déstructuration positionnelle* |
| object destructuring | décomposition d’objet | déstructuration nominative** |
* Il s’agit en fait de déstructurer n’importe quel itérable, revenir à la notion de position est donc plus juste.
** Un tableau est aussi un objet, ce n’est pas ici le cœur du sujet ; l’idée est qu’on se base sur les noms des propriétés, et non sur des positions.
Là aussi, rien à voir dans notre contexte avec « familier », qui indique un registre de langage. Le contexte classique est “be familiar with” ou “if this looks familiar”.
L'idée est qu’on a déjà croisé le sujet pas mal de fois, qu’on y est habitués.
On traduira souvent “if you’re not familiar / unfamiliar with X” par « si vous n’avez pas l’habitude [travailler avec] X », et “this looks familiar” par « ça vous rappelle quelque chose » (plus naturel / moins formel que « ça vous semble familier »).
Voir aussi “Comfortable” plus haut
Il existe une traduction assez immonde : « cadriciel » (qui ne fait penser qu’à Lando Calrissian, on est d’accord ?). On oublie ça tout de suite.
Le terme anglais est ultra établi dans l’usage français, on le garde tel quel.
Voir aussi “Library” plus bas
On l’utilise presque toujours dans l’expression “in hindsight”, qui signifie « avec le recul ».
Ne pas confondre avec “insight” (ci-après).
Difficile à bien transmettre en français (et j'en sais quelque chose, ma boîte s’appelant Delicious Insights).
Un insight, c’est une sorte de révélation, la compréhension soudaine de quelque chose, le plus souvent sans avoir eu à se fader un laborieux cheminement d’apprentissage. On sous-entend souvent qu’il s’agit d’un aspect profond, fondamental du sujet en question, qui parfois n’a été perçu par personne jusqu’ici.
Une expression comme “it should give you some insights about state management” se traduira par « ça devrait [considérablement] améliorer votre compréhension de la gestion d’état »
Ne pas confondre avec “hindsight” (ci-avant).
La doc abonde de phrases suggérant une approche alternative en disant “do [this and that and this] instead.” Il ne faut pas laisser ça en fin de phrase, et éviter la traduction « à la place », aussi. On préfèrera de loin utiliser « plutôt » et le repositionner comme l’adverbe qu’il est. En début de phrase, on peut utiliser « Au lieu de ça ».
perform your work in componentDidMount() or the other lifecycle methods instead
⬇️
faites-le plutôt dans
componentDidMount()ou d’autres méthodes de cycle de vie
Ou encore :
consider using the prop directly instead
⬇️
voyez si vous ne pouvez pas plutôt utiliser la prop directement
Le terme VF « Bibliothèque » est très établi, alors on s’en sert. J’assassinerai personnellement quiconque utilise à tort « librairie », qui est un faux-ami 😉
Voir aussi “Framework” plus haut
Dans le cadre de React, ces termes revêtent une signification bien précise. En substantifs (noms), on dira « montage » et « démontage », en verbes on dira « monter » et « démonter », en mode pronominal (ex. « se démonter ») quand le composant agit sur lui-même.
Le montage, c’est l’apparition du composant dans la couche d’affichage (qui n’est pas nécessairement un DOM). Le démontage, c’est son retrait.
Mais ces termes ne sont pas encore bien établis dans les textes français sur React (à nous justement de les ancrer via la doc officielle !), aussi lorsqu’on s’en sert pour la première fois, on utilisera une NdT concise précisant par ailleurs le sens du terme. Exemple :
React performs the cleanup when the component unmounts.
⬇️
React procède au nettoyage quand le composant se démonte (sort de la couche d’affichage, NdT)
Ou encore :
When the reconciler encounters a host element, it lets the renderer take care of mounting it.
⬇️
Quand le réconcilieur rencontre un élément hôte, il laisse le renderer s’occuper de son montage (de son injection dans la couche d’affichage, NdT).
Ce sont des termes-clés dans le monde React. Mais leur usage anglais a besoin de pas mal d’adaptations pour la VF.
- “The component renders / produces its rendering” ➡️ « le composant fait son rendu »
- “The parent renders its children ” ➡️ « le parent fait le rendu de ses enfants »
Lorsqu’une page utilise le mot “renderer”, à la première utilisation, elle utilisera la VF plus une NdT longue précisant le recours choisi à la VO :
React leaves it to the renderer.
⬇️
React laisse ça au moteur de rendu. (Dans la suite de cet article, pour des raisons de concision, nous emploierons le terme générique anglais renderer sans italiques, NdT)
Là aussi, on touche à quelque chose de très commun avec React. L’état en question peut être de deux natures :
- état local (cas majoritaire), c’est-à-dire celui au sein d’un composant, inaccessible de l’extérieur. On traduira alors le plus souvent “state” par « état local », sauf si aucune ambiguïté n’est à craindre.
- état (global) applicatif, par ex. celui qu’on trouverait dans un store Redux. Dans un tel cas, on parlera d’« état applicatif » ou d’« état global ».
On traduira “stateful” par « à état » (et non « avec état »), et “state logic” par « logique à état » plutôt que « logique d’état » (qui fait un peu trop « raison d’État »).