我今天在论坛上看到了这个
我认为 Discourse 是对的：不存在 dashboard.problem.sidekiq_check。存在
这些内容在此处被引用：
但看起来 Discourse 引用的是该问题检查的名称。
3 个赞
通过以下方式修复：
2 个赞
你能帮我理解一下这个修复是如何工作的吗？我看到 server.en.yml 中的翻译键和 override_key 都已重命名，以匹配检查的名称。我想知道为什么两者都需要重命名以匹配文件名。使用 sidekiq 而不是 sidekiq_check 难道不行吗？我怀疑是否仍然是检查的名称（而不是 override_key）决定了显示哪个警告，因此我想知道 dashboard.problem.queue_size 这个覆盖项是否有效，或者它是否像 dashboard.problem.sidekiq 一样，只是一段永远不会显示的文本。
2 个赞
是的，我们在一个单独的文件中引用了问题检查标识符：
因此，上述 PR 确保翻译中的字符串与问题检查文件名相匹配，该文件名会被转换为该标识符，即 sidekiq_check。在翻译字符串中使用 sidekiq 不起作用，因为它与标识符不匹配。
1 个赞
抱歉，我还是不太明白。
queue_size 也不匹配文件名/标识符，就像 sidekiq 不匹配一样。我仍然不明白为什么在那种情况下这不是一个问题。
这是因为有另一条代码路径直接使用标识符，而不是使用其中一个覆盖键吗？所以，与其添加第三个与文件名匹配的翻译键，你改为让 sidekiq 使用基于标识符的键？这是一种同时支持覆盖情况和标识符情况的二合一解决方案？
如果是这样，我不明白为什么需要将 dashboard.problem.sidekiq_check 作为覆盖键传递。其他翻译键与文件名匹配的问题检查都不需要这样做。那么，为什么这里需要覆盖呢？
1 个赞
是的，没错。
其实不需要，如果我们在 sidekiq_check.rb 的第 8 行使用 return problem，应该也能正常工作。两者是等价的。（我保留覆盖引用是为了让当时的 PR 改动更小。）
1 个赞
在开发环境中，有没有什么我可以轻松修改以触发 dashboard.problem.queue_size 错误消息的设置？
我以为将
def massive_queue?
Jobs.queued >= 100_000
end
改为 >= 0 会触发该错误——但这却导致了 dashboard.problem.sidekiq_check。
1 个赞
在系统规范中更容易复现。我尝试这样做，并暴露出更多问题，这应该能修复它们：
1 个赞
在翻译 Discourse 界面时，有时查看文本的上下文会很有帮助，这就是为什么我有时会尝试触发此类警告，并且一直希望能更轻松地做到这一点。在系统测试中可以实现吗？还是说你所说的“更容易”仅与确保代码按预期工作这一上下文有关？
是的，您可以使用系统规范（system specs）来查看上下文中的翻译。
如果您拥有 Discourse 的开发环境，可以执行以下操作：
- 在您希望在浏览器中查看的系统规范中添加
pause_test语句 - 以有头模式（headful mode，即使用完整浏览器）运行该系统规范（默认情况下，规范以无头模式运行）
例如，对于上述规范，我在 admin_notices_spec.rb 的第 47 行添加了 pause_test，然后使用以下命令运行该规范：
PLAYWRIGHT_HEADLESS=0 bin/rspec spec/system/admin_notices_spec.rb:47
这会启动一个浏览器并暂停在该特定屏幕上：
1 个赞