Bien j'ai effectué la sauvegarde de la base de données pour la convertir en utf8 et je me suis aperçu qu'elle était déjà à ce format. Pourtant j'ai des ? au lieu des accents si je mets en utf8 dans le fichier de config.
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'.
Ah oui les ? faut toucher à la base de données. Galère ça. Retour à l'anglais faute de temps. On verra plus tard c'est pas terrible comme ça mais franchement ça devient lourd.
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.
La valeur retournée est une chaine de caractère en cas de succès...
Valeur de retour Retourne la nouvelle configuration locale, ou FALSE si la localisation n'est pas implémentée sur votre plate-forme, si la variable de localisation n'existe pas, ou si la catégorie spécifiée n'est pas valide.
Ils auraient dû écrire...
if (setlocale(LC_TIME,'fr_FR.utf-8') !== false) $ok = 'yes';
else if (setlocale(LC_TIME,'fr_FR.utf8') !== false) $ok='yes';
else if (setlocale(LC_TIME,'fr-utf-8') !== false) $ok = 'yes';
Mais d'après la documentation concernant le(s) paramètre(s) $locale...
Si locale est un tableau ou bien est suivi par des paramètres additionnels, alors chaque élément du tableau ou chaque paramètre tente d'être défini comme nouvelle locale jusqu'à ce qu'un réussisse. Cela est pratique si la locale est connue sous différents noms sur des systèmes différents ou bien pour prévoir une autre valeur en cas de non disponibilité de la locale choisie.
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 !
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.
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:
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).
Les locales installées précédemment sur le serveur: /var/www/grrv2/include# locale -a C fr_FR.utf8 POSIX
J'ai rajouté comme locale fr_FR.iso88591: # locale -a C français french fr_FR fr_FR.iso88591 fr_FR.utf8 POSIX* * Maintenant les semaines et les mois sont en français.)
Cela semble correspondre à ce ue j'avais trouvé dans la FAQ (voir plus haut).
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...