توطين التاريخ والوقت والتقويم لجمهور الخليج والشام

حقل التاريخ من أقل عناصر الواجهة التي تبدو جاهزة رغم أنها ليست كذلك فعليًا. الشيفرة new Date().toLocaleDateString('ar') تُصرَّف، وتُخرج أرقامًا أو نصًا عربيًا، وتجتاز فحصًا بصريًا سريعًا في عرض تجريبي. ومع ذلك يمكن أن تكون خاطئة أمام جمهور حقيقي بثلاث طرق مستقلة في آن واحد: نظام التقويم الذي يتوقعه المستخدم ليس هو الذي يُعرض، وصيغة الساعة لا تطابق العرف المحلي، وحسابات المنطقة الزمنية تفترض إزاحة ثابتة غيّرتها حكومة ما بإشعار مدته أسبوعان.

لا شيء من هذا حالة استثنائية نادرة. إنه السلوك الافتراضي لهذه المنطقة. يتناول هذا المقال الطبقة من توطين اللغة العربية التي تقع تحت الخطوط والتخطيط ونصوص التحقق من الصحة — وهي مواضيع غطّيناها في مقالينا عن أنظمة التصميم لاتجاهي RTL وLTR والطباعة العربية في واجهات المنتجات — ويتناول تحديدًا كيفية تعامل مجال Intl في جافاسكريبت مع التقاويم والساعات والمناطق الزمنية لمستخدمي الخليج والشام، وأين تتطابق افتراضات المنصّة مع ما يتوقعه هؤلاء المستخدمون فعلًا، وأين لا تتطابق.

أبرز النقاط

• خيار calendar في Intl.DateTimeFormat لا يقتصر على gregory — فالمنصّة تدعم أيضًا عدة صيغ من التقويم الهجري (islamic، islamic-umalqura، islamic-civil، islamic-tbla، islamic-rgsa)، ويمكن أن تُحسب هذه الصيغ تواريخ مختلفة للحظة الزمنية نفسها لأن كل واحدة منها تعتمد خوارزمية مختلفة — حساب فلكي، أو قواعد جدولية ثابتة، أو نظام أم القرى السعودي.
• نقلت الحكومة السعودية المعاملات الرسمية — الرواتب والعقود والتعاملات الحكومية — إلى التقويم الميلادي في أكتوبر 2016 كإجراء لخفض التكاليف، بحسب تغطية عرب نيوز آنذاك؛ ولم يُلغِ ذلك التقويم الهجري، الذي لا يزال محوريًا في الشعائر الدينية ولا يزال معتمدًا إداريًا عبر نظام أم القرى.
• تنص المنصة الرسمية لحكومة الإمارات صراحة على أن "المناسبات الإسلامية تُحدَّد وفق ترائي الهلال"، وهذا هو سبب استحالة تثبيت تاريخ العيد مسبقًا حتى قبل أيام قليلة — فهو لا يُؤكَّد إلا قرب حلوله.
• تُعيد الدالة Intl.Locale.prototype.getCalendars() قائمة التقاويم التي تتعرف عليها لغة محلية معينة فعليًا، مرتبة حسب الأولوية، ويُظهر مثال MDN نفسه أن ar-EG تُحلّ إلى ["gregory", "coptic", "islamic", "islamic-civil", "islamic-tbla"] — أي أن تفضيلات مصر التقويمية تشمل تقويمًا لن يفكر معظم الفرق غير المصرية في اختباره أصلًا.
• تغيّرت قواعد المناطق الزمنية في المنطقة بما يكفي لجعل تثبيت الإزاحة الزمنية بشكل صريح في الشيفرة أمرًا خطيرًا فعليًا: ألغى الأردن التوقيت الصيفي نهائيًا عام 2022، وأعادت مصر العمل به عام 2023 بعد توقف دام سبع سنوات، وتراجعت الحكومة اللبنانية عن قرار موعد بدء التوقيت الصيفي في مارس 2023 في وقت متأخر لدرجة أن قاعدة بيانات المناطق الزمنية التابعة لـ IANA احتاجت إصدارين طارئين خلال خمسة أيام لمحاكاة ما جرى.
• تعتمد معظم اللهجات العربية في الخليج والشام افتراضيًا نظام ساعة 12 (hourCycle: "h12") مع علامتي ص/م بالعربية، وتعتمد عدة لغات محلية منها — السعودية ومصر والأردن والكويت وقطر والبحرين وعُمان والعراق ولبنان — افتراضيًا الأرقام الهندية الشرقية (numberingSystem: "arab") بدل الأرقام اللاتينية التي تفترضها فرق كثيرة؛ وهذا ليس نابعًا من دليل أسلوب، بل هو ما تُحلّه Intl.DateTimeFormat افتراضيًا لهذه اللغات المحلية.

