J’ai vu ceci sur un forum aujourd’hui
Et je pense que Discourse a raison : il n’y a pas de dashboard.problem.sidekiq_check. Il y a
qui sont référencés ici :
Mais il semble que Discourse fasse plutôt référence au nom de cette vérification de problème.
Corrigé via :
Pouvez-vous m’aider à comprendre comment le correctif fonctionne ? Je vois que la clé de traduction dans server.en.yml et la clé override_key ont été renommées pour correspondre au nom de la vérification. Je me demande pourquoi les deux devaient être renommées pour correspondre au nom du fichier. N’aurait-il pas également fonctionné avec sidekiq au lieu de sidekiq_check ? Je me demande si c’est toujours le nom de la vérification, plutôt que la clé override_key, qui influence l’avertissement affiché, donc je me demande si la substitution dashboard.problem.queue_size fonctionne ou si c’est un texte qui n’est jamais affiché, tout comme dashboard.problem.sidekiq ne l’était pas.
Oui, nous faisons référence dans un fichier séparé à l’identifiant de vérification de problème :
Ainsi, la PR ci-dessus s’assure que la chaîne dans les traductions correspond au nom de fichier de la vérification de problème, qui est converti en cet identifiant, c’est-à-dire sidekiq_check. L’utilisation de sidekiq dans les chaînes de traduction ne fonctionnait pas, car elle ne correspondait pas à l’identifiant.
Désolé, je ne comprends toujours pas vraiment.
queue_size ne correspond pas non plus au nom de fichier/identifiant, tout comme sidekiq ne le faisait pas. Et je ne comprends toujours pas pourquoi ce n’est pas un problème dans ce cas-là.
Est-ce parce qu’il existe un autre chemin de code qui utilise directement l’identifiant au lieu de l’une des clés de remplacement ? Ainsi, au lieu d’ajouter une troisième clé de traduction correspondant au nom de fichier, vous avez modifié sidekiq pour utiliser la clé basée sur l’identifiant ? Une sorte de solution deux-en-un prenant en charge à la fois le cas de remplacement et le cas d’identifiant ?
Si c’est le cas, je ne comprends pas pourquoi dashboard.problem.sidekiq_check doit être transmis comme clé de remplacement. Les autres vérifications de problèmes où la clé de traduction correspond au nom de fichier n’en ont pas besoin. Alors pourquoi un remplacement est-il nécessaire ici ?
Oui, c’est exact.
Il n’est pas nécessaire, cela fonctionnerait probablement très bien si nous avions fait return problem à la ligne 8 de sidekiq_check.rb. Ils sont équivalents. (J’ai conservé la référence au remplacement pour avoir une modification plus petite dans ce PR à l’époque.)
Y a-t-il quelque chose que je peux modifier facilement sur une installation de développement pour déclencher le message d’erreur dashboard.problem.queue_size ?
Je pensais que changer
def massive_queue?
Jobs.queued >= 100_000
end
en >= 0 déclencherait cette erreur, mais cela a plutôt provoqué dashboard.problem.sidekiq_check.
C’est plus facile à reproduire dans les spécifications du système. J’ai essayé de le faire et cela a révélé d’autres problèmes, cela devrait les corriger :
Pour la traduction de l’interface Discourse, il est parfois utile de voir le texte dans son contexte, c’est pourquoi j’essaie parfois de déclencher ce genre d’avertissements et je suis toujours intéressé par l’apprentissage de méthodes pour le faire plus facilement. Est-ce possible avec les specs système ? Ou votre « plus facile » ne concerne-t-il que le contexte de la vérification que le code fonctionne comme prévu ?
Oui, vous pouvez utiliser les spécifications système pour voir les traductions dans leur contexte.
Si vous disposez d’un environnement de développement pour Discourse, vous pouvez procéder comme suit :
pause_test dans la spécification système que vous souhaitez visualiser dans un navigateurPar exemple, pour la spécification ci-dessus, j’ai ajouté pause_test à la ligne 47 de admin_notices_spec.rb, puis j’ai exécuté la spécification avec :
PLAYWRIGHT_HEADLESS=0 bin/rspec spec/system/admin_notices_spec.rb:47
Cela a lancé un navigateur et s’est arrêté sur cet écran spécifique :
