Alpha
Der Lingo.dev Compiler ist aktuell in der Alpha-Phase. Er ist instabil, nicht für den Produktionseinsatz empfohlen, und APIs können sich zwischen Releases ändern.
Der Lingo.dev Compiler erstellt und verwaltet im Stammverzeichnis Ihres Projekts das Verzeichnis .lingo/, in dem Übersetzungsmetadaten und Cache gespeichert werden. Wenn Sie diese Verzeichnisstruktur verstehen, können Sie Übersetzungen in der Versionsverwaltung besser verwalten, fehlende Übersetzungen leichter debuggen und die Build-Performance optimieren.
Das Verzeichnis .lingo/#
Der Compiler erstellt dieses Verzeichnis beim ersten Build automatisch. Es enthält alle Übersetzungsmetadaten, die in der Build-Pipeline verwendet werden:
.lingo/
metadata.json # Translation cache and content hashes
locale-resolver.server.ts # Optional: custom server-side locale resolver
locale-resolver.client.ts # Optional: custom client-side locale resolvermetadata.json#
Dies ist die wichtigste Datei im Verzeichnis .lingo/. Sie speichert:
- Content-Hashes – Stabile, hashbasierte Kennungen für jede übersetzbare Zeichenfolge
- Zwischengespeicherte Übersetzungen – Generierte Übersetzungen für jedes Sprachpaar
- Quelltext-Snapshots – Der Quelltext zum Zeitpunkt der Übersetzung, um Änderungen zu erkennen
Der Compiler liest diese Datei zu Beginn jedes Builds. Zeichenfolgen mit übereinstimmenden Hashes verwenden zwischengespeicherte Übersetzungen wieder. Zeichenfolgen mit geänderten oder fehlenden Hashes werden an den konfigurierten Übersetzungsanbieter gesendet.
In die Versionsverwaltung committen
Committen Sie .lingo/metadata.json immer in Ihr Repository. Production-Builds im Modus cache-only lesen Übersetzungen ausschließlich aus dieser Datei. Wenn sie nicht committet ist, schlagen Production-Builds fehl.
.gitignore-Hinweise#
Fügen Sie .lingo/ nicht zu .gitignore hinzu. Das Verzeichnis sollte in der Versionsverwaltung erfasst werden. Ein typisches .gitignore für ein Projekt, das den Compiler verwendet:
# Do NOT ignore .lingo/ - it contains translation cache
node_modules/
dist/
.envsourceRoot#
Die Option sourceRoot bestimmt, welches Verzeichnis der Compiler nach übersetzbaren React-Komponenten durchsucht:
{
sourceRoot: "./app", // Next.js App Router
// or
sourceRoot: "src", // Vite + React
}Der Compiler durchsucht rekursiv alle Dateien vom Typ .tsx, .ts, .jsx und .js innerhalb von sourceRoot nach übersetzbarem JSX-Inhalt. Dateien außerhalb dieses Verzeichnisses werden nicht verarbeitet.
| sourceRoot-Wert | Was gescannt wird |
|---|---|
"./app" | Alle Dateien im Verzeichnis app/ (Next.js-Konvention) |
"src" | Alle Dateien im Verzeichnis src/ (Vite-Konvention) |
"." | Alle Dateien im Projektstammverzeichnis (nützlich für Monorepos mit gemeinsam genutzten Paketen) |
Ein breiter gefasstes sourceRoot scannt mehr Dateien und verlängert damit die Build-Zeit. Halten Sie es so eng wie möglich. Wenn nur einige Dateien übersetzt werden müssen, verwenden Sie stattdessen die Option useDirective.
Opt-in-Modus mit „use i18n“#
Standardmäßig übersetzt der Compiler den gesamten JSX-Text in sourceRoot. Um zum Opt-in-Modus zu wechseln, setzen Sie useDirective: true:
{
useDirective: true,
}Im Opt-in-Modus werden nur Dateien verarbeitet, die mit der Direktive 'use i18n' beginnen:
'use i18n';
export function Welcome() {
return <h1>Welcome to our app</h1>;
// This text IS translated
}Dateien ohne diese Direktive werden übersprungen:
export function InternalAdmin() {
return <h1>Admin Dashboard</h1>;
// This text is NOT translated
}Wann Sie den Opt-in-Modus verwenden sollten#
| Szenario | Empfohlener Modus |
|---|---|
| Kleine App, bei der alle Inhalte übersetzt werden sollen | Standard (useDirective: false) |
| Große Codebasis mit nur einigen nutzerseitigen Seiten | Opt-in (useDirective: true) |
| Monorepo mit gemeinsam genutzten internen und externen Komponenten | Opt-in (useDirective: true) |
| Schrittweise Einführung – i18n zu einer bestehenden App hinzufügen | Opt-in (useDirective: true) |
lingoDir#
Die Option lingoDir ändert den Speicherort des Metadatenverzeichnisses:
{
lingoDir: ".lingo", // Default
// or
lingoDir: ".translations", // Custom location
}Das ist nützlich, wenn .lingo/ mit einem bestehenden Verzeichnis in Ihrem Projekt kollidiert.
