Eu vi isto em um fórum hoje
E eu acho que o Discourse está certo: não existe dashboard.problem.sidekiq_check. Existem
que são referenciados aqui:
Mas parece que o Discourse se refere ao nome dessa verificação de problema em vez disso.
3 curtidas
Corrigido por:
2 curtidas
Você pode me ajudar a entender como a correção funciona? Vejo que a chave de tradução em server.en.yml e o override_key foram renomeados para corresponder ao nome da verificação. Me pergunto por que ambos precisavam ser renomeados para corresponder ao nome do arquivo. Não deveria funcionar com sidekiq em vez de sidekiq_check também? Me pergunto se ainda é o nome da verificação, em vez do override_key, que influencia qual aviso é exibido, então me pergunto se a sobrescrita dashboard.problem.queue_size funciona ou se é um texto que nunca é exibido, assim como dashboard.problem.sidekiq não era.
2 curtidas
Sim, referimo-nos em um arquivo separado ao identificador de verificação de problemas:
Portanto, a PR acima garante que a string nas traduções corresponda ao nome do arquivo de verificação de problemas, que é convertido para esse identificador, ou seja, sidekiq_check. Usar sidekiq nas strings de tradução não estava funcionando, pois não correspondia ao identificador.
1 curtida
Desculpe, mas ainda não entendo muito bem.
queue_size também não corresponde ao nome do arquivo/identificador, assim como sidekiq não correspondia. E ainda não entendo por que isso não é um problema nesse caso.
Será que isso ocorre porque há outro caminho de código que usa diretamente o identificador em vez de uma das chaves de substituição? Então, em vez de adicionar uma terceira chave de tradução correspondente ao nome do arquivo, você alterou sidekiq para usar a chave baseada no identificador? Uma espécie de solução dois-em-um que suporta tanto o caso de substituição quanto o caso de identificador?
Se for isso, não entendo por que dashboard.problem.sidekiq_check precisa ser passado como chave de substituição. As outras verificações de problema onde a chave de tradução corresponde ao nome do arquivo não precisam disso. Então, por que uma substituição é necessária aqui?
1 curtida
Sim, correto.
Não é necessária; isso provavelmente funcionaria bem se fizéssemos return problem na linha 8 de sidekiq_check.rb. Eles são equivalentes. (Mantive a referência à substituição para fazer uma alteração menor naquele PR na época.)
1 curtida
Existe algo que eu possa alterar facilmente em uma instalação de desenvolvimento para acionar a mensagem de erro dashboard.problem.queue_size?
Eu pensei que mudar
def massive_queue?
Jobs.queued >= 100_000
end
para >= 0 resultaria nesse erro sendo acionado — mas isso resultou em dashboard.problem.sidekiq_check
1 curtida
É mais fácil reproduzir nas especificações do sistema. Tentei fazer isso e isso revelou mais alguns problemas, isso deve corrigi-los:
1 curtida
Para traduzir a interface do Discourse, às vezes é útil ver o texto em seu contexto, é por isso que às vezes tento acionar esses avisos e sempre tenho interesse em aprender a fazer isso de forma mais fácil. Isso é possível com os testes de sistema? Ou o seu “mais fácil” está relacionado apenas ao contexto de garantir que o código funcione como esperado?
Sim, você pode usar especificações de sistema para ver as traduções em contexto.
Se você tiver um ambiente de desenvolvimento para Discourse, pode fazer algo como isso:
- adicione uma instrução
pause_testna especificação de sistema que deseja visualizar em um navegador - execute essa especificação de sistema no modo headful, ou seja, com um navegador completo (por padrão, as especificações são executadas no modo headless)
Por exemplo, para a especificação acima, adicionei pause_test na linha 47 de admin_notices_spec.rb e depois executei a especificação com:
PLAYWRIGHT_HEADLESS=0 bin/rspec spec/system/admin_notices_spec.rb:47
Isso abriu um navegador e pausou naquela tela específica:
1 curtida