La fonction setlocale() peut avoir changé sur votre serveur (comme sur le mien) sans pour autant avoir été prévenu !
C’est ce qui arrive quand on est sur un serveur mutualisé qui est maintenu à jour régulièrement. Pour récupérer le nom de la locale, il existe plusieurs solutions.
Via SSH
Vous avez un accès SSH à votre serveur ? SUPER ! Il vous suffit de taper cette commande pour voir toutes les locales disponibles :
# locale -a
ou
# php locale -a
Via PHP (serveur)
Pour que cela fonctionne, il faut qu’une des fonctions system(), shell_exec(), exec() soit activée ! Si ce n’est pas le cas (pour des raisons de sécurité), passez à la dernière solution.
system("locale -a")
Via… bah rien, à l’aveugle en fait ! 😀
Ce n’est pas vraiment une solution… Il s’agit surtout de mettre toutes les possibilités et de croiser les doigts pour que ça marche. Normalement ça doit marcher ! Si à ce stade ça ne fonctionne pas, contactez votre hébergeur afin d’être certain que les locales sont installées ! (on ne sait jamais) Tant que vous y êtes, demandez les noms des locales 🙂
setlocale(LC_TIME, 'fr_FR.UTF8', 'fr.UTF8', 'fr_FR.UTF-8', 'fr.UTF-8')
J’en profiterai pour citer PHP Manual :
If Your linux box returns false on setlocale (so setlocale is not working as expected):
var_dump(setlocale(LC_TIME, ‘fr_FR.UTF8’, ‘fr.UTF8’, ‘fr_FR.UTF-8’, ‘fr.UTF-8’));
make sure the glibc package is installed 🙂
Notes supplémentaires
Si vous utilisiez la fonction utf8_encode() lors de vos affichages de date, vous devrez penser à les retirer. En effet, l’UTF-8 étant renseigné dans la locale, il n’y a plus besoin de les convertir.
Cela vaut également (surtout ?) pour les utilisateurs de SMARTY. Plus besoin d’ajouter le modificateur |utf8_encode à la fin de vos dates 🙂 (pareil pour les {html_select_date} !)