Zum Hauptinhalt springen

Internationalisierung

Überblick​

Alle Anwendungen müssen internationalisiert werden, während viele auch lokalisiert werden (was für unsere Zwecke im Wesentlichen eine Übersetzung ist). Wenn die Internationalisierung nicht korrekt durchgeführt wird, ist eine vollständige Lokalisierung schwierig, wenn nicht sogar unmöglich.

Jutro bietet Ihnen eine gute Unterstützung bei der Internationalisierung und Lokalisierung, aber Sie kümmern sich um die Implementierung.

Sprache, Gebietsschema, Land und Währung werden als völlig unabhängige Variablen behandelt:

  • Sprache: Diese umfasst reguläre UI-Zeichenfolgen
    • In Anwendungen kann ein Array von availableLanguages und eine preferredLanguage (Standard) konfiguriert werden.
  • Gebietsschema: Auch als regionales Format bekannt, regelt, wie Datumsangaben, Uhrzeiten, Zahlen und Kalender formatiert werden. Beachten Sie, dass jede reguläre UI-Zeichenfolge (je nach Sprache), der eine Datums-, Zeit- oder Zahlenvariable enthält, entsprechend dem Gebietsschema formatiert werden sollte
    • In Anwendungen kann ein Array von availableLocales und ein preferredLocale (Standard) konfiguriert werden.
  • Land: Bestimmt, wie sich Telefonnummern- oder Adresskomponenten verhalten
    • Anwendungen können ein festlegen defaultCountryCode, das, sofern es auf Komponentenebene nicht überschrieben wird, von Komponenten wie IntlPhoneNumberField und Address verwendet wird, um das Standardland festzulegen
  • Währung: Die Währung soll nicht von der Sprache, dem Land oder dem Gebietsschema des Benutzers abgeleitet werden.
    • Die Währung ist lediglich eine Eigenschaft einer Transaktion.
    • In Anwendungen kann defaultCurrency festgelegt werden, die, sofern sie nicht auf Komponentenebene überschrieben wird, zum Konfigurieren von Komponenten wie CurrencyInput verwendet wird.

Bevor Sie beginnen​

Die Jutro-Beispiel-Anwendung bietet Folgendes:

  • Alle UI-Zeichenfolgen sind so markiert, dass sie in die Datei lang.json extrahiert werden können und somit übersetzbar sind.
  • Der Build-Prozess erstellt automatisch unsere Pseudosprache, die als Sherlock bekannt ist
  • Alle lokalisierungsabhängigen Komponenten (Datumsauswahl, Währungseingabe etc.) verhalten sich automatisch korrekt.

Unterstützung der Internationalisierung (i18n) in Jutro​

  • react-intl: Eine Bibliothek, die React-Komponenten (FormattedDate, FormattedNumber und andere) und APIs zur Formatierung von Daten, Zahlen und Zeichenfolgen sowie zur Handhabung von Übersetzungen umfasst. Einige Komponenten, z. B. CurrencyInput, umschließen Komponenten, die über react-intl bereitgestellt werden.
  • jutro - Diese Befehlszeilenprogramm, das einen Unterbefehl bereitstellt, der die Verwaltung von übersetzbarem Text vereinfacht. Weitere Informationen finden Sie in den entsprechenden Abschnitten zu CLI-Befehlen auf der Jutro-Plattform.
  • jutro-locale - Das Jutro-Paket, das u. a. Folgendes enthält:
    • GlobalizationProvider - Richtet den Internationalisierungskontext einer Anwendung über die Komponente IntlProvider von react-intl ein.
    • Globalisierungsspeicher basierend auf zustand, die Sie zur Interaktion mit den Gebietsschemaeinstellungen des Benutzers und Änderungen an Sprache, Gebietsschema, Währung und Land verwenden können.
  • jutro-components: Enthält eine Vielzahl von sprachabhängigen Komponenten, wie z. B. die folgende Mischung aus Anzeigefeldern für Eingaben und Werte:
    • CurrencyInput, CurrencyValue
    • SimpleDate, DateRange, DateTime, DateTimeZone
    • InputNumber, NumberValue
    • IntlPhoneNumberField, PhoneNumberValue
    • GlobalizationChooser - Widget, mit dem Sie locale und language unabhängig voneinander auswählen können.
    • LanguageSelector - Ähnlich wie GlobalizationChooser, kann jedoch nur zur Sprachauswahl verwendet werden.