تقويمان، وليس أيّهما هامشيًا

الافتراض الذي تقوم عليه معظم مكوّنات اختيار التاريخ — أن التاريخ تاريخ واحد، وأن التوطين يقتصر على تبديل الكلمات المحيطة به — ينهار في اللحظة التي يفتح فيها مستخدم خليجي التطبيق. هناك نظاما تقويم مستخدَمان فعليًا وبنشاط في المنطقة، وأي منتج يعرض التاريخ الميلادي فقط يكون قد اتخذ قرارًا لم يكن يقصده على الأرجح.

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

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

ما تدعمه فعليًا خاصية calendar في Intl.DateTimeFormat

هذه مشكلة محلولة أصلًا على مستوى المنصّة — يسهل فقط إغفال ذلك، لأن معظم استخدامات Intl.DateTimeFormat لا تُحدّد خيار calendar صراحةً أبدًا. وفق توثيق MDN لمُنشئ Intl.DateTimeFormat()، يقبل calendar أي قيمة تُعيدها Intl.supportedValuesOf('calendar')، والعديد من هذه القيم صيغ مختلفة من التقويم الهجري، لا خيارًا واحدًا موحّدًا باسم "islamic":

Intl.supportedValuesOf('calendar').filter(c => c.startsWith('islamic'));
// ["islamic", "islamic-civil", "islamic-rgsa", "islamic-tbla", "islamic-umalqura"]

هذه الصيغ ليست تسميات متبادلة لتقويم واحد — بل خوارزميات مختلفة قد تختلف في تحديد التاريخ الهجري المقابل ليوم ميلادي معين. توثيق CLDR الخاص بأنواع التقويم الهجري صريح في هذا الشأن: islamic-civil وislamic-tbla تقويمان جدوليان يعتمدان قواعد حسابية ثابتة؛ أما islamic المجرّد فهو "مبني على حساب فلكي لطور القمر بحسب موقع معين"، ويُوصف في المصدر نفسه بأنه تقريب لا مطابقة تامة للممارسة الفعلية؛ أما islamic-umalqura فهو "الخوارزمية... المستخدمة في السعودية لأغراض إدارية" — حتمية النتيجة، لكنها مشتقة فلكيًا لا حسابية بحتة. ويذكر المصدر نفسه النتيجة المترتبة على ذلك صراحة: "قد تقع اللحظة الزمنية نفسها في تاريخ مختلف بحسب الصيغة الهجرية المستخدمة فعليًا." وبالنسبة إلى جمهور خليجي، فإن islamic-umalqura — لا islamic الأقصر والأقرب ظاهريًا للاختيار البديهي — هي الصيغة التي تطابق ما تستخدمه الأنظمة السعودية ومعظم المنتجات الموجّهة للخليج فعليًا.

يمكن اختيار التقويم إما عبر خيار calendar في المُنشئ، أو عبر امتداد اللغة المحلية -u-ca- الخاص بيونيكود — وكلاهما يُحلّ إلى النتيجة نفسها:

const hijri = new Intl.DateTimeFormat('ar-SA', {
  calendar: 'islamic-umalqura',
  year: 'numeric',
  month: 'long',
  day: 'numeric',
});

hijri.format(new Date('2026-09-14'));
// "٣ ربيع الآخر ١٤٤٨ هـ" — تم التحقق منها فعليًا عبر تنفيذ حي على محرك V8/ICU

// معادلة، عبر امتداد اللغة المحلية:
new Intl.DateTimeFormat('ar-SA-u-ca-islamic-umalqura').format(new Date('2026-09-14'));

بالنسبة إلى جمهور خليجي، النمط العملي هو عرض التقويمين معًا أينما كان التاريخ ذا أهمية — تاريخ انتهاء، أو مدة عقد، أو موعد فعالية — بدل الاكتفاء بأحدهما:

function formatBothCalendars(date, locale = 'ar-SA') {
  const gregorian = new Intl.DateTimeFormat(locale, {
    calendar: 'gregory', day: 'numeric', month: 'long', year: 'numeric',
  }).format(date);
  const hijri = new Intl.DateTimeFormat(locale, {
    calendar: 'islamic-umalqura', day: 'numeric', month: 'long', year: 'numeric',
  }).format(date);
  return `${gregorian} (${hijri} هـ)`;
}

