--- order: 6 section: features title: Inline-Token description: >- Betten Sie Links, Asset-URLs und unübersetzbare Zeichenfolgen in MDX-Texte ein. Diese Token aktualisieren jedes Gebietsschema, ganz ohne Neuübersetzung. noindex: false canonicalPath: /de/docs/inline-tokens --- MDX-Bodys benötigen oft Werte, die Scribe bereits kennt. Das kann ein Link zu einem anderen Eintrag sein, die öffentliche URL eines Assets, ein Zeichenfolgen-Literal, das niemals übersetzt werden darf, oder ein kurzer dokumentspezifischer String, der mehrfach vorkommt. Wenn Sie diese Werte fest im Code verankern, wird das Dokument anfällig für Fehler. Ein umbenannter Slug oder ein verschobenes Asset macht Links unbemerkt unbrauchbar und erschwert die Übersetzung. Eine URL sollte schließlich nie übersetzt werden. 

Inline-Token lösen genau dieses Problem. Sie definieren ein Token einmalig im englischen Body. Beim Auslesen wird es für das jeweilige Gebietsschema aufgelöst. Die Übersetzung behandelt es dabei als festen, unveränderlichen Platzhalter. 

## Syntax 

Ein Token hat das Format `${{:}}`. Es gibt vier Arten: 

