hook_update_N（）でt（）を使用するか、カスタムモジュールで管理UIを使用する必要がありますか？

donquixote 2020-11-05 02:54.

背景/動機

多くの実装hook_update_N()とhook_install()D7とD8 / D9内のcontrib及びコアモジュールでは、への呼び出し含むt()機能。一般に、私t()たちが知らないユーザーに表示されるすべての種類の文字列に使用することは「ベストプラクティス」と見なされていると思います。

カスタムサイト固有のモジュールのt()場合、開発者以外の人にメッセージが表示されないことがわかっている場合は、を避けることがよくあります。これは、特に適用されるhook_update_N()とhook_install()。時々私はformat_string()代わりに、翻訳なしで代替品を入手するために使用します。

私自身の動機は次のようなものです。

これらの1回限りの文字列がデータベースと翻訳UIを汚染することは望ましくありません。（どのような状況でこれが発生するかはわかりません）
更新フックの対象者は、英語で書かれたコメントをコーディングするために使用される開発者と開発者の小さなチームです。
元の英語のメッセージをログ、UI、CLI出力、および開発者間で送信されるコピーと貼り付けのスニペットに表示したいと思います。
開発者/サイトビルダーに常に同じ文字列を表示してもらいたいです。

個人的には、さらに先に進んで、t()カスタムフィールドフォーマッターやプラグインなどの名前には使用しないこともあります。

私には、私の実用的な議論に納得しておらず、「本によって」物事をやりたいと思っている同僚がいます。彼は一貫性を重視しており、t()どこでも使用したいと考えています。

おそらく賛成の1つの議論t()は、すべての文字列を変更することなく、後でコードの一部をcontribまたは社内モジュールにコピーするのが簡単になるということです。典型的なhook_update_N（）の可能性は低いですが、可能性はあります。

質問

t()「内部」オーディエンスを持つ文字列を要求しないことは、チームポリシーとして「許容可能」ですか？

どのような場合に使用しないことが許容されますt()か？

個人的な好みを超えて、これを決定するために使用できる慣習や正当な理由はありますか？

編集

元の質問に隠れているより具体的な質問がいくつかあります。ハイゼンベルグで非難されないように、これらを「編集」と明確にマークされたセクションに入れています。

どのような場合に使用しないことが許容されますt()か？

議論される可能性のある特定のケース：

から返されhook_update_N()たメッセージ。
hook_update_N()失敗時にスローされる例外。（＃817160は、例外メッセージを翻訳しないことを提案しています。）
カスタムモジュールで定義されているフィールドフォーマッタおよびその他のプラグインの名前。元の名前は翻訳されるべきではないという議論がなされる可能性があります。
（watchdog()/Drupal::logger()呼び出しはコメントで言及されていますが、私はそれらのATMにはあまり興味がありません）

賛成/反対の議論は、これらの場合に異なって適用されます。

8 i18n-l10n

1 answers

anonymous 2020-11-05 13:39.

「あなたは練習のように遊ぶ」という表現を聞いたことがありますか？t()自分のサイト専用であるという理由だけで翻訳可能な文字列を使用しない習慣を身に付けた場合（「練習」）、それが重要な場合（つまり「プレイ」）t()、おそらくそれを除外することになります。慣れている。

ここで正しく行うことのマイナス面は実際にはありません。何も保存したり、パフォーマンスに測定可能な違いをもたらしたりすることはありません。t()利点は、どこでも同じように実行すれば、必要な場所を省略してバグを導入することはなく、自動コーディング標準ツールを使用して、多くの失敗を確認せずにコードをチェックできることです。あなたの不足しているt()機能から-それはあなたが持っているかもしれないいくつかの実際の問題をこれらの多くの失敗が覆い隠すのを防ぎます。