ユーザー設定ページの一部の文字列を変更しようとしています。管理 -\u003e サイトテキスト に移動し、関連するキーを検索しましたが、見つかったテキストがないというメッセージが表示されたため、探している特定のテキストをカスタマイズできませんでした。
キーはこちらで定義されているため、有効であると確信しています。
その後、ターゲット言語を英語に切り替えましたが、user.username.short_instructions を検索しても結果は得られませんでした。さらに、user.username.title、user.preferences.title、filters.latest.title などの他の文字列を検索しようとしましたが、うまくいきませんでした。
関連するエラーはないようです。リクエストの結果に基づくと、バックエンドの問題である可能性があります。
インストールしたプラグインがこの特定の部分を変更したとは思いませんが、問題が解決するかどうかを確認するために、後ですべての非公式プラグインを削除してみます。
セーフモードを使用して一時的にカスタマイズを無効にして、それが機能するかどうかを確認できます。
この件に関してアップデートがあります。問題がバックエンドにあることを断定的に確認できます。コードを調べていると、特定の行に気づきました。
驚いたことに、私のインスタンスで I18n.exists?(\"js.user.username.short_instructions\", :en) を実行すると false が返されます。
このコード行を削除したところ、user.username.short_instructions を検索できるようになりました。
I18n.exists?(\"js.user.username.short_instructions\", :en) が false を返す理由がわかりません。問題が私のインスタンス固有のものなのか、それとも Discourse のより一般的な問題なのかを判断するために、さらに調査する可能性があります。
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
特にビルドに関する問題です。ビルド中にこれらのすべてのものを解析し、テーブルに格納しますが、インスタンスではまだ行われていないようです。
コンソール再構築をお勧めします。
@sam、ご返信ありがとうございます。異なる方法で3つのDiscourseインスタンスをデプロイしましたが、すべて同じ問題が発生するため、インストールに問題があるとは考えていません。
プラグインを再確認したところ、そのうちの1つがロケールファイル（plugins/XXXX/config/locales/client.en.yml）を作成しており、その内容は以下のとおりでした。
en:
js:
このファイルを削除したところ、問題は解決しました。I18nの実装について簡単に調査したところ、ロード中に翻訳をマージするためにdeep_mergeが使用されていることがわかりました。
# 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
上記のYAMLは次のように解析されます。
{"en": {"js": null}}
これにより、マージ後にen.jsキーの下のコンテンツ全体が削除されます。プラグイン開発者として、この問題は私自身のコーディングエラーに起因するものであり、その責任はすべて私にあることを理解しています。しかし、Discourseには、特にDiscourseがすでにロケールファイルを検査するための設計（こちらで見られるように）を持っていることを考慮すると、このような発生に対して警告するための追加チェックから恩恵を受けることができると信じています。
見つけられてよかったです！
開発チームに連絡して、認識してもらいます。
素晴らしい指摘ですね。解決策についてアップデートしていただきありがとうございます @pangbo。
ここにチェックを追加することは間違いなく可能ですが、私の記憶が正しければ、このチェッカーは RSpec テスト中にのみ使用されます。それはあなたのケースに役立ったでしょうか？
もし適切な場所が見つかれば、この null ケースに対する実行時チェックを実装することには間違いなく前向きです。
おっしゃる通りです。これらのチェックが実行時に実行されるという、不当な仮定をしていました。GitHubリポジトリを検索したところ、これらのチェックは単にrakeタスク内で呼び出されているようです。
ここにチェックを追加しても、私が遭遇した問題を事前に特定することはできなかったでしょう。おそらく最も簡単な解決策は、ドキュメントで開発者にこの実践を避けるように注意喚起することです 
このトピックをどうしましょうか？開発者向けのガイダンスのようですが、Dev に移動しますか？