정말 유용할지 모르겠습니다.

1. 가장 중요한 사실은 영어에서 오류를 찾는 것이 훨씬 더 쉽다는 것입니다.
2. AppCenter 또는 HockeyApp과 같은 서비스는 예외 메시지별로 오류를 그룹화합니다. 그리고 때때로 우리는 동일한 오류를 볼 수 있지만 사용자 PC 언어로 번역과 중복됩니다.
3. 일반적으로 오류 메시지는 이해하기 쉬운 영어로 작성됩니다.
   그리고 더 중요한 사실은 영어에서 오류를 찾는 것이 훨씬 더 쉽다는 것입니다.
4. 어떤 종류의 오류 대화 상자에서 사용자에게 Exception.Message를 표시하는 것이 좋은 방법인지 확실하지 않지만 로그에 저장해야 합니다. 그리고 다시 - 만약 당신이 당신의 언어에 대해 알 수 없는 로그를 받는다면, 그것은 별로 유용하지 않습니다.

그건 그렇고, 응용 프로그램에 대해 비활성화 될 수 있지만 나에게는 괜찮습니다. 그러나 시간을 할애할 가치가 있는지 확실하지 않습니다.

추신: 저는 러시아어가 모국어입니다. 러시아어에서 약간의 오류를 찾는 것이 나에게는 고통이었습니다)

.NET Core가 최근 예외 메시지 지역화로 다시 전환되었음을 고려하면 WinUI가 따르지 않는다면 이상할 것입니다. [편집] WinUI가 순수한 .NET이 아니지만 예외 개체 대신 HRESULT 오류 코드를 사용한다는 사실을 잊었습니다.

어떤 종류의 오류 대화 상자에서 사용자에게 Exception.Message를 표시하는 것이 좋은 방법인지 확실하지 않습니다.

UWP/WinUI 데이터 바인딩에서 어떻게 수행되는지 모르지만 WPF 및 WinForms 데이터 바인딩은 사용자에게 데이터 바인딩 중에 발생하는 오류 메시지를 노출합니다. 이는 데이터 바인딩 쓰기 저장 시나리오에서 합리적으로 throw될 수 있는 모든 예외를 지역화해야 함을 의미합니다.

WinUI가 프로세스를 종료하는 대신 데이터 바인딩 중에 예외를 catch하는 경우 예외 메시지를 일반 지역화된 메시지로 바꾸지 않는 한 동일한 작업을 수행해야 합니다.

(그리고 네, 외국어 오류를 검색해야 하는 것은 고통스러운 일이지만 데이터 바인딩이 이러한 오류를 현지화된 오류 메시지를 확실히 예상하고 있는 최종 사용자에게 노출시킬 때 문제를 해결할 방법이 없습니다.)

WinUI는 WinRT로 구현되며 WinRT에는 Exception.Message를 설정할 수 있는 방법이 없습니다. 따라서 WinUI가 생성하는 오류 메시지는 디버거에서 볼 수 있지만 WPF/WinForms에서와 같이 최종 사용자에게 표시되어서는 안 됩니다. (WinUI는 메시지를 디버거에서만 검색할 수 있도록 설계된 RoOriginateError를 사용하여 오류를 생성합니다.)