دع اللغة المحلية تُخبرك أي التقاويم ذات صلة

تثبيت "الميلادي والهجري" كخيارين وحيدين تحسّن عن الاكتفاء بالميلادي فقط، لكنه يبقى تخمينًا. تُعيد Intl.Locale.prototype.getCalendars() التقاويم التي تتعرف عليها لغة محلية معينة فعلًا بوصفها شائعة الاستخدام، مرتبة حسب الأولوية — وهي مصدر حقيقة أوثق من افتراض عن معنى "العربية":

new Intl.Locale('ar-SA').getCalendars();
// ["gregory", "islamic-umalqura", "islamic", "islamic-rgsa"]

ويُظهر توثيق MDN نفسه للدالة حالة أكثر إثارة للدهشة: تُحلّ ar-EG إلى ["gregory", "coptic", "islamic", "islamic-civil", "islamic-tbla"]. والتقويم القبطي هنا ليس خطأً — بحسب تقرير إيجيبشان ستريتس، لا يزال مستخدَمًا شعبيًا لدى المزارعين المصريين لتتبّع المواسم الزراعية، ولدى الكنيسة القبطية الأرثوذكسية في تقويمها الطقسي — وهو بالضبط نوع التفصيل الخاص باللغة المحلية الذي لن يفكر فريق يخمّن أن "التقويمين اللذين تستخدمهما منطقة الشرق الأوسط" في اختباره. بناء خيارات أداة اختيار التقويم من getCalendars() الخاصة باللغة المحلية النشطة، بدل مصفوفة ثابتة مثل ['gregory', 'islamic']، يمنح مصر خيار التقويم القبطي دون أن يضطر أحد إلى معالجة هذه الحالة الخاصة، ويمنع لغة محلية لم تُختبر بعد من الانزلاق بصمت إلى افتراض خاطئ.

عرف عطلة نهاية الأسبوع: مُغطّى بالفعل، ولا داعي لتكراره

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

مناطق زمنية لا تستقر على حال

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

function offsetFor(tz, date) {
  const parts = new Intl.DateTimeFormat('en-US', { timeZone: tz, timeZoneName: 'shortOffset' }).formatToParts(date);
  return parts.find(p => p.type === 'timeZoneName').value;
}

for (const tz of ['Asia/Riyadh', 'Asia/Dubai', 'Asia/Amman', 'Asia/Beirut', 'Africa/Cairo']) {
  console.log(tz, offsetFor(tz, new Date('2026-01-15')), '→', offsetFor(tz, new Date('2026-07-15')));
}
// Asia/Riyadh  GMT+3 → GMT+3   (ثابتة طوال العام)
// Asia/Dubai   GMT+4 → GMT+4   (ثابتة طوال العام)
// Asia/Amman   GMT+3 → GMT+3   (ثابتة منذ تعديل الأردن عام 2022، أدناه)
// Asia/Beirut  GMT+2 → GMT+3   (تتغيّر مع التوقيت الصيفي)
// Africa/Cairo GMT+2 → GMT+3   (تتغيّر مع التوقيت الصيفي)

وهذا التذبذب حديث بما يكفي لجعل أي افتراض عن المنطقة الزمنية ثُبِّت في تطبيق منذ ثمانية عشر شهرًا خاطئًا بالفعل اليوم.

غيّر الأردن قاعدته جذريًا: ففي أكتوبر 2022 أعلنت الحكومة وقف العمل بالتوقيت الصيفي والبقاء بشكل دائم على توقيت غرينتش+3، وهي خطوة نقلت صحيفة ذا ناشونال أن الحكومة بررتها بأنها "الاستفادة القصوى من ساعات النهار" دون الاضطراب المتكرر مرتين سنويًا. أما مصر فسلكت الاتجاه المعاكس: فبعد سبع سنوات دون توقيت صيفي، أعادت العمل به عام 2023، بحيث تُقدَّم الساعة في نهاية أبريل وتُؤخَّر في نهاية أكتوبر — جدول أكّدت إيجيبشان ستريتس استمراره في السنوات التالية.

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

