الطريقة الشائعة لترجمة المحتوى التقني ما زالت مرهقة بشكل غير مبرر:
- تنهي المسودة الإنجليزية
- تلصقها في أداة خارجية
- تنظف الناتج بسرعة
- ثم تأمل أن البنية الأصلية لم تتكسر
هذه الطريقة تنجح بقدر يكفي لتتحول إلى عادة، وهذا بالضبط سبب ضرورة استبدالها. ترجمة المسودات ليست طقس نسخ ولصق، بل مشكلة بنية تحريرية.
لماذا المسودات التقنية أصعب من صفحات التسويق
المحتوى التقني يحمل كل العناصر التي تحب أدوات الترجمة كسرها:
- كتل الكود
- أسماء المنتجات
- أوامر الطرفية
- المصطلحات المختلطة بين الإنجليزية والعربية
- مكوّنات MDX
- بيانات Frontmatter
إذا كان السير مترهلًا، تصبح الترجمة أسرع طريق لإدخال أعطال بنيوية في نظام النشر نفسه. لذلك تبدأ أفضل طبقة ترجمة بحماية شكل الملف قبل تحسين الأسلوب.
احمِ شكل المستند قبل أي شيء
يجب أن يحافظ النظام على هذه العناصر قبل أن يرى الموديل النص أصلًا:
- مفاتيح الـ frontmatter
translationKey- الوسوم وslugs الخاصة بالتصنيف
- code fences
- مكوّنات MDX مثل
CalloutوProsConsوHFRepoCard
وهذا يعني أن خطوة الترجمة يجب أن تعمل على مقاطع النص المستخرجة فقط، لا على الملف كله كسلسلة واحدة خام.
مقتطف شيفرة
ts
import { pipeline } from "@huggingface/transformers";
const translator = await pipeline(
"translation",
"Xenova/nllb-200-distilled-600M"
);
const result = await translator("Secure the workspace before you trust it.", {
src_lang: "eng_Latn",
tgt_lang: "arb_Arab",
});
هذا المثال ليس النظام كاملًا، لكنه يوضح الاتجاه الصحيح: الترجمة يجب أن تكون مرحلة واضحة في الـ pipeline، لا محادثة جانبية داخل تبويب متصفح.
متى تفوز الترجمة المحلية أولًا
هذا النمط قوي جدًا عندما يكون:
- المحتوى غير منشور بعد
- الموقع ثنائي اللغة في بنيته
- الفريق يحتاج اتساقًا بنيويًا عاليًا
- المؤسسة تهتم بالخصوصية أو السرية أو مواد الحظر الزمني
كما أنه يرفع السرعة عمليًا. بمجرد أن تصبح الترجمة Script واضحة، يتوقف الفريق عن إعادة اختراع نفس الخطوات اليدوية مع كل مقال جديد.
أين يبقى دور المحرر أساسيًا
لا توجد غرفة تحرير جادة يجب أن تنشر ترجمة تقنية تلقائيًا من دون مرور بشري. ما زال على المحرر مراجعة:
- اختيار المصطلحات
- النبرة والإيقاع
- أسماء المنتجات
- الفوارق المناطقية في الصياغة
- المواضع التي تبدو فيها الترجمة الحرفية غير طبيعية
الهدف ليس إلغاء المحرر، بل تحرير وقته من إعادة التجميع الميكانيكية.
السير الذي أنصح به فعلًا
لو كنت أبني منصة ثنائية اللغة جادة فسأطلق الترجمة بهذا الترتيب:
- إنشاء مسودة المصدر بشكل نظيف
- تحليل البنية واستخراج frontmatter وكتل MDX وcode fences
- ترجمة المقاطع النصية فقط
- إعادة تركيب الملف مع الحفاظ على بنيته الأصلية
- إرسال المسودة المترجمة للمراجعة التحريرية
بهذا تصبح الترجمة عملية مملة بالمعنى الجيد للكلمة: قابلة للتكرار، قابلة للتدقيق، وأصعب بكثير أن تنكسر بالصدفة.
الخلاصة
في 2026 لا ينبغي أن يعتمد النشر الثنائي اللغة على طقوس النسخ واللصق وحسن النية. بل يجب أن يعتمد على خط إنتاج منضبط يحترم المحتوى غير المنشور، ويحافظ على بنية المستند، ويترك للمحرر ما تزال الآلة ضعيفة فيه: الحكم، والدقة، والصياغة الرفيعة.
لهذا السبب، الترجمة المحلية أولًا ليست مجرد حيلة للمطورين، بل ترقية فعلية في جودة التحرير.