20 परियोजनाओं, 20 भाषाओं, कल की समय सीमा

कल्पना करें: आपके पास 100 से अधिक लोगों की कुल 7 विकास टीमें हैं। उन्होंने एक साथ 13 आवेदन देखे। 20 रिपॉजिटरी में काम किया जाता है।

सभी अनुप्रयोगों का अनुवाद करने की आवश्यकता है। 6 भाषाओं में कुछ, 20 में कुछ। और कुछ 13 में, लेकिन यह भाषाओं का एक बिल्कुल अलग सेट है, यह पिछले 20 में शामिल नहीं है।

सभी के पास एक अलग स्टैक है, अलग-अलग लाइन प्रारूपों के परिणामस्वरूप: जेएस, जोंसन, टीएस, यामल या वाईएमएल। और कुछ अभी भी डेटाबेस में अपने ग्रंथों को रखते हैं।

आप एजाइल पर काम करते हैं: दैनिक मूल्य वितरण, दो सप्ताह के स्प्रिंट। DoR में सभी आवश्यक अनुवाद शामिल हैं। ठीक है, निश्चित रूप से, परीक्षण के लिए समय देने के लिए अनुवादों को कल की आवश्यकता थी।


तकनीकी लेखकों का एक विभाग है। तकनीकी लेखक कौन है? यह एक व्यक्ति है जो बाहरी प्रलेखन, कभी-कभी आंतरिक लिखता है। उन सभी प्रकार के ग्रंथों को लिखता है जिन्हें उपयोगकर्ता या भागीदार देख सकते हैं: फ्रंट-एंड टेक्स्ट, संदेश पाठ, एपीआई प्रतिक्रियाएं, त्रुटियां। विकास की प्रक्रिया को प्रौद्योगिकी और व्यावसायिक तर्क में डूबा हुआ माना जाता है। और आवेदन के लिए अनुवाद का समय पर वितरण प्रदान करता है।

कॉपीराइटर-अनुवादक और स्थानीयकरण प्रबंधक की स्थिति भी है। यह एक ऐसा व्यक्ति है जो अंग्रेजी में सभी ग्रंथों का निर्माण करता है, और अनुवाद की निरंतरता पर भी नज़र रखता है, अनुवादकों की नियुक्ति करता है और सभी संबंधित समस्याओं को हल करता है।
ध्यान दें, सवाल यह है: कितने तकनीकी विनिर्देश, कॉपीराइटर और स्थानीयकरण प्रबंधक आवश्यक हैं ताकि विकास में बाधा न हो और पूरे तकनीकी विभाग को चोट न पहुंचे?

हमारे मामले में, हमने 4 तकनीकी सेवाओं और 1 कॉपीराइटर-स्थानीयकरण प्रबंधक का प्रबंधन किया। औसतन ट्रांसफ़र की डिलीवरी एक व्यावसायिक दिन के भीतर होती है और कभी भी तीन व्यावसायिक दिनों से अधिक नहीं होती है। मुझे आशा है कि आपको यह दिलचस्प लगेगा।

हम इसके लिए कैसे आए?

6 साल पहले हमने Google शीट और एक DB में काम किया था। यही है, अगर विकास प्रक्रिया के दौरान अनुवाद के लिए लाइनें दिखाई देती हैं, तो हमने उन्हें एक टैबलेट में कॉपी किया, और फिर उन्हें अनुवाद के लिए मेल द्वारा भेजा। जब अनुवाद तैयार हो गया, तो इसे मैन्युअल रूप से डेटाबेस में डाला गया। इस समाधान का एकमात्र प्लस यह है कि आपको नई लाइनें देखने के लिए एप्लिकेशन को फिर से बिछाने की आवश्यकता नहीं है। लेकिन अगर अनुवाद में कोई गलती है, तो यह वापस रोल करने के लिए काम नहीं करेगा। कोई अनुवाद स्मृति नहीं, कोई शब्दावली नहीं। अनुवाद की संगति टकटकी विधि द्वारा प्राप्त की जाती है।

पहला प्रयास

इस प्रक्रिया को स्वचालित करने के लिए पहला संस्करण इस तरह से देखा गया था: जब एक डेवलपर के पास लाइनें थीं, तो उसने उन्हें अनुवाद के लिए एक विशेष भंडार में एक नई शाखा में जोड़ा। फिर, उसी शाखा में, एक पाइपलाइन शुरू की गई, जिसने एपीआई द्वारा, अनुवाद के लिए सभी अलग-अलग लाइनों को भेजा। सच है, अनुवाद पहले से ही डेटाबेस में वापस जाने वाले थे, लेकिन यह एपीआई के माध्यम से बाहरी डेटाबेस से आंतरिक डेटाबेस तक लाइनों को लोड करने में विफल रहा।

ऐसे एकीकरण ने क्या दिया? एक कदम हटा दिया गया था, जहां तकनीकी लेखक को एक तालिका में सब कुछ इकट्ठा करने की आवश्यकता होती है, मैन्युअल रूप से भेजते हैं, और फिर प्राप्त किए गए अनुवादों को एप्लिकेशन और भाषाओं की संख्या से विभाजित करते हैं। इस मामले में, लाइनों को तुरंत अनुवाद के लिए उसी नाम की एक परियोजना के भाग के रूप में भेजा गया था, जिसके लिए उनका इरादा था। नतीजतन, तकनीकी लेखक को प्रत्येक आवेदन के लिए अभिलेखागार का एक सेट मिला, जिसके लिए काम किया गया था। इसने मैन्युअल श्रम की हिस्सेदारी को काफी कम कर दिया। इसके अलावा, प्रदाता की ओर से अनुवाद मेमोरी को लागू किया गया था। लेकिन इस समाधान ने कई कमियां भी बरकरार रखीं: डेटाबेस में पंक्तियों को संग्रहीत करने ने हमारी तरफ पूर्ण-पंक्ति प्रबंधन को अनुमति नहीं दी और, पहले की तरह, मैनुअल काम का एक बड़ा हिस्सा निहित किया।

