Mehrsprachiges Onboarding für ein PHP-SaaS gestalten

Ein mehrsprachiges Onboarding in einem SaaS besteht nicht nur darin, die Texte auf dem ersten Bildschirm zu übersetzen. Nutzer müssen jeden Schritt verstehen, ihre Antworten behalten und das Onboarding abschließen können, auch wenn sie die Sprache wechseln oder später zurückkehren. Dafür sollten Sie die Spracheinstellung von den Geschäftsdaten trennen und den Ablauf als Prozess mit überprüfbaren Zuständen behandeln.

Dieser Leitfaden konzentriert sich auf das Onboarding einer Organisation: Was vor dem Erstellen eines Kontos angezeigt werden sollte, was während des Vorgangs gespeichert werden muss und was getestet werden sollte, um Fehler zu erkennen. Er soll nicht die allgemeine Internationalisierungsstrategie der gesamten Anwendung festlegen.

Sprache der Benutzeroberfläche, Inhalte und Onboarding-Daten trennen

In einem Formular können drei Arten von Informationen zusammen auftreten, sie dürfen jedoch nicht auf dieselbe Weise gespeichert oder übersetzt werden:

• Sprache der Benutzeroberfläche: Sie bestimmt Bezeichnungen, Anweisungen, Validierungen und Systemmeldungen. Sie ist eine Einstellung für das Nutzungserlebnis, etwa es oder fr.
• Produktinhalte: Das sind vom Unternehmen verwaltete Texte, zum Beispiel eine Tarifbeschreibung, eine Kategorie oder eine Willkommensvorlage. Sie können eigene Übersetzungen haben und eine separate Entscheidung erfordern.
• Vom Nutzer eingegebene Daten: Dazu gehören der Name der Organisation, eine Domain oder eine Beschreibung. Sie müssen so erhalten bleiben, wie die Person sie eingegeben hat, und dürfen nicht übersetzt werden, wenn die Sprache der Benutzeroberfläche geändert wird.

Vermeiden Sie im Datenmodell ein einzelnes, mehrdeutiges Feld namens language, das verschiedene Konzepte abbildet. Eine Spracheinstellung für die Benutzeroberfläche kann preferred_locale heißen; die Sprache eines verwalteten Inhalts sollte, sofern relevant, diesem Inhalt zugeordnet sein. Der Name einer Organisation wird dagegen nicht zu einem anderen Wert, wenn die Benutzeroberfläche geändert wird.

Diese Trennung verdeutlicht auch, wie mit Auswahlfeldern umzugehen ist. Wählt der Nutzer einen Bereich aus übersetzten Optionen aus, speichern Sie eine stabile ID und nicht die sichtbare Bezeichnung. So kann die ausgewählte Option in einer anderen Sprache angezeigt werden, ohne die Geschäftsdaten zu ändern oder davon abhängig zu sein, dass eine Bezeichnung unverändert bleibt.

Sprache auswählen, bevor ein Konto existiert

Das Onboarding beginnt oft, bevor es einen authentifizierten Nutzer und eine in dessen Profil gespeicherte Einstellung gibt. Deshalb braucht das System eine ausdrückliche Anfangsregel. Es kann einen sichtbaren Selektor anbieten, die Browsersprache als Vorschlag verwenden oder beides kombinieren. Die automatische Erkennung sollte helfen, aber die Person nicht daran hindern, eine andere Option auszuwählen.

Legen Sie fest, welcher Wert Vorrang hat, wenn mehrere Hinweise vorliegen. Eine während des Onboardings ausdrücklich getroffene Auswahl sollte beispielsweise Vorrang vor einer späteren automatischen Erkennung haben. Die ausgewählte Sprache kann vorübergehend in der Sitzung oder im Datensatz des Onboarding-Vorgangs gespeichert werden; nach dem Erstellen des Kontos kann sie in die Nutzereinstellung übernommen werden. Gibt es für die Organisation eine separate Spracheinstellung, verwechseln Sie diese nicht mit der persönlichen Einstellung.

Legen Sie außerdem fest, was passiert, wenn der Nutzer über einen Einladungslink kommt, eine Sitzung auf einem anderen Gerät fortsetzt oder nach einem Ablauf zurückkehrt. Dokumentieren Sie die Vorrangregel und verhindern Sie, dass eine zustandslose Anfrage eine gültige Auswahl löscht. Speichern Sie die Einstellung nicht ausschließlich im Browser, wenn der Vorgang auf einem anderen Gerät fortgesetzt werden kann: Verknüpfen Sie sie gegebenenfalls mit dem gespeicherten Onboarding-Status.

Zustände für den Wechsel und das Fortsetzen des Onboardings gestalten

Modellieren Sie das Onboarding als Abfolge von Zuständen und nicht als Sammlung unabhängiger Seiten. Ein Datensatz kann den aktuellen Schritt, bereits beantwortete Felder, die ausgewählte Sprache und den Status enthalten, etwa ausstehend, abgeschlossen oder abgelaufen. Eine konsistente Speicherung ermöglicht die Wiederherstellung des Vorgangs, ohne bei jedem erneuten Laden eines Bildschirms eine Organisation anzulegen.

Validieren Sie in einer PHP-Anwendung sowohl den Ablaufstatus als auch alle empfangenen Daten auf dem Server. Die Benutzeroberfläche kann die Navigation steuern, sollte aber nicht die alleinige Instanz sein, die über den Abschluss eines Schritts entscheidet. Verwenden Sie stabile IDs für Schritte und Optionen und verarbeiten Sie Aktualisierungen so, dass ein erneuter Versuch keine Ressourcen dupliziert. Eine wiederholte Anfrage zum Erstellen der Organisation sollte beispielsweise den bestehenden Vorgang erkennen, statt ein weiteres Onboarding zu starten.

