اختبار التوطين والتدويل

التدويل والتوطين والعولمة: ما الذي نختبره؟

التدويل (Internationalization أو i18n) خاصية هندسية: يُبنى المنتج بحيث يمكن تكييفه مع أي إعداد محلي دون تغيير الكود. تعيش النصوص في ملفات موارد لا في القوالب؛ وتمر التواريخ والأرقام والعملات عبر واجهات تنسيق واعية بالإعداد المحلي؛ ولا يُفترض اتجاه ثابت للنص؛ ويكون التخزين والنقل باليونيكود من طرف إلى طرف. أما التوطين (Localization أو l10n) فهو التكييف لإعداد محلي واحد: النصوص المترجمة، والصيغ المحلية، والمحتوى المحلي، والنصوص القانونية، ووسائل الدفع، وصيغ العناوين والهواتف. والعولمة (Globalization أو g11n) مصطلح جامع للجهد التجاري والهندسي الذي يضم الاثنين ليُقدَّم منتج واحد في أسواق كثيرة.

التفريق مهم لأن العيوب مختلفة. عيب التدويل يعيش في الكود ويظهر في كل الإعدادات المحلية — رمز عملة مكتوب في الكود، أو جملة مركّبة بالدمج، أو تاريخ يُحلَّل بنمط ثابت. وعيب التوطين يعيش في محتوى إعداد محلي واحد — مصطلح خاطئ، أو ترجمة ناقصة، أو صيغة عنوان خاطئة. وعيوب التدويل أرخص ما تكون حين تُكتشف قبل وجود أي ترجمة، بالتوطين الزائف؛ أما عيوب التوطين فتحتاج إلى الترجمة الحقيقية، وتحتاج جودة اللغة فيها إلى متحدث أصلي.

• الإعداد المحلي (Locale) — يُعرَّف بوسم لغة BCP 47 (المعيار RFC 5646): ar وar-SA وhi-IN وen-IN. الجزء الخاص باللغة يختار الترجمة، وجزء المنطقة يختار الصيغ والعملة والتقويم الافتراضي.
• اختبار التدويل — هل يستطيع المنتج دعم الإعدادات المحلية أصلاً؟ شغّله بنص موطّن توطيناً زائفاً، وبيانات يونيكود، واتجاه من اليمين إلى اليسار، وصيغ غير افتراضية.
• اختبار التوطين — هل هذا الإعداد المحلي بعينه صحيح؟ الترجمة في سياقها، والصيغ، والملاءمة الثقافية، والتخطيط بالنصوص الحقيقية.

خريطة اختبار التوطين

يمتد اختبار التوطين عبر مجالات تحتاج إلى مهارات وبيانات مختلفة. استخدم هذه الخريطة لتخطيط التغطية لكل إعداد محلي؛ والأقسام التالية تمر على كل مجال، أما التخطيط من اليمين إلى اليسار فيغطيه دليل اختبار RTL بالتفصيل.

• جودة اللغة والترجمة — المصطلحات، والسياق، والاكتمال، وصيغ الجمع والتذكير والتأنيث، ومعاملات الرسائل، والاقتطاع.
• الصيغ المحلية — التواريخ والتقاويم (الميلادي والهجري)، والأوقات والمناطق الزمنية، والأعداد والأرقام، والعملات، ووحدات القياس، والعناوين، وأرقام الهواتف، والأسماء الشخصية.
• معالجة النص وأنظمة الكتابة — الترميز، وتطبيع اليونيكود، والعناقيد الرسومية، والخطوط، والفرز، والبحث، وطرق الإدخال.
• التخطيط — تمدد النص وانكماشه، وارتفاع السطر لأنظمة الكتابة التي لها علامات فوق السطر وتحته، وفي العربية مجال عكس الواجهة والنص ثنائي الاتجاه بأكمله.
• اختيار الإعداد المحلي والرجوع الاحتياطي — كيف يختار المنتج الإعداد المحلي (إعداد المستخدم، أو ترويسة Accept-Language، أو الجهاز، أو الرابط)، وما الذي يحدث مع إعداد غير مدعوم، وهل ينتقل الاختيار إلى البريد الإلكتروني وملفات PDF والرسائل النصية والإشعارات.
• إمكانية الوصول لكل إعداد محلي — سمة lang التي تخبر قارئ الشاشة بالصوت وقواعد النطق المناسبة، والأسماء الوصفية المترجمة للأيقونات وعناصر التحكم.

