2010-07-16 2 views
-1

J'écris une application qui sera utilisée en plusieurs langues: 'en', 'de', 'fr', 'es' et 'pl'. J'ai fourni des chaînes de traduction pour chaque chaîne qui doit être traduite, j'ai préparé les fichiers de traduction et les compilés.Problèmes d'application multilingue dans la traduction de modèles

Ensuite, j'ai défini la variable LANGUES et ajouté le LocaleMiddleware dans settings.py. Le problème est que, lorsque j'entre dans la page, disons/admin /, les chaînes fournies sous forme de chaînes sont traduites correctement (j'utilise 'pl' dans Accept-Language), mais les chaînes dans les modèles et les formes (comme les étiquettes et verbose_names) sont affichés dans la langue LANGUAGE_CODE (lorsque je change le code de langue, les modèles sont traduits).

Quelqu'un a une idée, quel est le problème?

+0

duplication possible de [Comment savoir pourquoi Django ignore l'en-tête Accept-Language?] (Http://stackoverflow.com/questions/1658720/how-do-i-tell-why-django-is-ignoring -the-accept-language-header) –

+0

Non, l'affaire est un peu différente ici. Lisez-le attentivement. – mhaligowski

Répondre

0

Je me sers ugettext au lieu de ugettext_lazy. N'oubliez pas d'utiliser ce dernier pour les cordes de Django!

0

Avez-vous essayé

from django.utils.translation import ugettext as _ 

verbose_names = _("Eggs") 
+0

Non. C'est probablement ce qui s'est mal passé. ugettext() traduit les chaînes immédiatement quand elles sont invoquées, dans la langue définie à ce moment-là. Pour les modèles et les formulaires, cela ne se produit qu'une seule fois au moment de l'initialisation. Dans de tels contextes, on devrait plutôt utiliser ugettext_lazy(), qui crée un objet qui effectue la traduction au moment où la valeur est demandée. Voir aussi http://docs.djangoproject.com/fr/1.2/topics/i18n/internationalization/#lazy-translations –

Questions connexes