Een meertalige onboarding ontwerpen voor een PHP-SaaS

Een meertalige onboarding in een SaaS bestaat niet alleen uit het vertalen van de teksten op het eerste scherm. De gebruiker moet elke stap kunnen begrijpen, antwoorden behouden en de registratie voltooien, ook als die van taal wisselt of later terugkomt. Daarvoor is het verstandig de taalvoorkeur los te koppelen van bedrijfsgegevens en de flow te behandelen als een proces met verifieerbare statussen.

Deze gids richt zich op de registratie van een organisatie: wat je toont voordat je een account aanmaakt, wat je tijdens het proces opslaat en wat je test om fouten op te sporen. De gids is niet bedoeld om de algemene internationalisatiestrategie voor de hele applicatie te bepalen.

De interfacetaal, inhoud en registratiegegevens scheiden

In een formulier kunnen drie soorten informatie naast elkaar staan, maar je moet ze niet op dezelfde manier opslaan of vertalen:

• Interfacetaal: bepaalt labels, instructies, validaties en systeemberichten. Het is een ervaringsvoorkeur, zoals es of fr.
• Productinhoud: dit zijn teksten die door het bedrijf worden beheerd, zoals een planbeschrijving, een categorie of een welkomsttemplate. Deze inhoud kan eigen vertalingen hebben en een afzonderlijke keuze vereisen.
• Door de gebruiker ingevoerde gegevens: hieronder vallen de organisatienaam, een domein of een beschrijving. Deze gegevens moeten behouden blijven zoals de gebruiker ze heeft ingevoerd en mogen niet worden vertaald wanneer de interfacetaal verandert.

Vermijd in het datamodel één ambigu veld met de naam language voor verschillende begrippen. Een interfacevoorkeur kan preferred_locale heten; de taal van beheerde inhoud moet, waar relevant, aan die inhoud gekoppeld blijven. De naam van een organisatie wordt daarentegen geen andere waarde wanneer de interfacetaal verandert.

Deze scheiding maakt ook duidelijk wat je met keuzelijsten moet doen. Als de gebruiker een sector kiest uit vertaalde opties, sla dan een stabiele identifier op, niet het zichtbare label. Zo kan de geselecteerde optie in een andere taal worden weergegeven zonder de bedrijfsgegevens te wijzigen of afhankelijk te zijn van een label dat altijd hetzelfde blijft.

De taal kiezen voordat er een account bestaat

De registratie begint vaak voordat er een geauthenticeerde gebruiker is en voordat er een voorkeur in diens profiel is opgeslagen. Daarom heeft het systeem een expliciete initiële regel nodig. Je kunt een zichtbare keuzelijst aanbieden, de browsertaal als suggestie gebruiken of beide opties combineren. Automatische detectie moet de gebruiker helpen, niet verhinderen een andere optie te kiezen.

Bepaal welke waarde voorrang krijgt wanneer er meerdere signalen zijn. Een expliciete keuze tijdens de registratie zou bijvoorbeeld zwaarder moeten wegen dan een latere automatische detectie. De gekozen taal kan tijdelijk worden opgeslagen in de sessie of in het registratieproces; zodra het account is aangemaakt, kan de keuze naar de gebruikersvoorkeur worden gekopieerd. Als de organisatie een afzonderlijke taalinstelling heeft, verwar die dan niet met de persoonlijke voorkeur.

Bepaal ook wat er gebeurt wanneer de gebruiker via een uitnodigingslink binnenkomt, een sessie op een ander apparaat hervat of terugkeert nadat de sessie is verlopen. Leg de prioriteitsregel vast en voorkom dat een stateless request een geldige keuze wist. Sla de voorkeur niet uitsluitend in de browser op als het proces vanaf een ander apparaat kan worden hervat: koppel die waar passend aan de opgeslagen onboardingstatus.

Statussen ontwerpen om de registratie te wijzigen of te hervatten

Modelleer de onboarding als een reeks statussen, niet als een verzameling losse pagina's. Een registratie kan de huidige stap bevatten, de al beantwoorde velden, de gekozen taal en de status ervan, bijvoorbeeld in behandeling, voltooid of verlopen. Door de gegevens consistent op te slaan, kan het proces worden hersteld zonder telkens een organisatie aan te maken wanneer een pagina opnieuw wordt geladen.

Valideer in een PHP-applicatie zowel de flowstatus als alle ontvangen gegevens op de server. De interface kan de navigatie beheren, maar mag niet de enige autoriteit zijn die bepaalt of een stap is voltooid. Gebruik stabiele identifiers voor stappen en opties en verwerk updates zo dat een retry geen dubbele resources aanmaakt. Een herhaald verzoek om de organisatie aan te maken moet bijvoorbeeld het bestaande proces herkennen in plaats van een nieuwe registratie te starten.

