Fichier francais.inc.php utf-8 sans problème d'encodage

Plusieurs fois j’obtenais des problèmes liés à l’encodage de ce fichier notamment en UTF-8.

J’ai pris l’initiative de le transformer en version HTML. Pour ma part, mes problèmes sont disparus depuis.
Je vous livre le fichier transformé.

Edit (27/04/2006) : Guillaume a fourni un fichier encodé en UTF-8 qui fonctionne. Je le remercie.
Vous pouvez le télécharger ci-dessous.

Quand j’ai lu ton post, je me suis demandé ce que tu voulais dire par "transformer en version HTML"... en fait tu as simplement modifié les caractères accentués en entités hmtl (pour ceux qui ne connaissent pas é => é ) ?

D’ailleurs pour ceux que ça intéresse, il existe un outil (et surement d’autres) pour transformer automatiquement ceux-ci.

Le truc bizarre, c’est que normalement utf-8 a rendu obsolète l’utilisation des entités html, précisémment parcequ’il s’agit d’un encodage de caractère universel... Guillaume expliquera ça mieux que moi...

Mais si ça marche tant mieux !
Ceci dit ça veut dire que MODx bug parceque normalement, cela ne devrait pas être nécessaire...

Quote from: Marc at Apr 26, 2006, 03:47 PM

Pour ma part, mes problèmes sont disparus depuis.

j’ai perso jamais eu de problèmes avec mon français.inc.php en full utf-8 (avec des èèééàà ) sur modx v0.9.1
il faut absolument pas généraliser... je suis pas sur que modx bug...????

Installe le plugin BottomButtonBar et dis moi si tu ne rencontre pas de problème.
Cela peut-être du à mon fichier qui serait endommagé. Si c’est le cas, je vais le corriger

Me voilà

Sérieusement, utf-8 ne devrait pas poser ce genre de problème. Les entités sont / étaient utilisées pour que tous les caractères "spéciaux" soient affichés correctement partout dans le monde et quelque soit le navigateur.

Pour la version 0.9.1 j’ai également eu ce type de problème (ça vient de me revenir) mais je ne suis pas passé par les entités html pour le résoudre. J’ai utilisé PSPad pour convertir mon fichier en utf-8 et ensuite je l’ai mis au format Unix (si je me souviens bien ; ça date un peu ).

Je n’ai pas encore fait la mise à jour de mon côté. Je reviens sur ce point dès que je l’ai fait.

J’ai effectué plusieurs fois cette manip aussi avec PSPAD en prenant soin avant d’ouvrir le fichier de configurer PSPAD sans reconnaissance automatique de l’encodage et en le paramétrant sur ANSI.

Ensuite, je suis passé avec l’encodage UTF-8. Cliquer sur le format Linux.
J’obtiens un fichier corrolé qui génére des bugs en local et aussi des anomalies sur les sites hébergés.
Il suffit de vous rendre dans le journal des évènements pour vous apercevoir une liste importante d’erreurs liés à QuickEdit ou encore d’installer le plugin BottomButtonBar pour voir une fenêtre d’alerte s’afficher.

Si de votre coté vous n’obtenez pas d’erreur, je suis preneur de la solution voir de votre fichier. Je préfère utiliser un fichier qui ne contient pas d’entité html. Mais pour le moment, la seule solution qui donne aucun bug reste le fichier où j’ai insérer les entités html en lieu et place des caractères accentués.

Je n’ai aucun soucis en local ni en distant.
Ci joint le fichier de lang en UTF-8.

Merci Guillaume je vais regarder ça...

Merci Guillaume .

Ce fichier fonctionne correctement. Mais j’aimerais, à l’occasion, connaître le moyen de produire ce fichier au bon encodage et comprendre pourquoi je n’y suis pas arrivé.

J’ai modifié mon premier post et retirer le fichier encodé avec des entités html.

Je suis un génie je me vante un peu là ? non !!!

J’ai simplement fait comme décrit dans un de mes posts. J’ai téléchargé la dernière version de Modx puis je l’ai décompressé. J’ai ouvert le fichier francais.inc.php avec PSPad, puis j’ai changé le codage (Format > UTF-8). Il était déjà coché mais je l’ai re sélectionné pour être sûr que c’était bien pris en compte. Ensuite je l’ai enregistré et tout fonctionne.

Je ne sais pas plus que ça pourquoi chez moi ça passe et pas chez toi ...