मौजूदा व्यावसायिक ऐप में अनुवाद एकीकरण का दायरा कैसे तय करें
अपने व्यावसायिक ऐप में अनुवाद की योजना बनाइए। कोटेशन माँगने से पहले सामग्री, भाषाएँ, समीक्षा, डेटा नियम, विफलता से निपटने का तरीका और स्वीकृति परीक्षण तय कीजिए।
किसी एक पूरे काम से शुरुआत कीजिए जो आपकी टीम को किसी दूसरी भाषा में करना होता है। फिर तय कीजिए कि अनुवाद उस काम में कैसे फिट होता है। इससे सॉफ़्टवेयर आपूर्तिकर्ता को अनुमान लगाने के लिए, सिर्फ़ एक अनुवाद बटन जोड़ने के अनुरोध की तुलना में, ज़्यादा स्पष्ट आधार मिलता है।
दायरे में टेक्स्ट, लोग, डेटा और परिणाम शामिल होने चाहिए। इसमें यह भी बताया जाना चाहिए कि अनुवाद विफल होने पर क्या होता है। कोई तकनीकी तरीका चुनने से पहले यह दायरा तैयार करने के लिए नीचे दिए गए चरणों का इस्तेमाल कीजिए।
पहली रिलीज़ के लिए एक कार्यप्रवाह चुनिए
लिखिए कि स्रोत टेक्स्ट कहाँ से आता है और स्वीकृत अनुवाद को कहाँ जाना है। उदाहरण के लिए, सपोर्ट कर्मचारी को आया हुआ संदेश पढ़कर ग्राहक की भाषा में जवाब तैयार करना पड़ सकता है। यह उदाहरण के तौर पर दी गई ज़रूरत है, किसी Vavus इंस्टॉलेशन की रिपोर्ट नहीं।
हर चरण की सूची बनाइए: संदेश खोलना, अनुवाद का अनुरोध करना, परिणाम के साथ-साथ स्रोत पढ़ना, जवाब संपादित करना और उसे भेजने के लिए स्वीकृत करना। तय कीजिए कि अनुवाद अपने-आप शुरू होगा या तभी जब कोई कर्मचारी उसे चुने।
पहली रिलीज़ छोटी रखिए। किसी ऐप्लिकेशन के हर टेक्स्ट फ़ील्ड की तुलना में एक स्क्रीन और एक स्पष्ट व्यावसायिक काम का परीक्षण करना आसान है।
सामग्री और भाषा संबंधी ज़रूरतें पहचानिए
उन फ़ील्ड की सूची बनाइए जिनका अनुवाद ज़रूरी है। छोटे लेबल, फ़्री टेक्स्ट, दस्तावेज़ और बोली गई सामग्री को अलग-अलग रखिए। इनके लिए अलग प्रोसेसिंग और परीक्षण की ज़रूरत हो सकती है। उन फ़ील्ड की सूची भी बनाइए जिन्हें बिना बदलाव के रहना चाहिए, जैसे ऑर्डर नंबर और प्रोडक्ट कोड।
स्रोत और लक्ष्य भाषाएँ तय कीजिए, क्षेत्रीय रूपों सहित। टेक्स्ट की सामान्य लंबाई और अनुमानित दैनिक मात्रा दर्ज कीजिए। पूछिए कि प्रस्तावित सेवा किन भाषा संयोजनों और इनपुट फ़ॉर्मैट को सपोर्ट करती है।
छोटे टेक्स्ट में संदर्भ मायने रख सकता है। उदाहरण के लिए, DeepL का टेक्स्ट API एक context पैरामीटर सपोर्ट करता है, जो संदर्भ का खुद अनुवाद किए बिना अनुवाद को प्रभावित कर सकता है। इसके दस्तावेज़ यह भी बताते हैं कि एक ही अनुरोध की अलग-अलग टेक्स्ट प्रविष्टियाँ आपस में संदर्भ साझा नहीं करतीं। [1] आपके दायरे में बताया जाना चाहिए कि उपयोगी संदर्भ कहाँ से आएगा।
शब्दावली और मानवीय समीक्षा तय कीजिए
वे शब्द इकट्ठा कीजिए जिन्हें आपका व्यवसाय अक्सर इस्तेमाल करता है। पसंदीदा अनुवाद, उत्पादों के नाम और ऐसे शब्द शामिल कीजिए जिन्हें बिना बदलाव के रहना चाहिए। इस सूची को अद्यतन रखने की ज़िम्मेदारी एक व्यक्ति को दीजिए।
कुछ अनुवाद सेवाएँ ग्लॉसरी सपोर्ट करती हैं। Google Cloud Translation अपनी ग्लॉसरी को किसी खास क्षेत्र की शब्दावली को एकरूप रखने वाला कस्टम शब्दकोश बताता है। [2] अपने सटीक भाषा जोड़ों और चुनी गई सेवा के लिए यह सुविधा जाँचिए। ग्लॉसरी से यह साबित नहीं होता कि पूरा संदेश सही है।
तय कीजिए कि किन आउटपुट के लिए योग्य भाषा समीक्षक की ज़रूरत है। समीक्षक को मूल टेक्स्ट तक पहुँच दीजिए। ग्राहकों को दिखने वाला टेक्स्ट भेजने या प्रकाशित करने से पहले स्वीकृति का एक स्पष्ट चरण तय कीजिए।
डेटा और पहुँच के नियम तय कीजिए
बताइए कि कार्यप्रवाह किस जानकारी को संभालता है। शुरुआती परीक्षणों में काल्पनिक उदाहरण इस्तेमाल कीजिए। सिर्फ़ यह देखने के लिए कि कोई बटन काम करता है या नहीं, असली ग्राहक रिकॉर्ड ट्रायल में कॉपी करने से बचिए।
पूछिए कि टेक्स्ट कहाँ प्रोसेस होगा, ऐप्लिकेशन क्या स्टोर करेगा, उसे कौन पढ़ सकेगा और उसे कब हटाया जाएगा। इस चर्चा में लॉग और बैकअप भी शामिल कीजिए। प्रदाता की मौजूदा शर्तों और चुने गए प्लान में उपलब्ध नियंत्रणों की पुष्टि कीजिए।
कोई कस्टम इंटरफ़ेस अपने-आप में किसी बाहरी अनुवाद सेवा को निजी या ऑफ़लाइन नहीं बना देता। अगर आपकी परियोजना में लोकल प्रोसेसिंग ज़रूरी है, तो यह ज़रूरत शुरुआत में ही बताइए और पूरे डेटा प्रवाह को उसी कसौटी पर परखिए।
देरी और त्रुटियों के लिए योजना बनाइए
अपेक्षित प्रतिक्रिया समय लिखिए और यह भी कि सेवा उपलब्ध न होने पर स्टाफ़ को क्या करना चाहिए। ऐप्लिकेशन को एक स्पष्ट स्थिति दिखानी चाहिए, जैसे प्रतीक्षा में, समीक्षा के लिए तैयार या विफल। मूल टेक्स्ट सुरक्षित रखिए।
डेवलपर से कहिए कि वह अस्थायी विफलताओं और बदलाव की माँग करने वाली त्रुटियों में फ़र्क करे। उदाहरण के लिए, DeepL रेट-लिमिट त्रुटियों के लिए देरी से दोबारा कोशिश करने का तरीका बताता है, जबकि कोटा खत्म होने पर अलग प्रतिक्रिया चाहिए। [3] दोहराए गए अनुरोधों से व्यावसायिक कार्रवाइयाँ दोहराई नहीं जानी चाहिए, जैसे एक ही जवाब दो बार भेजना।
उपयोग से जुड़े अलर्ट पर और इस पर सहमति बनाइए कि सपोर्ट की ज़िम्मेदारी किसकी होगी। परियोजना की लागत की तुलना करते समय सेवा शुल्क, रखरखाव और भविष्य के बदलाव भी शामिल कीजिए।
विकास से पहले स्वीकृति परीक्षण लिखिए
हर ज़रूरी भाषा जोड़े के लिए प्रतिनिधि उदाहरण चुनिए। लंबे संदेश, असामान्य वर्ण, खाली फ़ील्ड और अपनी स्वीकृत सूची के शब्द शामिल कीजिए। स्रोत रिकॉर्ड से लेकर सेव किए गए या भेजे गए परिणाम तक, पूरे काम का परीक्षण कीजिए।
ऐसे पास मानदंड तय कीजिए जिन्हें लोग जाँच सकें: प्रोडक्ट कोड नहीं बदलते, बिना स्वीकृति वाला अनुवाद भेजा नहीं जा सकता, विफल अनुरोध दिखाई देता है और समीक्षक स्रोत पर वापस जा सकता है। किसी योग्य समीक्षक से अर्थ और लहजे का आकलन करवाइए। खामियाँ दर्ज कीजिए और बदलावों के बाद वही परीक्षण दोहराइए।
कोटेशन के लिए एक स्पष्ट अनुरोध तैयार कीजिए
कार्यप्रवाह, नमूना फ़ील्ड, भाषा जोड़े, अनुमानित मात्रा, डेटा नियम और स्वीकृति परीक्षण भेजिए। हर मद पर निशान लगाइए कि वह लॉन्च के लिए ज़रूरी है या किसी बाद की रिलीज़ के लिए ठीक है। मान्यताएँ और बाहर रखी गई चीज़ें लिखित में माँगिए।
Vavus कस्टम परियोजनाओं के लिए लिखित रूप में दायरा तय करने की सेवा देता है। [4] कोटेशन पेज पर अपने मौजूदा ऐप्लिकेशन और उस काम के बारे में बताइए जिसे आप बेहतर बनाना चाहते हैं। प्रस्तावित एकीकरण, डिप्लॉयमेंट और परीक्षण की पुष्टि आपकी परियोजना के दायरे में होनी चाहिए।