MQM‑Fin: A Risk‑Weighted Hybrid Quality Assurance Framework for Localizing Financial Software - Beyond LISA and SAE J2450

عندما تقرر شركة برمجيات بيع منتجها في بلد جديد، فإنها تواجه تحدياً أعمق بكثير من مجرد استبدال الكلمات من لغة إلى أخرى. هذه العملية، المعروفة باسم "التوطين" (localization)، تتطلب تكييف المحتوى الرقمي ليشعر المستخدم بأنه أصيل في ثقافته المحلية، مع احترام العادات المحلية، والقواعد اللغوية، والطريقة المحددة التي يتفاعل بها الناس مع التكنولوجيا. وفي عالم البرمجيات، يعني هذا أخذ النص الذي يظهر على الأزرار، والقوائم، ورسائل الخطأ، والتأكد من أنه منطقي تماماً لمستخدم يتحدث لغة مختلفة. ومع ذلك، فإن الحكم على ما إذا كانت هذه الترجمة جيدة بما يكفي هو أمر صعب للغاية. فخلافاً للرواية، حيث قد يشعر القارئ ببساطة أن جملة ما "غير دقيقة"، يجب أن يكون نص البرمجيات دقيقاً؛ إذ يمكن لتعليمات مترجمة بشكل خاطئ في تطبيق بنكي أن تؤدي إلى خسارة المستخدم لأمواله أو منعه من الوصول إلى حسابه. لسنوات طويلة، اعتمدت الصناعة على بعض قوائم التحقق المعيارية لقياس هذه الأخطاء، لكن الخبراء ظلوا يتجادلون منذ فترة طويلة حول ما إذا كانت هذه الأدوات حادة بما يكفي لاكتشاف الأخطاء الدقيقة والخطيرة التي تحدث عندما تقوم الآلات بالترجمة.

قام باحث يدعى سينا عليزاده طبري باختبار هذه الأساليب الحالية في مواجهة سيناريو محدد وعالي المخاطر: تطبيق بنكي مصمم للتمويل الإسلامي. تم بناء هذا البرنامج في الأصل باللغة الفارسية، متبعاً مبادئ مالية دينية صارمة، وكان الهدف هو معرفة مدى جودة ترجمته إلى الإنجليزية لاستخدامه في الولايات المتحدة. ولمحاكاة عملية ترجمة سريعة في ظروف ضاغطة، لم يستأجر الباحث مترجمين بشريين، بل تمت ترجمة الواجهة بأكملها باستخدام أداة آلية مجانية تسمى "ترجمة جوجل" (Google Translate)، دون أي تحرير بشري لاحق. وقد خلق هذا "عاصفة مثالية" من الأخطاء المحتملة، مما سمح للباحث برؤية أين تعثرت الآلة عند مواجهة مصطلحات مالية معقدة وسلاسل نصية معزولة تفتقر إلى السياق المحيط. ثم قام الباحث بتمرير هذا البرنامج المترجم آلياً عبر ثلاثة نماذج مختلفة لضمان الجودة — وهي أنظمة معيارية تستخدمها الصناعة لحساب ووزن الأخطاء — لمعرفة أي منها يمكنه تحديد المشكلات بشكل أفضل، والأهم من ذلك، أي منها يمكنه التمييز بين خطأ مطبعي غير ضار وخطأ مالي كارثي.

كشفت التحقيقات أنه بينما استطاعت الأنظمة الثلاثة إيجاد الأخطاء، إلا أنها لم تتفق على ماهية تلك الأخطاء أو مدى خطورتها. أحد النماذج القديمة، الذي يُستخدم غالباً في صناعة السيارات، ركز بشدة على القواعد والإملاء لكنه تجاهل إلى حد كبير ما إذا كان أسلوب أو تنسيق النص مناسباً لبنك. أما النموذج الآخر، المستخدم على نطاق واسع في صناعة التوطين، فقد كان أفضل في اكتشاف الأخطاء العامة، ولكنه مال إلى دمج أنواع مختلفة من الأخطاء معاً، مما جعل من الصعب رؤية الطبيعة المحددة للمشكلة. وأثبت النموذج الثالث، وهو إطار عمل أكثر حداثة يسمى "مقاييس الجودة متعددة الأبعاد" (Multidimensional Quality Metrics)، أنه الأكثر تفصيلاً. فقد عمل مثل مجهر عالي القدرة، حيث فصل الأخطاء إلى فئات واضحة مثل "الدقة" (هل تغير المعنى؟) و"الطلاقة" (هل تبدو الجملة طبيعية؟). واستطاع هذا النموذج تحديد أن الترجمة الآلية قد خلطت بين مصطلحات بنكية محددة، حيث حولت زراً مخصصاً لتسجيل دخول المستخدم إلى كلمة تعني ببساال "وصول"، كما اكتشف حالات حذف حيث غابت بيانات مالية كاملة عن الشاشة.

