10
votes

Localités mixtes dans les rails I18N

rails en quelque sorte mélange mes paramètres régionaux et je n'ai absolument aucune idée de la raison. La plupart de mes chaînes traduites fonctionnent comme prévu, mais pour certains, il mélange les lieux.

Fait intéressant, cela ne se produit que sur l'un de nos systèmes. Passager à exécution spécifique avec Apache.

Lorsque vous utilisez Webrick, mince ou autonome de passagers sur mon système de développement, tout va bien.

C'est ce que j'ai dans mon Application.rb : xxx

ceci est dans applic_controller.rb : xxx

( Je ressens des problèmes sur les pages où @current_client est nil et la pièce el / code> est exécuté).

donc, je J'utilise fondamentalement le : de locale. Lors de la montrage d'une erreur de validation sur un formulaire, je rencontre des traductions mélangées comme ceci:

ist zu kurz (Nicht weniger als 6 zeichen) et traduction manquante: fr.aciverecord.errors.custom.password_format

Comme vous pouvez le constater, le message d'erreur de la première validation de défaillance est traduit comme prévu, car le second message d'erreur tente d'accéder à la traduction anglaise (qui n'existe pas).

Je soupçonne un problème avec une chargement paresseuse de chaînes traduites, même avant que le avant_filter est exécuté.

Tous les indices que cela pourrait arriver? < P> Pour l'enregistrement: Ceci est des rails 3

edit :

Je viens de découvrir que cela dépend de l'environnement utilisé. Lorsque vous utilisez l'environnement de développement, tout va bien. Lors de l'utilisation de l'environnement de production (ou d'un environnement de production), j'effectue le comportement décrit ci-dessus.

EDIT 2 :

J'ai découvert encore plus : Il dépend spécifiquement de config.cache_classes . Lorsqu'il est défini sur true , je vois les traductions mixtes. Lorsqu'il est réglé sur false (comme dans l'environnement de développement typique), I18N fonctionne comme prévu.

Edit 3

Peut-être Ceci est lié au bug suivant?

https://rails.lighthouseApp.com/projects/8994-Ruby-on-Rails/tickets/5522

EDIT 4 :

Ceci est lié au bogue mentionné ci-dessus, le problème est due à des classes de modèle chargées avec impatience, qui utilisent des chaînes I18N, mais le chargement de la classe désireuse se produit avant l'initialisation I18N, d'où les traductions ne sont pas trouvées. Il y a même un autre bogue à ce sujet:

https://rails.lighthouseApp.com/projects/8994-Ruby-on-Rails/tickets/6353

Malheureusement, les rails gars n'ont pas réussi à inclure la solution dans le récent 3.0 .4 Libérer (autant que je puisse dire). Par conséquent, j'essaie de trouver une solution de contournement comme celle-ci (dans ma configuration de la demande): xxx

malchanceux, cela ne fonctionne pas. Des indices?


2 commentaires

Le mélange apparaît généralement lorsqu'une traduction est manquante dans votre localisation actuelle.


Eh bien, la chose amusante est que la traduction allemande est la complète (l'application est en allemand) et la traduction anglaise manque la plupart des cordes. Comme je l'ai écrit, cela fonctionne sur une autre machine, d'où les traductions sont réellement présentes. Et les paramètres régionaux par défaut sont de, alors pourquoi les rails essaient-ils d'utiliser en toute façon?


4 Réponses :


0
votes

Avez-vous essayé de jouer avec les paramètres de la méthode Passenger Spawn? Essayez de la définir à conservateur, de cette façon, le passager devrait se comporter de la même manière que mince.


4 commentaires

C'est plus un commentaire qu'une réponse


Cela n'aide pas, comme je l'ai mentionné ci-dessus, je me suis réduit dans le réglage config.cache_classes , c'est-à-dire qu'il ne dépend pas du serveur spécifique utilisé.


Je comprends que ma "réponse" était plus un commentaire que toute autre chose, mais je pense que cela peut être lié au paramètre Passenger SpawnMethod. Selon la documentation des passagers: "Lorsque la méthode intelligente est utilisée, la phalusion passager tentera de mettre en cache n'importe quel code-cadre (par exemple Ruby sur des rails) et du code d'application pour une période limitée.".


En outre, vous avez vérifié que mince ne présente pas ce comportement, cela doit donc être quelque chose lié à la mise en cache de classe, mais spécifique au passager. Je pense que cela vaut la peine de vérifier si la configuration de la SpawneMethod sur "conservateur" aide ou non.



2
votes

Voici ma solution de contournement finale, qui semble fonctionner (mettre cela dans appliquer.rb code> ou l'un de vos fichiers de configuration de l'environnement, au besoin):

 # THIS IS A WORKAROUND FOR A I18N BUG IN RAILS!
 # Only required when cache_classes is set to true
 # See https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6353
 config.before_eager_load do
   I18n.locale = :de
   I18n.load_path += Dir[Rails.root.join('config', 'locales', 'de.yml').to_s]
   I18n.reload!
 end


1 commentaires

HM, vient de passer à la version 3.0.10 qui ne résout pas le problème et même cette solution de contournement n'aide plus ...



0
votes

La mise à niveau vers les rails 3.0.5 devrait résoudre ce problème et des problèmes similaires I18N.

Voir: https://rails.lighthouseApp.com/ Projets / 8994-Ruby-On-Rails / Billets / 6353


0 commentaires

14
votes

Ce problème peut également occuler au cas où vous auriez un gemme qui utilise également I18N (j'avais ce problème avec Active_admin). Rails met à la fin de l'I18N pour que le gem soit en mesure de pouvoir utiliser ce même chemin_paths.

Ce que j'ai fait était d'ajouter ceci à la production.rb: xxx


3 commentaires

Merci! Le "antérieur_eauger_load" a cessé de fonctionner, mais cela corrige en effet les problèmes pour moi.


J'ai rencontré le même problème avec les rails 3.2.3. Ce correctif fonctionne toujours.


J'ai rencontré le même problème avec les rails 5.0.6. Ce correctif fonctionne toujours. :)