Zum Hauptinhalt springen

Anwendungs-Workflow

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Während unsere Installationsanleitung Ihnen den Einstieg erleichtert, gibt dieser Leitfaden einen Überblick über typische Übersetzungs-Workflows im Entwickleralltag.

Es gibt zwei Arten von Übersetzungstools und -diensten:

  • Lokal auf Ihrem Rechner ausgeführte Tools – ähnlich wie Ihre IDE.

  • Cloud-Übersetzungsdienste, die den Upload Ihrer Übersetzungsdateien erfordern. Diese benötigen eine Übersetzungspipeline mit komplexem Workflow.

Dieser Leitfaden zeigt Ihnen, wie Sie mit beiden Toolarten arbeiten können.

Einfacher Anwendungs-Workflow mit lokalem Übersetzungstool​

projectRoot
|-- src
|   |-- App.js
|-- extracted
|   |-- en.json
|-- lang
|   |-- fr.json
|   |-- de.json
|-- package.json
|-- .eslintrc.js

Die extrahierten Übersetzungsdateien befinden sich im extracted-Ordner, da sie eine andere interne Struktur aufweisen (z. B. enthalten sie Zusatzinformationen wie Kommentare). Die während des Übersetzungsprozesses erzeugten Dateien werden im lang-Ordner gespeichert.

Der Workflow​

Der Workflow gestaltet sich wie folgt:

Workflow

  1. Extraktion: Dieser Schritt fasst alle defaultMessages Ihrer Anwendung zusammen mit description in einer einzelnen JSON-Datei zusammen, übersetzungsbereit.

  2. Bearbeiten: Übersetzungen anpassen und nach Abschluss speichern.

  3. Die Änderungen werden umgehend in Ihrem Build sichtbar.

Komplexer Anwendungs-Workflow mit cloudbasiertem Übersetzungsdienst​

Projektstruktur​

Eine minimalistische i18n-fähige Projektstruktur könnte so aussehen:

projectRoot
|-- src
|   |-- App.js
|-- lang
|   |-- en-US.json
|   |-- fr.json
|-- package.json
|-- .eslintrc.js

Hier befinden sich die aggregierten String-Dateien Ihrer Anwendung im lang-Ordner. Die Integration mit einem Drittanbieter-Übersetzungsdienst verarbeitet die en-US.json-Datei und erzeugt entsprechend fr.json oder andere Lokalisierungsdateien.

Pipeline​

Eine typische Übersetzungspipeline sieht folgendermaßen aus:

Übersetzungspipeline

  1. Extraktion: Dieser Schritt fasst alle defaultMessages Ihrer Anwendung zusammen mit description in einer einzelnen JSON-Datei zusammen, übersetzungsbereit.

  2. Nachrichten hochladen: Die JSON-Datei wird an Ihren Übersetzungsdienst gesendet.

  3. Übersetzungen herunterladen: Dieser Schritt fragt regelmäßig Ihren Dienst ab oder integriert sich, um übersetzte Nachrichten in den konfigurierten Lokalisierungen abzurufen.

  4. Commit: Die übersetzten Nachrichten werden in die Codebasis übernommen.

Der Beitrag von FormatJS​

Ziel dieses Projekts ist nicht die Bereitstellung einer Komplettlösung, sondern die Optimierung der Developer Experience durch Tools und Best Practices, um Entwickler für i18n zu sensibilisieren. Dazu gehören:

  1. Deklaration i18n-freundlicher Nachrichten

  2. Linter zur Durchsetzung entsprechender Nachrichten

  3. CLI für Extraktion und Kompilierung

  4. Polyfills für stabile i18n-Laufzeitumgebungen

  5. Bundler-Plugin zur Kompilierung von TypeScript/JavaScript