Problèmes PHP Gettext (comme non-thread-safe?)

Question

Je souhaite commencer à utiliser gettext pour gérer mes traductions sur des projets Web (PHP 5). Comme il s’agit d’un standard largement utilisé et de bonne réputation, il semble être le meilleur choix.

Cependant, j'entends aussi des propos incohérents à propos du serveur et de l'absence de thread-safe. Qu'est-ce que cela signifie pour mes projets qui l'utilisent alors? Depuis que je construis des choses que beaucoup de gens utilisent, il est très important que mon code fonctionne.

Parlons-nous de problèmes mineurs (comme ceux qui utilisent encore PHP 4) ou de problèmes majeurs tels que la distribution et l’installation de gettext sur Websevers étant faibles?

Answer 1

Le problème des threads ne s'applique que si l'on utilise PHP incorporé (le mod-php d'Apache par exemple) et si le serveur qui utilise des threads (comme le serveur Apache avec worker-mpm) est exécuté.

Le problème de sécurité des threads ne vous concerne donc pas si:

1. vous utilisez le serveur NGINX (il n’utilise pas de threads.)
2. Vous utilisez Apache (avec ou sans MPM fileté) et PHP en mode fastcgi
3. Vous utilisez Apache avec un MPM sans thread (en tant que prefork-MPM) et PHP en mode mod-php.

Donc, la plupart des utilisateurs d'Apache par défaut ne devraient pas craindre que gettext ne soit pas thread-safe, car l'installation d'Apache par défaut dans la plupart des distributions utilise des préforks-MPM non-threadés!

P.S. De même, n'oubliez pas qu'Apache sous Windows est threadé.

Answer 2

Je pense que jouer un peu plus avec la partie des commentaires du manuel php devrait donner plus d'informations ... l'un des commentaires du manuel sur la section gettext

  

La bibliothèque GNU gettext fonctionne sur un   par processus, pas par thread.   Cela signifie que dans un multi-utilisateur   paramètres tels que le serveur Web Apache   cela ne fonctionnera qu'avec un MPM prefork   (c’est-à-dire un processus par utilisateur). Ouvrier   et les autres MPM filetés ne fonctionneront pas.

     

De plus, de nombreux utilisateurs contrôlent GNU.   gettext en définissant l'environnement système   des variables telles que LANG. Ceci n'est pas un   bonne solution pour un serveur web   environnement dû à une course évidente   condition.

http://www.php.net/manual/fr/gettext .setup.php

Answer 3

J'ai eu le même problème avec PHP 5.6.30 VC11 Theard Safe sous Windows 10. Solution de contournement trouvée et résolution de ce problème ici de sirio3mil.

Apparemment, PHP avec TS ne peut accéder qu’au dossier de la langue locale. Ainsi, lorsque setlocale et la fonction putenv sont appelées avec une autre langue que celle du système, les dossiers avec .mo et .po ne peuvent pas être lus.

La solution de contournement consiste à avoir un seul dossier de langue avec la langue du système et plusieurs paires de fichiers .mo / .po pour chaque langue traduite. Le domaine sera défini avec la langue souhaitée.

Exemple avec le français suisse, l'allemand et l'italien:

Structure du dossier

  

\ Locale \ fr_CH \ LC_MESSAGES

     

  
• fr_CH.mo + fr_CH.po // langue du système
  
• de_CH.mo + de_CH.po
  
• it_CH.mo + it_CH.po
  

Code

$lang = 'fr_CH' or 'de_CH' or 'it_CH'

bindtextdomain($lang, '.\Locale');
textdomain($lang);
bind_textdomain_codeset($lang, 'UTF-8');
setlocale (LC_ALL, $lang);
putenv('LC_ALL=' . $lang);