بصفتي طالبًا سابقًا يتحدث الإسبانية في علوم الكمبيوتر ، أجد أنه عند تعلم تقنية جديدة ولا تتحدث اللغة ، فإن وجود أخطاء وتوثيق بلغتك الأم مفيد للغاية ، أعتقد أن لدينا فرصة هنا للتحسين هنا .
لست متأكدًا إذا كان مفيدًا حقًا.
بالمناسبة ، بينما يمكن تعطيله للتطبيق ، فلا بأس بالنسبة لي. ومع ذلك ، لست متأكدًا مما إذا كان الأمر يستحق الوقت.
سكرتير خاص أنا المتحدث الأصلي باللغة الروسية. كان مؤلمًا بالنسبة لي أن أجد بعض الأخطاء في اللغة الروسية)
بالنظر إلى عودة .NET Core مؤخرًا إلى ترجمة رسائل الاستثناءات ، سيكون من الغريب أن لا يتبع WinUI. [تحرير] لقد نسيت أن WinUI ليس صافيًا خالصًا ، ولكنه يستخدم رموز خطأ HRESULT بدلاً من كائنات الاستثناء.
لست متأكدًا ، إذا كان من الممارسات الجيدة إظهار استثناء ، فقم بإرسال رسالة إلى المستخدم في نوع من مربعات حوار الخطأ
لا أعرف كيف يتم ذلك في ربط بيانات UWP / WinUI ، لكن ربط بيانات WPF و WinForms يعرضان أي رسالة خطأ تحدث أثناء ربط البيانات للمستخدم. هذا يعني أنه يجب ترجمة أي استثناء يمكن طرحه بشكل معقول في سيناريوهات إعادة كتابة ربط البيانات.
إذا اكتشف WinUI استثناءات أثناء ربط البيانات (بدلاً من إنهاء العملية) ، فربما يتعين عليه فعل الشيء نفسه ، ما لم يستبدل رسالة الاستثناء برسالة مترجمة عامة.
(ونعم ، يعد الاضطرار إلى البحث عن أخطاء لغة أجنبية أمرًا مزعجًا ، لكنني لا أرى أي طريقة للتغلب عليها عندما يكشف ربط البيانات هذه الأخطاء للمستخدم النهائي ، الذي يتوقع بالتأكيد رسائل خطأ محلية.)
يتم تطبيق WinUI على أنه WinRT ، وليس لدى WinRT طريقة لتعيين Exception.Message. لذلك تظهر رسائل الخطأ التي ينشئها WinUI في مصحح الأخطاء ، ولكن لا يجب أن تظهر للمستخدم النهائي كما تفعل مع WPF / WinForms. (ينشئ WinUI أخطاء باستخدام RoOriginateError ، المصمم بحيث لا يمكن استرداد الرسالة إلا بواسطة مصحح أخطاء.)
التعليق الأكثر فائدة
يتم تطبيق WinUI على أنه WinRT ، وليس لدى WinRT طريقة لتعيين Exception.Message. لذلك تظهر رسائل الخطأ التي ينشئها WinUI في مصحح الأخطاء ، ولكن لا يجب أن تظهر للمستخدم النهائي كما تفعل مع WPF / WinForms. (ينشئ WinUI أخطاء باستخدام RoOriginateError ، المصمم بحيث لا يمكن استرداد الرسالة إلا بواسطة مصحح أخطاء.)