Youtube और Instagram की तरह: पायथन एप्लिकेशन का अंतर्राष्ट्रीयकरण और स्थानीयकरण

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

परिचय

यह अंतर्राष्ट्रीयकरण (i18n) अजगर अनुप्रयोगों के लिए एक छोटा गाइड है। यह गाइड अजगर विकास के अनुभव के साथ सभी प्रोग्रामर के लिए दिलचस्प होगा। एक लेख पढ़ने में 10-15 मिनट लगेंगे।

हम अजगर भाषा में शामिल अच्छी तरह से परीक्षण किए गए गेटटेक्स्ट टूल का उपयोग करेंगे।

शुरुआत करने के लिए, हम समझेंगे कि अंतर्राष्ट्रीयकरण क्या है:

अंतर्राष्ट्रीयकरण (I18N) विभिन्न देशों और क्षेत्रों की भाषाओं के लिए एक आवेदन को स्वीकार करने की प्रक्रिया है, जिसमें इसे विकसित किया गया था।

लेकिन एक व्यापक अवधारणा भी है:

स्थानीयकरण (L10N) एक विशिष्ट क्षेत्र या भाषा में एक दिए गए स्थान और अनुवाद पाठ के लिए विशिष्ट घटकों को जोड़कर एक अंतरराष्ट्रीयकृत अनुप्रयोग को अपनाने की प्रक्रिया है।

स्थानीयकरण का अर्थ है अनुवाद:

• दिनांक और समय प्रारूप;
• संख्या प्रारूप;
• समय क्षेत्र
• एक कैलेंडर
• मुद्रा अभ्यावेदन;
• कर / वैट;
• तापमान और अन्य उपाय;
• ज़िप कोड, टेलीफोन;
• पता स्वरूपण;
• बंदोबस्त का कोड।

स्थानीयकरण सामग्री का दूसरी भाषा में अनुवाद करने से परे जाता है। सांस्कृतिक और कार्यात्मक पैरामीटर हैं जिन्हें ध्यान देने की आवश्यकता है। उदाहरण के लिए, उत्तरी अमेरिका में दिनांक प्रारूप MM / DD / YYYY है, लेकिन अधिकांश एशियाई देशों में इसे DD / MM / YYYY के रूप में लिखा जाता है।



एक आवेदन अनुवाद त्रुटि का एक प्रसिद्ध उदाहरण

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

इस लेख में हम केवल अंतर्राष्ट्रीयकरण पर विचार करेंगे, लेकिन स्थानीयकरण तंत्र एक समान तरीके से बनाया गया है। इस लेख में उल्लिखित पुस्तकालय स्थानीयकरण का समर्थन करते हैं।

मुख्य प्रकार

अंतर्राष्ट्रीयकरण में विभाजित है:

1. अजगर लिपियों में सीधे डेटा का अनुवाद।
2. टेम्पलेट इंजन में डेटा का अनुवाद।
3. एक डेटाबेस में संग्रहीत डेटा का अनुवाद।

1. अजगर स्क्रिप्ट डेटा का अनुवाद

काम करने के लिए हमारे अंतर्राष्ट्रीयकरण के लिए, हमें बेबल लाइब्रेरी और डिस्टिल्ट टूलकिट को बिक्री के लिए और उससे आगे के प्रोजेक्ट की असेंबली का प्रबंधन करने के लिए समझने की आवश्यकता है।

अनुवाद की तैयारी

शुरुआत करने के लिए, हमें अनुवाद की एक सूची बनाने की आवश्यकता है। शुरू करने के लिए, हम बैबेल पुस्तकालय स्थापित करते हैं - यह परियोजना के निर्माण के लिए सुविधाजनक परिवर्धन के साथ दिनांक, मुद्राओं को स्थानीयकृत और परिवर्तित करने के लिए एक आम तौर पर मान्यता प्राप्त अजगर-पुस्तकालय है (नीचे चर्चा की गई है)।

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

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

