تصميم منصة ويب متعددة اللغات: من قاعدة البيانات إلى المتصفح

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

الخطأ الشائع هو التعامل مع الترجمة كخطوة أخيرة: يُبنى الموقع بلغة واحدة ثم تُضاف اللغات الأخرى لاحقًا. وعندها تكون بنية قاعدة البيانات والروابط والمكوّنات كلها قد افترضت لغة واحدة، ويجب تفكيك كل افتراض على حدة. يشرح هذا المقال كيف تصمّم لعدة لغات منذ البداية عبر طبقات تطبيق من نمط MERN، وما الذي يجب التحقق منه قبل التعهد لعميل ببناء موقع متعدد اللغات.

لماذا تصبح «الترجمة لاحقًا» مكلفة؟

الموقع أحادي اللغة يقوم بافتراضات كثيرة صامتة. العنوان نص واحد. الزر يقع على اليمين لأن هناك مكان «التالي». والرابط لا يحمل أي لغة. وإضافة لغة أخرى تكسر الافتراضات الثلاثة جميعًا.

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

الطبقة الأولى: نموذج البيانات

في MongoDB مع Mongoose، أنظف أسلوب هو جعل كل حقل قابل للترجمة كائنًا يحمل جميع النسخ. المفاتيح أدناه أسماء مؤقتة؛ أما في مشروع حقيقي فتُستخدم رموز اللغات القياسية (locale codes).

// Reusable sub-schema
const translated = {
  primary:   { type: String, default: "" },
  secondary: { type: String, default: "" },
};

const ServiceSchema = new Schema({
  title: translated,
  summary: translated,
  slug: { type: String, required: true, unique: true },
  isPublished: { type: Boolean, default: false },
});

بذلك يحتوي المستند على العنوان مرة واحدة، مع إدخال واحد لكل لغة. ولهذا ثلاث مزايا:

• سجل واحد لكل صفحة. الأسعار والصور وحالة النشر والترتيب تُخزَّن مرة واحدة.
• شكل متوقَّع. الواجهة الأمامية تطلب دائمًا title[locale].
• سهولة التوسّع. إضافة لغة جديدة تعني إضافة مفتاح، ولا تعني ترحيل مجموعات البيانات.

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

الطبقة الثانية: لوحة الإدارة

لا ينجح النموذج إلا إذا استطاع المحررون تعبئته بلا عناء. في لوحة إدارة محتوى مبنية بـ React، اعرض حقول كل لغة جنبًا إلى جنب أو في تبويبات، واضبط اتجاه النص الصحيح على كل حقل ليرى المحرر ما سيراه القارئ. ومؤشر الاكتمال (مثل «تمت ترجمة 6 من 8 حقول») يوفّر كثيرًا من التواصل المتكرر، لأنه يُظهر ما لم يكتمل قبل نشر الصفحة.

الطبقة الثالثة: التوجيه (Routing) في Next.js

أبقِ اللغة في الرابط. وتصف وثائق Next.js ذلك لنظام App Router. ضع مساراتك داخل app/[lang]، واستخدم ملف وسيط (proxy) (كان يسمى middleware في Next.js 15 وما قبله) لإعادة توجيه الزوار إلى مسار يبدأ برمز اللغة. وفي التخطيط (layout) اضبط السمتين معًا على العنصر الجذر:

export default async function RootLayout({ children, params }) {
  const { lang } = await params;

  return (
    <html lang={lang} dir={isRtl(lang) ? "rtl" : "ltr"}>
      <body>{children}</body>
    </html>
  );
}

والروابط مهمة لمحركات البحث أيضًا. يجب أن يكون لكل نسخة لغوية عنوانها الخاص، وأن تشير الصفحات إلى بعضها بوسوم hreflang البديلة، حتى تعرض محركات البحث النسخة الصحيحة للمستخدم الصحيح. ويمكنك في Next.js التصريح بذلك داخل generateMetadata باستخدام alternates.languages. وأضف إدخال x-default للزوار الذين لا تتعرف على لغتهم.

تنبيه واحد: إذا كان موقعك يحتوي أيضًا على بادئات إقليمية، فابنِ الروابط عبر دالة مساعدة واحدة. كتابة المسارات يدويًا داخل المكوّنات هي السبب في وصول المستخدمين إلى لغة خاطئة بعد النقر على رابط.

الطبقة الرابعة: اتجاه التخطيط

بعض اللغات تُقرأ من اليمين إلى اليسار. ضبط dir="rtl" يعكس اتجاه النص، لكن CSS قد يلغي هذا الانعكاس. فالقيم المكتوبة صراحةً مثل margin-left وpadding-right وtext-align: left تبقى في مكانها عند قلب الصفحة.

استخدم بدلًا منها خصائص CSS المنطقية:

وهناك أمور تحتاج إلى اهتمام يدوي على أي حال:

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

اعتبارات عملية

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

لا تترجم آليًا ثم تنشر. المسودة الآلية نقطة بداية معقولة. لكن يجب أن يراجع شخص يتقن اللغة كل ما سيقرؤه العميل، وخاصة النصوص القانونية ونداءات اتخاذ الإجراء (Calls to action).

خصّص ميزانية للاختبار في كل الاتجاهات. لكل مكوّن جديد أكثر من تخطيط واحد. ومراجعة النسخة الافتراضية فقط هي الطريق الذي تصل به الأخطاء المتراجعة (Regressions) إلى بيئة الإنتاج.

تحقق من محتوى الصور. اللافتات التي يكون النص مدمجًا داخل صورتها لا يمكن ترجمتها. إما أن تُبقي النص خارج الصور أو تخزّن صورة منفصلة لكل لغة.

قائمة تحقق قبل البدء

• اتفق على قائمة اللغات المدعومة واللغة الافتراضية.
• اختر شكل بيانات واحدًا للحقول المترجمة واستخدمه في كل مكان.
• ضع اللغة في الرابط وأضف بدائل hreflang.
• اكتب أنماط التخطيط بالخصائص المنطقية منذ المكوّن الأول.
• حدّد قاعدة الترجمة المفقودة ومن يتولى مراجعة الترجمة.

الخلاصة

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