الترجمة تغيّر الكلمات، أما التوطين فيغيّر طريقة عمل التجربة
يمكن أن تكون ترجمة الملف الرقمي صحيحة لغويًا، ومع ذلك يشعر المستخدم أن الصفحة صُممت للغة أخرى ثم نُقلت إليه. قد تكون الكلمات سليمة، لكن اتجاه القراءة، وترتيب المعلومات، وأسماء الأزرار، والمسافات، وبنية النماذج، وأمثلة الإدخال، وصيغ التاريخ، وحتى طريقة التعامل مع المحتوى الناقص ما زالت مبنية على افتراضات النسخة الأصلية. الترجمة تعالج الكلمات، أما التوطين فيسأل إن كان المنتج كله يتصرف بصورة طبيعية لمستخدم هذه اللغة.
هذا الفرق مهم لأن الملف الرقمي ليس وثيقة ثابتة. هو واجهة تضم هوية، وإجراءات، وتنقلًا، ونماذج، وبيانات وصفية، ووسائط، وحالات مختلفة للمحتوى. كل طبقة منها قد تحمل افتراضات لغوية. عنوان قصير بالإنجليزية قد يصبح أطول بالعربية ويضغط على الزر المجاور. ترتيب عنصرين مناسب للقراءة من اليسار قد يصبح مربكًا عند القراءة من اليمين. نموذج قد يقسم الاسم بطريقة لا تناسب جميع الثقافات. ومبدّل اللغة قد يغيّر الكلمات لكنه يفقد المستخدم الصفحة التي كان فيها. تحسين الترجمة وحده لا يحل هذه المشكلات.
تتعامل مراجع التوطين المتخصصة، ومنها عمل بيرت إيسيلينك، مع التوطين باعتباره عملية تجمع التحرير والهندسة والاختبار وإدارة المنتج متعدد اللغات. الدرس العملي هو ألا تُعامل العربية كطبقة تُضاف بعد اكتمال الإنجليزية. متطلبات اللغة تؤثر من البداية في نموذج المحتوى والتخطيط والتنقل والتحقق والاختبار وطريقة النشر.
الملف القوي يشترك بين اللغات في الحقيقة الأساسية، لكنه يسمح لكل لغة بأن تعرض هذه الحقيقة بالطريقة الأنسب لقارئها. اسم النشاط والعرض والأسعار والشروط والحقائق يجب أن تبقى متوافقة. أما الصياغة والتسلسل البصري فليس مطلوبًا أن يتطابقا حرفيًا. الهدف ليس أن تبدو النسختان متشابهتين صورةً بصورة، بل أن تقدما معنى متكافئًا، وسهولة استخدام متكافئة، ووصولًا متكافئًا إلى الإجراءات المهمة.
والنتيجة العملية هي أن قرارات التوطين يجب أن تُكتب كقواعد منتج، لا أن تبقى استثناءات محفوظة في ذاكرة الفريق. من المفيد وجود مواصفة صغيرة تحدد الحقول المشتركة، والحقول المستقلة لكل لغة، والعناصر التي تنعكس، والقيم التي تبقى بصيغتها الأصلية، وما الذي يحدث عند غياب الترجمة. هذه المواصفة تخدم التصميم والتطوير والتحرير والاختبار معًا، لأنها تجعل الجودة قابلة للتكرار وتمنع اعتماد النسخة العربية على شخص واحد يتذكر سبب تعديل مكوّن ما قبل أشهر.
ومن المفيد أيضًا مراجعة التوطين عند إضافة نوع ملف أو مكوّن جديد؛ فنجاح العربية في صفحة واحدة لا يعني أن القاعدة نفسها ستنجح تلقائيًا في كل واجهة جديدة.
RTL نظام تخطيط كامل، وليس محاذاة النص إلى اليمين
يُختزل دعم العربية أحيانًا في أمر بصري بسيط: ضع النص على اليمين. هذا تنفيذ ناقص. العربية تغيّر الاتجاه الأساسي الذي يقرأ المستخدم من خلاله الواجهة ويمسحها بصريًا، ولذلك يؤثر الاتجاه في ترتيب العناصر، والمحاذاة، ومسار التنقل، والأيقونات الاتجاهية، ومواقع أدوات التحكم، والجداول، والنماذج، وطريقة ظهور النصوص المختلطة بين العربية والإنجليزية.
عندما تكون العربية هي لغة الصفحة الأساسية، يجب أن يكون اتجاه الصفحة خاصية بنيوية، لا سلسلة من التصحيحات اليدوية لكل عنصر. توصي إرشادات W3C بضبط الاتجاه الأساسي للمستند، ثم تغيير الاتجاه محليًا فقط عندما يحتاج جزء محدد إلى ذلك. بهذه الطريقة يفهم المتصفح أن الصفحة عربية من اليمين إلى اليسار، بدل أن تكون صفحة يسارية جرى دفع فقراتها نحو اليمين.
تظهر جودة التنفيذ فعلًا عند النص المختلط. قد تحتوي الجملة العربية على رابط، أو بريد إلكتروني، أو اسم منتج إنجليزي، أو رقم هاتف، أو سعر، أو رمز. هذه العناصر لا تتبع الاتجاه نفسه بالضرورة. ولهذا توجد خوارزمية يونيكود للنص ثنائي الاتجاه؛ فهي تتعامل مع أحرف عربية وإنجليزية وأرقام وعلامات ترقيم داخل السطر نفسه. الحل الصحيح هو استخدام الدلالة والاتجاه والعزل المناسب، لا إضافة مسافات يدوية حتى يبدو السطر مقبولًا على هاتف واحد.
كذلك لا يجب قلب كل شيء آليًا. سهم الرجوع يحمل معنى اتجاهيًا وغالبًا يحتاج إلى العكس. أما زر التشغيل أو شعار شركة أو رمز QR أو أيقونة معروفة لا تعبّر عن اتجاه الحركة، فلا تُقلب فقط لأن الصفحة عربية. السؤال هو: هل هذا العنصر يشرح اتجاهًا فعليًا أو اتجاه قراءة؟
ولفحص النظام، لا تستخدم أمثلة سهلة فقط. اختبر جملة عربية فيها اسم إنجليزي طويل، ورابط، ورقم هاتف، وعملة، وأقواس، وتاريخ، ونسبة مئوية. إذا بقيت هذه الحالات مقروءة على عروض الموبايل المختلفة من دون ترقيع خاص لكل مثال، فالاتجاه جزء من النظام فعلًا. أما إذا كانت الصفحة تنجح فقط مع النصوص المختارة بعناية، فالدعم ما زال شكليًا.
ويجب أن يبقى الاتجاه صحيحًا عند تغير التخطيط حسب حجم الشاشة. قد تكون الواجهة سليمة على اللابتوب ثم تتعطل عندما تتحول البطاقات إلى صف عمودي أو تنتقل الإجراءات إلى قائمة مختصرة أو شريط ثابت أسفل الهاتف. ترتيب العناصر في الصفحة، وترتيبها البصري، وتسلسل القراءة الذي تتلقاه تقنيات المساعدة يجب أن تبقى متوافقة. لذلك لا يكفي اختبار RTL بلقطة واحدة؛ يجب فحص المكوّن نفسه بعد الالتفاف والتكديس وتغير طول العناوين.
ويجب فحص ترتيب التركيز بلوحة المفاتيح وقارئات الشاشة عند تغير الاتجاه، لأن المظهر الصحيح لا يكفي إذا كان تسلسل التفاعل المنطقي يسير بعكس ما يراه المستخدم.
النص البديل AR
البنية نفسها للملف موطنة لاتجاهي LTR وRTL مع عرض صحيح للنص المختلط
إرشاد الصورة
وحّد الحقائق، واترك لكل لغة حرية الصياغة الطبيعية
الاتساق بين اللغات لا يعني أن تقابل كل جملة إنجليزية جملة عربية بالطول والترتيب نفسيهما. يمكن للنسختين أن تنقلا الحقيقة التجارية نفسها بصياغة مختلفة في الإيقاع والترتيب ودرجة التفصيل. بل إن فرض التطابق الحرفي قد ينتج عدم اتساق من نوع آخر: لغة تبدو طبيعية، ولغة ثانية تبدو كأنها خرجت من آلة ترجمة.
ما يجب تثبيته هو المعنى والحقائق. اسم النشاط، ونطاق الخدمة، والأسعار، وشروط الأهلية، ومواعيد العمل، وشروط التوصيل أو الضمان، وبيانات التواصل، وأي ادعاء موضوعي يجب ألا يتعارض بين العربية والإنجليزية. أما التعبير التحريري حول هذه الحقائق فيمكن أن يتكيف. تسمية قصيرة بالإنجليزية قد تحتاج عبارة أوضح بالعربية. وقد يكون من الطبيعي أن تبدأ الجملة العربية بالسياق قبل الفائدة، بينما تبدأ الإنجليزية بالفعل مباشرة.
هذا يقود إلى بنية محتوى أفضل: افصل الحقائق المشتركة عن العرض اللغوي. البيانات التي يجب أن تكون واحدة في جميع اللغات يفضّل أن تأتي من مصدر منظم مشترك متى كان ذلك ممكنًا، بينما تبقى الحقول التحريرية مستقلة لكل لغة. بهذه الطريقة نقلل مشكلتين معًا: الترجمة الحرفية الثقيلة، وانحراف الحقائق بين نسختين تُدار كل منهما بمعزل عن الأخرى.
ويجب التعامل مع انحراف النسخ بجدية. إذا تغيّر شرط في خطة، أو وصف خدمة، أو سعر، أو معلومة أساسية في المصدر، لا يكفي أن تكون الترجمة القديمة موجودة تقنيًا. ينبغي أن تدخل النسخة الأخرى حالة مراجعة واضحة. المحتوى المترجم له دورة حياة، وليس صفة دائمة تُمنح مرة واحدة.
لذلك يحتاج التدقيق إلى سؤالين منفصلين: هل هذه العربية طبيعية وواضحة بذاتها؟ وهل ما زالت تحمل الحقيقة نفسها الموجودة في النسخة الأخرى؟ المراجع اللغوي يجيب عن الأول، وفحص التكافؤ يجيب عن الثاني. الجمع بينهما أقوى من اعتبار اعتماد الترجمة نهاية العملية.
في الملفات التي تسمح بتبديل اللغة لحظيًا، يلاحظ المستخدم الاختلاف بسرعة. المطلوب أن يلتقي بالنشاط نفسه والعرض نفسه، لا بصفحتين متقاربتين فقط في الاسم.
كما يفيد التمييز بين تعديل لغوي وتعديل في حقيقة تجارية. تصحيح علامة ترقيم في الوصف الإنجليزي لا يحتاج بالضرورة إلى دورة المراجعة نفسها التي يحتاجها تغيير سعر أو شرط أهلية. وفي المقابل، لا يُعد التغيير الجوهري مكتملًا إذا حُدثت لغة واحدة فقط. تصنيف التغييرات حسب أثرها يساعد الفريق على تركيز المراجعة في النقاط التي قد يؤدي اختلافها إلى تضليل العميل، مع إبقاء مساحة لتحسين الأسلوب في كل لغة بصورة مستقلة.
ومن الأفضل أن تسجل أنظمة التحرير سبب الحاجة إلى المراجعة، حتى يعرف المحرر هل التغيير لغوي بسيط أم نتيجة تعديل في حقيقة يجب مطابقتها بدقة.
المحتوى البديل يحتاج سياسة لكل نوع حقل، لا تصرفًا عشوائيًا
من الطبيعي ألا تكتمل كل اللغات في الملف الرقمي في اللحظة نفسها. قد يكتب المستخدم النبذة الإنجليزية ويترك العربية فارغة. وقد يُترجم اسم الخدمة من دون وصفها الطويل. وقد يبقى اسم النشاط أو العلامة التجارية بلغته الأصلية عن قصد. في المقابل، لا يجوز لزر نظامي أساسي أن يختفي لمجرد أن ملف الترجمة ناقص.
إذا لم توجد سياسة واضحة للمحتوى البديل، تبدأ الصفحة بالتصرف بصورة عشوائية: حقل يعرض الإنجليزية، وآخر يصبح فارغًا، وثالث يظهر نصًا افتراضيًا، ورابع يخفي المكوّن كله. قد تستمر الصفحة في العمل، لكن المستخدم لا يستطيع معرفة إن كان ما يراه مقصودًا أم ناقصًا أم معطلًا.
الحل الأفضل هو تصنيف الحقول. تسميات الواجهة النظامية يفترض أن تكون لها ترجمة مكتملة. الأسماء الخاصة، والروابط، وعناوين البريد، وبعض الأكواد يمكن أن تبقى بلغتها الأصلية. الحقول التحريرية الاختيارية قد تستخدم قاعدة محددة، مثل إبقاء القيمة الإنجليزية عندما لا توجد عربية. أما المحتوى الذي قد يسبب تضليلًا إذا كان قديمًا أو خارج سياقه فيحتاج قاعدة أشد. المهم ليس وجود قاعدة واحدة لكل شيء، بل أن تكون النتيجة متوقعة.
وعندما يظهر محتوى إنجليزي داخل صفحة عربية، يجب ألا يفقد اتجاهه أو هويته اللغوية. إذا كانت النبذة العربية ناقصة واستُخدمت الإنجليزية بدلًا منها، ينبغي أن يظل ذلك الجزء قابلًا للقراءة من اليسار إلى اليمين عند الحاجة، مع بقاء بقية الصفحة عربية. المحتوى البديل الجيد يحافظ على قابلية الاستخدام، لا يملأ الفراغ فقط.
هناك أيضًا مشكلة القِدم. قد تكون الترجمة موجودة لكنها أقدم من النص الأصلي الذي تغيّر لاحقًا. النظام الذي يسأل فقط «هل الحقل فارغ؟» لن يكتشف ذلك. لذلك يفيد وجود حالة مراجعة أو تاريخ يوضح أن النسخة المحلية لم تعد متزامنة مع المصدر.
الهدف ليس منع اختلاط اللغات تمامًا؛ الأعمال الواقعية تحتوي أسماء وعلامات وأكوادًا ونصوصًا أدخلها المستخدم وقد يكون إبقاؤها كما هي صحيحًا. الهدف هو أن يكون كل انتقال بين اللغات قرارًا معروفًا، لا نتيجة نفاد الخيارات.
ويمكن أن تكون مصفوفة المحتوى البديل بسيطة وعملية. لكل نوع حقل، حدد مصدر الحقيقة، وهل يسمح بالبديل، وما اللغة المستخدمة عند الغياب، وهل يُخفى الحقل إذا بقي فارغًا، وهل يؤدي تغير المصدر إلى اعتبار الترجمة بحاجة إلى مراجعة. بهذه الطريقة لا تتوزع السياسة داخل عشرات القوالب. كما يصبح الاختبار واضحًا: احذف قيمة عربية عمدًا وتأكد أن النظام يعرض البديل أو الإخفاء أو التحذير المتوقع بدل التخمين.
هذه القواعد تقلل كذلك اختلاف السلوك بين المكونات؛ فالمستخدم لا ينبغي أن يتعلم في كل قسم قاعدة مختلفة لما يحدث عندما تكون الترجمة ناقصة.
تبديل اللغة يجب أن يحافظ على السياق نفسه
تغيير اللغة هو غالبًا تغيير في طريقة عرض الكيان نفسه، وليس طلبًا لبدء رحلة جديدة. إذا كان الزائر داخل ملف نشاط محدد أو خدمة أو صفحة تقييم ثم انتقل من الإنجليزية إلى العربية، فيجب أن يبقى على الشيء نفسه متى كانت له نسخة محلية. إعادته إلى الصفحة الرئيسية العامة تكسر السياق في اللحظة التي يفترض أن تصبح فيها التجربة أوضح.
وينطبق الأمر داخل الصفحة أيضًا. لا ينبغي لتبديل اللغة أن يمحو اختيار تبويب مهم، أو يغلق نافذة يحتاجها المستخدم، أو يعيد قائمة إلى بدايتها بلا سبب، أو يحذف بيانات كتبها في نموذج. بعض الحالات قد تحتاج إعادة ضبط لأن المحتوى المتاح اختلف، لكن فقدان الحالة يجب أن يكون استثناءً مبررًا، لا السلوك الافتراضي.
كذلك تحتاج أولوية اختيار اللغة إلى منطق واضح. حفظ اختيار المستخدم يفيد الزيارات اللاحقة، ولغة المتصفح قد تعطي مؤشرًا أوليًا، لكن لا يجوز لأي منهما أن يحاصر المستخدم. يجب أن يبقى مبدّل اللغة ظاهرًا، وأن يتغلب اختيار المستخدم الصريح عادةً على الاكتشاف التلقائي. شخص يعيش في الإمارات قد يستخدم جهازًا مضبوطًا بالإنجليزية لكنه يريد العربية، أو العكس.
ومن الأفضل ألا يعتمد مبدّل اللغة على أعلام الدول. العلم يشير إلى دولة، بينما اللغة قد تُستخدم في دول كثيرة. كتابة أسماء اللغات بصيغتها الأصلية مثل “English” و«العربية» أوضح في أغلب المنتجات. ويجب أن يكون عنصر التبديل نفسه مفهومًا لتقنيات المساعدة وأن يبقى في مكان متوقع بعد الانتقال.
لا يحتاج هذا المقال إلى إعادة شرح معمارية المعرّفات والمسارات التي تناولتها مقالات أخرى في السلسلة. قاعدة تجربة المستخدم هنا أبسط: أبقِ الشخص مرتبطًا بالشيء نفسه. النظام المتعدد اللغات القوي يجعل التبديل خطوة قابلة للعكس ومنخفضة المخاطر، بحيث يستطيع المستخدم تغيير طريقة العرض من دون أن يتساءل هل غادر الملف أو فقد موضعه أو دخل نسخة أخرى من النشاط.
وتزداد أهمية الحفاظ على السياق عندما يصل المستخدم من رابط عميق. قد يفتح ملفًا من رمز QR أو رسالة أو إشارة مرجعية أو نتيجة بحث، ثم يقرر تغيير اللغة بعد التأكد من الوجهة. التبديل الجيد لا يمحو خصوصية هذا الوصول. حتى لو اختلفت المسارات داخليًا بين اللغات، يجب أن يبقى المستخدم على المحتوى نفسه والإجراء المفيد نفسه، من دون أن يضطر إلى إعادة بناء الطريق الذي أوصله إلى الصفحة.
وإذا كانت بعض الحالات لا يمكن حفظها عند التبديل، يجب أن يكون ذلك واضحًا في التصميم وأن يحدث بأقل خسارة ممكنة بدل إعادة الصفحة كلها بلا ضرورة.
الأنظمة تحتاج إلى معرفة اللغة والاتجاه أيضًا
التوطين ظاهر للبشر، لكنه يُقرأ كذلك بواسطة المتصفحات، وتقنيات المساعدة، ومحركات البحث، وبرامج أخرى. قد تبدو الصفحة سليمة بصريًا لمستخدم مبصر بينما تعلن للأنظمة لغة أو اتجاهًا غير صحيحين. هذا يؤثر في النطق الآلي، وبعض خصائص العرض الحساسة للغة، وطريقة تفسير أجزاء الصفحة.
توصي إرشادات W3C بإعلان اللغة الأساسية لمستند HTML من العنصر الرئيسي، ثم تحديد اللغة محليًا عندما يظهر جزء بلغة أخرى. هذا مهم في الصفحة العربية التي قد تتضمن اسم شركة إنجليزيًا، أو اقتباسًا، أو حقلًا بديلًا مأخوذًا من الإنجليزية. وسم اللغة يعطي البرامج فرصة أفضل لنطق النص بصورة صحيحة وفهم أن ما حدث انتقال لغوي حقيقي، لا مجرد سلسلة من الأحرف اللاتينية.
أما الاتجاه فهو خاصية مختلفة. الكتلة العربية تحتاج عادةً إلى اتجاه أساسي من اليمين إلى اليسار، بينما قد يحتاج رابط أو بريد أو كود داخلها إلى معالجة اتجاه مختلفة أو عزل مناسب. ربط اللغة والاتجاه بمفتاح واحد دائمًا يخلق أخطاء، لأن النص المختلط طبيعي، ولأن اللغة والكتابة والاتجاه مفاهيم مترابطة لكنها ليست متطابقة.
ويجب أن تتبع البيانات الوصفية النسخة المحلية أيضًا. عنوان الصفحة، ووصف Meta، ونصوص المشاركة الاجتماعية، والتسميات البنيوية، والعلاقة بين النسخ اللغوية ينبغي أن تصف اللغة التي يراها المستخدم فعلًا. صفحة عربية بجسم عربي لكن عنوان إنجليزي في نتائج البحث أو المعاينة الاجتماعية ما زالت تجربة غير مكتملة.
من المفيد لذلك أن يميّز النظام بين ثلاثة أشياء: هوية الملف الأساسية، والنسخة اللغوية المطلوبة، ولغة كل جزء محتوى على حدة. قد يبقى اسم النشاط نفسه في اللغتين بينما تتغير النبذة. وقد تحتوي الصفحة العربية رابطًا إنجليزيًا عن قصد. وقد يأتي حقل بديل من لغة أخرى.
التوطين القابل للفهم آليًا يجعل هذه العلاقات صريحة، بدل أن يطلب من البرامج استنتاجها من المحاذاة أو شكل الحروف. عندما يعمل هذا جيدًا لا يلاحظه المستخدم، وهذا بالضبط دليل نجاحه.
ويجب أن يدخل هذا المستوى الآلي في الاختبار، لا أن نفترض صحته من شكل الصفحة. افحص HTML الناتج، وتأكد من لغة الصفحة واتجاهها، ومن الأجزاء التي تغيّر اللغة داخل النص، ومن أن روابط النسخ البديلة تصل فعلًا إلى المحتوى المكافئ، ومن وجود البيانات الوصفية المحلية. هذه فحوص منخفضة الكلفة مقارنة بإصلاح مشكلات الوصول أو تراجع جودة التوطين بعد النشر، كما تمنع تكرار الخطأ عند استخدام القالب نفسه في ملفات كثيرة.
كما ينبغي اختبار العناوين والبيانات الوصفية بعد النشر الفعلي، لأن بعض الأخطاء لا تظهر داخل المحرر بل تظهر في المعاينات أو أدوات المشاركة أو نتائج البحث.
النماذج والبيانات المنظمة يجب أن تناسب السوق، لا اللغة فقط
قد تبدو الصفحة متعددة اللغات ممتازة حتى اللحظة التي يبدأ فيها المستخدم بالكتابة. هنا تظهر افتراضات لا تكشفها النصوص الثابتة: كيف يتكون الاسم، وكيف يُكتب رقم الهاتف، وما الحقول المطلوبة للعنوان، وكيف يُعرض التاريخ، وأي لوحة مفاتيح متوقعة، وما الأحرف التي تسمح بها قواعد التحقق.
تنبّه إرشادات W3C حول الأسماء الشخصية إلى أن الناس حول العالم لا يستخدمون بنية واحدة للأسماء. ليس لدى الجميع تقسيم بسيط يمكن وضعه بأمان في حقلي «الاسم الأول» و«اسم العائلة»، كما يختلف ترتيب أجزاء الاسم حسب الثقافة. لذلك يجب أن يتبع نموذج البيانات الحاجة الفعلية للتطبيق. إذا كان المطلوب مجرد اسم يعرض في جهة اتصال، فقد يكون حقل اسم كامل ومرن أنسب من فرض تقسيم لا يحتاجه العمل أصلًا.
ويجب التفريق بين اللغة والسوق المحلي. اختيار «العربية» لا يحدد وحده الدولة أو مفتاح الهاتف أو العملة أو شكل العنوان أو السياق القانوني. مستخدم عربي في الإمارات ومستخدم عربي في سوق آخر قد يشتركان في لغة الواجهة ويختلفان في تفاصيل الإدخال. والشيء نفسه ينطبق على الإنجليزية؛ استخدام الإنجليزية في الإمارات لا يعني افتراض تنسيقات الولايات المتحدة.
يمكن للواجهة أن توطّن طريقة العرض مع إبقاء القيمة التقنية مستقرة في الخلفية. التاريخ مثلًا يمكن تخزينه بصيغة داخلية غير ملتبسة ثم عرضه بالشكل المناسب للسياق. حقل الهاتف يجب أن يتعامل مع المفاتيح الدولية بدل افتراض بلد واحد. وقواعد التحقق يجب ألا ترفض مسافات أو شرطات أو أحرفًا صحيحة لمجرد أنها لا تشبه المثال الذي استخدمه المطور أثناء البناء.
حتى حالات الخطأ جزء من التوطين. رسالة التحقق يجب أن تكون بلغة النموذج وتشرح المشكلة الحقيقية. أمثلة الحقول يجب أن تناسب السوق المتوقع. واتجاه المؤشر والإدخال والمحاذاة لا ينبغي أن يحارب المستخدم عندما يجمع النموذج بين العربية والأرقام أو النص اللاتيني.
وهذا يختلف عمدًا عن موضوع Article 10. السؤال هناك هو: كم من بيانات العميل نحتاج أن نجمع؟ أما السؤال هنا فهو: بعد أن نقرر أن الحقل ضروري، هل يستطيع مستخدم هذه اللغة والسوق إدخال قيمة صحيحة وطبيعية، أم أن النموذج يفرض عليه قالبًا ثقافيًا واحدًا؟
ويفيد أيضًا الفصل بين طريقة العرض وطريقة التخزين. يمكن أن يرى المستخدم التاريخ أو الرقم أو الهاتف بصيغة مألوفة في سوقه، بينما يحتفظ النظام في الخلفية بقيمة موحدة صالحة للمعالجة. هذا يمنع تحويل عادات العرض إلى قيود داخل قاعدة البيانات. كما يسهل التوسع لاحقًا، لأن إضافة سوق جديد قد تغيّر التنسيق والتحقق من دون الحاجة إلى إعادة كتابة السجلات القديمة بسبب اختلاف ترتيب الحقول أو علامات الفصل.
وتبقى الأمثلة داخل الحقول جزءًا من التجربة؛ المثال الجيد يساعد المستخدم على فهم الصيغة، بينما المثال المستورد من سوق آخر قد يخلق خطأً حتى لو كانت التسمية مترجمة.
النص البديل AR
نموذج موطن يتكيف في الاسم والهاتف والتاريخ والاتجاه وقواعد التحقق حسب السوق
إرشاد الصورة
اختبار اللغات مرحلة إطلاق كاملة، لا تدقيق لغوي أخير
كثير من أخطاء التوطين تظهر بعد اعتماد الترجمة. عنوان عربي طويل يضغط على زر. رابط إنجليزي يقلب ترتيب جزء من جملة عربية. حقل ناقص يشغّل قاعدة بديلة خاطئة. مبدّل اللغة يعمل من الصفحة الرئيسية لكنه يفقد السياق داخل ملف. رسالة خطأ مترجمة تتجاوز حدود الشاشة على هاتف صغير. هذه عيوب منتج، وليست أخطاء إملائية.
لذلك يفيد بناء مصفوفة اختبار تجمع اللغة وعرض الشاشة وحالة المحتوى وحالة التفاعل. اختبر العربية والإنجليزية على أصغر عرض موبايل مدعوم، وعلى المقاسات الشائعة، والتابلت، وسطح المكتب. اختبر أسماء قصيرة وطويلة، وحقولًا اختيارية فارغة، وعناوين خدمات طويلة، ونصوصًا عربية إنجليزية مختلطة، وروابط، وبريدًا إلكترونيًا، وأرقام هاتف، وأسعارًا، وتواريخ، ونسبًا، وعلامات ترقيم. اختبر الصفحة قبل تبديل اللغة وبعده، واختبر النماذج بإدخال عربي ولاتيني.
المراجعة البشرية من شخص يتقن اللغة ضرورية، لكنها ليست بوابة الجودة الوحيدة. المراجع اللغوي يعرف إن كانت العربية طبيعية وإن كان ترتيب المعلومات منطقيًا لقارئ عربي. أما الفحوص الآلية فيمكنها كشف مفاتيح غير مترجمة، ووسوم لغة ناقصة، وكتل اتجاهها غير متوقع، وروابط لغوية مكسورة، وتجاوز النص لمساحته. المقارنة البصرية تكشف انحراف التخطيط. ولا يلغي أي نوع من الاختبارات النوع الآخر.
كما يحتاج المحتوى إلى مالك واضح. إذا لم يكن هناك من يتحمل مسؤولية حداثة النسخ، تبدأ اللغات بالتباعد مع الوقت. العملية الجيدة تحدد من يعدل الحقائق المشتركة، ومن يراجع الصياغة المحلية، وأي تغيير يجعل الترجمة الحالية بحاجة إلى مراجعة، وما شروط اعتبار كل لغة جاهزة للنشر.
ومعيار القبول ليس أن تكون لقطتا الشاشة متطابقتين. المطلوب تجربة متكافئة: يستطيع مستخدم كل لغة معرفة صاحب الملف، وفهم العرض، والتنقل، وتنفيذ الإجراء، وإدخال البيانات الصحيحة، وفهم الخطأ من دون احتكاك إضافي سببه اللغة. قد يختلف التخطيط قليلًا حتى يصل الطرفان إلى النتيجة نفسها.
بهذا تصبح اللغة الثانية عرضًا أصيلًا للمنتج نفسه، لا صفحة مكررة أضيفت في نهاية المشروع. لها متطلبات لغوية وواجهية خاصة، لكنها تحمل الحقيقة الأساسية نفسها وتخضع لمعيار جودة كامل.
وأخيرًا يجب أن يشمل الاختبار عمليات التحرير بعد الإطلاق. أضف خدمة جديدة، وعدل اسم النشاط، وأنهِ عرضًا مؤقتًا، واحذف حقلًا عربيًا اختياريًا، وغيّر حقيقة مشتركة، ثم راقب اللغتين. كثير من الأنظمة تنجح يوم الإطلاق ثم تبدأ بالتعطل مع التعديلات اليومية لأن مسار التحديث لم يُختبر. المعيار الحقيقي ليس أن تبدو النسخة الأولى صحيحة، بل أن تستطيع التغييرات العادية الحفاظ على كل لغة من دون إصلاح يدوي في كل مرة.
بهذا يصبح اختبار اللغات جزءًا من دورة المنتج المستمرة: تصميم، وتحرير، ونشر، وتعديل، ثم تحقق جديد كلما تغيرت المكونات أو المحتوى المشترك.
المصادر
- A Practical Guide to Localization — Bert Esselink — John Benjamins Publishing Company
- Structural markup and right-to-left text in HTML — W3C Internationalization
- Declaring language in HTML — W3C Internationalization
- Unicode Standard Annex #9: Unicode Bidirectional Algorithm — Unicode Consortium
- Personal names around the world — W3C Internationalization — Richard Ishida
