Fichiers langues sous format .po .mo ?

Bonjour

Je me demandais si ce n'était pas plus intéressant d'avoir les fichiers langues sous .po et .mo ?
En tout cas, je vois la facilité de traduction sous Wordpress avec poedit, c'est clairement pas une corvée.

Là, je suis en train de faire les fichier lang de mes plugins et je dois vous dire que ça me fait c*ier, à moins qu'il existe un éditeur pour ce format bizarre mais je ne pense pas.

Alors pourquoi ne pas passer sous ce système ? Problème de dépendances du serveur ? Trop gourmand ?

Réponses

  • Jerry WhamJerry Wham Member
    novembre 2013 modifié
    C'est pas si évident à utiliser comme système. Et tu es dépendant à nouveau d'un service tiers.
    Et ajouter un index de traduction est beaucoup plus facile quand tu crées un nouveau thème que de passer par poEdit.
  • J'ai vu que la librairie pouvait être lancé de façon indépendante (je sais pas si je m'explique bien, mais pas besoin de dépendance sur le serveur en incluant les fichiers de gettext dans les répertoires : https://launchpad.net/php-gettext/).

    Ensuite, je trouve beaucoup, mais alors beaucoup plus rapide l'utilisation de poEdit, et surtout pas besoin d'ouvrir un éditeur de code, d'assigner des variables L_MACHIN_CHOSE.
    Parce que ça va pour quelques variables mais alors ça devient lourd et surtout faut être créatif pour bien les nommer histoire de pas se perdre, déjà que c'est lourd de trouver des noms sympa pour des fonctions php... :p

    Quelques liens :
    http://www.grafikart.fr/tutoriels/php/internationaliser-site-gettext-104
    http://maxime.sh/2012/06/utilisation-pratique-de-gettext-avec-php/
    http://blog.lingohub.com/developers/2013/07/php-internationalization-with-gettext-tutorial/#Setting_up_the_PHP_to_use_gettext
  • Jerry WhamJerry Wham Member
    novembre 2013 modifié
    Je l'utilise avec cakephp et je ne trouve pas ça pratique du tout. Si tu oublies une traduction, c'est tout une galère pour l'ajouter. Ça fonctionne un coup sur deux.
    Et ce n'est pas éditable avec un éditeur basique. Il faut utiliser le logiciel poEdit qui ne fonctionne pas bien sur toutes les plateformes (mac os en particulier).

    Pour ce qui est de trouver des noms, tu mets L_+nom en anglais.
  • Bizarre... Sous Wordpress, ça tourne sans soucis et sous mon Mac, je n'ai aucun problèmes.

    Je crois qu'on va pas être d'accord sur ce sujet.
    En plus, en terme de performances, il semblerait qu'avec gettext, ce soit plus rapide.

    Et en lecture rapide du code, on voit directement dans le fichier .php les mots utilisés. Si pas de fichiers langue, il utilise le contenu directement. Je vois vraiment que des avantages pour une localisation aisée et rapide. Le codeur écrit simplement son echo avec un alias, sans se soucier et après, un scan et hop on traduit tout.

    Je trouve la méthode avec les array vraiment lourde.

    Peut être que Stéphane pourrait venir donner son point de vue. Savoir pourquoi ce choix ?
  • C'est vrai qu'on lit souvent que gettext est plus rapide. M'enfin, la méthode de Stéphane utilise un tableau php tout ce qu'il y a de plus basique et je ne pense pas que cela plombe drastiquement les perf.
    De plus
    Seulement l’extension gettext n’est rapide qu’à une seule condition : Redémarrer le serveur Web à chaque fois que l’on met à jour le fichier .po, pour vider le cache.
    (...)
    Avec le recul, le problème que je craignais s’est avéré vrai : Les fichiers de langue ne sont pas assez stables sur un site Web pour ne demander qu’un seul redémarrage de temps en temps. C’est d’autant plus vrai lorsqu’on a 10 serveurs Web à redémarrer à chaque fois.
    ce qui est quand même galère surtout si on est sur un mutualisé.
  • LE truc que j'ai découvert à poEdit (linux) c'est qu'il est possible de scanner les fichiers à la recherche de nouvelle chaine à traduire. Bien pratique lorsqu'on part de zéro.

    J'ai un string de l'array

  • StéphaneStéphane Member, Former PluXml Project Manager
    @Hamtaro: Je suis en train d'étudier tout ça. J'avais pas mal d'aprioris négatifs sur l'utilisation des .po, mais à force de creuser j'y vois effectivement pas mal d'avantages. Me reste à faire quelque benchmarks pour mesurer les perfs (cpu, utilisation mémoire). Après l'impact sur l'existant (code de PluXml et plugins) est assez gros, mais cela reste faisable et comme on est en train de repenser l'interface d'administration ça serait l'occasion d'y inclure cette évolution. Mais pour le moment on y est pas encore.

    @JerryWham: J'ai la solution technique pour ne pas avoir à redemarrer le serveur apache en cas de modification d'un .po Je l'ai testé est ça fonctionne très bien.

    @flipflip: Le scan des sources pour trouver les chaines de traduction est effectivement un gros point positif pour maintenir les fichiers qui ne m'a pas échappé également.

    De façon générale l'utilisation des fichiers .po repose soit sur l'extension gettext qui doit être installé sur le serveur, soit sur une librairie php qu'il faut inclure dans les sources. Si l'extension n'est pas dispo sur l'hébergeur, il faut basculer sur la lib php. J'ai fait quelques tests également avec ce fonctionnement et ça marche très bien.

    edit: les 1ers benchmarks ne sont pas en faveur de l'utilisation de .po. La consommation cpu est assez importante (et ça explose avec la lib php) et même au niveau de la conso mémoire ce n'est pas très concluant par rapport à la solution PluXml

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • S'il n'y a pas une gestion du cache poussée, gettext plombe les perf car elle rescanne tout.

    Pour la solution qui évite de redémarrer, je veux bien un petit lien... :P
  • Alors il faudrait peut être faire en sorte que la traduction puisse se faire simplement au sein des fichiers, sans passer par un éditeur de texte ?
    Genre par un tableur ou je ne sais quoi ?

    Histoire d'avoir comme poEdit : une case source et en face une case traduction. Parce que, je dois mal m'y prendre, mais rédiger avec les => etc c'est lourd et long... :p
  • StéphaneStéphane Member, Former PluXml Project Manager
    Jerry Wham a écrit:

    Pour la solution qui évite de redémarrer, je veux bien un petit lien... :P

    Voilà le bout de code que j'ai écrit pour mes tests, qui permet de switcher entre l'utilisation de l'extension php_gettext si dispo sinon la librairie php gettext (à mettre dans un dossier /gettext). Il permet également de prendre en compte la modification d'un fichier .po sans avoir à redémarrer apache. Les fichiers .po et .mo sont à mettre dans /lang/fr_FR/LC_MESSAGES/ avec le nom de la locale.
    /gettext
         /gettext.inc
         /gettext.php
         /streams.php
    /lang
        /fr_FR
            /LC_MESSAGES
                  /fr_FR.po
                  /fr_FR.mo
    
    <?php
    
    # gettext settings
    $locale = "fr_FR";  # the locale 
    $locales_root = "./lang";  # locales directory
    $domain = $locale; #  .po/.mo file name without the extension
    $encoding = "UTF-8"; # file encoding
    
    # update .mo if needed because we don't want to restart apache after .po update
    $filename = "$locales_root/$locale/LC_MESSAGES/$domain.mo"; # path to the .mo file that we should monitor
    $mtime = filemtime($filename); # check modification time
    $filename_new = "$locales_root/$locale/LC_MESSAGES/{$domain}_{$mtime}.mo"; # new unique .mo file 
    if (!file_exists($filename_new)) { # check if we have created it before: if not, create it now, by copying the original
    	copy($filename,$filename_new);
    }
    $domain_new = "{$domain}_{$mtime}"; # compute the new domain name
    
    if(!function_exists('_')) {
    	# if gettext extension isn't available
    	require_once(__DIR__.'/gettext/gettext.inc');
    	T_setlocale(LC_MESSAGES, $locale);
    	T_bindtextdomain($domain, $locales_root);
    	T_bind_textdomain_codeset($domain, $encoding);
    	T_textdomain($domain);
    } else {
    	# with php_gettext extension
    	setlocale(LC_ALL, $locale);
    	setlocale(LC_TIME, $locale);
    	putenv("LANG=$locale");
    	bindtextdomain($domain_new,$locales_root);
    	bind_textdomain_codeset($domain, $encoding);
    	textdomain($domain_new);
    }
    
    header("Content-type: text/html; charset=$encoding");
    
    echo _('Hello World');
    echo "<br />";
    echo _('New article');
    echo "<br />";
    echo _('Title');
    echo "<br />";
    echo _('Content');
    $n = 1;
    echo ngettext('Comment', 'Comments', $n);
    
    ?>
    

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • Cool. Merci Stéphane.
Connectez-vous ou Inscrivez-vous pour répondre.