Kompetenzen Portfolio Referenzen Lebenslauf Blog Termin buchen

React + TYPO3 = Übersetzungen

Gepostet von: Felix Dziekan in: Blog am 

Die meisten meiner Projekte würden davon profitieren, wenn ich sie in mehrere Sprachen übersetzen würde. Um das ordentlich zu machen, muss ich jeden Text, Button, Popup, jedes Formular usw. in meinen Apps übersetzen.

Ein üblicher Weg dafür ist bei REACT das react-i18next-Bundle. Dieses Bundle liefert alle Funktionen und Komponenten, die man für i18n (Internationalisierung) und fürs Übersetzen einer App braucht.

Alles, was du tun musst: initialisieren und für jede benötigte Sprache ein JSON-Objekt oder eine Datei bereitstellen.

 

const resources = {
  en: {
    translation: {
      "Welcome to React": "Welcome to React and react-i18next"
    }
  },
  fr: {
    translation: {
      "Welcome to React": "Bienvenue à React et react-i18next"
    }
  }
};

 

So einfach das ist, es hat einen großen Nachteil: Standardmäßig liegen alle Übersetzungen irgendwo in der Codebase! In fast jedem Projekt, in dem ich bisher gearbeitet habe, brauchte es einen Programmierer, um Übersetzungen oder Texte zu ändern oder auch nur Rechtschreibfehler zu korrigieren.

Das ist nicht nur teuer, das ist auch sehr ineffizient. Es wäre deutlich besser, wenn jeder im Team nötige Änderungen „im Vorbeigehen" machen könnte.

Meine Lösung

Meine eigenen Projekte haben alle irgendeine Art Blog, der auf einem TYPO3-CMS läuft. Da Übersetzungen im Grunde nur eine weitere Form von Inhalt sind, ist die naheliegende Lösung, Übersetzungen in genau diesem CMS bereitzustellen und zu pflegen.

Also los!

Vorteile:

TYPO3 statt einer Sprachdatei oder eines JSON-Objekts zu nutzen bringt ein paar Vorteile.

Es ist: 

  • sehr leicht zu pflegen
  • extrem einfach, neue Übersetzungen anzulegen
  • kein zusätzlicher Ort, an dem „Inhalt" liegt
  • kann wirklich jeder machen

Natürlich kannst du dafür jedes Headless-CMS nutzen. Es muss nicht TYPO3 sein!

Wie es funktioniert

So habe ich es gebaut: 

Mein Problem dabei: Die Routen /blogapi und /translations/[sprache] können nicht direkt vom CMS bedient werden, da es nicht einmal auf demselben System läuft wie die App.

Damit das funktioniert, nutze ich einen Proxy-Server, der eingehende Requests an das richtige Backend weiterleitet.

TYPO3-Backend

Inhalt

So sieht es im Backend aus: Es gibt nur eine Seite, auf der alle Übersetzungen liegen! Wenn etwas geändert, ergänzt oder korrigiert werden muss, bearbeite ich einfach das Inhaltselement in TYPO3, und fertig. Kein Programmieren, keine Deployments, kein „Testen" — und wenn es sein muss, mache ich das vom Handy aus.

Jedes Mal, wenn ich meiner App eine neue Sprache hinzufüge, muss ich jetzt nur noch:

  • eine neue Site Language in TYPO3 anlegen
  • den Entry Point konfigurieren
  • eine neue Übersetzung des Haupt-Inhaltselements anlegen.

Das kann jetzt jeder TYPO3- oder Content-Admin machen — Entwickler braucht es dafür nicht mehr!

Die Kombination aus der TYPO3-Headless-API-Extension und ein bisschen TypoScript liefert mir außerdem eine recht sauber formatierte Ausgabe.

 

{
  "Signup": "Registrieren",
  "Login": "Anmelden"
}

 

Wenn du es dir selbst ansehen willst, kannst du hier schauen:

React

Auf der React-Seite habe ich ein Bundle namens i18next-http-backend ergänzt, um die Übersetzungen von einer URL zu holen statt aus einer Quelldatei oder einem JSON-Objekt.

So sieht das aus:

 

i18n
  .use(HttpApi)
  .use(initReactI18next)
  .init({
    fallbackLng: "en",
    interpolation: {
      escapeValue: false,
    },
    backend: {
      loadPath: (lng, ns) => {
        const baseUrl = "https://bewerbungshelferlein.de/translations/";
        switch (lng) {
          case "en":
            return baseUrl;
          case "de":
            return baseUrl+`de`;
        }
      },
      requestOptions: {
        cache: "no-store",
      },
    },
  });

 

Um eine komplett neue Sprache hinzuzufügen, muss ich den React-Code trotzdem noch anpassen. 

Fazit

Ich finde, das ist eine sehr mächtige Lösung, die deinem Dev-Team einiges (viel?) an Arbeit abnimmt und Textänderungen schneller macht. Die App, die ich für dieses Beispiel genutzt habe, geht hoffentlich bald live, und dann kannst du das in Aktion sehen.

Sie brauchen einen Senior-Entwickler, der liefert?

Über 20 Jahre. Produktionssysteme. Echte Deadlines. Ob Architekt, Entwickler oder DevOps-Engineer — ich habe alle drei Rollen übernommen, oft im selben Projekt. Sparen wir uns den Agentur-Overhead und sprechen direkt.