جودة اللغة والترجمة

يعمل المترجمون عادةً من جدول بيانات أو نظام لإدارة الترجمة دون أن يروا الشاشة، ومن هنا يأتي كثير من عيوب الترجمة. فكلمة "Save" الإنجليزية قد تكون فعلاً (احفظ الملف) أو اسماً (توفير في خصم)؛ و"Open" قد تكون حالة (مفتوح) أو أمراً (افتح)؛ والمترجم بلا سياق يختار واحداً. ومهمة المختبِر أن يراجع كل نص على الشاشة الحقيقية، وأن يذكر مفتاح النص مع لقطة الشاشة حتى يقع الإصلاح في المورد الصحيح.

صيغ الجمع هي أشيع العيوب البنيوية. للإنجليزية صيغتا جمع عدديتان. أما قواعد الجمع في مستودع CLDR من يونيكود فتمنح العربية ست فئات — zero (0)، وone (1)، وtwo (2)، وfew (الأعداد التي آخر رقمين فيها من 3 إلى 10، مثل 3 أو 103)، وmany (آخر رقمين من 11 إلى 99)، وother (مثل 100 إلى 102) — وتمنح الهندية فئتين، تُستخدم فيهما صيغة "one" للعددين 0 و1. والكود الذي يختار الصيغة بالشرط count === 1 خاطئ للعربية من أساسه. والإصلاح صيغة رسائل تدعم فئات الجمع؛ والاختبار جدول أعداد يصيب كل فئة.

• اتساق المصطلحات — مصطلح واحد لكل مفهوم عبر الشاشات وصفحات المساعدة والبريد، يُراجع مقابل المسرد. تسمية السلة "سلة" في شاشة و"عربة" في أخرى عيب.
• النصوص غير المترجمة — إنجليزية متروكة داخل الواجهة العربية أو الهندية؛ وتكثر في رسائل التحقق وأخطاء API والبريد والنصوص المضافة في آخر السبرنت.
• النصوص المدموجة (Concatenated strings) — الجمل المركّبة من أجزاء ("You have" + n + "items") لا يمكن ترجمتها صحيحاً لأن ترتيب الكلمات والمطابقة يختلفان؛ ويجب أن تكون كل جملة رسالة واحدة بمعاملات.
• معاملات الرسائل — يجب أن تبقى {name} أو %s داخل الترجمة كما هي؛ فالمعامل المترجَم أو المحذوف يُظهر أقواساً خاماً أو يُسقط أداة التنسيق.
• التذكير والتأنيث وأسلوب الخطاب — الأفعال والصفات العربية تطابق الجنس؛ قرر كيف تخاطب الرسائل المستخدم وتحقق من تطبيق القرار باتساق.

