私はプロジェクトに取り組んでおり、アプリケーションをグローバル化するために必要なすべての作業を開始したところです。よくあることの 1 つは、例外メッセージをグローバル化するかどうかということですが、string.Format が CultureInfo.InvariantCulture ではなく CultureInfo.CurrentCulture を使用するようにします。さらに、これは、カルチャ固有としてマークできるリソース ファイルに例外メッセージが格納されることを意味します。
問題は、例外メッセージをグローバル化するか、InvariantCulture または作成者の国に残すかです。私の場合は en-US です。
例外メッセージがユーザーに直接表示されることはめったにありません。文字列ごとにコンシューマーについて考える必要があります。明らかに、ユーザーインターフェイスのテキストは国際化する必要がありますが、例外メッセージがサポートによってのみ表示される場合（またはユーザーに表示され、ボタンをクリックしたときにサポートに電子メールで送信される場合）、次の利点があります。それを翻訳しますか？
行き過ぎてしまうと、時間と労力を浪費するだけでなく（i18nは多大な労力を費やす可能性があります）、サポートライフも難しくなります。外国語で書かれたログファイルを読んで、母国語に翻訳し直す必要は本当にありません。
例外メッセージは世界中の開発者に読まれるので、 Microsoftが国際化することは理にかなっていますが、共通の言語を共有していない複数の国の開発者と多国籍でない限り、メッセージを翻訳しません。これは本当に開発/サポートを目的としています。
グローバル化とは、通常国際化と呼ばれるi18n準拠を意味すると思います。はい、診断メッセージを含め、GUIのすべての表示部分を国際化します。開発者がスタックトレースなどの実際の情報を取得するために移動する必要があるログファイルは、国際化されるべきではありません。