Intlayer

--- createdAt: 2025-11-24 updatedAt: 2025-11-24 title: Compiler vs. deklarative i18n description: Untersuchung der architektonischen Kompromisse zwischen "magischer" compilerbasierter Internationalisierung und explizitem deklarativem Content-Management. keywords: - Intlayer - Internationalisierung - Blog - Next.js - JavaScript - React - i18n - Compiler - Deklarativ slugs: - blog - compiler-vs-declarative-i18n --- # Pro und Contra compilerbasierte i18n Wenn Sie seit mehr als einem Jahrzehnt Webanwendungen entwickeln, wissen Sie, dass Internationalisierung (i18n) schon immer ein Reibungspunkt war. Es ist oft die Aufgabe, die niemand machen möchte – das Extrahieren von Strings, das Verwalten von JSON-Dateien und das Sorgen um Pluralisierungsregeln. Kürzlich ist eine neue Welle von **"compilerbasierten" i18n-Tools** aufgetaucht, die versprechen, diesen Schmerz verschwinden zu lassen. Das Versprechen ist verlockend: **Schreiben Sie einfach den Text in Ihre Komponenten, und lassen Sie das Build-Tool den Rest erledigen.** Keine Schlüssel, keine Importe, einfach Magie. Aber wie bei allen Abstraktionen in der Softwareentwicklung hat Magie ihren Preis. In diesem Blogbeitrag werden wir den Wandel von deklarativen Bibliotheken hin zu compilerbasierten Ansätzen untersuchen, die versteckten architektonischen Schulden, die sie mit sich bringen, und warum der „langweilige" Weg für professionelle Anwendungen vielleicht immer noch der beste ist. ## Inhaltsverzeichnis <TOC/> ## Eine kurze Geschichte der Internationalisierung Um zu verstehen, wo wir stehen, müssen wir zurückblicken, wo wir angefangen haben. Um 2011–2012 sah die JavaScript-Landschaft ganz anders aus. Bundler, wie wir sie heute kennen (Webpack, Vite), existierten entweder noch nicht oder steckten noch in den Kinderschuhen. Wir klebten Skripte direkt im Browser zusammen. In dieser Zeit entstanden Bibliotheken wie **i18next**. Sie lösten das Problem auf die damals einzig mögliche Weise: **Laufzeit-Wörterbücher**. Man lud ein riesiges JSON-Objekt in den Speicher, und eine Funktion suchte die Schlüssel zur Laufzeit nach. Es war zuverlässig, explizit und funktionierte überall. Schneller Vorlauf bis heute. Wir haben leistungsstarke Compiler (SWC, Rust-basierte Bundler), die Abstract Syntax Trees (AST) in Millisekunden parsen können. Diese Leistung brachte eine neue Idee hervor: _Warum verwalten wir Schlüssel manuell? Warum kann der Compiler nicht einfach den Text "Hello World" sehen und für uns austauschen?_ So wurde die compilerbasierte i18n geboren. > **Beispiel für compiler-basierte i18n:** > > - Paraglide (Tree-shaken-Module, die jede Nachricht in eine kleine ESM-Funktion kompilieren, sodass Bundler ungenutzte Sprachen und Schlüssel automatisch entfernen können. Du importierst Nachrichten als Funktionen, anstatt String-Schlüssel nachzuschlagen.) > - LinguiJS (Macro-zu-Funktion-Compiler, der Nachrichten-Makros wie `<Trans>` zur Build-Zeit in einfache JS-Funktionsaufrufe umschreibt. Du erhältst ICU/MessageFormat-Syntax mit einem sehr kleinen Laufzeit-Footprint.) > - Lingo.dev (Konzentriert sich auf die Automatisierung der Lokalisierungspipeline, indem übersetzte Inhalte direkt während des Builds deiner React-Anwendung injiziert werden. Es kann Übersetzungen mithilfe von KI automatisch generieren und sich direkt in CI/CD integrieren.) > - Wuchale (Svelte-first Preprocessor, der Inline-Text in .svelte-Dateien extrahiert und in Wrapper-freie Übersetzungsfunktionen kompiliert. Er vermeidet String-Schlüssel und trennt die Logik der Inhaltsextraktion vollständig vom Hauptanwendungs-Laufzeitumfeld.) > - Intlayer (Compiler / Extract CLI, der deine Komponenten parst, typisierte Wörterbücher generiert und optional den Code umschreiben kann, um expliziten Intlayer-Inhalt zu verwenden. Das Ziel ist es, den Compiler für Geschwindigkeit zu nutzen und gleichzeitig einen deklarativen, framework-agnostischen Kern beizubehalten.) > **Beispiel für deklarative i18n:** > > - i18next / react-i18next / next-i18next (Der ausgereifte Industriestandard, der zur Laufzeit JSON-Wörterbücher und ein umfangreiches Plugin-Ökosystem verwendet) > - react-intl (Teil der FormatJS-Bibliothek, die sich auf die standardisierte ICU-Nachrichtensyntax und strikte Datenformatierung konzentriert) > - next-intl (Speziell für Next.js optimiert mit Integration für den App Router und React Server Components) > - vue-i18n / @nuxt/i18n (Die Standardlösung im Vue-Ökosystem, die Übersetzungsblöcke auf Komponentenebene und eine enge Reaktivitätsintegration bietet) > - svelte-i18n (Ein leichter Wrapper um Svelte Stores für reaktive, zur Laufzeit stattfindende Übersetzungen) > - angular-translate (Die veraltete dynamische Übersetzungsbibliothek, die auf Laufzeit-Schlüsselabfragen statt auf Build-Zeit-Zusammenführung setzt) > - angular-i18n (Angulards native Ahead-of-Time-Methode, die XLIFF-Dateien direkt während des Builds in Templates zusammenführt) > - Tolgee (Kombiniert deklarativen Code mit einem In-Context-SDK für „Click-to-Translate“-Bearbeitung direkt in der UI) > - Intlayer (Komponentenbasierter Ansatz, der Content-Declaration-Dateien verwendet und so natives Tree-Shaking sowie TypeScript-Validierung ermöglicht) ## Der Intlayer Compiler Obwohl **Intlayer** eine Lösung ist, die grundsätzlich einen **deklarativen Ansatz** für Ihre Inhalte fördert, beinhaltet sie einen Compiler, der die Entwicklung beschleunigen oder schnelles Prototyping erleichtern soll. Der Intlayer Compiler durchläuft den AST (Abstract Syntax Tree) Ihrer React-, Vue- oder Svelte-Komponenten sowie anderer JavaScript/TypeScript-Dateien. Seine Aufgabe ist es, hartkodierte Strings zu erkennen und in dedizierte `.content`-Deklarationen zu extrahieren. > Für weitere Details siehe die Dokumentation: [Intlayer Compiler Docs](https://github.com/aymericzip/intlayer/blob/main/docs/docs/de/compiler.md) ## Der Reiz des Compilers (Der "Magische" Ansatz) Es gibt einen Grund, warum dieser neue Ansatz im Trend liegt. Für einen Entwickler fühlt sich die Erfahrung unglaublich an. ### 1. Geschwindigkeit und "Flow" Wenn man im Flow ist, unterbricht das Nachdenken über einen semantischen Variablennamen (`home_hero_title_v2`) den Arbeitsfluss. Mit einem Compiler-Ansatz tippt man einfach `<p>Welcome back</p>` und macht weiter. Die Reibung ist null. ### 2. Die Rettungsmission für Legacy-Code Stellen Sie sich vor, Sie erben eine riesige Codebasis mit 5.000 Komponenten und keinen Übersetzungen. Diese nachträglich mit einem manuellen schlüsselbasierten System auszustatten, ist ein monatelanger Albtraum. Ein compilerbasiertes Tool fungiert als Rettungsstrategie, indem es sofort Tausende von Strings extrahiert, ohne dass Sie eine einzige Datei manuell anfassen müssen. ### 3. Das KI-Zeitalter Dies ist ein moderner Vorteil, den wir nicht übersehen sollten. KI-Coding-Assistenten (wie Copilot oder ChatGPT) erzeugen natürlich standardmäßiges JSX/HTML. Sie kennen Ihr spezifisches Übersetzungsschlüsselschema nicht. - **Deklarativ:** Sie müssen die Ausgabe der KI umschreiben, um Text durch Schlüssel zu ersetzen. - **Compiler:** Sie kopieren den Code der KI und es funktioniert einfach. ## Der Realitätscheck: Warum „Magie“ gefährlich ist Während die „Magie“ verlockend ist, treten Abstraktionslecks auf. Sich darauf zu verlassen, dass ein Build-Tool die menschliche Absicht versteht, führt zu architektonischer Fragilität. ### Heuristische Fragilität (Das Ratespiel) Der Compiler muss erraten, was Inhalt und was Code ist. Das führt zu Randfällen, bei denen man am Ende gegen das Tool „kämpft“. Betrachten Sie diese Szenarien: - Wird `<span className="active"></span>` extrahiert? (Es ist ein String, aber wahrscheinlich eine Klasse). - Wird `<span status="pending"></span>` extrahiert? (Es ist ein Prop-Wert). - Wird `<span>{"Hello World"}</span>` extrahiert? (Es ist ein JS-Ausdruck). - Wird `<span>Hello {name}. How are you?</span>` extrahiert? (Interpolation ist komplex). - Wird `<span aria-label="Image of cat"></span>` extrahiert? (Barrierefreiheitsattribute müssen übersetzt werden). - Wird `<span data-testid="my-element"></span>` extrahiert? (Test-IDs sollten NICHT übersetzt werden). - Wird `<MyComponent errorMessage="An error occurred" />` extrahiert? - Wird `<p>This is a paragraph{" "}\n containing multiple lines</p>` extrahiert? - Wird das Ergebnis der Funktion `<p>{getStatusMessage()}</p>` extrahiert? - Wird `<div>{isLoading ? "The page is loading" : <MyComponent/>} </div>` extrahiert? - Wird eine Produkt-ID wie `<span>AX-99</span>` extrahiert? Unweigerlich fügen Sie spezifische Kommentare hinzu (wie `// ignore-translation` oder spezifische Props wie `data-compiler-ignore="true"`), um zu verhindern, dass die Anwendung logik bricht. ### Wie geht Intlayer mit dieser Komplexität um? Intlayer verwendet einen gemischten Ansatz, um zu erkennen, ob ein Feld für die Übersetzung extrahiert werden soll, und versucht dabei, Fehlalarme zu minimieren: 1. **AST-Analyse:** Es überprüft den Elementtyp (z. B. Unterscheidung zwischen einem `reactNode`, einem `label` oder einer `title`-Prop). 2. **Mustererkennung:** Es erkennt, ob der String großgeschrieben ist oder Leerzeichen enthält, was darauf hindeutet, dass es sich wahrscheinlich um menschenlesbaren Text und nicht um einen Codebezeichner handelt. ### Die harte Grenze für dynamische Daten Die Compiler-Extraktion basiert auf **statischer Analyse**. Sie muss den Literalstring in Ihrem Code sehen, um eine stabile ID zu generieren. Wenn Ihre API einen Fehlercode-String wie `server_error` zurückgibt, können Sie diesen nicht mit einem Compiler übersetzen, da der Compiler zur Build-Zeit nicht weiß, dass dieser String existiert. Sie sind gezwungen, ein sekundäres "Nur-Laufzeit"-System ausschließlich für dynamische Daten zu erstellen. ### Fehlende Chunk-Aufteilung Bestimmte Compiler teilen Übersetzungen nicht pro Seite auf. Wenn Ihr Compiler eine große JSON-Datei pro Sprache generiert (z. B. `./lang/en.json`, `./lang/fr.json` usw.), laden Sie wahrscheinlich Inhalte aller Seiten für eine einzelne besuchte Seite. Außerdem wird jede Komponente, die Ihre Inhalte verwendet, wahrscheinlich mit weit mehr Inhalt als nötig hydriert, was potenziell zu Performance-Problemen führen kann. Seien Sie auch vorsichtig beim dynamischen Laden Ihrer Übersetzungen. Wenn dies nicht gemacht wird, laden Sie Inhalte für alle Sprachen zusätzlich zur aktuellen. > Um das Problem zu veranschaulichen, betrachten Sie eine Website mit 10 Seiten und 10 Sprachen (alle zu 100 % einzigartig). Sie würden Inhalte für 99 zusätzliche Seiten laden (10 × 10 - 1). ### „Chunk-Explosion“ und Netzwerk-Wasserfälle Um das Chunking-Problem zu lösen, bieten einige Lösungen Chunking pro Komponente oder sogar pro Schlüssel an. Doch das Problem wird nur teilweise gelöst. Das Verkaufsargument für diese Lösungen ist oft: „Ihr Inhalt wird tree-shaken.“ Tatsächlich, wenn Sie Inhalte statisch laden, wird Ihre Lösung ungenutzte Inhalte tree-shaken, aber Sie werden dennoch Inhalte aus allen Sprachen mit Ihrer Anwendung laden. Warum also nicht dynamisch laden? Ja, in diesem Fall laden Sie mehr als den notwendigen Inhalt, aber das ist nicht ohne Kompromisse. Das dynamische Laden von Inhalten isoliert jeden Inhaltsblock in einem eigenen Chunk, der nur geladen wird, wenn die Komponente gerendert wird. Das bedeutet, dass Sie für jeden Textblock eine HTTP-Anfrage stellen. 1.000 Textblöcke auf Ihrer Seite? → 1.000 HTTP-Anfragen an Ihre Server. Und um den Schaden zu begrenzen und die erste Renderzeit Ihrer Anwendung zu optimieren, müssen Sie mehrere Suspense-Grenzen oder Skeleton Loader einfügen. > Hinweis: Selbst mit Next.js und SSR werden Ihre Komponenten nach dem Laden noch hydriert, sodass die HTTP-Anfragen weiterhin ausgeführt werden. Die Lösung? Die Einführung einer Lösung, die es ermöglicht, scoped Content-Deklarationen zu definieren, wie es `i18next`, `next-intl` oder `intlayer` tun. > Hinweis: `i18next` und `next-intl` erfordern, dass Sie Ihre Namespace- / Nachrichtenimporte manuell für jede Seite verwalten, um die Bundle-Größe zu optimieren. Sie sollten einen Bundle-Analyzer wie `rollup-plugin-visualizer` (vite), `@next/bundle-analyzer` (next.js) oder `webpack-bundle-analyzer` (React CRA / Angular / etc.) verwenden, um zu erkennen, ob Sie Ihr Bundle mit ungenutzten Übersetzungen belasten. ### Laufzeit-Performance-Overhead Um Übersetzungen reaktiv zu machen (damit sie sofort aktualisiert werden, wenn Sie die Sprache wechseln), injiziert der Compiler häufig State-Management-Hooks in jede Komponente. - **Die Kosten:** Wenn Sie eine Liste mit 5.000 Elementen rendern, initialisieren Sie 5.000 `useState`- und `useEffect`-Hooks ausschließlich für den Text. React muss alle 5.000 Verbraucher gleichzeitig identifizieren und neu rendern. Dies verursacht eine massive Blockade des "Main Thread" und friert die Benutzeroberfläche während des Wechsels ein. Dies verbraucht Speicher und CPU-Zyklen, die deklarative Bibliotheken (die typischerweise einen einzigen Context-Provider verwenden) einsparen. > Beachten Sie, dass das Problem bei anderen Frameworks als React ähnlich ist. ## Die Falle: Vendor Lock-in Seien Sie vorsichtig bei der Wahl einer i18n-Lösung, die die Extraktion oder Migration von Übersetzungsschlüsseln ermöglicht. Im Fall einer deklarativen Bibliothek enthält Ihr Quellcode explizit Ihre Übersetzungsabsicht: Dies sind Ihre Schlüssel, und Sie kontrollieren sie. Wenn Sie die Bibliothek wechseln möchten, müssen Sie in der Regel nur den Import aktualisieren. Bei einem Compiler-Ansatz besteht Ihr Quellcode möglicherweise nur aus einfachem englischem Text, ohne jegliche Übersetzungslogik: Alles ist in der Build-Tool-Konfiguration verborgen. Wenn dieses Plugin nicht mehr gepflegt wird oder Sie die Lösung wechseln möchten, könnten Sie feststecken. Es gibt keinen einfachen Weg zum „Aussteigen“: Es gibt keine verwendbaren Schlüssel in Ihrem Code, und Sie müssen möglicherweise alle Ihre Übersetzungen für eine neue Bibliothek neu generieren. Einige Lösungen bieten auch Übersetzungsgenerierungsdienste an. Keine Credits mehr? Keine Übersetzungen mehr. Compiler hashen oft den Text (z. B. `"Hello World"` -> `x7f2a`). Ihre Übersetzungsdateien sehen dann so aus: `{ "x7f2a": "Hola Mundo" }`. Die Falle: Wenn Sie die Bibliothek wechseln, sieht die neue Bibliothek `"Hello World"` und sucht nach diesem Schlüssel. Sie wird ihn nicht finden, weil Ihre Übersetzungsdatei voller Hashes (`x7f2a`) ist. ### Plattform-Abhängigkeit Durch die Wahl eines compiler-basierten Ansatzes binden Sie sich an die zugrunde liegende Plattform. Beispielsweise sind bestimmte Compiler nicht für alle Bundler verfügbar (wie Vite, Turbopack oder Metro). Dies kann zukünftige Migrationen erschweren, und Sie müssen möglicherweise mehrere Lösungen einführen, um alle Ihre Anwendungen abzudecken. ## Die andere Seite: Risiken des deklarativen Ansatzes Um fair zu sein, ist der traditionelle deklarative Weg auch nicht perfekt. Er hat seine eigenen "Fallstricke". 1. **Namespace-Hölle:** Sie müssen oft manuell verwalten, welche JSON-Dateien geladen werden (`common.json`, `dashboard.json`, `footer.json`). Wenn Sie eine vergessen, sieht der Benutzer rohe Schlüssel. 2. **Übermäßiges Laden:** Ohne sorgfältige Konfiguration ist es sehr einfach, versehentlich _alle_ Ihre Übersetzungsschlüssel für _alle_ Seiten beim ersten Laden zu laden, was die Bundle-Größe aufbläht. 3. **Synchronisationsabweichung:** Es ist üblich, dass Schlüssel lange nach der Löschung der sie verwendenden Komponente in der JSON-Datei verbleiben. Ihre Übersetzungsdateien wachsen unendlich und sind mit "Zombie-Schlüsseln" gefüllt. ## Der Mittelweg von Intlayer Hier versuchen Werkzeuge wie **Intlayer** zu innovieren. Intlayer versteht, dass Compiler zwar mächtig sind, implizite Magie jedoch gefährlich ist. Intlayer bietet einen gemischten Ansatz, der es Ihnen ermöglicht, von den Vorteilen beider Ansätze zu profitieren: deklaratives Content-Management, das auch mit seinem Compiler kompatibel ist, um Entwicklungszeit zu sparen. Und selbst wenn Sie den Intlayer-Compiler nicht verwenden, bietet Intlayer einen `transform`-Befehl an (auch über die VSCode-Erweiterung zugänglich). Anstatt nur Magie im versteckten Build-Schritt auszuführen, kann er tatsächlich **Ihren Komponenten-Code umschreiben**. Er durchsucht Ihren Text und ersetzt ihn durch explizite Inhaltsdeklarationen in Ihrem Code-Repository. Das gibt Ihnen das Beste aus beiden Welten: 1. **Granularität:** Sie halten Ihre Übersetzungen nah an Ihren Komponenten (verbessert Modularität und Tree-Shaking). 2. **Sicherheit:** Die Übersetzung wird zu explizitem Code, nicht zu versteckter Build-Zeit-Magie. 3. **Keine Abhängigkeit:** Da der Code in eine deklarative Struktur innerhalb Ihres Repos umgewandelt wird, können Sie einfach Tab drücken oder den Copilot Ihres IDEs verwenden, um Ihre Inhaltsdeklarationen zu generieren; Sie verstecken keine Logik in einem Webpack-Plugin. ## Fazit Welche Option sollten Sie also wählen? **Wenn Sie ein MVP erstellen oder schnell vorankommen möchten:** Der compiler-basierte Ansatz ist eine gültige Wahl. Er ermöglicht es Ihnen, unglaublich schnell zu arbeiten. Sie müssen sich nicht um Dateistrukturen oder Schlüssel kümmern. Sie bauen einfach. Die technische Schuld ist ein Problem für das „zukünftige Ich“. **Wenn Sie ein Junior-Entwickler sind oder sich nicht um Optimierung kümmern:** Wenn Sie die geringste manuelle Verwaltung wünschen, ist ein compiler-basierter Ansatz wahrscheinlich am besten. Sie müssen sich nicht selbst um Schlüssel oder Übersetzungsdateien kümmern – schreiben Sie einfach Text, und der Compiler automatisiert den Rest. Dies reduziert den Einrichtungsaufwand und häufige i18n-Fehler, die mit manuellen Schritten verbunden sind. **Wenn Sie ein bestehendes Projekt internationalisieren, das bereits Tausende von Komponenten zur Überarbeitung enthält:** Ein compiler-basierter Ansatz kann hier eine pragmatische Wahl sein. Die anfängliche Extraktionsphase kann Wochen oder Monate manueller Arbeit einsparen. Erwägen Sie jedoch die Verwendung eines Tools wie den `transform`-Befehl von Intlayer, der Zeichenketten extrahieren und in explizite deklarative Inhaltsdeklarationen umwandeln kann. Dies bietet Ihnen die Geschwindigkeit der Automatisierung bei gleichzeitiger Sicherheit und Portabilität eines deklarativen Ansatzes. Sie erhalten das Beste aus beiden Welten: eine schnelle anfängliche Migration ohne langfristige architektonische Schulden. **Wenn Sie eine professionelle, unternehmensgerechte Anwendung entwickeln:** Magie ist im Allgemeinen keine gute Idee. Sie benötigen Kontrolle. - Sie müssen dynamische Daten von Backends verarbeiten. - Sie müssen die Leistung auf Geräten mit geringer Leistung sicherstellen (Vermeidung von Hook-Explosionen). - Sie müssen sicherstellen, dass Sie nicht für immer an ein bestimmtes Build-Tool gebunden sind. Für professionelle Anwendungen bleibt **Deklaratives Content-Management** (wie Intlayer oder etablierte Bibliotheken) der Goldstandard. Es trennt Ihre Anliegen, hält Ihre Architektur sauber und stellt sicher, dass die Mehrsprachigkeitsfähigkeit Ihrer Anwendung nicht von einem „Black-Box“-Compiler abhängt, der Ihre Absichten errät.