Toon bij het wisselen van taal de labels en berichten opnieuw, maar behoud geldige antwoorden. Als een antwoord ongeldig wordt door een daadwerkelijk verschil in regels tussen markten, leg dan uit waarom en vraag de gebruiker het te corrigeren; verwijder het niet stilzwijgend. De taalkeuze mag de procesidentifier evenmin wijzigen of de voortgang resetten.

Labels, validaties en foutmeldingen consistent houden

De vertaling moet de volledige flow omvatten, niet alleen de koppen. Denk aan labels, helptekst, knoppen, laadstatussen, bevestigingen, validatiemeldingen en herstelbare fouten. Als een scherm verschillende talen door elkaar gebruikt, neemt de kans toe dat de gebruiker verkeerd begrijpt wat die moet doen, ook als de velden werken.

De validatieregels moeten consistent zijn tussen client en server. De regel wordt uitgedrukt als een gedeelde voorwaarde — bijvoorbeeld dat een verplicht veld niet leeg mag zijn — en elke interface toont de bijbehorende melding in de gekozen taal. Stel berichten niet samen door vertaalde fragmenten aan elkaar te plakken, omdat de woordvolgorde en grammatica kunnen verschillen. Gebruik liever volledige berichten die aan stabiele foutcodes zijn gekoppeld.

Scheid de interne foutcode van de tekst die de gebruiker ziet. De applicatie kan bijvoorbeeld een sleutel zoals organization_name_required teruggeven en die omzetten in een passende interfacemelding. Technische logs kunnen de code en de procesidentifier bevatten, maar mogen geen onnodige persoonsgegevens blootleggen of interne exceptions aan de browser teruggeven.

Geef bij een netwerkfout of een tijdelijk niet-beschikbaar antwoord aan of de antwoorden behouden zijn en bied een veilige actie om verder te gaan of opnieuw te proberen. De melding moet begrijpelijk zijn en mag niet beloven dat informatie is opgeslagen als de server dat niet heeft bevestigd.

Volledige flows testen, niet alleen vertalingen

Tests moeten de gebruiksvolgorde en statuswijzigingen omvatten. Een praktische testset bevat de volgende gevallen:

• De registratie starten in een beschikbare taal, meerdere velden invullen en controleren of labels en berichten in die taal worden weergegeven.
• Tijdens het proces van taal wisselen en controleren of de antwoorden behouden blijven, geselecteerde opties worden vertaald en er geen dubbele resources worden aangemaakt.
• Een formulier met ongeldige gegevens verzenden en controleren of de foutmeldingen duidelijk en gelokaliseerd zijn en aan het juiste veld zijn gekoppeld.
• Een herstelbare fout veroorzaken, opnieuw proberen en controleren welke antwoorden behouden zijn en of het proces slechts één keer is voortgezet.
• De registratie verlaten en hervatten, ook nadat de sessie is verlopen of vanuit een nieuwe sessie, om de regel voor het bewaren van de voorkeur te controleren.
• De door de gebruiker ingevoerde waarden en geselecteerde identifiers vóór en na het wisselen van taal controleren.

Automatiseer de belangrijkste invarianten: het wisselen van taal mag de organisatienaam niet wijzigen; het hervatten van een proces mag geen dubbele accounts aanmaken; een mislukte validatie mag geen geldige velden verwijderen. Voeg interfacetests toe om te controleren of de teksten aanwezig zijn en er geen zichtbare vertaalsleutels achterblijven. Handmatige tests blijven nuttig om verwarrende berichten op te sporen of instructies die niet meer in het ontwerp passen.

Checklist voordat je een andere taal beschikbaar maakt

• Is duidelijk welk veld de interfacetaal vertegenwoordigt en wie die kan wijzigen?
• Blijft de keuze behouden voordat een account wordt aangemaakt en wanneer het proces wordt hervat?
• Blijven ingevoerde gegevens en identifiers van opties intact wanneer de taal verandert?
• Zijn alle labels, helpteksten, validaties, bevestigingen en foutmeldingen in de flow afgedekt?
• Zijn retries en herhaalde verzoeken veilig en veroorzaken ze geen dubbele registraties?
• Controleren de tests het starten, het wisselen van taal, het hervatten en herstelbare fouten?

Een betrouwbare meertalige registratie bereik je door voor elk gegeven duidelijke verantwoordelijkheden vast te leggen en te controleren of de status behouden blijft bij gebruikelijke acties. Controleer voordat je een nieuwe taal beschikbaar maakt de volledige flow, vanaf de eerste keuze tot en met de bevestiging: elk scherm moet de gebruiker op weg helpen zonder diens gegevens anders te interpreteren of voortgang verloren te laten gaan.