meertalig

De situatie is dat ik de host voor het uitzoeken heb en intl is daarop aanwezig. Helaas heb ik de browser niet voor het uitzoeken, de IT-organisatie bepaalt dat ik momenteel vastzit aan Internet Explorer 10.

Mijn applicatie wil ik toekomstbestendig maken. Zo kan ik me nog erg goed herinneren hoe ik een poosje geleden zat te klooien om de applicatie uit het slijk van Latin1 te halen en Unicode te maken, zodat in ieder geval Microsoft Word-documenten goed konden worden ingelezen. Het was een lange refactor-klus, met een tut tot gevolg: https://www.phphulp.nl/php/tutorial/php-algemeen/unicode-enzo/831/
Met terugwerkende kracht kan ik zeggen dat het handiger was om de applicatie van meet af aan Unicode te schrijven, dat had een hoop gedoe met nutteloze transcoding tussen front- en backend bespaard.

De keuze voor intl is een logische keuze. Wanneer personeel vanaf een andere plaats (tijdzone) werkt, of in de eigen taal (soms Arabisch idd.), of wanneer het product vermarkt wordt naar bedrijven met eigen locales, dan zou het fijn zijn als de applicatie, inclusief de kalender, dat gewoon alvast ondersteunt. Te meer omdat bedrijven een voorkeur hebben voor web-enabled front-ends, om deployment op clients te besparen, is intl een goede investering. Sterker, als ik voor mijn Unicode-exercitie van het bestaan van intl had geweten, had ik niet in mijn tutorial aangeraden om zoveel mogelijk in de database te doen, en de mb_*-functies te vermijden. In plaats daarvan had ik meteen intl aangeraden. Ondersteuning voor locales in MySQL/MariaDB lijkt mij beduidend minder dan de mogelijkheden van intl. Ik ben het daarom eens met Ivo om de database in haar native format te laten en een schil met intl te maken.
Misschien dat wanneer ik een overstap naar PostgreSQL kan maken, dat ik deze keuze moet heroverwegen, momenteel heb ik die keuze niet.

Tot zover de verdediging van mijn keuze voor intl, zonder direct mee te gaan in de typische reflex op phphulp.nl om de vragensteller op andere gedachten te brengen. :-)

Ik ben nu bezig met het oriënteren voor de planningsmodule om te kijken wat handig is. intl is het probleem niet, de library is iets meer dan 100k, en de code is goed te begrijpen: https://www.phphulp.nl/php/forum/topic/dagen-/99808/

Wanneer ik een kalender teken op het scherm voor meerdere mensen tegelijkertijd, vergelijkbaar met een kalender van Outlook, dan kan ik daarvoor eenvoudig geparametriseerde JavaScript code gebruiken met variabelen van intl, om de load van een XHR-verzoek zo licht mogelijk te houden.
Echter, als iemand een willekeurige datum invult en ik zou bijvoorbeeld willen berekenen of dat een geldige datum is, wat de dag van het jaar is ed., dan zie ik nog niet voor me hoe dat gemakkelijk in JavaScript (van IE10) zou kunnen op een manier die compatible is met intl, zonder extra XHR-verzoek. Misschien is dat niet heel erg, want met een extra XHR-verzoek kan ik controleren op conflicten en aanvullende informatie ophalen, maar ik zou het niet voor elke situatie willen. Bijvoorbeeld met een widget in een normaal formulier.

Zo kom ik op mijn oorspronkelijke vraag van dit topic, namelijk wat de mogelijkheden zijn van JavaScript en of ik met geparametriseerde JavaScript-code op de goede weg zit, ondanks het bestaan van de Internationalization API en intl.js. Het zou fijn zijn om hierover terugkoppeling te krijgen, want het is goed mogelijk dat het nog jaren duurt eer de IT-organisatie over zal gaan op IE11 of Edge.

Nu het ineens angstvallig stil blijft, ga ik er vanuit dat geparametriseerde Javascript de beste manier is om met meertalige widgets en een kalender om te gaan. (Als niemand een betere oplossing weet, mag ik er vanuitgaan dat mijn oplossing niet gek is.. :-)

Ik had hier een hele tijd geleden een interessante comment over gezien, volgens mij op stackoverflow. Het ging hierbij om de formattering van locale-specifieke datums. Aan het einde van het verhaal was dit volgens mij nog steeds een weergaveprobleem. Kun je dit probleem niet compleet verplaatsen naar en oplossen in een soort van templatesysteem of -laag?

Het enige wat je nodig hebt is een taal-specifieke "datum string" waarin je de dag-, maand- en jaarvakjes (en wat je nog meer wilt) vult met informatie.

Omrekenen naar een andere/de eigen tijdszone is een apart probleem en kan dus in afzondering opgelost worden (separation of concerns). Dit kan ook direct in PHP via je <favoriete datetime lib>.

Wellicht is dit een oversimplificatie, maar dan begrijp ik ook niet echt wat het probleem is of waar het schip precies strandt :).

Het toevoegen van een taal (wat datums betreft dan) is dan niet meer dan het toevoegen van de "datum strings" voor die taal.

Je zou kunnen zeker kunnen stellen dat het een weergave-probleem is, omdat dat het moment is dat de applicatie moet kunnen interfacen met mensen.

Aanpassen van namen van dagen en maanden is slechts een klein onderdeel van het probleem, want in verschillende culturen zijn er onder meer:
- andere talen met andere karakters
- in een andere leesrichting,
- met andere sorteringen
- met andere kalenders dan de gregoriaanse (ander aantal maanden per jaar en dagen per maand)

Om dit alles soepel te laten samenwerken bevat de International Components for Unicode of ICU tooling welke wordt gebruikt door alle grote spelers, zie: http://site.icu-project.org.
We kunnen hier in PHP dankbaar gebruik van maken via de intl-extentie: http://php.net/manual/en/book.intl.php

Nu wil ik in mijn AJAX-applicatie straks een kalender hebben waarin de eindgebruiker activiteiten kan plannen. Of ik heb een datum-widget waarin de eindgebruiker zijn datum kan opgeven. De eindgebruiker tikt dan bijvoorbeeld de datum in, in zijn taal. En ik zou dat dan graag client-side willen controleren, ook op collisions in de al geladen kalender-data, zodat ik niet bij elke muisklik of toetsaanslag een XHR-verzoek naar de server hoef te sturen.

- Hoe kan je dat doen met het JavaScript van Internet Explorer 10, waar de Internationalization API nog niet wordt ondersteund?
- Hoe past die data op intl? Gaat dat goed met de 64-bit integers die intl onderhuids gebruikt?

Ik zou graag feedback willen over hoe anderen dit probleem oplossen, dus niet alleen namen van dagen/maanden.