البحث هو المكان الذي تخسر فيه المنصات الثنائية اللغة قراءها بصمت.
المشكلة ليست في السرعة غالبًا. أدوات مثل Pagefind سريعة بما يكفي لأي منصة تحريرية حديثة. الخلل الحقيقي يظهر في طبقة المعنى: القارئ لا يبحث دائمًا بنفس الكلمات التي وضعناها نحن في العنوان. ويصبح هذا أوضح عندما يعمل الموقع بالإنجليزية والعربية معًا، حيث قد يتذكر المستخدم الفكرة نفسها لكن لا يتذكر الصياغة الحرفية.
لماذا يتعثر البحث الحرفي في المواقع الثنائية
البحث بالكلمات المفتاحية ممتاز حين تتطابق صياغة الاستعلام مع كلمات العنوان أو المتن. لكنه يضعف عندما يتذكر القارئ النية بدل العبارة نفسها:
- “صلاحيات MCP” بدل “حدود الأدوات”
- “البحث العربي” بدل “الاسترجاع متعدد اللغات”
- “سير ترجمة محلي” بدل “خط إنتاج مسودات ثنائية اللغة”
وفي الموقع الثنائي اللغة تظهر مشكلة إضافية: نية البحث قد تعبر الحدود اللغوية. فقد يبحث قارئ عربي بكلمة إنجليزية رآها على منصة اجتماعية، بينما يبحث قارئ إنجليزي باسم منتج ويريد رغم ذلك أن تظهر له أفضل تغطية عربية مرتبطة بالموضوع.
الطبقة الأولى: Pagefind يجب أن تبقى الأساس التشغيلي
ما زلت أرى أن Pagefind يجب أن تكون الإجابة الأولى في أغلب الحالات. هي أداة ثابتة، سهلة النقل، وسريعة جدًا في بيئات النشر التحريري. كما أنها تمنحك نمط فشل محترمًا: حتى لو توقفت أي طبقة ذكية إضافية، يبقى البحث الأساسي يعمل بشكل نظيف.
العقلية الصحيحة هنا بسيطة:
- Pagefind تعالج العناوين الدقيقة والمطابقات النصية القوية والنتائج الفورية.
- الطبقة الدلالية تساعد حين تختلف الصياغة أو عندما تعبّر الإنجليزية والعربية عن الفكرة نفسها بعبارات مختلفة.
- الاختيار التحريري يبقى مسؤولًا عن إبراز المحتوى على الصفحة الرئيسية وأقسام الموقع.
هكذا تبقى المنظومة مفهومة وقابلة للتحكم.
الطبقة الثانية: استخدم Embeddings لتحسين الاستدعاء لا لاختراع الصلة
هنا تظهر قيمة Multilingual Embeddings. بدل الاعتماد على تشابه الكلمات حرفيًا، تحول السؤال والمقال إلى متجهات ثم ترتب النتائج حسب القرب الدلالي. الهدف ليس إظهار البحث وكأنه سحر. الهدف هو التقاط المواد القوية التي يفوتها البحث النصي.
أفضل الاستخدامات العملية لهذه الطبقة هي:
- إظهار المقالات العربية والإنجليزية لنفس الموضوع
- إنقاذ عمليات البحث التي لا تطابق مفردات العنوان مباشرة
- تشغيل قسم “مواد مرتبطة” بدقة أعلى
- اكتشاف الفجوات بين التغطية العربية والإنجليزية
أما الاستخدام الخاطئ فهو تحويل كل الترتيب إلى صندوق أسود. البحث الدلالي ينجح حين يكون إضافة ذكية فوق taxonomy منضبط واختيارات تحريرية واضحة، لا بديلًا عنها.
معمارية نظيفة وقابلة للإدارة
بالنسبة للفِرق التحريرية، النمط الأنظف هو فهرسة وقت البناء مع طبقة دلالية اختيارية:
مقتطف شيفرة
ts
type SearchDocument = {
id: string;
locale: "en" | "ar";
url: string;
title: string;
description: string;
category: "devhub" | "security" | "reviews";
tags: string[];
body: string;
};
export async function buildSearchArtifacts(docs: SearchDocument[]) {
const pagefindIndex = await buildPagefindIndex(docs);
const semanticIndex = await buildEmbeddingIndex(docs, {
model: "ibm-granite/granite-embedding-278m-multilingual",
});
return {
pagefindIndex,
semanticIndex,
};
}
هذه المعمارية تجعل المسار السريع واضحًا: Pagefind أولًا، والطبقة الدلالية كخدمة مرافقة وليست شرطًا لكل طلب.
جودة العربية أهم من اختيار الموديل وحده
كثير من الفرق تنشغل بالمقارنات بين الموديلات وتنسى الأشياء التي تكسر التجربة العربية فعلًا:
- استراتيجية Slugs غير منضبطة
- وسوم ضعيفة أو عشوائية
- وصف إنجليزي فقط في الصفحات العربية
- Typography تجعل العربية أخف بصريًا من الإنجليزية
إذا كانت هذه الأساسيات مكسورة فلن ينقذك موديل أقوى. الاسترجاع متعدد اللغات ليس مسألة موديل فقط، بل مسألة بنية تحريرية كاملة.
خطة الإطلاق الموصى بها في 2026
لو كنت أبني منصة ثنائية اللغة من الصفر فسأطلق البحث على أربع مراحل:
- Pagefind فقط مع عناوين ووصف ووسوم منضبطة.
- محتوى مرتبط مبني على taxonomy لكل مقال.
- Embeddings متعددة اللغات لتحسين الاستدعاء والاكتشاف عبر اللغتين.
- طبقة تحليل تحريري تكشف ما الذي بحث عنه القراء ولم يجدوه.
هذا الترتيب مهم لأنه يحمي الأداء، ويُبقي النظام مفهومًا للمحررين، ويمنع الفريق من القفز إلى الذكاء الدلالي قبل ترتيب الأساس التحريري.
أفضل بنية بحث ثنائية في 2026 ليست الأكثر تعقيدًا، بل الأكثر اتزانًا: سريعة تحت الضغط، واضحة للمحرر، وتحترم الطريقة التي يتحرك بها القارئ فعلًا بين الإنجليزية والعربية وهو يبحث عن إجابة تقنية دقيقة.