Internationalisierung und Lokalisierung für statische Websites

Internationalisierung und Lokalisierung ist mehr als nur das Schreiben Ihrer Inhalte in mehreren Sprachen. Sie benötigen eine Strategie, um zu bestimmen, welche Lokalisierung gesendet werden soll, und einen entsprechenden Code. Sie müssen in der Lage sein, nicht nur verschiedene Sprachen, sondern auch verschiedene Regionen mit derselben Sprache zu unterstützen. Ihre Benutzeroberfläche muss nicht nur auf die Bildschirmgröße reagieren, sondern auch auf verschiedene Sprachen und Schreibmodi. Ihre Inhalte müssen bis hin zur Mikrokopie in Ihrer Benutzeroberfläche und dem Format Ihrer Daten strukturiert sein, um an jede Sprache angepasst werden zu können, die Sie darauf werfen. All dies mit einem statischen Site-Generator wie Eleventy zu tun, kann es noch schwieriger machen, da Sie möglicherweise keine Datenbank, aber dennoch einen Server haben. Es kann zwar alles getan werden, aber es erfordert Planung.

Beim Aufbau von chromeOS.dev wussten wir, dass wir es einem globalen Publikum zur Verfügung stellen mussten. Es wäre entscheidend, sicherzustellen, dass unsere Codebasis mehrere Gebietsschemas (Sprache, Region oder eine Kombination aus beiden) unterstützen kann, ohne dass jedes einzeln codiert werden muss, während die Übersetzung mit so wenig Wissen wie möglich über dieses System erfolgen kann Dies geschieht. Unsere Inhaltsersteller mussten sich auf das Erstellen von Inhalten und unsere Übersetzer auf das Übersetzen von Inhalten konzentrieren können, mit so wenig Arbeit wie möglich, um ihre Arbeit auf die Website zu bringen und bereitzustellen. Diese manchmal widersprüchlichen Anforderungen richtig zu erfüllen, ist das Herzstück dessen, was es braucht, um Codebasen zu internationalisieren und Websites zu lokalisieren.

Internationalisierung (i18n) und Lokalisierung (l10n) sind zwei Seiten derselben Medaille. Bei der Internationalisierung geht es darum, wie in unserem Fall Software so gestaltet wird, dass sie für mehrere Sprachen und Regionen angepasst werden kann, ohne dass technische Änderungen erforderlich sind. Bei der Lokalisierung hingegen geht es darum, die Software tatsächlich für diese Sprachen und Regionen anzupassen. Die Internationalisierung kann über den gesamten Website-Stack hinweg erfolgen; von HTML, CSS und JS bis hin zu Designüberlegungen und Build-Systemen. Die Lokalisierung findet hauptsächlich bei der Inhaltserstellung (sowohl Langformkopie als auch Mikrokopie) und Verwaltung statt.

Hinweis : Für Neugierige sind i18n und l10n Arten von Abkürzungen, die als Numeronyme bekannt sind. A11y, für Barrierefreiheit, ist ein weiteres gebräuchliches Numeronym in der Webentwicklung.

Internationalisierung (i18n)

Bei der Internationalisierung müssen Sie im Allgemeinen drei Punkte berücksichtigen: wie Sie herausfinden, welche Sprache und/oder Region der Benutzer wünscht, wie Sie sicherstellen, dass er Inhalte in seiner bevorzugten Lokalisierung erhält, und wie Sie Ihre Website anpassen, um sich daran anzupassen diese Unterschiede. Während sich die Implementierungsdetails für dynamische Websites (die eine Seite rendern, wenn ein Benutzer sie anfordert) und statische Websites (wo Seiten erstellt werden, bevor sie bereitgestellt werden) ändern können, sollten die Kernkonzepte gleich bleiben.

Bestimmen der Sprache und Region des Benutzers

Das erste, was Sie bei der Internationalisierung berücksichtigen sollten, ist zu bestimmen, wie Benutzer auf lokalisierte Inhalte zugreifen sollen. Diese Entscheidung wird grundlegend für die Einrichtung anderer Systeme, daher ist es wichtig, dies frühzeitig zu entscheiden und sicherzustellen, dass die Kompromisse für Ihre Benutzer gut funktionieren.