Ordnerstruktur​

  • i18n/src/* - Automatisch generierte temporäre Dateien, die lediglich die UI-Zeichenfolgen enthalten, die aus src/**extrahiert wurden. Bearbeiten Sie sie nicht manuell und checken Sie sie nicht in die Quellcodeverwaltung ein. .gitignore ist bereits so konfiguriert, dass diese Dateien ignoriert werden
  • src/i18n/lang.json - Die generierte Übersetzungsdatei (kann in package.json durch Ändern der Befehlsoptionen jutro geändert werden). Auch die Datei, die .gitignore hinzugefügt wird, darf nicht manuell bearbeitet werden. Die Übersetzer verwenden diese Datei als Grundlage für weitere Übersetzungen. Diese fügen andere Sprachdateien im selben Ordner hinzu, z. B. ru.json, fr.json

Zeichenfolgenform​

Jutro enthält einen intlMessageShape-Typ mit den folgenden Eigenschaften:

  • id: Muss in der Anwendung eindeutig sein
  • defaultMessage: Der eigentliche UI-Text. Es ist auch die Fallback-Zeichenfolge, wenn keine Übersetzungen vorhanden sind
  • description (optional): Hilft dem Übersetzer, den Kontext zu verstehen, in dem die Zeichenfolge erscheint
  • args (optional): Erlaubt die Übergabe von Argumentwerten. Siehe Variablen-Interpolation

Zeichenfolgen müssen diese Form haben, sonst können sie nicht für die Übersetzung extrahiert werden.

Siehe auch: intlMessageShape

Internationalisierung einer Anwendung​

react-intl bietet den größten Teil der Unterstützung für die Internationalisierung von Jutro-Apps.

Hinweis: Wenn Sie die mit Jutro gelieferten Beispielanwendung nutzen, erhalten Sie die meisten/alle der unten aufgeführten Funktionen kostenlos.

IntlProvider (über GlobalizationProvider) hinzufügen​

Wenn Sie die Jutro-Funktion start nicht verwenden, können Sie unter Verwendung von GlobalizationProvider Jutro-Globalisierungsfunktionen in der Anwendung hinzufügen.

Im Stamm Ihrer Anwendung müssen Sie die Jutro-Komponente GlobalizationProvider von jutro-locale hinzufügen. Dies bietet einen Internationalisierungskontext für alles, was es enthält. Es wird die Komponente IntlProvider von react-intl verwendet.

IntlProvider legt zwei Schlüsseleigenschaften fest:

  • locale: Wirkt sich auf das Verhalten aller gebietsschemaabhängigen Komponenten aus, z. B. Komponenten, die für die Eingabe von Datum, Kalender, Anzeige, Zeit und Zahlen verwendet werden
  • messages: Das Array der Übersetzungen, die von den eingeschlossenen Komponenten verwendet werden sollen

Beachten Sie, dass locale und messages unabhängig voneinander sind. Das heißt, Sie könnten locale auf fr-FR setzen, das Array messages könnte aber beispielsweise deutsche Übersetzungen enthalten.

localeSettings {#configure-localesettings-in-srcconfigconfigjson} konfigurieren​

Sie können localeSettings in src/config/config.json festlegen. Zum Beispiel:

src/config/config.json
{
  "localeSettings": {
    "availableLocales": ["en-US", "es-ES", "es-MX", "de-DE", "pl"],
    "availableLanguages": ["en", "es", "de", "pl", "yy"],
    "preferredLocale": "en-US",
    "preferredLanguage": "en",
    "defaultCountryCode": "US",
    "defaultCurrency": "USD"
  }
}

Wenn localeSettings oder ein Teil davon in Ihrer Konfiguration weggelassen wird, greift die Anwendung auf diese Standardeinstellungen zurück:

src/config/config.json
{
  "localeSettings": {
    "availableLocales": ["en-US"],
    "availableLanguages": ["en"],
    "preferredLocale": "en-US",
    "preferredLanguage": "en",
    "defaultCountryCode": "US",
    "defaultCurrency": "USD"
  }
}

Benutzern die Möglichkeit bieten, Sprache und Gebietsschema auszuwählen​

Sie haben verschiedene Möglichkeiten, um Benutzern die Auswahl der Sprache und des Gebietsschemas zu ermöglichen und um die jeweilige Auswahl zu speichern.

GlobalizationChooser-Komponente​

GlobalizationChooser ermöglicht es dem Benutzer, Sprache und Gebietsschema separat auszuwählen. Diese Komponente akzeptiert die folgenden Eigenschaften:

  • className: Zusätzliche Klassennamen für die Komponente (PropTypes.string)
  • containerStyle: Zusätzliche Klassennamen für den Komponentencontainer (PropTypes.string)
  • localeId - ID des Elements für Gebietsschemaauswahl (PropTypes.string)
  • languageId - ID des Elements für Sprachauswahl (PropTypes.string)
  • localeValue: Ausgewähltes Gebietsschema (PropTypes.string)
  • languageValue: Ausgewählte Sprache (PropTypes.string)
  • languageLabelText: Meldungsschlüssel für die Sprachbeschriftung (intlMessageShape)
  • localeLabelText: Meldungsschlüssel für die Gebietsschemabeschriftung (intlMessageShape)
  • availableLanguageValues: Zur Auswahl stehende Sprachen (PropTypes.arrayOf(PropTypes.string))
  • availableLocaleValues: Zur Auswahl stehende Gebietsschemas (PropTypes.arrayOf(PropTypes.string))
  • onLocaleValueChange: Aufgerufener Rückruf bei Gebietsschemawechsel (PropTypes.func)
  • onLanguageValueChange: Aufgerufener Rückruf bei Sprachwechsel (PropTypes.func)
  • renderLocaleLabel: render-Eigenschaft zum Anzeigen des Gebietsschemas in den Optionen (PropTypes.func)
  • renderLanguageLabel: render-Eigenschaft zum Anzeigen der Sprache in den Optionen (PropTypes.func)
  • showLocaleLabel: Flag zum Ein- oder Ausblenden der Gebietsschemabeschriftung (PropTypes.bool)
  • showLanguageLabel: Flag zum Ein- oder Ausblenden der Sprachbeschriftung (PropTypes.bool)
  • showLocaleSelect: Flag zum Ein- oder Ausblenden der Gebietsschemaauswahl (PropTypes.bool)
  • showLanguageSelect: Flag zum Ein- oder Ausblenden der Sprachauswahl (PropTypes.bool)
  • readOnly: Bei „true“ sind die Dropdown-Listen schreibgeschützt und werden im Storybook-Modus ignoriert. (PropTypes.bool)
  • skipPropagation: Bei „true“ wird die Konfiguration bei einer Wertänderung nicht aktualisiert und GlobalizationChooser wird zu einer kontrollierten Komponente. (PropTypes.bool)

LanguageSelector-Komponente​

Diese Komponente zeigt nur ein Sprachauswahlmenü an. Der ausgewählte Sprachwert wird auch zum Festlegen des Gebietsschemas verwendet. Die Auswahl ist nicht persistent in localStorage.

Note:

Die @jutro/router Abhängigkeit und ihre Peer-Abhängigkeiten wie history und react-router-dom sind jetzt optional für Komponentenpakete. Allerdings erfordert LanguageSelector die Komponente, dass die Abhängigkeit zu Ihren App-Abhängigkeiten hinzuzufügen, um verwendet werden zu können.

Wie wird in Jutro bestimmt, welche Sprache und welches Gebietsschema verwendet wird​

Wenn ein Benutzer eine Jutro-App lädt, geschieht Folgendes:

  • Die Anwendung liest die Spracheinstellung des Browsers (navigator.language)
  • Die Sprache der Anwendung wird standardmäßig an die Browsereinstellung des Benutzers angepasst, wenn diese Einstellung auch in availableLanguages enthalten ist, andernfalls wird sie auf preferredLanguage festgelegt.
  • Die Spracheinstellung des Browsers des Benutzers wird auch für das Gebietsschema der Anwendung übernommen, wenn diese Einstellung auch in availableLocales enthalten ist, andernfalls wird der Standardwert preferredLocale verwendet.

Wenn die Funktion createG11nLocalStorageStore verwendet wird, werden auch die Präferenzen des Benutzers in localStorage gespeichert und sitzungsübergreifend gespeichert.

Important: Jutro liest nicht die HTTP-accept-language-Kopfzeile. Stattdessen liest das JS auf der Clientseite die navigator.language-Eigenschaft.

Während accept-language zwar eine sortierte Liste von Voreinstellungen enthalten kann, enthält navigator.language jedoch nur einen Wert. Der erste Wert in accept-language ist derselbe wie der einzelne Wert in navigator.language.

Interaktion mit dem g11n- Speicher​

Der Globalisierungsspeicher (g11n) ist in der Datei src/startApp.js aktiviert. Standardmäßig wird es mit Gebietsschemaeinstellungen aus src/config/config.json initialisiert. Weitere Informationen finden Sie im Abschnitt zur Konfiguration.

Den Speicher können Sie mit einer der folgenden Funktionen initialisieren:

  • createG11nMemoryStore - Verwaltet die Gebietsschemaeinstellungen im Arbeitsspeicher. Dieser Speicher ist standardmäßig festgelegt. Das bedeutet, dass Änderungen am Speicher zurückgesetzt werden, wenn die Seite aktualisiert wird und wieder zur Konfiguration gewechselt wird.
  • createG11nLocalStorageStore - Verwaltet Gebietsschemaeinstellungen im lokalen Speicher, sodass die Einstellungen des Benutzers sitzungsübergreifend gespeichert werden. Weitere Informationen finden Sie im Abschnitt über das Beibehalten von Benutzerauswahloptionen.

Bei Verwendung einer dieser Funktionen können Sie die Standardeinstellungen überschreiben, indem Sie ein Objekt mit den folgenden Eigenschaften übergeben:

src/startApp.js
const g11nStore = createG11nMemoryStore({
  country: 'PL',
  currency: 'PLN',
  language: 'pl',
  locale: 'pl-PL',
  locales: ['en-GB', 'pl-PL'],
  timeZone: 'Europe/Warsaw',
  languages: ['en', 'pl'],
});

Dann müssen Sie den Speicher an die Funktion startApp übergeben:

src/startApp.js
startApp({
  g11nStore,
  // ... other settings
});

Reagieren auf Gebietsschemaänderungen​

Wenn Sie auf Gebietsschema- und Sprachänderungen in der React-Anwendung reagieren möchten, können Sie LocaleContext und den useLanguage-Hook verwenden. Hier ein Beispiel:

import { useContext } from 'react';
import { useLanguage, LocaleContext } from '@jutro/locale';

const MyPanel = () => {
  const {
    availableLocales,
    dateLocale,
    locale,
    defaultTimeZone,
    localeOnChangeCallback,
  } = useContext(LocaleContext);
  const { availableLanguages, language, languageOnChangeCallback } =
    useLanguage();

  return <div>Functionality coming soon, I promise!</div>;
};

Sie können localeOnChangeCallback und languageOnChangeCallback verwenden, um eine Änderung des Gebietsschemas oder der Sprache zu erzwingen. Sie können sie beispielsweise in Schaltflächenklick-Handlern verwenden:

return (
  <>
    <button onClick={() => languageOnChangeCallback('lang')}>
      Change language to "lang"
    </button>
    <button onClick={() => localeOnChangeCallback('loc')}>
      Change locale to "loc"
    </button>
  </>
);

Interaktion mit dem Speicher außerhalb des React-Baums​

Wenn Sie auf den Speicher außerhalb des React-Baums zugreifen möchten, können Sie eine der createG11n*Store-Funktionen in der src/startApp.js-Datei verwenden.

Wann immer der Benutzer eine der Gebietsschemaeinstellungen ändert, wird der Speicher aktualisiert. Sie können diese Änderungen abonnieren, indem Sie subscribe aufrufen und eine Rückruffunktion übergeben. Dieser Rückruf wird immer dann aufgerufen, wenn sich die Gebietsschemaeinstellungen ändern.

src/startApp.js
import { createG11nMemoryStore } from '@jutro/locale';
import { loadConfiguration } from '@jutro/config';
import appConfig from './config/config.json';

// load the configuration from the config.json file
// because globalization store gets defaults from this config
loadConfiguration(appConfig);

// create a store that will save changes in memory
const g11nStore = createG11nMemoryStore({});

// subscribe to all changes
g11nStore.subscribe((state) => {
  console.log('G11n store changed', state);
});

// subscribe to language changes specifically
g11nStore.subscribe(
  (state) => state.language,
  (language) => {
    console.log('Language changed to: ', language);

    window.location.reload();
  }
);

export const startApp = () => {
  start(Jutro, {
    // pass your new local store here
    g11nStore,
    // ... other options
  });
};

Persistente Speicherung der Benutzerauswahl​

Zum persistenten Speichern der Auswahl des Benutzers können Sie die Funktion createG11nLocalStorageStore von jutro-locale verwenden. Über diese Funktion werden die Gebietsschemaeinstellungen in localStorage automatisch aktualisiert.

  1. Erstellen Sie einen Speicher mit createG11nLocalStorageStore. Dieser Speicher speichert Änderungen im lokalen Speicher des Browsers. Im nachstehenden Beispiel nennen wir diesen Speicher g11nStore.
  2. Übergeben Sie g11nStore an die Startfunktion der Anwendung.
src/startApp.js
import { createG11nLocalStorageStore } from '@jutro/locale';
import { loadConfiguration } from '@jutro/config';
import appConfig from './config/config.json';

// load the configuration from the config.json file
// because globalization store gets defaults from this config
loadConfiguration(appConfig);

// create a store that will save changes in the browser's local store
const g11nStore = createG11nLocalStorageStore({
  name: 'unique-store-name',
});

export const startApp = () => {
  start(Jutro, {
    // pass your new local store here
    g11nStore,
    // ... other options
  });
};

Markieren von Meldungen, die eine Übersetzung erfordern​

Das ist etwas, was Entwickler immer tun sollten.

Siehe auch:

Für in JSX definierte Komponenten​

Importieren Sie die Funktion defineMessages von @jutro/locale, um Zeichenfolgen für die Übersetzung zu definieren.

Legen Sie diese in einer Datei ab, die Ihrer Komponente entspricht (z. B. MyPage.messages.js), und exportieren Sie sie:

import { defineMessages } from '@jutro/locale';

export default defineMessages({
  clickMe: {
    id: 'jutro-app.pages.myPage.clickMe',
    defaultMessage: 'Click me!',
    description: 'Action message',
  },
  thanks: {
    id: 'pages.myPage.thanks',
    defaultMessage: 'Thanks for clicking me!',
    description: 'Result message that appears when user clicks a button',
  },
});

Importieren Sie die Nachrichten in die entsprechende Datei .js und referenzieren Sie sie:

import { TranslatorContext } from '@jutro/locale';
import messages from './MyPage.messages';
...
const translator = useContext(TranslatorContext);
...
const handleClick = () => {
    // eslint-disable-next-line no-alert
    alert(translator(messages.thanks));
};
...
<Button onClick={handleClick}>
    {translator(messages.clickMe)}
</Button>

Auch wenn useContext(TranslatorContext) weiterhin verwendet werden kann, empfiehlt es sich, zu useTranslator() zu wechseln. useTranslator verfügt über eine zusätzliche Funktion, die prüft, ob der Kontextwert gültig ist, und Sie darüber informiert, wenn dies nicht der Fall ist. Die entsprechende Zeile in Ihrer .js-Datei sieht folgendermaßen aus:

...
const translator = useTranslator();
...
Warum eine separate Datei für JSX-Meldungen verwenden?​

Es ist nicht erforderlich, aber es ist sauberer. (Im Idealfall würde man etwas Ähnliches auch für JSON5-basierte Zeichenfolgen tun. Zum jetzigen Zeitpunkt ist dies jedoch nicht möglich. In Metadaten-/JSON5-Dateien müssen Zeichenfolgen direkt darin deklariert werden.)

Wenn Zeichenfolgen stärker vom Code isoliert sind, ist es einfacher, diese zu ändern, und das Risiko von Fehlern ist geringer.

Verwendung der Syntax MessageFormat für formatierte Argumente​

Hinweis: Weitere Informationen finden Sie unter Variablen-Interpolation.

react-intl (insbesondere intl-messageformat) unterstützt die Syntax MessageFormat von ICU4J. Anstatt eine Variable / ein Argument einfach in eine Zeichenfolge einzubetten, können Sie mit der Syntax MessageFormat auch den Typ und den Formatierungsstil eines Arguments deklarieren.

Beispiele:

  • Your premium is due on {someDate, date}
    • Formatiert someDate in einem kurzen Stil (im Allgemeinen keine gute Idee – das Format ist zweideutig)
  • Your premium is due on {someDate, date, long}
    • Formatiert someDate im Stil von long, wie bei en-US: February 17, 2019
  • You've had {numClaims, number} on this policy
    • Formatiert numClaims als Zahl. Das heißt, es werden dem Gebietsschema entsprechende Dezimal- und Gruppierungstrennzeichen verwendet
  • Your premium will increase by {somePercent, number, percent}
    • Formatiert somePercent als Prozentzeichenfolge

Siehe https://formatjs.io/docs/core-concepts/icu-syntax/#formatted-argument für weitere Informationen.

MessageSyntax und Währungsargumente​

Zum Formatieren von Währungen mit MessageFormat verwenden Sie diese Syntax:

Your next payment is for {someAmount, number, :: currency/EUR}.

Das Problem hierbei ist, dass Ihre Zeichenfolge die Währung deklariert - und Sie müssen die Währung daher im Voraus kennen. Dies funktioniert nur für Anwendungen, die nur eine einzige Währung verwenden

Verarbeitung von übersetzbarem UI-Text​

Nachdem der Benutzeroberflächentext ordnungsgemäß im Code markiert wurde, muss der Text extrahiert und in einer Datei zusammengeführt werden. Diese Datei kann dann übersetzt werden.

i18n-Skript​

In der Datei package.json Ihrer Anwendung befindet sich das Skript i18n. Dieses Skript führt jutro generate:i18n aus. Standardmäßig geschieht Folgendes:

  • Ordnungsgemäß markierter Text wird aus Dateien extrahiert, die folgenden Mustern entsprechen: src/**/*.metadata.json5, src/**/*.{ts,tsx,js,jsx}
    • Der Text wird in das temporäre Verzeichnis ./i18n/src/ extrahiert
  • Führt den gesamten Text der Benutzeroberfläche aus den verschiedenen Dateien in ./i18n/src zusammen in ./src/i18n/lang.json
  • Die src/i18n/lang.json-Datei ist pseudoübersetzt in src/i18n/yy.json. Dies wird im Folgenden näher erläutert