والعبرة ليست أن "لبنان غير متوقَّع" — بل أن معرّف منطقة زمنية باسمه القياسي من IANA، محدَّثًا باستمرار عبر تحديثات نظام التشغيل والمتصفح الروتينية، استوعب ذلك الاضطراب كله فلم تضطر شيفرة التطبيق إلى فعل شيء. أي شيفرة تحسب توقيت بيروت كإزاحة ثابتة قدرها UTC+2 أو UTC+3 كانت خاطئة لعدة أيام في 2023. أما الشيفرة التي طلبت من Intl.DateTimeFormat المنطقة Asia/Beirut فحصلت على الإجابة الصحيحة، وإن بدت غريبة مؤقتًا، بمجرد تحديث بيانات المناطق الزمنية:

// هشّة: تفترض إزاحة ثابتة غيّرتها حكومات إقليمية
// أكثر من مرة في السنوات الأخيرة، أحيانًا بإشعار مدته أيام.
const wrongOffset = new Date(utcTimestamp + 3 * 60 * 60 * 1000);

// مرنة: تُفوّض حساب الإزاحة وقواعد التوقيت الصيفي إلى قاعدة
// بيانات المناطق الزمنية في المنصّة، التي تستوعب هذا النوع من التغيير.
const correct = new Intl.DateTimeFormat('ar-LB', {
  timeZone: 'Asia/Beirut',
  hour: 'numeric',
  minute: 'numeric',
  timeZoneName: 'short',
}).format(new Date(utcTimestamp));

الالتزام الوحيد الذي يقع على عاتقك هنا هو إبقاء بيانات ICU/tz في بيئة التشغيل لديك محدَّثة — فإصدار قديم من Node.js طويل الأمد أو متصفح لم يُحدَّث منذ مدة قد يتأخر عن تغيير قاعدة كتغيير الأردن أو لبنان، وهذا يدعو إلى متابعة إصدار ICU في منصّتك، لا إلى حساب الإزاحة يدويًا بدلًا من ذلك.

نظاما الساعة 12 و24، والأرقام الكامنة تحتهما

صيغة الساعة من أكثر التفاصيل عرضة للتثبيت على قيمة عامة واحدة تُشحن على هذا النحو، وهذا خطأ — فلهجات الخليج والشام العربية لا تُفضّل صيغة واحدة موحّدة. تشغيل Intl.DateTimeFormat دون تحديد hourCycle صراحةً وقراءة resolvedOptions() يُظهر القيمة الافتراضية الفعلية وفق خياري hourCycle وhour12 الموثّقَين في MDN:

for (const loc of ['ar-SA', 'ar-AE', 'ar-EG', 'ar-JO', 'ar-KW', 'ar-QA']) {
  const dtf = new Intl.DateTimeFormat(loc, { hour: 'numeric', minute: 'numeric' });
  console.log(loc, dtf.resolvedOptions().hourCycle, dtf.format(new Date()));
}
// ar-SA h12 ٦:٣٠ م
// ar-AE h12 6:30 م
// ar-EG h12 ٦:٣٠ م
// ar-JO h12 ٦:٣٠ م
// ar-KW h12 ٦:٣٠ م
// ar-QA h12 ٦:٣٠ م

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

new Intl.DateTimeFormat('ar-SA', { hourCycle: 'h23', hour: '2-digit', minute: '2-digit' })
  .format(new Date()); // "١٨:٣٠" — نظام 24 ساعة مفروض عمدًا، خلافًا للافتراضي في اللغة المحلية

ويكشف الفحص نفسه افتراضًا ثانيًا يسهل إغفاله: نمط الأرقام. تعتمد ar-SA وar-EG وar-JO وar-KW وar-QA وar-BH وar-OM وar-IQ وar-LB جميعها افتراضيًا numberingSystem: "arab" — أي الأرقام الهندية الشرقية (٠١٢٣٤٥٦٧٨٩) — بينما تُعدّ ar-AE الاستثناء بين اللغات المحلية الخليجية، إذ تعتمد افتراضيًا الأرقام اللاتينية (latn). فريق يختبر بصريًا ar-AE فقط ويفترض أن بقية الخليج تطابقها سيشحن نمط الأرقام الخاطئ في كل مكان آخر، والعكس صحيح لفريق يتحقق من ar-SA فقط. لا تُعدّ إحدى الصيغتين "الأصح" من الأخرى؛ وخاصية numberingSystem هي الاستثناء الصريح للحالات التي تحتاج فرض نمط معين بغض النظر عن اللغة المحلية، مثل معرّف رقمي مشترك ينبغي أن يبقى بأرقام لاتينية داخل نص عربي:

new Intl.DateTimeFormat('ar-SA', { numberingSystem: 'latn', year: 'numeric', month: 'numeric', day: 'numeric' })
  .format(new Date()); // "14/9/2026" — أرقام لاتينية مفروضة على لغة محلية تعتمد افتراضيًا الأرقام الهندية الشرقية

وثمة اختلاف ثالث أصغر لكنه حقيقي يكمن في أسماء الأشهر الميلادية نفسها، ويظهر بوضوح مماثل من مخرجات على نمط resolvedOptions:

for (const loc of ['ar-SA', 'ar-EG', 'ar-JO', 'ar-LB', 'ar-IQ']) {
  console.log(loc, new Intl.DateTimeFormat(loc, { month: 'long' }).format(new Date('2026-09-14')));
}
// ar-SA سبتمبر   ar-EG سبتمبر   (نقل صوتي عن اللاتينية)
// ar-JO أيلول    ar-LB أيلول    ar-IQ أيلول   (أصل آرامي)

تعتمد لهجتا الخليج ومصر افتراضيًا أسماء الأشهر المنقولة صوتيًا عن اللاتينية، بينما تعتمد لهجتا الشام والعراق افتراضيًا المجموعة الأقدم ذات الأصل الآرامي. لا يُعدّ أي منهما خطأً؛ فشحن مجموعة أسماء أشهر واحدة لكل الأسواق الناطقة بالعربية اختيار لهجوي ضمني يستحق أن يُتّخذ عمدًا.

أخطاء شائعة

افتراض أن "العربية" تعني تقويمًا واحدًا. الاقتصار على الميلادي يُسقط بصمت أي محتوى مرتبط بالتقويم الهجري، والعكس صحيح مع الاقتصار على الهجري. ابنِ خيارات التقويم من getCalendars() لكل لغة محلية بدل التخمين.

استخدام islamic المجرّد بدل islamic-umalqura. قد تُحلّ الصيغتان إلى تاريخين هجريين مختلفين لليوم نفسه. بالنسبة إلى جمهور خليجي، تكاد islamic-umalqura تكون دائمًا الصيغة التي يتوقعها المستخدمون فعليًا.

تثبيت إزاحة زمنية صريحة بدل معرّف منطقة زمنية من IANA. غيّر كل من الأردن ومصر ولبنان قواعد التوقيت الصيفي في السنوات الأخيرة، أحدها بإشعار مدته أيام. تخزين +3 بدل Asia/Amman يحوّل كل تغيير مستقبلي إلى خطأ في شيفرتك.

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

افتراض أن نمط الأرقام في لغة خليجية واحدة يمثّل بقيتها. تعتمد ar-AE افتراضيًا أرقامًا لاتينية بينما تعتمد معظم بقية الخليج والشام أرقامًا هندية شرقية — اختبار لغة محلية واحدة فقط أثناء ضمان الجودة يُغفل النمط الآخر كليًا.

تجميع كل ذلك معًا

لا شيء من هذا يحتاج مكتبة تقويم خارجية أو محوّلًا هجريًا مكتوبًا يدويًا — تحمل Intl.DateTimeFormat وIntl.Locale أصلًا البيانات الصحيحة لكل لغة محلية ومنطقة زمنية تستخدمها المنطقة. ما يحتاجه الأمر هو فريق يسأل المنصّة بدل أن يفترض: استدعاء getCalendars() بدل تثبيت خيارين افتراضيين، واختيار islamic-umalqura عمدًا بدل islamic الأقصر، ومخاطبة المناطق الزمنية بمعرّفها القياسي من IANA بحيث يصبح قرار التوقيت الصيفي المقبل لحكومة ما مشكلة يُصلحها شخص آخر لا خطأً في شيفرتك، ومعاملة نظام الساعة 12 والأرقام الهندية الشرقية بوصفهما الافتراض الحقيقي في الخليج والشام لا انحرافًا عن معيار عالمي بنظام 24 ساعة وأرقام لاتينية لم يكن شاملًا يومًا. وبإضافة أساس التخطيط والطباعة من دليلَي أنظمة التصميم لاتجاه RTL والطباعة العربية، ونصوص التحقق من الصحة الواعية بقواعد الجمع من مقالنا عن رسائل التحقق من صحة النماذج بالعربية، يكتمل بذلك الجزء من توطين اللغة العربية الذي يسهل الخلط بينه وبين "مجرّد تنسيق" — إلى أن يظهر تاريخ بتقويم خاطئ أمام مستخدم لم يكن أصلًا في شك بشأن التقويم الذي يتوقعه.