Ho visto questo su un forum oggi
E penso che Discourse abbia ragione: non esiste dashboard.problem.sidekiq_check. Ci sono
che sono citati qui:
Ma sembra che Discourse si riferisca invece al nome di quel controllo del problema.
3 Mi Piace
Corretto tramite:
2 Mi Piace
Puoi aiutarmi a capire come funziona la correzione? Vedo che la chiave di traduzione in server.en.yml e la override_key sono state rinominate per corrispondere al nome del controllo. Mi chiedo perché entrambe abbiano dovuto essere rinominate per corrispondere al nome del file. Non avrebbe funzionato anche con sidekiq invece di sidekiq_check? Mi chiedo se sia ancora il nome del controllo, invece della override_key, a influenzare quale avviso viene visualizzato, quindi mi chiedo se l’override dashboard.problem.queue_size funzioni o se si tratti di un testo che non viene mai mostrato, proprio come dashboard.problem.sidekiq non lo era.
2 Mi Piace
Sì, facciamo riferimento in un file separato all’identificatore del controllo problema:
Quindi la PR sopra garantisce che la stringa nelle traduzioni corrisponda al nome del file del controllo problema, che viene convertito in quell’identificatore, ovvero sidekiq_check. Usare sidekiq nelle stringhe di traduzione non funzionava, non corrispondeva all’identificatore.
1 Mi Piace
Mi dispiace, ma non ho ancora capito bene.
queue_size non corrisponde al nome del file/identificatore, proprio come non corrispondeva sidekiq. E non capisco ancora perché questo non sia un problema in quel caso.
È perché c’è un altro percorso di codice che utilizza direttamente l’identificatore invece di una delle chiavi di override? Quindi, invece di aggiungere una terza chiave di traduzione corrispondente al nome del file, hai modificato sidekiq per usare la chiave basata sull’identificatore? Qualcosa come una soluzione due-in-uno che supporta sia il caso di override sia quello dell’identificatore?
Se è così, non capisco perché dashboard.problem.sidekiq_check debba essere passato come chiave di override. Gli altri controlli dei problemi in cui la chiave di traduzione corrisponde al nome del file non ne hanno bisogno. Quindi perché è necessario un override qui?
1 Mi Piace
Sì, esatto.
Non è necessario, probabilmente funzionerebbe bene se avessimo usato return problem alla riga 8 di sidekiq_check.rb. Sono equivalenti. (Ho mantenuto il riferimento all’override per avere una modifica più contenente in quella PR all’epoca.)
1 Mi Piace
C’è qualcosa che posso modificare facilmente in un’installazione di sviluppo per far comparire il messaggio di errore dashboard.problem.queue_size?
Pensavo che modificare
def massive_queue?
Jobs.queued >= 100_000
end
in >= 0 avrebbe scatenato quell’errore, ma ha invece prodotto dashboard.problem.sidekiq_check.
1 Mi Piace
È più facile riprodurlo nelle specifiche del sistema. Ho provato a farlo e questo ha evidenziato alcuni altri problemi, questa dovrebbe risolverli:
1 Mi Piace
Per tradurre l’interfaccia di Discourse, a volte è utile vedere il testo nel suo contesto, motivo per cui a volte cerco di attivare tali avvisi e sono sempre interessato a imparare come farlo più facilmente. È possibile farlo con gli spec di sistema? O il tuo “più facile” si riferisce solo al contesto di garantire che il codice funzioni come previsto?
Sì, puoi utilizzare le specifiche di sistema per visualizzare le traduzioni nel contesto.
Se hai un ambiente di sviluppo per Discourse, puoi fare qualcosa del genere:
- aggiungi un’istruzione
pause_testnella specifica di sistema che desideri visualizzare in un browser - esegui quella specifica di sistema in modalità headful, ovvero con un browser completo (per impostazione predefinita, le specifiche vengono eseguite in modalità headless)
Ad esempio, per la specifica sopra, ho aggiunto pause_test alla riga 47 di admin_notices_spec.rb e poi ho eseguito la specifica con:
PLAYWRIGHT_HEADLESS=0 bin/rspec spec/system/admin_notices_spec.rb:47
Questo ha avviato un browser e si è bloccato su quella specifica schermata:
1 Mi Piace