Datums, of eigenlijk de kalender waarin ze getoond worden, wil ik meertalig maken. Ik maak gebruik van MariaDB <=> PHP <=> JavaScript, en ik zit in beginsel met de vraag wat het handigst is om de Engelse datums om te zetten naar Nederlandse notatie.
Datumberekeningen (conflicten ed.) zullen voornamelijk op database-niveau moeten plaatsvinden, dat werkt het snelst. Dus gewoon in het native format met DATETIME velden. Maar de ondersteuning voor locales in de database is niet zo uitgebreid, het enige dat ik heb gevonden is dat de database (MariaDB/MySQL) dag en maandnamen omzet, en al het andere mag je zelf doen met formatting.
Ik heb gekeken naar de intl-extentie in PHP, en die is ideaal voor gebruik in PHP. Echter, als je een formulier met datumwidget hebt, of een kalender, dan wil je niet voor elk wissewasje een AJAX-call maken van soms 0.5s of meer naar de backend. Ofwel, als ik in JavaScript wil gaan rekenen met datums, dan is het handig als de vertaalslag van Engels naar Nederlands meteen in JavaScript kan.
Dan komt mijn vraag: wat is handig om te doen? Er is een Internationalization API in JavaScript, maar niet voor IE10 wat mijn klanten ook gebruiken. Wat kan je aan de browser overlaten? Welke dingen wil je toch via PHP laten doen?
Het idee dat ik op het moment heb, is dat je zo min mogelijk aan JS wilt overlaten om browserafhankelijkheid te omzeilen. Een inputwidget moet de ruwe datum bevatten, met een versie die via HTML-elementen getoond wordt in de browser, locale-bewust. En een tekstelement met de printversie van de datum, zodat het goed wordt afgedrukt, zonder de controls.
Uiteraard ben ik niet de enige die een dergelijk probleem heeft, dus vraag ik me af wat de ervaring is van anderen, wat is aan te raden?
Je hebt maar 7 dagnamen, 12 maandnamen en 4 datumnotaties, namelijk de korte en de lange in respectievelijk Nederlands en Engels. En zelfs dat niet als je een maandkalender-widget gebruikt: dan hoef je alleen de maandnamen te lokaliseren. Daarvoor zou ik geen karrenvracht aan JavaScript API laden die niet eens compatibel is met alle clients. Ik zou zelfs php_intl dan links laten liggen. Allebei overkill. Met een handvol arrays en wat functies kom je er ook.
?
Onbekende gebruiker
22-04-2016 15:31
gewijzigd op 22-04-2016 15:31
Ik snap dat je het voorstelt om het bij alleen Nederlands gewoon simpel te houden, maar ik wil voorkomen dat de applicatie op den duur houtje touwtje wordt.
Wat als er straks ook Frans en Duits en Spaans bij komt, of als er een vestiging in Hongkong opent? Of als ik het kalenderobject wil hergebruiken in anderstalige applicaties?
Het fijne van intl lijkt mij juist dat alles al is uitgezocht, dat alle namen goed staan, alle lengten van perioden, sorteringen en nummerformattering van monetaire eenheden, alles van veel talen/culturen.
Eenmaal uitgeschreven hoef je het alleen nog te configureren, evt. via autodetectie. Die tijdsinvestering is geen probleem.
En ik ga er blind van uit dat het sneller werkt dan het in mijn ogen erg trage DateTime-object van PHP, omdat er bij ICU erg gelet wordt op performance, zelfs in de C-implementatie.
Ik ga er zowieso mee aan de slag, misschien kom ik nog op andere gedachten bij gebruik van intl.
Qua JavaScript ben ik er nog niet uit of de internationalization API of compatibility-library voor IE10 en ouder vergelijkbare functies heeft en een beetje aansluit op PHP's intl extentie.
Ter vergelijk met PHP: intl past bijvoorbeeld moeizaam op PHP's date() functie omdat de interne verwerking van datums met intl via 64-bit signed integers gaat, en als ik het aantal microseconden (UNIX-timestamp) voer aan date(), dan gaat het goed fout. Moet het toch misschien via DateTime oid.
Voor al dat soort details vraag ik me af wie kan vertellen wat handige combinaties zijn met JavaScript, ook omdat de hele internationalization API relatief nieuw is in browserland.
Het alternatief is dat ik JavaScript niet laat nadenken over datums en berekeningen, maar dat ik het denkwerk voorbereid met intl en dat via arrays aan JavaScript geef voor widgets ed.
als je de datum in de database en op de achtergrond in je applicatie gewoon houdt op 2015-12-31 23:44
dan kun je daar een schil omheen bouwen die naar de gebruiker in een mooi formaat de datum toont.
Dat kan bijvoorbeeld door
$date = new DateTime("2015-12-31 23:44");
en dan
met echo $date->format('een leuk formaat')
als het nodig is om te achterhalen op welk vakje van de kalender de gebruiker klikt: zorg dan dat zo'n vakje iets heeft als <span data-datum="2015-12-31">...</span>
dus in een fixed formaat. Ziet de gebruiker toch niet.
Moet de gebruiker een datum invoeren: liefst met een of andere widget zorgen dan de invoer "22-04-2016" direct omgaat naar "2016-04-22"
Dan hoef je alleen maar bij de ->format() te zorgen voor een custom formaat en bij de widget
Wat Ward denk ik bedoeld is dat je moet bouwen wat je nu nodig hebt. Niet wat je mogelijk nodig gaat hebben. Dan maak je het allemaal veel te complex.
Uit ervaring kan ik je vertellen dat het tof lijkt om op alles voorbereid te zijn maar dat het in werkelijk juist meer tijd kost om dingen te implementeren dan wel te onderhouden. Dan kan je beter een keer zeggen van; We gaan nu refactoren.
Momenteel heb je Nederlands en Engels nodig. Dan maak je daar nu iets voor.
Persoonlijk zou ik iets bestaand pakken (om af te kijken) zoals de datepicker van Bootstrap.
Dat bedoel ik inderdaad en dat was onder andere hierom:
An tje op 22/04/2016 15:31:00
Wat als er straks ook Frans en Duits en Spaans bij komt, of als er een vestiging in Hongkong opent? Of als ik het kalenderobject wil hergebruiken in anderstalige applicaties?
Met een "wat als" kun je de boel enorm complex maken. Elke invulling van een "wat als" verlengt de ontwikkeltijd, verhoogt de ontwikkelkosten en vergroot de kans op bugs.
Wat als je talen moet ondersteunen die van rechts naar links worden gelezen, zoals Arabisch? Wat als je de Chinese jaartelling moet ondersteunen? Wat als je voor historische doeleinden een paar miljoen jaar voor Christus moet weergeven? Wat als het 2038 wordt? Wat als …
Als je voor je kalender nog meer moet vertalen dan alleen de dagen en maanden dan kan het er net zo makkelijk in mee. De intl extensie is lang niet op iedere HOST geïnstalleerd en dus maak je je website weer afhankelijk van een "niet zo standaard configuratie". Of je bouwt zoals ward al aangaf eenmalig een eigen date-class die de belangrijkste talen ondersteund. Dan kun je waarschijnlijk de rest van je leven hiermee vooruit. Alleen als je echt een tool wilt bouwen waarvan je verwacht dat je gebruikers van over de hele wereld zullen komen en het gaat enkel om de weken en maanden (wat ik me al niet voor kan stellen) dan zou ik intl overwegen.