ومع ذلك، وجد الباحث أن حتى النموذج الأكثر تفصيلاً لديه نقطة عمياء فيما يتعلق بالمخاطر الفريدة للبرمجيات المالية. فقد يمكن لفحص جودة قياسي أن يعامل خطأً إملائياً صغيراً في شاشة تسجيل الدخول بنفس الطريقة التي يعامل بها خطأً إملائياً في صفحة "من نحن". ولكن في تطبيق بنكي، الأمر ليس كذلك؛ فخطأ في شاشة تسجيل الدخول قد يمنع المستخدم من الوصول إلى أمواله تماماً، بينما الخطأ المطبعي في صفحة معلوماتية هو مجرد أمر مزعج. ولحل هذه المشكلة، اقترحت الدراسة نموذج جودة جديداً ومتخصصاً مصمماً خصيصاً للتمويل. هذا النهج الجديد، المسمى (MQM-Fin)، يضيف طبقة من تقييم المخاطر لكل خطأ يتم العثور عليه. فهو لا يسأل فقط "ما الخطأ؟" بل "ما مدى سوء الأمر إذا رآه المستخدم؟". ومن خلال ضرب درجة الخطأ في احتمالية تسببه في خسارة مالية أو فشل في المعاملة، كشف النظام الجديد أن البرنامج، الذي بدا "مقبولاً حده الأدنى" بموجب القواعد القياسية، كان في الواقع يفشل في وظائفه الأكثر أهمية. لقد كانت شاشة تسجيل الدخول وأزرار المعاملات معيبة للغاية لدرجة أن البرنامج أصبح غير قابل للاستخدام فعلياً لغرضه المنشود.

كما كشفت الدراسة أيضاً عن سبب فشل الترجمة الآلية في كثير من الأحيان. فقد تبين أن الأخطاء لم تكن عشوائية، بل اتبعت نمطاً يمكن التنبؤ به ناتجاً عن الطريقة التي تُبنى بها واجهات المستخدم. في البرمجيات، تظهر النصوص غالباً في قطع صغيرة ومعزولة، مثل كلمة واحدة على زر، دون الجمل المحيطة التي تساعد المترجم البشري على فهم السياق. والآلة، لافتقارها لهذا السياق، كانت تخمن معنى الكلمة بناءً على الاستخدام الأكثر شيوعاً، والذي كان غالباً خاطئاً في السياق البنكي. على سبيل المثال، تُرجمت عبارة تصف نوعاً معيناً من الحسابات البنكية إلى مزيج غير منطقي من الكلمات مثل "معالجة ورقة المعلومات، مستشفى الهاتف" لأن الآلة لم تكن تعلم أنها تنظر إلى قائمة مالية. وقد حدد الباحث ثلاث طرق رئيسية حدث فيها ذلك: كان النص معزولاً جداً بحيث لا تستطيع الآلة فهم قواعده، أو أن للكلمات معانٍ متعددة واختارت الآلة المعنى الخاطئ، أو أن العبارات الطويلة تم ضغطها في تسميات قصيرة لم تستطع الآلة تحليلها.

وفي الختام، تشير الدراسة إلى أن الصناعة بحاجة إلى تجاوز قوائم التحقق العامة عند التعامل مع البرمجيات الحرجة. وتقترح الدراسة سير عمل هجين حيث يتم استخدام مسح سريع وعام أولاً لاكتشاف الأخطاء الواضحة، يليه فحص دقيق ومرتبط بالمخاطر فقط على الأجزاء الأكثر أهمية من البرمجيات، مثل شاشات تسجيل الدخول وأزرار الدفع. هذا النهج من شأنه توفير الوقت والمال مع ضمان اكتشاف الأخطاء الأكثر خطورة. كما تسلط النتائج الضوء على حاجة ماسة لأدوات أفضل: فإذا استطاع مطورو البرمجيات تزويد آلات الترجمة بمزيد من السياق — مثل ملاحظة توضح أن هذا الزر مخصص لـ "تسجيل الدخول" وليس مجرد عرض كلمة "Login" — فإن جودة المخرجات ستتحسن بشكل كبير. وتخلص الدراسة إلى أنه بينما يمكن للآلات ترجمة الكلمات، إلا أنها لا تستطيع بعد فهم ثقل المعاملة المالية دون توجيه بشري ونظام جودة يدرك الفرق بين الخطأ الشكلي والكارثة المالية.