Optionen im Befehl generate:i18n​
  • --pseudoInputFile <pseudoInputFile>. Definiert eine benutzerdefinierte Pseudo-Eingabedatei. Der Standardwert ist src/i18n/lang.json.
  • --jsxFileNamePattern <jsxFileNamePattern>. Definiert das Dateinamensmuster der JSX-Dateien. Der Standardwert ist src/**/*.{ts,tsx,js,jsx}.
  • --metadataFileNamePattern <metadataFileNamePattern>. Definiert das Dateinamensmuster der JSON-Metadatendateien. Der Standardwert ist src/**/*.metadata.json5.
  • --translationOutputDir <translationOutputDir>. Definiert, wo die Ausgabemeldungen, die Standardübersetzungen und extrahierte Übersetzungen enthalten, gespeichert werden. Der Standardwert ist src/i18n.
  • --pseudoType <pseudoType>. Dadurch wird der zu verwendende Pseudotyp definiert. Kann einer von ['expansion', 'sherlock', 'both'] sein. Der Standardwert ist „sherlock“.
  • --fileNameIgnorePattern <fileNameIgnorePattern>. Dies ist die durch Kommas getrennte Liste von Dateinamensmustern, die ignoriert werden sollen. Der Standardwert ist **/__mocks__/**,**/__local_mocks__/**,**/basic.metadata.schema.json,**/dist/**,**/node_modules/**,**/generated/**.
  • --jsxMessageOutputPath <jsxMessageOutputPath>. Definiert das Ausgabeverzeichnis für die extrahierten JSX- Meldungen. Der Standardwert ist i18n/src/js-jsx-strings.json.
  • --mergeBizCompOutputDir <mergeBizCompOutputDir>. Definiert den Ausgabedateinamen der zusammengeführten Übersetzungen. Der Standardwert ist i18n/biz-comp-translations.
  • --messagesFileNamePattern <messagesFileNamePattern>. Definiert, wo die extrahierten Meldungen gespeichert werden. Der Standardwert ist i18n/src/**/*.json.
  • --metadataMessageOutputDir <metadataMessageOutputDir>. Definiert das Ausgabeverzeichnis für die extrahierten Metadatenmeldungen. Der Standardwert ist i18n.
  • --pseudoOutputFileName <pseudoOutputFileName>. Damit wird die Vorlage für den Ausgabedateinamen definiert. Der Standardwert ist yy.json.
  • --translationFileName <translationFileName>. Definiert den Ausgabedateinamen der zusammengeführten Übersetzungen. Der Standardwert ist en.