import gettext import os localedir = os.path.join(os.path.abspath('/path/to/locales'), 'locales') translate = gettext.translation('domain_name', localedir, ['ru']) _ = translate.gettext print(_('some_text')) print(_('some_text_2')) 

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

संक्षिप्तता के लिए, Translate.gettext फ़ंक्शन को नीचे _ के रूप में दर्शाया जाएगा। इस समारोह के लिए अंडरस्कोर सामान्य नाम है, जिसे पायथन समुदाय द्वारा मान्यता प्राप्त है।

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

 from babel.messages import frontend as babel from distutils.core import setup setup(name='foo', version='1.0', cmdclass = {'extract_messages': babel.extract_messages, 'init_catalog': babel.init_catalog, 'update_catalog': babel.update_catalog, 'compile_catalog': babel.compile_catalog,} ) 

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

extract_messages

यह कमांड GNU xgettext टूल पर एक रैपर है, जो एक फ़ाइल में _ () अनुवाद योग्य टैग को पार्स करता है। चलाने के लिए, आपको असेंबली के लिए कई सेटिंग्स चाहिए। ऐसा करने के लिए, रूट निर्देशिका में, सामग्री के साथ setup.cfg फ़ाइल बनाएँ:

 [extract_messages] input_dirs = foobar output_file = foobar/locales/messages.pot 

• input_dirs - निर्देशिका का नाम जिसमें से _ () कोड में सभी लेबल अनुवाद के लिए चुने जाएंगे।
• output_file - .pot फ़ाइल के लिए पथ

कमांड चलाने के लिए, कंसोल में निष्पादित करें:

 $ python setup.py extract_messages 

 running extract_messages extracting messages from foobar/__init__.py extracting messages from foobar/core.py ... writing PO template file to foobar/locales/messages.pot 

पॉट-फाइल में, चिह्नित पंक्तियों को एक सूची में एकत्र किया जाता है जिसमें से अनुवादक तब इच्छित भाषाओं में से प्रत्येक के लिए अनुवाद बना सकते हैं।

 # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR ORGANIZATION # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. # msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2018-01-28 16:47+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Generated-By: pygettext.py 1.5\n" #: src/main.py:5 msgid "some_text" msgstr "" #: src/main.py:6 msgid "some_text_2" msgstr "" 

अगला, आपको कई भाषाओं के लिए अनुवाद बनाने की आवश्यकता है। ऐसा करने के लिए, निम्न कोलाहल आदेशों का उपयोग करें।

init_catalog

यह कमांड GNU msginit टूल पर एक आवरण है, जो पॉट फ़ाइल के आधार पर एक नई अनुवाद निर्देशिका बनाता है।

 $ python setup.py init_catalog -l en -i foobar/locales/messages.pot \ -o foobar/locales/en/LC_MESSAGES/base.po 

 running init_catalog creating catalog 'foobar/locales/en/LC_MESSAGES/messages.po' based on 'foobar/locales/messages.pot' 

महत्वपूर्ण! स्थानीयकरण फ़ाइलें एक विशिष्ट तरीके से, सम्मेलन के अनुसार संग्रहीत की जाती हैं:

स्थानों // LC_MESSAGES / .po

- एक विशिष्ट भाषा में अनुवाद के साथ एक निर्देशिका, हमारे मामले में यह अंग्रेजी (एन) है। न केवल एक विशिष्ट भाषा में अनुवाद के साथ एक निर्देशिका भी हो सकती है, लेकिन अतिरिक्त सुविधाओं को भी ध्यान में रखना चाहिए। उदाहरण के लिए, संयुक्त राज्य अमेरिका के लिए एक अंग्रेजी अनुवाद en_US है;

- अनुवाद के साथ डोमेन। यदि हमारा आवेदन बढ़ता है, तो अनुवादों को डोमेन में विभाजित किया जाएगा ताकि एक फ़ाइल को अधिभार न दिया जा सके।

