Jedes Beispiel unten ist ein echtes Repository mit eingechecktem .lingo/config.json und bereits vorhandenen Übersetzungen, damit du die Konfiguration direkt neben dem Ergebnis sehen kannst, das sie erzeugt hat. Die meisten sind lauffähige Apps; ein paar sind einfach dazu da, ein Dateiformat für sich allein zu zeigen. Klone oder forke eines, führe lingo link aus, um deine eigene Engine zu verknüpfen, und pushe los.
Wähle zuerst den passenden Ansatz#
Mit der CLI gibt es zwei Wege zur Lokalisierung — und davon hängt ab, welche Beispiele für dich relevant sind.
Übersetze die Dateien, die du bereits hast. Dein Framework verwaltet Übersetzungen in seinem eigenen Format — Rails YAML, Android XML, Laravel PHP, ARB, Markdown — und die CLI übersetzt diese Dateien direkt an Ort und Stelle. An deinem Code ändert sich nichts. So funktionieren neun der elf Beispiele unten.
Ohne Schlüssel arbeiten. Du umschließt Strings direkt dort, wo sie vorkommen, mit l.text(...), lingo extract erstellt daraus für dich einen hash-basierten Katalog, und es gibt keine Übersetzungsschlüssel, die benannt oder gepflegt werden müssen. Das erfordert einen Build-Schritt und ein Laufzeitpaket — und genau das zeigen die beiden Web-App-Beispiele.
Mobile Apps#
| Beispiel | Format | Warum gerade dieses |
|---|---|---|
| iOS | xcode-xcstrings | Ein String Catalog enthält jede Sprache, deshalb ist der Zielpfad derselbe wie der Quellpfad. |
| Android | android | Reines values/ als Quelle, plus Androids eigene Qualifier (values-pt-rBR/) |
| Flutter | flutter | @-Metadaten und ICU-Platzhalter bleiben erhalten, @@locale wird pro Datei umgeschrieben |
Web-Apps#
Die zwei schlüssellosen Beispiele. Beide umschließen Strings mit l.text(...) und erzeugen ihren Katalog mit lingo extract, deshalb benennt die mittlere Spalte das Runtime-Paket statt eines Dateiformats.
| Beispiel | Paket | Warum gerade dieses |
|---|---|---|
| React + Vite | @lingo.dev/react | Schlüssellose Pflege; generierte Deklarationen grenzen l.text() auf extrahierte Strings ein |
| Next.js | @lingo.dev/react-next | Schlüsselloses Authoring plus Sprache-Routing, hreflang und ein Switcher: Pages Router |
hreflang in Produktion
LingoHead erstellt seine hreflang-URLs aus einer baseUrl-Prop, die standardmäßig leer ist — dadurch sind die Tags out of the box relativ. Suchmaschinen erwarten absolute URLs: Übergib den Ursprung deiner Website (<LingoHead baseUrl="https://example.com" />), bevor du dich darauf verlässt.
Inhalte und Spezifikationen#
| Beispiel | Format | Warum gerade dieses |
|---|---|---|
| Markdown-Dokumentation | md, mdx | Standardmäßig Fließtext, mit optionalen Frontmatter-Feldern und MDX-Props |
| Markdoc | markdoc, json | Next.js-Inhalte und UI-Strings in einem Push — drei Einträge, jeweils mit anderen Optionen |
| OpenAPI | yaml-openapi | Nur Zusammenfassungen und Beschreibungen; Pfade, Operation IDs und Enums bleiben unberührt |
Framework-Kataloge#
| Beispiel | Format | Warum gerade dieses |
|---|---|---|
| Rails | yaml-root-key | Die Sprache ist der YAML-Wurzelschlüssel, daher wird auch der Root-Key selbst umgeschrieben |
| Laravel | php, po | Laravel-Kataloge plus eine gettext-Datei; :name-Platzhalter bleiben in beiden erhalten |
| TypeScript-Module | typescript | Kataloge als TypeScript-Module statt als JSON. Nur das Format — keine App verwendet sie |
TypeScript-Kataloge brauchen einen Default-Export
Das typescript-Format liest einen default-Export — export default { … }, mit oder ohne as const. Ein benannter Export erzeugt keinen übersetzbaren Inhalt, und der Durchlauf endet damit, dass der Quelltext unverändert kopiert wird. Wenn ein Push also meldet, dass Dateien lokalisiert wurden, aber praktisch keine Output-Tokens angefallen sind, prüfe zuerst die Exportform.
So verwendest du diese Beispiele#
npm install -g @lingo.dev/cli
lingo login
lingo link # writes your own orgId and engineId into .lingo/config.json
lingo push --waitKeines der Beispiele versioniert orgId oder engineId — so verhinderst du, dass ein Fork über die Engine einer anderen Person pusht. lingo link ergänzt beides lokal.
Wenn du die GitHub App statt der CLI nutzen willst
Die GitHub App liest engineId aus der .lingo/config.json, die in deinem Repository committet ist — die Organisation wird zwar über die App-Installation selbst aufgelöst, aber die Engine muss in der Datei stehen. Nach einem Fork führe lingo link aus und committe die aktualisierte Konfiguration, bevor du die App installierst.
Nicht für jedes Format gibt es ein Beispiel#
Diese elf decken die Frameworks ab, nach denen am häufigsten gefragt wird, aber die CLI übersetzt achtzehn Formate. xliff, srt, Xcode-.strings und .stringsdict, generisches yaml sowie eigenständiges JSON/JSONC funktionieren alle auch ohne ein Repository hier — die vollständige Liste und die jeweils nötige Konfiguration findest du unter Formats.
