Sto tentando di modificare alcune stringhe nella pagina delle preferenze dell’utente. Ho navigato su Admin → Testi del sito e ho cercato le chiavi pertinenti. Tuttavia, non sono riuscito a personalizzare il testo specifico che stavo cercando poiché mi è stato comunicato che non sono stati trovati testi.
Sono ragionevolmente certo che la chiave sia valida, poiché è definita qui:
Ho quindi cambiato la lingua di destinazione in inglese, ma ancora nessun risultato per user.username.short_instructions. Inoltre, ho tentato di cercare altre stringhe, come user.username.title, user.preferences.title e filters.latest.title, ma senza successo.
Sembra che non ci siano errori correlati e, in base ai risultati della richiesta, potrebbe trattarsi di un problema backend.
Anche se non credo che i plugin che ho installato abbiano modificato quest’area specifica, in seguito tenterò di rimuovere tutti i plugin non ufficiali per vedere se questo risolve il problema.
Ho alcuni aggiornamenti riguardo a questa questione. Posso ora confermare definitivamente che il problema risiede nel backend. Esaminando il codice, ho notato una riga particolare:
Con mia sorpresa, l’esecuzione di I18n.exists?("js.user.username.short_instructions", :en) sulla mia istanza restituisce false.
Non sono sicuro del motivo per cui I18n.exists?("js.user.username.short_instructions", :en) restituisce false. Potrei indagare ulteriormente per determinare se il problema è specifico della mia istanza o un problema più generale con Discourse.
Sembra un problema generale della tua istanza 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
In particolare qualcosa relativo alla build. Durante la build analizziamo tutte queste cose e le inseriamo nelle tabelle, in qualche modo questo non è ancora successo nella tua istanza.
@sam, grazie per la tua risposta. Ho distribuito tre istanze di Discourse utilizzando metodi diversi e tutte presentano lo stesso problema, il che mi porta a credere che non si tratti di un problema di installazione.
Riesaminando i miei plugin, ho scoperto che uno di essi ha creato un file locale (plugins/XXXX/config/locales/client.en.yml) con il seguente contenuto:
en:
js:
L’eliminazione di questo file ha risolto il problema. Dopo una breve indagine sull’implementazione di I18n, ho scoperto che deep_merge viene utilizzato per unire le traduzioni durante il caricamento:
# 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
Lo YAML sopra viene analizzato come:
{"en": {"js": null}}
Ciò comporta l’eliminazione dell’intero contenuto sotto la chiave en.js dopo l’unione. In qualità di sviluppatore di plugin, comprendo che questo problema deriva da un mio errore di codifica e ne sono pienamente responsabile. Tuttavia, credo che Discourse potrebbe beneficiare di controlli aggiuntivi per avvisare contro tali occorrenze, soprattutto considerando che Discourse ha già una progettazione per ispezionare i file locali, come si vede qui.
Ottima osservazione, grazie per averci aggiornato sulla soluzione @pangbo.
Potremmo sicuramente aggiungere un controllo qui, anche se se non ricordo male questo checker viene utilizzato solo durante i test RSpec. Ti avrebbe aiutato nel tuo caso?
Sono decisamente aperto ad avere un controllo in fase di runtime per questo caso null, se riusciamo a trovare un buon posto dove inserirlo.
Hai ragione. Ho fatto un’ipotesi ingiustificata che questi controlli venissero eseguiti in fase di runtime. Dopo aver cercato nel repository GitHub, sembra che questi controlli vengano invocati esclusivamente all’interno di un’attività rake: discourse/lib/tasks/i18n.rake at main · discourse/discourse · GitHub
L’aggiunta di controlli qui non avrebbe identificato in via preventiva il problema che ho riscontrato. Forse la soluzione più semplice è mettere in guardia gli sviluppatori contro questa pratica nella documentazione
