[TPL] [OPL] Datum Nederlands/Engels

[TRON]

Ik heb een simpele doch bruikbare oplossing gevonden voor het probleem dat verschillende data in het Engels en Nederlands weergegeven worden.

Met het stukje JavaScript:

code:

var postDate = new Date();
ConvertedDate = postDate.toLocaleString({HIER DE UNIX_TIMESTAMP});

wordt de datum weergegeven op de manier hoe het weergegeven moet worden.

[ Voor 3% gewijzigd door TRON op 22-10-2003 11:13 ]

[TRON]

^^ kick

Je mag slaan als dit heel irritant is, maar hebben jullie hier nou wat aan?

[ Voor 20% gewijzigd door TRON op 17-11-2003 11:50 ]

[chem]

Tsja, dat moeten de tpl-devvers zelf beslissen he

[crisp]

Het lijkt me niet dat we dit soort dingen met een javascriptje moeten gaan doen (is afhankelijk van de locale settings op de client PC die bijvoorbeeld bij mij op US staat), je zou dan eerder serverside de timestamp door een functie moeten halen die de formatted date in het Nederlands in de templates zet; iets wat technisch gezien wel mogelijk is.
Op dit moment gebruiken we de formatted date uit de RML, die dus Engels is en wat binnen React dus blijkbaar niet instelbaar is.

Persoonlijk vind ik dit echter geen template issue; alleen in een multi-language omgeving waarbij je voor verschillende talen verschillende templates zou hebben zou je het template-based moeten doen; op GoT zou je het gewoon board-wide (binnen React dus) moeten kunnen instellen, maar dat is mijn mening.

Blijft over de vraag of het wenselijk is; er zijn wel meer dingen Engelstalig binnen GoT. Persoonlijk stoort het me absoluut niet eigenlijk.

[ Voor 6% gewijzigd door crisp op 17-11-2003 12:55 ]

[Harm]

crisp schreef op 17 november 2003 @ 12:53:
Blijft over de vraag of het wenselijk is; er zijn wel meer dingen Engelstalig binnen GoT. Persoonlijk stoort het me absoluut niet eigenlijk.

Is het dan een idee om het mee te nemen bij de ontwikkeling van de nieuwe templates? Als er dan toch voor gezorgd gaat worden dat Nederlands en Engels minder consistenter gebruikt gaat worden, dan is dit IMHO iets waar ook wel aandacht aan geschonken mag gaan worden .

[chem]

MySQL kan geen nederlands, dus zonder zwaar aan performance in te boeten kan React ook geen nederlands

[We Are Borg]

Harm schreef op 17 november 2003 @ 13:23:
[...]

Is het dan een idee om het mee te nemen bij de ontwikkeling van de nieuwe templates? Als er dan toch voor gezorgd gaat worden dat Nederlands en Engels minder consistenter gebruikt gaat worden, dan is dit IMHO iets waar ook wel aandacht aan geschonken mag gaan worden .

Het meenemen van de engels woorden en deze zoveel mogelijk vertalen naar Nederlands lijkt me zeker wenselijk. Al ben ik met crisp eens dat de datum van engels naar nederlands omzetten niet m.b.v. JS moet worden gedaan maar in de software (php) moet worden verwerkt. Alleen chem vind het niet wenselijk vanwege perfomance .

Zo zwaar is de datum van engels naar nederlands omzetten toch niet?

[crisp]

ik ben bang dat de performance dan alleen nog maar slechter zal zijn op het moment dat we het in de templates gaan doen...

[Harm]

chem schreef op 17 november 2003 @ 13:32:
MySQL kan geen nederlands, dus zonder zwaar aan performance in te boeten kan React ook geen nederlands

Ok, dat wist ik dan weer niet. Dan gaat het 'feestje' dus niet door aangezien het uitvoeren van de conversie in de templates zelf ook geen optie is.

[TRON]

Hoeveel performance zou het dan kosten als je dat stukkie JavaScript meeneemt in de template?

[crisp]

TRON schreef op 17 november 2003 @ 21:56:
Hoeveel performance zou het dan kosten als je dat stukkie JavaScript meeneemt in de template?

voor de server: geen omdat het clientside uitgevoerd wordt, echter krijg je dan zoiets te zien:

het is nu:

edit: bij mij staat er dan "17 November 2003 22:13:53" - dus de dagnaam is er al vanaf, echter is dit volledig afhankelijk van de instellingen en het platform, er kan dus ook dit komen te staan op een client: "11/17/03 22:13:53" - ik denk dat dat niet wenselijk is...

[ Voor 26% gewijzigd door crisp op 17-11-2003 22:12 ]

[TRON]

Tja, is te begrijpen aan de ene kant. Aan de andere kant is het ook wel een leuke, en voor sommige mensen een handige feature

[crisp]

NOFIX in de huidige templates