مقارنة الترجمة بالذكاء الاصطناعي: Gemini ضد GPT-4 ضد DeepSeek لملفات ‎.po

لديك ثلاثة من أقوى نماذج الذكاء الاصطناعي في التاريخ في متناول يدك. تلصق سلسلة ‎.po WordPress في كل منها. اثنان منهم يدمران موقعك.

هذا ليس سيناريو افتراضيًا. يحدث هذا كل يوم للمطورين الذين يفترضون أن "جيد في اللغة الإنجليزية" يعني "جيد في Gettext". الحقيقة هي أن ترجمة ملفات توطين WordPress هي مهمة متخصصة، وكل نموذج لغوي كبير يتعامل معها بشكل مختلف تمامًا.

قمنا بتشغيل نفس مجموعة سلاسل ‎.po من خلال Gemini 2.0 Flash و GPT-4 و DeepSeek لمعرفة النموذج الذي ينتج ترجمات أكثر دقة وأمانًا للتعليمات البرمجية. كانت النتائج مفاجئة.

إعداد الاختبار: ما قمنا بترجمته

لقد اخترنا 200 سلسلة حقيقية من متجر WooCommerce قيد التشغيل وسمة WordPress شائعة. كانت مجموعة الاختبار صعبة عن قصد، وتغطي:

• سلاسل واجهة مستخدم بسيطة ("أضف إلى السلة"، "نتائج البحث")
• سلاسل تحتوي على متغيرات printf (‎%s‎، ‎%d‎، ‎%1$s of %2$s‎)
• سلاسل تحتوي على علامات HTML (‎<strong>‎، ‎<a href>‎، ‎<br/>‎)
• صيغ الجمع (‎msgid_plural‎) التي تستهدف البولندية (3 صيغ) والعربية (6 صيغ)
• سلاسل ذات سياق (‎msgctxt‎) حيث يمكن أن تعني كلمة "Post" منشور مدونة أو الفعل "لنشر"

تلقى كل نموذج نفس المطالبة: ترجمة إدخالات Gettext هذه من الإنجليزية إلى التركية، مع الحفاظ على جميع المتغيرات وعلامات HTML تمامًا كما تظهر في المصدر.

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

الجولة الأولى: سلاسل واجهة المستخدم البسيطة

تعاملت جميع النماذج الثلاثة مع السلاسل الأساسية بشكل جيد. أصبحت "أضف إلى السلة" "Sepete Ekle" في كل مكان. تم عرض "تسجيل الدخول" بشكل صحيح. لا توجد مفاجآت هنا.

ولكن حتى في هذه الفئة البسيطة، لاحظنا نمطًا. أضاف GPT-4 أحيانًا علامات أدب لم تكن موجودة في المصدر. تحولت كلمة "حذف" الموجزة إلى ما يعادلها الأكثر رسمية، مما أضاف 3-4 أحرف إضافية. ليس خطأ، ولكنه مصدر قلق لتخطيطات واجهة المستخدم حيث يكون عرض الزر ثابتًا.

أنتج DeepSeek ترجمات حرفية أكثر بقليل، وهو أمر مفضل بالفعل لعناصر واجهة المستخدم حيث يكون الإيجاز مهمًا.

حقق Gemini توازنًا، حيث طابق سجل وطول السلسلة المصدرية بأكثر ثباتًا.

الخلاصة: سلاسل بسيطة

كل الثلاثة اجتازوا. اختلافات أسلوبية طفيفة فقط.

الجولة الثانية: متغيرات Printf والوسائط الموضعية

هنا تظهر الاختلافات الحقيقية. ضع في اعتبارك سلسلة WordPress الشائعة هذه:

msgid "Page %1$s of %2$s"
msgstr ""

إليك ما أنتجه كل نموذج عند الترجمة إلى التركية:

# Gemini 2.0 Flash
msgstr "Sayfa %1$s / %2$s"

# GPT-4
msgstr "Sayfa %1$s / %2$s"

# DeepSeek
msgstr "%1$s / %2$s. Sayfa"

حافظت النماذج الثلاثة على المتغيرات سليمة من الناحية الفنية. لكن DeepSeek أعاد ترتيب هيكل الجملة، ونقل كلمة "Sayfa" إلى النهاية. على الرغم من الإبداع النحوي، إلا أن هذا يغير المعنى: يقرأ المستخدم الآن "1 / 10. الصفحة" بدلاً من "الصفحة 1 من 10".

