We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 33175
    • 711 Posts
    Tutoriel : Mise en place de l’UTF-8 sous Modx


    Ce tutoriel a pour but d’utiliser Modx en UTF-8.
    Je vais essayer d’être le plus générique possible afin de pouvoir traduire ce tutoriel ultérieurement.
    Les exemples seront donnés en français mais devraient pouvoir s’appliquer à toutes les langues.


    Toute petite introduction
    L’UTF-8 permet d’afficher tout type de caractère accentué ou non ou spécifique à chaque langue (je pense ici au "ç" français, aux caractères grecs, japonais...).


    La configuration de MySQL
    Il est important de bien configurer MySQL pour l’UTF-8 (mal configuré, la longueur des champs semble "rétrécir").
    L’idéal est de créer une base de données en UTF-8 mais les hébergeurs le permettent rarement.
    Je reviendrai sur la meilleur méthode pour contourner ce point dès que possible.

    Note :
    A partir de la version 5 de MySQL, il n’y a aucun soucis si la base de données est en UTF-8. En revanche, les versions précédentes semblent poser quelques soucis. Utilisez donc la version 5 si vous le pouvez.


    Les fichiers de langues
    Pour utiliser UTF-8 dans l’interface de Modx, il faut au préalable convertir le fichier de langue à l’aide d’un éditeur de texte gérant l’UTF-8.

    Note:
    Voir en fin du tutoriel les fichiers de langue français en UTF-8. Ces fichiers sont à renommer en "francais.inc.php".

    Note :
    Wordpad sous Windows le gère mais mal. En l’utilisant vous aurez des erreurs à l’affichage. Personnellement, j’utilise l’éditeur de texte gratuit PSPad.

    Ouvrez le fichier de traduction /manager/includes/lang/francais.inc.php
    Modifiez l’encodage en UTF-8. Avec PSPad : Menu "Format, cocher UTF-8.
    Pour que l’UTF-8 soit localisé en français, insérez
    setlocale (LC_ALL, 'fr_FR');
    juste après les commentaires de l’entête (juste après la ligne "**/").
    Enregistrez le
    Fermez le fichier

    Si cela ne semble pas fonctionner, vous pouvez également essayer de remplacer la ligne de code précédente par celle ci dessous. Cependant, elle peut ne pas fonctionner car "fr_FR.utf-8" n’est pas normalisée. Attention donc si vous changez d’hébergeur.
     setlocale (LC_ALL, 'fr_FR.utf-8');



    L’application Modx
    Maintenant, il faut configurer Modx pour utiliser l’UTF-8. Tout d’abord, il faut se connecter au manager en tant qu’administrateur. Puis, dans "Administration" > "i]Configuration[/i]", sous l’onglet "Réglage du site", sélectionnez à l’aide de la liste déroulante "Unicode (UTF-8) - utf-8" au niveau du paramètre "Encodage des caractères". Validez et vous verrez alors Modx utiliser l’UTF-8.


    Les modèles
    Le modèle par défaut utilisé pour le site (côté utilisateur) est "Default template". Il utilise l’ISO-8859-1. Nous allons le modifier.
    Tout d’abord, il faut l’éditer à partir de "Ressources" > "Gestion ressources" et ensuite l’onglet "Gestion modèles". Ensuite, sélectionnez le modèle.
    Dans le code html, il faut chercher la ligne
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    et la remplacer par
    <meta http-equiv="Content-Type" content="text/html; charset=[(etomite_charset)]" />


    La variable de modèle [(etomite_charset)] est remplacée, lors l’affichage de la page, par l’encodage paramétré côté administration. Voir le point précédent.

    Note :
    Modx est à l’origine basé sur Etomite, ce qui explique le nom de la variable de modèle [(etomite_charset)]. Pour en savoir plus sur les variables de modèle, la documentation a été traduite.


    Ressources, fonctions PHP et UTF-8
    Certaines ressources posent quelques problèmes avec l’UTF-8. Actuellement, je n’ai recensé qu’un seul problème, lié au formatage des dates, lors de l’affichage des noms de jours et de mois contenant des accents. Ce problème est lié à une fonction PHP.

    Snippets fonctionnant mal avec l’UTF-8:

    • NewsListing : jusqu’à la version 6.3.3 (dernière en date). Le problème concerne le formatage des noms des dates comportant des accents. Il sera résolu dans la prochaine version.
      NewsListing 6.4.x (actuellement en béta) ne pose plus ce problème.
    • MaxiGallery : jusqu’à la version 0.3 : problèmes sur les titres et les descriptions. Résolue à partir de la version 0.4.


    Note :
    Pour les ressources, je vais contacter au fur et à mesure les développeurs afin de régler les divers problèmes rencontrés et pouvoir utiliser l’UTF-8 sans soucis.

    Note :
    Toutes informations complémentaires sur l’UTF-8, les fonctions PHP et les ressources ne fonctionnant pas en UTF-8 seront appréciables.
    Ce tutoriel sera mis à jour en fonction de vos remarques.



    Merci à nissai pour la relecture, à xeres pour son "tip" et à grunt_lord pour les précisions sur MySQL.
      Sorry for my english. I&#39;m french... My dictionary is near me, but it&#39;s only a dictionary !
      • 32847
      • 171 Posts
      Merci Guillaume,
      si certains ont des problèmes avec les accents des dates, ils peuvent essayer
       setlocale (LC_ALL, 'fr_FR.utf-8');
        • 33175
        • 711 Posts
        Quote from: xeres at Mar 30, 2006, 11:32 PM

        Merci Guillaume,
        si certains ont des problèmes avec les accents des dates, ils peuvent essayer
         setlocale (LC_ALL, 'fr_FR.utf-8');

        Merci de l’info, elle peut effectivement dépanner. A noter tout de même que "fr_FR.utf-8" n’est pas toujours reconnu car non normalisé. C’est souvent un ajout des hébergeurs pour faciliter la gestion de l’UTF-8.
        Je vais le rajouter wink
          Sorry for my english. I&#39;m french... My dictionary is near me, but it&#39;s only a dictionary !
          • 22221
          • 283 Posts
          Merci Guillaume grin,

          Tes explications sont très claires.
          En plus cela m’a permis de réaliser que j’avais des accents mal codés dans les champs "titre" , "titre long" et "résumé" de mes documents. Il faut penser à utiliser les code HTML (ex &egrave; à la place de é) dans ces champs aussi tongue
            • 11413
            • 203 Posts
            passer les champs par un petit parser qui remplacerait les oublis serait bien aussi. Et même inversement, de cette manière on écrit en langage clair et la machine fait la conversion automatiquement!
              Blaise Bernier

              www.medialdesign.com - Solutions for small business, hosting, design and more!
              • 6726
              • 7,075 Posts
              Excellent tuto Guillaume ! Merci grin

              Etant donné l’importance de ce sujet, je passe ce tuto en sticky.
                .: COO - Commerce Guys - Community Driven Innovation :.


                MODx est l&#39;outil id
                • 2472
                • 151 Posts
                Attention tout de même... si votre site tourne sur une base de données mySQL 4.0 ou inférieure il y aura toujours des problèmes entre modx et la bd puisqu’elle ne gère pas correctement l’utf... bon à savoir.

                  A thing of beauty is a joy forever ( John Keats)
                  • 33175
                  • 711 Posts
                  Quote from: OncleBen31 at Mar 31, 2006, 06:58 AM

                  En plus cela m’a permis de réaliser que j’avais des accents mal codés dans les champs "titre" , "titre long" et "résumé" de mes documents. Il faut penser à utiliser les code HTML (ex &egrave; à la place de é) dans ces champs aussi tongue
                  Je viens de regarder le code source de mes pages et effectivement les caractères ne sont pas des entités html.

                  Quote from: grunt_lord at Mar 31, 2006, 08:50 AM

                  passer les champs par un petit parser qui remplacerait les oublis serait bien aussi. Et même inversement, de cette manière on écrit en langage clair et la machine fait la conversion automatiquement!
                  FCKEditor et TinyEdit le font automatiquement. D’où l’intérêt de les utiliser. Mais il est vrai qu’il ne serve que pour le corps du document et pas pour les titres.

                  J’estime que c’est une erreur de Modx de ne pas les convertir à l’affichage uniquement, côté frontend. Je viens de faire la demande pour que cela soit inclus dans une prochaine version. La 0.92 j’espère laugh

                  Quote from: Avander_be at Mar 31, 2006, 11:32 AM

                  si votre site tourne sur une base de données mySQL 4.0 ou inférieure il y aura toujours des problèmes entre modx et la bd puisqu’elle ne gère pas correctement l’utf... bon à savoir.
                  Effectivement. Je n’ai pas abordé ce point car je manque de temps pour produire des informations convenables à partir de la documentation MySQL. Il semblerait que ces limitations ne sont pas plus génantes que cela, du moins tant qu’on n’upgrade pas MySQL en version 5.

                  Quote from: davidm at Mar 31, 2006, 10:23 AM

                  Excellent tuto Guillaume ! Merci grin

                  Etant donné l’importance de ce sujet, je passe ce tuto en sticky.
                  Merci de ton soutien smiley Pour le premier tuto de ma vie, ça me fait plaisir grin.
                    Sorry for my english. I&#39;m french... My dictionary is near me, but it&#39;s only a dictionary !
                    • 21595
                    • 159 Posts
                    une petite erreur orthographique

                    Wordpad sous Windows le gère mais mal. En l’utilisant vous aurez des erreurs à l’affichage. Personnellement, j’utilise l’éditeur de texte gratuit PSPad.

                      • 33175
                      • 711 Posts
                      Merci nissai smiley c’est maintenant rectifié.
                        Sorry for my english. I&#39;m french... My dictionary is near me, but it&#39;s only a dictionary !