27 يونيو 2025·8 دقيقة
كيفية بناء تطبيق ويب لإدارة التوطين والترجمات
صِف تطبيق ويب لإدارة التوطين يدير سير الترجمة، بيانات اللغات، المراجعات، فحوص QA، والإصدارات — يشمل نموذج البيانات، UX، والتكاملات.
صِف تطبيق ويب لإدارة التوطين يدير سير الترجمة، بيانات اللغات، المراجعات، فحوص QA، والإصدارات — يشمل نموذج البيانات، UX، والتكاملات.
إدارة التوطين هي العمل اليومي لجعل نصوص المنتج (وأحيانًا الصور والتواريخ والعملات وقواعد التنسيق) مترجمة ومراجعة ومعتمدة ومُطلقة — من دون كسر البناء أو إرباك المستخدمين.
بالنسبة لفريق المنتج، الهدف ليس "ترجمة كل شيء"، بل الحفاظ على دقة وموثوقية وتحديث كل إصدار لغوي مع تغيّر المنتج.
معظم الفرق تبدأ بنوايا حسنة وتنتهي بفوضى:
تطبيق إدارة التوطين المفيد يدعم أدوارًا متعددة:
ستبني MVP يركّز السلاسل، يتتبع الحالة لكل لغة، ويدعم المراجعة والتصدير الأساسيين. نظام أكمل يضيف الأتمتة (مزامنة، فحوص QA)، سياقًا أغنى، وأدوات مثل المعجم وذاكرة الترجمة.
قبل تصميم الجداول أو الشاشات، قرّر مسؤوليات تطبيق إدارة التوطين. نطاق محكم يجعل النسخة الأولى قابلة للاستخدام — ويمنع إعادة البناء لاحقًا.
الترجمات نادرًا ما تعيش في مكان واحد. اكتب ما تحتاج لدعمه من اليوم الأول:
تساعدك هذه القائمة على تجنّب نهج "سير عمل واحد يناسب الجميع". مثلاً، قد تحتاج النسخ التسويقية لموافقات متعددة، بينما تحتاج سلاسل الواجهة لتكرار سريع.
اختر 1–2 صيغة للـMVP، ثم وسّع. الخيارات الشائعة تشمل JSON، YAML، PO، وCSV. اختيار عملي للـMVP هو JSON أو YAML (لسلاسل التطبيق)، مع CSV فقط إذا كنت تعتمد على استيراد جداول البيانات.
كن صريحًا بشأن متطلبات مثل أشكال الجمع (plurals)، المفاتيح المتداخلة، والتعليقات. هذه التفاصيل تؤثر على إدارة ملفات اللغات وموثوقية الاستيراد/التصدير لاحقًا.
عرّف لغة مرجعية (غالبًا en) وضع سلوك الارتداد:
pt-BR → pt → en)أيضًا قرّر ما معنى "مكتمل" لكل لغة: 100% مترجم، مُراجع، أم مُطلق.
للـMVP، ركّز على عملية مراجعة الترجمة وسير عمل i18n الأساسي: إنشاء/تحرير السلاسل، تعيين العمل، المراجعة، والتصدير.
خطط لإضافات لاحقة — لقطات شاشة/سياق، معجم، أساسيات TM، ودمج الترجمة الآلية — لكن لا تبنِها حتى تتحقق من سير العمل الأساسي بمحتوى حقيقي.
نجاح تطبيق الترجمة يعتمد على نموذج البيانات. إذا كانت الكيانات والحقول واضحة، يصبح كل شيء آخر — الواجهة، سير العمل، التكاملات — أبسط.
يمكن لمعظم الفرق تغطية 80% من احتياجاتها بمجموعة صغيرة من الجداول/المجموعات:
en, en-GB, pt-BR).checkout.pay_button).نمذج العلاقات صراحة: Project له العديد من Locales؛ Key ينتمي إلى Project؛ Translation ينتمي إلى Key وLocale.
أضف حالة لكل ترجمة لتوجّه البشر:
draft → in_review → approvedblocked للسلاسل التي لا يجب شحنها بعد (مراجعة قانونية، سياق مفقود، إلخ)وحافظ على تغيّرات الحالة كأحداث (أو جدول تاريخ) لتتمكن من الإجابة لاحقًا "من الذي وافق ومتى؟".
الترجمات تحتاج أكثر من نص خام. سجّل:
{name}, %d) وهل يجب أن تطابق المصدرعلى الأقل، احتفظ بـ: created_by, updated_by, الطوابع الزمنية، وchange_reason قصيرة. هذا يُسرّع المراجعات ويبني ثقة عندما تقارن الفرق ما في التطبيق بما شُحن.
قرارات التخزين تُشكّل كل شيء: تجربة التحرير، سرعة الاستيراد/التصدير، الفروق، ومدى ثقتك بالطرح.
صف لكل مفتاح (صف قاعدة بيانات لكل مفتاح لكل لغة) ممتاز للواجهات ولوحات المعلومات وسير العمل. يمكنك بسهولة فلترة "مفقود بالفرنسية" أو "بحاجة للمراجعة" وتعيين أصحاب. العيب: إعادة تجميع ملف لغة للتصدير تتطلب تجميعًا وترتيبًا، وستحتاج حقولًا إضافية لمسارات الملفات والمساحات الاسمية.
مستند لكل ملف (تخزين كل ملف لغة كمستند JSON/YAML) يتوافق مع طريقة عمل المستودعات. التصدير أسرع ويحافظ على التنسيق. لكن البحث والفلترة أصعب ما لم تحتفظ أيضًا بفهرس للمفاتيح والحالات والبيانات الوصفية.
العديد من الفرق تستخدم نهجًا هجينًا: تخزين صفّي كمصدر للحقيقة، بالإضافة إلى لقطات ملف مُولّدة للتصدير.
احتفظ بتاريخ المراجعات على مستوى وحدة الترجمة (مفتاح + لغة). كل تغيير يجب أن يسجل: القيمة السابقة، القيمة الجديدة، المؤلف، الطابع الزمني، وتعليق. هذا يجعل المراجعات والتراجع سهلة.
بالمقارنة، تتبّع لقطات الإصدار: "ما الذي شُحِن بالضبط في v1.8". اللقطة يمكن أن تكون وسمًا يشير إلى مجموعة متسقة من المراجعات المعتمدة عبر اللغات. هذا يمنع التعديلات المتأخرة من تغيير بناء مُطلق بصمت.
لا تعامل "الجمع" كقيمة منطقية واحدة. استخدم ICU MessageFormat أو فئات CLDR (مثل one, few, many, other) حتى لا تُجبر لغات مثل البولندية أو العربية على قواعد إنجليزية.
بالنسبة للجنس والاختلافات الأخرى، نمذجها كفَرَعات من نفس المفتاح (أو الرسالة) بدلًا من مفاتيح منفصلة عشوائية، حتى يرى المترجمون السياق الكامل.
نفّذ بحثًا نصيًا كاملاً على المفتاح، النص المصدر، الترجمة، وملاحظات المطور. أزواجه بفلترات تعكس العمل الحقيقي: الحالة (جديد/مترجم/مراجع)، الوسوم، الملف/المساحة الاسمية، ومفقود/فارغ.
فهرس هذه الحقول مبكرًا—البحث هو الميزة التي سيستخدمها الناس مئات المرات يوميًا.
عادةً ما يبدأ تطبيق إدارة التوطين بسيطًا—رفع ملف، تحرير سلاسل، تنزيله مرة أخرى. يتعقّد عندما تضيف منتجات متعددة، لغات كثيرة، إصدارات متكررة، وتدفق أتمتة مستمر (مزامنة، QA، ترجمة آلية، مراجعات).
أسهل طريقة للبقاء مرنًا هي فصل المهام منذ البداية.
إعداد شائع وقابل للتوسع هو API + واجهة ويب + مهام خلفية + قاعدة بيانات:
يفيد هذا التقسيم في إضافة عمال أكثر للمهام الثقيلة دون إعادة كتابة التطبيق ككل.
إذا أردت سرعة في النسخة الأولى العاملة، منصات توليد التطبيقات مثل Koder.ai قد تساعدك على إنشاء واجهة React، API بـGo، ومخطط PostgreSQL من مواصفات منظمة، ثم تصدّر الكود عندما تكون جاهزًا لامتلاك المستودع والنشر.
اجعل الـAPI مركزًا على موارد أساسية قليلة:
checkout.button.pay).صمم نقاط النهاية لدعم التحرير البشري والأتمتة. على سبيل المثال، قائمة المفاتيح يجب أن تقبل فلترات مثل "مفقود في لغة"، "تغير منذ"، أو "بحاجة للمراجعة".
عامل الأتمتة كعمل غير متزامن. قائمة الانتظار عادةً تتعامل مع:
اجعل الوظائف idempotent (آمنة لإعادة المحاولة) وسجّل سجلات الوظائف لكل مشروع حتى تستطيع الفرق تشخيص الفشل بنفسها.
حتى الفرق الصغيرة قد تنشئ مجموعات بيانات كبيرة. أضف ترقيم صفحات للقوائم (المفاتيح، التاريخ، الوظائف)، وخزّن قراءات شائعة (إحصائيات لغة المشروع)، وطبّق حدود معدل لحماية نقاط استيراد/تصدير وTokens عامة.
هذه تفاصيل مملة لكنها تمنع بطء النظام عندما ينمو الاعتماد.
إذا كان تطبيقك يخزّن سلاسل المصدر وتاريخ الترجمة، التحكم في الوصول ليس اختياريًا—إنه كيف تمنع التعديلات العرضية وتحافظ على قرارات قابلة للتتبّع.
مجموعة بسيطة من الأدوار تغطي معظم الفرق:
عامل كل إجراء كصلاحية حتى تتمكن من التطور لاحقًا. قواعد شائعة:
هذا يتوافق مع نظام إدارة الترجمات ويبقى مرنًا للمتعاقدين.
إذا كانت شركتك تستخدم Google Workspace أو Azure AD أو Okta، يقلل تسجيل الدخول الموحد (SSO) مخاطر كلمات المرور ويجعل إلغاء الوصول فوريًا. البريد الإلكتروني/كلمة المرور قد يعمل للفرق الصغيرة—لكن اشترط كلمات قوية وتدفقات إعادة تعيين.
استخدم جلسات قصيرة الأجل وآمنة (كوكيز HTTP-only)، حماية CSRF، حدود معدل، و2FA حيثما أمكن.
سجّل من غيّر ماذا ومتى: التعديلات، الموافقات، تغييرات اللغات، التصديرات، وتحديثات الصلاحيات. اقترن السجل بخيار "تراجع" عبر تاريخ الإصدارات حتى يكون التراجع آمنًا وسريعًا (انظر /blog/plan-storage-and-versioning).
الواجهة هي المكان الذي يتم فيه العمل الفعلي على التوطين، لذا أعطِ الأولوية للشاشات التي تقلّل التبادلات وتجعل الحالة واضحة بنظرة واحدة.
ابدأ بلوحة تحكم تجيب عن ثلاثة أسئلة بسرعة: ما المكتمل، ما المفقود، وما المحظور.
أظهر التقدّم بحسب اللغة (النسبة المترجمة، النسبة المراجعة)، مع عداد واضح "للسلاسل المفقودة". أضف عنصر قائمة مراجعة للمهام التي تنتظر الموافقة، وتغذية "التغييرات الأخيرة" حتى يلاحظ المراجعون التعديلات الخطرة.
الفلترات أهم من الرسوم: اللغة، مجال المنتج، الحالة، المعين، و"تغير منذ آخر إصدار".
محرر جيد يكون جنبًا إلى جنب: المصدر على اليسار، الهدف على اليمين، مع عرض السياق دائمًا.
يمكن أن يتضمن السياق المفتاح، نص لقطة الشاشة (إذا وُجد)، حدود الحروف، والعناصر النائبة (مثل {name}, %d). أدرج التاريخ والملاحظات في نفس العرض حتى لا يحتاج المترجمون لشاشة مناقشة منفصلة.
اجعل سير الحالة نقرة واحدة: Draft → In review → Approved.
العمل على التوطين غالبًا "العديد من التعديلات الصغيرة". أضف اختيارًا جماعيًا بإجراءات مثل تعيين لمستخدم/فريق، تغيير الحالة، واستيراد/تصدير للغة أو وحدة.
قيد الإجراءات الجماعية بحسب الصلاحيات (انظر /blog/roles-permissions-for-translators إذا غطّيت ذلك في مكان آخر).
يقضي المترجمون المحترفون ساعات في المحرر. قدّم تنقلاً كاملًا عبر لوحة المفاتيح، حالات تركيز مرئية، واختصارات مثل:
أيضًا ادعم قارئات الشاشة ووضع التباين العالي — فالإتاحة تُحسّن السرعة للجميع.
نجاح تطبيق التوطين يعتمد على سير العمل. إذا لم يستطع الناس معرفة ما يترجم بعده، أو من يملك القرار، أو لماذا سلسلة محجوزة، ستشهد تأخيرات وجودة متقلبة.
ابدأ بوحدة عمل واضحة: مجموعة مفاتيح لِلغة في إصدار محدد. دع مدراء المشاريع أو القادة يعينون العمل بحسب اللغة، الملف/الوحدة، والأولوية، مع تاريخ مستهدف اختياري.
اجعل التعيينات مرئية في صندوق "عملي" الذي يجيب عن ثلاثة أسئلة: ما المعين لي، ما المتأخر، وما ينتظر الآخرين. للفرق الكبيرة، أضف إشارات حمل العمل (عدد العناصر، تقدير عدد الكلمات، آخر نشاط) حتى تكون التعيينات عادلة.
انبني تدفق حالة بسيط، مثلاً: غير مترجم → قيد العمل → جاهز للمراجعة → معتمد.
يجب أن تكون المراجعة أكثر من تحقق ثنائي. ادعم التعليقات المضمنة، اقتراحات تحرير، والموافقة/الرفض مع سبب. عند رفض المراجع، احتفظ بالتاريخ—لا تكتب فوقه.
هذا يجعل عملية المراجعة قابلة للتدقيق ويقلّل الأخطاء المتكررة.
سيتغير نص المصدر. عندما يحدث ذلك، علّم الترجمات الموجودة بأنها بحاجة لتحديث وعرّض فرق أو "ما تغيّر". احتفظ بالترجمة القديمة كمرجع، لكن امنع إعادة الموافقة عليها بدون قرار صريح.
أعلِم بالأحداث التي تعطل التقدم: تعيين جديد، طلب مراجعة، رفض، اقتراب موعد الاستحقاق، وتغيّر مصدر يؤثر على ترجمات معتمدة.
اجعل الإشعارات قابلة للتنفيذ بروابط عميقة مثل /projects/{id}/locales/{locale}/tasks كي يتمكن الناس من حل المشاكل بنقرة.
تلاعب الملفات اليدوي هو مصدر الانحراف: يعمل المترجمون على سلاسل قديمة، ينسى المطورون سحب التحديثات، وتصدر الإصدارات بنصوص نصف مكتملة.
يجب أن يعامِل تطبيق إدارة التوطين الاستيراد/التصدير كأنبوب قابل للتكرار، لا كمهمة لمرة واحدة.
ادعم المسارات الشائعة التي تستخدمها الفرق:
عند التصدير، اسمح بالفلترة حسب المشروع، الفرع، اللغة، والحالة (مثلاً "المعتمد فقط"). هذا يمنع تسرب السلاسل غير المراجعة إلى الإنتاج.
تنجح المزامنة فقط إذا بقيت المفاتيح ثابتة. قرّر مبكرًا كيف تُولَّد السلاسل:
checkout.button.pay_now)، احمها من إعادة التسمية العرضية.يجب أن يكتشف تطبيقك عندما يتغير نص المصدر لكن المفتاح لم يتغير، ويعلّم الترجمات بأنها بحاجة لمراجعة بدلًا من الكتابة فوقها.
أضف webhooks حتى تحدث المزامنة تلقائيًا:
main → استيراد السلاسل المحدثة.يجب أن تكون webhooks قابلة لإعادة التشغيل (idempotent) وتنتج سجلات واضحة: ما الذي تغيّر، ما الذي تم تخطيه، ولماذا.
إذا كنت تنفّذ هذا، وثّق الإعداد البسيط من الطرف إلى الطرف (وصول المستودع + webhook + تصدير PR) واربطه من الواجهة، مثلاً: /docs/integrations.
QA للتوطين هو المكان الذي يتحول فيه التطبيق من محرر بسيط إلى نظام يمنع أخطاء الإنتاج.
الهدف هو اكتشاف المشكلات قبل شحنها — خصوصًا التي تظهر فقط في ملف لغة معين.
ابدأ بفحوص يمكن أن تكسر الواجهة أو تخرّب التنسيق:
{count} موجود بالإنجليزية لكن مفقود بالفرنسية، أو أشكال الجمع غير متسقة).% في سلاسل printf، ICU غير مصاغة).عامل هذه كـ"منع إصدار" افتراضيًا، مع رسالة خطأ واضحة ومؤشر للمفتاح واللغة المحددين.
هذه لا تكسر التطبيق دائمًا، لكنها تضر بالجودة والاتساق:
قد يكون النص صحيحًا ومع ذلك يبدو سيئًا. أضف طريقة لطلب سياق لقطة شاشة لكل مفتاح (أو إرفاق لقطة شاشة بالمفتاح)، حتى يتمكن المراجعون من التحقق من القطع، انكسارات الأسطر، والنبرة في واجهة المستخدم الحقيقية.
قبل كل إصدار، أنشئ ملخّص QA لكل لغة: الأخطاء، التحذيرات، السلاسل غير المترجمة، وأبرز المخالفات.
اجعل التصدير أو الربط الداخلي سهلًا (مثال: /releases/123/qa) حتى يحصل الفريق على رؤية "انطلق/لا تنطلق" واحدة.
إضافة معجم، ذاكرة ترجمة (TM)، وترجمة آلية (MT) يمكن أن تسرّع التوطين كثيرًا — لكن فقط إذا عامل التطبيق هذه كإرشاد وأتمتة، لا كمحتوى "جاهز للنشر".
المعجم هو قائمة من المصطلحات المراجعة مع ترجمات معتمدة لكل لغة (أسماء المنتجات، مفاهيم الواجهة، عبارات قانونية).
خزن الإدخالات كـمصطلح + لغة + ترجمة معتمدة + ملاحظات + حالة.
لتطبيقه، أضف فحوصًا في محرر المترجمين:
TM تعيد استخدام الترجمات المعتمدة سابقًا. اجعلها بسيطة:
عامل TM كنظام اقتراح: يمكن للمستخدم قبول أو تعديل أو رفض المطابقات، ويجب أن تغذي فقط الترجمات المقبولة ذاكرة الترجمة.
الـMT مفيدة للمسودات والرصيد المتراكم، لكنها ليست الناتج النهائي الافتراضي.
اجعل MT خيارًا ضمن المشروع والمهام، ومرّر النص المترجم آليًا عبر عملية المراجعة الاعتيادية.
لكل فريق قيود مختلفة. اسمح للمسؤولين باختيار المزوّدين (أو تعطيل MT تمامًا)، وضبط حدود الاستخدام، وتحديد البيانات المرسلة (مثلاً استبعد المفاتيح الحساسة).
سجّل الطلبات لرؤية التكلفة والتدقيق، ووثّق الخيارات في /settings/integrations.
لا يجب أن يقتصر تطبيق التوطين على "تخزين الترجمات" — يجب أن يساعدك على شحنها بأمان.
الفكرة الأساسية هي الإصدار: لقطة مجمّدة من النصوص المعتمدة لبناء معين، بحيث يكون ما يتم نشره متوقعًا وقابلًا لإعادة البناء.
عامل الإصدار كحزمة لا تتغير:
هذا يتيح الإجابة عن: "ما الذي شحن في v2.8.1 لـ fr-FR؟" دون تخمين.
يرغب معظم الفرق في التحقق من الترجمات قبل ظهورها للمستخدمين. نمذج التصديرات حسب البيئة:
اجعل نقطة نهاية التصدير صريحة (مثال: /api/exports/production?release=123) لتجنب تسريبات نصوص غير مراجعة.
التراجع أسهل عندما تكون الإصدارات غير قابلة للتغيير. إذا أدخل إصدار مشكلة (عناصر نائبة مكسورة، مصطلحات خاطئة)، يجب أن تكون قادرًا على:
تجنّب "تحرير الإنتاج في المكان" — يكسر آثار التدقيق ويجعل الحوادث أصعب للتحليل.
ملاحظة: ذهنية "اللقطة + التراجع" تتوافق مع كيفية عمل منصات البناء الحديثة. على سبيل المثال، تضمّن Koder.ai لقطات وتراجع كجزء أساسي من سير العمل للتطبيقات التي تولّدها، وهو نموذج ذهني مفيد عند تصميم إصدارات توطين غير قابلة للتغيير.
بعد النشر، شغّل قائمة تشغيل تشغيلية صغيرة:
إذا عرضت سجل الإصدارات في الواجهة، أدرج "فرق مقارنة مع الإصدار السابق" حتى يستطيع الفريق رصد التغييرات الخطرة بسرعة.
الأمان والرؤية هما الفارق بين أداة توطين مفيدة وأداة تثق بها الفرق. عندما يستقر سير العمل، أَمّن النظام وابدأ بقياسه.
اتبع مبدأ أدنى الامتيازات افتراضيًا: لا يجب أن يتمكن المترجمون من تغيير إعدادات المشروع، ولا يجب أن يصل المراجعون إلى الفواتير أو التصديرات الخاصة بالمسؤولين. اجعل الأدوار صريحة وقابلة للتدقيق.
خزن الأسرار بأمان. احتفظ ببيانات الاعتماد لقاعدة البيانات، مفاتيح توقيع الويب هوكس، ورموز الطرف الثالث في مدير أسرار أو متغيرات بيئة مشفرة — لا في المستودع. دوّر المفاتيح دوريًا وعند خروج شخص من الفريق.
النسخ الاحتياطية ليست اختيارية. نفّذ نسخًا آليًا من قاعدة البيانات وتخزين الكائنات (ملفات اللغات، المرفقات)، اختبر الاستعادة، وعرّف الاحتفاظ. "نسخة احتياطية لا تُستعاد" ما هي إلا تخزين إضافي.
إذا كانت السلاسل قد تضمّن محتوى من المستخدم (تذاكر الدعم، أسماء، عناوين)، تجنب تخزينها في نظام الترجمة. فضّل العناصر النائبة أو المراجع، واحذف السجلات الحساسة من السجلات.
إذا اضطُررت لمعالجة مثل هذا النص، عرّف قواعد احتفاظ وقيود وصول.
اتبّع بعض المقاييس التي تعكس صحة سير العمل:
لوحة بسيطة وتصدير CSV يكفيان للبدء.
عندما تكون الأساسيات ثابتة، فكر في:
إذا تخطط لتقديم هذا كخدمة، أضف مسار ترقية واضح ودعوة لاتخاذ إجراء (انظر /pricing).
إذا هدفك الفوري هو التحقق من سير العمل بسرعة مع مستخدمين حقيقيين، يمكنك أيضًا نمذجة الـMVP على Koder.ai: وصِف الأدوار، تدفق الحالات، وصيغ الاستيراد/التصدير في وضع التخطيط، تفاعل على واجهة React وAPI بـGo عبر الدردشة، ثم صدّر قاعدة الكود عند الاستعداد لتقويتها للإنتاج.
تطبيق إدارة التوطين على الويب يركّز السلاسل النصية ويدير سير العمل حولها — الترجمة، المراجعة، الموافقات، والتصدير — حتى تتمكن الفرق من طرح تحديثات دون مفاتيح مفقودة أو عناصر نائب (placeholders) خاطئة أو حالة غير واضحة.
ابدأ بتحديد ما يلي:
pt-BR → pt → en)نطاق ضيق يمنع خطأ "سير عمل واحد يناسب الجميع" ويجعل الـMVP قابلًا للاستخدام بسرعة.
يمكن لمعظم الفرق تغطية سير العمل الأساسي بالكيانات التالية:
سجّل بيانات تساعد على منع الأخطاء الإنتاجية وتخفيف دورات المراجعة:
يعتمد على ما تريد تحسينه:
استخدم طبقتين:
ابدأ بالأدوار التي تعكس العمل الفعلي:
علّم الأذونات على مستوى الإجراءات (تعديل المصدر، الموافقة، التصدير) لتظل مرنًا مع نمو النظام.
ركّز على موارد قليلة ومركزية:
Projects, Locales, Keys, Translationsاجعل نقاط النهاية قابلة للفلترة حسب المهام الحقيقية، مثل:
اجعل الأعمال الطويلة غير متزامنة:
اجعل الوظائف قابلة لإعادة التشغيل (idempotent) وسجّل مخرجات كل مشروع حتى تتمكن الفرق من تشخيص الأخطاء دون التنقيب في سجلات الخادم.
ركّز على الفحوص التي تمنع تحطيم واجهة المستخدم:
{count}, %d) وتغطية أشكال الجمع\n- صحة الصيغة (هروب JSON، تركيب ICU)\n- صحة HTML حيثما يُسمح بعلاماتعامل هذه الفحوص كعوائق إصدار افتراضية، وأضف تحذيرات أخف للاتساق مع القاموس والفراغات/الحالة.
draft → in_review → approved)إذا كانت هذه الكيانات واضحة، تصبح الشاشات والصلاحيات والتكاملات أسهل للبناء والصيانة.
created_by، updated_by، الطوابع الزمنية، سبب التغيير)هذا هو الفرق بين "محرر نصي" ونظام يمكن للفرق الوثوق به.
هذا يدعم التحرير البشري في الواجهة والأتمتة عبر CLI/CI.