Im Allgemeinen gibt es drei allgemeine Möglichkeiten, um zu bestimmen, welche Lokalisierung Benutzern bereitgestellt werden soll:

1. Standort von IP-Adresse;
2. Accept-Language Header oder navigator.languages ​​;
3. Kennung in URL.

Viele Systeme kombinieren am Ende eines, zwei oder alle drei, wenn sie entscheiden, welche Lokalisierung bedient werden soll. Bei der Untersuchung fanden wir jedoch Probleme bei der Verwendung von IP-Adressen und Accept-Language Headern, die wir für bedeutsam genug hielten, um sie für uns außer Betracht zu lassen:

• Die bevorzugte Sprache eines Benutzers korreliert oft nicht mit seinem physischen Standort, den die IP-Adresse bereitstellt. Nur weil sich jemand beispielsweise physisch in Amerika befindet, heißt das nicht, dass er englische Inhalte bevorzugen würde.
• Die Standortanalyse von IP-Adressen ist schwierig, im Allgemeinen unzuverlässig und kann verhindern, dass die Website von Suchmaschinen gecrawlt wird.
• Accept-Language Header werden oft nie explizit festgelegt und liefern nur Informationen über die Sprache, nicht über die Region. Aufgrund seiner Einschränkungen kann dies hilfreich sein, um eine erste Vermutung über die Sprache zu erstellen, ist aber nicht unbedingt zuverlässig.

Aus diesen Gründen haben wir entschieden, dass es besser für uns wäre, nicht zu versuchen, Sprache oder Region abzuleiten, bevor ein Benutzer auf unserer Website landet, sondern stattdessen starke Indikatoren in unseren URLs zu haben. Mit starken Indikatoren können wir auch davon ausgehen, dass sie die Website in der gewünschten Sprache allein über ihre Zugriffs-URL erhalten, bieten eine einfache Möglichkeit, lokalisierte Inhalte direkt ohne Bedenken einer Weiterleitung zu teilen, und bieten uns eine saubere Möglichkeit, sie zuzulassen Benutzer wechseln ihre bevorzugte Sprache.

Es gibt drei gängige Muster für den Einbau von Kennungen in URLs:

