كيف تقدم وكالة محتوى فردية مواقع متعددة اللغات بدون مترجم
By Robert M
كيف تقدم وكالة محتوى فردية مواقع متعددة اللغات بدون مترجم
يسأل العميل إذا كان بإمكانك تقديم موقعهم الجديد بالإنجليزية والفرنسية والألمانية والإسبانية والهولندية. أنت تدير وكالة فردية. ليس لديك ميزانية ترجمة مدمجة في عقدك، وليس لديك شبكة من المترجمين المستقلين جاهزين. لكنك أيضًا لا تريد أن تقول لا لمشروع جيد.
هذه حالة ينتهي بها الكثير من الوكالات الصغيرة والمستقلين. الطلب على المواقع متعددة اللغات نما باستمرار مع محاولة المزيد من الشركات الوصول إلى جماهير خارج سوقها المحلي، لكن محادثات الميزانية لم تلحق بالركب. غالبًا ما يعامل العملاء الترجمة كبند يمكن تقليصه أو قطعه، دون فهم حقيقي لتكلفة القيام بها بشكل صحيح.
هذا المنشور يتحدث عن كيفية التعامل مع هذه الفجوة بشكل عملي، دون التنازل عن الجودة أو تكبد خسارة في المشروع.
الخيارات القديمة ولماذا هي غير كافية
الطرق التقليدية معروفة.
يمكنك توظيف مترجم مستقل لكل لغة. لموقع بخمس لغات يحتوي على ثلاثين صفحة محتوى، أنت تنظر إلى تكلفة كبيرة قبل أن تحسب جولات المراجعة، ووقت التنفيذ، والعبء الإداري لإحاطة خمسة أشخاص مختلفين بأسلوب العميل ومصطلحاته. هذه التكلفة إما تأكل هامشك أو تضاف إلى فاتورة العميل وفجأة يصبح المشروع في خطر.
يمكنك استخدام أداة ترجمة للمستهلك وتنظيفها يدويًا. هذا يعمل للجمل البسيطة، لكن بمجرد أن يحتوي المحتوى على أي هيكل (ملف JSON للغة، منشور مدونة Markdown، صفحة HTML مع سمات وعلامات) يصبح الناتج غير متوقع. تُترجم المفاتيح. تنكسر صياغة Markdown. تُفسد سمات HTML. تنفق وقتًا أكثر في تصحيح الناتج مما حفظته بعدم توظيف مترجم.
يمكنك إخبار العميل أن التعدد اللغوي خارج النطاق وأن تقوم بموقع بلغة واحدة. أحيانًا هذا هو الجواب الصحيح. لكنه ليس دائمًا محادثة تريد خوضها.
ما الذي تغير فعليًا
الشيء الذي جعل هذا سير العمل ممكنًا ليس الترجمة بالذكاء الاصطناعي بشكل عام. إنه الحفاظ على التنسيق تحديدًا.
المشكلة في إدخال محتوى منظم في أداة ترجمة عامة لم تكن جودة الترجمة حقًا. الترجمة الآلية الحديثة جيدة. المشكلة كانت أن الأدوات لم تفهم الفرق بين المحتوى والبنية. كانت تعامل كل شيء كنص للترجمة، بما في ذلك الأجزاء التي كان يجب تركها كما هي.
ملف لغة مثل هذا:
{
"nav": {
"home": "Home",
"about": "About us",
"contact": "Get in touch"
}
}
كان يعود مع ترجمة المفاتيح، أو انهيار التداخل، أو تحويل كل شيء إلى نص سردي. أي من هذه النتائج يعني تنظيفًا يدويًا قبل أن يكون الملف قابلًا للاستخدام، وهنا يختفي توفير الوقت.
واجهة برمجة تطبيقات تعامل البنية كمنطقة محظورة تغير الاقتصاديات. ترسل الملف، تحصل على نفس البنية مع تغيير قيم النص فقط. تضع ملف الإخراج مباشرة في المشروع. لا حاجة لتمرير تنظيف.
سير العمل في التطبيق
إليك كيف يبدو العملية في مشروع فعلي.
في مرحلة المحتوى، كل شيء يُوضع في ملفات نص عادي أو Markdown بدلاً من سلاسل نصية مشفرة. هذه ممارسة جيدة على أي حال للصيانة، لكنها تعني أيضًا أن المحتوى في صيغة يمكن ترجمتها بشكل نظيف.
في مرحلة البناء، يقرأ سكربت قصير ملف اللغة المصدر، يرسله إلى واجهة PolyLingo مع قائمة اللغات المستهدفة، ويكتب ملف إخراج لكل لغة. لموقع يحتاج خمس لغات، هذا يعني مكالمة API واحدة. يستغرق السكربت بضع ثوانٍ للتشغيل. تذهب ملفات الإخراج مباشرة إلى هيكل المشروع.
في مرحلة المراجعة، يراجع العميل المحتوى المترجم. هذه خطوة تستحق الاحتفاظ بها. الترجمة الآلية تتعامل مع معظم المحتوى جيدًا، لكن العملاء أحيانًا لديهم مصطلحات مفضلة، عبارات تحمل علامة تجارية، أو تقاليد إقليمية تحتاج إلى عين بشرية. المراجعة أسرع من الترجمة من الصفر لأن البنية صحيحة بالفعل ومعظم المحتوى دقيق. أنت تراجع بدلاً من أن تنتج.
في مرحلة التسليم، يُشحن الموقع مع كل ملفات اللغة في مكانها. يعمل مفتاح تبديل اللغة من اليوم الأول. لا يوجد شيء للمتابعة.
التكلفة مقارنة بتوظيف المترجمين
الأرقام تعتمد على حجم المشروع، لكن هيكل المقارنة ثابت.
موقع أعمال صغيرة نموذجي قد يحتوي على حوالي 2000 كلمة من نص الواجهة ومحتوى الصفحات. مترجم إلى خمس لغات، هذا حوالي 10000 كلمة ناتجة. بمعدل ترجمة مستقل متوسط، أنت تنظر إلى عدة مئات من الجنيهات أو الدولارات قبل المراجعات.
مع PolyLingo، 2000 كلمة محتوى عبر خمس لغات مستهدفة تناسب خطة Starter المدفوعة بسعر 9 دولارات شهريًا، بما في ذلك القدرة على مشاريع متعددة في نفس فترة الفوترة. الطبقة المجانية (50000 رمز شهريًا) تغطي المشاريع الصغيرة بدون أي تكلفة على الإطلاق.
العميل لا يزال يقوم بتمرير مراجعة، مما يعني أنهم يشاركون في جودة الناتج بدلاً من مجرد استلام فاتورة. هذا يميل لأن يكون أفضل في محادثات المشروع.
محادثة النطاق مع العملاء
تحول واحد يمكّنه هذا سير العمل هو تغيير كيفية الحديث عن نطاق التعدد اللغوي مع العملاء.
سابقًا، "متعدد اللغات" يعني "أغلى، جدول زمني أطول، اعتماد على أطراف ثالثة." الآن هو أقرب إلى قرار تكوين. تحدد النطاق، تشغل السكربت، يراجع العميل. الجزء الصعب هو استراتيجية المحتوى وبنية الموقع، وليس لوجستيات الترجمة.
هذا يغير ما يمكنك تقديمه. عميل كان سيطلق بلغة واحدة مع خطة غامضة لإضافة لغات لاحقًا يمكنه إطلاق كل الخمس لغات دفعة واحدة بدون مضاعفة تكلفة المشروع. عميل يضيف صفحات باستمرار يمكنه إعادة تشغيل السكربت كلما تغير المحتوى بدلاً من العودة إلى مترجم مع موجز جديد.
كما يغير المحادثة حول ما ينطوي عليه التعدد اللغوي فعليًا. وظيفة الوكالة هي بناء موقع بهيكل i18n صحيح، نص جيد في اللغة المصدر، وعملية مراجعة للترجمات. هذه محادثة ذات قيمة أعلى من "سنهتم بالترجمات بعد الانتهاء من النسخة الإنجليزية."
متى لا يزال من المنطقي استخدام المترجمين البشر
من المهم أن نكون صادقين بشأن هذا.
لنصوص التسويق التي تحتاج إلى حمل وزن عاطفي حقيقي في اللغة المستهدفة، سينتج المترجم البشري الماهر ناتجًا أفضل. الفرق مهم خصوصًا للحملات، بيانات تحديد موقع العلامة التجارية، وأي شيء حيث الصياغة نفسها هي المنتج.
للمحتوى المنظم بشدة (قانوني، طبي، مالي) المترجم البشري ذو الخبرة في المجال هو الخيار الصحيح، وغالبًا ما يكون مطلبًا للامتثال.
للمحتوى التحريري الطويل حيث يجب أن يشعر الصوت بأنه أصلي وليس مترجم، المراجعة البشرية أكثر من مجرد تمرير خفيف.
سير العمل الموضح هنا مناسب أكثر لنصوص الواجهة، محتوى الصفحات، أوصاف المنتجات، التوثيق، ومواقع التسويق حيث الدقة وسلامة البنية أهم من الفروق الأسلوبية. هذا يغطي جزءًا كبيرًا مما تقدمه وكالة صغيرة فعليًا.
البدء
الطبقة المجانية من PolyLingo تشمل 50000 رمز شهريًا بدون الحاجة إلى بطاقة ائتمان. لوكالة صغيرة، هذا يغطي كمية كبيرة من المحتوى قبل الحاجة للتفكير في خطة مدفوعة.
واجهة برمجة التطبيقات تقبل النص العادي، Markdown، JSON، وHTML. المترجم بدون كود في لوحة التحكم يتعامل مع الوظائف الفردية بدون لمس API على الإطلاق، وهو مفيد لجلسات مراجعة العميل حيث تريد عرض الناتج المترجم بدون بناء أي شيء أولًا.