Franciser la date (SetLocale) et définir le jeu de caractère (Charset)

Sacré OVH.... ce n’est pas la première fois que je vois des soucis avec eux... toujours des config spécifiques et parfois un peu opaques !

Ceci dit, bien vu ça veut donc bien dire que
- soit ton serveur est en ISO-8859-1 (et à ce moment là il faudra tenter de modifier .htaccess ou php.ini mais bon pour le deuxième chez OVH je crois que pas possible d’avoir un php.ini custom)
- soit ton fichier de langue est encodé lui même en ISO-8859-1 au lieu de UTF-8 (à confirmer par Nissai)

Si tu veux l’astuce .htaccess, voilà ce que tu peux tenter d’ajouter dans ton .htaccess :



Si tu as accès à php.ini tu ajoutes :



Mais chez OVH, je ne pense pas...

Ceci dit, tout ça n’est valable que si ça vient du serveur.

Je crois plutôt que ça vient de l’encodage du fichier de langue... après tout il fonctionne avec le réglage par défaut de modx (ISO-8859-1), ce qui est normal. Pour encoder le fichier en UTF-8 il te faut un éditeur avancé comme PS Pad. Car quand je parle de l’encodage du fichier de langue, ce n’est pas setlocale qui va le changer, mais le format d’encodage du fichier lui-même.

Quand j’aurai le temps, je regarderai ça.

Sacré OVH.... ce n’est pas la première fois que je vois des soucis avec eux... toujours des config spécifiques et parfois un peu opaques !

Très bon hébergeur. SAV excellent. Mais effectivement problème avec leur config...

soit ton serveur est en ISO-8859-1 (et à ce moment là il faudra tenter de modifier .htaccess ou php.ini mais bon pour le deuxième chez OVH je crois que pas possible d’avoir un php.ini custom)

J’ai modifié le .htaccess mais ça ne fonctionne pas mieux. De toute façon, ma page est bien envoyée par le serveur en UTF-8 :

soit ton fichier de langue est encodé lui même en ISO-8859-1 au lieu de UTF-8

J’ai revérifié et téléchargé PS Pad http://www.pspad.com/fr/ puisque notepad pose problème. J’ai bien précisé UTF-8 dans l’encodage, enregistré et mis sur mon site.

Dans la configuration du site, j’ai bien précisé UTF-8 et dans mon fichier de langue la ligne

Ça ne fonctionne pas mieux :

mardi 28 f�vrier 2006 - 17:0

(partie centrale sous un post) et

Ajouter une actualité

(sidebar de droite / "Récemment").

Je dirais que le problème viens d’OVH mais au niveau de la directive setlocale() comme si elle ne prenait pas en compte l’encodage spécifié (en l’occurence UTF-8) : elle garderait une valeur par défaut (ici ISO-8859-1).

[edit]
01/03/2006 21:30 : je viens de contacter OVH. J’attend une réponse. Actullement une page de test est disponible et montre bien que le problème ne viens pas Modx mais bien de strftime et setlocale chez OVH.
[/edit]

Quote from: Guillaume at Mar 01, 2006, 08:23 AM

[edit]01/03/2006 21:30 : je viens de contacter OVH. J’attend une réponse. Actullement une page de test est disponible et montre bien que le problème ne viens pas Modx mais bien de strftime et setlocale chez OVH.[/edit]

Eh bien je m’en doutais...
Je suis d’accord qu’OVH est un bon hébergeur, les dernières offres en date sont excellentes... mais par contre c’est parfois un cauchemard pour faire fonctionner des choses "simples" à cause de leurs config qui sont trop spécifiques et du coup rien ne marche comme ça devrait...

question très bête mais pas toujours inutile.
As tu pensé à régler dans l’administration réglages divers l’encodage?

Bonne remarque surtout qu’une bonne pratique dans MODx c’est de définir le charset dans ton template de la manière suivante, qui est lié avec le charset défini dans le manager :



le "etomite" est un héritage du passé qui va disparaître et sera remplacé par modx_charset, pour les curieux...

@nissai:

As tu pensé à régler dans l’administration réglages divers l’encodage?

Oui, c’est fait mais c’est dans "administration > configuration > réglages site". Sinon, comme je l’ai dit dans mon précédent post, j’ai testé sur une page PHP simple indépendante de mon site modx. Cette page a le même problème.

@davidm:

Bonne remarque surtout qu’une bonne pratique dans MODx c’est de définir le charset dans ton template de la manière suivante, qui est lié avec le charset défini dans le manager :

<meta http-equiv="Content-Type" content="text/html; charset=[(etomite_charset)]" />

Je viens de le changer pour que ce soit plus propre mais avant j’avais préciser UTF-8 à la main :

Après contact avec OVH qui m’a gentil renvoyé bouler vers les sites et forums traitants de PHP, j’ai un semblant de solution...
Il faudrait utiliser la fonction PHP utf8_encode() :

Comme ça, il n’y a pas de problème... L’idéal aurait été d’utiliser la fonction override_function() mais bien évidemment elle est désactivée chez OVH (sécurité oblige).

Si quelqu’un à une idée pour intégrer cette solution sans faire de hack, je pense que ça pourrait être intéressant pour le développement de Modx.

@Modérateur : dois-je créer un nouveau topic (dans ce cas où ?) pour discuter de ce dernier point ?

Merci

Vu les problèmes que j’ai eu pour obtenir une date correcte gérant les accents en UTF-8, j’ai créé un snippet qui permet de récupérer une date (du document courant ou autre) (date de publication, de modification, etc...), de la formater comme on le souhaite et de la convertir en UTF-8 si besoin est (en fonction de l’encodage du site).

J’ai fait un post pour ce snippet.

Moi aussi j’ai ce problème de la date qui n’est pas en français. J’ai essayé les 3 setlocale qui sont proposé ici, que se soit dans le snipets ou dans le fichier de langue, cela ne marche pas.

Il y a uen syntaxe particluière (endehors de la ligne citré sur le sujet) pour le setlocale ?
L’hébergeur peut bloquer cette fonction ?

@upurii : je pense pas que les hébergeurs bloque cette fonction. Quel est ton hébergeur ?