1. Stellen Sie verschiedene Domains bereit (normalerweise TLDs oder Subdomains für verschiedene Regionen und Sprachen (z. B. example.com und example.de , en.example.org und de.example.org );
2. Haben Sie lokalisierte Unterverzeichnisse für Inhalte (z. B. example.com/en und example.com/de );
3. Stellen Sie lokalisierte Inhalte basierend auf URL-Parametern bereit (z. B. example.com?loc=en und example.com?loc=de ).

Obwohl häufig verwendet, werden URL-Parameter im Allgemeinen nicht empfohlen, da es für Benutzer schwierig ist, die Lokalisierung zu erkennen (zusammen mit einer Reihe von Analyse- und Verwaltungsproblemen). Wir haben auch entschieden, dass verschiedene Domains keine gute Lösung für uns sind; Unsere Website ist eine Progressive Web App und jede Domain, einschließlich TLDs und Subdomains, wird als ein anderer Ursprung betrachtet, was effektiv eine separate PWA für jede Lokalisierung erfordert.

Wir entschieden uns für die Verwendung von Unterverzeichnissen, was den Vorteil bot, dass wir bei Bedarf nur nach Sprache ( example.com/en ) oder Sprache und Region ( example.com/en-US und example.com/en-GB ) lokalisieren konnten Pflege einer einzelnen PWA. Wir haben auch entschieden, dass jede Lokalisierung unserer Website in einem Unterverzeichnis gespeichert wird, damit eine Sprache nicht über eine andere gestellt wird, und dass alle URLs, mit Ausnahme des Unterverzeichnisses, für alle Lokalisierungen identisch sind, basierend auf der Autorensprache, sodass Benutzer sie leicht ändern können Lokalisierungen, ohne URLs übersetzen zu müssen.

Bereitstellen lokalisierter Inhalte

Nachdem eine Strategie zur Bestimmung der Sprache und Region eines Benutzers festgelegt wurde, müssen Sie ihm zuverlässig die richtigen Inhalte bereitstellen. Dies erfordert mindestens eine Form von gespeicherten Informationen, sei es in einem Cookie, einem lokalen Speicher oder einem Teil der benutzerdefinierten Logik Ihrer App. Die Möglichkeit, die Lokalisierungspräferenzen eines Benutzers beizubehalten, ist ein wichtiger Teil der i18n-Benutzererfahrung; Wenn ein Benutzer festgestellt hat, dass er Inhalte auf Deutsch haben möchte, und er auf englischen Inhalten landet, sollten Sie in der Lage sein, seine bevorzugte Sprache zu identifizieren und ihn entsprechend weiterzuleiten. Dies kann auf dem Server erfolgen, aber die Lösung, die wir für chromeOS.dev gewählt haben, ist Hosting und Server-Setup agnostisch: Wir haben Servicemitarbeiter eingesetzt. Die Reise des Benutzers ist wie folgt:

• Ein Benutzer kommt zum ersten Mal auf unsere Seite. Unser Servicemitarbeiter ist nicht installiert.
• Unabhängig davon, auf welcher Lokalisierung sie landen, legen wir sie als ihre bevorzugte Sprache in IndexedDB fest. Dafür gehen wir davon aus, dass sie dort über irgendein Mittel landen, entweder über soziale Netzwerke, Verweise oder Suchvorgänge, das sie basierend auf anderen Lokalisierungskontexten, die wir nicht haben, geleitet hat. Wenn ein Benutzer ohne eine festgelegte Lokalisierung landet, stellen wir sie auf Englisch ein, da dies die Hauptsprache unserer Website ist. Wir haben auch einen Sprachumschalter in unserer Fußzeile, damit ein Benutzer seine Sprache ändern kann. An dieser Stelle sollte unser Servicemitarbeiter installiert werden.
• Nachdem der Service Worker installiert ist, fangen wir alle URL-Anforderungen für die Seitennavigation ab. Da unsere Lokalisierungen auf Unterverzeichnissen basieren, können wir leicht erkennen, welche Lokalisierung angefordert wird. Nach der Identifizierung prüfen wir, ob sich die angeforderte Seite in einem lokalisierten Unterverzeichnis befindet, prüfen, ob sich das lokalisierte Unterverzeichnis in einer Liste unterstützter Lokalisierungen befindet, und prüfen, ob das lokalisierte Unterverzeichnis mit ihren in IndexedDB gespeicherten Einstellungen übereinstimmt. Wenn es sich nicht in einem lokalisierten Unterverzeichnis befindet oder das lokalisierte Unterverzeichnis ihren Präferenzen entspricht, stellen wir die Seite bereit; Andernfalls führen wir eine 302-Weiterleitung von unserem Servicemitarbeiter für die richtige Lokalisierung durch.

Wir haben unsere Lösung im Workbox-Plugin Service Worker Internationalization Redirect gebündelt. Das Plugin kann zusammen mit seinem Untermodul für Einstellungen kombiniert werden, um die Spracheinstellung eines Benutzers festzulegen und abzurufen und die Umleitung zu verwalten, wenn es mit der Methode registerRoute von Workbox und dem Filtern von Anfragen nach request.mode === 'navigate' kombiniert wird.

Ein vollständiges Minimalbeispiel sieht so aus:

Client-Code

 import { preferences } from 'service-worker-i18n-redirect/preferences'; window.addEventListener('DOMContentLoaded', async () => { const language = await preferences.get('lang'); if (language === undefined) { preferences.set('lang', lang.value); // Language determined from localization user landed on } });

Dienstmitarbeitercode

 import { StaleWhileRevalidate } from 'workbox-strategies'; import { CacheableResponsePlugin } from 'workbox-cacheable-response'; import { i18nHandler } from 'service-worker-i18n-redirect'; import { preferences } from 'service-worker-i18n-redirect/preferences'; import { registerRoute } from 'workbox-routing'; // Create a caching strategy const htmlCachingStrategy = new StaleWhileRevalidate({ cacheName: 'pages-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), ], }); // Array of supported localizations const languages = ['en', 'es', 'fr', 'de', 'ko']; // Use it for navigations registerRoute( ({ request }) => request.mode === 'navigate', i18nHandler(languages, preferences, htmlCachingStrategy), );

Mit der Kombination aus clientseitigem und Service-Worker-Code wird die bevorzugte Lokalisierung der Benutzer automatisch festgelegt, wenn sie die Website zum ersten Mal besuchen, und wenn sie zu einer URL navigieren, die nicht in ihrer bevorzugten Lokalisierung ist, werden sie es tun umgeleitet.

Anpassen der Site-Benutzeroberfläche

Es gibt viel, was in die richtige Anpassung von Benutzeroberflächen einfließt, also wird hier zwar nicht alles behandelt, aber es gibt eine Handvoll subtilerer Dinge, die programmgesteuert verwaltet werden können und sollten.

Blockquote-Zitate

Ein gängiges Designmuster besteht darin, Blockquotes in Anführungszeichen zu setzen, aber wussten Sie, was für diese Anführungszeichen verwendet wird, variiert je nach Lokalisierung? Anstatt fest zu codieren, verwenden open-quote und close-quote , um sicherzustellen, dass die richtigen Anführungszeichen für die richtige Sprache verwendet werden.

Datums- und Zahlenformat

Sowohl Datumsangaben als auch Zahlen haben eine Methode, .toLocaleString , um die Formatierung basierend auf einer Lokalisierung (Sprache und/oder Region) zu ermöglichen. Browser, die diese unterstützen, werden mit allen verfügbaren Lokalisierungen ausgeliefert, sodass sie dort problemlos verwendet werden können, Node.js jedoch nicht. Glücklicherweise können Sie mit dem Full-icu-Modul für Node alle verfügbaren Lokalisierungsdaten verwenden. Führen Sie dazu nach der Installation des Moduls Ihren Code aus, wobei die Umgebungsvariable NODE_ICU_DATA auf den Pfad zum Modul gesetzt ist, z. B. NODE_ICU_DATA=node_modules/full-icu .

HTML-Metainformationen

Es gibt drei Bereiche in Ihrem HTML-Tag und Ihren Headern, die bei jeder Lokalisierung aktualisiert werden sollten:

• Die Sprache der Seite,
• Schreibrichtung,
• Alternative Sprachen, in denen die Seite verfügbar ist.

Das erste, das auf das html -Element mit den Eigenschaften dir bzw. lang geht, zB <html lang="en" dir-"ltr"> für US-Englisch. Die richtige Einstellung stellt sicher, dass der Inhalt in die richtige Richtung fließt, und kann es Browsern ermöglichen, zu verstehen, in welcher Sprache die Seite ist, was zusätzliche Funktionen wie die Übersetzung des Inhalts ermöglicht. Sie sollten auch rel="alternate" ="alternate"-Links einfügen, um Suchmaschinen wissen zu lassen, dass eine Seite vollständig übersetzt wurde, also wird <link href="/es" rel="alternate" hreflang="es"> auf unserer englischen Zielseite eingefügt lassen Sie Suchmaschinen wissen, dass es eine Übersetzung gibt, nach der sie Ausschau halten sollten.

Intrinsisches Design

Die Lokalisierung von Inhalten kann Designherausforderungen darstellen, da unterschiedliche Übersetzungen unterschiedlich viel Platz auf der Seite einnehmen. Einige Sprachen, wie z. B. Deutsch, haben längere Wörter, die mehr horizontalen Platz oder einen fehlerverzeihenderen Textumbruch erfordern. Andere Sprachen, wie Arabisch, haben größere Schriftarten, die mehr vertikalen Platz benötigen. Glücklicherweise gibt es eine Reihe von CSS-Tools, mit denen Abstände und Layouts nicht nur auf die Größe des Ansichtsfensters, sondern auch auf den Inhalt reagieren, was bedeutet, dass sie sich besser an mehrere Sprachen anpassen.

Es gibt eine Reihe von CSS-Einheiten, die speziell für die Arbeit mit Inhalten entwickelt wurden. Es gibt die Einheiten em und rem , die die berechnete Schriftgröße bzw. die Wurzelschriftgröße darstellen. Das Austauschen von px -Werten mit fester Größe für diese Einheiten kann viel dazu beitragen, dass eine Website besser auf ihren Inhalt reagiert. Dann gibt es noch die ch -Einheit, die die Inline-Größe der 0 (Null)-Glyphe in einer Schriftart darstellt. Auf diese Weise können Sie beispielsweise Dinge wie width direkt an den darin enthaltenen Inhalt binden.

Diese Units können dann mit bestehenden, mächtigen CSS-Werkzeugen für Layout, insbesondere Flexbox und Grid, zu Komponenten kombiniert werden, die sich ihrer Größe und Layouts ihrem Inhalt anpassen. Wenn Sie diese mit logischen Eigenschaften für Rahmen, Ränder und Polsterung anstelle von physikalischen physikalischen Eigenschaften erweitern, passen sich diese Layouts und Komponenten auch automatisch an den Schreibmodus an. Die Leistungsfähigkeit von intrinsischem Webdesign (geprägt von Jen Simmons), inhaltsbewussten Einheiten und logischen Eigenschaften ermöglicht es, Schnittstellen so zu entwerfen und zu erstellen, dass sie sich an jede Sprache anpassen können, nicht nur an jede Bildschirmgröße.

Lokalisierung (l10n)

Die offensichtlichste Form der Lokalisierung ist die Übersetzung von Inhalten von einer Sprache in eine andere. In subtileren Formen erfolgen Übersetzungen nicht nur nach Sprache, sondern auch nach Region, in der sie gesprochen wird, z. B. Englisch, das in Amerika gesprochen wird, im Vergleich zu Englisch, das in Großbritannien, Südafrika oder Australien gesprochen wird. Um hier erfolgreich zu sein, ist es entscheidend für den Erfolg zu verstehen, was zu übersetzen ist und wie Sie Ihre Inhalte für die Übersetzung strukturieren.

Content-Strategie

Es gibt einige Teile eines Softwareprojekts, die für die Lokalisierung wichtig sind, und andere, die es nicht sind. CSS-Klassennamen, JavaScript-Variablen und andere Stellen in Ihrer Codebasis, die zwar strukturell, aber nicht benutzerorientiert sind, müssen wahrscheinlich nicht lokalisiert werden. Herauszufinden, was lokalisiert werden muss und wie man es strukturiert, hängt von der Inhaltsstrategie ab.

Inhaltsstrategie hat viele Definitionen, aber hier bedeutet es die Struktur des Inhalts, die Mikrokopie (die Wörter und Phrasen, die während eines Projekts verwendet werden, die nicht an einen bestimmten Inhalt gebunden sind) und die Verbindungen davon. Für detailliertere Informationen zur Content-Strategie empfehle ich Content Strategy for Mobile von Karen McGrane und Designing Connected Content von Carrie Hane und Mike Atherton.

Für chromeOS.dev haben wir es geschafft, Inhaltsmodelle zu kodifizieren, die die Struktur unserer Inhalte beschreiben. Inhaltsmodelle sind nicht nur für lange artikelähnliche Inhalte; Ein Inhaltsmodell sollte für jede Entität vorhanden sein, die ein Benutzer speziell von Ihnen haben möchte, z. B. einen Autor, ein Dokument oder sogar wiederverwendbare Medienelemente. Gute Inhaltsmodelle umfassen individuell adressierbare Teile oder Chunks eines größeren konzeptuellen Stücks, während Chunks ausgeschlossen werden, die tangential verwandt sind oder von einem anderen Inhaltsmodell referenziert werden können. Beispielsweise kann ein Inhaltsmodell für einen Blogbeitrag einen Titel, eine Reihe von Tags, einen Verweis auf einen Autor, das Veröffentlichungsdatum und den Hauptteil des Beitrags enthalten, aber es sollte nicht die Zeichenfolge für Breadcrumbs oder die enthalten Name und Bild des Autors, das ein eigenes Inhaltsmodell sein sollte. Inhaltsmodelle ändern sich nicht von Lokalisierung zu Lokalisierung; sie sind Seitenstruktur. Eine Instanz eines Inhaltsmodells ist an eine Lokalisierung gebunden, und diese Instanzen können lokalisiert werden.

Inhaltsmodelle decken jedoch nur einen Teil dessen ab, was lokalisiert werden muss. Der Rest – Ihre „Weiterlesen“-Schaltflächen, Ihr „Menü“-Titel, Ihr Haftungsausschlusstext – das ist alles Mikrokopie. Auch das Mikroskopieren braucht Struktur. Während sich die Erstellung von Inhaltsmodellen natürlich anfühlt, insbesondere für vorlagengesteuerte Websites, sind Mikrokopiemodelle in der Regel weniger offensichtlich und werden oft versehentlich übersehen, indem das, was benötigt wird, direkt in eine Vorlage geschrieben wird.

Indem Sie Inhalts- und Mikrokopiemodelle erstellen und durchsetzen – durch ein Content-Management-System, Linting oder Review – können Sie sicherstellen, dass sich die Lokalisierung auf die Lokalisierung konzentrieren kann.

Lokalisieren Sie Werte, nicht Schlüssel

Inhalts- und Mikrokopiemodelle erzeugen normalerweise Strukturen, die Objekten in einer Codebasis ähneln; seien es Datenbankeinträge, JSON-Objekte, YAML oder Front Matter. Objektschlüssel nicht lokalisieren! Wenn sich Ihre Suchtext-Mikrokopie in einem microcopy Objekt unter microcopy.search.text , platzieren Sie sie nicht in einem microcopie Objekt unter microcopie.chercher.texte . Schlüssel in Modulen sollten als lokalisierungsunabhängige Bezeichner behandelt werden, damit sie zuverlässig in wiederverwendbaren Vorlagen verwendet und in einer Codebasis zuverlässig verwendet werden können. Das bedeutet auch, dass Objektschlüssel Endbenutzern nicht als Inhalt oder Mikrokopie angezeigt werden sollten.

Statische Site-Einrichtung

Für chromeOS.dev haben wir Eleventy (11ty) mit Nunjucks als unseren statischen Site-Generator verwendet, aber diese Empfehlungen zum Einrichten eines statischen Site-Generators sollten auf die meisten statischen Site-Generatoren anwendbar sein. Wo etwas 11ty-spezifisch ist, wird es ausgerufen.

Ordnerstruktur

Statische Site-Generatoren, die basierend auf der Ordnerstruktur kompiliert werden, unterstützen die Unterverzeichnis-i18n-Methode besonders gut. 11ty unterstützt auch eine Datenkaskade mit globalen Daten und ein Mittel zum Generieren von Seiten aus Daten durch Paginierung, sodass die Kombination dieser drei Konzepte eine grundlegende Ordnerstruktur ergibt, die wie folgt aussieht:

 . └── pages ├── _data ├── _generated └── {{locale-code}} ├── {{locale-code}}.11tydata.js ├── _data └── [...content]

Auf der obersten Ebene gibt es ein Verzeichnis, in dem die Seiten einer Site gespeichert werden, hier als pages bezeichnet. Darin verschachtelt gibt es einen _data -Ordner, der globale Datendateien enthält. Dieser Ordner ist wichtig, wenn als nächstes über Helfer gesprochen wird. Dann gibt es einen _generated -Ordner. Wir haben eine Reihe von Seiten, die, anstatt eigene Inhalte zu haben, aus bestehenden Inhalten, kleinen Mengen von Mikrokopien oder einer Kombination aus beidem generiert werden. Denken Sie an eine Startseite, eine Suchseite oder die Zielseite eines Blogabschnitts. Da diese Seiten stark mit Vorlagen versehen sind, speichern wir die Vorlagen im Ordner _generated und erstellen sie von dort aus, anstatt für jede einzelne HTML- oder Markdown-Dateien zu haben. Diesen Ordnern ist ein Unterstrich vorangestellt, um anzuzeigen, dass sie Seiten nicht direkt darunter ausgeben, sondern zum Erstellen von Seiten an anderer Stelle verwendet werden.

Als nächstes l10n Unterverzeichnisse! Jedes Verzeichnis sollte nach dem BCP47-Sprachtag (häufiger dem Gebietsschemacode) für die darin enthaltene Lokalisierung benannt werden: zum Beispiel en für Englisch oder en-US für amerikanisches Englisch. In der Codebasis von chromeOS.dev bezeichnen wir diese häufig auch als Gebietsschemas . Diese Ordner werden zu den Unterverzeichnissen der Lokalisierung und segmentieren den Inhalt für eine Lokalisierung. Die Datenkaskade von 11ty ermöglicht es, dass Daten für jede Datei in einem Verzeichnis und seinen untergeordneten Dateien verfügbar sind, wenn sich die Datei im Stammverzeichnis eines Verzeichnisses befindet und denselben Namen wie das Verzeichnis hat (als Verzeichnisdatendateien bezeichnet). 11ty verwendet ein Objekt, das von dieser Datei zurückgegeben wird, oder eine Funktion, die ein Objekt zurückgibt, und injiziert es in die für die Vorlagenerstellung bereitgestellten Variablen, sodass wir hier Zugriff auf Daten für alle Inhalte dieser Lokalisierung haben.

Um die Wartbarkeit dieser Dateien zu unterstützen, haben wir einen Helfer namens l10n-data geschrieben, der Teil unseres statischen Site-Gerüsts ist und diese Ordnerstruktur nutzt, um eine Kaskade lokalisierter Daten aufzubauen, sodass Daten stückweise lokalisiert werden können. Dies geschieht, indem Daten in einem gebietsschemaspezifischen Datenverzeichnis gespeichert werden, _data Verzeichnis darin (geladen in die Verzeichnisdatendatei). Wenn Sie zum Beispiel in unser englisches Locale-Datenverzeichnis schauen, sehen Sie Mikrokopiemodelle wie locale.json , die den Sprachcode und die Schreibrichtung definieren, die dann in unser HTML gerendert werden, newsletter.yml , das die für unsere benötigte Mikrokopie definiert Newsletter-Anmeldung und eine microcopy.yml -Datei, die allgemeine Mikrokopien enthält, die an mehreren Stellen auf der Website verwendet werden und nicht in eine spezifischere Datei passen. Überall dort, wo diese Mikrokopie verwendet wird, ziehen wir sie aus diesen Daten, die durch 11ty-Injektion von Datenvariablen in unsere Vorlagen zur Verfügung gestellt werden, um sie zu verwenden.

Die Mikrokopie ist in der Regel am schwierigsten zu verwalten, während der Rest des Inhalts meist einfach ist. Legen Sie Ihre Inhalte, häufig Markdown-Dateien oder HTML, im lokalisierten Unterordner ab. Bei statischen Site-Generatoren, die mit einer Ordnerstruktur arbeiten, werden der Dateiname und die Ordnerstruktur des Inhalts in der Regel 1:1 der endgültigen URL für diesen Inhalt zugeordnet, sodass eine Markdown-Datei unter en/web/pwas.md an eine URL ausgegeben würde en/web/pwa . Gemäß unserem Lokalisierungsprinzip „Werte, nicht Schlüssel“ haben wir uns entschieden, Inhaltsdateinamen (und damit Pfade) nicht zu lokalisieren, um es für uns einfacher zu machen, den Lokalisierungsstatus derselben Datei in verschiedenen Gebietsschemas zu verfolgen und für Benutzer zu erkennen Sie befinden sich auf der richtigen Seite zwischen den verschiedenen Gebietsschemas.

I18n Helfer

Zusätzlich zu Inhalt und Mikrokopie mussten wir eine Reihe von Hilfsmodulen schreiben, um die Arbeit mit lokalisierten Inhalten zu vereinfachen. 11ty hat ein Konzept namens Filter, mit dem Inhalte vor dem Rendern geändert werden können. Wir haben schließlich vier davon gebaut, um beim i18n-Templating zu helfen.

Der erste ist ein Datumsfilter. Wir haben standardisiert, dass alle Daten in unseren Inhalten als YAML-Datumswert geschrieben werden, weil wir sie meistens in YAML schreiben und sie in unseren Vorlagen als vollständiger UTC-Zeitstempel verfügbar sind. Bei Verwendung des full-icu Moduls und der Konfiguration kann die Datumszeichenfolge (Inhalt, der geändert wird) zusammen mit dem Gebietsschemacode für den gerenderten Inhalt direkt an Date.toLocaleString (mit optionalen Formatierungsoptionen) übergeben werden, um ein lokalisiertes Datum zu rendern. Date.toLocaleDateString kann optional verwendet werden, wenn Sie statt des vollständig lokalisierten Datums und der Uhrzeit nur den Datumsteil verwenden möchten, wenn keine Formatierungsoptionen übergeben werden.

Der zweite Filter ist etwas, das wir localURL genannt haben. Dies nimmt eine lokale URL (Inhalt wird geändert) und das Gebietsschema, in dem sich die URL befinden sollte, und tauscht sie aus. Es ändert beispielsweise /en/linux in /es/linux .

Bei den letzten beiden Filtern geht es darum, lokalisierte Informationen allein aus dem Gebietsschemacode abzurufen. Das dritte nutzt das Modul iso-639-10, um einen Gebietsschemacode in einen Sprachnamen in der Muttersprache umzuwandeln. Diese verwenden wir hauptsächlich für unsere Sprachauswahl. Der vierte verwendet das Modul iso-i18n-countries, um eine Liste von Ländern in dieser Sprache abzurufen. Dies verwenden wir hauptsächlich zum Erstellen von Formularen mit Länderlisten.

Zusätzlich zu den Filtern hat 11ty ein Konzept namens Sammlungen, das eine Gruppierung von Inhalten darstellt. 11ty stellt standardmäßig eine Reihe von Sammlungen zur Verfügung und kann sogar Sammlungen aus Tags erstellen. Auf einer mehrsprachigen Website stellten wir fest, dass wir benutzerdefinierte Sammlungen erstellen wollten. Am Ende haben wir eine Reihe von Hilfsfunktionen erstellt, um Sammlungen basierend auf der Lokalisierung zu erstellen. Auf diese Weise können wir beispielsweise standortspezifische Tag-Sammlungen oder Website-Abschnittssammlungen erstellen, ohne in unseren Vorlagen nach allen Inhalten auf unserer Website filtern zu müssen.

Unser letzter und wichtigster Helfer waren die globalen Daten unserer Website. Basierend auf der auf dem Gebietsschemacode basierenden Unterverzeichnisstruktur bestimmt diese Funktion dynamisch, welche Lokalisierungen die Site unterstützt. Es erstellt eine globale Variable, site , die die l10n -Eigenschaft enthält, die den gesamten Mikrokopie- und lokalisierungsspezifischen Inhalt von {{locale-code}}.11tydata.js . Es enthält auch eine languages , die alle verfügbaren Gebietsschemas als Array auflistet. Schließlich gibt die Funktion eine JavaScript-Datei aus, in der detailliert angegeben ist, welche Sprachen von der Website unterstützt werden, sowie einzelne Dateien für jeden Eintrag in {{locale-code}}.11tydata.js , die nach Lokalisierung verschlüsselt sind und alle zum Importieren durch unsere Browser-Skripts entwickelt wurden. Das schwere Heben dieser Datei bindet unsere statische Website an unser Front-End-JavaScript, wobei die einzige Quelle der Wahrheit die Lokalisierungsinformationen sind, die wir bereits benötigen. Es ermöglicht uns auch, Seiten basierend auf unseren Lokalisierungen programmgesteuert zu generieren, indem site.l10n . In Kombination mit unseren lokalisierungsspezifischen Sammlungen konnten wir so die Paginierung von 11ty verwenden, um lokalisierte Home- und News-Landing-Pages zu erstellen, ohne für jede Seite separate HTML-Seiten zu unterhalten.

Fazit

Die richtige Internationalisierung und Lokalisierung kann schwierig sein; Um es einfacher zu machen, ist es entscheidend zu verstehen, wie sich verschiedene Strategien und Komplexität auswirken. Wählen Sie eine i18n-Strategie, die für statische Sites und Unterverzeichnisse geeignet ist, und bauen Sie dann Tools darauf auf, um Teile von i18n und i10n aus den produzierten Inhalten zu automatisieren. Erstellen Sie robuste Inhalts- und Mikrokopiemodelle. Nutzen Sie Servicemitarbeiter für die serverunabhängige Lokalisierung. Verbinden Sie alles mit einem Design, das nicht nur auf die Bildschirmgröße, sondern auch auf den Inhalt reagiert. Am Ende haben Sie eine Website, die Ihre Benutzer aller Gebietsschemas lieben werden und die von Autoren und Übersetzern gepflegt werden kann, als wäre es eine einfache Website mit einem einzigen Gebietsschema.