J'ai rencontré un problème étrange lors de la traduction des chaînes (dans l'administrateur) à l'aide de GetText de Django : exécutez localement le serveur DEV Toutes les traductions sont affichées correctement dans l'administrateur, mais lorsque le projet est déployé sur Le serveur de production certains strings ne sont pas traduits du tout. Je ne peux pas déterminer aucun système derrière lequel les chaînes sont affectées et que non! Pour vous donner une impression, par exemple. Un modèle est défini comme: à l'aide de Dev Server Le nom du modèle apparaît correctement dans différentes langues de l'administrateur, sur le serveur de production non! Cela affecte certains modèles, d'autres non ... Cela me rend vraiment fou, puisque j'ai à peine une idée sur la façon de déboguer cela ...
3 Réponses :
Quelques possibilités:
FUZZY
- _ () résout à
ugettext au lieu de ugettext_lazy
Ils ne sont pas marqués comme flou, mais pouvez-vous peut-être nommer certaines raisons pour lesquelles le serveur ne verrait pas les messages compilés (ils sont dans l'application DirS). Vous n'avez pas encore lu ce que le problème de l'utilisation de ugettext au lieu de ugettext_lazy est?
D'accord. résolu maintenant. J'étais hérité d'un modèle qui utilisait ugettext , tandis que l'enfant utilisait ugettext_lazy , alors j'ai eu ce mélange étrange! Merci!
Ce que je voulais dire était que peut-être ex. Les messages compilés n'ont pas été commités au serveur. Rien de magique, juste que de telles choses triviales se produisent parfois.
@Thomaszzielinski merci! Dans mon cas, j'avais utilisé un fichier générique Python .gitignore qui ignore *. Mo fichiers! Un problème aussi stupide: P
Belle réponse à toutes sortes de possibilités. Cette réponse il y a 5 ans peut encore sauver mon cul.
J'ai eu un problème similaire et mis à part ce que Tomasz Zielinski a souligné que je devais faire les modifications suivantes:
dans Paramètres.py P>
project
your_app
your_other_app
locale
en_US
LC_MESSAGES
sv_SE
LC_MESSAGES
Si vous développez sous Windows et que l'instance de production est Linux, le problème peut être: Windows n'est pas sensible à la casse pendant que Linux est sensible à la casse, en termes de nommage des chemins de fichiers.
Par exemple, un nom de dossier local doit être:
zh_has au lieu de zh_hans
-
pt_br au lieu de pt_br
Peut-être
ugettext_lazy contreugettext ?