Ich bin mir nicht sicher, ob es wirklich nützlich ist.

1. Die wichtigste Tatsache ist, dass es viel einfacher ist, Fehler auf Englisch zu finden.
2. Dienste wie AppCenter oder HockeyApp gruppieren Fehler durch Ausnahmemeldungen. Und manchmal können wir denselben Fehler sehen, der jedoch mit der Übersetzung in der Benutzer-PC-Sprache dupliziert wird.
3. Normalerweise werden Fehlermeldungen in leicht verständlichem Englisch verfasst.
   Und noch wichtiger ist, dass es viel einfacher ist, Fehler auf Englisch zu finden.
4. Ich bin mir nicht sicher, ob es sinnvoll ist, dem Benutzer Exception.Message in irgendeiner Art von Fehlerdialog anzuzeigen, aber es sollte in Protokollen gespeichert werden. Und noch einmal - wenn Sie für Ihre Sprache unbekannte Protokolle erhalten, ist es nicht wirklich nützlich.

Übrigens, obwohl es für die Anwendung deaktiviert werden könnte, ist es für mich in Ordnung. Ich bin mir jedoch nicht sicher, ob es die Zeit wert ist.

PS Ich bin russischer Muttersprachler. Es war schmerzhaft für mich, einige Fehler auf Russisch zu finden)

Wenn man bedenkt, dass .NET Core kürzlich wieder auf die Lokalisierung von Ausnahmemeldungen umgestellt hat, wäre es seltsam, wenn WinUI nicht folgen würde. [Bearbeiten] Ich habe vergessen, dass WinUI kein reines .NET ist, sondern HRESULT-Fehlercodes anstelle von Ausnahmeobjekten verwendet.

Ich bin mir nicht sicher, ob es eine gute Vorgehensweise ist, dem Benutzer Exception.Message in einer Art von Fehlermeldungen anzuzeigen

Ich weiß nicht, wie dies bei der UWP/WinUI-Datenbindung erfolgt, aber die WPF- und WinForms-Datenbindung macht alle Fehlermeldungen sichtbar, die während der Datenbindung für den Benutzer auftreten. Das bedeutet, dass jede Ausnahme, die in Datenbindungs-Rückschreibe-Szenarien vernünftigerweise ausgelöst werden kann, lokalisiert werden muss.

Wenn WinUI während der Datenbindung Ausnahmen abfängt (anstatt den Prozess zu beenden), muss es wahrscheinlich dasselbe tun, es sei denn, es ersetzt die Ausnahmemeldung durch eine generische lokalisierte Meldung.

(Und ja, nach fremdsprachigen Fehlern suchen zu müssen ist mühsam, aber ich sehe keinen Weg, wenn die Datenbindung diese Fehler dem Endbenutzer offenlegt, der definitiv lokalisierte Fehlermeldungen erwartet.)

WinUI ist als WinRT implementiert, und WinRT hat keine Möglichkeit, eine Exception.Message festzulegen. Die von WinUI generierten Fehlermeldungen sind also im Debugger sichtbar, sollten jedoch niemals einem Endbenutzer angezeigt werden, wie dies bei WPF/WinForms der Fall ist. (WinUI generiert Fehler mithilfe von RoOriginateError , das so konzipiert ist, dass die Nachricht nur von einem Debugger abgerufen werden kann.)