रेल्स का i18n लाइब्रेरी जितना दिखता है उससे अधिक शक्तिशाली है। आपको इसका उपयोग केवल अनुवाद के लिए करने की आवश्यकता नहीं है। i18n लाइब्रेरी कहीं भी उपयोगी है जहां आप अपने द्वारा प्रदर्शित टेक्स्ट को उस स्थान से अलग करना चाहते हैं जहां आप इसे प्रदर्शित करते हैं।
जब मैं Avvo में था, हमने 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 में हैं।
एक्टिवरिकॉर्ड बैकएंड्स
कभी-कभी, एक YAML फाइल में स्टेटिक अनुवाद आपके प्रोजेक्ट के लिए काम नहीं करेंगे। यदि आप एक्टिवरिकॉर्ड i18n बैकएंड का उपयोग करते हैं:
require 'i18n/backend/active_record'
I18n.backend = I18n::Backend::ActiveRecord.new
आप अपने डेटाबेस में translations टेबल में अनुवाद देख सकते हैं। इस तरह, आपको अपने सभी अनुवादों को अग्रिम रूप से परिभाषित करने की आवश्यकता नहीं है। इसके बजाय, आप नए अनुवादों को ऑन-द-फ्लाई जोड़ सकते हैं।
translations टेबल सेट करने के लिए एक विशिष्ट माइग्रेशन की आवश्यकता होती है। i18n-active_record रेपो पर README में इसे काम करने के लिए आवश्यक सभी जानकारी है।
ऑब्जेक्ट प्रकारों के बीच पार्शियल साझा करना
Avvo में, हमारे पास एक वकील निर्देशिका, वकील समीक्षाएं, और कानूनी सलाह थी। लेकिन कुछ साल पहले, हमारे पास साइट पर सिर्फ वकील नहीं थे। हमारे पास डॉक्टर और डेंटिस्ट भी थे!
हमारे 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
# "en" पर वापस जाएं अगर हम "en_jd", आदि के तहत कुछ नहीं ढूंढ सकते।
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 के बारे में जो कुछ भी सीखा वह रेल्स गाइड्स और API डॉक्स पढ़ने से सीखा।
तो, वह अतिरिक्त कदम उठाएं। जिन टूल्स पर आप भरोसा करते हैं उन्हें अच्छी तरह से सीखें। आप पाएंगे कि आप सुविधाओं और ट्रिक्स में भाग लेंगे जो न केवल आपको अधिक उत्पादक बनाएंगे, बल्कि उन समाधानों की पूरी नई श्रेणियों को अनलॉक कर सकते हैं जिनके बारे में आपने कभी सोचा भी नहीं था।