| Token | Wird aufgelöst zu | 
| --- | --- | 
| `${{static:"text"}}` | Dem exakten Literal `text` (ein JSON-String, daher sind Anführungszeichen und Escapes klar definiert). Es wird nie übersetzt und bleibt in jedem Gebietsschema identisch. | 
| `${{relation:::href}}` | Einem **Linkpfad** zum Zieleintrag (siehe [Beziehungsmodi](#relation-modes)). Das Modus-Suffix ist erforderlich. | 
| `${{relation:::slug}}` | Dem **englischen Slug-String** des Ziels. Dies ist ein stabiler Bezeichner für MDX-Komponenten, die selbst Scribe-Inhalte laden. | 
| `${{asset:/web/path.webp}}` | Der öffentlichen Asset-URL (`assets.publicPath` verbunden mit dem Pfad). Weitere Informationen finden Sie unter [Assets](/docs/assets). | 
| `${{var:key}}` | `frontmatter.vars[key]` desselben Dokuments. | 

Slugs dürfen kein `:` enthalten. Das stellt sicher, dass das Parsen von Beziehungen absolut eindeutig ist. Ein einfaches `${{relation::}}` ohne Modus-Suffix führt zu einem Validierungsfehler. 

### Beziehungsmodi 

Jedes Beziehungstoken muss auf `:href` oder `:slug` enden. 

| Modus | Zweck | 
| --- | --- | 
| `:href` | Navigierbarer Link. Das aufgelöste Format hängt vom jeweiligen Consumer ab (siehe unten). | 
| `:slug` | Identität: Gibt immer den englischen Slug-String des Ziels aus. | 

Wie `:href` aufgelöst wird, hängt davon ab, wer das Dokument liest: 

| Consumer | `:href` wird aufgelöst zu | 
| --- | --- | 
| `createScribe()` (App-Laufzeit) | Einem Pfadnamen ohne Gebietsschema, aber mit lokalisiertem Slug (zum Beispiel `/for/vestidos`). Dieser kann direkt an den `Link` Ihres Routers übergeben werden. | 
| Statischer `.md` Export | Dem vollständigen lokalisierten öffentlichen Pfad mit Dateiendung (zum Beispiel `/es/for/vestidos.md`). Dies entspricht dem Layout der Exportdatei. | 

### Escape-Möglichkeit 

`${{` (ein Backslash zwischen dem Dollarzeichen und den geschweiften Klammern) erzeugt das Zeichenfolgen-Literal `${{` und wird von Scribe niemals als Token interpretiert. Setzen Sie dies ein, um die Token-Syntax in Ihren Dokumentationen zu veranschaulichen. Diese Seite macht genau das. 

## Der Frontmatter-Schlüssel `vars` 

`vars` ist ein optionales `Record`. Jeder Eintrag kann dieses Record deklarieren, **ohne** es zum Typschema hinzufügen zu müssen: 

```mdx 
--- 
title: Spring sale 
vars: 
 cta: Shop the sale 
--- 

Ready? ${{var:cta}}. Limited time only. 
``` 

Bei `vars` handelt es sich um einen reservierten Schlüssel. Er wird noch vor der Schema-Validierung herausgefiltert. So wird er selbst von einem strikten Schema niemals abgelehnt. Er gilt nicht als übersetzbares Feld und existiert ausschließlich im englischen Dokument. Übersetzte Dokumente lesen `${{var:key}}` aus der `vars`-Map ihres englischen übergeordneten Elements aus. So gibt es immer nur eine einzige Wahrheitsquelle. 

## Hashing und Übersetzung 

Token werden noch vor dem Hashing extrahiert. Jedes Token wird durch eine inaktive, nummerierte Markierung ersetzt (wie `%%1%%`, `%%2%%` und so weiter, in der Reihenfolge ihres Auftretens). Genau dieser *Platzhalter-Body* wird anschließend gehasht und an den Übersetzer übermittelt. Das hat folgende Konsequenzen: 

- **Eine Änderung des Token-Werts** (des statischen Textes, des Beziehungsziels, des Asset-Pfades oder eines `var`-Wertes) verändert den englischen Hash **nicht**. Eine reine Wertebearbeitung macht ein Gebietsschema also nicht veraltet. 
- **Das Hinzufügen, Entfernen oder Neuanordnen von Token** ändert den Hash **durchaus**. Übersetzungen werden dadurch wie gewünscht neu in die Staging-Phase versetzt. 
- **Ein Body ohne Token** wird Byte für Byte genau wie bisher gehasht. Die Einführung von Token führt also nicht dazu, dass plötzlich zahlreiche Inhalte als veraltet markiert werden. 

Der Übersetzer erhält die Anweisung, dass `%%n%%`-Markierungen absolut unveränderlich sind. Er muss jede Markierung exakt einmal reproduzieren. Sie dürfen niemals übersetzt oder neu nummeriert werden. Eine Verschiebung innerhalb eines Satzes ist nur erlaubt, wenn die Grammatik dies zwingend vorgibt. Sobald eine Übersetzung eingeht, prüft ein Post-Receive-Check, ob jede Markierung wirklich nur ein einziges Mal vorkommt. Bei Abweichungen schlägt die Zeile fehl und der Vorgang wird wiederholt. Gespeicherte übersetzte Bodys behalten diese Markierungen bei und füllen sie erst beim Auslesen. 

## Ersetzung beim Auslesen 

Die Ersetzung betrifft primär den Lesepfad und wird ähnlich wie die Asset-Auflösung gesteuert. `createScribe()` aktiviert sie für die App-Laufzeit, während statische Exporte sie für das `.md`-Layout freischalten. Die CLI, `scribe validate` und das Studio behalten die rohe Token-Syntax bei. So können sie Quell-Bodys inspizieren und neu hashen. 

- **In englischen Dokumenten** werden die Token direkt an Ort und Stelle ersetzt und für das Standard-Gebietsschema aufgelöst. 
- **In übersetzten Dokumenten** werden die `%%n%%`-Markierungen mit der Token-Liste gefüllt, die aus dem **aktuellen** englischen Body extrahiert wurde. Sie werden passend zum Gebietsschema des Dokuments aufgelöst. Ein Beziehungslink verweist dadurch stets auf den aktiven lokalisierten Slug, selbst wenn die Übersetzung an sich bereits älter ist. 

Zwei Randfälle werden zur Laufzeit als leere Zeichenfolge aufgelöst. Diese werden von `scribe validate` entsprechend markiert: eine Beziehung, deren Zieltyp im `:href`-Modus keinen `path` hat, und ein fehlender `var`-Schlüssel. 

## Validierung 

`scribe validate` meldet diese als Probleme auf Eintragsebene: 

- **Fehlerhafte Token-Syntax** (falscher JSON-String, fehlerhafte Stelligkeit, unbekannte Art): Error. 
- **`relation`**: Unbekannte `typeId`, unbekannter `enSlug`, fehlender Modus oder eine `:href`-Beziehung, die auf einen nicht routbaren Typ verweist: Error. 
- **`asset`**: Die Datei fehlt auf der Festplatte: Error. 
- **`var`**: Der Schlüssel ist nicht in der `vars`-Map des Dokuments vorhanden oder `vars` ist kein String-to-String-Record: Error. 

Rohe Token werden vor der MDX-Body-Validierung als inaktiver Text maskiert. So löst ein gültiges Token niemals einen falschen MDX-Parse-Fehler aus. 

## Body-Referenzen und Löschvorgänge 

Das "Used by"-Panel im Studio und der Asset-Browser scannen die Bodys. `${{relation:...}}`-Token erscheinen dabei als Rückverweise (mit der Feldbezeichnung `body`). Gleichzeitig werden `${{asset:...}}`-Token als deklarierte Asset-Referenzen erfasst. Wenn Sie einen Eintrag löschen, der nur aus dem **Body** eines anderen Eintrags referenziert wird, löst dies niemals eine Kaskadierung, Trennung oder Blockierung aus. Weitere Details finden Sie unter [Eintragslöschung](/docs/cli#scribe-delete). Der Löschplan führt solche Referenzen lediglich unter der Warnungs-Sektion "body references" auf. Sie bleiben als hängende Verweise bestehen und führen nach der Löschung zu Validierungsfehlern.