update_catalog

यह कमांड GNU msgmerge टूल पर एक आवरण है, जो * .po फ़ाइलों के लिए मौजूदा अनुवाद निर्देशिकाओं को अपडेट करता है।

नए अनुवाद जोड़ते समय, हम बस कमांड चलाते हैं:

 $ python setup.py update_catalog -l en -i foobar/locales/messages.pot \ -o foobar/locales/en/LC_MESSAGES/base.po 

 running update_catalog updating catalog 'foobar/locales/en/LC_MESSAGES/base.po' based on 'foobar/locales/messages.pot' 

एन के बजाय आरयू निर्दिष्ट करके हम रूसी में स्थानीयकरण भी निर्दिष्ट कर सकते हैं।

compile_catalog

अंतिम कमांड GNU msgfmt टूल पर एक आवरण है। यह * .po फ़ाइलों से अनुवाद योग्य संदेश लेता है और प्रदर्शन को अनुकूलित करने के लिए उन्हें बाइनरी * .mo फ़ाइलों में संकलित करता है।

 $ python setup.py compile_catalog --directory foobar/locales --domain base 

 running compile_catalog compiling catalog to foobar/locales/en/LC_MESSAGES/base.mo 

--directory - स्थानीयकरण के साथ निर्देशिका के लिए पथ,
--domain - अनुवाद डोमेन को निर्दिष्ट करने के लिए एक ध्वज, हम इसे मौजूदा एप्लिकेशन डोमेन के अनुसार निर्दिष्ट करते हैं।

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



कविता - अनुवाद आवेदन

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

नतीजतन, अनुवाद कैटलॉग की संरचना इस तरह दिखाई देगी:

 locales ├── en │ └── LC_MESSAGES │ ├── base.mo │ └── base.po ├── ru │ └── LC_MESSAGES │ ├── base.mo │ └── base.po └── messages.pot 

अनुवाद मार्कर नाम कन्वेंशन

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

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

profile.user_form.component.title: उपयोगकर्ता डेटा
profile.user_form.component.save: सहेजें
profile.user_form.field.username: उपयोगकर्ता नाम
profile.user_form.field.password: पासवर्ड


आवेदन परिनियोजन

डॉकटर में एप्लिकेशन को लागू करने और तैनात करने के लिए, आपको निम्न आदेशों का उपयोग करके अनुवाद फ़ाइलों को .mo बाइनरी फाइलों में संकलित करने की आवश्यकता है:

 $ python setup.py compile_catalog --domain <> 

हम .OGignore में * .mo और * .pot फ़ाइलों को बाहर करने की सलाह देते हैं:

# अनुवाद
* .मो
* .पोट

2. टेम्पलेट इंजन में डेटा का अनुवाद

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

 translations = get_gettext_translations() env = Environment(extensions=['jinja2.ext.i18n']) env.install_gettext_translations(translations) 

फिर टेम्प्लेट में हम केवल निर्माण का उपयोग करते हैं:

 {{ gettext('some_text') }} {{ gettext('Hello %(name)s!')|format(name='World') }} 

3. डेटाबेस में संग्रहीत डेटा का अनुवाद

आइए सबसे सामान्य संबंधपरक डेटाबेस में अनुवाद के साथ काम करने के विकल्पों पर विचार करें। यह ध्यान दिया जाना चाहिए कि noSQL और newSQL डेटाबेस के लिए अनुवाद और स्थानीयकरण का कार्यान्वयन समान है।

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

1) प्रत्येक भाषा के लिए अलग लाइनें

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



वर्णित योजना के लिए, तालिका में डेटा इस तरह दिखना चाहिए:



फायदे:

• सरल और कुशल कार्यान्वयन।
• एक विशिष्ट भाषा कोड का उपयोग करते समय सरल प्रश्न।

नुकसान:

• केंद्रीकरण का अभाव

विभिन्न भाषाओं में अनुवाद विभिन्न तालिकाओं में संग्रहीत किए जा सकते हैं। इस प्रकार, आप नहीं जानते कि आपका आवेदन कितनी भाषाओं में पूरी तरह अनुवादित है।

यह समाधान उन अनुप्रयोगों के लिए उपयुक्त है जिन्हें शुरू में सभी डेटा के पूर्ण अंतर्राष्ट्रीयकरण की आवश्यकता नहीं होती है। लेकिन नए क्षेत्रों के लिए अनुवाद जोड़ना संभव है क्योंकि व्यवसाय का विस्तार होता है।

डेटा के लिए अनुरोध इस प्रकार होगा:

 SELECT p.product_name, p.price, p.description FROM product p WHERE p.language_code = @language_code; 

2) अनुवाद के साथ अलग टेबल

इस दृष्टिकोण में, स्थानीयकरण की आवश्यकता वाली प्रत्येक तालिका के लिए, हम अनुवाद के साथ तालिकाओं का निर्माण करते हैं।



पेशेवरों:

• अनारक्षित डेटा के लिए तालिकाओं में शामिल होने की आवश्यकता नहीं है।
• क्वेरीज़ आसान हो जाती हैं क्योंकि अनुवाद के लिए अलग-अलग टेबल होते हैं।
• डेटा में कोई विसंगतियां नहीं हैं।
• अनुवादों के अलावा, भाषा तालिका में शेष डेटा को प्रभावी ढंग से स्थानीय बनाना संभव है।

नुकसान:

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

डेटा के लिए अनुरोध इस प्रकार होगा:

 SELECT tp.text, p.price, tc.text, c.contact_name FROM order_line o, product p, customer c, translation tp, translation tc, language l WHERE o.product_id = p.id AND o.customer_id = c.id AND p.name_translation_id = tp.id AND c.name_translation_id = tc.id AND tp.language_id = l.id AND tc.language_id = l.id AND l.name = @language_code AND o.id = ***; 

3) अनुवादित और गैर-अनुवादित क्षेत्रों के लिए इकाइयाँ बनाना

इस समाधान में, इकाई तालिकाओं में एक या अधिक अनुवादित फ़ील्ड होते हैं जो अप्रतिष्ठित लोगों के साथ डेटा का विस्तार करते हैं।



पेशेवरों:

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

नुकसान:

• कार्यान्वयन की सापेक्ष जटिलता।

यहाँ एक प्रश्न का उदाहरण दिया गया है जो अनुवादित पाठ को पुनः प्राप्त करेगा:

 SELECT pt.product_name, pt.description, p.price FROM order_line o, product p, product_translation pt, language l WHERE o.product_id = p.id AND AND p.id = pt.product_non_trans_id AND pt.language_id = l.id AND l.name = @language_code; 

निष्कर्ष

जब स्थानीयकरण और अंतर्राष्ट्रीय बाजार के लिए अनुप्रयोगों का अंतर्राष्ट्रीयकरण किया जाता है, तो विभिन्न तरीकों का उपयोग किया जा सकता है, जिनमें से प्रत्येक की कुछ विशेषताएं और सीमाएं हैं।

इस लेख में, हमने निम्नलिखित प्रकार के अंतर्राष्ट्रीयकरण की जांच की:

• कोड में: हम अनुवाद का उपयोग करते हैं जब एक सेवा या आवेदन के साथ gui बना;
• टेम्प्लेट में: डायनेमिक फ्रंटएंड के बिना वेब एप्लिकेशन विकसित करते समय हम उपयोग करते हैं;
• डेटाबेस में: उपयोगकर्ता या गतिशील रूप से उत्पन्न डेटा को संग्रहीत करते समय उपयोग करें।

हमें उम्मीद है कि हमारा लेख आपको अपनी परियोजना के लिए सबसे उपयुक्त विधि चुनने में मदद करेगा।