material i18n: Gedankenstriche

Author: fmalcher

material/i18n/README.md

@@ -163,7 +163,7 @@ Die Objekt-Variante ist nützlich, wenn die Ausgangssprache beim Build unter ein
 ```
 
 Durch die Angabe von `sourceLocale` wird das InjectionToken `LOCALE_ID` beim Build automatisch auf den konfigurierten Wert gesetzt.
-Auch die passende Sprachdefinition wird automatisch geladen — der manuelle Provider in der `app.config.ts` und der Import in der `main.ts` sind damit nicht mehr notwendig.
+Auch die passende Sprachdefinition wird automatisch geladen – der manuelle Provider in der `app.config.ts` und der Import in der `main.ts` sind damit nicht mehr notwendig.
 In dieser einfachen Form unterstützt `sourceLocale` allerdings nur ein einzelnes Locale.
 Wie wir mehrere Sprachen über die `angular.json` konfigurieren und die Anwendung in verschiedenen Sprachvarianten bauen können, zeigen wir im Abschnitt [Übersetzung während des Build-Prozesses](#übersetzung-während-des-build-prozesses).
 
@@ -213,7 +213,7 @@ export class MyComponent {
 ## Internationalisierung (i18n): die Anwendung übersetzen
 
 Im vorhergehenden Abschnitt zur Lokalisierung haben wir betrachtet, wie wir Formate für ein einzelnes Locale anpassen.
-Damit sind Datumsangaben, Zahlen und Währungen bereits korrekt formatiert — aber die eigentlichen Texte der Anwendung werden noch nicht übersetzt.
+Damit sind Datumsangaben, Zahlen und Währungen bereits korrekt formatiert – aber die eigentlichen Texte der Anwendung werden noch nicht übersetzt.
 Buttons, Überschriften, Hinweistexte und Fehlermeldungen erscheinen weiterhin in der Ursprungssprache.
 Nun geht es darum, die Anwendung mehrsprachig anzubieten.
 Bei der Übersetzung von Texten hilft uns das i18n-Tooling der Angular CLI.
@@ -273,7 +273,7 @@ Beide Angaben sind optional.
 <h1 i18n="description">Salut!</h1>
 ```
 
-Steht kein DOM-Element zur Verfügung, auf dem wir das Attribut `i18n` setzen könnten, können wir die Markierung mit einem `<ng-container>` vornehmen. Angular rendert dieses Element nicht im DOM — es erzeugt also kein zusätzliches HTML-Element, sondern dient ausschließlich als Hilfskonstrukt für die Übersetzung:
+Steht kein DOM-Element zur Verfügung, auf dem wir das Attribut `i18n` setzen könnten, können wir die Markierung mit einem `<ng-container>` vornehmen. Angular rendert dieses Element nicht im DOM – es erzeugt also kein zusätzliches HTML-Element, sondern dient ausschließlich als Hilfskonstrukt für die Übersetzung:
 
 ```html
 <ng-container i18n="meaning|description">
@@ -364,7 +364,7 @@ removeBook() {
 
 ### Pluralisierung und ICU-Ausdrücke
 
-Nicht alle Texte lassen sich 1:1 übersetzen — manchmal hängt die korrekte Formulierung von einem konkreten Wert ab.
+Nicht alle Texte lassen sich 1:1 übersetzen – manchmal hängt die korrekte Formulierung von einem konkreten Wert ab.
 Angular unterstützt dafür die sogenannte [ICU Message Syntax](https://unicode-org.github.io/icu/userguide/format_parse/messages) (*International Components for Unicode*).
 Ein ICU-Ausdruck besteht aus einem Ausdruck (z. B. einem Signal), einem ICU-Typ und den zugehörigen Varianten, eingeschlossen in geschweifte Klammern:
 
@@ -390,18 +390,18 @@ Mit `plural` unterscheiden wir Textbausteine anhand eines numerischen Werts:
 ```
 
 Dabei ist `count` ein Signal der Komponente.
