-
Notifications
You must be signed in to change notification settings - Fork 164
Meilleures pratiques de traduction
- Voix passive
- Ton
- Intention
- Titres, IDs de titres et ancres des liens
- Exemples et codes sources
- Défis et exemples
- Liens vers des docs externes
- Adverbes, locutions adverbiales et compléments circonstanciels
- Mots français à n’importe quel coût
- Erreurs classiques de conjugaison
- Gérondif
- Participes passés
- Faux amis
- Au sujet de l’écriture inclusive
- Typographie
- Respecter l’algo de diff
Ce document tente de centraliser l’ensemble des éléments importants du savoir-faire de traduction technique des membres de l’équipe, notamment les traducteurs chevronnés, afin d’aider les plus novices à monter en gamme rapidement, et de réduire la charge lors des revues de code internes sur les PR de traduction.
L’anglais recourt énormément à la voix passive. Parfois, le français fera la même chose :
React has been designed from the start for gradual adoption
⬇️
React a été conçu dès le départ pour une adoption progressive
Mais très souvent, on optera plutôt pour une voix active, car la voix passive serait gauche et « ampoulée » en français :
But why is using
setInterval()
andclearInterval()
annoying with Hooks?
️️⬇️
🔴️ Mais pourquoi l’utilisation de
setInterval()
etclearInterval()
est-elle énervante avec les Hooks ?
✅ Mais pourquoi est-ce si énervant d’utiliser
setInterval() et
clearInterval()` avec les Hooks ?
Notez que la documentation de React essaie très fort de favoriser la voix active, ça devrait donc ne pas être un si gros problème…
La doc contient des pages plus ou moins formelles, et il faut respecter ce ton. Selon l’objectif de la page (ex. accompagnement de tuto vs. référence API intégrale), le ton ne sera pas le même. Une page, ou même une section de doc, dont le ton varie trop est vite source de gêne.
Par exemple, « cela » est assez ampoulé et formel, on préfèrera généralement le plus fluide « Ça ».
Essayez de résister à la tentation des figures de style. On n’est pas dans une copie de philo ou un article de journal d’Afrique équatoriale, qui font un concours permanent de métaphores, allitérations, zeugmes et autres ressorts visant surtout à établir leur culture littéraire mais oublient de faire passer un message clair.
Une doc technique sert à transmettre une info de façon claire et concise. On suit la règle d’Hemingway, autant que possible : sujet, verbe, complément. Au présent de l’indicatif et en voix active, autant que possible.
Si vous tombez sur du contenu utilisant des expressions idiomatiques (ex. jump the shark, bite the bullet, catch-22, perfect storm), peut-être spécifiques aux US, et que vous n’êtes pas sûr-e de comment procéder, jetez d’abord un œil au glossaire pour voir si on n’a pas déjà référencé une traduction de référence, et sinon renseignez-vous : cet idiome porte avec lui un ton, une intention, qu’il faut essayer de retranscrire au plus près dans notre choix d’expressions équivalentes.
La priorité, dans une traduction, est de restituer convenablement le sens et l’objectif du texte ; on prend les phrases dans leur ensemble, et non mot-à-mot, ce qui donnerait toujours une traduction « automatique » lourde, gauche.
En termes d’intention, il faut garder à l’esprit le contexte général du texte.
Si on est sur une page de type tuto, Bien démarrer, etc. on est sur un contenu d’accompagnement, pas-à-pas. Nos priorités sont la simplicité, la clarté, l’absence de toute zone d’ombre et ambiguïté, et de nous assurer qu’à tout moment, nos lecteurs ont déjà toutes les infos dont ils ont besoin pour accomplir leur manip’, mais rien de plus, pas de superflu. Parfois, une petite approximation (que ce soit dans l’absolu ou vis-à-vis du texte original) sera plus utile qu’une exactitude rigoureuse.
À l’inverse, une page de référence de l’API est là pour une consultation plus experte, plus détaillée : elle doit contenir 100% de l’info associée, ne rien laisser de côté, et être absolument exacte.
Un cas particulier de cette notion d'intention, ce sont les titres et sous-titres. Dans la mesure ou ils sont très court et parfois très idiomatiques, ne vous forcez pas à les traduire au plus proche. Il est plus efficace de comprendre l'intention des titres et de proposer des titres radicalement différents dans leur forme mais qui vont porter l'intention original.
Nombre de titres sont en “Title Case”, avec la plupart des initiales en majuscules. En français, ça n'a pas lieu d'être, et l'équipe React est pour suivre les normes localisées. On utilisera donc une capitalisation classique, avec seule la première initiale en majuscules
## Convertir une fonction en classe {/* converting-a-function-to-a-class */}
Vous remarquerez par ailleurs, comme ci-dessus, que chaque titre de pages utilise un ID explicite.
Ne traduisez jamais l'ID. Il est utilisé par des liens entrants partout dans le reste du site, et doit être préservé. Par ailleurs, un avantage de cette approche est qu'elle permet de conserver la même URL ciblée (avec une ancre) d'une langue à l'autre : il suffit de changer le sous-domaine de langue.
On ne traduit pas toute l'UI de navigation tout de suite, mais pensez tout de même, si le titre de la page que vous traduisez figure dans une sidebar, à synchroniser le titre de l'entrée de navigation dans le fichier src/sidebar*.json
correspondant, par cohérence.
Règles d’or :
- On ne traduit pas les identifiants (variables, fonctions, etc.)
- On traduit les littéraux chaînes de caractère et les textes littéraux dans JSX
- On peut notamment traduire les prénoms, s'ils sont clairement de culture anglaise, vers un prénom d’initiale équivalente mais plus répandu en français (ex. “Taylor” qui devient « Thierry »)
- On traduit les commentaires
- Dans les traductions, on n’utilise pas le point de suspension (
…
), qui ressemble trop, en lecture rapide et en police à chasse fixe, au soulignement (underscore), mais trois points distinct (...
).
Exemples :
function ExpenseForm() {
// Acceptable si ça n’affecte pas d’autres composants :
SuperCalculator.initializeIfNotReady();
// Suite du rendu...
}
- Traduction des commentaires
- Trois points au lieu des points de suspension
function Form({ showMessage }) {
let message = null;
if (showMessage) {
message = <p>Je viens d’être ajouté ici !</p>;
}
return (
<dialog>
{message}
<input />
</dialog>
);
}
- Traduction des textes littéraux au sein de JSX
let inputNode = dialogNode.firstChild;
let pNode = document.createElement('p');
pNode.textContent = 'Je viens d’être ajouté ici !';
dialogNode.insertBefore(pNode, inputNode);
- Traduction des littéraux chaîne de caractère
Si vous avez un un formatage actif, typiquement Prettier, prenez bien garde de ne pas le laisser reformater aveuglément le Markdown, et surtout le code source des blocs d'exemple.
La doc React emploie le style par défaut de Prettier ; si vous avez des réglages distincts par ailleurs, assurez-vous pour votre dossier de travail sur cette traduction d'utiliser les défauts pour JavaScript, à savoir :
- Points-virgules
- Indentation constituée de 2 espaces
- Pas de parenthèses autour de l’argument unique d'une fonction fléchée
- Guillemets simples pour les chaînes, sauf en JSX (doubles)
- Pas de virgules terminales (trailing commas)
- Chevrons fermants JSX sur leur ligne propre
- etc.
Faites aussi attention au retour forcé à la ligne automatique (possible avec des extensions type Rewrap), qui pourrit bien les diffs ensuite…
Nombre de pages comportent des blocs d'exemples avec onglets et éditeurs interactifs. De même, beaucoup de pages ont le même type de blocs pour les "défis" (challenges) en fin de contenu.
Les onglets sont au sein d'une zone de défilement horizontale conditionnelle. Lorsque celle-ci en vient à proposer un défilement, c'est assez disgracieux.
Dans la mesure du possible, essayez de traduire les titres originaux de façon assez concise pour éviter le défilement, surtout s'il n'était pas présent à l'origine. Parfois, les titres originaux sont inutilement qualifiés (par exemple "Focus a field on mount" qui pourrait tout aussi bien être "Focus on mount") et la VF peut simplifier la qualification pour rester concise ("Focus au montage") et éviter le défilement.
En revanche, si le défilement est incontournable (trop d'onglets, etc.) ne raccourcissez pas inutilement les traductions.
Les docs font souvent des liens vers des docs de référence au sujet du langage JavaScript, du DOM, etc. Vérifiez à chaque fois si le source propose une VF quali, et si c'est le cas, adaptez le lien. En revanche, ne changez jamais de source, quitte à laisser une cible anglophone.
Les VF du MDN sont toujours quali, profitez-en.
Les adverbes, comme leur nom l’indique, qualifient le verbe. Ce sont par exemple « vraiment », « rapidement », « vite », etc. Une locution adverbiale est une locution (un groupe cohérent de mots) jouant le rôle d’un adverbe (ex. « plus vite »).
Les compléments circonstanciels sont de lieu (ex. « en haut de la page ») ou de temps (ex. « plus tard »).
En anglais, on les trouve souvent en fin de phrase ou de subordonnée, mais en français, les rapprocher du verbe (juste après, en général) sonnera plus naturel.
We can wrap the existing imperative APIs and create declarative APIs expressing our intent more closely.
️️⬇️
🔴️ On peut enrober des APIs impératives existantes et créer des APIs déclaratives qui expriment notre intention plus lisiblement.
✅ On peut enrober des APIs impératives existantes et créer des APIs déclaratives qui expriment plus lisiblement notre intention.
Pour résumer : non. On ne va pas ressortir la loi Toubon. Après tout, vous ne dites ni « machouillon » (chewing-gum) ni « cédérom » (vous avez deviné…).
Pour recourir à une VF, il faut que la traduction soit bien établie et n’alourdisse pas trop le texte.
En ce qui concerne JS en général, le MDN en français est souvent une bonne source, même si @tdd estime que certains choix ne sont pas idéaux (cf. glossaire, qui le cas échéant aura priorité).
Pour React plus spécifiquement, on évitera notamment « crochet » (hook) et « rendre » (render). Le glossaire, là encore, a de quoi vous aider.
Cas particuliers : s’ils apparaissent de nombreuses fois dans un texte, on se contentera d’une mention initiale avec sa VO de « environnement d’exécution » (runtime), « écouteur » (listener)… Pour ensuite utiliser la VO, sans italiques. Ça donnerait ceci :
[…] plutôt en tant qu’environnement d’exécution. (Dans la suite de cet article, pour des raisons de concision, nous emploierons le terme générique anglais runtime, NdT)
VF acceptables même à répétition : « fermeture lexicale » (closure), « fonction de rappel » (callback), « abonnement » (subscription), « moteur de rendu » (renderer). On aura tendance à les expliciter tout de même à la première utilisation dans la page, comme ceci :
Le Hook a l’avantage de pouvoir exploiter la fermeture lexicale (closure, NdT) pour récupérer ses données.
Pour en savoir plus, consultez notre glossaire
Il peut arriver qu’un choix de traduction appelle une explication pour les lecteurs. Parmi les cas courants, on trouve :
- Expliquer une tournure issue d’un jeu de mots dans la langue d’origine, qui s’avère intraduisible
- Expliquer une référence culturelle
- Mentionner brièvement la VO d’une traduction, établie ou non, qui semble le mériter (cf. section précédente)
- Expliquer un choix de maintien du terme original, en précisant sa traduction française pas forcément très établie, ou trop verbeuse (ibid.)
Dans ces cas-là, on ajoute dans le corps du texte, juste après le contenu visé, une note du traducteur, qui respecte les formes suivantes :
- En italiques (ou romane si au sein d’italiques)
- Entre parenthèses
- Le contenu parenthésé se termine par une virgule, une espace et « NdT »
On considèrera que React est masculin. Oui, c’est une bibliothèque, mais pour beaucoup c’est un framework, un projet ou simplement un outil, et dans la pratique, l’immense majorité des textes FR sur React le désignent au masculin. Donc « il », accords au masculin, etc.
En anglais, les compléments circonstanciels de temps référençant le futur sont écrits au présent :
When you get there, call me
Once you’re done, run the script
En français, on prendra soin de respecter la concordance des temps et donc d’employer le futur approprié (antérieur en général) :
Quand tu seras arrivée, appelle-moi
(Notez qu’ici le plus informel « appelle-moi quand tu arrives », qui utilise le présent, marche aussi)
Une fois que vous aurez fini, lancez le script
Ce n'est pas une erreur, mais une question de fluidité, de concision, d'élégance.
On évitera systématiquement le recours à l'auxiliaire aller au futur suivi d'un infinitif, pour lui préférer un futur simple du verbe :
🔴️ Quand l'utilisateur va cliquer sur le bouton
🔴️ React va refaire le rendu
✅ Quand l'utilisateur cliquera sur le bouton
✅ React refera le rendu
Les articles et docs techniques respectueux de leur lectorat emploient volontiers l’auxiliaire might, qui indique une possibilité incertaine (may étant déjà plus probable). La traduction française évitera généralement le conditionnel pour utiliser, suivant le cas, un présent ou un futur, couplé à « peut-être » :
You might wonder why
setState()
is asynchronous.
️️⬇️
Vous vous demandez peut-être pourquoi
setState()
est asynchrone.
Ou encore :
Once you’re done, You might want to clean the cache.
️️⬇️
Quand vous aurez fini, vous voudrez peut-être vider le cache.
Contrairement à la plupart des usages avec « que », « après que » n’est pas suivi du subjectif mais de l’indicatif (ou du futur antérieur, selon le temps en vigueur), l’action de référence étant déjà passée, et ne relevant donc plus de la supposition.
Dans le même esprit, les verbes représentant une assurance, une garantie, une certitude, sont suivis s'ils utilisent « que » de l'indicatif. Ça concerne notamment : garantir, attester, assurer, certifier, vérifier…
🔴️ React refera le rendu après qu’il ait appliqué les lots de mise à jour d’état
🔴️ Après que vous ayez sauvé le fichier, Gastby met la page à jour
✅ React refera le rendu après qu’il aura appliqué les lots de mise à jour d’état
✅ Après que vous avez sauvé le fichier, Gastby met la page à jour
On accorde le verbe en genre et en nombre avec le complément :
🔴️ La plupart des gens pense que Facebook est utile
🔴️ La majorité du séjour sera passée à visiter les temples
✅ La plupart des personnes interrogées ne savaient pas
✅ L'essentiel de la journée était consacrée aux échanges
On utilise énormément ces verbes dans la traduction technique (appel de fonction, etc.), aussi il est judicieux de ne pas se planter sur les P et les L.
Il y a toujours deux P. Le double L, en revanche, se cantonne aux personnes du singulier et à la troisième personne du pluriel pour les temps présents et le futur simple (au présent du subjonctif, double L partout en revanche).
Pour appeler ou n’importe quoi d’autre, Le Conjugueur reste la référence incontournable.
Le gérondif, ce sont les formes verbales anglaises en -ing : being, starting, etc.
Elles indiquent souvent la notion d’une action « en train de se passer », mais en pratique, une traduction naturelle n’insistera pas souvent là-dessus et utilisera plutôt l’indicatif simple.
L’anglais a une forme particulière : un article possessif suivi d’un verbe gérondif. Exemples :
They think that React’s being faster is why people use it
All you cared about was my wiring the money to your account every week!
En français, ça devient des subordonnées, souvent à la voix active, et souvent en plaçant la subordonnée sur la fin pour plus de clarté :
Ils pensent que si les gens utilisent React, c’est parce qu’il est plus rapide
Tout ce qui t’importait, c’était que je verse l’argent sur ton compte chaque semaine !
On accorde si le complément d’objet, ou un pronom le désignant (ex. « que ») est situé avant l’auxiliaire.
- « React a créé les éléments »
- « Les éléments créés par React »
- « Les éléments que React a créés »
Au sujet de « créer », justement…
Il crée, donc le truc est créé, la chose est créée, les bidules sont créés, les choses sont créées.
Encore une fois, Le Conjugueur est votre ami…
Attention à ne pas confondre vos infinitifs (créer), impératifs (créez) et participes. Suivant le contexte de la VO, un même verbe peut être en fait à l’infinitif ou à l’impératif, soyez attentifs !
Ce ne sont pas « actuel(lement) » et « courant / couramment », mais respectivement « vraiment / véritablement / en réalité / en fait » et « actuel(lement) ».
Ce n’est pas « comprendre », ni au sens intellectuel (« j’ai compris ») ni au sens compositif (« ce kit de démarrage comprend X objets »), mais ça a trait au second.
L’anglais inverse le sujet par rapport au français : Three elements comprise the native platform” est donc traduit par, au choix :
La plateforme native est constituée de trois éléments (forme à favoriser)
La plateforme native comprend trois éléments
La plateforme native consiste en trois éléments
Ce n’est pas « consistant », qui en français désigne plutôt une notion de taille, ou parfois celle de persévérance. C’est « cohérent » / « cohérence ».
Ne signifie pas du tout « compréhensif » (qui serait “understanding”), mais « complet », « exhaustif » (et oui, on a aussi “exhaustive” en anglais, qui dit la même chose, contrairement à “exhausting”, qui signifie « épuisant »).
Ne signifie pas « éventuel(lement) » mais « final(ement) ».
En anglais, while est utilisé dans deux sens distincts, attention :
While it’s recompiling, grab a cup of coffee
C’est là un mésusage répandu, ou while désigne une concommittance. Le bon terme serait whilst, mais l’anglais, c’est comme le français : les rédacteurs tech sont rarement les meilleurs dans la langue…
On traduirait donc par « Pendant que ça recompile, prenez donc un café » (notez l’indicatif au lieu du gérondif)
While this sounds appealing, there is actually a flaw to it.
Ici, on l’emploie en opposition, là où on pourrait dire although. Il existe pas mal de façons de le traduire suivant le contexte et les traductions environnantes (pour éviter que le texte soit trop répétitif), un peu comme pour however. Quelques possibilités, avec des petites variations de ton :
Même si ça semble séduisant, il y a en réalité une faille.
Ça semble séduisant, mais en réalité une faille s’y cache.
Quand bien même c’est séduisant, une faille nous guette.
Au sein de l’anglais, ou entre l’anglais et le mot français pourtant orthographiquement très proche (d’où le risque).
anglais | français |
---|---|
Loose vs. Lose | Deux O = laxiste, relâché, décontracté, approximatif. Un seul O = perdre. |
Address | Un seul D ! |
Authenticate | On ajoute un « fi » : authentifier. |
Develop(er) | Deux P (moyen mnémotechnique : le nombre de consonnes se… développe. Mouais). |
Environment | Deux N, et le E de jointure : environnement. |
License | Le S est un second C en français : licence. |
(Re)commend | Le français utilise des A au lieu de E : (re)commander. |
Subtract | Pas de S en anglais, sub étant déjà sous. Pas un problème en EN->FR, mais dans l’autre sens, je vois trop souvent des substract… |
(Un)controlled | Un circonflexe et un seul L en français ; on évitera aussi de traduire le préfixe ”un” par « in » dans le cas précis des champs React, on préfèrera le préfixe « non-» : (non-)contrôlé. |
@tdd est d’habitude pour les middots, par exemple « traducteur·ice·s chevronné·e·s », mais ça risque de pas mal alourdir le texte, notamment dans les parties tutos.
On recommande donc plutôt le recours à un masculin pluriel, moins genré (même si ça reste un peu genré…), et donc du « vous » au lieu du « tu / toi » pour le « you », qui rend plus fluide le recours à un pluriel derrière (ex. « nous espérons que cet article vous a éclairés »).
En revanche, si ça concerne genre 2–3 occurrences dans toute la page, n’hésitez pas à faire du véritable inclusif. La bonne syntaxe n’est pas le tiret, ni les parenthèses, ni le point classique, mais le middle dot Unicode : ·
.
Bon, @tdd (Christophe) est un typonazi, alors méfiez-vous 😅 Et lui aussi d’ailleurs, parce que @JeremiePat a une formation d’imprimeur et ne le laissera pas dire des conneries ! 😂
La typographie anglaise est très distincte de la française, et tout aussi compliquée.
En français, nous avons quelques diacritiques, mais pas trop : les accents aigü, grave, circonflexe, le tréma et la cédille. Les majuscules les portent aussi, ce qui est une tanné pour les utilisateurs de Windows, dont la saisie clavier ne le gère pas nativement (si vous passez en majuscules verrouillées, saisir un é affichera 2, un è donnera 7, un ç donnera 9, un à donnera 0, un ù donnera par exemple %, et ainsi de suite).
Pour celles et ceux sous Windows, le circonflexe et le tréma, étant tapés par succession, marchent quand même. Pour le reste, une astuce consiste à taper la lettre en minuscule puis à demander à votre éditeur de la convertir en majuscule (par exemple dans VS Code, la commande Transformer en majuscule). On peut aussi aller piocher le caractère dans la palette des caractères.
Vous pouvez aussi les récupérer dans la liste un peu plus bas
Sur OSX et Linux, les majuscules verrouillées marchent bien ; la majuscule temporaire (Shift), elle, change le glyphe de la touche, attention !
En français, les signes de ponctuation doubles (le deux-points, le point-virgule, le point d’exclamation et le point d’interrogation) sont précédées d’une espace demi-fine insécable. C’est cool et joli, mais en pratique chiant à taper, même sur un joli clavier Mac français…
(Les traitements de texte le font normalement tous seuls, s’il savent que la langue active est le français.)
Un des intérêts est d’éviter que le signe double soit tout seul en début de ligne en raison du retour automatique de formatage. L’anglais, qui n’insère aucune forme d’espace avant ces ponctuations, n’a pas le souci.
On se contente donc généralement d’une espace insécable de largeur classique, plus facile à chercher ou taper. Sur Mac français notamment, Alt+Espace insère une espace insécable littérale (le
de HTML/XML). Sur Windows, on a le bon vieux Alt+160 (160 est le code décimal du caractère en question) Essayez d’utiliser un littéral plutôt que l’entité HTML, mais si vous galérez, l’entité marche aussi (et au moins, on sera sûrs de votre gestion d’espace en regardant le code source !)
Les guillemets anglais sont “
(ouvrant) et ”
(fermants). Si on cite de l’anglais, on les utilise (et on met en italiques pour renforcer visuellement le changement de langue). Ils sont collés au texte qu’ils encadrent. Exemple : “awesome”
Les guillemets français sont les « chevrons » («
et »
) et sont séparés du texte encadré par des demi-fines insécables (donc des insécables pour nous, la demi-fine étant une tannée à taper). Exemple : « topissime ».
L’apostrophe n’est pas juste le '
du clavier, mais bien le ’
. Christophe a tendance à le taper directement propre dans le source, et malheureusement, sur les nouvelles docs, le traitement Markdown appliqué par le système du site ne transformera pas automatiquement '
en apostrophe propre, donc pensez juste à faire un rechercher-remplacer pertinent avant d'envoyer votre PR.
Pour les littéraux chaîne de caractère dans le code en revanche, s’il doit y en avoir, essayez de mettre le bon glyphe, ne serait-ce que pour ne pas avoir à jouer sur les délimiteurs ou l’échappement du littéral.
En anglais, il n’y a pas toujours de points de suspension. Le code d’imprimerie américain précise qu’on emploie normalement trois points séparés par des demi-fines, avec un point final derrière en cas de fin de phrase (cas majoritaire). Berk.
En français on a le glyphe : …
(entité HTML : …
, pour horizontal ellipsis). Attention toutefois, dans du code, on ne l’utilisera pas car en lecture diagonale on dirait trop un underscore (trait de soulignement) ; on le réservera au corps de texte, à la prose. Il suffit à terminer la phrase et n’est jamais suivi d’un point final.
C'est un des plus jolis pièges de la langue française : mange-t-il ou mange-t’il ? Va-t’en ou va-t-en ?
Il y a un certain nombre de règles, la confusion pouvant surgir entre l’euphonie et l’élision. Cette petite page est mochissime mais bien fichue pour vous expliquer tout ça 😉
La première prend toujours des traits d’union, la seconde jamais, déjà (la version avec traits d’union est totalement vieillie).
Par ailleurs, « tout à fait » ne veut pas dire « d’accord », mais « entièrement », « complètement », à la rigueur « absolument ».
Si le début d’une phrase est dans les parenthèses, sont point final aussi. Dans le cas contraire, le point final est après. Auquel cas on évite de terminer la parenthèse par « etc. » car .).
est moche comme tout (on préfèrera tricher avec « et ainsi de suite » à la place, même si ça n’a pas toujours le même sens que « etc. »).
Exemples :
React retrouvera ses petits (où qu’ils soient).
React retrouvera ses petits. (Et si ce n’est pas le cas, signalez-le sur GitHub.)
On a tendance à utiliser le « tiret du 6 » (notion 100% clavier FR PC, car sur Mac ce n’est pas du tout sur le 6) pour tout et n’importe quoi. En pratique, il est acceptable comme trait d’union, à la rigueur, mais c’est tout.
Le tiret cadratin (entité HTML : —
) est utilisé pour les apartés, un peu comme les parenthèses. Les textes anglais peuvent y recourir, mais ils ont plutôt tendance à choisir la facilité en utilisant un tiret, et en tous les cas l’entourent d’espaces. On remplacera par un cadratin sans entourage :
[A]djusting it dynamically can be useful — for example, to poll for […]
⬇️
[…] l’ajuster dynamiquement peut être utile—par exemple, pour […]
Le tiret semi-cadratin (entité HTML : –
) est spécifiquement utilisé en français pour les intervalles. Par exemple, on n’écrira pas « 3-5 jours » (tirets) ni « 3—5 jours » (cadratin), mais « 3–5 jours » (semi-cadratin).
Attention : dans une police à chasse fixe (monospace), ces trois tirets sont souvent très similaires visuellement. Contrôlez bien le rendu final de votre Markdown.
Notez par ailleurs que le signe moins mathématique (entité HTML −
) n’est ni la même hauteur, ni la même largeur, ni la même épaisseur. Il est conçu pour être aligné sur le signe plus.
Besoin d’un caractère vite fait ? Gardez-moi cette section au chaud !
Nom | Caractère | Entité HTML | Clavier Mac FR | Clavier Win FR |
---|---|---|---|---|
Digramme soudé oe | œ | œ |
Alt+o | Alt+0156 |
É majuscule | É | É |
⇪ puis é | Alt+0201 |
È majuscule | È | È |
⇪ puis è | Alt+0200 |
À majuscule | À | À |
⇪ puis à | Alt+0192 |
Ù majuscule | Ù | Ù |
⇪ puis ù | Alt+0217 |
Ç majuscule | Ç | Ç |
⇪ puis ç | Alt+0199 |
Guillemet ouvrant anglais | “ | “ |
Alt+3 | Alt+0147 |
Guillemet fermant anglais | ” | ” |
Alt+Maj+3 | Alt+0148 |
Guillemet ouvrant français | « | « |
Alt+7 | Alt+174 |
Guillemet fermant français | » | » |
Alt+Maj+7 | Alt+175 |
Espace insécable | |
Alt+Espace | Alt+255 | |
Point de suspension | … | … |
Alt+; | Alt+0133 |
Point milieu | · | · |
Alt+Maj+F* | Alt+0183 |
Tiret cadratin | — | — |
Alt+- | Alt+0151 |
Tiret semi-cadratin | – | – |
Alt+Maj+- | Alt+0150 |
* Attention, dans VSCode sur OSX, Alt+Maj+F dans l’éditeur est associé, par défaut, au reformatage du document.
Pour éviter cela (et récupérer la gestion OSX de base de ce raccourci), ajoutez le réglage suivant à votre keybindings.json
pour neutraliser le raccourci :
{
"key": "shift+alt+f",
"command": "-editor.action.formatDocument",
"when": "editorTextFocus && !editorReadonly"
}
Git, et donc GitHub, essaie de faire des diffs malins pour bien regrouper les portions VO juste au-dessus de leur changement VF, et faciliter ainsi considérablement la revue de Pull Request. Mais pour que ça marche, il est impératif de ne pas flinguer la mise en forme principale du texte !
En particulier, faites bien attention à :
- Ne pas modifier le nombre de sauts de ligne entre deux blocs
- Ne pas introduire ou retirer un saut de ligne au sein d'un bloc
- Ne pas introduire ou retirer des délimiteurs visuels tels que les barres de séparation (ex.
-------
ou******
, à partir de 3 caractères successifs).