الآن انظر إلى مثال أكثر خطورة:

msgid "Hello %s, you have %d new messages"
msgstr ""

# Gemini 2.0 Flash
msgstr "Merhaba %s, %d yeni mesajiniz var"

# GPT-4
msgstr "Merhaba %s, %d yeni mesajınız var"

# DeepSeek
msgstr "Merhaba % s, % d yeni mesajınız var"

ها هو. أضاف DeepSeek مسافات داخل ‎%s‎ و ‎%d‎، وحولهما إلى ‎% s‎ و ‎% d‎. لن يتعرف ‎sprintf()‎ الخاص بـ PHP على هذه. إما أن يطرح موقعك خطأً فادحًا أو يعرض سلسلة المتغيرات الأولية للمستخدمين.

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

الخلاصة: المتغيرات

Gemini و GPT-4 موثوقان. DeepSeek خطير بدون معالجة لاحقة.

الجولة الثالثة: الحفاظ على علامات HTML

تحتوي سلاسل WordPress بشكل متكرر على HTML مضمن. هنا مثال حقيقي:

msgid "Click <a href=\"%s\">here</a> to view your <strong>order</strong>."
msgstr ""

# Gemini 2.0 Flash
msgstr "<a href=\"%s\">Buraya</a> tıklayarak <strong>siparişinizi</strong> görüntüleyin."

# GPT-4
msgstr "Siparişinizi görüntülemek için <a href=\"%s\">buraya</a> tıklayın.</strong>"

# DeepSeek
msgstr "<a href=\"%s\">buraya</a> tıklayarak <strong>siparişinizi</strong> görüntüleyin."

ارتكب GPT-4 خطأً دقيقًا ولكنه بالغ الأهمية. نقل علامة الإغلاق ‎</strong>‎ إلى نهاية الجملة، بعيدًا عن نظيرتها الافتتاحية ‎<strong>‎. النتيجة: كل شيء بعد كلمة "order" في الصفحة يظهر بالخط العريض، مما قد يؤثر على التخطيط بأكمله أدناه.

حافظ كل من Gemini و DeepSeek على هيكل HTML بشكل صحيح في هذه الحالة. ومع ذلك، عبر اختبارنا الكامل المكون من 200 سلسلة، أضاف DeepSeek مسافات داخل العلامات ذاتية الإغلاق (‎<br />‎ أصبحت ‎<br / >‎) في 3 حالات.

الخلاصة: HTML

Gemini هو الأكثر اتساقًا. يقدم كل من GPT-4 و DeepSeek أخطاء HTML هيكلية في ظل ظروف معينة.

الجولة الرابعة: صيغ الجمع

التعامل مع صيغة الجمع هو المكان الذي تنهار فيه معظم أدوات الترجمة تمامًا. تحتوي اللغة الإنجليزية على صيغتين للجمع. التركية لديها أيضا 2. لكن البولندية لديها 3، والعربية لديها 6.

لقد اختبرنا هذه السلسلة مقابل اللغة البولندية (‎nplurals=3‎):

msgid "%d item in your cart"
msgid_plural "%d items in your cart"

أنتج Gemini بشكل صحيح ثلاثة إدخالات ‎msgstr‎، تم تصريف كل منها للنطاق الرقمي المناسب. أنتج GPT-4 أيضًا ثلاثة أشكال ولكن في بعض الأحيان قام بدمج النموذجين 1 و 2 في نص متطابق، وهو أمر غير صحيح نحويًا للغة البولندية. أنتج DeepSeek شكلين فقط، متجاهلاً تمامًا متطلب ‎nplurals=3‎.

للحصول على شرح أعمق لسبب أهمية ذلك وكيف تستخدم WordPress رأس ‎Plural-Forms‎، راجع دليلنا حول صيغ الجمع في Gettext.

الخلاصة: صيغ الجمع

Gemini في الصدارة. GPT-4 مقبول مع المراجعة. يفشل DeepSeek للغات التي تحتوي على أكثر من صيغتين للجمع.

الجولة الخامسة: توضيح السياق

يخبر حقل ‎msgctxt‎ في Gettext المترجم بكيفية استخدام الكلمة. يمكن أن تعني كلمة "Post" ما يلي:

• منشور مدونة (اسم)
• لنشر تعليق (فعل)
• بريد (اسم، في اللغة الإنجليزية البريطانية)

