अंतर्राष्ट्रीयकरण परामर्श: जो टूट रहा है उसे ठीक करें, आगे की योजना बनाएँ
आप पहले से जानते हैं कि i18n कितना मुश्किल है। मैंने इसके लक्षण देखे हैं: RTL लेआउट जो बिखर जाते हैं, जर्मन टेक्स्ट जो बटनों से बाहर निकल जाता है, ग़लत भाषा में आने वाले API रिस्पॉन्स, और अनुवाद जो लॉन्च के कुछ ही हफ़्तों में बेमेल हो जाते हैं। मैं कोई चमत्कारी समाधान नहीं बेचता। मैं आपकी टीम जिस उलझन में फँसी है, उसे सुलझाने में मदद करता हूँ — और ऐसे सिस्टम बनाता हूँ जो एक ही तरह से दोबारा न टूटें।
"हमें यह पहले से प्लान करना चाहिए था"
आर्किटेक्चर टैक्स जो आप अभी चुका रहे हैं
आपने अंग्रेज़ी में लॉन्च किया। काम कर गया। फिर आपने "बस लैंडिंग पेज के लिए" फ़्रेंच जोड़ी। अब आप यहाँ हैं क्योंकि:
आपके कोडबेस में lang= जाँचें 47 फ़ाइलों में बिखरी हुई हैं
प्रोडक्ट मैनेजर पूछते हैं "क्या हम कॉपी का A/B टेस्ट कर सकते हैं?" और इंजीनियरिंग कहती है "पूरी तरह से दोबारा लिखे बिना नहीं"
आपके पास तीन अलग-अलग अनुवाद कार्य-प्रवाह हैं और उनमें से कोई भी ठीक से काम नहीं करता
मैंने किन चीज़ों में खराबी देखी है:
- टीमें 6+ महीने लगाकर Next.js ऐप में i18n रेट्रोफ़िट कर रही हैं, क्योंकि स्ट्रिंग्स कंपोनेंट्स में हार्डकोड थीं
- अनुवाद फ़ाइलें सिंक से बाहर हो जाती हैं क्योंकि डेवलपर्स को पता ही नहीं होता कि कौन सी फ़ाइल अपडेट करनी है
- रिलीज़ से पहले "स्थानीयकरण फ़्रीज़" की अवधियाँ — क्योंकि अनुवाद प्रक्रिया पर किसी को भरोसा नहीं
- अनुवादित सामग्री में बदलाव करने से कतराना क्योंकि वर्कफ़्लो बहुत कठिन है
मैं किसमें मदद करता हूँ:
- रीफ़ैक्टरिंग रणनीतियाँ जो आपको i18n को चरणबद्ध तरीके से अपनाने में मदद करती हैं (मैं यह नहीं कहता कि सब कुछ रोको और दोबारा लिखो)
- डेवलपमेंट रोके बिना अनुवादों को सिंक में रखने के लिए प्रक्रिया डिज़ाइन
- आर्किटेक्चर समीक्षा — ताकि पता चल सके कि 10+ भाषाओं पर आपका मौजूदा तरीका कहाँ फ़ेल होगा
i18n आर्किटेक्चर है, कोई सुविधा नहीं। इसे बाद में जोड़ने की कोशिश करना वैसा ही है जैसे घर बन जाने के बाद तय करना कि उसमें तहख़ाना भी होना चाहिए।
मैं आपकी वो बेसमेंट बनाने में मदद करता हूँ—या यह तय करने में कि आपको सच में इसकी ज़रूरत है भी या नहीं।
RTL सब कुछ तोड़ देता है
आपका यूआई अरबी, हिब्रू या उर्दू के लिए डिज़ाइन नहीं किया गया था
आपने dir="rtl" लगाया और देखा कि आपका लेआउट बिखर गया:
मैंने क्या देखा है:
- 200+ कंपोनेंट्स वाले डिज़ाइन सिस्टम, जिनमें से सिर्फ़ 12 ही RTL को सही से संभाल पाते हैं
- टीमें logical properties की जगह float: left इस्तेमाल कर रही हैं, जिससे हर नई सुविधा में RTL बग आ रहे हैं
- पॉपओवर और मोडल जिनमें कंपोनेंट-विशिष्ट RTL ओवरराइड की ज़रूरत पड़ती है
- "RTL सपोर्ट" का दावा करने वाले फ्रेमवर्क जो केवल लेआउट दिशा को पलटते हैं, लेकिन प्लेसमेंट लॉजिक को बिगाड़ देते हैं।
मैं इनमें मदद करता हूँ:
- CSS लॉजिकल प्रॉपर्टीज़ माइग्रेशन (margin-left की जगह margin-inline-start)
- RTL की छिपी समस्याओं को प्रोडक्शन में जाने से पहले पकड़ने के लिए डिज़ाइन सिस्टम ऑडिट
- RTL-first स्टाइलिंग के लिए फ़्रेमवर्क के अनुसार मार्गदर्शन (Tailwind, shadcn, MUI)
हर कंपोनेंट में RTL बग को हाथ से ठीक करते रहना चल नहीं सकता। मैं RTL support को व्यवस्थित बनाता हूँ — लगातार आग बुझाने की कवायद नहीं।
"जर्मन टेक्स्ट ने हमारे बटन को खराब कर दिया"
ऐसा UI जो अनुवाद को ध्यान में रखकर नहीं बनाया गया
अंग्रेज़ी फ़िट हो जाती है। जर्मन नहीं। आपके डिज़ाइन ने यह माना था:
फिर आपने जर्मन, फ़िनिश या थाई में अनुवाद किया और पता चला:
बटन शब्द के बीच में कट जाते हैं
हर पंक्ति में हॉरिज़ॉन्टल स्क्रॉल वाली टेबलें
टेक्स्ट जो अपठनीय ब्लॉक्स में टूट जाता है
गैर-लैटिन टेक्स्ट कट रहा है क्योंकि कंटेनरों की चौड़ाई निश्चित है
मैं किसमें मदद करता हूँ:
- लचीले UI पैटर्न जो कंटेंट की लंबाई के हिसाब से ढल जाते हैं
- कैरेक्टर बजट की योजना (जर्मन में 30% बढ़ जाता है, थाई में स्पेस नहीं होते)
- टाइपोग्राफी सिस्टम जो CJK, अरबी और देवनागरी को बिना किसी समस्या के संभालते हैं।
मैं आपको ऐसा UI बनाने में मदद करता हूँ जो अनुवाद के बाद भी ठीक से काम करे—इससे पहले कि आप 10,000 ऐसे शब्दों के लिए भुगतान करें जो UI में फिट ही न हों
आपको i18n की अहमियत पर कोई लेक्चर देने की ज़रूरत नहीं है। आपको ऐसा कोई चाहिए जिसने रात 2 बजे RTL पॉपओवर डीबग किए हों, प्रोडक्ट से कैरेक्टर बजट पर बहस की हो, और ऐसी ट्रांसलेशन पाइपलाइन डिज़ाइन की हों जो सच में काम करती हों।
वो पेचीदगियाँ जिनके बारे में किसी ने नहीं बताया
उन टीमों की संघर्ष कहानियाँ जो इससे गुज़र चुकी हैं
ये सैद्धांतिक नहीं हैं। ये वो चीज़ें हैं जो प्रोडक्शन में खराब हो गईं:
बहुवचन का नरक
अंग्रेज़ी: "1 item" बनाम "2 items"
पोलिश: "1 przedmiot" / "2 przedmioty" / "5 przedmiotów" (3 बहुवचन रूप)
अरबी: 6 बहुवचन रूप
आपका count === 1 ? 'item' : 'items' लॉजिक अब काम नहीं करता है।
तारीख/समय की गड़बड़ी
आपने toLocaleDateString() से तारीखें फ़ॉर्मेट कीं। फिर जापान के यूज़र्स ने आपके CSV एक्सपोर्ट में "2025年2月9日" देखा और Excel ने हाथ खड़े कर दिए।
API भाषा मिसमैच
आपका फ़्रंटएंड फ़्रेंच माँगता है। आपका API अंग्रेज़ी भेजता है क्योंकि auth टोकन में locale नहीं होता। नतीजा: मिश्रित भाषा का UI, और यूज़र इसे बग समझते हैं।
स्यूडो-लोकेल टेस्टिंग
आपने प्रोडक्शन में जाने से पहले [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] के साथ परीक्षण नहीं किया। अब आपकी पोलिश साइट अनुपयोगी है।
अदृश्य धारणा
आपने मान लिया कि बस स्ट्रिंग्स का अनुवाद करना है। फिर सामने आईं तारीखें, संख्याएँ, मुद्राएँ, सॉर्टिंग, सर्च—हर चीज़ का व्यवहार locale के हिसाब से अलग होता है।
मैं किसमें मदद करता हूँ:
- ICU MessageFormat कार्यान्वयन (बहुवचन, लिंग, संदर्भ को संभालता है)
- API i18n पैटर्न (भाषा नेगोशिएशन, फ़ॉलबैक रणनीतियाँ)
- ऐसी QA प्रक्रियाएँ जो इन समस्याओं को अनुवाद एजेंसियों से पहले पकड़ लें
असली मुश्किल हिस्सा कार्यप्रवाह है
रोज़ाना शिप करते हुए 8 भाषाओं को सिंक में कैसे रखें?
आपने तकनीक समझ ली है। अब आप प्रक्रिया में फँसे हैं:
डेवलपर्स नई अंग्रेज़ी स्ट्रिंग्स के साथ कोड मर्ज करते हैं। अनुवाद 2 हफ़्ते पीछे रह जाते हैं। यूज़र्स को आधा-अनुवादित UI दिखता है।
आपको नहीं पता कि कौन सी स्ट्रिंग्स हटाना सुरक्षित है (क्या वे इस्तेमाल हो रही हैं? अनुवादित हैं? किसी एजेंसी के पास प्रक्रिया में हैं?)
प्रोडक्ट टीम कॉपी अपडेट करना चाहती है। किसी को नहीं पता कि "Submit" को "Send" में बदलने से 12 भाषाएँ टूटेंगी या नहीं।
अनुवाद फ़ाइलें हफ़्तों तक प्रोडक्शन के साथ सिंक में बनी नहीं रहतीं
टीमें जो सवाल मुझसे पूछती हैं:
मैंने किन चीज़ों में खराबी देखी है:
- Git में चेक इन की गई अनुवाद फ़ाइलें जो प्रोडक्शन स्ट्रिंग्स से भिन्न हो जाती हैं
- "स्पेनिश फ़ाइल को मत छुएँ" की चेतावनियाँ क्योंकि किसी को पता नहीं कि क्या बदलना सुरक्षित है
- सुविधाएँ अंग्रेज़ी में लॉन्च हुईं, फिर 6 महीने बाद अनुवाद हुआ (अगर कभी हुआ तो)
मैं किसमें मदद करता हूँ:
- अनुवाद पाइपलाइन डिज़ाइन (i18n लाइब्रेरीज़ कब इस्तेमाल करें, TMS कब इस्तेमाल करें, AI कब इस्तेमाल करें)
- सोर्स स्ट्रिंग्स और अनुवादों को सिंक में रखने के लिए Git वर्कफ़्लो
- ऑटोमेशन जो नई स्ट्रिंग्स अनुवाद के लिए मार्क नहीं होने पर PRs को ब्लॉक कर दे
तकनीक तो हल हो जाती है। असली बाधा कार्यप्रवाह है। मैं ऐसे कार्यप्रवाह डिज़ाइन करता हूँ जिन्हें बनाए रखने के लिए किसी असाधारण मेहनत की ज़रूरत नहीं पड़ती।
मैंने इन टीमों के साथ काम किया है
वैश्विक उत्पाद, क्षेत्रीय विशेषज्ञता
LINE (जापान, ताइवान, थाईलैंड)
3 प्रमुख पूर्वी एशियाई बाज़ारों में संचालित मैसेजिंग प्लेटफ़ॉर्म। CJK वर्णों को संभालने, प्लेटफ़ॉर्म इकोसिस्टम एकीकरण और यूज़र अनुभव की अपेक्षाओं से जुड़ी चुनौतियों पर काम किया, जो जापान, ताइवान और थाईलैंड में अलग-अलग हैं।
KakaoTalk (दक्षिण कोरिया)
कोरिया का प्रमुख मैसेजिंग प्लेटफ़ॉर्म। कोरियाई बाज़ार की विशिष्ट उत्पाद आवश्यकताओं पर काम किया, जिसमें UI में भाषा की औपचारिकता की अपेक्षाएँ और प्लेटफ़ॉर्म एकीकरण की ज़रूरतें शामिल हैं।
Change.org (196 देश, 20+ प्राथमिकता भाषाएँ)
वैश्विक याचिका प्लेटफ़ॉर्म जहाँ कंटेंट की गति और गुणवत्ता दोनों महत्वपूर्ण हैं। विविध बाज़ारों में यूज़र-जनरेटेड राजनीतिक/सामाजिक कंटेंट के लिए अनुवाद वर्कफ़्लो को सुव्यवस्थित करने में मदद की।
Airbnb (220+ देश, 60+ भाषाएँ)
जटिल i18n आवश्यकताओं वाला वैश्विक बाज़ार। कई भाषाओं में विश्वास/सुरक्षा की चुनौतियों और विभिन्न बाज़ारों में प्लेटफ़ॉर्म अवधारणाओं के सांस्कृतिक अनुकूलन पर परामर्श दिया।
Intercom (30+ भाषाएँ, वैश्विक B2B SaaS)
ग्लोबल एंटरप्राइज़ क्लाइंट्स के लिए कस्टमर कम्युनिकेशन प्लेटफ़ॉर्म। रियल-टाइम सपोर्ट टूलिंग और नॉलेज बेस स्थानीयकरण के लिए प्रोडक्ट अंतर्राष्ट्रीयकरण पर काम किया।
Lilith Games (चीन, जापान, कोरिया, अमेरिका, यूरोप)
मोबाइल गेम प्रकाशक जिनके टाइटल्स दुनिया भर में वितरित हैं। कॉन्टेंट लोकलाइज़ेशन और क्षेत्रीय प्लेटफ़ॉर्म आवश्यकताओं से जुड़ी बाज़ार-विशिष्ट चुनौतियों का समाधान किया।
जिन बाज़ारों में मैंने लॉन्च किया है:
पूर्वी एशिया (जापान, कोरिया, चीन):
CJK टाइपोग्राफ़ी, प्लेटफ़ॉर्म इकोसिस्टम इंटीग्रेशन, वर्टिकल टेक्स्ट सपोर्ट
दक्षिण-पूर्व एशिया (थाईलैंड, वियतनाम, इंडोनेशिया):
मल्टी-स्क्रिप्ट सपोर्ट, मोबाइल-फ़र्स्ट उपयोगकर्ता अपेक्षाएँ
MENA (अरबी भाषी क्षेत्र):
RTL लेआउट आवश्यकताएँ, औपचारिक बनाम बोलचाल की भाषा की अपेक्षाएँ, सांस्कृतिक सामग्री का अनुकूलन
यूरोप:
24 आधिकारिक भाषाएँ, बहु-देशीय उत्पाद लॉन्च
अमेरिका:
क्षेत्रीय भाषा भिन्नताएँ (लैटिन अमेरिकी स्पैनिश बनाम स्पेन की स्पैनिश, ब्राज़ीलियाई पुर्तगाली), द्विभाषी बाज़ार
मैंने देखा है कि इन बाज़ारों में क्या काम करता है और क्या नहीं—सिद्धांत से नहीं, बल्कि ऐसे प्रोडक्ट्स लॉन्च करने से जिन पर वास्तविक यूज़र्स निर्भर करते हैं।
आइए जो टूट रहा है उसे ठीक करते हैं
आपको i18n की अहमियत पर कोई लेक्चर देने की ज़रूरत नहीं है। आपको ऐसा कोई चाहिए जिसने रात 2 बजे RTL पॉपओवर डीबग किए हों, प्रोडक्ट से कैरेक्टर बजट पर बहस की हो, और ऐसी ट्रांसलेशन पाइपलाइन डिज़ाइन की हों जो सच में काम करती हों।
आर्किटेक्चर और रणनीति समीक्षा (1-2 हफ़्ते):
मैं आपको बताता हूँ कि अगली 3 भाषाएँ जोड़ने पर क्या टूटेगा, और उसे ठीक करने में कितना खर्च आएगा
मार्केट लॉन्च सपोर्ट (4-8 हफ़्ते):
आप जापान/MENA/EU में लॉन्च कर रहे हैं और आपको ऐसे विशेषज्ञ चाहिए जिन्होंने यह पहले किया हो
निरंतर साझेदारी:
जैसे-जैसे आप 2 भाषाओं से 20 तक स्केल करते हैं, एम्बेडेड कंसल्टिंग
मैं सिद्धांतों में नहीं उलझता। मैं प्राथमिकता तय करता हूँ, रोडमैप बनाता हूँ, और प्रोडक्ट शिप करता हूँ।