--- order: 6 section: features title: Tokens en ligne description: >- Intégrez des liens, des URL d'assets et des chaînes non traduisibles dans du texte MDX à l'aide de tokens qui se mettent à jour pour chaque langue sans nécessiter de nouvelle traduction. noindex: false canonicalPath: /fr/docs/inline-tokens --- Les corps MDX ont souvent besoin d'une valeur que Scribe connaît déjà, par exemple un lien vers une autre entrée, l'URL publique d'un asset, une valeur littérale qui ne doit jamais être traduite, ou une petite chaîne de caractères spécifique au document réutilisée à plusieurs endroits. Le codage en dur de ces éléments rend les corps fragiles (un slug renommé ou un asset déplacé casse silencieusement les liens) et pollue la traduction (une URL ne devrait jamais être « traduite »). Les tokens en ligne résolvent ce problème. Vous rédigez un token une fois dans le corps en anglais, puis il se résout par paramètre régional au moment de la lecture, tandis que la traduction le traite comme un espace réservé opaque et immuable. ## Syntaxe Un token se présente sous la forme `${{:}}`. Il existe quatre types : | Token | Résolution | | --- | --- | | `${{static:"text"}}` | La chaîne de caractères textuelle littérale `text` (une chaîne JSON dont les guillemets et les échappements sont bien définis). Elle n'est jamais traduite et reste identique dans toutes les langues. | | `${{relation:::href}}` | Un **chemin d'accès** à l'entrée cible (voir les [modes de relation](#relation-modes)). Le suffixe du mode est obligatoire. | | `${{relation:::slug}}` | La chaîne **English slug** de la cible, un identifiant stable pour les composants MDX qui chargent eux-mêmes le contenu de Scribe. | | `${{asset:/web/path.webp}}` | L'URL de l'asset public (`assets.publicPath` lié au chemin). Voir les [assets](/docs/assets). | | `${{var:key}}` | `frontmatter.vars[key]` du même document. | Les slugs ne peuvent pas contenir `:`, l'analyse syntaxique des relations est donc sans ambiguïté. Un simple `${{relation::}}` sans suffixe de mode est une erreur de validation. ### Modes de relation Chaque token de relation doit se terminer par `:href` ou `:slug`. | Mode | Objectif | | --- | --- | | `:href` | Lien de navigation. La forme résolue dépend du consommateur (voir ci-dessous). | | `:slug` | Identité, toujours la chaîne du slug anglais de la cible. | La résolution de `:href` varie en fonction de la personne qui lit le document : | Consommateur | Résolution de `:href` | | --- | --- | | `createScribe()` (exécution de l'application) | Chemin d'accès sans indication de lieu avec le slug localisé, par ex. `/for/vestidos`, passez directement au `Link` de votre routeur. | | Exportation statique en `.md` | Chemin public localisé complet avec l'extension de fichier, par exemple `/es/for/vestidos.md`, correspondant à la présentation du fichier d'exportation. | ### Mécanisme d'échappement L'utilisation d'une barre oblique inversée (`${{`) entre le signe dollar et les accolades affiche `${{` littéralement et n'est jamais considérée comme un token. Utilisez cette méthode pour illustrer la syntaxe des tokens dans la documentation, tout comme le fait cette page. ## La clé de frontmatter `vars` La clé `vars` est un élément optionnel de type `Record` que chaque entrée peut déclarer **sans** l'intégrer au schéma de type : ```mdx --- title: Spring sale vars: cta: Shop the sale --- Ready? ${{var:cta}}. Limited time only. ``` La clé `vars` est réservée, elle est extraite avant la validation du schéma (ce qui garantit qu'un schéma strict ne la rejettera pas), elle n'est jamais traitée comme un champ traduisible et n'existe que dans le document original en anglais. Les documents traduits lisent `${{var:key}}` à partir de la carte `vars` du document parent anglais, assurant ainsi une source d'information unique. ## Hachage et traduction Les tokens sont extraits avant le hachage. Chaque token est remplacé par un marqueur inerte numéroté (`%%1%%`, `%%2%%`, …, par ordre d'apparition), et ce *corps d'espace réservé* est haché et envoyé au traducteur. Conséquences : - **La modification de la valeur d'un token** (le texte statique, la cible de relation, le chemin de l'asset ou une valeur de `var`) **ne modifie pas** le hash en anglais, ainsi aucune traduction locale ne devient obsolète pour une simple édition de valeur. - **L'ajout, la suppression ou la réorganisation des tokens** **modifie** le hash, et par conséquent les traductions se mettent à jour comme prévu. - **Un corps de texte ne contenant aucun token** produit un hash identique au niveau des octets, ce qui signifie que l'adoption des tokens ne provoque aucune obsolescence massive. Le traducteur est informé que les marqueurs `%%n%%` sont immuables. Ils doivent être reproduits exactement une fois, ne jamais être traduits ou renumérotés, et ne doivent être déplacés dans une phrase que si la grammaire l'exige. Lors de la réception d'une traduction, une vérification post-réception confirme que chaque marqueur apparaît exactement une fois. En cas de différence, la ligne échoue et elle est retentée. Les corps de texte traduits stockés conservent les marqueurs et les remplissent lors de la lecture. ## Substitution lors de la lecture La substitution est une question liée au chemin de lecture et elle est contrôlée, à l'image de la résolution des assets. La fonction `createScribe()` l'active pour l'exécution de l'application, et les exportations statiques l'activent pour la disposition en `.md`. Le CLI, la fonction `scribe validate` et le studio maintiennent la syntaxe des tokens à l'état brut afin de pouvoir inspecter et recalculer le hachage des corps sources. - **Les documents en anglais** voient leurs tokens substitués sur place et résolus pour le paramètre régional par défaut. - **Les documents traduits** ont leurs marqueurs `%%n%%` remplis grâce à la liste de tokens extraite du corps anglais **actuel** et résolue pour la langue du document, de sorte qu'un lien de relation pointe toujours vers le slug localisé en direct, même si la traduction elle-même est plus ancienne. Deux cas particuliers sont résolus en chaîne vide lors de l'exécution (et sont signalés par `scribe validate`) : une relation dont le type de cible ne comporte pas de `path` en mode `:href`, et une clé `var` manquante. ## Validation `scribe validate` signale ces erreurs comme des problèmes d'entrée de base : - **Syntaxe de token malformée** (chaîne JSON incorrecte, arité erronée, type inconnu) : erreur. - **`relation`** : `typeId` inconnu, `enSlug` inconnu, mode manquant, ou une relation `:href` ciblant un type non routable : erreur. - **`asset`** : le fichier est manquant sur le disque : erreur. - **`var`** : la clé est absente de la carte `vars` du document, ou `vars` n'est pas un enregistrement de chaîne à chaîne : erreur. Les tokens bruts sont convertis en texte inerte avant la validation du corps MDX. Ainsi, un token valide ne produit jamais de fausse erreur d'analyse MDX. ## Références et suppressions de corps Le panneau « Used by » du studio et le navigateur d'assets analysent les corps, les tokens `${{relation:...}}` s'affichent comme des références arrière (étiquette de champ `body`), et les tokens `${{asset:...}}` sont enregistrés comme des références d'assets déclarées. La suppression d'une entrée référencée uniquement depuis le **corps** d'une autre entrée ne provoque jamais d'action en cascade, ne détache pas l'entrée et ne bloque pas l'opération, pour plus d'informations consultez [la suppression des entrées](/docs/cli#scribe-delete). Le plan de suppression liste ces références dans une section « body references » servant d'avertissement uniquement. Celles-ci deviendront des références pendantes et généreront des erreurs de validation à la suite de la suppression.