Zeigen Sie beim Sprachwechsel die Bezeichnungen und Meldungen erneut an, aber behalten Sie gültige Antworten bei. Ist eine Antwort aufgrund eines tatsächlichen Unterschieds zwischen den Regeln verschiedener Märkte nicht mehr gültig, erklären Sie den Grund und bitten Sie um eine Korrektur; löschen Sie sie nicht stillschweigend. Die Sprachauswahl sollte außerdem weder die ID des Vorgangs ändern noch den Fortschritt zurücksetzen.

Bezeichnungen, Validierungen und Fehler konsistent halten

Die Übersetzung muss den gesamten Ablauf abdecken, nicht nur die Überschriften. Berücksichtigen Sie Bezeichnungen, Hilfetexte, Schaltflächen, Ladezustände, Bestätigungen, Validierungsmeldungen und behebbare Fehler. Wenn ein Bildschirm Sprachen mischt, steigt selbst bei funktionierenden Feldern die Wahrscheinlichkeit, dass Nutzer missverstehen, was sie tun sollen.

Die Validierungsregeln müssen auf Client und Server übereinstimmen. Die Regel wird als gemeinsame Bedingung formuliert – beispielsweise, dass ein Pflichtfeld nicht leer sein darf –, und jede Benutzeroberfläche zeigt die Meldung in der ausgewählten Sprache an. Vermeiden Sie es, Meldungen aus übersetzten Fragmenten zusammenzusetzen, da Reihenfolge und Grammatik variieren können. Verwenden Sie vorzugsweise vollständige Meldungen, die stabilen Fehlerschlüsseln zugeordnet sind.

Trennen Sie den internen Fehlercode vom Text, den der Nutzer sieht. Die Anwendung kann beispielsweise einen Schlüssel wie organization_name_required zurückgeben und diesen in eine passende Meldung für die Benutzeroberfläche auflösen. Technische Protokolle können den Code und die ID des Vorgangs enthalten, dürfen aber keine unnötigen personenbezogenen Daten offenlegen oder interne Ausnahmen an den Browser zurückgeben.

Bei einem Netzwerkfehler oder einer vorübergehend nicht verfügbaren Antwort sollten Sie angeben, ob die Antworten erhalten geblieben sind, und eine sichere Möglichkeit zum Fortfahren oder Wiederholen anbieten. Die Meldung muss verständlich sein und darf nicht versprechen, dass Informationen gespeichert wurden, wenn der Server dies nicht bestätigt hat.

Vollständige Abläufe testen, nicht nur Übersetzungen

Die Tests sollten die Nutzungsschritte und Zustandsänderungen abdecken. Eine praktische Testsammlung umfasst folgende Fälle:

• Das Onboarding in einer verfügbaren Sprache beginnen, mehrere Felder ausfüllen und prüfen, ob Bezeichnungen und Meldungen in dieser Sprache erscheinen.
• Mitten im Vorgang die Sprache wechseln und prüfen, ob die Antworten erhalten bleiben, ausgewählte Optionen übersetzt angezeigt werden und keine Ressourcen dupliziert werden.
• Ein Formular mit ungültigen Daten absenden und prüfen, ob die Fehler verständlich, lokalisiert und dem richtigen Feld zugeordnet sind.
• Einen behebbaren Fehler auslösen, den Vorgang wiederholen und bestätigen, welche Antworten erhalten geblieben sind und ob der Prozess nur einmal fortgeschritten ist.
• Das Onboarding verlassen und fortsetzen, auch nach einem Ablauf oder aus einer neuen Sitzung, um die Regel zur Speicherung der Spracheinstellung zu überprüfen.
• Vom Nutzer eingegebene Werte und ausgewählte IDs vor und nach einem Sprachwechsel überprüfen.

Automatisieren Sie wichtige Invarianten: Ein Sprachwechsel darf den Namen der Organisation nicht ändern; das Fortsetzen eines Vorgangs darf das Konto nicht duplizieren; eine fehlgeschlagene Validierung darf gültige Felder nicht löschen. Ergänzen Sie Oberflächentests, um zu prüfen, ob die Texte vorhanden sind und keine Übersetzungsschlüssel sichtbar bleiben. Manuelle Tests sind weiterhin nützlich, um verwirrende Meldungen oder Anweisungen zu erkennen, die nicht mehr in das Design passen.

Checkliste vor der Aktivierung einer weiteren Sprache

• Ist klar, welches Feld die Sprache der Benutzeroberfläche abbildet und wer sie ändern kann?
• Bleibt die Auswahl vor dem Erstellen eines Kontos und beim Fortsetzen des Vorgangs erhalten?
• Bleiben eingegebene Daten und IDs ausgewählter Optionen beim Sprachwechsel unverändert?
• Sind alle Bezeichnungen, Hilfetexte, Validierungen, Bestätigungen und Fehler im Ablauf abgedeckt?
• Sind Wiederholungen und doppelte Anfragen sicher und führen sie nicht zu doppelten Onboardings?
• Prüfen die Tests den Beginn, den Sprachwechsel, die Wiederaufnahme und behebbare Fehler?

Ein zuverlässiges mehrsprachiges Onboarding entsteht, wenn für jedes Datum klare Zuständigkeiten definiert sind und geprüft wird, ob der Zustand typische Aktionen übersteht. Überprüfen Sie vor der Aktivierung einer neuen Sprache den Ablauf von der ersten Entscheidung bis zur Bestätigung: Jeder Bildschirm sollte den Nutzer anleiten, ohne seine Daten neu zu interpretieren oder ihn den Fortschritt verlieren zu lassen.