दर्द और निरंतर स्थानीयकरण

निम्नलिखित एकीकरण ने डेवलपर्स के लिए बहुत सारे कष्ट लाए। यह मुझे लगता है कि जिन लोगों ने इसे पकड़ा है वे अभी भी "स्थानीयकरण" शब्द पर अपनी आँखें घुमा रहे हैं। सर्ज और स्मार्टकैट के साथ यह पहला एकीकरण था।



यहां यह बताना महत्वपूर्ण है कि सर्ज और स्मार्टकैट क्या हैं।

सर्ग एक उपयोगिता है जो गिट का समर्थन करती है। वह जानती है कि शाखा से आवश्यक लाइनें कैसे प्राप्त करें, उन्हें अनुवाद के लिए भेजें, और फिर उसी पंक्तियों के लिए उसी शाखा में अनुवाद वापस करें। हमें एक प्लगइन की भी आवश्यकता है जो कैट सिस्टम के एपीआई को कॉल करेगा जिसमें हम अनुवाद करते हैं। प्लगइन को सर्ज से नई लाइनें प्राप्त करनी चाहिए और सर्गे को तैयार अनुवाद वापस करना चाहिए।

स्मार्टकैट शब्दावली, अनुवाद स्मृति, प्लेसहोल्डर्स के समर्थन के साथ एक कैट सिस्टम है। इसके अलावा, स्मार्टकैट फ्रीलांसरों के साथ बस्तियों की प्रक्रिया को समुच्चय और सरल करता है, अनुवाद विक्रेताओं के कनेक्शन का समर्थन करता है।

इस चरण पर, हमने डेटाबेस से प्रोजेक्ट रिपॉजिटरी में पंक्तियों को स्थानांतरित कर दिया। अब स्ट्रिंग्स को एप्लिकेशन रिपॉजिटरी से सीधे भेजा जाना था और वहां लौट आए।

यह माना जाता था कि यह इस तरह काम करेगा: डेवलपर को पता है कि उसने किस शाखा से अपनी सुविधा शाखा बनाई है, और इन दो शाखाओं के बीच संसाधन फ़ाइलों में अंतर ठीक उसी प्रकार है जिसका अनुवाद करने की आवश्यकता है। जब एक डेवलपर के पास अनुवाद के लिए लाइनों का एक सेट होता है, तो वह सर्ज कॉन्फ़िगरेशन के साथ अपनी शाखा में नौकरी शुरू करता है। सर्ज अलग-अलग गणना करता है, नई लाइनें निकालता है, प्लगइन को कॉल करता है और अनुवाद के लिए लाइनें भेजता है। जब अनुवाद तैयार हो जाते हैं, तो डेवलपर निम्नलिखित कार्य को कॉल करता है: वह पिछले चरण में बनाए गए सर्ज उदाहरण को दिखाता है, तैयार अनुवादों को प्राप्त करता है और उन्हें स्रोत शाखा में भेजता है।

समाधान अस्थिर हो गया था: सर्ज को हर बार पाइप लाइन के चालू होने के बाद खरोंच से उतारा नहीं जाता था, डेवलपर्स शाखाओं के बीच अंतर के बारे में नहीं सोचना चाहते थे, और स्मार्टकैट प्लगइन को अपडेट और सुधार की तत्काल आवश्यकता थी। नई लाइनें पहुंचाने की प्रक्रिया में घंटों लग सकते थे। और, अफसोस, यह हमेशा सफल नहीं रहा।

सैद्धांतिक रूप से, प्रक्रिया के सभी चरण स्वचालित थे, वास्तव में, रखरखाव, पाइपलाइन की शुरुआत से पहले अंतर की गणना करना और समस्या निवारण पूरी तरह से मैन्युअल रूप से एक ही कार्य करने में अधिक समय लेता था।

सुरंग के अंत में प्रकाश

अगस्त 2018 तक, हमने एकीकरण का वर्तमान संस्करण लॉन्च किया है। हमारे पास एक स्थानीयकरण सर्वर है। प्रत्येक रिपॉजिटरी के लिए सर्वर पर सर्ज का एक अलग उदाहरण है। सर्ज रिपॉजिटरी में सभी शाखाओं को स्कैन करता है, अनुवाद के लिए नई लाइनें भेजता है और मूल शाखाओं को समाप्त अनुवाद करता है। वर्तमान एकीकरण में, सब कुछ तेज और स्थिर है। अनुवाद के लिए एक शाखा बनाने के बाद, लाइनें 5-6 मिनट के भीतर स्मार्टकाट में दिखाई देती हैं। स्थानान्तरण की पुष्टि करने के बाद, प्रतिबद्धता समान रूप से होती है, 5-6 मिनट के भीतर। अनुवाद के लिए वितरण का समय केवल मानव कारक द्वारा सीमित है: अनुवादकों का कार्यभार, समय क्षेत्र और इतने पर अंतर।

निम्नलिखित लेखों में मैं आपको बताऊंगा कि सर्ग-स्मार्टकैट-गिटलैब एकीकरण को खरोंच से कैसे कॉन्फ़िगर किया जाए, और हमने विभिन्न गैर-मानक कार्यों को कैसे हल किया।
जारी रखा:
20 परियोजनाओं, 20 भाषाओं, कल की समय सीमा। भाग २
20 परियोजनाओं, 20 भाषाओं, कल की समय सीमा। भाग 3