Rails ऐप्स में Devise को अंतर्राष्ट्रीयकृत करने के लिए पूर्ण चेकलिस्ट

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

आप शायद Devise को जानते हैं—Rails एप्लिकेशन के लिए एक लोकप्रिय प्रमाणीकरण समाधान। Devise के साथ काम करते समय, मैंने पाया कि अनुवाद को चालू करना और चलाना मेरी अपेक्षा से अधिक जटिल था। बीते हुए मैं चाहता था कि एक चेकलिस्ट हो जो प्रक्रिया के माध्यम से मेरा मार्गदर्शन कर सके।

तो यह यहां है - भविष्य के मेरे और आपके लिए - अंतिम Devise अंतर्राष्ट्रीयकरण चेकलिस्ट!

devise-i18n जेम का उपयोग कब (नहीं) करना चाहिए?

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

हालांकि, devise-i18n जेम स्पष्ट रूप से Devise टेक्स्ट का यथासंभव बारीकी से पालन करना चुनता है। लेकिन Devise जो टेक्स्ट प्रदान करता है वह शुरू से ही बहुत सुसंगत नहीं है। और चूंकि शाब्दिक अनुवाद कभी भी धाराप्रवाह भाषा उत्पन्न नहीं करेगा, मैं लगातार अनुवादों को ट्वीक कर रहा हूं (और परियोजनाओं के बीच फाइलें कॉपी कर रहा हूं)। यह एक निरंतर संघर्ष है क्योंकि एक समय में एक स्ट्रिंग या एक व्यू को देखते हुए सभी अनुवादों को सुसंगत बनाना कठिन है।

परिणामस्वरूप, i18n-devise जेम के अनुवादों की गुणवत्ता मेरे मोनोलिंगुअल, केवल-डच प्रोजेक्ट्स के लिए आवश्यक मानकों तक नहीं पहुंचती।

अनुकूलित व्यूज़ के साथ जेम का उपयोग करने का एक और नुकसान उत्पन्न होता है। भले ही यह केवल स्टाइलिंग के साथ करना हो, devise-i18n जेम का हर अपडेट जो Devise द्वारा व्यूज़ में किए गए किसी भी बदलाव को छूता है, का मतलब होगा कि आपको चीजों को ठीक करना होगा। आपको या तो व्यूज़ को पुन: उत्पन्न करना होगा और अनुकूलन लागू करना होगा या आपको अपने व्यूज़ में परिवर्तनों को कॉपी/पेस्ट करना होगा। यह समस्या नीचे चेकलिस्ट में दृष्टिकोण के साथ हल नहीं होती है, वैसे, लेकिन इसे devise-i18n जेम के बिना हल करना भी अधिक कठिन नहीं है। 🤷‍♀

🇳🇱 एक डच उपहार

मैंने Devise के लिए एक अच्छी डच अनुवाद फ़ाइल बनाने का फैसला किया, और फिर कभी इसके बारे में चिंता न करनी पड़े। उपहार की तरह लगता है? आप नई और बेहतर अनुवाद फ़ाइल GitHub पर पा सकते हैं। चेकलिस्ट में चरण 3 देखें। प्रत्येक अनुवाद निर्णय का तर्क फ़ाइल में समझाया गया है।

अंतिम चेकलिस्ट

अब जब हम :nl अनुवाद के साथ अकेले उड़ रहे हैं, तो आइए सभी विवरणों के साथ शुरू करें और बॉक्स चेक करना शुरू करें।

ध्यान दें कि यह मानता है कि आपके पास एक ऐप तैयार है, जिसमें Devise जोड़ा गया है और एक User मॉडल के साथ इंस्टॉल किया गया है, और Devise व्यूज़ उत्पन्न किए गए हैं। यदि आप साथ में कोडिंग कर रहे हैं: यह प्रारंभिक बिंदु है। और ध्यान दें कि nl में *.nl.yml को आपकी पसंद की भाषा से बदला जा सकता है, और User और :user को Devise में आपके द्वारा उपयोग किए जाने वाले मॉडल नाम से बदला जा सकता है।

चरण एक: लोकेल सेट करें

उपलब्ध लोकेल में :nl जोड़ें (यदि आपके पास इस मामले पर कोई मजबूत राय नहीं है, तो अभी के लिए इसे application.rb में डालकर शुरू करें)। अब आप इसे डिफ़ॉल्ट के रूप में सेट कर सकते हैं।

# application.rb
config.i18n.available_locales = [:nl, :en]
config.i18n.default_locale = :nl

लोकेल सेट करने के लिए application.rb में जोड़ने की तुलना में बेहतर, शायद क्लीनर विकल्प हैं। इस पोस्ट को पढ़ने के बाद Rails i18n गाइड देखें ताकि वह विकल्प चुन सकें जो आपको सबसे अच्छा लगे।

चरण दो: Rails अनुवाद जोड़ें

Rails :nl अनुवाद फ़ाइल जोड़ें ताकि इंटरफ़ेस में उन स्ट्रिंग्स का ख्याल रखा जा सके जो Devise-विशिष्ट नहीं हैं (विशेष रूप से Rails सत्यापन त्रुटि संदेश)।

चरण तीन: Devise कुंजियाँ

Devise कुंजियों को :nl में अनुवाद करें: नया और बेहतर डच अनुवाद जोड़ें! (ऊपर लिंक 🇳🇱)

चरण चार: व्यूज़.*.yml फ़ाइलें बनाएं

व्यूज़ के लिए डच और अंग्रेजी .yml फ़ाइलें जोड़ें, views.*.yml। रेपो में एक तैयार views.nl.yml फ़ाइल का उदाहरण है, जो चरण 4, 6 और 7 को दर्शाता है।

#example views.nl.yml
nl:
  devise:
    # बाद में Devise स्कोप के साथ भरें:
    # registrations:
    #   new:
    #     forget_password: Wachtwoord vergeten?

चरण पांच: Active Record विशेषताएँ

अब, Active Record विशेषताओं के लेबल के लिए अनुवाद जोड़ें, जैसे ईमेल और पासवर्ड। केवल उन्हीं का अनुवाद करें जो उपयोगकर्ता और एडमिन उपयोगकर्ता देखते हैं, आपके द्वारा लागू किए गए प्रत्येक मॉड्यूल के लिए। टोकन नाम और ऐसे का अनुवाद करने की कोई आवश्यकता नहीं है (जैसा कि i18n जेम करता है)। यहां मैं उपयोगी 'अनुवादनीय' मानता हूँ:

# In: active_record.nl.yml
# उन लेबल का अनुवाद करना जो User विशेषताओं से मैप होते हैं
nl:
  activerecord:
    attributes:
      user:
        current_password: Huidig wachtwoord
        email: e-mailadres
        password: wachtwoord
        password_confirmation: Wachtwoord bevestigen
        remember_me: Ingelogd blijven?
    models:
      user: Gebruiker

ध्यान दें कि :email और :password मान लोअरकेस हैं। यह चरण 7 में Rails त्रुटि संदेशों में बदलाव के कारण है।

अभी के लिए, कुंजियों को active_record.*.yml में रखें।

चरण छह: हर Devise व्यू की जांच करें

अगला, सभी Devise-विशिष्ट टेम्पलेट्स और स्ट्रिंग्स को संबंधित अनुवादों के साथ i18n-ed करने की आवश्यकता है। इसे स्वयं करना एक कष्टप्रद काम है। इसमें गोता लगाने से पहले, देखें कि क्या इन शॉर्टकट्स में से कोई आपके लिए काम करता है:

• आप व्यूज़ के लिए 118n-devise जेम का उपयोग कर सकते हैं, लेकिन आपको अभी भी जेम की .yml फाइलों से कुंजियों को अपने प्रोजेक्ट की .yml फाइलों में कॉपी करना होगा। जेम उन्हें devise.*.yml में इंटरलीव करता है, लेकिन हम अपने अच्छे नए डच अनुवाद को ओवरराइट नहीं करना चाहते। और यदि आपने Devise व्यूज़ को स्टाइल किया है, तो आपको स्टाइलिंग को भी कॉपी करना होगा। यूग।

• यदि आपके पास पहले से ही i18n-ed प्रोजेक्ट हैं, तो आप व्यू फ़ाइलों को कॉपी कर सकते हैं। (पिछले विकल्प के समान नुकसान।)

• मेरे नवीनतम प्रोजेक्ट में उपयोग किए गए कुछ व्यूज़ के उदाहरणों के लिए रेपो का उपयोग करें।

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

Devise फॉर्म्स के लिए मिनी चेकलिस्ट

• स्ट्रिंग्स जो Active Record स्ट्रिंग्स नहीं हैं, उन्हें 118n-ed करने की आवश्यकता है और उनके (उचित रूप से स्कोप्ड) कुंजियाँ और अनुवाद होने चाहिए (उदाहरण के लिए, एक views.*.yml फ़ाइल में संग्रहीत—उदाहरण देखें)।
• ध्यान रखें कि डच अनुवाद, जब आप अपने खुद के जोड़ते हैं, नए devise.nl.yml के साथ सुसंगत हैं।
• लोअरकेस लेबल को नज़रअंदाज़ करें; वे चरण 7 में उचित रूप से कैपिटलाइज़ किए जाएंगे।
• यदि आपके पास पहले से ही मेलर्स i18n-ed हैं, तो यह ठीक है। यदि नहीं, तो आप उन्हें चरण 8 तक नज़रअंदाज़ कर सकते हैं।
• निम्नलिखित Devise व्यूज़ को Rails translate (t) हेल्पर के साथ अनुवाद योग्य बनाने की आवश्यकता है:
  • devise/views/shared/_links पार्शियल: सभी लिंक नाम;
  • devise/views/shared/_errors पार्शियल (Devise 4.6 के बाद से)
  • आपके द्वारा उपयोग किए जाने वाले प्रत्येक मॉड्यूल के लिए Devise फॉर्म में: वे सभी स्ट्रिंग्स जो Active Record विशेषताओं के लेबल नहीं हैं।

चरण सात: Active Record त्रुटि संदेश

अगला, हमें Devise कार्यक्षमता से संबंधित Active Record त्रुटि संदेशों को ट्वीक करने की आवश्यकता है। जैसे "पासवर्ड खाली नहीं हो सकता", और अन्य सत्यापन।

बात यह है, अब जब हमने Devise अनुवादों को अपग्रेड कर दिया है, तो Active Record संदेशों को भी ट्वीक करने की आवश्यकता है क्योंकि शैली में असंगतता वास्तव में दिख रही है। तो मैंने उन्हें भी ट्वीक किया, Devise अनुवादों के लिए समान नियमों का पालन करते हुए, और यह सुनिश्चित करते हुए कि वे सुसंगत हैं।

आप देखेंगे कि संदेशों का प्रारूप बदल गया है: "%{attribute} %{message}" से "%{message}" तक। अब हम अनुवादित स्ट्रिंग के भीतर विशेषता का संदर्भ दे रहे हैं, बजाय इसे स्ट्रिंग की शुरुआत में मजबूर करने के, इससे डच संदेशों को सुंदर बनाना बहुत आसान हो जाता है। मुझे डुप्लिकेशन पसंद है बजाय कभी-कभी अजीब संदेशों को सहन करने के।

नए संदेश प्रारूप ही कारण है कि, चरण 5 में, ईमेल और पासवर्ड विशेषताओं को लोअरकेस करने की आवश्यकता थी: त्रुटि संदेशों में, वे एक वाक्य के भीतर कहीं भी प्रकट हो सकते हैं।

मैंने :taken संदेश को भी बदल दिया। Devise की नीति यह प्रकट न करने की है कि क्या कोई ईमेल पता 'नहीं मिला' या 'अमान्य' है। मैंने उस नीति को Rails के taken संदेश तक बढ़ा दिया।

यदि आप नए संदेश शैली का पालन करना चाहते हैं तो इस फ़ाइल को देखें। फिर मूल nl.yml फ़ाइल में Rails error: messages: कुंजियों के संबंधित भाग को बदलें। एक चेतावनी: जब आप Devise-संबंधित इनपुट के अलावा सत्यापन जोड़ रहे हों, तो कृपया दोबारा जांच लें कि त्रुटि संदेश अभी भी समझ में आते हैं। (मुझे आगे जांच करने की आवश्यकता है; मैंने केवल उन्हीं की जांच की है जो Devise से संबंधित हैं।)

चरण आठ: उन लेबल को ठीक करें जिन्हें हमने अभी तोड़ा

चरण 5 में, हमने नए त्रुटि संदेशों में उपयोग के लिए ईमेल और पासवर्ड अनुवाद को लोअरकेस किया। अब हमें लेबल में उनकी उपस्थिति को ठीक करने की आवश्यकता है। कई विकल्प हैं, लेकिन मुझे जो सबसे ज्यादा पसंद है वह अलग 'लेबल' कुंजियाँ जोड़ना है।

यह उपयोगकर्ता कुंजियों के लिए कुछ डुप्लिकेशन जोड़ता है, लेकिन यह फॉर्म में लेबल को साफ रखता है।

# in active_record.nl.yml लेबल हेल्पर कुंजियाँ जोड़ें:
nl:
  activerecord:
    attributes:
      user:
        current_password: Huidig wachtwoord
        email: e-mailadres
        password: wachtwoord
        password_confirmation: Herhaal het wachtwoord
        remember_me: Wil je ingelogd blijven?
    models:
      user: Gebruiker
    helpers:
      label:
        user:
          email: Emailadres
          password: Wachtwoord

ध्यान दें कि मूल nl.yml में पहले से ही एक :helpers स्कोप है। सामान्य रूप से, एक स्कोप के लिए कुंजियों को एक साथ रखना आसान लुकअप (मनुष्यों द्वारा) के लिए एक अच्छा विचार है।

अन्य परिवर्तन जो हमें करने की आवश्यकता है वे सीधे हैं। यहां से कोई बड़ा आश्चर्य नहीं निकलेगा। 🎉।

चरण नौ: नेविगेशन लिंक अपडेट करें

Devise की ओर इशारा करने वाले सभी लिंक ढूंढें (नेविगेशन सोचें) और उन्हें Rails t हेल्पर के साथ i18n करें।

मैं उन्हें .yml's के Devise स्कोप में कहीं रखना पसंद करता हूं। उदाहरण के लिए, मैं t("devise.sign_out") जोड़ूंगा ताकि :sign_out :sign_up और :sign_in के समान स्कोप में हो (उदाहरण फ़ाइलें देखें)।

चरण दस: मेलर्स का अनुवाद करें।

मेलर व्यूज़ का अनुवाद करें। कुछ विकल्प हैं:

• आप हर स्ट्रिंग और लिंक नाम को i18n कर सकते हैं, ठीक वैसे ही जैसे हमने चरण 6 में अन्य व्यूज़ के साथ किया था। आप एक अलग mailer.*.yml जोड़ना चाह सकते हैं।

• या आप प्रत्येक लोकेल के लिए अलग मेलर व्यूज़ जोड़ सकते हैं: devise/mailer/reset_password.nl.html.erb और devise/mailer/reset_password.en.html.erb। प्रत्येक अपने स्वयं के टेक्स्ट के साथ। Rails वह चुनेगा जो सेट लोकेल से मेल खाता है।

ठीक है! अब सभी Devise स्ट्रिंग्स ठीक से अनुवादित हैं। याय!

बाद की देखभाल: अव्यवस्था दूर करें

मेरे व्यूज़ उदाहरण में, मैंने शेयर्ड कुंजियों (जैसे :forgot_password) को निकाला और उन्हें सामान्य Devise स्कोप में एकत्र किया। इससे उन्हें बदलना आसान हो जाता है, लेकिन Rails उन्हें स्वचालित रूप से नहीं ढूंढ सकता, इसलिए हमें वर्बोज़ सिंटैक्स (t("devise.forgot_password")) की आवश्यकता है, क्योंकि डॉट सिंटैक्स (t(".new_confirmation_mail")) काम नहीं करेगा।

यदि आप active_record.*.yml के साथ जाते हैं, तो Active Record स्कोप वाली सभी कुंजियों को उस फ़ाइल में एकत्र करना समझ में आता है। Active Record कुंजियों को Rails *.yml फाइलों से संबंधित active_record.*.yml में ले जाएं।

हमारे पास devise: स्कोप को डुप्लिकेट करने वाली *.yml फाइलों के दो जोड़े हैं। Devise व्यूज़ की कुंजियों को devise.*.yml व्यूज़ में मिलाने पर विचार करें। यह वही है जो Devise-i18n जेम करता है, और मुझे यह पसंद है। आप इसे इस तरह करेंगे:

# व्यू स्कोप को devise.nl.yml में मिलाना
nl:
  devise:
    confirmations: ...
    registrations: ...
    edit: ...
    new: ...

कुछ ट्वीक और टिप्स

• मैं त्रुटि संदेश में हेडर का प्रशंसक नहीं हूं ('x त्रुटियों ने इस उपयोगकर्ता को सहेजे जाने से रोका'), इसलिए मैंने उसे errors पार्शियल से हटा दिया।
• यदि आप default_locale को :nl पर सेट करते हैं, तो Rails कुंजियों को 'मानवीकृत' करेगा यदि उसे कोई अनुवाद नहीं मिलता। तो, t(:some_untranslated_key) व्यू में Some Untranslated Key के रूप में दिखाई देगा।
• I18n-tasks जेम के साथ आप अप्रयुक्त कुंजियों को साफ कर सकते हैं और लापता कुंजियों को जोड़ सकते हैं। यह एक बढ़िया उपकरण है! हालांकि, मेरे IDE में बढ़िया i18n समर्थन है और मेरे लिए यह जेम की तुलना में तेज़ वर्कफ़्लो साबित हुआ।

विदा लेना ऐसा मीठा दुख है

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

लेकिन इस चेकलिस्ट के हाथ में होने के बावजूद, कार्य करने से पहले सोचें: शायद थोड़ी देर के लिए कम इष्टतम अनुवादों के साथ रहना उचित है…