---
title: لماذا يجب أن يكون المحتوى متعدد اللغات في git
description: >-
  تؤدي قواعد بيانات أنظمة إدارة المحتوى المستضافة ومنصات الترجمة إلى تشتت
  المحتوى بين ثلاثة مصادر مختلفة. حفظ ملفات MDX الإنجليزية والترجمات وسجل
  التعديلات في مستودع واحد يحل هذه المشكلة جذريا. إليك النموذج الذي تعتمد عليه
  Scribe.
publishedAt: '2026-07-08'
updatedAt: '2026-07-08'
noindex: false
canonicalPath: /ar/blog/why-multilingual-content-belongs-in-git
---
تنتهي أغلب المواقع متعددة اللغات بامتلاك ثلاثة مصادر للحقيقة: المحتوى في نظام إدارة محتوى مستضاف، والترجمات في منصة للترجمة، والكود البرمجي في git. كل مصدر من هذه المصادر يمتلك نظاما خاصا لإدارة الإصدارات، وصلاحيات وصول مستقلة، ومفهوما مختلفا لما يعنيه الإصدار «الحالي». لذا تصبح محاولة الحفاظ على تزامنها مهمة شاقة، ويصبح التشتت والتعارض هو الوضع الافتراضي.

هناك نموذج أبسط بكثير: ضع كل شيء في المستودع.

## ما ينجح git في حله مسبقا

تتعامل آلية عمل الكود البرمجي لديك بالفعل مع أعقد مشاكل إدارة المحتوى:

- **المراجعة.** أي تغيير في المحتوى هو عبارة عن pull request. وهناك دائما من يراجع الفروقات قبل اعتمادها.
- **التراجع.** إصلاح أي تعديل خاطئ يتم عبر أمر revert، وليس عبر فتح تذكرة دعم فني.
- **الترابط الوثيق.** يتم نشر المحتوى والكود الذي يعرضه معا في نفس الوقت. هكذا يمكن إدراج أي تغيير في الهيكلية وما يرافقه من نقل للمحتوى في commit واحد.
- **سجل التعديلات.** يجيب أمر `git log` على سؤال «من قام بتغيير هذا ومتى؟» دون الحاجة لأي إضافات برمجية.

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

## معضلة الترجمة

يتمثل النهج البدائي في تخصيص ملف لكل لغة (مثل `about.en.mdx` و `about.fr.mdx` و `about.ja.mdx`). لكن هذا النهج سرعان ما ينهار؛ فعشر لغات ستحول موقعا من 50 صفحة إلى 500 ملف، وتصبح مراجعة اللغات التي لا يتقنها أحد في الفريق أمرا مستحيلا، ولا توجد أي طريقة لمعرفة ما إذا كان ملف `about.fr.mdx` يعكس النص الإنجليزي الحالي أم النسخة القديمة من قبل ثلاثة أشهر.

تقوم [Scribe](/docs/getting-started) بفصل هاتين المسألتين:

- **المحتوى الإنجليزي عبارة عن ملفات MDX.** ملف واحد لكل مستند، يتم التحقق من صحته باستخدام مخطط Zod. هذا هو الجزء الذي يكتبه ويراجعه البشر.
- **تُحفظ الترجمات في ملف SQLite واحد يودع بجانبها.** ترتبط كل ترجمة برمز تعمية (hash) يمثل مصدرها الإنجليزي، إلى جانب لقطة توضح كيف كان يبدو هذا المصدر وقتها.

رمز التعمية هذا هو ما يقضي على مشكلة التشتت. فإذا قمت بتعديل فقرة واحدة باللغة الإنجليزية، سيصبح مستند واحد فقط قديما بشكل واضح في كل اللغات. وعند تشغيل أمر [`scribe translate`](/docs/translation)، ستتم إعادة ترجمة هذا المستند تحديدا. لن يتخلف أي شيء عن الركب بصمت، ويُظهر أمر `scribe status` مستوى التغطية الدقيق عند أي commit.

