🧖🏼 🧑🏼‍🤝‍🧑🏻 🉑 20 परियोजनाओं, 20 भाषाओं, कल की समय सीमा। भाग 3 🐰 ⛴️ 🤞🏼

सर्ज + स्मार्टकाट एकीकरण पर अंतिम लेख। इस लेख में, मैं आपको बताऊंगा कि कैसे हम सर्ज को पूरी कंपनी में स्केल करते हैं, 4 गैर-मानक एकीकरण पर विचार करते हैं और एक बोनस के रूप में, 2 सुविधाओं के बारे में बात करते हैं जो आपके जीवन को आसान बना सकते हैं।

पिछले लेख:

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

scalability

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

एकीकरण के विकल्प

एक रिपॉजिटरी में भाषाओं के दो सेट

सबसे सरल मामले से शुरू करते हैं। कल्पना करें कि आपके भंडार में संसाधन फ़ाइलों के कई सेट हैं। उदाहरण के लिए, क्लाइंट स्ट्रिंग्स और एप्लिकेशन API को एक ही रिपॉजिटरी में संग्रहीत किया जाता है, लेकिन विभिन्न निर्देशिकाओं में। क्लाइंट का 20 भाषाओं में अनुवाद किया जाता है, एपीआई 6 में।

उद्देश्य : प्रत्येक निर्देशिका में अनुवाद की एक स्वतंत्र आपूर्ति को व्यवस्थित करना।
समाधान :

स्मार्टकैट में 2 परियोजनाएं स्थापित करें: 6 भाषाओं में और 20 में।
स्थानीयकरण सर्वर पर 2 प्रोजेक्ट सेट करें।
पहली परियोजना में, हमारे $ unmerged_branch_mask = '^ (TranslateAPI-)' को प्रोजेक्ट 1.cfg फ़ाइल में जोड़ें ; # प्रक्रिया इस मास्क से मेल खाती अनमैरिड ब्रांच की है , जहाँ " ट्रांसएपीआई- " शाखा का नाम उपसर्ग है। उपसर्ग सर्ज को इंगित करेगा कि इस शाखा को एपीआई निर्देशिका में अनुवाद की आवश्यकता है।
Project1.serge.tmpl फ़ाइल में, source_dir पैरामीटर में API निर्देशिका में संसाधन फ़ाइलों के लिए पथ निर्दिष्ट करें।
इसी प्रकार, project2.cfg फ़ाइल में दूसरी परियोजना के लिए लाइन को हमारे $ unmerged_branch_mask = '^ (TranslateCLIENT-)' में जोड़ें; # इस मुखौटे से मेल खाने वाली शाखाओं की प्रक्रिया नहीं होती है , जहां " ट्रांसलसेंट " इस परियोजना की शाखाओं के लिए उपसर्ग है। उपसर्ग सर्ज को इंगित करेगा कि इस शाखा को क्लाइंट निर्देशिका में अनुवाद की आवश्यकता है।
Project2.serge.tmpl फ़ाइल में, source_dir पैरामीटर में CLIENT निर्देशिका में संसाधन फ़ाइलों के लिए पथ निर्दिष्ट करें।

कृपया ध्यान दें कि एक भंडार के लिए कॉन्फ़िगर की गई सभी परियोजनाओं के बीच उपसर्ग अद्वितीय होना चाहिए।

कुल मिलाकर, हमारे पास स्मार्टकैट में 2 परियोजनाएं और स्थानीयकरण सर्वर पर 2 संबंधित परियोजनाएं हैं। दोनों परियोजना Gitlab में एक ही भंडार को देखते हैं, लेकिन अलग-अलग निर्देशिकाओं में। सर्ग, शाखा उपसर्ग का उपयोग करते हुए, समझता है कि अनुवाद के लिए उसे किन लाइनों को भेजने की आवश्यकता है। अंतर की गणना करने के लिए, उसी आधार-अनुवाद शाखा का उपयोग किया जाता है।

स्थानीयकरण स्वैगर

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

समाधान : myproject.tmpl.serge फ़ाइल में, डेटा ऑब्जेक्ट को पार्सर ऑब्जेक्ट में जोड़ें और इसमें उन फ़ील्ड्स को सूचीबद्ध करें, जिनका मूल्य निकाला जाना चाहिए और अनुवाद के लिए भेजा जाना चाहिए:

parser { plugin parse_json data { path_matches \/(summary|description)$ } }

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

 parser { plugin parse_json data { path_matches ^\/legal\..* } }

कानूनी अनुवाद की सूक्ष्मता

एक और दिलचस्प मामला। हमारे पास एक कानूनी दस्तावेज है, जिसकी शर्तें अलग-अलग देशों में अलग-अलग हैं। लेकिन, फिर भी, यह एक अनुप्रयोग है और संसाधन फ़ाइलें एक ही निर्देशिका में हैं।

उद्देश्य : कई दस्तावेजों का अनुवाद करने के लिए एक परियोजना के ढांचे में, प्रत्येक दस्तावेज़ को एक विशिष्ट भाषा में अनुवाद किया जाना चाहिए।

क्या किया गया है :

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

 callback_plugins { :feature_branch { plugin feature_branch data { master_job job.base-translate } } :limit_languages { plugin limit_languages data { # all rules are processed top to bottom; each rule can add or remove languages # so the most priority rules are placed at the bottom if { # by default, don't localize file_matches . then { exclude_all_languages YES } } if { file_matches de-au\/ then { include_languages de-AT } } if { file_matches li-LI\/ then { include_languages li } } if { file_matches pt\/ then { include_languages pt-BR } } if { file_matches zh-Hans\/ then { include_languages zh-Hans } } # and so on.. } }

डेटाबेस में पंक्तियों को संग्रहीत करते समय स्थानीयकरण

हमारे सिस्टम में कोड का एक हिस्सा है जो डेटाबेस में अनुवाद को संग्रहीत करता है, और कई कारणों से यह रिपॉजिटरी में संसाधन फ़ाइलों में नहीं जा सकता है। हालाँकि, हमें अनुवाद जल्दी और स्वचालित रूप से वितरित करने में सक्षम होना चाहिए।

कार्य : पंक्तियों को रिपॉजिटरी में संग्रहीत नहीं किया जाता है, लेकिन डेटाबेस में निरंतर स्थानीयकरण की प्रक्रिया को व्यवस्थित करें।

समाधान :

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

बोनस सुविधाएँ

चेतावनी

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

रिपॉजिटरी में सभी अनुवादों की उपलब्धता पर निर्माण करने का निर्णय लिया गया और, यदि वे पूरी तरह से तैयार हैं, तो कॉरपोरेट मैसेंजर पर सूचनाएं भेजें, हमारे मामले में, Google चैट।

कार्य : रिपॉजिटरी में अलर्ट व्यवस्थित करें, जहां 8 टीमें प्रतिबद्ध हो सकती हैं, तकनीकी प्रलेखन विभाग के चैनल में सभी अलर्ट डुप्लिकेट करें।

समाधान :

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

सीआई

 check-translations: stage: check-translations image: node:8.14.0 tags: - devops script: - chmod +x ./notification.sh - ./notification.sh only: - base-translate - /^translate.*$/ when: always

अलर्ट स्क्रिप्ट

 #!/bin/bash hangouts(){ curl -X POST --max-time 180 -H "Content-Type: application/json; charset=UTF-8" --data "{ \"cards\": [{\"header\": {\"title\": \"LOCALIZATION IS READY\",\"subtitle\": \"REPOSITORY NAME\",\"imageUrl\": \"https://avatanplus.com/files/resources/mid/5775880ee27f8155a31b7a50.png\"},\"sections\": [{\"widgets\": [{\"keyValue\": {\"topLabel\": \"Translation is finished in the branch\",\"content\": \"$1\"}}]},{\"widgets\": [{\"buttons\": [{\"textButton\": {\"text\": \"SEE COMMIT\",\"onClick\": {\"openLink\": {\"url\": \"https://gitlab.loc/common/publisher-client/commit/$2\"}}}}]}]}]}]}" "$3" || true } cd app/translations if echo "$CI_COMMIT_REF_NAME" | grep "commandname1"; then grep -rl '\:\s\"\"' *.json >> result.file if [ -s network.file ]; then echo "Translations are not ready"; cat result.file else hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_COMMAND_NAME_1 hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_DOC fi fi if echo "$CI_COMMIT_REF_NAME" | grep "commandname2"; then grep -rl '\:\s\"\"' *.json >> result.file if [ -s result.file ]; then echo "Translations are not ready"; cat result.file else hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_COMMAND_NAME_2 hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_DOC fi fi ... if echo "$CI_COMMIT_REF_NAME" | grep "commandname8"; then grep -rl '\:\s\"\"' *.json >> result.file if [ -s result.file ]; then echo "Translations are not ready"; cat result.file else hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_COMMAND_NAME_8 hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_DOC fi fi

स्मार्टकैट एपीआई के माध्यम से अनुवादक असाइनमेंट

जब हमारे अनुवाद के लिए सभी शाखाओं को निर्दिष्ट करने का समय आता है तो यह हमारे स्थानीयकरण प्रबंधक की तरह दिखता है।

औसतन, हमारे काम में हर दिन 10 से अधिक शाखाएँ होती हैं। स्मार्टकैट में, प्रत्येक भाषा जोड़ी एक अलग दस्तावेज़ है, और अनुवादकों को ऐसे प्रत्येक दस्तावेज़ को सौंपा जाना चाहिए। मैन्युअल रूप से। कल्पना करें: हर दिन 40-60 नियुक्तियां। इस प्रक्रिया को सरल बनाने के लिए, हमने एपीआई के माध्यम से एक नियुक्ति की, और इसे पाइपलाइन में भी रखा। यह नौकरी बटन द्वारा लॉन्च की गई है। एक वाजिब सवाल: ट्रांसफ़र भेजते समय असाइनमेंट को ऑटोमैटिक क्यों नहीं बनाया जाए, और स्मार्टकैट प्लगइन में मेथड कॉल न करें, न कि पाइपलाइन में?

इस निर्णय के कई कारण हैं:

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

समाधान: जब स्थानीयकरण प्रबंधक मानता है कि इस शाखा में लाइनें अनुवाद के लिए तैयार हैं, तो वह गीतालाब में एक बटन दबाती है। अनुवादकों की पूरी टीम को इस शाखा को सौंपा गया है। कार्य अनुवादक द्वारा लिया जाता है जिसने पहले प्रतिक्रिया दी थी।

सीआई

 assignee: stage: assignee image: node:8.14.0 tags: - devops script: - chmod +x ./assignee.sh - ./assignee.sh only: - base-translate - /^translate.*$/ - assignee when: manual

असाइनमेंट स्क्रिप्ट

 #!/bin/bash if echo "$CI_COMMIT_REF_NAME" | grep "translate-"; then node -pe "JSON.parse(process.argv[1]).documents.forEach(function(elem){ if(elem.name.indexOf(\"$CI_COMMIT_REF_NAME\") !== -1) { console.log(elem.id) } });" "$(curl -XGET -H "Authorization: Basic $SMARTCAT_API_KEY" -H "Content-type: application/json" "https://smartcat.ai/api/integration/v1/project/$SMARTCAT_PROJECT_ID")" >> documents fi sed '$d' documents > documents.list while read LINE; do bash -c "curl -XPOST -H 'Authorization: Basic $SMARTCAT_API_KEY' -H "Content-type:application/json" -d '{"documentIds":[\""$LINE"\"],"stageNumber": 1}' 'https://smartcat.ai/api/integration/v1/document/assignFromMyTeam'";done < documents.list

यह निरंतर स्थानीयकरणों को एकीकृत और कॉन्फ़िगर करने पर लेखों की मेरी श्रृंखला को समाप्त करता है। मुझे आपके किसी भी प्रश्न का उत्तर देने में खुशी होगी।

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

scalability

एकीकरण के विकल्प

एक रिपॉजिटरी में भाषाओं के दो सेट

स्थानीयकरण स्वैगर

कानूनी अनुवाद की सूक्ष्मता

डेटाबेस में पंक्तियों को संग्रहीत करते समय स्थानीयकरण

बोनस सुविधाएँ

चेतावनी

सीआई

अलर्ट स्क्रिप्ट

स्मार्टकैट एपीआई के माध्यम से अनुवादक असाइनमेंट

सीआई

असाइनमेंट स्क्रिप्ट

More articles: