Mehrsprachige UIs: i18n-Pattern ohne vue-i18n oder react-intl

1. Warum ein schweres i18n-Framework für Alpine oft überdimensioniert ist

Bibliotheken wie vue-i18n oder react-intl bringen einen eigenen Build-Schritt, eine eigene Runtime und ein komplettes Konzept für Locale-Erkennung, Formatierung und Nachrichtenkatalog mit, was in einem Vue- oder React-Projekt mit hunderten Komponenten sinnvoll ist. In einer Alpine-Komponente, die typischerweise nur wenige Dutzend Textbausteine besitzt und ohnehin kein eigenes Build-System voraussetzt, steht dieser Aufwand in keinem Verhältnis zum tatsächlichen Bedarf.

Hinzu kommt, dass in einem Magento-Kontext ein Großteil der Übersetzungen bereits serverseitig über die Magento-Übersetzungsdateien und Store-Views ausgeliefert wird. Die clientseitige Alpine-Komponente muss oft nur wenige dynamische Textbausteine übersetzen, die sich zur Laufzeit ändern, etwa eine Statusmeldung oder ein Tooltip, wofür ein simples Objekt-Lookup völlig ausreicht.

2. Grundpattern: Übersetzungsobjekt plus Alpine.store()

Der Kern des Patterns ist ein globaler Alpine.store, der zwei Dinge hält: die aktuell aktive Sprache und ein verschachteltes Objekt mit allen Übersetzungen je Sprachcode. Eine Übersetzungsfunktion t(key) liest den aktuellen Sprachcode aus dem Store und gibt den passenden Text aus dem verschachtelten Objekt zurück, mit einem Fallback auf den Schlüssel selbst, falls eine Übersetzung fehlt, damit ein fehlender Text nie als leere Fläche im UI erscheint.

Weil der Store global registriert ist, kann jede beliebige Alpine-Komponente im Markup über $store.i18n.t('key') auf dieselbe Übersetzungsfunktion zugreifen, ohne dass Daten explizit von Komponente zu Komponente weitergereicht werden müssen. Das entspricht im Kleinen genau dem Prinzip, das vue-i18n mit seiner globalen $t-Funktion verfolgt, nur ohne Plugin-Registrierung und ohne separaten Kompilierungsschritt für die Nachrichten.

document.addEventListener('alpine:init', () => {
  Alpine.store('i18n', {
    locale: document.documentElement.lang || 'de',
    messages: {
      de: {
        addToCart: 'In den Warenkorb',
        itemsInCart: '{count} Artikel im Warenkorb',
      },
      en: {
        addToCart: 'Add to cart',
        itemsInCart: '{count} items in cart',
      },
    },

    t(key, params = {}) {
      const dict = this.messages[this.locale] || this.messages.de;
      let text = dict[key] ?? key;
      for (const [param, value] of Object.entries(params)) {
        text = text.replace(`{${param}}`, value);
      }
      return text;
    },
  });
});

3. Sprachumschaltung zur Laufzeit implementieren

Da locale eine reaktive Store-Eigenschaft ist, genügt ein einfaches x-on:click, das $store.i18n.locale auf einen neuen Sprachcode setzt, damit sich jede Komponente, die über x-text="$store.i18n.t('key')" gebunden ist, automatisch neu rendert. Es ist kein manuelles Neuladen der Seite und kein erneutes Initialisieren der Alpine-Komponenten nötig, weil Alpines Reaktivitätssystem die Änderung direkt propagiert.

In einem Magento-Shop mit mehreren Store-Views bleibt die eigentliche Sprachumschaltung in aller Regel serverseitig gelöst, weil sich mit dem Store-View auch Preise, Steuern und Verfügbarkeit ändern können, was ein rein clientseitiger Ansatz nicht abbildet. Der hier gezeigte Alpine-Store eignet sich daher vor allem für isolierte Widgets, die unabhängig vom Store-View-Wechsel bereits vor dem nächsten Seitenaufruf reagieren sollen, etwa ein Cookie-Banner oder ein Sprachauswahl-Vorschau-Widget.

4. Verschachtelte Keys und Namespaces organisieren

Sobald ein Projekt über eine Handvoll Übersetzungen hinauswächst, lohnt sich eine Gliederung nach Namespaces, etwa cart, checkout oder search, als verschachtelte Objektebene statt eines einzigen flachen Schlüssel-Wert-Objekts. Das verhindert Namenskollisionen zwischen ähnlichen Begriffen in unterschiedlichen Kontexten, etwa ein Wort wie remove, das im Warenkorb und im Wunschzettel unterschiedlich formuliert sein könnte.

Die Übersetzungsfunktion t() lässt sich leicht so erweitern, dass sie einen Punkt-getrennten Pfad wie cart.remove auflöst, indem der Schlüssel an jedem Punkt gesplittet und rekursiv durch das verschachtelte Objekt navigiert wird. Dieser Ansatz bleibt weiterhin ein einfaches Objekt-Lookup ohne externe Abhängigkeit, skaliert aber deutlich besser auf mehrere hundert Textbausteine, bevor ein Wechsel zu einer echten i18n-Bibliothek überhaupt notwendig wird.

5. Pluralformen ohne Bibliothek abbilden

Echte i18n-Bibliotheken lösen Pluralformen über den ICU-MessageFormat-Standard, der für Sprachen mit komplexen Pluralregeln wie Polnisch oder Arabisch mehrere Kategorien wie one, few, many und other unterscheidet. Für ein leichtgewichtiges Alpine-Pattern, das primär Deutsch und Englisch bedient, reicht dagegen meist eine simple Fallunterscheidung zwischen der Singular- und der Pluralform, gesteuert über eine kleine Hilfsfunktion, die anhand der übergebenen Zahl den richtigen Schlüssel wählt.

Wichtig ist, diese Grenze bewusst zu kennen: Sobald eine Zielsprache mit differenzierteren Pluralregeln unterstützt werden soll, etwa Russisch mit drei unterschiedlichen Pluralformen je nach letzter Ziffer, stößt die einfache Singular-Plural-Unterscheidung an ihre Grenze und ein Wechsel auf eine Bibliothek mit vollständiger ICU-Unterstützung wird nötig, statt die Logik von Hand immer weiter zu verzweigen.

// einfache Singular-Plural-Unterscheidung, ausreichend für DE/EN
plural(count, key) {
  const dict = this.messages[this.locale] || this.messages.de;
  const variant = count === 1 ? `${key}.one` : `${key}.other`;
  const text = variant.split('.').reduce((obj, part) => obj?.[part], dict) ?? key;
  return text.replace('{count}', count);
}

// Nutzung im Markup:
// <span x-text="$store.i18n.plural(itemCount, 'cart.items')"></span>

6. Platzhalter und Interpolation in Übersetzungsstrings

Die im Grundpattern gezeigte replace-basierte Interpolation mit geschweiften Klammern wie {count} deckt den überwiegenden Teil der praktischen Fälle ab, in denen ein einzelner dynamischer Wert in einen ansonsten statischen Satz eingesetzt werden muss. Für mehrere Platzhalter im selben String funktioniert dieselbe Schleife über Object.entries problemlos, solange die Platzhalternamen im Übersetzungstext eindeutig sind.

Nicht abgedeckt ist dagegen eine kontextabhängige Grammatik, bei der sich etwa die Wortform eines Platzhalters je nach umgebendem Satzbau ändern müsste, was in flektierenden Sprachen wie Deutsch gelegentlich vorkommt. Für diesen Fall bleibt oft nur, unterschiedliche vollständige Satzvarianten als eigene Übersetzungsschlüssel anzulegen, statt zu versuchen, die Grammatik generisch über Platzhalter abzubilden.

7. Persistenz der Sprachwahl über localStorage und Server-Sync

Damit eine im Alpine-Store getroffene Sprachwahl einen Seitenwechsel übersteht, wird der aktuelle Sprachcode zusätzlich in localStorage gespiegelt und beim init() des Stores von dort wieder eingelesen, bevor auf den Wert aus document.documentElement.lang zurückgefallen wird. So bleibt eine bewusste Nutzerentscheidung, etwa in einem eingebetteten Widget, auch über einen Reload hinweg erhalten.

Für die eigentliche, verbindliche Sprachumschaltung des gesamten Shops bleibt die serverseitige Store-View-Weiche in Magento die maßgebliche Quelle, weil sie zusätzlich Preise, Verfügbarkeit und SEO-relevante hreflang-Verknüpfungen korrekt mitführt, was ein reines localStorage-Flag im Browser nicht leisten kann. Der Alpine-Store sollte deshalb den Wert aus document.documentElement.lang als primäre Quelle behandeln und localStorage nur für isolierte Widgets als sekundäre Ergänzung nutzen.

8. Grenzen des leichtgewichtigen Ansatzes gegenüber echten i18n-Bibliotheken

Ein einfaches Übersetzungsobjekt mit Alpine.store deckt weder Datumsformatierung nach Locale-Konventionen noch Zahlen- und Währungsformatierung ab, wofür in der Praxis ohnehin die native Intl-API des Browsers verwendet werden sollte, unabhängig von jedem i18n-Pattern. Auch die automatische Ableitung der Textrichtung für RTL-Sprachen wie Arabisch oder Hebräisch übernimmt keine der beiden gezeigten Funktionen, dafür ist eine eigene dir-Attribut-Logik nötig.

Ebenfalls fehlt dem leichten Ansatz jede Form von Extraktions-Tooling, wie es echte i18n-Bibliotheken mitbringen, um automatisch fehlende Übersetzungsschlüssel im Code aufzuspüren oder Übersetzungsdateien für externe Übersetzungsdienstleister zu exportieren. In einem Projekt mit wenigen Dutzend Schlüsseln lässt sich das noch manuell pflegen, bei mehreren hundert Schlüsseln über viele Komponenten hinweg wird dieses fehlende Tooling schnell zum eigentlichen Engpass.

9. Wann sich der Umstieg auf eine echte i18n-Bibliothek lohnt

Ein klares Signal für den Umstieg ist, wenn die Anzahl der Übersetzungsschlüssel über eine mittlere zwei- bis niedrige dreistellige Zahl hinauswächst, mehr als zwei bis drei Sprachen mit komplexen Pluralregeln unterstützt werden müssen, oder ein Übersetzungsteam ohne Entwicklerkenntnisse eigenständig an den Texten arbeiten soll. In all diesen Fällen wiegt der Mehraufwand einer echten Bibliothek den Verlust an Einfachheit auf.

Solange ein Alpine-Widget dagegen isoliert bleibt, wenige Dutzend Textbausteine besitzt und primär Sprachen mit einfachen Pluralregeln wie Deutsch und Englisch bedient, bleibt das hier gezeigte Store-Pattern die pragmatischere Wahl, weil es ohne zusätzlichen Build-Schritt auskommt und sich nahtlos in eine bestehende Hyvä-Codebasis einfügt, ohne eine neue Abhängigkeit ins Projekt zu bringen.

10. Zusammenfassung

11. FAQ: Leichtgewichtiges i18n mit Alpine: Das Wichtigste auf einen Blick