msgctxt "verb: to publish"
msgid "Post"
msgstr ""

msgctxt "noun: blog entry"
msgid "Post"
msgstr ""

ميز Gemini بشكل صحيح بين الاثنين، حيث أنتج "Yayinla" (نشر) للفعل و "Yazi" (مقالة) للاسم. تعامل GPT-4 أيضًا مع هذا بشكل صحيح. ترجم DeepSeek كلاهما على أنه "Gonderi" (اسم عام)، متجاهلاً تلميح ‎msgctxt‎.

الوعي بالسياق ليس ميزة فاخرة. إذا كان زر "نشر" الخاص بك ينشر تعليقًا ولكن الترجمة تقول "مقالة"، فسوف يتردد المستخدمون في النقر فوقه. لقد ناقشنا لماذا يعتمد أمان الذكاء الاصطناعي في توطين WordPress على هذا النوع من الفهم السياقي بالضبط.

الخلاصة: السياق

يتعامل Gemini و GPT-4 مع ‎msgctxt‎ بشكل جيد. DeepSeek يتجاهله.

سجل الأداء

لماذا لا يكفي إخراج النموذج الخام أبدًا

حتى Gemini، الأفضل أداءً في اختباراتنا، ليس معصومًا من الخطأ. عبر 200 سلسلة، قدم مشكلات في التباعد في حالتين وأضاف مرة واحدة نقطة غير ضرورية إلى سلسلة لم يكن بها أي شيء في المصدر.

هذا هو السبب في أن التحقق من المعالجة اللاحقة ضروري. بغض النظر عن النموذج الذي تستخدمه، يجب تشغيل الإخراج من خلال:

1. تطبيع العناصر النائبة لإصلاح ‎% s‎ مرة أخرى إلى ‎%s‎
2. مطابقة علامات الترقيم للتأكد من أن السلسلة المترجمة تنتهي بنفس الحرف الموجود في المصدر
3. فرض صيغة الجمع للتحقق من العدد الصحيح لإدخالات ‎msgstr‎
4. التحقق من عدد المتغيرات للتأكد من أن كل ‎%s‎ و ‎%d‎ من المصدر يظهران في الهدف

هذا هو المبدأ الكامن وراء تأمين بناء الجملة، طبقة التحقق التي تقع بين نموذج الذكاء الاصطناعي وملف ‎.po‎ النهائي. إنه يكتشف كل خطأ حتى أفضل نموذج يرتكبه أحيانًا.

إذا كنت تقوم بتقييم الأدوات لسير عملك، فإن ملخصنا لأفضل 5 أدوات مجانية لتحرير وترجمة ملفات PO يغطي المشهد خارج الحلول القائمة على الذكاء الاصطناعي فقط.

الخلاصة

يعتبر Gemini 2.0 Flash حاليًا النموذج الأكثر موثوقية لترجمة ملفات ‎.po‎ في WordPress. إنه يتعامل مع المتغيرات و HTML وصيغ الجمع والسياق بشكل أفضل من المنافسة. GPT-4 هو خيار ثانٍ قوي ولكنه يتطلب مراجعة دقيقة لإخراج HTML وصيغ الجمع. DeepSeek، على الرغم من نقاط قوته في مهام البرمجة ذات الأغراض العامة، إلا أنه غير مناسب لترجمة Gettext بدون معالجة لاحقة مكثفة.

ولكن إليك البصيرة الأساسية: النموذج وحده غير كافٍ. حتى Gemini يحتاج إلى طبقة تحقق لاكتشاف الحالات الشاذة. الفرق بين أداة توطين احترافية واستدعاء API خام ليس نموذج الذكاء الاصطناعي. إنه كل ما يحدث قبل وبعد تشغيل النموذج.

تستخدم SimplePoTranslate Gemini كمحركها الأساسي، ملفوفًا في مسار ذكاء اصطناعي واعي بالسياق مع تأمين بناء الجملة الذي يكتشف ويصحح كل متغير وعلامة وصيغة جمع تلقائيًا. تحصل على أفضل نموذج جنبًا إلى جنب مع شبكة الأمان التي تجعله جاهزًا للإنتاج.

هل تريد أن ترى الفرق بنفسك؟ قم بتحميل ملف ‎.po‎ الخاص بك وترجمة ما يصل إلى 100 سلسلة مجانًا على SimplePoTranslate.com