كيف تحددون نطاق دمج الترجمة في تطبيق أعمال قائم
خططوا للترجمة داخل تطبيق أعمالكم. حددوا المحتوى واللغات والمراجعة وقواعد البيانات ومعالجة الأخطاء واختبارات القبول قبل طلب عرض سعر.
ابدأوا بمهمة واحدة كاملة يحتاج فريقكم إلى إنجازها بلغة أخرى. ثم حددوا كيف تندرج الترجمة ضمن تلك المهمة. فهذا يمنح مورّد البرمجيات أساسًا أوضح للتقدير من مجرد طلب إضافة زر للترجمة.
ينبغي أن يغطي النطاق النص والأشخاص والبيانات والنتيجة. وينبغي أن يوضح أيضًا ما يحدث عندما تفشل الترجمة. استخدموا الخطوات التالية لإعداد هذا النطاق قبل اختيار نهج تقني.
اختاروا مسار عمل واحدًا للإصدار الأول
اكتبوا من أين يأتي النص المصدر وإلى أين يجب أن تذهب الترجمة المعتمدة. على سبيل المثال، قد يحتاج موظف الدعم إلى قراءة رسالة واردة وإعداد رد بلغة العميل. هذا متطلب توضيحي، وليس تقريرًا عن تثبيت لدى Vavus.
اذكروا كل خطوة: فتح الرسالة، وطلب الترجمة، وقراءة النص المصدر بجانب النتيجة، وتعديل الرد، واعتماده للإرسال. وقرروا ما إذا كانت الترجمة تبدأ تلقائيًا أم فقط بعد أن يختارها الموظف.
اجعلوا الإصدار الأول صغيرًا. فاختبار شاشة واحدة ومهمة عمل واحدة واضحة أسهل من اختبار كل حقول النص في التطبيق.
حددوا احتياجات المحتوى واللغات
أعدّوا قائمة بالحقول التي تحتاج إلى ترجمة. وافصلوا بين التسميات القصيرة والنص الحر والمستندات والكلام. فقد يتطلب كل منها معالجة واختبارات مختلفة. واذكروا أيضًا الحقول التي يجب أن تبقى دون تغيير، مثل أرقام الطلبات ورموز المنتجات.
حددوا لغات المصدر واللغات الهدف، بما في ذلك أي متغيرات إقليمية. وسجلوا الطول المعتاد للنص والحجم اليومي المتوقع. واسألوا عن تركيبات اللغات وتنسيقات الإدخال التي تدعمها الخدمة المقترحة.
قد يكون السياق مهمًا في النصوص القصيرة. فعلى سبيل المثال، تدعم واجهة API النصية من DeepL معاملًا للسياق يمكن أن يؤثر في الترجمة دون أن يُترجَم السياق نفسه. وتذكر وثائقها أيضًا أن إدخالات النص المنفصلة في الطلب الواحد لا تتشارك السياق. [1] ينبغي أن يوضح نطاقكم مصدر السياق المفيد.
حددوا المصطلحات والمراجعة البشرية
اجمعوا المصطلحات التي تستخدمها شركتكم كثيرًا. وأدرجوا الترجمات المفضلة وأسماء المنتجات والكلمات التي يجب أن تبقى دون تغيير. وكلّفوا شخصًا واحدًا بتحديث هذه القائمة.
تدعم بعض خدمات الترجمة مسارد المصطلحات. وتصف Google Cloud Translation مسردها بأنه قاموس مخصص لضمان اتساق المصطلحات الخاصة بالمجال. [2] تحققوا من هذه الميزة لأزواج اللغات المحددة لديكم وللخدمة التي اخترتموها. فوجود مسرد لا يثبت أن الرسالة كلها صحيحة.
قرروا أي المخرجات تحتاج إلى مراجع لغوي مؤهل. وامنحوا المراجع إمكانية الوصول إلى النص الأصلي. وضعوا خطوة اعتماد واضحة قبل إرسال النصوص الموجهة إلى العملاء أو نشرها.
ضعوا قواعد للبيانات والوصول
صِفوا المعلومات التي يتعامل معها مسار العمل. واستخدموا أمثلة مصطنعة في الاختبارات الأولى. وتجنبوا نسخ سجلات عملاء حقيقية إلى تجربة لمجرد معرفة ما إذا كان زر ما يعمل.
اسألوا أين ستتم معالجة النص، وما الذي سيخزنه التطبيق، ومن يمكنه قراءته، ومتى سيُحذف. وأدرجوا السجلات والنسخ الاحتياطية في هذا النقاش. وتأكدوا من الشروط الحالية لمقدّم الخدمة ومن أدوات التحكم المتاحة في الخطة المختارة.
الواجهة المخصصة لا تجعل بحد ذاتها خدمة ترجمة خارجية خاصة أو تعمل دون اتصال. إذا كان مشروعكم يتطلب معالجة محلية، فاذكروا هذا المتطلب منذ البداية واختبروا تدفق البيانات بالكامل في ضوئه.
خططوا للتأخير والأخطاء
اكتبوا زمن الاستجابة المتوقع والإجراء الذي يجب أن يتخذه الموظفون إذا لم تكن الخدمة متاحة. ينبغي أن يعرض التطبيق حالة واضحة، مثل «قيد الانتظار» أو «جاهز للمراجعة» أو «فشل». واحتفظوا بالنص الأصلي.
اطلبوا من المطوّر أن يميّز بين الأعطال المؤقتة والأخطاء التي تتطلب تغييرًا. فعلى سبيل المثال، توثّق DeepL إعادة المحاولة بعد مهلة في حالة أخطاء تجاوز حد الطلبات، بينما يتطلب نفاد الحصة استجابة مختلفة. [3] ولا ينبغي أن تُنشئ الطلبات المتكررة إجراءات عمل مكررة، مثل إرسال الرد نفسه مرتين.
اتفقوا على تنبيهات الاستخدام وعلى الجهة المسؤولة عن الدعم. وأدرجوا رسوم الخدمة والصيانة والتغييرات المستقبلية عند مقارنة تكاليف المشروع.
اكتبوا اختبارات القبول قبل التطوير
اختاروا أمثلة تمثيلية لكل زوج لغات مطلوب. وأدرجوا رسائل طويلة وأحرفًا غير مألوفة وحقولًا ناقصة ومصطلحات من قائمتكم المعتمدة. واختبروا المهمة بالكامل، من السجل المصدر إلى النتيجة المحفوظة أو المرسلة.
ضعوا معايير نجاح يمكن للأشخاص التحقق منها: تبقى رموز المنتجات دون تغيير، ولا يمكن إرسال ترجمة غير معتمدة، ويظهر الطلب الفاشل بوضوح، ويستطيع المراجع العودة إلى المصدر. واطلبوا من مراجع مؤهل تقييم المعنى والأسلوب. وسجلوا العيوب وكرروا الاختبارات نفسها بعد التغييرات.
أعدّوا طلب عرض سعر واضحًا
أرسلوا مسار العمل ونماذج الحقول وأزواج اللغات والحجم التقديري وقواعد البيانات واختبارات القبول. وحددوا لكل بند ما إذا كان مطلوبًا عند الإطلاق أم مناسبًا لإصدار لاحق. واطلبوا الافتراضات والاستثناءات كتابيًا.
تقدم Vavus تحديدًا مكتوبًا للنطاق في المشاريع المخصصة. [4] استخدموا صفحة عرض السعر لوصف تطبيقكم الحالي والمهمة التي تريدون تحسينها. وينبغي تأكيد الدمج والنشر والاختبار المقترحة في نطاق مشروعكم.