DeepL مقابل Google Translate مقابل الذكاء الاصطناعي: الأفضل لملفات .po؟

تقوم بتصدير ملف .pot من إضافة WordPress الخاصة بك، ثم تلصق بضع مئات من النصوص في DeepL أو Google Translate، وتستعيد عمودًا ألمانيًا مرتبًا، وتضعه في ملف .po الخاص بك، ثم تقوم بالترجمة النهائية والنشر. ثم يبلغ مستخدم أن صفحة سلة التسوق تظهر %1$s خامًا حيث يجب أن يكون اسم المنتج، أو الأسوأ من ذلك، أن سطر السعر يقرأ You have 1 items بكل لغة لأن صيغة الجمع انهارت. كانت جودة الترجمة جيدة. لكن بنية الترجمة دمرت.
هذا هو جوهر الخلاف في نقاش DeepL مقابل Google Translate عندما يكون المصدر ملف .po من Gettext وليس فقرة نثرية. كلاهما عالمي المستوى في ترجمة الجمل الطبيعية. لم يتم تصميم أي منهما لاحترام عنصر نائب لـ printf، أو مصفوفة جمع Gettext، أو توضيح msgctxt. يتعاملون مع %1$s كخطأ مطبعي يجب تصحيحه ومع صيغة جمع ثنائية كجملة واحدة لتسويتها. بالنسبة للنصوص التسويقية، هذا غير مرئي. أما بالنسبة لتعريب البرمجيات، فإنه يؤدي إلى تعطيل المواقع.
تقارن هذه المقالة الترجمة الآلية الكلاسيكية - DeepL و Google Translate - مقابل مسار عمل ذكاء اصطناعي واعي بالسياق مصمم خصيصًا لـ gettext. سننظر في المحاور التي تهم بالفعل ملفات .po: معالجة العناصر النائبة، صيغ الجمع، السياق، دعم الملفات الكبيرة، والتكلفة. إذا كنت تريد مناقشة أعمق لجودة نماذج اللغة الكبيرة (LLM) مقابل نماذج اللغة الكبيرة، فقد تناولنا ذلك في جودة الترجمة بالذكاء الاصطناعي: Gemini مقابل GPT-4 مقابل DeepSeek. هنا، السؤال أضيق وأكثر عملية: ما هو الأفضل لملفات .po؟
DeepL مقابل Google Translate: ما هي الغاية من بنائهما
كلاهما محركات ترجمة آلية للأغراض العامة مُحسّنة لإنتاج مخرجات سلسة وبلغة طبيعية. لا يقوم أي منهما بتحليل تنسيقات الملفات.
DeepL - سلس، لكن لا يدرك التنسيق
يحظى DeepL بثناء واسع لإنتاجه الأكثر طبيعية، خاصة عبر اللغات الأوروبية. لكنه يستقبل النص، وليس البنية. زوده بمعرف رسالة (msgid) لملف .po يحتوي على %1$s ordered %2$s وسيترجم الكلمات المحيطة بالعناصر النائبة بينما يقوم في كثير من الأحيان بإعادة ترتيب أو إضافة مسافات أو إسقاط الرموز - لأنها بالنسبة لـ DeepL مجرد أحرف غريبة في جملة.
Google Translate - تغطية واسعة، نفس النقطة العمياء
يدعم Google Translate عددًا أكبر بكثير من اللغات وهو الخيار الافتراضي الاقتصادي وراء إضافات مثل GTranslate. لا تختلف معالجته للعناصر النائبة. يشترك كلا المحركين في نفس القيد الأساسي: إنهما يحسّنان سلاسة الجملة ولا يملكان نموذجًا لقواعد gettext.
السؤال الحقيقي ليس عن الجودة - بل عن البنية
بالنسبة لملفات .po، الجودة اللغوية الخام هي الحد الأدنى المطلوب. ما يعطل الإنتاج هو السلامة الهيكلية: هل تبقى المتغيرات سليمة، هل تبقى صيغ الجمع متعددة الأشكال، هل يتم احترام السياق. هذا هو المكان الذي يتفوق فيه مسار عمل الذكاء الاصطناعي الذي يدرك gettext على كل من DeepL و Google Translate.
لماذا تؤدي العناصر النائبة وصيغ الجمع إلى تعطيل الترجمة الآلية
ملف .po ليس نصًا نثريًا. إنه نص قريب من الكود مع قواعد صارمة، وثلاثة من هذه القواعد تهزم الترجمة الآلية الكلاسيكية بشكل روتيني.
تشويه العناصر النائبة والمتغيرات
سلاسل نصوص WordPress مليئة بالعناصر النائبة على غرار printf: %s، %d، والأشكال الموضعية مثل %1$s و %2$s. العناصر الموضعية مهمة لأن بعض اللغات تعيد ترتيب الجملة، والأرقام تخبر sprintf أي وسيطة تذهب إلى أي مكان. شاهد ما تفعله الترجمة الآلية الكلاسيكية بهذا:
// Source string in your .po file
$msg = sprintf( __( '%1$s left a comment on %2$s', 'mytheme' ), $user, $post );
// What DeepL / Google Translate often return (German):
// "%2$s hat einen Kommentar zu %1$s hinterlassen" <- reordered, OK
// "% 1$ s hat einen Kommentar..." <- spaces injected, BROKEN
// "hat einen Kommentar hinterlassen" <- placeholders dropped, BROKEN
مسافة واحدة مضافة (% 1$ s) أو رمز محذوف يتسبب في ظهور تحذير PHP أو طباعة كود خام لمستخدميك. نتعمق في وضع الفشل هذا في كيفية ترجمة ملفات PO دون تعطيل متغيرات الكود.
انهيار صيغ الجمع
صيغ الجمع في Gettext ليست سلسلة نصية واحدة - إنها مصفوفة مفتاحها قاعدة الجمع للغة. الإنجليزية لها صيغتان؛ البولندية لها ثلاث؛ العربية لها ست. تستقبل الترجمة الآلية الكلاسيكية msgid_plural كجملتين منفصلتين وتترجمهما بشكل مستقل، دون وعي بأنه يجب أن تبقيا كمجموعة متماسكة متعددة الأشكال. غالبًا ما تكون النتيجة صيغة واحدة مكررة، لذا 1 item و 5 items تظهران بشكل متطابق.
msgid "%d item in your cart"
msgid_plural "%d items in your cart"
msgstr[0] ""
msgstr[1] ""
# A gettext-aware pipeline fills BOTH forms correctly with %d preserved.
# DeepL/Google translate each line in isolation and lose the plural relationship.
يتم تجاهل السياق (msgctxt)
يستخدم Gettext msgctxt لإزالة الغموض عن السلاسل المتطابقة - "Post" الاسم مقابل "Post" الفعل، أو "Order" كاسم مقابل فعل في WooCommerce. لا ترى الترجمة الآلية الكلاسيكية حقل السياق هذا أبدًا، لذلك تخمن، وتخمن بنفس الطريقة في كل مرة بغض النظر عن مكان ظهور السلسلة.
يتفاقم الضرر في التجارة. كتالوج WooCommerce مليء بالسلاسل النصية القصيرة والمبهمة - "Order" (طلب)، "Ship" (شحن)، "Free" (مجاني)، "View" (عرض) - حيث يؤدي الفهم الخاطئ إلى زر يقول شيئًا خاطئًا بلغة العميل. نظرًا لأن DeepL و Google Translate يترجمان كل سلسلة على حدة، فلا يمكنهما استخدام السياق المحيط الذي يقوم gettext بترميزه عن عمد. مسار عمل يدرك التنسيق ويقرأ msgctxt يحل هذه الالتباسات بالضبط، وهذا هو السبب في أهميته القصوى في صفحات المتجر حيث تكلف الترجمات الخاطئة مبيعات حقيقية.
نهج الذكاء الاصطناعي الواعي بالسياق لملفات .po
لا يترجم مسار عمل gettext المصمم خصيصًا الكلمات فقط - بل يفهم تنسيق الملف ويحمي هيكله. هذا هو الفرق على مستوى الفئة، وهذا هو السبب في أن المقارنة الصحيحة ليست DeepL مقابل Google Translate على الإطلاق، بل الترجمة الآلية الكلاسيكية مقابل سير عمل ذكاء اصطناعي يدرك التنسيق.
قفل البنية يحمي كل رمز
التقنية الحاسمة هي قفل البنية (Syntax Locking). قبل أن يصل أي نص إلى الذكاء الاصطناعي، يتم قفل كل متغير (%s، %1$s، {name})، وعلامة HTML، ورمز كودي ووضعها جانبًا. يرى النموذج الكلمات المقروءة بشريًا فقط ويعيد كتابتها. بعد الترجمة، يتم استعادة الرموز المقفلة في مواضعها الصحيحة. لا يمكن أن يحدث تشويه % 1$ s هذا، لأن الذكاء الاصطناعي لا يلمس العنصر النائب في المقام الأول. هذه هي شبكة الأمان التي تفتقر إليها الترجمة الآلية الكلاسيكية من الناحية الهيكلية - وهي نقطة نتوسع فيها في الترجمة اليدوية مقابل الترجمة بالذكاء الاصطناعي: هل الذكاء الاصطناعي آمن لتعريب WordPress.
دعم كامل لصيغ الجمع والسياق
يقرأ مسار عمل يدرك gettext msgid_plural كمجموعة ويولد كل صيغة مطلوبة لقاعدة الجمع في اللغة الهدف، مع الحفاظ على العناصر النائبة سليمة عبر جميعها. كما يقرأ msgctxt ويستخدمه كسياق، بحيث يتم ترجمة "Order" الاسم و "Order" الفعل بشكل مختلف وصحيح.
ملفات مجمعة، لا نسخ ولصق
DeepL و Google Translate هما أدوات للصق في مربع (أو واجهات برمجة تطبيقات لكل حرف). يستوعب مسار عمل .po السحابي الملف بأكمله - ومع التجميع الذكي (Smart Batching)، يتم تقسيم حزم سلاسل WooCommerce التي تزيد عن 10 ميجابايت، وترجمتها بالتوازي، ودمجها، حيث ينهار نهج النسخ واللصق قبل ذلك بكثير. تقوم بتحميل ملف وتنزيل .po + .mo + المزيد، بدلاً من تجميع الأعمدة يدويًا.
DeepL مقابل Google Translate مقابل الذكاء الاصطناعي الواعي بـ Gettext: الحكم
بالنسبة للنصوص النثرية العادية، DeepL و Google Translate ممتازان. بالنسبة لملفات .po، المحاور التي تحدد سلامة الإنتاج هي العناصر النائبة، صيغ الجمع، السياق، والمعالجة المجمعة - وهذا هو المكان الذي يفوز فيه مسار عمل يدرك التنسيق.
جدول المقارنة
| القدرة | DeepL | Google Translate | الذكاء الاصطناعي الواعي بـ Gettext |
|---|---|---|---|
| طلاقة اللغة الطبيعية | ممتاز | جيد جدًا | جيد جدًا |
أمان %1$s / العنصر النائب | محفوف بالمخاطر | محفوف بالمخاطر | مقفل (قفل البنية) |
| صيغ جمع Gettext | يسوّيها | يسوّيها | دعم كامل لكل لغة |
سياق msgctxt | يتم تجاهله | يتم تجاهله | يتم استخدامه |
إدخال ملفات .po المجمعة | لصق يدوي | لصق يدوي | تحميل ملف كامل |
| حزم WooCommerce الكبيرة | تنهار | تنهار | التجميع الذكي (Smart Batching) |
| تنسيقات الإخراج | نص فقط | نص فقط | .po + .mo + .json + .php + .xliff |
كيف تختار
إذا كنت تترجم منشور مدونة أو صفحة تسويقية، استخدم DeepL للنبرة. إذا كنت تترجم ملف .po أو .pot مخصصًا لموقع WordPress مباشر، فإن الطلاقة ليست العامل الحاسم - بل السلامة الهيكلية. يمنحك مسار عمل الذكاء الاصطناعي الواعي بـ gettext كليهما: جودة لغوية قوية وعناصر نائبة، وصيغ جمع، وسياق تبقى سليمة حتى ملف .mo المترجم.
هناك أيضًا تكلفة لسير العمل يقلل الجدول من شأنها. تشغيل إضافة كاملة عبر DeepL أو Google Translate يعني نسخ أعمدة من النصوص إلى مربع، ولصق النتائج مرة أخرى، وإعادة فحص كل عنصر نائب يدويًا - وهي عملية مملة وعرضة للأخطاء تزداد سوءًا مع كل لغة إضافية. يقوم مسار العمل القائم على الملفات بتبسيط ذلك إلى تحميل وتنزيل واحد، ولا يعيد فقط ملف .po بل أيضًا ملف .mo المترجم وتنسيقات أخرى في ملف ZIP واحد، بحيث يكون الملف الذي تشحنه هو الملف الذي أنتجه الذكاء الاصطناعي - لا يوجد إعادة تجميع يدوية حيث تتسرب أخطاء جديدة.
الخلاصة
الإجابة الصريحة على سؤال DeepL مقابل Google Translate لملفات .po هي أنك تسأل عن المتنافسين الخطأ. كلاهما مترجمان نثر ممتازان وكلاهما أعمى هيكليًا عن gettext - يقومان بتشويه %1$s، ويسويان صيغ الجمع، ويتجاهلان msgctxt، لأنهما لم يُبنيا أبدًا لقراءة ملف ترجمة. بالنسبة لتعريب البرمجيات، هذا هو الفرق بين إصدار نظيف وصفحة سلة مشوهة.
يغير مسار عمل الذكاء الاصطناعي الواعي بالسياق مع قفل البنية المقارنة تمامًا. إنه يطابق الطلاقة التي تتوقعها من DeepL أو Google Translate مع ضمان وصول كل متغير، وصيغة جمع، وملاحظة سياقية سليمة - بحيث يعمل موقعك المترجم، ولا يكتفي بالقراءة الجيدة.
هل أنت مستعد لترجمة ملفات
.poدون عناصر نائبة مشوهة أو صيغ جمع منهارة؟ جرب SimplePoTranslate مجانًا - لا توجد بطاقة ائتمان مطلوبة. حمّل ملفات.po،.pot،.json، أو.xliffواحصل على ترجمات بالذكاء الاصطناعي آمنة لـ gettext على المستوى المجاني.