Sicherstellen, dass alle Zeichenfolgen extrahiert werden​

Entwickler lassen Zeichenfolgen oft fest kodiert/in Anwendungen eingebettet, was eine Übersetzung unmöglich macht. In diesem Sinne haben wir die Sherlock-Sprache.

„Sherlock“: Die / Mock- / Fake- / Pseudosprache​

Worum handelt es sich​

Es handelt sich um eine automatisch generierte Sprache, Codeless Form die Zeichenfolgen von z. B. in [2zqq25_Codeless Form] konvertiert. Dies ist in der Standardkonfiguration der Beispiel-Anwendung enthalten.

Unsere Standardkonfiguration enthält yy in availableLanguages. Dies führt dazu, dass „Sherlock“ im Sprachmenü der GlobalizationChooser Komponente angezeigt wird. Streng genommen ist in der realen Welt yy kein gültiger Sprachcode. Unsere Software ordnet diesen Sprachcode jedoch unserer eigenen „Sherlock“-Scheinsprache zu. Es sollte aus den Produktionskonfigurationen entfernt werden.

Welcher Wert wird bereitgestellt​
  • Jede Zeichenfolge, die ohne die umgebenden eckigen Klammern und den vorangestellten Hash angezeigt wird, wurde nicht ordnungsgemäß extrahiert. Dies bedeutet, dass es einen Fehler in Ihrem Code gibt. Kundendatenzeichenfolgen werden natürlich normal angezeigt
  • Der Hash selbst: Auch wenn er zufällig erscheinen mag, ist er für jedes Schlüssel-Wert-Paar eindeutig.

