Een bedrag dat verandert wanneer de taal wordt aangepast, een datum die op de verkeerde dag verschijnt of een vertaling die een bedrijfsregel verandert, wijst vaak op hetzelfde probleem: de applicatie haalt gegevens en presentatiekeuzes door elkaar. Voor de internationalisering van datums en valuta in PHP moeten taal, locale, valuta en tijdzone afzonderlijk worden behandeld. Bepaal daarbij welke waarde het systeem bewaart en welke weergave elke gebruiker ziet.
Door deze zaken te scheiden, kun je meer regio’s ondersteunen zonder bedrijfsregels te dupliceren of historische gegevens opnieuw te interpreteren. Het helpt ook om de oorzaak van fouten te vinden: die kan liggen bij de gebruikersinvoer, de opslag, een tijdzoneconversie of alleen de uitvoeropmaak.
Taal, locale, valuta en tijdzone zijn afzonderlijke keuzes
De taal bepaalt de interfacetekst en vertaalbare inhoud, zoals labels, validatiemeldingen en productnamen. Een locale of regionale instelling bepaalt presentatieconventies, zoals decimaaltekens, de volgorde van de datum en maandnamen. Een locale is niet altijd hetzelfde als een taal: twee regio’s met dezelfde voertaal kunnen verschillende notaties gebruiken.
De valuta geeft de eenheid aan waarin een bedrag wordt uitgedrukt, zoals EUR of JPY. Die kun je niet betrouwbaar afleiden uit de taal of locale. Iemand kan de interface in het Spaans bekijken, een bepaalde regionale notatie gebruiken en een aankoop in een andere valuta doen. De tijdzone bepaalt hoe lokale tijden zich verhouden tot de universele tijd en tot de klokwisselingen in een regio.
Modelleer deze voorkeuren bij voorkeur expliciet. Een account kan bijvoorbeeld een taal en tijdzone hebben, een sessie kan een notatievoorkeur vastleggen en elke bestelling moet de daadwerkelijk gebruikte valuta bewaren. Toegestane waarden en standaardwaarden moeten productkeuzes zijn, geen stilzwijgende aannames op basis van de netwerklocatie.
Wat je opslaat en wat je berekent voor de weergave
Sla de gegevens op die nodig zijn om de oorspronkelijke gebeurtenis te reconstrueren, niet alleen een vooraf opgemaakte tekenreeks. Een aanmaaktijdstip staat voor een moment; een notatie als ‘03/04/2025’ is dubbelzinnig en geen goede canonieke representatie. Voor wereldwijde gebeurtenissen is het vaak praktisch om het tijdstip in UTC op te slaan en de relevante tijdzone te bewaren wanneer de context daarvan afhangt, zoals bij een afspraak die in een bepaalde stad is gemaakt.
In een PHP-applicatie helpt DateTimeImmutable onbedoelde wijzigingen tijdens conversies te voorkomen. Converteer het tijdstip naar de gekozen tijdzone wanneer je het antwoord voorbereidt, zonder de opgeslagen waarde te vervangen. Gebruik erkende tijdzone-ID’s, zoals Europe/Madrid, in plaats van een vaste offset zoals +01:00 op te slaan: een offset bevat geen historische regels of seizoenswisselingen.
Bewaar voor de regionale notatie een geldige locale-aanduiding volgens de gebruikte bibliotheek en omgeving, en handel niet-ondersteunde voorkeuren expliciet af. Functies uit intl, zoals IntlDateFormatter en NumberFormatter, maken het mogelijk lokale conventies toe te passen zonder scheidingstekens en maandnamen handmatig aan elkaar te rijgen. Controleer of de extensie beschikbaar is in de omgevingen waarin de applicatie draait.
Datums en tijden: conversie en dubbelzinnige gevallen
Tijdstippen die door het systeem zijn vastgelegd en lokale kloktijden zijn niet onderling uitwisselbaar. Een tijdstip als ‘2025-04-10T15:00:00Z’ duidt één ondubbelzinnig moment aan. ‘2025-10-26 om 02:30 in Europe/Madrid’ kan daarentegen dubbelzinnig zijn tijdens de overgang naar wintertijd, omdat dat lokale tijdstip twee keer kan voorkomen. Bij de overgang naar zomertijd kunnen er ook lokale tijdstippen zijn die helemaal niet voorkomen.
Als je een actie voor een toekomstig lokaal tijdstip plant, sla dan niet alleen een timestamp op die één keer is berekend wanneer de afspraak gebaseerd is op de lokale klok van een regio. Bewaar de gevraagde datum en tijd, de tijdzone en een beleid voor het afhandelen van niet-bestaande of dubbele tijdstippen. De keuze — afwijzen, om verduidelijking vragen of een van de twee tijdstippen kiezen — hangt af van het product. Registreer voor een gebeurtenis die al heeft plaatsgevonden juist het daadwerkelijke tijdstip.
Bepaal ook hoe je datums uit formulieren en API’s interpreteert. Accepteer gedocumenteerde notaties, valideer de tijdzone en wijs dubbelzinnige invoer af in plaats van te raden of ‘04/05/2025’ april of mei betekent. Toon in interfaces een leesbare weergave, maar bewaar de canonieke waarde voor sorteren, vergelijken en auditen.
Bedragen: precisie, valuta en notatie
De zichtbare notatie mag niet de financiële bron van waarheid worden. Gebruik geen binaire floating-pointgetallen voor geldberekeningen: bepaalde decimale breuken kunnen niet exact worden weergegeven en kunnen afrondingsfouten veroorzaken. Een gebruikelijke aanpak is om bedragen als gehele aantallen kleinste valuta-eenheden op te slaan, samen met de valutacode. Niet alle valuta gebruiken echter twee decimalen, en sommige berekeningen vereisen meer precisie tijdens tussenberekeningen dan het uiteindelijk in rekening gebrachte bedrag.
Bepaal de precisie en het moment van afronden volgens de domeinregels: per regel, per belasting of over het totaal. Houd de valuta expliciet vast bij bestellingen, betalingen, terugbetalingen en berekeningen; interpreteer een getal niet zonder te weten bij welke valuta het hoort. Als je valuta’s converteert, bewaar dan ook de gegevens die nodig zijn om de conversie toe te lichten, zoals de toegepaste wisselkoers en het referentietijdstip, wanneer die relevant zijn voor de transactie.
Geef bij de weergave van het bedrag de numerieke waarde en de valutacode door aan de geschikte regionale formatter. De notatie kan verschillen in symbolen, volgorde en scheidingstekens. De gebruiker moet de valuta kunnen herkennen zonder afhankelijk te zijn van een mogelijk dubbelzinnig symbool. Parseer een gelokaliseerde tekenreeks niet alsof die een universeel getal is: valideer de invoer en zet die om naar een gecontroleerde numerieke representatie voordat je ermee verdergaat.
Inhoud vertalen zonder bedrijfsregels te dupliceren
Vertaal teksten en pas notaties aan, maar houd de regels voor prijzen, belastingen, geschiktheid, machtigingen en statussen gecentraliseerd. Logica per taal dupliceren leidt tot afwijkend gedrag dat moeilijk te ontdekken is. De keuze van een tarief kan afhangen van de markt, het contract of commercieel beleid; die keuze mag niet veranderen alleen omdat het interfacelabel is gewijzigd.
Scheid vertaalcatalogi van de domeinlogica. Leg voor bewerkbare, gelokaliseerde inhoud vast welke versies kunnen bestaan, hoe ontbrekende versies worden afgehandeld en wat het fallbackgedrag is. Een vertaalde naam mag geen stabiele identificatiecode vervangen. Documenteer in API’s of velden canonieke waarden, gelokaliseerde inhoud of kant-en-klare weergaven bevatten.
Tests en geleidelijke uitrol van regionale ondersteuning
Test de keuzes op meerdere lagen. Unit-tests moeten conversies tussen tijdzones, datumvalidatie, afronding en de opmaak van bedragen controleren. Neem gevallen op rond daggrenzen, overgangen naar zomer- en wintertijd, dubbele of niet-bestaande tijdstippen, maanden met verschillende lengtes en valuta met verschillende precisie. Vertrouw niet op de standaardlocale of tijdzone van de testmachine: stel deze expliciet in.
Integratietests moeten bevestigen dat de API canonieke gegevens opslaat en dat de interface die presenteert volgens de afgesproken voorkeuren. Controleer ook ongeldige invoer, onbekende locale-instellingen, wijzigingen van voorkeuren en het ontbreken van de benodigde extensie. Controleer na updates van de tijdzonedatabase de processen die toekomstige gebeurtenissen plannen en de verwachte resultaten.
Voer ondersteuning voor regio’s geleidelijk in: definieer eerst de gegevens en regels, test daarna de notaties en volledige processen en schakel de functionaliteit ten slotte in voor het beoogde publiek. Door validatiefouten, afrondingsverschillen en taken die buiten de geplande tijd worden uitgevoerd te monitoren, kun je fouten opsporen die op een screenshot niet zichtbaar zijn.
Checklist
- Taal: Is deze gescheiden van de locale en is er een fallbackbeleid?
- Datums: Wordt onderscheid gemaakt tussen een tijdstip en een geplande lokale tijd?
- Tijdzone: Worden regionale ID’s opgeslagen en dubbelzinnige tijdstippen afgehandeld?
- Bedragen: Heeft elk bedrag een expliciete valuta en zijn de precisie- en afrondingsregels bepaald?
- Presentatie: Wordt de notatie met geschikte hulpmiddelen gemaakt en wordt zichtbare tekst nooit voor berekeningen gebruikt?
- Tests: Worden daggrenzen, klokwisselingen, ongeldige invoer en verschillende voorkeuren getest?
- Uitvoering: Wordt de PHP-configuratie gecontroleerd en wordt regionale ondersteuning gecontroleerd uitgerold?
De belangrijkste keuze is een duidelijke grens te handhaven tussen de gegevens die het systeem begrijpt en de manier waarop elke persoon ze ziet. Met die grens wordt de internationalisering van datums en valuta in PHP een verzameling toetsbare regels, in plaats van een verzameling uitzonderingen verspreid over de applicatie.