# ICU MessageFormat, Arabic: one message, six CLDR plural categories
cart.items = {count, plural,
  zero  {السلة فارغة}
  one   {منتج واحد في السلة}
  two   {منتجان في السلة}
  few   {# منتجات في السلة}
  many  {# منتجًا في السلة}
  other {# منتج في السلة}
}

# Counts that hit every Arabic category
0 (zero) · 1 (one) · 2 (two) · 3, 10, 103 (few) · 11, 99 (many) · 100, 101, 102 (other)

# Hindi has two categories: one (0 and 1) and other
0, 1 (one) · 2, 5, 1.5 (other)

التوطين الزائف: اكتشف عيوب التدويل قبل الترجمة

التوطين الزائف (Pseudo-localization) يستبدل كل نص في الواجهة بنسخة محوّلة آلياً ما زال الفريق يستطيع قراءتها: حروف بعلامات، وطول إضافي، وأقواس تحدد بداية كل رسالة ونهايتها. شغّل المنتج بالإعداد الزائف فتظهر دفعة واحدة كل فئات العيوب التي لا تحتاج إلى ترجمة حقيقية — النص المكتوب في الكود يبقى إنجليزياً عادياً، والجملة المدموجة تظهر قطعاً متعددة بين أقواس، والاقتطاع يقطع القوس الختامي، والمحارف خارج ASCII تكشف مشكلات الترميز.

يوفر Android إعدادين زائفين يمكن تفعيلهما في بنيات التصحيح: English (XA) الذي يضيف العلامات ويمدد النص ويحيط كل رسالة بأقواس، وAR (XB) الذي يحوّل الاتجاه إلى اليمين-إلى-اليسار ويعكس ترتيب المحارف، فيستطيع الفريق اكتشاف مشكلات العكس والنص ثنائي الاتجاه دون أن يعرف لغة تُكتب من اليمين. وعلى الويب يكون الإعداد الزائف عادةً ملف موارد إضافياً يُولَّد أثناء البناء من النصوص المصدرية.

Source (en):           Save changes
Pseudo (expanded):     [Ŝàṽé çĥàñĝéš ·····]
RTL pseudo:            same text, base direction switched to right-to-left

What each symptom on screen means:
  Save changes            -> hard-coded string, never externalised
  [Ŝàṽé] [çĥàñĝéš]         -> sentence assembled by concatenation
  [Ŝàṽé çĥàñĝ             -> truncated: no room for longer translations
  [Ŝ?ṽ? ?ĥ?ñĝ?š]          -> characters lost in an encoding conversion

التواريخ والتقاويم والمناطق الزمنية

صيغة التاريخ أكثر من ترتيب اليوم والشهر. فالإعداد المحلي يحدد التقويم، وأسماء الأشهر، والأرقام، والفواصل، وأول أيام الأسبوع، ونظام الساعة 12 أو 24. وفي السعودية تقويمان مستخدمان يومياً: التقويم الميلادي، والتقويم الهجري الذي توحّد المملكة حسابه بتقويم أم القرى. وكثير من المنتجات يعرض الاثنين أو يترك الاختيار للمستخدم؛ وكل موضع يعرض تاريخاً أو يقبله أو يخزنه أو يقارنه يجب أن يكون واضحاً في أي تقويم يستخدم.

لا تفترض ما ينتجه "ar-SA". فالقيم الافتراضية للإعداد المحلي تأتي من بيانات CLDR داخل بيئة التشغيل وتتغير بين الإصدارات: كانت بيئات التشغيل الأقدم تنسّق تواريخ ar-SA بالتقويم الهجري افتراضياً، بينما تستخدم الحديثة التقويم الميلادي بالأرقام العربية المشرقية. اطلب التقويم ونظام الأرقام صراحةً — مثلاً بامتدادات اليونيكود ar-SA-u-ca-islamic-umalqura أو ar-SA-u-nu-latn — واختبر النتيجة على كل بيئة تشغيل تطلقها: الخادم والمتصفحات والجوال. وقد تضع طرق الحساب الهجري المختلفة (أم القرى، والجدولي المدني) اليوم نفسه في تواريخ مختلفة، لذا يجب أن يسمّي اختبار التحويل التقويم بعينه لا أن يكتفي بكلمة "هجري".

تأتي المناطق الزمنية من قاعدة بيانات IANA tz. المنطقة Asia/Riyadh هي UTC+03:00 والسعودية لا تطبق التوقيت الصيفي؛ والمنطقة Asia/Kolkata هي UTC+05:30 دون توقيت صيفي أيضاً. وهذا يجعل عيوب التوقيت الصيفي (DST) غير مرئية في الاختبار المحلي وحقيقية لمستخدمين في أوروبا أو أمريكا الشمالية. خزّن اللحظات الزمنية بتوقيت UTC أو بفارق صريح (ISO 8601)، وحوّلها إلى منطقة المستخدم للعرض فقط، واختبر فارق نصف ساعة، ومنطقة تطبق التوقيت الصيفي، وأوقاتاً قريبة من منتصف الليل حيث يتغير اليوم.

• كل حقل تاريخ يعلن تقويمه؛ واختيار تاريخ في منتقي التاريخ الهجري يخزن القيمة نفسها التي يخزنها اختيار التاريخ الميلادي المقابل.
• نهايات الأشهر والسنوات: أشهر أم القرى 29 أو 30 يوماً؛ اختبر آخر يوم في الشهر وفي السنة في التقويمين.
• انزياح منتصف الليل: الطلب المسجَّل الساعة 01:30 بتوقيت الرياض يقع في اليوم السابق بتوقيت UTC؛ والتقرير المجمَّع حسب يوم UTC يعرضه في تاريخ خاطئ.
• الأسبوع وعطلته: أول أيام الأسبوع يختلف حسب الإعداد المحلي، والعطلة الأسبوعية في السعودية الجمعة والسبت؛ ويجب أن تتبع التقاويم والجداول وحساب أيام العمل قاعدة المنتج لا قاعدة مكتوبة في الكود.

One instant: 2026-09-28T09:05:00Z
(example output from Node.js 22 with ICU 78 / CLDR 48; other runtimes may differ)

ar-SA                          ٢٨ سبتمبر ٢٠٢٦
ar-SA-u-nu-latn                28 سبتمبر 2026
ar-SA-u-ca-islamic-umalqura    ١٧ ربيع الآخر ١٤٤٨ هـ
hi-IN                          28 सितंबर 2026
en-US                          September 28, 2026

Time in Asia/Riyadh  (UTC+03:00)   12:05
Time in Asia/Kolkata (UTC+05:30)   14:35

جرّبها: مولّد بيانات اختبار التواريخ جرّبها: محوّل المناطق الزمنية جرّبها: محوّل الطوابع الزمنية جرّبها: محوّل ISO 8601

الأعداد والأرقام والعملات

يمكن أن يستخدم النص العربي الأرقام الغربية (⁦0–9⁩) أو الأرقام العربية المشرقية (٠١٢٣٤٥٦٧٨٩)، ومع الأرقام المشرقية تتغير الفواصل أيضاً: الفاصلة العشرية العربية ٫ (U+066B) وفاصل الآلاف العربي ٬ (U+066C). ويستخدم النص الهندي عادةً الأرقام الغربية، مع أن أرقام الديفاناغاري (०–९) موجودة ويمكن طلبها. وتجمّع الهند الأعداد الكبيرة بطريقة مختلفة — 12,34,567 وفق نظام اللاك (1,00,000) والكرور (1,00,00,000) — في en-IN وhi-IN كليهما. قرر لكل إعداد محلي أي أرقام وأي تجميع يستخدم المنتج، ثم اختبر العرض والإدخال: فقد يكتب المستخدم أرقاماً مشرقية في حقل مبلغ أو هاتف، وعلى المنتج إما قبولها وتوحيدها أو رفضها برسالة واضحة.

تُعرَّف العملات برموز ISO 4217 — SAR للريال السعودي وINR للروبية الهندية، ولكل منهما خانتان عشريتان للوحدة الفرعية. نسّق المبالغ بالإعداد المحلي لا بقوالب نصية: فالرمز وموضعه والمسافة تختلف حسب الإعداد المحلي. وقد أطلق البنك المركزي السعودي رمزاً خاصاً بالريال في 2025، ويرمّزه الإصدار 17.0 من يونيكود بالنقطة U+20C1 SAUDI RIYAL SIGN؛ فإن استخدمه تصميمك فتحقق من الخطوط التي تستطيع عرضه على أجهزتك المستهدفة، لأن الخط الذي لا يحوي الرسم يعرض مربعاً فارغاً.

تحتوي النصوص المنسّقة محلياً على محارف غير مرئية. فتنسيق مبلغ بالريال للإعداد ar-SA ينتج علامة من اليمين إلى اليسار (U+200F) في الطرفين ومسافة غير فاصلة قبل العملة، فيفشل الاختبار الذي يقارن بنص مكتوب يدوياً مع أن الشاشة تبدو صحيحة. قارن بمخرجات واجهة التنسيق نفسها، أو أزل المحارف غير المرئية في التحقق عن قصد.

• التحليل: "1.234" تعني ألفاً ومئتين وأربعة وثلاثين في بعض الإعدادات المحلية وواحداً فاصلة اثنين ثلاثة أربعة في غيرها؛ والقيمة المنسّقة للعرض يجب أن تُحلَّل بالإعداد المحلي نفسه.
• أرقام الهواتف وأرقام IBAN وأرقام الهوية معرّفات لا كميات: لا تجمّعها ولا تحوّل أرقامها عند العرض.

1234567.5 as currency, per locale
(example output from Node.js 22 with ICU 78 / CLDR 48)

ar-SA            SAR   ١٬٢٣٤٬٥٦٧٫٥٠ ر.س.
                       (U+200F at start and end, U+00A0 before ر.س.)
ar-SA-u-nu-latn  SAR   1,234,567.50 ر.س.
hi-IN            INR   ₹12,34,567.50
en-IN            INR   ₹12,34,567.50
en-US            SAR   SAR 1,234,567.50

1234567 with Devanagari digits (hi-IN-u-nu-deva):  १२,३४,५६७

جرّبها: مولّد بيانات الاختبار العربية جرّبها: مولّد بيانات الاختبار الهندية جرّبها: مولّد مجموعات الأرقام العشرية

النص واليونيكود وأنظمة الكتابة

يجب أن تتفق كل طبقة على UTF-8: ترميز meta في HTML وترويسة Content-Type في HTTP، وإرسال النماذج، وAPI، وطوابير الرسائل، وأعمدة قاعدة البيانات واتصالاتها، والسجلات، وتصدير CSV أو PDF. وحين تقرأ طبقة ما بايتات UTF-8 بترميز قديم أحادي البايت تكون النتيجة نصاً مشوّهاً (Mojibake) — فتتحول "مرحبا" إلى شيء مثل "مرحبا" — وقد تجعل رحلة ذهاب وعودة التلف دائماً. علامات الاستفهام مكان الحروف تعني عادةً أن المحارف ضاعت في تحويل؛ والمربعات الفارغة تعني عادةً أن الخط لا يحوي الرسم. وفي MySQL تخزن مجموعة المحارف القديمة utf8 (أي utf8mb3) العربية والديفاناغاري لكنها لا تخزن المحارف التكميلية رباعية البايت، ومنها معظم الرموز التعبيرية؛ أما utf8mb4 فتخزن اليونيكود كله.

قد يُخزَّن النص المرئي نفسه بتسلسلات مختلفة من نقاط الترميز — "é" نقطة واحدة مركّبة مسبقاً أو "e" مع علامة مركِّبة. ويجعلها تطبيع اليونيكود (NFC وNFD وNFKC وNFKD) قابلة للمقارنة، لذا يجب أن يطبّع البحث وفحوص التفرد وأسماء المستخدمين باتساق. والطول ملتبس أيضاً: الكلمة الهندية "नमस्ते" هي 6 نقاط ترميز، و6 وحدات UTF-16، و18 بايت UTF-8، و3 محارف يدركها المستخدم (عناقيد رسومية: न، म، स्ते). والحد المحسوب بالبايتات، والحد المحسوب بالمحارف، والمؤشر الذي يتحرك بنقطة ترميز — كلها ستختلف.

تجمع الديفاناغاري الحروف الساكنة في حروف مركّبة (क्ष، स्त) عبر علامة الفيراما، وبعض علامات الحركات تُرسم قبل الحرف الذي تليه في الذاكرة — فعلامة i في "कि" تُخزَّن بعد क لكنها تظهر على يساره. والاقتطاع أو التظليل أو تحريك المؤشر داخل العنقود يترك علامة حركة بلا قاعدة، وتعرضها محركات العرض عادةً مع دائرة منقطة (◌ि). والخط الذي لا يدعم تشكيل الديفاناغاري كاملاً يعرض الحروف المركّبة حروفاً منفصلة بفيراما ظاهرة.

الفرز والبحث يختلفان حسب الإعداد المحلي: استخدم الترتيب الذي توفره المنصة (Intl.Collator في JavaScript، وترتيبات المقارنة في قاعدة البيانات) واختبر بأسماء تبدأ بصور الألف المختلفة (ا أ إ آ)، مع التشكيل ودونه، وبأنظمة كتابة مختلطة. وللإدخال فحوصه أيضاً: لوحات المفاتيح العربية، والهندية المكتوبة بتخطيط InScript أو بلوحة نقل صوتي، ومحررات أساليب الإدخال (IME) التي تركّب النص عبر عدة ضغطات — فالتحقق الذي يعمل مع كل ضغطة قد يقاطع عملية التركيب.

• تمدد النص وانكماشه: قد تكون الترجمة أطول كثيراً أو أقصر من الإنجليزية، خاصة في التسميات القصيرة؛ اختبر الأزرار والتبويبات وعناوين الجداول والتنبيهات المنبثقة والشارات بالنصوص الحقيقية لكل إعداد محلي.
• المساحة الرأسية: للديفاناغاري علامات حركات فوق الخط العلوي وتحته، وللعربية تشكيل فوق الحروف وتحتها؛ وارتفاعات الأسطر الثابتة مع إخفاء الفائض تقصّها.
• الرسائل النصية: الرسالة التي تحتوي عربية أو ديفاناغاري تُرسل عادةً بترميز UCS-2 بمعدل 16 بتاً للمحرف؛ ولأن بيانات المستخدم في الرسالة الواحدة 140 ثُمانية (3GPP TS 23.040)، تتسع الرسالة الواحدة عندئذٍ لـ 70 محرفاً بدلاً من 160 في أبجدية GSM ذات السبعة بتات، لذا قد تنقسم قوالب رموز التحقق (OTP) والإشعارات إلى عدة رسائل.

جرّبها: مولّد مجموعات بيانات Unicode جرّبها: عدّاد طول السلاسل النصية جرّبها: عدّاد الأحرف جرّبها: مولّد مجموعات الأحرف الخاصة

كيف تنفّذ اختبار التوطين

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

• راجع المتطلبات والتصاميم بحثاً عن قرارات الإعداد المحلي: أي إعدادات محلية، وأي تقويم وأي أرقام لكل منها، وأي الصيغ يستطيع المستخدم تغييرها، ولغة الرجوع الاحتياطي، وما الذي لا يُترجم عمداً (أسماء العلامات التجارية والنصوص القانونية).
• راجع الكود من ناحية التدويل: نصوص خارجية في ملفات موارد، وواجهات تنسيق واعية بالإعداد المحلي، ولا يسار/يمين فيزيائي في كود التخطيط، وتخزين باليونيكود من طرف إلى طرف.
• شغّل التوطين الزائف في CI: كل بناء يعمل بالإعداد الزائف، وأي نص إنجليزي عادي عيب.
• اختبر وظيفياً لكل إعداد محلي ببيانات اختبار موطّنة — أسماء وعناوين وأرقام هواتف ومبالغ وتواريخ بأنظمة الكتابة والصيغ المستهدفة — عبر كل طبقة حتى قاعدة البيانات ثم عائدة إلى التصدير والبريد والرسائل النصية.
• أجرِ مراجعة لغوية في السياق مع متحدثين أصليين، بلقطات شاشة ومفاتيح النصوص، مقابل المسرد ودليل الأسلوب.
• نفّذ الانحدار لكل إصدار: اختبارات دخان موطّنة، وفحص المفاتيح الناقصة، ومقارنة لقطات الشاشة لكل إعداد محلي في كل بناء، وجولة توطين كاملة حين تغيّر ميزة شاشات كثيفة النص.

Localization test checklist, per locale (ar-SA, hi-IN, en-US ...)

[ ] Locale is picked correctly (setting, Accept-Language, URL) and persists
[ ] Unsupported locale falls back to the agreed default, never to raw keys
[ ] No untranslated or hard-coded strings (pseudo-locale run is clean)
[ ] Plurals: counts 0, 1, 2, 3, 11, 100 give the correct Arabic forms
[ ] Dates: calendar, digits, month names, time zone, midnight shift
[ ] Numbers: digits, decimal and grouping separators, lakh/crore in hi-IN
[ ] Currency: ISO 4217 code, symbol, position, minor units, input parsing
[ ] Text: Arabic and Devanagari intact through DB, API, CSV, PDF, email, SMS
[ ] Length limits enforced in the unit the backend uses (chars vs bytes)
[ ] Sorting and search work for the locale (alif forms, diacritics)
[ ] Layout: no truncation, clipping or overlap with real strings
[ ] RTL: direction, mirroring, bidirectional text (see the RTL guide)
[ ] lang attribute on the page and on inline foreign-language text

جرّبها: مولّد بيانات اختبار متعددة اللغات جرّبها: مولّد بيانات الاختبار العربية جرّبها: مولّد بيانات الاختبار الهندية جرّبها: بيانات اختبار العناوين السعودية

أتمتة فحوص التوطين

يجب أن تعمل الاختبارات المؤتمتة بأكثر من إعداد محلي. اجعل الحزمة معاملية حسب الإعداد المحلي والمنطقة الزمنية، واحسب القيم المتوقعة بواجهات Intl في المنصة بدلاً من كتابة نصوص منسّقة داخل التحققات — فالنصوص المكتوبة يدوياً تفوتها العلامات غير المرئية وتنكسر حين تُحدَّث بيانات CLDR. واحسب القيمة المتوقعة في بيئة التشغيل نفسها التي أنتجت القيمة الفعلية: فمشغّل اختبارات Node.js والمتصفح قد يحملان إصدارين مختلفين من ICU فيختلفان.

ثلاثة فحوص قليلة الكلفة تلتقط معظم حالات الانحدار: فحص للمفاتيح الناقصة يقارن كل ملف إعداد محلي بإعداد المصدر في CI، وفحص لغير المترجم يرصد القيم المطابقة للمصدر (مع قائمة سماح لأسماء العلامات التجارية والرموز)، ومقارنة لقطات الشاشة لكل إعداد محلي في الشاشات الأساسية.

// Locale-parameterised UI check (Playwright Test)
for (const locale of ["en-US", "ar-SA", "hi-IN"]) {
  test(`order total is formatted for ${locale}`, async ({ browser }) => {
    const context = await browser.newContext({
      locale,
      timezoneId: locale === "hi-IN" ? "Asia/Kolkata" : "Asia/Riyadh",
    });
    const page = await context.newPage();
    await page.goto("/orders/ORD-2026-0042");
    // expected value computed with Intl in the same browser, not typed by hand
    const expected = await page.evaluate(
      (l) => new Intl.NumberFormat(l, { style: "currency", currency: "SAR" }).format(1500),
      locale,
    );
    await expect(page.getByTestId("order-total")).toHaveText(expected);
    await expect(page).toHaveScreenshot(`order-${locale}.png`);
  });
}

// Missing and untranslated keys (Node.js, runs in CI)
const flat = (o, p = "") => Object.entries(o).flatMap(([k, v]) =>
  v && typeof v === "object" ? flat(v, p + k + ".") : [[p + k, v]]);
const en = new Map(flat(require("./locales/en.json")));
const ar = new Map(flat(require("./locales/ar.json")));
const missing = [...en.keys()].filter((k) => !ar.has(k));
const same = [...en].filter(([k, v]) => ar.get(k) === v);
if (missing.length) { console.error("Missing in ar:", missing); process.exit(1); }
if (same.length) console.warn("Identical to en, check:", same.map(([k]) => k));

جرّبها: مقارنة JSON جرّبها: مولّد بيانات اختبار متعددة اللغات

عيوب توطين نموذجية مكتوبة كعناوين أخطاء

الأمثلة التالية توضيحية وليست حوادث حقيقية. يتبع كل منها نمط تقرير الخطأ: العَرَض والمكان والشرط؛ ويغطي دليل كتابة تقرير الخطأ بقية التقرير.

• شارة السلة تعرض "2 منتج" بدلاً من "منتجان" — الصيغة مختارة بالشرط count === 1
• بريد تأكيد الطلب يصل بالإنجليزية للمستخدمين الذين اختاروا العربية في التطبيق
• منتقي التاريخ الهجري يخزن اليوم السابق حين يُختار التاريخ بين 00:00 و03:00 بتوقيت الرياض
• حقل المبلغ يرفض "١٥٠٠" المكتوبة بلوحة مفاتيح عربية برسالة "Invalid number"
• تقرير المبيعات في hi-IN يعرض 1,234,567 بدلاً من 12,34,567
• اسم منتج هندي مقتطع داخل حرف مركّب يترك علامة حركة بدائرة منقطة في نتائج البحث
• رسالة التحقق "Field is required" غير مترجمة في نموذج التسجيل العربي

الأسئلة الشائعة

المراجع

• Internationalization (i18n) ActivityW3Cمقالات W3C ودروسها وفحوصها في التدويل لبناء محتوى ويب متعدد اللغات واختباره.
• Unicode CLDR ProjectUnicode Consortiumمستودع بيانات اللغات والمناطق المشترك: بيانات صيغ التاريخ والوقت والأرقام والعملات وقواعد الجمع التي تعتمدها معظم المنصات.
• The Unicode StandardUnicode Consortiumمجموعة المحارف العالمية وأشكال ترميزها (UTF-8 وUTF-16 وUTF-32) والتطبيع وخصائص كل نقطة ترميز.
• ECMAScript Internationalization API Specification (ECMA-402)Ecma International (TC39)مواصفة واجهة Intl في JavaScript — التنسيق الواعي باللغة والمنطقة للتواريخ والأرقام والعملات والقوائم وقواعد الجمع في المتصفح.
• Intl — MDNMDN Web Docs (Mozilla)نطاق Intl عملياً: DateTimeFormat وNumberFormat وCollator وPluralRules، وكيف يعمل التفاوض على اللغة والمنطقة.
• Time Zone DatabaseIANAقاعدة بيانات tz للمناطق الزمنية في العالم وقواعد فروق التوقيت والتوقيت الصيفي تاريخياً، وتُحدَّث عدة مرات في السنة.
• ISO 4217 — Currency codesISOرموز العملات ثلاثية الأحرف (SAR وINR وUSD…) ووحداتها الفرعية — المرجع لاختبار حقول العملة وتنسيقها.
• RFC 5646: Tags for Identifying LanguagesIETF · 2009وسوم اللغات BCP 47 (ar وar-SA وhi-IN وen-GB) — المعرّفات المستخدمة في سمة lang وترويسة Accept-Language وإعدادات اللغة.
• Indic Layout RequirementsW3C · 2020متطلبات التخطيط للخطوط الهندية مثل الديفاناغاري — الحروف المركبة وعلامات الحركات وتقسيم الأسطر — ذات الصلة بالواجهات الهندية (مسودة عمل من W3C).