डेवलपर्स द्वारा किए जाने वाले 10 सामान्य i18n-गलतियाँ | समाधान गाइड 2025
डेवलपर्स द्वारा किए जाने वाले सबसे सामान्य i18n-गलतियाँ सीखें, और कैसे ठीक करें। इन बेहतरीन अभ्यासों के साथ अपनी iOS, Android या Web ऐप की लोकलाइज़ेशन गुणवत्ता बेहतर बनाएं.
अनुवाद (i18n) सरल लग सकता है — जब तक आप यह न पहचान लें कि आपके जर्मन उपयोगकर्ता कटे हुए बटन देख रहे हैं, आपके जापानी उपयोगकर्ता अधूरे वाक्यों के fragments पाते हैं, और आपके अरबी-भाषी उपयोगकर्ता पूरी तरह से खराब लेआउट देखते हैं. ये किसी भी विक्षेप नहीं हैं। ये उन सामान्य त्रुटियों के पूर्वानुमानित परिणाम हैं जो अधिकांश विकास टीमें Lokalizacji को पहली बार अपनाते समय करती हैं. इस गाइड में हम i18n की 10 सबसे आम गलतियों पर चर्चा करेंगे, बतायेंगे कि वे क्यों होती हैं, और कदम-दर-कदम दिखायेंगे कि हर एक को कैसे ठीक करें. चाहे आप एक नई ऐप बना रहे हों या मौजूदा को अपग्रेड कर रहे हों — इन बाधाओं से बचना आपको debugging में हफ्तों की बचत कराएगा.
त्रुटि #1: हार्ड-कोडेड स्ट्रिंग्स
Hardcoding strings i18n की सबसे बुनियादी गलती है। यह उस स्थिति में होता है जब डेवलपर्स पहले फीचर्स चलाने पर केंद्रित रहते हैं और बाद में ठीक करने की योजना बनाते हैं। लेकिन बाद में कभी नहीं आता और अचानक आपके पास हज़ारों स्ट्रिंग्स होते हैं जो सैकड़ों फाइलों में फैले होते हैं।
['पहले UI कोड की पहली पंक्ति लिखने से पहले अपने i18n फ्रेमवर्क को सेट करें', 'टेम्पलेट्स और कॉम्पोनेंट्स में हार्डकोड स्ट्रिंग्स को पहचानने के लिए Lint प्लगइन का उपयोग करें', 'अनुवाद कुंजी वर्णनात्मक रूप से रखें और फीचर या पेज के अनुसार व्यवस्थित करें']
UI कोड की पहली पंक्ति लिखने से पहले अपने i18n फ्रेमवर्क सेट करें.
Templates और Components में hard-coded स्ट्रिंग्स पहचानने के लिए Linter प्लगइन का प्रयोग करें.
अनुवाद कुंजी वर्णनात्मक रखें और फीचर या पेज के अनुसार व्यवस्थित करें.
एकTypical Szenario
एक डेवलपर JSX में सीधे बटन लेबल लिखता है: <button>Submit Order</button>.
एप्लिकेशन अंग्रेजी में जारी किया गया है और सही तरीके से काम करता है। छह महीने बाद कंपनी जर्मनी तक बढ़ती है.
लोकलाइज़ेशन टीम 2,000+ हार्डकोडेड स्ट्रिंग्स ढूंढ लेती है। अपग्रेड में 3 हफ्ते लगते हैं और 47 बग्स होते हैं.
यह समस्या क्यों है
एक सक्षम कोडबेस में हार्डकोडेड स्ट्रिंग्स हजारों में पहुँच सकती हैं। बाद में उन्हें निकालना प्रत्येक फ़ाइल को छूना पड़ेगा, हर कंपोनेंट को पुनः परीक्षण करना पड़ेगा और हर जगह रिग्रेशन होने का जोखिम होगा。
हार्डकोडेड स्ट्रिंग्स सीधे स्रोत कोड, टेम्पलेट या कंपोनेंट्स में होती हैं। इन्हें रनटाइम पर निकाला, अनुवादित किया या बदला नहीं जा सकता बिना कोड को बदले।
अंग्रेजी नहीं बोलने वाले उपयोगकर्ता UI तत्वों को अनुवादित नहीं देखते, बल्कि प्लेसहोल्डर टेक्स्ट के साथ मिश्रित होते हैं — यह एक хаकाश और असामान्य प्रदर्शन देता है।
इसे कैसे ठीक करें
यूज़र-देखे जाने वाले सभी स्ट्रिंग्स को स्रोत फ़ाइलों में पहले से ही स्थानांतरित करें.
पहली UI कंपोनेंट लिखने से पहले एक अनुवाद फ्रेमवर्क स्थापित करें (जैसे next-intl, react-i18next, vue-i18n).
एक संसाधन-फाइल संरचना बनाएं (जैसे messages/de.json) और सभी स्ट्रिंग्स को t('checkout.submitButton') जैसे अनुवाद-की के जरिए संदर्भित करें।
UI घटकों में कच्चे स्ट्रिंग लिटरलों को चिह्नित करने के लिए एक lint नियम या एक pre-commit hook जोड़ें.
त्रुटि #10: सब कुछ शब्दशः अनुवादित करना।
हर कंटेंट का अनुवाद जरूरी नहीं है. ब्रांड नाम, कानूनी इकाइयों के नाम, तकनीकी शब्द और कुछ उत्पाद नाम अपनी मूल भाषा में रहने चाहिए. अधिक अनुवाद से कानूनी समस्याएं, ब्रांड-असंगति और उपयोगकर्ता भ्रम हो सकता है.
["एक 'अनुवाद न करें'-ग्लॉसरी बनाएँ और इसे सभी अनुवादकों के साथ साझा करें", "ब्रांड और अधिकार-शब्दों के लिए लॉक किए गए सेगमेंट या अलग Namespace का उपयोग करें", "हमेशा बहुवचन स्ट्रिंग के लिए संदर्भ-नोट्स दें ताकि गलत अनुवादन रोका जा सके"]
एक 'नहीं अनुवादित' शब्दकोश बनाएं और सभी अनुवादकों के साथ साझा करें।
MS: 브랜드 및 지식용어를 위한 잠금된 세그먼트 또는 별도 네임스페이스를 사용하십시오.
हमेशा अस्पष्ट स्ट्रिंग्स के लिए संदर्भ नोट्स दें ताकि गलत अनुवाद रोके जा सकें।
एक सामान्य परिदृश्य
एक अनुवाद फ़ाइल में कंपनी के नाम 'CloudForge Inc.' और तकनीकी शब्द 'OAuth 2.0 Token' को सामान्य अनुवाद योग्य स्ट्रिंग के रूप में शामिल किया गया है।
स्पैनिश अनुवादक ने 'CloudForge' को 'ForjaNube' और 'OAuth 2.0 Token' को 'ficha OAuth 2.0' में अनुवादित किया।
परिणाम: उपयोगकर्ता कंपनी को अपने वास्तविक नाम से नहीं ढूंढ पाते, और जो डेवलपर्स स्पैनिश दस्तावेज़ पढ़ रहे हैं वे अनजाने तकनीकी शब्दों के अनुवाद से भ्रमित होते हैं।
यह समस्या क्यों है
किसी कानूनी दस्तावेज़ में गलत ब्रांड-नेम एक अनुबंध को अवैध बना सकता है. अत्यधिक अनुवादों को सही करने के लिए हर भाषा में प्रत्येक स्ट्रिंग की जाँच करनी पड़ती है — कई हफ्तों का काम।
यदि सभी स्ट्रिंग्स संदर्भ के बिना अनुवाद के लिए भेजी जाती हैं, तो अनुवादक ब्रांड नाम ('Apple' → 'Apfel'), कानूनी शब्द ('GmbH' → 'LLC') या तकनीकी पदों को अनुवादित कर सकते हैं जो अंग्रेजी में ही रहने चाहिए।
उपयोगकर्ता अपने परिचित ब्रांड नाम के अंतर्गत उत्पाद नहीं पाते, कानूनी दस्तावेज गलत कंपनी का उल्लेख करते हैं, और तकनीकी दस्तावेजीकरण अस्पष्ट हो जाता है जब 'API Endpoint' जैसे शब्द अनुवादित होते हैं।
इसे कैसे ठीक करें
अनुवाद नहीं करने योग्य सामग्री को स्पष्ट रूप से चिन्हित करें और अनुवादकों के लिए संदर्भ टिप्पणियाँ दें.
ऐसा 'अनुवाद नहीं करें' ग्लॉसरी बनाएँ जो सभी ब्रांड नाम, उत्पाद नाम, कानूनी इकाइयाँ और पेशेवर शब्दावली सूचीबद्ध करे जिन्हें अपरिवर्तित रखना है.
गैर-अनुवाद योग्य सामग्री के लिए एक अलग namespace या विशिष्ट keys का उपयोग करें। कई i18n टूल्स 'लॉक्ड' सेगमेंट्स का समर्थन करते हैं जिन्हें अनुवादक संपादित नहीं कर सकते।
अपने अनुवाद फ़ाइलों में अनुवादक-टिप्पणियाँ जोड़ें जो संदर्भ स्पष्ट करें: 'यह ब्रांड नाम है — अनुवाद न करें' या 'तकनीकी शब्द — अंग्रेज़ी में ही रखें'.
त्रुटि #2: स्ट्रिंग्स का संयोजन
Fragment से वाक्यों को जोड़ना अंग्रेजी में तर्कसंगत हो सकता है, लेकिन अन्य भाषाओं में यह काम नहीं करता। शब्द-आ Reihen, व्याकरण और वाक्य संरचना भाषाओं के बीच गहरे भिन्न होते हैं, जिससे संयुक्त स्ट्रिंग अनुवाद योग्य नहीं होते.
['कभी भी अनुवादित अंशों को जोड़कर वाक्य न बनाएं', 'स्पष्टता के लिए नामित प्लेसहोल्डर ('{name}') का उपयोग करें, स्थानिक ({0}) के बजाय', 'अनुवादकों के लिए संदर्भ टिप्पणियां प्रदान करें, जो समझाएं कि प्रत्येक प्लेसहोल्डर में क्या है']
कभी भी अनुवादित अंशों को जोड़कर वाक्य न बनाएं.
स्पष्टता के लिए नामित प्लेसहोल्डर ('{name}') का उपयोग करें, स्थानिक ({0}) के बजाय
अनुवादकों के लिए संदर्भ टिप्पणी दें जो हर प्लेसहोल्डर में क्या है समझाती है।
ایک عام منظر نامہ
डेवलपर लिखता है: 'You have ' + count + ' items in your ' + cartType + ' cart' — यह अंग्रेजी में ठीक से काम करता है.
जर्मन अनुवादक तीन अलग थ्री भाग प्राप्त करता है और सही वाक्य नहीं बना सकता क्योंकि शब्द-विन्यास बदलना पड़ता है.
परिणाम: जर्मन उपयोगकर्ता 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' जैसे टेक्स्ट देखते हैं — बेवजह और गैर-पेशेवर.
यह समस्या क्यों है
हर जुड़े हुए स्ट्रिंग एक टाइम बम की तरह टिक-टिक कर रहा है. 20 भाषाओं में और 50 जुड़े हुए स्ट्रिंग्स के साथ 1,000 संभावित ग्रामर त्रुटियाँ होती हैं जिन्हें मैन्युअली ठीक करना पड़ेगा.
जैसे 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' जैसी स्ट्रिंग्स को जोड़ना एक विशेष शब्द क्रम की मांग करता है. अनुवादक को ऐसे fragment मिलते हैं जिन्हें क्रमबद्ध नहीं किया जा सकता.
उपयोगकर्ता व्याकरणिक रूप से गलत वाक्य देखते हैं. जर्मन में क्रिया अक्सर वाक्य के अंत में होती है. अरब के शब्द-विन्यास में संरचना पूरी तरह उलट जाती है. परिणाम पढ़ने में बेकार लगता है.
اسی طرح سے درست کریں
नामित प्लेसहोल्डर के साथ पैरामीटर के रूप में वैरिएबल दें ताकि अनुवादक पूरे वाक्य को फिर से क्रमबद्ध कर सकें.
जोड़ने के बजाय एकल संदेश कुंजी का उपयोग करें जिसमें प्लेसहोल्डर हो: 'cart.summary': 'आपके '{cartType}'-कार्ट में {count} आइटम हैं।'
वैरिएबल्स को फंक्शन के पैरामीटर के रूप में पास करें: t('cart.summary', { count: 5, cartType: 'Premium' }).
अनुवादक अब स्वतंत्र रूप से स्थानांतरित कर सकते हैं: 'आपके '{cartType}'-कार्ट में {count} आइटम हैं' — व्याकरणिक रूप से सही जर्मन।
त्रुटि #3: बहुवचन का अवहेलना
अंग्रेज़ी में बहुवचन के दो रूप होते हैं: एकवचन और बहुवचन. डेवलपर्स अक्सर मान लेते हैं कि सभी भाषाएं एक जैसी तरह से काम करती हैं. ऐसा नहीं है. पॉलिश के 4 रूप हैं, अरबी के 6, और फ्रेंच जैसे कुछ भाषाएं शून्य को अंग्रेज़ी से अलग तरह से हैं.
['हमेशा ICU MessageFormat या उसके समकक्ष लाइब्रेरी का उपयोग करें जो गिनती योग्य सामग्री के लिए हो', 'अपनी खुद की बहुवचन-लॉजिक कभी न लिखें — CLDR नियमों पर भरोसा करें', '0, 1, 2, 5, 21 और 100 जैसे मानों के साथ बहुवचन परीक्षण करें ताकि सभी श्रेणियाँ कवर हों']
गिनती योग्य सामग्री के लिए हमेशा ICU MessageFormat या समान लाइब्रेरी का उपयोग करें।
कभी अपनी खुद की बहुवचन लॉजिक न लिखें — CLDR के नियमों पर भरोसा करें।
सभी श्रेणियाँ कवर करने के लिए 0, 1, 2, 5, 21 और 100 जैसे मानों के साथ बहुवचन का परीक्षण करें।
ایک عام منظر نامہ
डेवलपर लिखता है: count + (count === 1 ? ' Datei' : ' Dateien') — यह जर्मन के लिए सही है.
폴란드어 번역가는 4 형태가 필요합니다: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. 단순 삼항 연산으로는 표현할 수 없습니다.
परिणाम: पोलिश उपयोगकर्ता '5 pliki' (गलत फॉर्म) देखते हैं, बजाय '5 plików' (सही फॉर्म), और ऐप खराब लगती है.
यह क्यों समस्या है
हर गिनने योग्य संज्ञा के लिए आपकी ऐप में बहुवचन नियम की आवश्यकता होती है। 50 ऐसे स्ट्रिंग्स और 20 भाषाओं के साथ 1,000 बहुवचन नियम होते हैं — उन्हें मैन्युअली प्रबंधित करना असंभव है।
सरल if/else चेक (count === 1 ? 'Datei' : 'Dateien') सिर्फ जर्मन/अंग्रेजी को संभालते हैं. CLDR छह बहुवचन श्रेणियाँ तक परिभाषित करता है: zero, one, two, few, many और other. हर भाषा एक भिन्न उपसमुच्चय उपयोग करती है.
उपयोगकर्ता ऐसे व्याकरणिक रूप से गलत पाठ देखते हैं जैसे '1 Nachrichten' या पूरी तरह गलत बहुवचन रूप. औपचारिक संदर्भों में यह विश्वसनीयता को नुकसान पहुँचाता है.
इसे कैसे ठीक करें
ICU MessageFormat का उपयोग करें जो CLDR plurals नियमों का आउट-ऑफ-द-बॉक्स समर्थन देता है.
ICU-sinStruct के साथ संदेश निर्धारित करें: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
अनुवादक अपने भाषा के लिए सभी आवश्यक बहुवचन रूप प्रदान करते हैं. पोलिश: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
आपकी i18n-लाइब्रेरी सक्रिय लोकल के CLDR नियमों के आधार पर रनटाइम के दौरान सही रूप को अपने आप चुन लेती है।
त्रुटि #4: UI-तत्वों की स्थिर चौड़ाई
डिज़ाइनर अंग्रेज़ी में पिक्सेल-लेआउट बनाते हैं, और डेवलपर्स इन्हें फिक्स चौड़ाई के साथ लागू करते हैं। लेकिन अनुवादित टेक्स्ट काफी लंबा या छोटा हो सकता है। जर्मन टेक्स्ट अंग्रेज़ी से लगभग 30% लंबा है, जबकि चीनी टेक्स्ट संभवतः 50% छोटा हो सकता है।
['कोई भी फिक्स्ड पिक्सेल चौड़ाई वाले तत्वों में अनुवादन योग्य टेक्स्ट के लिए कभी भी इस्तेमाल न करें', '40% टेक्स्ट-विस्तार को बेसलाइन के रूप में प्लान करें — कुछ भाषाएँ और भी बढ़ जाती हैं', 'CSS Flexbox या Grid का उपयोग करें ऐसी लेआउट के लिए जो परिवर्तित सामग्री के अनुसार अनुकूल हो']
अनुवाद योग्य पाठ वाले तत्वों के लिए कभी भी निश्चित पिक्सेल चौड़ाई न रखें।
40% टेक्स्ट विस्तार को बेसलाइन के रूप में योजना बनाएं — कुछ भाषाएं और भी विस्तार करती हैं।
ऐसे लेआउट के लिए CSS Flexbox या Grid का उपयोग करें जो बदलते सामग्री के आकार के साथ अनुकूल हो।
एक सामान्य परिदृश्य
डिज़ाइनर 5 बटन वाले नेविगेशन बार बनाते हैं, प्रत्येक की चौड़ाई बिल्कुल 100px — अंग्रेज़ी संस्करण में यह शानदार दिखता है।
जर्मन अनुवाद: 'Settings' को 'Einstellungen' (13 बनाम 8 अक्षर) और 'Submit' को 'Absenden' (8 बनाम 6) बनाते हैं। Navbar ओवरफ्लो हो जाएगा।
परिणाम: मोबाइल डिवाइसों पर बटन एक-दूसरे के ऊपर रखे जाते हैं या पाठ कट जाता है, जिससे जर्मन उपयोगकर्ताओं के लिए नेविगेशन असंगत हो जाता है。
यह समस्या क्यों है
हर स्थिर चौड़ाई वाला तत्व एक संभावित ब्रेकपॉइंट है. एक सामान्य ऐप में सैकड़ों बटन, लेबल और कार्ड होते हैं, जिन्हें כולם टेकסט-विस्तार का सामना करना होता है।
स्थिर चौड़ाई वाला कंटेनर (width: 120px) और स्थिर आकार के बटन पाठ फैलने पर कट जाते हैं या ओवरफ्लो हो जाते हैं. CSS overflow: hidden सामग्री को चुपचाप छुपा देता है, जबकि overflow: visible लेआउट को तह कर देता है।
उपभोक्ता कटे हुए लेबल देखते हैं जैसे 'Einstellu...' के बजाय 'Einstellungen', या बटन जो पड़ोसी तत्वों को ओवरलैप करते हैं. महत्वपूर्ण क्रियाएं पढ़ने योग्य नहीं होतीं या क्लिक-योग्य नहीं रहतीं।
इसे कैसे ठीक करें
ऐसे लचीले लेआउट डिज़ाइन करें और लागू करें जो सभी स्थानीयकरणों के टेक्स्ट की लंबाई के अनुसार सेट हो जाएं।
फिक्स्ड चौड़ाई को min-width, max-width और Flex-Layouts से बदल दें. जगह को डायनामिक रूप से वितरित करने के लिए CSS Grid या Flexbox का उपयोग करें.
टेक्स्ट कंटेनर को ब्रेक के अनुसार लाइन ब्रेक कराने के लिए सेट करें: overflow-wrap: break-word का प्रयोग करें और अनुवाद योग्य सामग्री में white-space: nowrap से बचें.
अपनी UI को Pseudo-लोकलाइजेशन के साथ टेस्ट करें, जो सभी स्ट्रिंग्स को 40% बढ़ाता है, ताकि Worst Case को सिम्युलेट किया जा सके — अनुवादकों को स्ट्रिंग्स भेजने से पहले।
त्रुटि #5: तिथियों और संख्याओं का प्रारूप
डेटा और संख्याएँ दिखती हैं विश्वसनीय, पर 01/02/2025 अमेरिका में 2 जनवरी और यूरोप में 1 फरवरी होता है. संख्याओं में कॉमा और पॉइंट अपनी-अपनी भूमिका बदलते हैं: 1,000.50 (USA) बनाम 1.000,50 (जर्मनी). ऐसा गलत करने से भ्रम, डेटा त्रुटियाँ और विश्वास में कमी होती है।
['शुरुआत से ही सिर्फ तार्किक CSS-प्रॉपर्टीज़ (inline-start/end, block-start/end) का प्रयोग करें', 'हर स्प्रिंट-रीव्यू पर HTML-एलिमेंट पर dir='rtl' के साथ अपने ऐप का परीक्षण करें', 'नेविगेशन, आइकॉन, फ़ॉर्म और प्रगति संकेतक के लिए RTL-चेकलिस्ट बनाएं']
डेटा या संख्याओं को कभी भी मैन्यूअल स्ट्रिंग-टेम्पलेट के साथ फॉर्मेट न करें — हमेशा Intl API का उपयोग करें।
सभी डेटा ISO 8601 में और मुद्राओं को सबसे छोटी इकाई (सेंट) में आंतरिक रूप से संग्रहीत करें।
सभी लोकेलों के साथ टेस्ट करें जो विभिन्न दशमलव चिह्न, तारीख क्रम और कैलेंडर सिस्टम का उपयोग करते हैं।
एक सामान्य परिदृश्य
डेवलपर्स तारीख को MM/DD/YYYY के रूप में और कीमत को $1,234.50 के रूप में फॉर्मेट करते हैं — अमेरिकी उपयोगकर्ताओं के लिए सही।
जर्मन अनुवाद: 'Settings' को 'Einstellungen' (13 बनाम 8 अक्षर) और 'Submit' को 'Absenden' (8 बनाम 6) बनाते हैं। Navbar ओवरफ्लो हो जाएगा।
परिणाम: उपयोगकर्ता गलत तिथि के लिए एक उड़ान बुक करता है और मूल्य फ़ॉर्मेट पर प्रश्न उठाता है. जर्मन बाजार में सपोर्ट टिकट 15% बढ़ते हैं.
यह समस्या क्यों है
तारीखों और संख्याओं का फॉर्मेट सभी डेटा-प्रदर्शनों को प्रभावित करता है: तालिकाएँ, चार्ट, फ़ॉर्म, चालान, रिपोर्टें. एक वैश्विक सुधार सैंकड़ों उदाहरणों को कवर करेगा.
Hardkodierte Formatstrings jaise toLocaleDateString('en-US') ya manually format ke Template-Literals user ki actual locale ko nazarandaz karte hain. Sahi locale hone par bhi galat calendar system (Gregorian vs Hijri) problems karta hai.
उपभोक्ता डेटा को गलत तरीके से पढ़ते हैं और गलत फॉर्मेट में डेटा दर्ज करते हैं। एक यूरोपीय उपयोगकर्ता जिसे 03/04/2025 दिखता है, संभवतः इसे 3 अप्रैल समझ लेता है — मिस्ड अपॉइंटमेंट या गलत बुकिंग।
इसे कैसे ठीक करें
सभी तिथियाँ, समय, संख्याएं और मुद्राओं के लिए बिल्ट-इन Intl API या लोकेल-अनुकूल फ़ॉर्मेटिंग लाइब्रेरी का उपयोग करें।
डेटा/तारीख के लिए Intl.DateTimeFormat(locale) और कीमतों के लिए Intl.NumberFormat(locale, { style: 'currency', currency }) का प्रयोग करके मैन्युअल फ़ॉर्मेटिंग को हटाएं।
डेटा ISO 8601 (YYYY-MM-DD) के फॉर्म में आंतरिक रूप से संग्रहीत करें और केवल प्रदर्शन के लिए उपयोगकर्ता के लोकेल के अनुसार उसे फॉर्मेट करें।
कम से कम 5 अलग-अलग लोकेल में तारीख/संख्या दिखाने के तरीकों का परीक्षण करें: en-US, de-DE, ja-JP, ar-SA और zh-CN, ताकि प्रमुख फॉर्मेटिंग वैरिएंट्स कवर हो सकें।
त्रुटि #6: RTL भाषाओं को भूलना
RTL-समर्थन उन भाषाओं पर असर डालता है जो RTL (Right-To-Left) हैं जैसे अरबी, हिब्रू और फारसी। परंतु ज़्यादातर ऐप्स केवल LTR लेआउट के लिए डिज़ाइन किए जाते हैं। RTL-सपोर्ट केवल टेक्स्ट के रोटेशन तक सीमित नहीं है — पूरा UI कॉम्पोनेंट हर एक पर सही तरह से दर्पणित होना चाहिए.
['शुरुआत से ही सिर्फ तार्किक CSS-प्रॉपर्टीज़ (inline-start/end, block-start/end) का प्रयोग करें', 'हर स्प्रिंट-रीव्यू पर HTML-एलिमेंट पर dir='rtl' के साथ अपने ऐप का परीक्षण करें', 'नेविगेशन, आइकॉन, फ़ॉर्म और प्रगति संकेतक के लिए RTL-चेकलिस्ट बनाएं']
पहले दिन से केवल तारקטिक CSS-प्रॉपर्टीज़ अपनाएं (inline-start/end, block-start/end).
हर स्प्रिंट-रीव्यू पर HTML एलिमेंट पर dir='rtl' के साथ अपनी एप्लिकेशन को टेस्ट करें।
नेविगेशन, आइकॉन, फॉर्म और प्रगति संकेत के लिए RTL-टेस्ट चेकलिस्ट बनाएं।
एक सामान्य परिदृश्य
विकासकर्ता पूरे ऐप में margin-left: 16px और text-align: left का उपयोग करता है — LTR की मानक प्रैक्टिस।
ऐप सऊदी अरब में शुरू होती है. पीछे के बटन forward दिखाते हैं, साइडबार गलत साइट पर दिखाई देते हैं, और संख्यात्मक डेटा सही तरह से नहीं सजते।
परिणाम: अरब उपयोगकर्ता 30 सेकंड के भीतर ऐप छोड़ देते हैं। समस्या हल करने के लिए टीम को 4 सप्ताह के CSS-Refactoring की आवश्यकता होगी।
यह समस्या क्यों है
RTL-समर्थन आपके हर कॉम्पोनेंट पर असर डालता है. RTL को बाद में शामिल करना आम तौर पर CSS के 30-50% नियमों को फिर से लिखना और हर आइकन और लेआउट की जाँच करना आवश्यक बनाता है.
CSS-गुणधर्म जैसे margin-left, padding-right, text-align: left और float: left दिशा को हार्ड-कोड करते हैं. दिशा-निर्देशन वाले आइकॉनों (तीर, प्रगति संकेतक) गलत दिशा में दिखते हैं. यहां तक कि border-radius मान भी प्रतिबिंबित होने चाहिए.
अरब उपयोगकर्ता नेविगेशन गलत दिशा में दिखता है, प्रगति बार पीछे की ओर चलता है, और UI तत्वों के साथ टेक्स्ट टकराता है. ऐप विदेशी और उपयोग में अक्षम महसूस होता है.
इसे कैसे ठीक करें
लॉजिकल CSS-प्रॉपर्टीज़ का इस्तेमाल करें और शुरू से RTL प्लानिंग के साथ अपने ऐप का परीक्षण करें।
सभी फिजिकल CSS-प्रॉपर्टीज़ को लॉजिक समकक्षों से बदलिए: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Active Locale के आधार पर HTML-root तत्व पर dir-attribute सेट करें. RTL-specific override के लिए CSS :dir(rtl) चयनकर्ता کا استعمال کریں۔
सभी आइकॉनों के दिशा-निर्देशन की जाँच करें। दिशा-निर्भर आइकॉनों को mirrored संस्करण से बदल दें या RTL संदर्भों के लिए CSS transform: scaleX(-1) का उपयोग करें।
त्रुटि #7: टेक्स्ट के साथ तस्वीरें
टेक्स्ट को चित्रों में डालना — चाहे वह हीरो बैनर, बटन, इन्फोग्राफिक्स या स्क्रीनशॉट हों — स्थानीयकरण का एक डरावना अनुभव है। हर भाषा के लिए टेक्स्ट वाली प्रत्येक छवि नई बनानी पड़ती है, जिससे डिज़ाइन लागत बढ़ती है और रिलीज़ देरी होती है।
['अनुवादित टेक्स्ट कभी भी सीधे रास्टर इमेज (PNG, JPG) में न डालें', 'हीरो बैनर और CTA के लिए पृष्ठभूमि छवियों पर CSS टेक्स्ट ओवरले का उपयोग करें', 'ऐप स्टोर लिस्टिंग और मार्केटिंग पेज के लिए स्क्रीनशॉट जेनरेशन को ऑटोमेट करें']
कभी भी अनुवाद योग्य टेक्सट को rastr छवियों (PNG, JPG) में सीधे न डालें।
CSS टेक्स्ट ओवरले का उपयोग करें Hero-banner और CTA के लिए।
App Store लिस्टिंग और मार्केटिंग पेज के लिए स्क्रीनशॉट जेनरेशन को ऑटोमेट करें।
एक सामान्य परिदृश्य
एक डिज़ाइनर एक प्रचार बैनर बनाता है जिसमें टेक्स्ट 'Start Your Free Trial' सीधे चित्र में एम्बेड किया गया है.
स्थानीयकरण टीम सभी UI स्ट्रिंग्स का अनुवाद कर देती है, लेकिन जर्मन पृष्ठ पर बैनर अभी भी अंग्रेज़ी पाठ दिखाता है।
परिणाम: जर्मन लैंडिंग पेज पर अंग्रेज़ी बैनर दिखाई देता है जो भ्रमित करता है. 15 भाषाओं के लिए स्थानीयीकृत बैनर बनाना 3 दिन का डिज़ाइन कार्य लेता है और लॉन्च में देरी होती है.
यह समस्या क्यों है
एक सामान्य मार्केटिंग पेज में टेक्स्ट के साथ 5-10 चित्र होते हैं. 15 भाषाओं में यह 75-150 छवि-वेरिएंट बन जाते हैं जिन्हें बनाना, बनाए रखना और हर डिज़ाइन परिवर्तन पर अपडेट करना पड़ता है.
टेक्स्ट जो इमेज में एम्बेडेड है (PNG, JPG, SVG में एम्बेडेड टेक्स्ट) अनुवाद टूल्स से एक्सट्रैक्ट नहीं किया जा सकता। प्रत्येक लोकलाइज़ेशन के लिए डिज़ाइनर को स्रोत फ़ाइल को मैन्युअली संपादित करना, एक्सटोर्ट करना और अपलोड करना पड़ता है।
उपयोगकर्ता अन्य भाषा में टेक्स्ट वाले चित्र देखते हैं, या सबसे बुरा, यूआई के अनुवादित और अनुवाद-रहित चित्रों का मिश्रण। यह असंगत लगता है और ब्रांड की विश्वसनीयता को कमजोर करता है।
इस समाधान को कैसे लागू करें
टेक्स्ट को CSS ओवरले, अनुवादित टेक्स्ट वाले SVGs या डायनेमिक इमेज जनरेशन के साथ छवि से अलग करें.
अनुवादित टेक्स्ट को बैकग्राउंड इमेजेज के ऊपर रखने के लिए CSS का उपयोग करें: टेक्स्ट लेयर को इमेज-कंटेनर के ऊपर absolute पोज़िशनिंग के साथ रखिए।
Infographics या चार्ट के लिए, टेक्स्ट तत्वों के साथ SVGs का उपयोग करें जो अनुवाद-कीज़ को संदर्भित करें, बदले हुए स्ट्रिंग्स को सीधे न डालें.
ऐप स्टोर लिस्टिंग और मार्केटिंग पेज के लिए स्क्रीनशॉट जेनरेशन को ऑटोमेट करें ताकि हर लोकली में स्क्रीनशॉट हों.
त्रुटि #8: लापता अनुवादों को नहीं संभाला गया
विकास के दौरान अनुवाद हमेशा अधूरा रहता है. नई सुविधाएं स्ट्रिंग्स को जल्दी जोड़ती हैं, जितना अनुवादक उन्हें अनुवाद कर सकते हैं. सही fallback-ह Händling के बिना, गायब अनुवाद क्रैश, खाली UI एलिमेंट्स या यूज़र को कच्चे अनुवादन‑की दिखते हैं.
['अपने i18n-सेटअप में कम से कम एक fallback-भाषा हमेशा कॉन्फ़िगर करें', 'अनुवाद-ग़ायब कुन्जियों को अपने मॉनिटरिंग सिस्टम पर लॉग करें ताकि ट्रैक किया जा सके', 'किसी लोकेल को लाइव जाने से पहले न्यूनतम अनुवाद कवरेज स्तर सेट करें']
i18n सेटअप में कम से कम एक फallback भाषा को हमेशा कॉन्फ़िगर करें।
अनुपलब्ध अनुवाद कुंजी को अपने मॉनिटरिंग सिस्टम में लॉग करें ताकि ट्रैक किया जा सके।
एक न्यूनतम अनुवाद कवरेज निर्धारित करें ताकि कोई लोकैल लाइव हो सके।
एक सामान्य परिदृश्य
डेवलपर्स ने 15 नए अनुवाद कुंजी के साथ एक नया 'Premium Features' सेक्शन जोड़ा। अंग्रेज़ी संस्करण तुरंत जारी किया गया।
फ्रेंच अनुवाद अभी तक पूरे नहीं हैं। फ्रेंच पेज पर रॉ कीज़ दिख रहे हैं: 'premium.feature1.title', 'premium.feature1.description'.
परिणाम: फ्रांसीसी उपयोगकर्ता एक टूटी हुई पेज देखते हैं, जिसमें डेवलपर-पक्ष की कुंजी के नाम भरे होते हैं। सपोर्ट टीम को दर्जनों बग-रिपोर्ट मिलते हैं।
यह समस्या क्यों है
जैसे-जैसे आपकी ऐप बड़ेगी, अंग्रेजी स्ट्रिंग्स और अन्य भाषाओं के अनुवादों के बीच अंतर बढ़ेगा। 100 भाषाओं और 2,000 स्ट्रिंग्स वाली ऐप कभी भी 10,000+ गायब अनुवाद रख सकती है।
fallback- लॉजिक के बिना, गायब अनुवाद कुंजी undefined, null या कच्चा कुंजी‑स्ट्रींग लौटाती है (जैसे 'checkout.confirmButton'). Template इंजन त्रुटियाँ फेंक सकते हैं, पेज क्रैश हो सकता है या कुछ भी रेंडर नहीं होगा.
उपयोगकर्ता खराब UI देखते हैं: खाली बटन, गायब लेबल, या 'nav.settings.title' जैसे अस्पष्ट स्ट्रिंग्स असली टेक्स्ट की जगह। यह भ्रमित करने वाला और असंप्रोफेशनल है.
इसे कैसे ठीक करें
एक मजबूत fallback श्रृंखला कॉन्फ़िगर करें और सभी लोकेलों में अनुवाद कवरेज की निगरानी करें.
अपनी i18n कॉन्फ़िगरेशन में एक fallback-भाषा चेन सेट करें: FR फ्रेंच keys(fr) गायब होने पर स्वतः EN अंग्रेज़ी(en) पर लौटेंगे.
एक Missing-Key-Handler जोड़ें जो अनुवादित न किए गए कुंजियों को आपके मॉनिटरिंग-सिस्टम (जैसे Sentry, Datadog) पर लॉग करे, उपयोगकर्ता अनुभव में बाधा डाले बिना।
एक अनुवाद कवरेज डैशबोर्ड बनाएं जो हर लोकेल के अनुसार पूर्णता ट्रैक करे और कवरेज थ्रेशोल्ड से नीचे गिरने पर रिलीज़ को ब्लॉक करे (उदा. 95%).
त्रुटि #9: कैरेक्टर इन्कोडिंग समस्याएं
चर अक्षर एन्कोडिंग समस्याएं स्थानीयकरण की चुपचाप हत्या हैं। सब कुछ अंग्रेज़ी और यूरोपीय भाषाओं में ठीक लगता है, पर जब आप चीनी, जापानी, कोरियाई, अरबी या इमोजी जोड़ते हैं, विकृत अक्षर (Mojibake) दिखते हैं। ये बग्स पहचाने जाने में बहुत कठिन होते हैं।
['सबھی جگہ UTF-8 एन्कोडिंग का उपयोग करें — स्रोत फ़ाइलें, डेटाबेस, API-रेस्पांस और HTML मेटा-टैग्स', 'MySQL में utf8mb4 का प्रयोग करें ( utf8 नहीं ), ताकि Unicode का पूरा दायरा सपोर्ट हो सके', 'CJK, अरबी और इमोजी में वास्तविक कंटेंट के साथ टेस्ट करें ताकि कोडिंग समस्याएं जल्दी फँस सके']
हर जगह UTF-8 एन्कोडिंग का उपयोग करें — स्रोत फ़ाइलें, डेटाबेस, API प्रतिक्रियाएं और HTML मेटा-टैग।
MySQL में utf8mb4 का उपयोग करें (utf8 नहीं) ताकि पूरा यूनिकोड सपोर्ट हो, जिसमें इमोजी भी आते हैं।
CJK, अरबी और इमोजी में वास्तविक सामग्री के साथ परीक्षण करें ताकि एन्कोडिंग समस्याओं को जल्दी पकड़ सकें।
एक सामान्य परिदृश्य
डेवलपर्स एक MySQL डेटाबेस latin1 कोलोशन के साथ सेटअप करते हैं (पुरानी डिफ़ॉल्ट). एप्लिकेशन कोड UTF-8 का उपयोग करता है।
जापानी उपयोगकर्ता अपने वास्तविक नाम से पंजीकरण करते हैं। डेटाबेस '田中太郎' को खराब बाइट्स के रूप में स्टोर करता है。
परिणाम: उपयोगकर्ता प्रोफाइल में टुकड़ा टेक्स्ट दिखाई देता है. सबसे बुरा: खोज और क्रमबद्धता सभी CJK नामों के लिए टूट जाते हैं, जिससे हजारों उपयोगकर्ता प्रभावित होते हैं.
यह समस्या क्यों है
कोडिंग समस्याएं आपके पूरे स्टैक में फैलती हैं. डेटाबेस की गलत कोलैशन (Collation) मिलियन रिकॉर्ड्स को नुकसान पहुंचा सकती है — मरम्मत में महंगे डेटा माइग्रेशन की ज़रूरत पड़ेगी.
Stack के पूरे हिस्सों में असंगत कैरेक्टर एन्कोडिंग — स्रोत फ़ाइलों में UTF-8, डेटाबेस में Latin-1 और API उत्तर में Windows-1252 — बहु-वाइट अक्षर (Multibyte) अक्षरों को बिगाड़ देती है. एक गलत कॉन्फ़िगर किया गया स्तर '日本語' को '????' या '日本èª' में बदल सकता है.
उपयोगकर्ता विकृत पाठ देखते हैं, प्रश्न चिह्न या खाली बॉक्स दिखते हैं, जहां उनकी भाषा होनी चाहिए। सबसे खराब स्थिति में फॉर्म इनपुट डेटाबेस में स्थायी रूप से खराब हो सकता है।
इसे कैसे ठीक करें
अपने एप्लिकेशन स्टैक की हर परत में UTF-8 एन्कोडिंग को संगत ढंग से लागू करें.
सभी सोर्स फ़ाइलों को UTF-8 पर सेट करें (अपने एडिटर और .editorconfig को कॉन्फ़िगर करें). HTML में <meta charset='UTF-8'> जोड़ें और API उत्तरों में 'Content-Type: application/json; charset=utf-8' सेट करें.
अपने डेटाबेस को utf8mb4 पर कॉन्फ़िगर करें (केवल utf8 नहीं, जो MySQL में 3-बाइट सब्सेट है). कनेक्शन-कॉलैशन को utf8mb4_unicode_ci पर सेट करें।
अपने लक्षित लेखन प्रणालियों को कवर करने वाले फॉन्ट चुनें: लैटिन, सिरिलिक, CJK, अरबी, देवनागरी. बेहतर लोड के लिए System-Font-Stacks या Google Fonts में भाषाई उप-सेट्स का उपयोग करें।
अपने i18n-इम्प्लीमेंटेशन का परीक्षण करें
लंबाई-विस्तार परीक्षण
इन सभी अनुदित स्ट्रिंग्स को 30-40% बढ़ाएं ताकि टेक्सचर विस्तार का अनुकरण किया जा सके जो कठिन भाषाओं जैसे जर्मन, फिनिश या ग्रीक में होता है। यह फिक्स्ड-वाइड कंटेनर, कटे हुए लेबल और ओवरफ्लो बटन को कवर करता है, इससे पहले कि आप अनुवाद शुरू करें। कई pseudo-localization टूल इसे बिल्ट-इन फीचर के रूप में प्रदान करते हैं।
"Senden" → "Ṡééééñðéñ_éxpáñðéð" (40% लंबा)
प्सूडो-लोकालाइज़ेशन
प्स्यूडो-लोकालिज़ेशन हर अक्षर को एक accented समकक्षक से बदल देता है (जैसे, 'a' → 'á') और स्ट्रिंग्स को [!! और !!] जैसी मार्कअप के साथ घेरता है। इससे तुरंत स्पष्ट होता है कि कौन-सी स्ट्रिंग्स hard-coded हैं और कौन सी अनुवादन-प्रणाली से आती हैं। CI पाइपलाइन का भाग बनकर प्यूज़्डो-लोकालिज़ेशन चलाएं ताकि रिग्रेशन अपने आप पकड़ में आ सके।
हर स्क्रीन टेक्स्ट जो [!! !!]-मार्कअप के भीतर नहीं है, वह हार्ड-कोडेड है और उसे बाहर निकाला जाना चाहिए। यह परीक्षण 95% ऐसे स्ट्रिंग्स पकड़ लेता है जिन्हें एक मिनट से कम समय में नहीं पाया गया।
"संदेश भेजें" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
RTL-लेआउट परीक्षण
यसी RTL-डिज़ाइन टेस्ट बिना अरेबिक या हीब्रू भाषा अनुवाद के भी किया जा सकता है: HTML के रूट एलीमेंट में dir='rtl' जोड़कर. इससे CSS दिशा-गत होने वाले बग्स जैसे गलत आइकॉन-लाइनिंग, गलत साइट-मार्ग, खराब नेविगेशन और गलत Flex-आइटम-排序 तुरंत पकड़ में आते हैं. इसे हर स्प्रिंट-रेव्यू में मानक चेक बनाएं — स्विच करने में 10 सेकंड लगते हैं औरProduction में फंसने वाली समस्याओं को पकड़ लेता है.
i18n-चेकलिस्ट
['यूज़र-से पाहे जाने वाले सभी स्ट्रिंग resources फाइलों में आउटसोर्स करें', 'SENTENCE बनाने के लिए स्ट्रिंग-जोड़ना (string concatenation) का प्रयोग न करें', ' ICU MessageFormat या समकक्ष के साथ बहुवचन नियम लागू करें', 'तारीख, समय और संख्याओं के फॉर्मेटिंग में locale-aware APIs का उपयोग करें', 'RTL-लेआउट अरबी या हिब्रू सामग्री के साथ टेस्ट किया गया', 'टेक्स्ट-भरे तत्वों के लिए Flexible UI बिना निश्चित चौड़ाई के', 'फॉलबैक भाषा कॉन्फ़िगर और ग़ायब keys पर परीक्षण करें', 'UTF-8 कोडिंग सभी फ़ाइलों और डेटाबेस में सुसंगत', 'हर मार्केट के लिए App Store और Play Store मेटाडेटा स्थानीयीकृत', 'हर भाषा के लिए स्क्रीनशॉट और मार्केटिंग-एसेट्स अपडेट करें']