Les dates affichées sont en anglais

Passe pas un JavaScript ou avec une boucle pour que le mois soit bon...

Ton truc est vachement long pour donner une date

Bonsoir,

Pourtant ca devrait marcher, la locale fr_FR est installée sur le système:

# locale -a
C
en_US.utf8
fr_FR.utf8
POSIX

Les dates et calendriers sont toujours en français.

Dans les FAQ, la question a déjà été posée et il semble que ce soit une question de paramétrage du serveur PHP, et voici la réponse :

Je rencontre un problème de configuration des dates dans GRR : les noms des jours et des mois s’affichent en anglais alors que tout le reste de l’application est en français.

Cela tient sans doute à la configuration du serveur PHP concernant les "locales". Parmi les "locales" testées par GRR dans le fichier /include/language.inc.php (fr_FR, fr_FR@euro, fr_FR.ISO8859-1, French, france ...) aucune n’est disponible dans votre système.

Si vous avez accès au serveur, essayez en mode console, la commande "locale -a" afin de savoir quelles sont les locales disponibles.

Une solution consiste alors à ajouter sur votre serveur une locale reconnue par GRR sur votre système (recherche sur Google pour savoir comment faire).

Par exemple, sur une distribution linux basée sur debian, la commande suivante, suivie d’un redémarrage du serveur apache devrait suffire :
apt-get install locales-all

A noter également qu’on rencontre le problème sur certains serveurs qui ont bien le support fr_Fr mais pas par défaut. La variable setlocale de php ne semble prendre en compte que la valeur par défaut de la variable locale du système. Le problème est alors résolu en mettant par défaut fr_FR.

Eh bien je suis peut-être aveugle, mais désolé ça ne marche pas, c'est toujours en anglais. J'ai déjà utilisé ce logiciel et le calendrier apparaissait bien en français.
Voici ce que cela donne :
http://espacelangues.lescigales.org/
Voilà un exemple en français :
http://espacelangues.olympe-network.com/

Si j'ai bien compris, il y a plusieurs types de "locales" différentes qui ne sont pas forcément toutes installées sur le serveur, certaines n'étant pas reconnues par GRR, d'où le conseil qu'ils donnent de le installer toutes d'après ce que j'ai lu. Je vous renvoie à mon précédent message de 9h23 ce même jour ci-dessus dans lequel j'ai inséré la réponse trouvée dans la FAQ de GRR quant à ce problème.
Il semblerait aussi que lorsque la locale fr_Fr est disponible, il faut qu'elle le soit par défaut, sinon ça ne marche pas (voir ci-dessus là encore).
Je ne suis qu'utllisateur de ce logiciel et je ne fais que constater sans avoir plus de compétences techniques que ça.
Voici le site de GRR : http://grr.mutualibre.org/
Ce n'est pas que ce problème soit absolument fondamental, mais le moins qu'on puisse dire c'est que cela ne fait pas très "propre", et vu qu'il s'agit d'un site pour gérer un espace multimédia destiné à l'enseignement des langues vivantes, je vois tout de suite des sensibilités "non-anglophones" protester vigoureusement contre l'invasion de l'anglais...

Avez vous demandé des précisions aux gens qui gèrent ce logiciel ?

Je viens de regarder le code de grr + de faire quelques tests sur le serveur

Le code suivant renvoie bien une date francaise:

setlocale(LC_TIME, 'fr_FR.utf8');
echo strftime("%A %e %B", time()); // affiche samedi 13 novembre

Malheureusement GRR semble avoir été écrit avant tout pour un public francais et le support UTF8 / langues différentes est particulier:
- la traduction de textes se fait selon des tableaux (au lieu d'utiliser gettext et donc setlocale())
- la traduction des données relatives au temps se fait grâce à gettext (setlocale(LC_TIME))
- l'exploitation d'UTF8 doit être configurée manuellement comme le montre ce bout de code de la version 197d:

if ($unicode_encoding) {
 
               if (setlocale(LC_TIME,'fr_FR.utf-8') == TRUE) $ok = 'yes';
 
               else if (setlocale(LC_TIME,'fr_FR.utf8') == TRUE) $ok = 'yes';
 
               else if (setlocale(LC_TIME,'fr-utf-8') == TRUE) $ok = 'yes';
 
            } else {

source: includes/language.inc.php

Et la variable à configurer se trouve dans includes/config.inc.php:

# Positionner la valeur $unicode_encoding à 1 pour utiliser l'UTF-8 dans toutes les pages et dans la base
# Dans le cas contraire, les textes stockés dans la base dépendent des différents encodage selon la langue selectionnée par l'utilisateur
# Il est fortement conseillé de lire le fichier notes-utf8.txt à la racine de cette archive
$unicode_encoding = 0;

Mais cela semble modifier également l'usage de la base qui est à convertir (la méthode est expliquée dans la documentation).

J'ai déjà vérifié le fichier de configuration en question et la variable
$unicode_encoding = 0;
est déjà sur 0.
J'avais vu cette explication dans les archives, mais ce n'est visiblement pas ça.

Ok. J'avais sans doute mal lu, j'avais compris qu'il fallait garder la valeur 0.
J'ai mis 1 et apparemment ça marche.
Je n'ai pas touché à rien sur la base, vu que ça a l'air de fonctionner comme ça, mais à suivre.
Je n'ai pas tout compris (je ne suis pas informaticien) mais tant que ça marche...
Merci beaucoup  !

Trop calé pour moi tout ça même si y a clairement quelque-chose qui coince car la question semble revenir souvent.
En attendant, j'ai le, calendrier en français mais les é sont remplacés par ?
et quand je règle ça dans firefox (iso 8859-1) ça ne reste pas dès que je recharge la page ou que je me reconnete.

Pas forcément Eric, la notation if (quelque chose) revient automatiquement à demander si if (quelque chose != false) donc ca passe..

Ce qui aurait été peut être plus souhaitable dans ce code est d'avoir quelque chose qui permette de lister les locales installées sur le serveur au lieu de chercher 'au pif'.