それが本当に役立つかどうかはわかりません。

1. 最も重要な事実は、英語のエラーを見つけるのがはるかに簡単であるということです。
2. AppCenterやHockeyAppなどのサービスは、例外メッセージによってエラーをグループ化します。 また、同じエラーが表示されることもありますが、ユーザーのPC言語での翻訳と重複しています。
3. 通常、エラーメッセージはわかりやすい英語で書かれています。
   そしてもっと重要な事実は、英語の間違いを見つけるのがずっと簡単だということです。
4. ある種のエラーダイアログでException.Messageをユーザーに表示するのが良い方法かどうかはわかりませんが、ログに保存する必要があります。 また、言語が不明なログを受け取った場合、それはあまり役に立ちません。

ちなみに、アプリケーションでは無効にすることもできますが、私にとっては問題ありません。 しかし、それが時間の価値があるかどうかはわかりません。

PS私はロシア語を母国語としています。 ロシア語でいくつかのエラーを見つけるのは私にとって苦痛でした）

.NET Coreが最近例外メッセージのローカライズに戻ったことを考えると、WinUIがフォローしていなければ奇妙なことになります。 [編集] WinUIが純粋な.NETではなく、Exceptionオブジェクトの代わりにHRESULTエラーコードを使用していることを忘れました。

ある種のエラーダイアログでException.Messageをユーザーに表示するのが良い方法かどうかはわかりません

UWP / WinUIデータバインディングでどのように行われるかはわかりませんが、WPFおよびWinFormsデータバインディングは、データバインディング中に発生したエラーメッセージをユーザーに公開します。 これは、データバインディングライトバックシナリオで合理的にスローされる可能性のある例外をローカライズする必要があることを意味します。

WinUIが（プロセスを終了する代わりに）データバインディング中に例外をキャッチした場合、例外メッセージを一般的なローカライズされたメッセージに置き換えない限り、おそらく同じことを行う必要があります。

（そして、ええ、外国語のエラーを検索しなければならないのは苦痛ですが、データバインディングがこれらのエラーをエンドユーザーに公開するとき、私はそれを回避する方法がわかりません。エンドユーザーは間違いなくローカライズされたエラーメッセージを期待しています。）

WinUIはWinRTとして実装されており、WinRTにはException.Messageを設定する方法がありません。 したがって、WinUIが生成するエラーメッセージはデバッガーに表示されますが、WPF / WinFormsの場合のようにエンドユーザーに表示されることはありません。 （WinUIは、メッセージをデバッガーでのみ取得できるように設計されたRoOriginateErrorを使用してエラーを生成します。）