Je tente de modifier certaines chaînes sur la page des préférences utilisateur. J’ai navigué vers Admin -\u003e Textes du site et recherché les clés pertinentes. Cependant, je n’ai pas pu personnaliser le texte spécifique que je cherchais car il m’a indiqué qu’aucun texte n’a été trouvé.
Je suis raisonnablement certain que la clé est valide, car elle est définie ici :
J’ai ensuite changé la langue cible pour l’anglais, mais j’ai toujours obtenu aucun résultat pour user.username.short_instructions. De plus, j’ai essayé de rechercher d’autres chaînes, telles que user.username.title, user.preferences.title et filters.latest.title, mais sans succès.
Il semble qu’il n’y ait pas d’erreurs liées, et d’après les résultats de la requête, il pourrait s’agir d’un problème backend.
Bien que je ne pense pas que les plugins que j’ai installés aient modifié cette zone particulière, je vais essayer de supprimer tous les plugins non officiels plus tard pour voir si cela résout le problème.
J’ai quelques mises à jour concernant ce problème. Je peux maintenant confirmer de manière définitive que le problème vient du backend. En examinant le code, j’ai remarqué une ligne particulière :
À ma grande surprise, l’exécution de I18n.exists?("js.user.username.short_instructions", :en) sur mon instance renvoie false.
Je ne suis pas sûr de la raison pour laquelle I18n.exists?("js.user.username.short_instructions", :en) renvoie false. Je vais peut-être enquêter davantage pour déterminer si le problème est spécifique à mon instance ou s’il s’agit d’un problème plus général avec Discourse.
Semble être un problème général avec votre instance Discourse.
sam@arch discourse % bin/rails c
Loading development environment (Rails 8.0.4)
[1] pry(main)> I18n.exists?("js.user.username.short_instructions", :en)
=> true
Particulièrement quelque chose autour de la construction. Pendant la construction, nous analysons toutes ces choses et les plaçons dans des tableaux, d’une manière ou d’une autre, cela ne s’est pas encore produit dans votre instance.
Je recommanderais une reconstruction de la console.
@sam, merci pour votre réponse. J’ai déployé trois instances de Discourse en utilisant différentes méthodes, et toutes présentent le même problème, ce qui me fait croire qu’il ne s’agit pas d’un problème d’installation.
En réexaminant mes plugins, j’ai découvert que l’un d’eux avait créé un fichier de locale (plugins/XXXX/config/locales/client.en.yml) avec le contenu suivant :
en:
js:
La suppression de ce fichier a résolu le problème. Après une brève investigation de l’implémentation I18n, j’ai constaté que deep_merge est utilisé pour fusionner les traductions lors du chargement :
# File activesupport/lib/active_support/vendor/i18n-0.4.1/i18n/backend/simple.rb, line 31
31: def store_translations(locale, data, options = {})
32: locale = locale.to_sym
33: translations[locale] ||= {}
34: data = data.deep_symbolize_keys
35: translations[locale].deep_merge!(data)
36: end
Le YAML ci-dessus est analysé comme suit :
{"en": {"js": null}}
Cela entraîne la suppression de tout le contenu sous la clé en.js après la fusion. En tant que développeur de plugin, je comprends que ce problème découle de ma propre erreur de codage, et j’en assume l’entière responsabilité. Cependant, je pense que Discourse pourrait bénéficier de vérifications supplémentaires pour avertir de telles occurrences, d’autant plus que Discourse dispose déjà d’une conception pour inspecter les fichiers de locale, comme on peut le voir ici.
Bien vu, merci de nous tenir informés de la solution @pangbo.
Nous pourrions certainement ajouter une vérification ici, bien que si je me souviens bien, ce vérificateur ne soit utilisé que pendant les tests RSpec. Cela vous aurait-il aidé dans votre cas ?
Je suis tout à fait ouvert à avoir une vérification à l’exécution pour ce cas null, si nous pouvons trouver un bon endroit pour la placer.
Vous avez raison. J’ai fait l’hypothèse injustifiée que ces vérifications s’exécuteraient à l’exécution. En recherchant dans le dépôt GitHub, il semble que ces vérifications ne soient invoquées que dans une tâche rake :
L’ajout de vérifications ici n’aurait pas permis d’identifier préventivement le problème que j’ai rencontré. La solution la plus simple serait peut-être de mettre en garde les développeurs contre cette pratique dans la documentation
