يحتاج نظام التصميم العربي والإنجليزي إلى مسار واضح لتغيير المكونات والنصوص، لا إلى مكتبة معتمدة مرة واحدة فقط. إذا عدّل فريق رسالة أو حجم حقل ثم استخدمها الآخرون دون مراجعة، فقد تتباعد اللغتان ويصعب معرفة النسخة الصحيحة. الحوكمة العملية تجيب: من يقترح؟ من يراجع المعنى والسلوك؟ من يطلق؟ ومن يتأكد من وصول التغيير إلى المنتجات؟
ليس المطلوب لجنة لكل مسافة أو كلمة. المطلوب تصنيف التغيير بحسب أثره، وتعيين مسؤوليات لا تضيع بين التصميم والهندسة والمحتوى. ابدأ بأبسط إجراء يستطيع فريقك الالتزام به، ثم وسّعه إذا ظهرت حاجة فعلية. عملية كبيرة لا تُستخدم لا تحمي النظام.
فرّق بين ملكية المصدر وملكية الاستخدام
مالك المكتبة مسؤول عن النسخة المشتركة، لكن فريق المنتج مسؤول عن اعتمادها في شاشاته. قد يُنشر إصلاح داخل المكتبة بينما يبقى التطبيق على نسخة قديمة. لذلك لا تعتبر «نشر المكون» نهاية العمل إذا كان الهدف تصحيح تجربة موجودة.
عيّن مالكاً تصميمياً للقاعدة والمظهر، ومالكاً هندسياً للسلوك والتنفيذ، ومراجعاً للمحتوى العربي والإنجليزي، ومسؤولاً عن التبني في كل منتج متأثر. يمكن أن يشغل شخص واحد أكثر من دور إذا امتلك المهارة والوقت، لكن لا تترك الدور مجهولاً. وتحتاج صيانة الكود والعمل المستمر إلى اتفاق صريح؛ وجود خدمة أنظمة التصميم في المشروع لا يعني تعهداً مفتوحاً بإدارة كل إصدار مستقبلي.
ما الذي يستحق مراجعة مشتركة؟
قسّم الطلبات إلى تغييرات محدودة لا تبدل السلوك، وتغييرات تؤثر في المعنى أو التفاعل، وتغييرات تستلزم انتقالاً للمستهلكين. تحديد الفئة يعتمد على المنتج، وليس على حجم الرسم. كلمة واحدة قد تغير التزاماً أو توحي بنجاح غير مؤكد، بينما تعديل مسافة قد يبقى محلياً.
ضع ضمن المراجعة أثر العربية والإنجليزية، وطول المحتوى، والحالات البديلة، واتجاه النص المختلط. في الويب، تميز W3C بين لغة المحتوى واتجاهه؛ لذلك لا يكفي اعتماد الترجمة للتحقق من سلوك الاتجاه. مرجع W3C لاتجاه النص. أما تفاصيل التنفيذ الخاصة بالتطبيقات الأصلية على كل منصة فتحتاج تحققاً منفصلاً.
مثال افتراضي: رسالة خطأ أطول بالعربية
لنفترض أن رسالة «تعذر الحفظ» ستصبح أكثر فائدة: «لم تُحفظ التغييرات. راجع الحقول المحددة ثم حاول مجدداً». النسخة الإنجليزية المقابلة يجب أن تعبّر عن السبب والإجراء نفسيهما، لا أن تكتفي برسالة عامة. المثال يوضح عملية تغيير مقترحة، وليس نتيجة مشروع قائم.
يقدم فريق المنتج طلباً يتضمن المشكلة، ومكان ظهورها، والنسختين المقترحتين، وسبب الاعتقاد بأن الرسالة الحالية لا تكفي. يراجع فريق الهندسة ما إذا كان الفشل مرتبطاً فعلاً بصحة الإدخال؛ إذا كان السبب انقطاعاً مجهولاً، تُرفض الصياغة لأنها توجه المستخدم إلى إصلاح غير مناسب. يراجع المحتوى وضوح المصطلح وثباته مع بقية الواجهة.
يكشف التصميم أن الرسالة العربية تتجاوز الارتفاع الثابت للمكون في شاشة ضيقة. يُقترح تعديل قابلية تمدده، ثم تُراجع الحالات التي تستخدمه. لو كان في نافذة محدودة المساحة، يُختبر تأثيره على الأزرار وإمكانية الوصول إلى بقية المحتوى. التعديل هنا يمس المكون، وليس النص فقط.
بعد قبول الحل، يسجل الإصدار الرابط إلى النسخة التصميمية والنسخة البرمجية والفحوص المنفذة. لنفترض أن منتجين يستخدمان المكون: يؤكد الأول تبني الإصدار، بينما يحتاج الثاني معالجة تخطيط قديم. يبقى الثاني مسجلاً كتحديث معلق بمالك، ولا يُعلن إصلاح كل المنتجات لمجرد نشر المكتبة.
سجل تغيير مختصر لكنه كافٍ
يُستحسن أن يحتوي الطلب الواحد على:
- المشكلة المدعومة بمثال، والمستخدم أو المهمة المتأثرة.
- النسختين العربية والإنجليزية والقيم المتغيرة داخل النص.
- المكونات والمنتجات المتأثرة وما قد ينكسر عند التحديث.
- قرار المراجعين وسبب الاستثناء إن وجد.
- رابط الإصدار، ودليل الفحص، وحالة التبني لدى المستهلكين.
- طريقة التراجع أو المعالجة إن ظهر عيب بعد النشر.
يمكن أن تدعم استراتيجية المحتوى وإنتاجه ضبط المصطلحات والمحتوى الثنائي اللغة ضمن نطاق متفق عليه. وتحدد خدمة تصميم واجهات المستخدم السلوك المرئي للحالات، بينما تحتاج أدلة الإصدار إلى اختبار وضمان جودة البرمجيات بحسب التغطية المحددة.
اسمح بالاستثناء دون تحويله إلى فوضى
قد يحتاج منتج إلى نمط مختلف لا يخدم بقية المنتجات. اطلب سبباً ومستهلكاً ومالكاً ونقطة مراجعة، بدلاً من منعه تلقائياً أو إضافته فوراً إلى المكتبة العامة. إذا تكرر الاحتياج لاحقاً، يُعاد تقييم جعله نمطاً مشتركاً. أما الاستثناء المؤقت المرتبط بقيد قديم فيحتاج شرط انتهاء، لا عبارة «نراجعه لاحقاً» فقط.
قِس صحة العملية بأدلة تشغيلية: هل يعرف الفريق أين النسخة المعتمدة؟ هل التغييرات المؤثرة لها مستهلكون معروفون؟ هل الاستثناءات القديمة ما زالت مبررة؟ لا تجعل كثرة الإصدارات أو عدد المكونات دليلاً وحيداً على النضج. قد يعكس الرقم الكبير إعادة عمل أو تفريعاً غير ضروري.
ومن الأخطاء مراجعة العربية بعد اعتماد الإنجليزية نهائياً، أو ترك الملاحظات في رسائل خاصة، أو تحديث التصميم دون رابط إلى التنفيذ. كذلك لا تصف مكوناً بأنه آمن لكل حالات الوصول بسبب اجتياز فحص سابق؛ تغيير المحتوى والسياق قد يفرض إعادة تحقق محددة.
أسئلة شائعة
هل نحتاج مديراً متفرغاً للنظام؟
يعتمد على حجم الاستخدام والتغيير. المهم وجود مسؤولية ووقت مخصص وآلية بديلة عند غياب المالك، لا مسمى وظيفي معين.
هل كل تغيير نصي يحتاج إصداراً؟
يحتاج سجلاً يمكن تتبعه وطريقة توصيل للمستهلكين. أما نوع الإصدار وطريقة ترقيمه فيحددهما اتفاق الفريق وأثر التغيير، لا قاعدة عامة واحدة.
من يملك القرار عند اختلاف اللغتين؟
يُحسم المعنى لدى مالك المنتج والمحتوى، ويُراجع التعبير في كل لغة مع شخص مؤهل. لا تُختصر العربية لإرضاء مساحة ثابتة إذا ضاع الإجراء المطلوب.
متى نغلق طلب التغيير؟
عندما تتحقق شروطه: اعتماد المصدر وفحصه وتوضيح تبني المستهلكين أو تسجيل المتبقي بمسؤولية صريحة. نشر الملف وحده قد يكون مرحلة فقط.
ابدأ بمكون مشترك واحد وتغيير حقيقي معلق. تطبيق مسار مراجعة كامل عليه يكشف الاحتياجات العملية أفضل من كتابة سياسة طويلة لا تختبرها الفرق.
المصدر
- W3C: الاتجاه البنيوي للنص في HTML، راجع في 26 أكتوبر 2026.