## لا حاجة لخوادم بفضل التصميم

نظرا لأن كل شيء عبارة عن ملفات داخل المستودع، فلا يوجد شيء يحتاج إلى استضافة. يقرأ وقت التشغيل ملفات MDX و SQLite من القرص أثناء عملية البناء (build time)، ويزود إطار العمل الخاص بك بمستندات مكتملة الأنواع (fully typed): قوائم، وبحث، وعلاقات، وبدائل hreflang، وإدخالات خريطة الموقع. لا توجد واجهة برمجة تطبيقات (API) لنظام إدارة المحتوى تحتاج لاستدعائها عند الطلب، ولا رموز مصادقة (tokens) تتطلب التجديد، ولا توجد أعطال محتملة من مزودي الخدمة قد تتسبب في إيقاف محتواك. راجع [runtime API](/docs/runtime-api) لمعرفة كيفية عمل عمليات القراءة.

## الملفات هي البيئة المثالية لعمل وكلاء الذكاء الاصطناعي

هناك حجة أحدث لدعم هذا النموذج، وربما تكون الأقوى: وكلاء الذكاء الاصطناعي (AI agents) يتعاملون ببراعة مع المستودعات. فوكيل كتابة الأكواد يعرف مسبقا كيفية البحث في الملفات، وقراءة ملفات MDX كنص عادي، وتعديلها في فرع مستقل (branch)، ثم فتح pull request. أما إذا وجهته نحو نظام إدارة محتوى مستضاف، فستجد نفسك تبرمج واجهات برمجة تطبيقات، وتدير رموز مصادقة، وتبني عمليات دمج مخصصة قبل أن يتمكن الوكيل حتى من تغيير عنوان رئيسي.

تنتقل آليات الحماية أيضا بسلاسة. يتم التحقق من صحة Frontmatter مقابل مخطط Zod الخاص بك، ويجب أن يكون كل نص قابلا للترجمة البرمجية كـ MDX، لذا لا يمكن للوكيل حفظ مستند مشوه؛ وسيلتقط أمر [`scribe validate`](/docs/cli) هذا الخطأ قبل عملية البناء. وبما أن كل تعديل هو commit، فإن تغييرات الذكاء الاصطناعي تعامل تماما كالتغييرات البشرية (مراجعة الفروقات، ثم التقييم، ثم الاعتماد). هذا الموقع يعمل بهذه الطريقة بالضبط؛ إذ يقوم وكلاء الذكاء الاصطناعي بمعظم أعمال صيانة المستندات وسجل التغييرات، بينما يراجع البشر الفروقات.

## متى لا يكون هذا النموذج مناسبا لك

فقرة الصراحة. يفترض نظام إدارة المحتوى المعتمد على git أن الأشخاص الذين يحررون المحتوى مرتاحون للتعامل مع الملفات و pull requests، أو أن هناك شخصا تقنيا يتوسط بينهم وبين المستودع. إذا كان المحررون لديك يحتاجون إلى واجهة تحرير مرئية (WYSIWYG) وزر نشر مباشر، فإن نظام إدارة المحتوى المستضاف هو الخيار الأنسب. توفر Scribe [studio](/docs/studio) محليا لتصفح الترجمات والبحث فيها وفحصها، لكن عملية الكتابة نفسها تتم داخل محرر الأكواد الخاص بك.

أما إذا كان فريقك يعتمد كليا على git بالفعل، فإن إضافة نظام ثان وثالث للمحتوى والترجمات سيزيد فقط من مساحة التشتت. مستودع واحد، مسار مراجعة واحد، وعملية نشر واحدة.

## جرب بنفسك

الإعداد بالكامل لا يتطلب سوى ملف تكوين واحد ومجلد لملفات MDX:

```bash
pnpm add scribe-cms zod better-sqlite3
```

ابدأ مع [getting started guide](/docs/getting-started)، أو اقرأ كيف تعمل [translation](/docs/translation) من الداخل.