Zum Inhalt springen

Mehrsprachige Oberflächen mit einem konkreten Vorgang planen

Ein Portalbeispiel zeigt, wie Sie lange Texte, lokale Zahl- und Datumsformate sowie fehlende Übersetzungen für einen Sprachwechsel planen.

Julia Hoffmann2 Min. Lesezeit
Smartphone mit blauem Kopfbereich, zwei unterschiedlich breiten Feldern und gegenläufigen Pfeilen.

Mit einem unveränderten Datensatz beginnen

Planen Sie eine mehrsprachige Oberfläche an einer vollständigen Aufgabe: einen Antrag öffnen, prüfen und freigeben. Dabei müssen Texte verständlich bleiben und Geschäftsdaten ihre Bedeutung behalten. Eine Liste übersetzter Schaltflächen zeigt diese Zusammenhänge noch nicht.

Ein fiktives Projektportal soll zehn Sprachen unterstützen. Der Antrag R-18 enthält den numerischen Betrag 1234.5, die Währung EUR und das Kalenderdatum 2026-11-12. Bei diesem Vorgang bleiben Währung, Betrag, Termin und Freigabestatus beim Sprachwechsel unverändert. Eine englische Oberfläche macht daraus keinen Dollarbetrag.

Anzeigeformate ausdrücklich festlegen

Das Team wählt für den Vergleich diese drei Locales, also Sprach- und Regionsvarianten. Der Betrag wird als Währung mit zwei Nachkommastellen dargestellt, das Datum mit zweistelligem Tag und Monat sowie vollständigem Jahr. Für den Datumsvergleich ist die Zeitzone UTC festgelegt.

Locale

Betrag in der Anzeige

Datum in der Anzeige

de-DE

1.234,50 €

12.11.2026

en-GB

€1,234.50

12/11/2026

tr-TR

€1.234,50

12.11.2026

Intl.NumberFormat und Intl.DateTimeFormat unterstützen solche sprachabhängigen Anzeigen. Locale und Optionen werden ausdrücklich gewählt; die Rechner-Voreinstellung soll den Vergleich nicht unbemerkt verändern. Ein reines Kalenderdatum darf beim Sprachwechsel nicht auf einen anderen Tag rutschen. Falls Personen einen Betrag eingeben, braucht das zusätzlich passende Eingabe- und Prüfregeln: Ein formatierter Ausgabetext definiert noch keinen sicheren Eingabeparser.

Lange Texte und fehlende Zustände einplanen

Prüfen Sie die tatsächlichen Beschriftungen auf schmalen und breiten Ansichten. Im Beispiel soll die Schaltfläche „Projektantrag nach Prüfung freigeben“ ihre Bedeutung behalten, auch wenn eine Übersetzung mehr Raum braucht. Geplanter Umbruch oder eine andere Anordnung ist sinnvoller als eine unverständliche Abkürzung. Eine feste Vergrößerungsquote garantiert keine passende Darstellung für jeden Text.

Zum Sprachbestand gehören auch leere Listen, Ladezustände und Fehlermeldungen. Fehlt im Beispiel die Übersetzung für approval.confirm, sperrt das Portal die Freigabe und zeigt einen verständlichen Hinweis in der gewählten Sprache. Eine gemischte Ersatzsprache wird für diesen kritischen Schritt nicht stillschweigend akzeptiert. Das ist die gewählte Produktregel, keine automatische Eigenschaft einer Übersetzungsbibliothek.

Den Sprachwechsel im laufenden Vorgang prüfen

Öffnen Sie denselben Antrag in jeder vorgesehenen Sprache und wechseln Sie während der Bearbeitung. Im Beispiel müssen Eingaben erhalten bleiben; der Sprachwechsel darf keine Freigabe auslösen. Prüfen Sie danach den erhaltenen Betrag, den Kalendertag und den weiterhin offenen Status.

Künstlich verlängerte Testtexte können Layoutprobleme früh sichtbar machen. Die endgültigen Übersetzungen müssen Sie dennoch im Kontext lesen und im vollständigen Vorgang prüfen. Halten Sie je Sprache fest, ob die Freigabe verständlich und ohne Datenverlust möglich ist oder welcher konkrete Zustand noch fehlt.

Quellen

Geschrieben von

  • Julia HoffmannRedakteurin für Design und UXJulia Hoffmann ist bei ASES für die redaktionellen Inhalte zu Design und User Experience zuständig. Ihre Beiträge behandeln die Nutzung von Websites und Anwendungen, die Gestaltung von Benutzeroberflächen und digitale Barrierefreiheit.

ASES folgen

Weiterlesen

Alle Beiträge

Design & UX mit ASES

Nutzererlebnis, Oberflächen und Markenauftritt