रेल की i18n लाइब्रेरी जितनी दिखती है, उससे कहीं ज्यादा शक्तिशाली है। आपको इसे केवल अनुवाद के लिए उपयोग करने की आवश्यकता नहीं है। i18n लाइब्रेरी आपके द्वारा प्रदर्शित टेक्स्ट को उस स्थान से अलग करने के लिए कहीं भी उपयोगी है जहां आप इसे प्रदर्शित करते हैं।
जब मैं एवो में रहा हूं, हमने कुछ बहुत अच्छी चीजें करने के लिए i18n का उपयोग किया है। मैं कुछ चीजें साझा करने जा रहा हूं जो हमने सीखी हैं जो काम में आई हैं, साथ ही पुस्तकालय का एक पागल दुरुपयोग जो हमारे लिए अविश्वसनीय रूप से अच्छा काम कर रहा है।
स्वचालित HTML एस्केपिंग
क्या आपके पास ऐसी लाइनें हैं जो इस तरह दिखती हैं:
<%= raw(t('form.required_field_header')) %>
आपके विचारों में? आपको उस raw की आवश्यकता नहीं है , क्योंकि यदि आपकी अनुवाद कुंजी _html . के साथ समाप्त होती है , आप मुफ्त में बच जाते हैं:
<%= t('form.required_field_header_html') %>
आपके अन्य t() . के साथ सरल, और अधिक सुसंगत कॉल।
स्थानीय स्थानों को अधिक आसानी से एक्सेस करना
जब आप अपनी स्थानीय फ़ाइलें बनाते हैं, तो संभवत:आपकी कुछ कुंजियाँ एक ही पैरेंट के अंतर्गत समूहीकृत होंगी:
en:
bugs:
index:
new_label: "File a new bug"
edit_label: "edit"
delete_label: "delete"
इन सभी के एक समूह को एक साथ संदर्भित करने के लिए, आप कर सकते हैं उन्हें उनकी पूरी कुंजी से देखें:
<%= t('bugs.index.edit_label') %> | <%= t('bugs.index.delete_label') %>
यह काफी कष्टप्रद और दोहराव वाला है। लेकिन t() सहायक रूप से एक दायरा लेता है, इसलिए आप कुंजियों को अधिक आसानी से संदर्भित कर सकते हैं:
<% bugs_scope = 'bugs.index' -%>
<%= t('edit_label', scope: bugs_scope) %> | <%= t('delete_label', scope: bugs_scope) %>
यदि आप अपने आंशिक नाम अच्छी तरह से रखते हैं, तो आपको दायरा निर्दिष्ट करने की भी आवश्यकता नहीं है:
<%= t('.edit_label') %> | <%= t('.delete_label') %>
यानी .edit_label संदर्भ bugs.index.edit_label , क्योंकि आप bugs/index.html.erb . में हैं ।
ActiveRecord बैकएंड
कभी-कभी, yaml फ़ाइल में स्थिर अनुवाद आपके प्रोजेक्ट के लिए काम नहीं करते हैं। यदि आप इसके बजाय ActiveRecord i18n बैकएंड का उपयोग करते हैं:
require 'i18n/backend/active_record'
I18n.backend = I18n::Backend::ActiveRecord.new
आप अनुवादों को translations में देख सकते हैं आपके डेटाबेस में तालिका। इस तरह, आपको अपने सभी अनुवादों को पहले से परिभाषित करने की आवश्यकता नहीं है। इसके बजाय, आप तुरंत नए अनुवाद जोड़ सकते हैं।
translations सेट करना तालिका के लिए एक विशिष्ट माइग्रेशन की आवश्यकता होती है। i18n-active_record रेपो पर README में वह सारी जानकारी है जो आपको इसे काम करने के लिए चाहिए।
ऑब्जेक्ट प्रकारों के बीच आंशिक साझा करना
एवो में, हमारे पास एक वकील निर्देशिका, वकील की समीक्षा और कानूनी सलाह है। लेकिन कुछ साल पहले, हमारी साइट पर केवल वकील ही नहीं थे। हमारे पास डॉक्टर और दंत चिकित्सक भी थे!
इन व्यवसायों के बीच हमारा बहुत सारा UI समान था। लेकिन काफी अलग था (उदाहरण के लिए, जिसे वकील "अभ्यास क्षेत्र" कहते हैं, डॉक्टर "विशेषज्ञता" कहते हैं), कि बिना किसी बदसूरत कोड के समान विचार या आंशिक साझा करना मुश्किल होगा।
आखिरकार, हमने इसके लिए i18n सिस्टम पर भरोसा करने की कोशिश करने के बारे में सोचा। आखिरकार, अंग्रेजी वकील तरह का है अंग्रेजी की एक बोली, और डॉक्टरेट एक ही तरह से है . हम अंततः अन्य भाषाओं का उपयोग करने से खुद को रोकना नहीं चाहते थे, इसलिए हमने दो नए स्थान बनाने का निर्णय लिया:en_jd और en_md ।
यह एक कस्टम i18n बैकएंड के रूप में स्थापित करना आसान साबित हुआ:
class AvvoI18nStore < I18n::Backend::Simple
def translate(locale, key, options = {})
begin
default = options.delete(:default)
super(locale, key, options)
rescue I18n::MissingTranslationData => e
# fall back to "en" if we can't find anything under "en_jd", etc.
fallback_locale = locale.to_s.split("_").first
super(fallback_locale, key, options.merge(:default => default))
end
end
end
I18n.backend = AvvoI18nStore.new
और अनुवादों को परिभाषित करना उतना ही आसान था:
en_jd:
practice_area: "practice area"
en_md:
practice_area: "specialty"
इसने संपूर्ण आंशिक अनुवादों के लिए भी बहुत अच्छा काम किया (फ़ाइल नाम नोट करें):
<!-- Lawyer badge HTML -->
<!-- Doctor badge HTML -->
और यह वापस en . पर भी गिर गया लोकेल, साझा अनुवादों के लिए:
en:
leaderboard:
title: "Leaderboard"
जब आप साइट के "डॉक्टर" अनुभाग में थे, तो हमने डिफ़ॉल्ट लोकेल को :en_md में बदल दिया था , और इसके विपरीत:
I18n.locale = :en_md
और सब कुछ बस काम कर गया!
मुझे यकीन नहीं है कि मैं इसकी सिफारिश करूंगा। यह थोड़ा पागल है, अलग-अलग भाषाओं वाले विभिन्न व्यवसायों के बारे में सोच रहा है। लेकिन हमने ऐसा करते हुए आश्चर्यजनक रूप से अच्छा काम किया। और इससे पता चलता है कि i18n जैसे सरल उपकरणों में कितनी शक्ति हो सकती है।
आप यह सामान कहां से लाते हैं?
पिछले हफ्ते, मैंने एक शुरुआत से एक विशेषज्ञ तक जाने के तरीके के रूप में विशिष्ट तकनीकों में गहरी गोता लगाने के बारे में बात की थी। यह उसका एक और उदाहरण है:हमने i18n के बारे में जो कुछ भी सीखा है, उसमें से अधिकांश हमने रेल गाइड और एपीआई डॉक्स को पढ़ने से सीखा है।
तो, वह अतिरिक्त कदम उठाएं। उन उपकरणों को जानें जिन पर आप अच्छी तरह भरोसा करते हैं। आप पाएंगे कि आप ऐसी उपयुक्तताओं और तरकीबों में भाग लेंगे जो न केवल आपको अधिक उत्पादक बनाएगी, बल्कि उन नई श्रेणियों के समाधानों को भी अनलॉक कर सकती हैं जिनके बारे में आपने कभी सोचा भी नहीं होगा।