UI-Zeichenfolgen und Live-Vorschau​

Wenn Sie Ihre Anwendung mit npm startstarten, wechselt sie in den Modus „Live-Vorschau“. Das bedeutet, dass Änderungen, die Sie an Ihrem Code vornehmen, sofort in Ihrem Browser angezeigt werden.

Leider werden Änderungen an bestehenden Quelltextzeichenfolgen in der Live-Vorschau nicht aktualisiert. Man muss den Extrahieren-Zusammenführen-Pseudo-Zyklus über npm run i18n erneut ausführen. Beim erneuten Erstellen der Anwendung wird dieses Skript ebenfalls aufgerufen.

Übersetzen der Anwendung​

Die Standardausgangssprache ist Englisch, mit dem Sprachcode en.

Standardmäßig befinden sich diese Zeichenfolgen gemäß der Beispiel-App in der Datei ./src/i18n/lang.json. Diese Datei wird in .gitignore hinzugefügt. Übersetzer sollten stattdessen die Datei kopieren und entsprechend der Sprache umbenennen, z. B. en.json, de.json usw.

Bedenken Sie auch, dass nur npm run i18n (oder build) garantieren kann, dass alle Strings aus dem Code extrahiert werden und in dieser Datei zusammengeführt werden.

Die Übersetzungen sollten im gleichen Verzeichnis wie die Datei lang.json hinzugefügt werden.

