À priori, strftime() retourne bien la date suivant le format demandé, mais toujours en anglais. Je n'ai pas (encore) réussi à obtenir une date francisé ; mais ça ne retourne pas une chaine vide.
Il est en revanche difficile de manipuler les différentes 'locales'. Ce n'est pas vraiment très claire. entre LC_TIME et LC_ALL d'une part, et 'fr' ou 'French' ou encore 'fr_FR', voire 'fr_FR.UTF8' d'autre part.
Le problème réside dans l'implémentation de l'option de format %e de strftime qui flushe la chaine construite, et renvoit donc une chaine vide.
Et aussi dans le plugin qTranslate qui a du mal à récupérer la bonne locale... sous Win32.
jmparis a écrit: ------------------------------------------------------- > Il est en revanche difficile de manipuler les différentes 'locales'. Ce n'est pas vraiment > très clair entre LC_TIME et LC_ALL d'une part, et 'fr' ou 'French' ou encore 'fr_FR', voire 'fr_FR.UTF8' > d'autre part.
On ne peut rien définir avec certitude. cela va dépendre de plusieurs paramètres du serveur ET du système d'exploitation. Il faut effectuer des essais et même, éventuellement, différentier local et hébergeur.
J'ai du pot, setlocale(LC_ALL, "French" fonctionne correctement en local, chez Free et chez 1and1.
Est-ce que quelqu'un a le même comportement sur son serveur ???
Note: J'ai essayé 2 versions de PHP 5.2.7 et 5.2.8 avec le même comportement. Pour le 2) faire le test avec la locale 'English' donne le même résultat.
À priori, en local, "%e" retourne une chaine vide au lieu du quantième du jour du mois sur deux caractères ; le premier étant une espace sur inférieur à 10.
J'ai remarqué aussi que les options %g et %G ne fonctionnent pas non plus. Décidément !
A noter que dans mon cas, chaque fois que je met une de ces options dans la chaine de format, avec d'autres options. Le résultat est une chaine vide. Ce qui diffère de votre serveur local, Free.fr ou 1to1... en plus grave !
Quand au setlocale(); alors là, c'est à s'arracher les cheveux :-) Seules les chaines littérales 'French', 'English', 'Spanish' marchent sur mon serveur. Toutes autres valeurs telles que 'fr_FR' ou 'fr-FR' ne passent pas....
« Tous les caractères modificateurs ne sont pas toujours supportés par toutes les bibliothèques C. Dans ce cas, ils ne seront pas supportés par PHP non plus. De plus, toutes les plates-formes ne supportent pas les timestamps négatifs, et vos dates pourraient être limitées par le début de l'époque Unix. Cela signifie que %e, %T, %R et %D (et peut être d'autres) et les dates antérieures au 1er Janvier 1970 ne fonctionneront pas sous Windows, sur certaines distributions de Linux, et sur certains systèmes d'exploitation. »
Donc, sous Windows, %e, %T, %R et %D et peut être d'autres ne fonctionnent pas.
La valeur retournée par setlocale() dépend du système sur lequel PHP est installé. C'est pourquoi Windows retourne "French_France.1252", Free sous Linux retourne "French" et 1and1 retourne une chaine vide. Cette valeur de retour n'est pas celle que j'envoie : French dans les trois cas.
Cela doit dépendre de ce que vous avez déclaré comme jeu de caractère (charset) dans vos entêtes de page et d'une éventuel conflit avec un jeu de caractère par défaut dans php.ini et d'un autre éventuel conflit avec le codage de votre éditeur de script php.
1) Merci pour l'extrait de php.net, je n'avais pas trouvé ce passage...très important !! Du coup, j'en ai profité pour l'instant pour changer tous les %e par %d. En attendant de faire un wrapper pour %e dans le plugin qTranslate2.
2) Oui, du coup j'ai fait un petit wrapper (immonde) dans le plugin pour utiliser la forme littérale des langues sélectionnées. 'French', 'German', 'Italian', etc... Et çà marche parfaitement sous Wamp. Est-ce que çà marchera sous une distrib Linux...mystère ;-)
3) L'entête de page est chargé avec charset=<?php bloginfo('charset'); ?>.Soit 'UTF-8' en l'occurrence. Donc pour l'instant, j'ai contourné le problème en utilisant la fonction htmlentities() très pratique!
La meilleure solution est sans doute de mettre un autre charset; quoi que 'UTF-8' normalement çà supporte TOUS les caractères. Je ne suis pas très au fait des meilleurs charset...un ISOquelquechose ??
En tout cas, un GRAND merci, pour m'avoir aidé (et expliqué) toutes ces "subtilités" !!!
jmparis a écrit: ------------------------------------------------------- > 3) L'entête de page est chargé avec charset=<?php bloginfo('charset'); ?>.Soit 'UTF-8' > en l'occurrence.
Attention à bien comprendre de quoi on parle lorsque l'on dit « entête » de page.
Lorsque le serveur envoie une page au navigateur et bien que celui-ci « essaye » de trouver quel est le jeu de caractères utilisé, il est beaucoup plus simple de dire, le plus tôt possible, avec quel jeu de caractères la page est envoyée. On peut le faire par la première instruction d'une page php avec, par exemple : <?php header("content-type:text/html; charset=iso-8859-1"
Il faut bien avoir présent à l'esprit que si vous ne forcez pas cet envoi d'entête, le serveur le fait à votre place et vous ne savez pas quel jeu est envoyé ; par exemple, Pour Wampserver, aucun jeu n'est défini, par défaut, dans G:\wamp\bin\apache\apache2.2.11\bin\php.ini :
Merci, pour ce mini cours sur le charset :-) Je ne savais pas du tout comment tout cela fonctionnait.
J'ai donc mis du 'iso-8859-1' partout :-) Dans php.ini; et dans la balise http-equiv (ceinture et bretelles).
Néanmoins, je dois encore garder mon appel à htmlentities(); pour avoir mes caractères accentués. Du coup, pour l'instant j'ai remis 'utf8' comme charset (le même que pour MySQL).
Comme l'auteur du plugin travaille sur une Debian; il n'a pas les mêmes problèmes de charset, locale que moi...les tests doivent donc être complémentaires.