Ein Betrag, der sich beim Ändern der Sprache verändert, ein Datum, das am falschen Tag erscheint, oder eine Übersetzung, die eine Geschäftsregel verändert, weisen oft auf dasselbe Problem hin: Die Anwendung verwechselt Daten mit Darstellungsentscheidungen. Die Internationalisierung von Datumsangaben und Währungen in PHP erfordert, Sprache, Locale, Währung und Zeitzone getrennt zu behandeln und festzulegen, welchen Wert das System beibehält und welche Darstellung die einzelnen Nutzer sehen.
Diese Trennung erleichtert es, weitere Regionen zu unterstützen, ohne Geschäftsregeln zu duplizieren oder historische Daten neu zu interpretieren. Außerdem hilft sie dabei, die Ursache von Fehlern einzugrenzen: Sie kann bei der Nutzereingabe, der Speicherung, einer Zeitzonenumrechnung oder ausschließlich beim Ausgabeformat liegen.
Sprache, Locale, Währung und Zeitzone sind unterschiedliche Entscheidungen
Die Sprache bestimmt den Text der Benutzeroberfläche und übersetzbare Inhalte, etwa Beschriftungen, Validierungsmeldungen und Produktnamen. Ein Locale beziehungsweise eine Regionaleinstellung legt Darstellungskonventionen fest, beispielsweise Dezimaltrennzeichen, Datumsreihenfolge und Monatsnamen. Es ist nicht immer mit einer Sprache gleichzusetzen: Zwei Regionen mit derselben Sprache können unterschiedliche Formate verwenden.
Die Währung bezeichnet die Einheit, in der ein Betrag angegeben wird, etwa EUR oder JPY. Sie lässt sich nicht zuverlässig aus der Sprache oder dem Locale ableiten. Eine Person kann die Benutzeroberfläche auf Spanisch anzeigen lassen, ein bestimmtes Regionalformat verwenden und einen Kauf in einer anderen Währung tätigen. Die Zeitzone wiederum legt fest, wie lokale Uhrzeiten mit der Weltzeit und den Zeitumstellungen einer Region zusammenhängen.
Diese Präferenzen sollten explizit modelliert werden. Ein Konto kann beispielsweise eine Sprache und eine Zeitzone haben, eine Sitzung kann eine Formatpräferenz festlegen, und jede Bestellung muss die tatsächlich verwendete Währung speichern. Zulässige Werte und Standardwerte sollten Produktentscheidungen sein und nicht stillschweigend aus dem Netzwerkstandort abgeleitet werden.
Was gespeichert und was zur Anzeige berechnet werden sollte
Speichern Sie die Daten, die erforderlich sind, um den ursprünglichen Sachverhalt wiederherzustellen, und nicht nur eine bereits formatierte Zeichenfolge. Ein Erstellungsdatum bezeichnet einen Zeitpunkt; ein Format wie „03.04.2025“ ist mehrdeutig und keine geeignete kanonische Darstellung. Für globale Ereignisse ist es oft sinnvoll, den Zeitpunkt in UTC zu speichern und die relevante Zeitzone beizubehalten, wenn der Kontext davon abhängt, wie bei einem Termin, der für eine bestimmte Stadt vereinbart wurde.
In einer PHP-Anwendung hilft DateTimeImmutable, unbeabsichtigte Änderungen während der Umrechnungen zu vermeiden. Wandeln Sie den Zeitpunkt bei der Vorbereitung der Antwort in die ausgewählte Zeitzone um, ohne den gespeicherten Wert zu ersetzen. Verwenden Sie anerkannte Zeitzonenkennungen wie Europe/Madrid, statt einen festen Offset wie +01:00 zu speichern: Der Offset enthält weder historische Regeln noch saisonale Änderungen.
Bewahren Sie für das Regionalformat eine gültige Locale-Kennung entsprechend der verwendeten Bibliothek und Umgebung auf und behandeln Sie nicht unterstützte Präferenzen ausdrücklich. Funktionen aus intl wie IntlDateFormatter und NumberFormatter ermöglichen die Anwendung lokaler Konventionen, ohne Trennzeichen und Monatsnamen manuell zusammenzusetzen. Prüfen Sie, ob die Erweiterung in den Umgebungen verfügbar ist, in denen die Anwendung ausgeführt wird.
Datums- und Zeitangaben: Umrechnung und mehrdeutige Fälle
Vom System erfasste Zeitpunkte und zivile Uhrzeiten sind nicht austauschbar. Ein Zeitpunkt wie „2025-04-10T15:00:00Z“ bezeichnet einen eindeutigen Moment. „26.10.2025 um 02:30 Uhr in Europe/Madrid“ kann dagegen während der Umstellung auf die Winterzeit mehrdeutig sein, weil diese lokale Uhrzeit zweimal auftreten kann. Bei der Umstellung im Frühjahr kann es zudem lokale Uhrzeiten geben, die gar nicht auftreten.
Wenn eine Aktion für eine zukünftige lokale Uhrzeit geplant wird, sollten Sie nicht nur einen einmalig berechneten Timestamp speichern, sofern die Vereinbarung an die Ortszeit einer Region gebunden ist. Speichern Sie das angeforderte Datum und die Uhrzeit, die Zeitzone sowie eine Richtlinie für den Umgang mit nicht existierenden oder wiederholten Uhrzeiten. Die Entscheidung – ablehnen, nachfragen oder eines der Vorkommen auswählen – hängt vom Produkt ab. Bei einem bereits eingetretenen Ereignis sollte hingegen der tatsächliche Zeitpunkt erfasst werden.
Legen Sie außerdem fest, wie Datumsangaben aus Formularen und APIs interpretiert werden. Akzeptieren Sie dokumentierte Formate, validieren Sie die Zeitzone und weisen Sie mehrdeutige Eingaben zurück, statt zu erraten, ob „04/05/2025“ April oder Mai bedeutet. Zeigen Sie in Benutzeroberflächen eine gut lesbare Darstellung an, bewahren Sie aber den kanonischen Wert zum Sortieren, Vergleichen und Überprüfen auf.
Beträge: Genauigkeit, Währung und Formatierung
Das sichtbare Format darf nicht zur finanztechnischen Quelle der Wahrheit werden. Vermeiden Sie binäre Gleitkommazahlen für Geldberechnungen: Bestimmte Dezimalbrüche lassen sich nicht exakt darstellen und können Rundungsfehler verursachen. Eine verbreitete Strategie ist es, Beträge als ganze Zahlen in Untereinheiten zusammen mit dem Währungscode zu speichern. Allerdings verwenden nicht alle Währungen zwei Dezimalstellen, und manche Berechnungen erfordern eine höhere Zwischengenauigkeit als der letztlich belastete Betrag.
Legen Sie Genauigkeit und Zeitpunkt der Rundung entsprechend den Regeln des Fachbereichs fest: pro Position, pro Steuer oder für die Gesamtsumme. Führen Sie die Währung bei Bestellungen, Zahlungen, Erstattungen und Berechnungen explizit mit; interpretieren Sie eine Zahl nicht, ohne zu wissen, zu welcher Währung sie gehört. Wenn Sie Währungen umrechnen, bewahren Sie außerdem die erforderlichen Angaben zur Erklärung der Umrechnung auf, etwa den verwendeten Wechselkurs und den Bezugszeitpunkt, sofern diese für den Vorgang relevant sind.
Übergeben Sie zur Anzeige des Betrags den Zahlenwert und den Währungscode an den passenden regionalen Formatierer. Die Darstellung kann sich bei Symbolen, Reihenfolge und Trennzeichen unterscheiden. Nutzer sollten die Währung erkennen können, ohne sich auf ein möglicherweise mehrdeutiges Symbol verlassen zu müssen. Analysieren Sie eine lokalisierte Zeichenfolge nicht so, als wäre sie eine universelle Zahl: Validieren Sie die Eingabe und wandeln Sie sie vor der Verarbeitung in eine kontrollierte numerische Darstellung um.
Inhalte übersetzen, ohne Geschäftsregeln zu duplizieren
Übersetzen Sie Texte und passen Sie Formate an, halten Sie jedoch die Regeln für Preise, Steuern, Anspruchsberechtigungen, Berechtigungen oder Status zentral. Eine nach Sprache duplizierte Logik erzeugt abweichendes Verhalten, das sich nur schwer erkennen lässt. Die Wahl eines Tarifs kann vom Markt, vom Vertrag oder von einer Geschäftspolitik abhängen; sie sollte sich nicht allein deshalb ändern, weil sich eine Beschriftung in der Benutzeroberfläche geändert hat.
Trennen Sie Übersetzungskataloge von der Domänenlogik. Legen Sie bei bearbeitbaren und lokalisierten Inhalten fest, welche Versionen existieren können, wie fehlende Versionen behandelt werden und welches Fallback-Verhalten gilt. Ein übersetzter Name sollte keinen stabilen Bezeichner ersetzen. Dokumentieren Sie bei APIs, ob die Felder kanonische Werte, lokalisierte Inhalte oder bereits für die Anzeige vorbereitete Formate enthalten.
Tests und schrittweiser Rollout regionaler Unterstützung
Testen Sie die Entscheidungen auf mehreren Ebenen. Unit-Tests sollten Zeitzonenumrechnungen, Datumsvalidierung, Rundung und Betragsformatierung prüfen. Berücksichtigen Sie Grenzfälle am Tageswechsel, saisonale Zeitumstellungen, wiederholte oder nicht existierende Uhrzeiten, Monate unterschiedlicher Länge und Währungen mit unterschiedlicher Genauigkeit. Verlassen Sie sich nicht auf die Standard-Locale oder -Zeitzone der Testmaschine: Konfigurieren Sie beide explizit.
Integrationstests sollten bestätigen, dass die API kanonische Daten speichert und die Benutzeroberfläche diese entsprechend den vereinbarten Präferenzen darstellt. Prüfen Sie auch fehlerhafte Eingaben, unbekannte Locales, Änderungen der Präferenzen und das Fehlen der erforderlichen Erweiterung. Werden Zeitzonendatenbanken aktualisiert, überprüfen Sie die Prozesse zur Planung zukünftiger Ereignisse und die erwarteten Ergebnisse.
Führen Sie die Unterstützung für Regionen schrittweise ein: Legen Sie zunächst Daten und Regeln fest, testen Sie anschließend Formate und vollständige Abläufe und aktivieren Sie schließlich das Erlebnis für die vorgesehene Zielgruppe. Die Überwachung von Validierungsfehlern, Rundungsabweichungen und außerhalb der vorgesehenen Zeiten ausgeführten Aufgaben hilft dabei, Fehler zu erkennen, die auf einem Screenshot nicht sichtbar sind.
Checkliste
- Sprache: Ist sie vom Locale getrennt und gibt es eine Fallback-Regel?
- Datumsangaben: Wird zwischen einem Zeitpunkt und einer geplanten lokalen Uhrzeit unterschieden?
- Zeitzone: Werden regionale Kennungen gespeichert und mehrdeutige Uhrzeiten korrekt behandelt?
- Beträge: Hat jeder Betrag eine explizite Währung und sind die Genauigkeitsregeln festgelegt?
- Darstellung: Wird mit geeigneten Werkzeugen formatiert und wird der sichtbare Text niemals für Berechnungen verwendet?
- Tests: Werden Tagesgrenzen, Zeitumstellungen, ungültige Eingaben und unterschiedliche Präferenzen abgedeckt?
- Betrieb: Wird die PHP-Konfiguration überprüft und die regionale Unterstützung kontrolliert bereitgestellt?
Entscheidend ist eine klare Grenze zwischen den Daten, die das System versteht, und der Darstellung, die einzelne Personen sehen. Mit dieser Grenze wird die Internationalisierung von Datumsangaben und Währungen in PHP zu einer Reihe überprüfbarer Regeln statt zu einer Sammlung von Ausnahmen, die über die Anwendung verteilt sind.