UI-Text aus dem Jutro-Framework​

Wie jedes UI-Framework verfügt auch Jutro über einen gewissen UI-Text, der von Ihrer Anwendung getrennt ist. Ihre Anwendung wird wahrscheinlich zumindest einen Teil dieses Textes verfügbar machen. Dieser Text umfasst Zeichenfolgen wie „Ok“, „Next“, „Cancel“ und „Submit“. Komponenten, die solchen Text verfügbar machen, ermöglichen es Ihnen häufig, den Standardtext zu überschreiben. Bei einigen ist dies jedoch nicht der Fall – z. B. bei der Liste der Länder, aus denen in der IntlPhoneNumberField-Komponente ausgewählt werden soll.

Neben der Basissprache Englisch (US) ist der Framework-Text in die folgenden Sprachen übersetzt: Dänisch, Deutsch, Spanisch (Spanien), Spanisch (USA), Französisch, Italienisch, Japanisch, Niederländisch, Norwegisch, Portugiesisch, Russisch und Vereinfachtes Chinesisch.

Möglicherweise ist dies für Sie nicht ausreichend.

Überschreiben von Framework- Zeichenfolgen oder Bereitstellen eigener Übersetzungen​

Folgende Szenarios sind denkbar:

  • Sie möchten den Standardtext ändern, der von unseren Komponenten verwendet wird
  • Sie möchten einige der von uns gelieferten Übersetzungen ändern
  • Sie möchten das Framework in eine andere als die unterstützten Sprachen übersetzen.

So gehen Sie vor:

  1. Erstellen Sie unter ./src eine framework.messages.js-Datei, entsprechend der Beschreibung hier.
  2. Kopieren Sie die Liste der Framework-Quellzeichenfolgen von node_modules/@jutro/translations/lang-data/en.json.
  3. Fügen Sie in der framework.messages.js oben erstellten alle (oder nur einige) dieser Rahmenzeichenfolgen hinzu - mit der Paarform id und defaultMessage. Wenn Sie das defaultMessage für eine bestimmte Zeichenfolge ändern möchten, tun Sie dies hier
  4. Nach der Neuerstellung können Sie sehen, dass diese Zeichenfolgen nun in der Datei ./src/i18n/lang.json hinzugefügt wurden.
  5. Nun können Sie die Framework-Zeichenfolgen wie die Zeichenfolgen der Anwendung übersetzen.

Gebietsschemabezogene Komponenten​

Elemente wie die Anzeige, Formatierung von Datumsangaben, Uhrzeiten, Zahlen, Kalendern, Geldbeträgen und Prozentsätzen variieren je nach Gebietsschema. Jutro bietet verschiedene Komponenten, die das Gebietsschema des Benutzers berücksichtigen.

Daten, Zeiten, Kalender​

Jutro bietet eine Vielzahl von Datums-, Zeit- und Kalenderoptionen.

Komponenten​

Alle sind unter @jutro/components verfügbar.

DateField: Rendert ein Datumsauswahl-Eingabeelement. Verfügt über eine Schreibschutzoption und bietet volle Unterstützung für die Auswahl und Eingabe von Datum und Uhrzeit sowie einen schreibgeschützten Modus.

FormattedDate: Rendert ein formatiertes Datum inline (no <div>). Unterstützt eine Reihe vordefinierter Formate:

Gebietsschemashortlongabbreviatedfull
en-USAug 30, 2018August 30, 2018Thu, Aug 30, 2018Thursday, August 30, 2018
fr-FR30 août 201830 août 2018jeu. 30 août 2018jeudi 30 août 2018
pl-PL30 sie 201830 sierpnia 2018czw., 30 sierpnia 2018czwartek, 30 sierpnia 2018

DateValue: Rendert ein formatiertes Datum und verwendet die Eigenschaft tag, um den Wert zu umschließen.

FormattedDateRange: Ähnlich wie FormattedDate, nur für einen Datumsbereich und nicht für ein einzelnes Datum.

Alle werden in einer an das Gebietsschema angepassten Form präsentiert.

APIs​

Verfügbar über @jutro/components

formatDate und formatDateRange: Zwingende APIs für die Formatierung von Datums- und Zeitangaben unter Verwendung des aktuellen Gebietsschemas

Zahlen (keine Geldbeträge)​

Komponenten​

Verfügbar über @jutro/components

InputNumberField: Rendert ein Eingabeelement für Zahlenfelder. Verfügt auch über eine schreibgeschützte Option.

FormattedNumber: Bietet Inline-Unterstützung mit Schreibschutz.

NumberValue: Rendert eine formatierte Währung und verwendet die Eigenschaft tag, um den Wert zu umschließen.

GebietsschemaFormatierte Ausgabe
en-US23,234.34
fr-FR23 234,34
de-DE23.234,34

APIs​

Verfügbar über @jutro/components

formatNumber: Zwingende API für die Formatierung von Zahlen unter Verwendung des aktuellen Gebietsschemas

Geldbeträge​

Komponenten​

Verfügbar über @jutro/components

CurrencyInput: Verwenden Sie diese Option, um einen Geldwert einzugeben oder anzuzeigen. Die Formatierung basiert auf dem Gebietsschema. Unterstützt den Eingabe- und den schreibgeschützten Modus.

FormattedCurrency: Zeigt einen formatierten Währungswert inline an. (kein <div>).

CurrencyValue: Rendert eine formatierte Währung und verwendet die Eigenschaft tag, um den Wert zu umschließen.

Mit den oben genannten Komponenten können Sie die Eigenschaft currencyDisplay festlegen. Wenn Sie für einen Betrag in US-Dollar im Gebietsschema en-US die Eigenschaft currencyDisplay auf code setzen, erhalten Sie USD; wenn Sie sie auf symbol setzen, erhalten Sie $.

Die Währung selbst (z. B. USD, EUR) wird als Eigenschaft der Komponente bereitgestellt und ist völlig unabhängig vom Gebietsschema und Land des Benutzers.

Das Gebietsschema bestimmt, wie der Währungsbetrag formatiert wird, aber nicht die Währung selbst.

GebietsschemaFormatierte Ausgabe (code)Formatierte Ausgabe (symbol)
en-USUSD 23.234.3423.234,34 $
fr-FR23 234,34 USD23 234,34 $US
de-DE23.234,34 USD23.234,34 $

APIs​

Verfügbar über @jutro/components

formatCurrency: Zwingende API für die Formatierung von Währungswerten unter Verwendung des aktuellen Gebietsschemas

Es gibt keine globale defaultCurrency-Einstellung für währungsbezogene Komponenten.

Das bedeutet, dass Sie die Währung oder die Standardwährung, die verwendet werden soll, an die währungsbezogenen Komponenten CurrencyInput, FormattedCurrency und CurrencyValue übergeben müssen:

<CurrencyInput
  availableCurrencies={['USD']}
  label="Currency input component"
/>

Im Fall von CurrencyValue wird standardmäßig US-Dollar oder USD als Komponente verwendet, wenn defaultCurrency nicht gesetzt ist Sie können diesen Wert auch durch Aufrufen der Funktion getDefaultCurrency aus dem Jutro-Gebietsschemapaket abrufen und dann an die entsprechende Komponente übergeben.

import { getDefaultCurrency } from '@jutro/locale';

Sortierung / Zusammenstellung​

Die Textsortierung (Sortierung) ist sprachspezifisch. Jede Sprache hat ihre eigenen Kollationsregeln.

Zeitzone​

Standardmäßig werden alle Daten mit Uhrzeit in UTC-Zeit gespeichert und bei der Anzeige in die lokale Zeitzone des Benutzers konvertiert. Sie können dies durch Festlegen von defaultTimeZone in localeSettings unter src/config/config.json überschreiben.

"localeSettings": {
    ...
    "defaultTimeZone": "Atlantic/Faroe"
}

Wenn defaultTimeZone gesetzt ist, werden alle Datumsangaben mit Uhrzeit bei der Anzeige in die Zeitzone defaultTimeZone konvertiert (aber weiterhin als UTC-Datum gespeichert). Die einzige Ausnahme ist die Komponente DateTimeZoneField, bei der der Benutzer eine Zeitzone aus der Liste auswählen kann. In diesem Fall wird defaultTimeZone als Standardzeitzone verwendet.

Der Wert von defaultTimeZone muss eine gültige IANA-Zeitzone sein.

Substantive im Plural im UI-Text​

Substantive im Plural sind ein kniffliges linguistisches Problem, das in Jutro durch Verwendung der react-intl-Bibliothek gelöst wird.

Sehen Sie sich diesen Pseudo-Code an:

if (numPolicies === 1) print('You have 1 policy with us');
else print('You have {numPolicies} policies with us');

Dieser Code ist für Englisch geeignet, lässt sich aber für viele andere Sprachen nicht anwenden.

Viele Sprachen haben viel komplexere Regeln für Substantive im Plural. Sogar im Französischen gelten andere Regeln als im Englischen. (Im Französischen wird der Singular verwendet, wenn die Menge 1 oder 0 ist).

Einige Sprachen haben drei (Polnisch), vier (Russisch) oder sogar sechs (Arabisch) Pluralformen – alle abhängig vom Wert der Ganzzahl, deren Wert nur zur Laufzeit bekannt sein kann. Auf dieser Seite wird die mathematische Logik rund um den Plural für viele Sprachen erfasst.

Unterstützung der Pluralbildung in Jutro​

Informationen finden Sie in der Dokumentation unter FormatJS und im ICU MessageFormat Syntax Guide.

Notiz:

  • Die Pluralsyntax ist nicht unbedingt intuitiv – weder für Entwickler noch für Übersetzer.
  • Stellen Sie bei der Übersetzung sicher, dass die Syntax in Ihren Übersetzungstools und von Ihren Übersetzungsanbietern beherrscht und unterstützt wird.