-Die geschweiften Klammern um `{{count()}}` innerhalb der `other`-Variante sind die gewohnte Interpolation von Angular — die äußeren Klammern gehören zur ICU-Syntax.
+Die geschweiften Klammern um `{{count()}}` innerhalb der `other`-Variante sind die gewohnte Interpolation von Angular – die äußeren Klammern gehören zur ICU-Syntax.
 
 Neben exakten Werten wie `=0` oder `=1` definiert die ICU-Spezifikation auch benannte Kategorien: `zero`, `one`, `two`, `few`, `many` und `other`.
 Welche dieser Kategorien tatsächlich greifen, wird durch die [CLDR Plural Rules](https://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html) festgelegt und hängt vom eingestellten Locale ab.
 Die Bezeichnungen `few` und `many` sind dabei leicht irreführend: Sie beschreiben keine Größenordnungen, sondern sprachspezifische grammatische Kategorien.
 Im Polnischen etwa gilt `few` für Zahlen mit den Endziffern 2–4 (außer 12–14), im Arabischen für 3–10.
-Deutsch und Englisch verwenden lediglich `one` und `other` — die übrigen Kategorien existieren für diese Sprachen nicht.
-Die Kategorie `other` ist der Fallback und muss immer angegeben werden. Nicht zutreffende Kategorien werden stillschweigend ignoriert — solange `other` vorhanden ist, kann es nicht zu einem Laufzeitfehler kommen.
+Deutsch und Englisch verwenden lediglich `one` und `other` – die übrigen Kategorien existieren für diese Sprachen nicht.
+Die Kategorie `other` ist der Fallback und muss immer angegeben werden. Nicht zutreffende Kategorien werden stillschweigend ignoriert – solange `other` vorhanden ist, kann es nicht zu einem Laufzeitfehler kommen.
 
 Im Idealfall definieren wir im Quelltext alle Kategorien, die für eine der Zielsprachen relevant sein könnten.
 Das Übersetzungsteam muss dann aber nur diejenigen Kategorien übersetzen, die in der jeweiligen Zielsprache auch tatsächlich greifen.
-Für eine deutsche Übersetzung reicht es aus, `one` und `other` zu übersetzen — `two`, `few` und `many` werden hier nie ausgewertet.
+Für eine deutsche Übersetzung reicht es aus, `one` und `other` zu übersetzen – `two`, `few` und `many` werden hier nie ausgewertet.
 Für eine arabische Übersetzung hingegen sollten alle sechs Kategorien berücksichtigt werden.
 Exakte Werte wie `=0` oder `=2` funktionieren unabhängig vom Locale immer und können zusätzlich zu den benannten Kategorien verwendet werden.
 
@@ -519,19 +519,19 @@ Wie bereits erwähnt, bietet Angular zwei Wege, um die übersetzten Texte in die
 Wir beginnen mit dem ersten der beiden Ansätze: Die Anwendung wird direkt beim Build in mehreren Sprachen erzeugt.
 Das Ergebnis sind mehrere gebaute Varianten der gesamten Angular-Anwendung in jeweils einer Sprache.
 Da keine Übersetzungen zur Laufzeit geladen werden müssen, ist die Anwendung sofort einsatzbereit.
-Ein Nachteil ist jedoch, dass die Texte nach dem Build nicht mehr angepasst werden können — sie sind fester Bestandteil des Quellcodes.
+Ein Nachteil ist jedoch, dass die Texte nach dem Build nicht mehr angepasst werden können – sie sind fester Bestandteil des Quellcodes.
 
 ### Die App mit Übersetzungen bauen
 
 Wir haben bereits alle Nachrichten markiert, extrahiert und übersetzt.
-Die Datei mit den übersetzten Nachrichten liegt ebenfalls im Projekt — und nun muss die Anwendung nur noch gebaut werden.
+Die Datei mit den übersetzten Nachrichten liegt ebenfalls im Projekt – und nun muss die Anwendung nur noch gebaut werden.
 
 Der empfohlene Weg ist, dass die Anwendung für jedes Locale separat kompiliert wird.
 Das Ergebnis ist eine kleine, schnelle und sofort einsatzbereite App mit einer einzigen eingebauten Sprache.
 Die Startzeit wird nicht durch das dynamische Nachladen der Übersetzungen verlängert.
 
 Zunächst konfigurieren wir das Standard-Locale in der `angular.json`.
-Den Eintrag `sourceLocale` im Abschnitt `i18n` haben wir [weiter oben](#alternative-locale-über-die-build-konfiguration-setzen) bereits kennengelernt — er setzt das InjectionToken `LOCALE_ID` und lädt die passende Sprachdefinition automatisch.
+Den Eintrag `sourceLocale` im Abschnitt `i18n` haben wir [weiter oben](#alternative-locale-über-die-build-konfiguration-setzen) bereits kennengelernt – er setzt das InjectionToken `LOCALE_ID` und lädt die passende Sprachdefinition automatisch.
 Im BookManager verwenden wir als Ausgangssprache `en-US`:
 
 ```json
@@ -827,7 +827,7 @@ Das betrifft insbesondere die verschiedenen Abschnitte mit `localize` und die Ko
 ### Übersetzungen zur Laufzeit laden
 
 Jetzt betrachten wir die zweite Variante: Statt die Übersetzungen beim Build einzubauen, laden wir sie zur Laufzeit.
-Dafür müssen die Übersetzungen verfügbar sein, bevor die Anwendung startet — damit Angular die Texte beim Bootstrapping direkt austauschen kann.
+Dafür müssen die Übersetzungen verfügbar sein, bevor die Anwendung startet – damit Angular die Texte beim Bootstrapping direkt austauschen kann.
 Deshalb müssen wir den Code in der Datei `main.ts` unterbringen, bevor wir `bootstrapApplication()` aufrufen.
 Hier legen wir uns eine neue Funktion `setupLocale()` an.
 Sie soll alle Schritte erledigen, die vor dem Start der Anwendung notwendig sind:
@@ -929,12 +929,12 @@ Auf der aktuellen Grundlage können wir nun einen einfachen Sprachwechsel implem
 Dafür müssen wir die gewählte Sprache persistieren und beim Start entscheiden, welche Sprachdatei geladen wird.
 Je nach Architektur der Anwendung bieten sich dafür unterschiedliche Mechanismen an:
 
-- **`localStorage`**: Die einfachste Lösung im Browser — die Sprachauswahl wird lokal gespeichert und steht beim nächsten Seitenaufruf sofort zur Verfügung. Auf dem Server (SSR) ist `localStorage` allerdings nicht verfügbar (mehr dazu später im Artikel).
+- **`localStorage`**: Die einfachste Lösung im Browser – die Sprachauswahl wird lokal gespeichert und steht beim nächsten Seitenaufruf sofort zur Verfügung. Auf dem Server (SSR) ist `localStorage` allerdings nicht verfügbar (mehr dazu später im Artikel).
 - **Session oder Identity-Token**: Verfügt die Anwendung über ein Session-Management oder eine Authentifizierung, kann die Sprachpräferenz im Nutzerprofil oder in der Session hinterlegt werden. Dieser Ansatz funktioniert sowohl im Browser als auch auf dem Server.
 - **`Accept-Language`-Header**: Der Browser sendet bei jeder Anfrage einen Header mit den im Browser eingestellten Sprachen. Dieser kann als Fallback dienen, wenn keine explizite Auswahl vorliegt.
 - **Cookies**: Cookies werden bei jedem HTTP-Request an den Server gesendet und könnten die Sprachauswahl transportieren. Allerdings bringen Cookies zahlreiche Nachteile mit sich: Sie erhöhen die Größe jedes Requests, erfordern besondere Sicherheitsmaßnahmen (z. B. `HttpOnly`, `Secure`, `SameSite`) und unterliegen strengen datenschutzrechtlichen Anforderungen. In der Regel sind die anderen genannten Ansätze vorzuziehen.
 
-Im Folgenden verwenden wir exemplarisch `localStorage` — die einfachste Variante für eine rein clientseitige Anwendung.
+Im Folgenden verwenden wir exemplarisch `localStorage` – die einfachste Variante für eine rein clientseitige Anwendung.
 Dies ist keine generelle Handlungsempfehlung: Für das jeweilige Projekt können die anderen Ansätze besser geeignet sein, insbesondere wenn Server-Side Rendering zum Einsatz kommt.
 
 Damit die Sprache in der Oberfläche umgeschaltet werden kann, erstellen wir in der `App`-Komponente eine Methode `changeLocale()`:
@@ -955,7 +955,7 @@ export class App {
 
 > **Hinweis:** Bei Anwendungen mit Server-Side Rendering (SSR) ist zu beachten, dass `localStorage` und `location` Browser-APIs sind, die in Node.js nicht zur Verfügung stehen.
 > Eine Verwendung auf dem Server würde zu einem Laufzeitfehler führen.
-> Die Methode `changeLocale()` wird hier ausschließlich durch ein Click-Event ausgelöst und ist daher unkritisch — Events finden nur im Browser statt.
+> Die Methode `changeLocale()` wird hier ausschließlich durch ein Click-Event ausgelöst und ist daher unkritisch – Events finden nur im Browser statt.
 > Auf die Besonderheiten beim Zusammenspiel mit SSR gehen wir weiter unten noch einmal ein.
 
 Im Template der Komponente erzeugen wir zwei Buttons, um die Methode `changeLocale()` aufzurufen.
@@ -973,7 +973,7 @@ So ist es möglich, die Sprache zwischen Deutsch und Englisch zu wechseln.
 <!-- ... -->
 ```
 
-Die gewählte Sprache wird nun im Browser gespeichert — jetzt müssen wir diese Entscheidung beim Start der Anwendung in der Datei `main.ts` berücksichtigen.
+Die gewählte Sprache wird nun im Browser gespeichert – jetzt müssen wir diese Entscheidung beim Start der Anwendung in der Datei `main.ts` berücksichtigen.
 
 Unsere Funktion `setupLocale()` soll dazu als Rückgabewert die gewählte Sprache liefern.
 Diese Information können wir dann beim Bootstrapping verwenden, um den Provider für die `LOCALE_ID` zu setzen.
@@ -1036,12 +1036,12 @@ Wenn wir unsere Anwendung mit Server-Side Rendering betreiben (siehe unseren [On
 ### Separate Server-Bundles pro Locale
 
 Beim Build-Zeit-Ansatz mit `localize: true` und `outputMode: "server"` erzeugt Angular pro Locale ein eigenes Server-Bundle.
-Die `AngularAppEngine` routet eingehende Anfragen anhand des URL-Pfads automatisch an das passende Bundle weiter — ein Aufruf von `/de/books` wird vom deutschen Server-Bundle bedient, `/en-US/books` vom englischen.
+Die `AngularAppEngine` routet eingehende Anfragen anhand des URL-Pfads automatisch an das passende Bundle weiter – ein Aufruf von `/de/books` wird vom deutschen Server-Bundle bedient, `/en-US/books` vom englischen.
 
 ### Automatische Sprachweiterleitung
 
 Ruft jemand die Wurzel-URL `/` auf, wertet Angular den `Accept-Language`-Header des Browsers aus und leitet mit einem HTTP-302-Redirect an die passende Sprachvariante weiter.
-Diese Weiterleitung funktioniert nur mit `outputMode: "server"` und ist dort automatisch aktiv — eine manuelle Konfiguration im Webserver (z. B. Nginx oder Apache) ist nicht notwendig.
+Diese Weiterleitung funktioniert nur mit `outputMode: "server"` und ist dort automatisch aktiv – eine manuelle Konfiguration im Webserver (z. B. Nginx oder Apache) ist nicht notwendig.
 Ohne SSR muss die Weiterleitung hingegen manuell im Webserver eingerichtet werden.
 
 ### Hydration mit i18n-Blöcken
@@ -1061,10 +1061,10 @@ Ohne `withI18nSupport()` werden Elemente mit i18n-Attributen bei der Hydration 
 
 Beim Laufzeit-Ansatz haben wir die Sprachauswahl exemplarisch im `localStorage` gespeichert.
 Auf dem Server steht `localStorage` jedoch nicht zur Verfügung. Es handelt sich um eine reine Browser-API, die in Node.js nicht existiert.
-Anders als beim Build-Zeit-Ansatz existieren beim Laufzeit-Ansatz auch keine sprachspezifischen URL-Pfade wie `/de/` oder `/en/` — das Locale lässt sich also nicht aus der URL ableiten.
+Anders als beim Build-Zeit-Ansatz existieren beim Laufzeit-Ansatz auch keine sprachspezifischen URL-Pfade wie `/de/` oder `/en/` – das Locale lässt sich also nicht aus der URL ableiten.
 
 Kommt Server-Side Rendering zum Einsatz, sollte deshalb einer der im [Abschnitt zum Sprachwechsel](#die-sprache-wechseln) genannten servertauglichen Ansätze gewählt werden, etwa Session-basierte Speicherung oder die Auswertung des `Accept-Language`-Headers.
-Eine pauschale Lösung gibt es hier nicht — die Wahl hängt davon ab, wie die Anwendung generell Daten persistiert und welche Infrastruktur zur Verfügung steht.
+Eine pauschale Lösung gibt es hier nicht – die Wahl hängt davon ab, wie die Anwendung generell Daten persistiert und welche Infrastruktur zur Verfügung steht.
 Am unkompliziertesten ist es in der Praxis, die Sprache bereits zur Build-Zeit festzulegen und so den Build-Zeit-Ansatz mit SSR zu kombinieren.
 
 ## Deployment: Unterverzeichnisse mit `subPath` anpassen
@@ -1089,12 +1089,12 @@ In diesem Beispiel wird die deutsche Variante unter `/deutsch/` statt unter `/de
 Bei beiden vorgestellten Ansätzen wurde eine technische Einschränkung deutlich:
 Wir können nur jeweils eine einzelne Sprache laden.
 Dazu können wir entweder eine speziell dafür gebaute Anwendung erzeugen, oder wir können die Sprache einmalig vor dem Start der App laden und festlegen.
-Ein Wechsel zur Laufzeit ist mit den Bordmitteln von Angular nicht möglich — zum Laden einer Sprache muss immer die App gewechselt bzw. die Seite neu geladen werden.
+Ein Wechsel zur Laufzeit ist mit den Bordmitteln von Angular nicht möglich – zum Laden einer Sprache muss immer die App gewechselt bzw. die Seite neu geladen werden.
 Dafür haben wir den Vorteil, dass wir keine Einbußen bei der Performance in Kauf nehmen müssen.
 Zur Laufzeit ist die Sprache immer schon festgelegt, und es müssen keine zusätzlichen Ressourcen dafür beansprucht werden.
 
 Eine weitere Einschränkung betrifft dynamische Inhalte: Das i18n-Tooling von Angular übersetzt ausschließlich statische Texte in Templates und im TypeScript-Code.
-Inhalte, die zur Laufzeit von einer API geladen werden, können damit nicht übersetzt werden — hier muss entweder die API selbst die Texte in der richtigen Sprache liefern, oder wir müssen im Code eine eigene Logik dafür bereitstellen.
+Inhalte, die zur Laufzeit von einer API geladen werden, können damit nicht übersetzt werden – hier muss entweder die API selbst die Texte in der richtigen Sprache liefern, oder wir müssen im Code eine eigene Logik dafür bereitstellen.
 
 Wenn du die Anwendung beim Sprachwechsel auf keinen Fall neu laden willst, kannst du die mitgelieferten Ansätze von Angular nicht verwenden.
 Wir empfehlen dann, auf eine externe Bibliothek zurückzugreifen, z. B. [Transloco](https://github.com/jsverse/transloco) oder [ngx-translate](https://github.com/ngx-translate/core).
@@ -1104,7 +1104,7 @@ Dieser Ansatz kann niemals so performant sein wie eine Anwendung, die gezielt f
 ## Fazit
 
 Angular liefert ein ausgereiftes Tooling für Lokalisierung und Internationalisierung mit.
-In diesem Artikel haben wir den gesamten Weg kennengelernt: von der Lokalisierung für ein einzelnes Locale über die Extraktion und Übersetzung von Texten bis hin zur mehrsprachigen Auslieferung — sowohl zur Build-Zeit als auch zur Laufzeit.
+In diesem Artikel haben wir den gesamten Weg kennengelernt: von der Lokalisierung für ein einzelnes Locale über die Extraktion und Übersetzung von Texten bis hin zur mehrsprachigen Auslieferung – sowohl zur Build-Zeit als auch zur Laufzeit.
 Wir können jetzt eine Angular-Anwendung vollständig internationalisieren, ohne auf externe Bibliotheken angewiesen zu sein.
 Das i18n-Tooling der Angular CLI übernimmt dabei die schwere Arbeit: Es extrahiert die Texte, erzeugt Übersetzungsdateien und baut die lokalisierten Varianten automatisch.
 Wir wünschen viel Erfolg bei der Bereitstellung eurer Anwendung für eine internationale Zielgruppe!