© Excellent backgrounds/Shutterstock.com
Java Magazin
Internationalisierung von Single Page Applications

Around the World

Für Webapplikationen, die von Anwendern aus verschiedenen Ländern genutzt werden, ist Internationalisierung eine Standardanforderung. Wir wollen verschiedene Ansätze betrachten, die es ermöglichen, eine JavaScript-Applikation an die jeweiligen sprach- und landesspezifischen Besonderheiten anzupassen. Exemplarisch wird eine React-Anwendung internationalisiert.

Philip Stroh


Zu Beginn wollen wir die Begriffe Internationalisierung und Lokalisierung klären. Diese werden zwar oft synonym verwendet, es handelt sich jedoch um unterschiedliche Schritte bei der Bereitstellung einer Anwendung zur internationalen Nutzung. Durch Internationalisierung – häufig aus dem Englischen mit dem Numeronym i18n abgekürzt – wird eine Anwendung so vorbereitet, dass sie per Konfiguration leicht für verschiedene Sprachen und Länder angepasst werden kann. Hierfür setzt man beispielsweise statt hartkodierter Texte Platzhalter ein und bereitet die Unterstützung verschiedener Zahlen- und Datumsformate vor. Im nächsten Schritt, der Lokalisierung (localization = l10n), werden die Übersetzungen für die jeweiligen Sprachen hinzugefügt, ohne dass weitere Änderungen im Code notwendig sind. Die Sprache und das Land, an die die Software angepasst werden soll, werden über die Locale definiert. Diese kann auch weitere Eigenschaften vorgeben, zum Beispiel den verwendeten Zeichensatz oder die Sortierungen. JavaScript nutzt dabei die Locale-Codes nach dem Standard BCP 47 [1]. Beispiele hierfür sind de, de-DE und de-CH.

Aufgrund des Umfangs des Themas wird dieser Artikel sich auf die folgenden, gängigen i18n-Fragestellungen beschränken:

Übersetzungen: Ersetzen von Texten in der Anwendung mit Stringinterpolation und PluralbildungFormatierung: Anzeige von Datums-, Zeit- und Zahlenformaten sowie Währungen, abhängig von der Locale des UsersParsen: Verarbeitung von Eingaben in einem Locale-abhängigen Datums-, Zeit- und ZahlenformatSortierung: Berücksichtigung von nationalen Regeln bei Textvergleichen

Auf weitere, speziellere Anforderungen – wie zum Beispiel linksläufige Schreibrichtung oder die Verarbeitung von Telefonnummern, Adressen und Postleitzahlen – kann hier nicht näher eingegangen werden. Bezüglich der Schreibrichtung, die nicht per JavaScript, sondern per HTML und CSS gelöst wird, sei an dieser Stelle auf den Artikel „Right-To-Left Development In Mobile Design“ von Robert Dodis [2] verwiesen.

Standards: CLDR und ICU

Zur Internationalisierung und Lokalisierung von Anwendungen gibt es eine breite Palette unterschiedlicher Standards beziehungsweise Standardformate. Zwei Projekte sind hierbei besonders relevant, nämlich das Common Locale Data Repository (CLDR) und die International Components for Unicode (ICU).

Bei CLDR handelt es sich um ein Projekt des Unicode-Konsortiums [3]. Es stellt ein umfangreiches Datenset mit Lokalisierungsinformationen bereit. Enthalten sind ...

Java Magazin
Internationalisierung von Single Page Applications

Around the World

Für Webapplikationen, die von Anwendern aus verschiedenen Ländern genutzt werden, ist Internationalisierung eine Standardanforderung. Wir wollen verschiedene Ansätze betrachten, die es ermöglichen, eine JavaScript-Applikation an die jeweiligen sprach- und landesspezifischen Besonderheiten anzupassen. Exemplarisch wird eine React-Anwendung internationalisiert.

Philip Stroh


Zu Beginn wollen wir die Begriffe Internationalisierung und Lokalisierung klären. Diese werden zwar oft synonym verwendet, es handelt sich jedoch um unterschiedliche Schritte bei der Bereitstellung einer Anwendung zur internationalen Nutzung. Durch Internationalisierung – häufig aus dem Englischen mit dem Numeronym i18n abgekürzt – wird eine Anwendung so vorbereitet, dass sie per Konfiguration leicht für verschiedene Sprachen und Länder angepasst werden kann. Hierfür setzt man beispielsweise statt hartkodierter Texte Platzhalter ein und bereitet die Unterstützung verschiedener Zahlen- und Datumsformate vor. Im nächsten Schritt, der Lokalisierung (localization = l10n), werden die Übersetzungen für die jeweiligen Sprachen hinzugefügt, ohne dass weitere Änderungen im Code notwendig sind. Die Sprache und das Land, an die die Software angepasst werden soll, werden über die Locale definiert. Diese kann auch weitere Eigenschaften vorgeben, zum Beispiel den verwendeten Zeichensatz oder die Sortierungen. JavaScript nutzt dabei die Locale-Codes nach dem Standard BCP 47 [1]. Beispiele hierfür sind de, de-DE und de-CH.

Aufgrund des Umfangs des Themas wird dieser Artikel sich auf die folgenden, gängigen i18n-Fragestellungen beschränken:

Übersetzungen: Ersetzen von Texten in der Anwendung mit Stringinterpolation und PluralbildungFormatierung: Anzeige von Datums-, Zeit- und Zahlenformaten sowie Währungen, abhängig von der Locale des UsersParsen: Verarbeitung von Eingaben in einem Locale-abhängigen Datums-, Zeit- und ZahlenformatSortierung: Berücksichtigung von nationalen Regeln bei Textvergleichen

Auf weitere, speziellere Anforderungen – wie zum Beispiel linksläufige Schreibrichtung oder die Verarbeitung von Telefonnummern, Adressen und Postleitzahlen – kann hier nicht näher eingegangen werden. Bezüglich der Schreibrichtung, die nicht per JavaScript, sondern per HTML und CSS gelöst wird, sei an dieser Stelle auf den Artikel „Right-To-Left Development In Mobile Design“ von Robert Dodis [2] verwiesen.

Standards: CLDR und ICU

Zur Internationalisierung und Lokalisierung von Anwendungen gibt es eine breite Palette unterschiedlicher Standards beziehungsweise Standardformate. Zwei Projekte sind hierbei besonders relevant, nämlich das Common Locale Data Repository (CLDR) und die International Components for Unicode (ICU).

Bei CLDR handelt es sich um ein Projekt des Unicode-Konsortiums [3]. Es stellt ein umfangreiches Datenset mit Lokalisierungsinformationen bereit. Enthalten sind ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang