Estou tentando modificar certas strings na página de preferências do usuário. Naveguei para Admin -\u003e Textos do Site e procurei pelas chaves relevantes. No entanto, não consegui personalizar o texto específico que estava procurando, pois ele me informou que nenhum texto foi encontrado.
Tenho certeza de que a chave é válida, pois ela está definida aqui:
Em seguida, mudei o idioma de destino para inglês, mas ainda assim não obtive resultados para user.username.short_instructions. Além disso, tentei procurar outras strings, como user.username.title, user.preferences.title e filters.latest.title, mas sem sucesso.
Parece que não há erros relacionados e, com base nos resultados da solicitação, pode ser um problema de backend.
Embora eu não acredite que os plugins que instalei tenham modificado essa área específica, tentarei remover todos os plugins não oficiais mais tarde para ver se isso resolve o problema.
Tenho algumas atualizações sobre este assunto. Agora posso confirmar definitivamente que o problema está no backend. Ao examinar o código, notei uma linha específica:
Para minha surpresa, executar I18n.exists?("js.user.username.short_instructions", :en) na minha instância retorna false.
Não tenho certeza por que I18n.exists?("js.user.username.short_instructions", :en) está retornando false. Posso investigar mais para determinar se o problema é específico da minha instância ou um problema mais geral com o Discourse.
Parece um problema geral na sua instância do 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
Particularmente algo em torno da compilação. Durante a compilação, analisamos todas essas coisas e as colocamos em tabelas, de alguma forma isso ainda não aconteceu na sua instância.
@sam, obrigado pela sua resposta. Implantei três instâncias do Discourse usando métodos diferentes e todas apresentam o mesmo problema, o que me leva a acreditar que não é um problema de instalação.
Ao reexaminar meus plugins, descobri que um deles criou um arquivo de local (plugins/XXXX/config/locales/client.en.yml) com o seguinte conteúdo:
en:
js:
Excluir este arquivo resolveu o problema. Após uma breve investigação sobre a implementação do I18n, descobri que deep_merge é usado para mesclar traduções durante o carregamento:
# 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
O YAML acima é analisado como:
{"en": {"js": null}}
Isso resulta na exclusão de todo o conteúdo sob a chave en.js após a mesclagem. Como desenvolvedor de plugins, entendo que esse problema decorre de um erro meu de codificação e sou totalmente responsável por ele. No entanto, acredito que o Discourse poderia se beneficiar de verificações adicionais para alertar contra tais ocorrências, especialmente considerando que o Discourse já possui um design para inspecionar arquivos de local, como visto aqui.
Ótima observação, obrigado por nos atualizar sobre a solução @pangbo.
Nós definitivamente poderíamos adicionar uma verificação aqui, embora, se bem me lembro, este verificador é usado apenas durante os testes do RSpec. Isso teria ajudado no seu caso?
Definitivamente aberto a ter uma verificação em tempo de execução para este caso de null, se pudermos encontrar um bom lugar para colocá-lo.
Você está correto. Fiz uma suposição injustificada de que essas verificações seriam executadas em tempo de execução. Ao pesquisar no repositório do GitHub, parece que essas verificações são invocadas exclusivamente em uma tarefa rake: discourse/lib/tasks/i18n.rake at main · discourse/discourse · GitHub
Adicionar verificações aqui não teria identificado preventivamente o problema que encontrei. Talvez a solução mais direta seja alertar os desenvolvedores contra essa prática na documentação
