20 مشروعًا ، 20 لغة ، الموعد النهائي أمس

تخيل: لديك 7 فرق تطوير تضم أكثر من 100 شخص. رأوا في وقت واحد 13 تطبيقا. يتم تنفيذ العمل في 20 مستودع.

جميع التطبيقات تحتاج إلى ترجمة. بعض اللغات بـ 6 لغات ، بعضها في 20. والبعض الآخر في 13 لغة ، لكن هذه مجموعة مختلفة تمامًا من اللغات ، فهي غير مدرجة في اللغات العشرين السابقة.

كل شخص لديه رصة مختلفة ، نتيجة لتنسيقات الخطوط المختلفة: js ، json ، ts ، yaml أو yml. وما زال البعض يحتفظ بنصوصهم في قاعدة البيانات.

أنت تعمل على Agile: تسليم القيمة اليومية ، سباق السرعة لمدة أسبوعين. DoR يشمل جميع الترجمات اللازمة. حسنًا ، بالطبع ، كانت هناك حاجة للترجمات أمس من أجل الحصول على وقت للاختبار.


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

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

في حالتنا ، تمكنا من 4 خدمات فنية ومدير توطين مؤلف واحد. يناسب تسليم التحويلات في المتوسط ​​يوم عمل واحد ولا يتجاوز ثلاثة أيام عمل. أتمنى أن تجدها مثيرة للاهتمام.

كيف وصلنا إلى هذا؟

قبل 6 سنوات عملنا في أوراق Google و DB. أي أنه أثناء ظهور خطوط عملية التطوير للترجمة ، قمنا بنسخها في لوحة ، ثم أرسلناها بالبريد إلى الترجمة. عندما كانت الترجمة جاهزة ، تم سكبها يدويًا في قاعدة البيانات. الإضافة الوحيدة لهذا الحل هي أنك لست بحاجة إلى إعادة وضع التطبيق لرؤية خطوط جديدة. ولكن إذا كان هناك خطأ في الترجمات ، فلن يعمل على التراجع. لا توجد ذاكرة ترجمة ، لا مسارد. يتم تحقيق اتساق الترجمات بواسطة طريقة النظرة.

المحاولة الأولى

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

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

ألم وتوطين مستمر

جلب التكامل التالي الكثير من المعاناة للمطورين. يبدو لي أن أولئك الذين اشتعلوا لا يزال لديهم عيونهم الوخز في كلمة "التعريب". كان هذا أول تكامل مع Serge و Smartcat.



من المهم هنا معرفة ماهية Serge و Smartcat.

سيرج هو الأداة التي تدعم بوابة. إنها تعرف كيفية الحصول على الأسطر اللازمة من الفرع وإرسالها للترجمة ، ثم إرجاع الترجمة لنفس الأسطر إلى الفرع نفسه فقط. نحتاج أيضًا إلى مكون إضافي يتصل بـ API لنظام CAT الذي نترجم فيه. يجب أن يتلقى المكون الإضافي خطوطًا جديدة من Serge ويعود إلى الترجمات الجاهزة إلى Serge.

Smartcat عبارة عن نظام CAT يوفر دعمًا لمسرد المصطلحات وذاكرة الترجمة والعناصر النائبة. أيضًا ، تقوم Smartcat بتجميع وتبسيط عملية التسوية مع المستقلين ، وتدعم اتصال بائعي الترجمة.

في هذه الخطوة ، قمنا بنقل الصفوف من قاعدة البيانات إلى مستودع المشروع. الآن يجب إرسال السلاسل مباشرة من مستودع التطبيق وإعادتها إلى هناك.

كان من المفترض أن يعمل هذا على النحو التالي: يعرف المطور من الفرع الذي أنشأه فرع الميزة الخاص به ، والفرق في ملفات الموارد بين هذين الفرعين هو بالضبط ما يجب ترجمته. عندما يكون لدى المطور مجموعة من الأسطر للترجمة ، يبدأ مهمة في فرعه باستخدام التكوين Serge. يحسب سيرج الفرق ، ويستخرج خطوط جديدة ، ويدعو البرنامج المساعد ويرسل الخطوط للترجمة. عندما تكون الترجمات جاهزة ، يقوم المطور بالاتصال بالمهمة التالية: يقوم بنشر مثيل Serge الذي تم إنشاؤه في الخطوة السابقة ، ويتلقى الترجمات النهائية ويلزمها بالفرع المصدر.

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

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

ضوء في نهاية النفق

بحلول أغسطس 2018 ، أطلقنا الإصدار الحالي من التكامل. لدينا خادم الترجمة. على الخادم لكل مستودع يوجد مثيل منفصل لـ Serge. يفحص سيرج جميع الفروع في المستودع ، ويرسل أسطر جديدة للترجمة ويلتزم الترجمات النهائية إلى الفروع الأصلية. في التكامل الحالي ، كل شيء سريع ومستقر. بعد إنشاء فرع للترجمات ، تظهر الخطوط في Smartcat خلال 5-6 دقائق. بعد تأكيد عمليات النقل ، يحدث الالتزام بالمثل ، خلال نفس 5-6 دقائق. يقتصر وقت التسليم للترجمات فقط على العامل البشري: عبء العمل على المترجمين ، والفرق في المناطق الزمنية وما إلى ذلك.

في المقالات التالية ، سأخبرك بكيفية تكوين تكامل Serge-Smartcat-Gitlab من البداية ، وكيف حللنا العديد من المهام غير القياسية.
تابع:
20 مشروعًا ، 20 لغة ، الموعد النهائي أمس. الجزء 2
20 مشروعًا ، 20 لغة ، الموعد النهائي أمس. الجزء 3