i18n टूटा हुआ है: अनुवाद कुंजियाँ लिखना बंद करें

अंतरराष्ट्रीयीकरण (अक्सर i18n कहा जाता है), स्थानीयकरण (l10n), और बहुभाषी समर्थन — ये सभी एक ही विचार को दर्शाते हैं: अपने उत्पाद को इस तरह ढालना कि लोग उसे अपनी भाषा में इस्तेमाल कर सकें।

i18n अब भी 2005 वाली ही बनावट में है

हर व्यवसाय अंततः समझ जाता है कि उन्हें कई भाषाओं का समर्थन करना होगा। उस समय प्रोडक्ट टीम मैकेनिक की तरह पीछे झुकती है, दाँतों के बीच से हवा खींचती है, और कहती है, “कितने पन्नों की बात है? कम से कम चार स्प्रिंट तो लगेंगे।”

i18n को लागू करने का हमारा मूल तरीका पिछले 20 सालों में नहीं बदला है। i18n की ज़्यादातर “best practices” आधुनिक वेब आर्किटेक्चर के बहुत पहले ही बन चुकी थीं, और उसके बाद जो भी हुआ, वह बस उनके ऊपर परत-दर-परत जुड़ता गया है।

I18n आधुनिक वेब डेवलपमेंट का एकमात्र हिस्सा है जिसमें अब भी फ़ाइलें एक्सपोर्ट करना और उन्हें किसी को भेजना शामिल है। अगर उन्हें ईमेल करने के बजाय आप API के ज़रिए अपलोड कर दें, तो इसे आधुनिक सेटअप माना जाता है।

एक ऐसी दुनिया में जहाँ CI पाइपलाइनें और deploys दिनों की बजाय मिनटों में मापे जाते हैं, हमें शायद खुद को खुशकिस्मत समझना चाहिए कि हमें कुछ भी fax नहीं करना पड़ता।

i18n क्यों टूटा हुआ लगता है

आधुनिक web development बहुत तेज़ी से आगे बढ़ा है।

हमारे पास है:

• सर्वर-रेंडर किए गए कंपोनेंट्स
• स्ट्रीमिंग UI
• एज रनटाइम्स
• निरंतर डिप्लॉयमेंट
• AI-नेटिव टूलिंग

फिर भी, अंतरराष्ट्रीयकरण वर्कफ़्लो अब भी किसी और ही दौर के लगते हैं।

यहाँ तक कि अपेक्षाकृत छोटे ऐप्स भी जल्दी ही इन चीज़ों को संभालते-सम्भालते पहुँच जाते हैं:

• translation keys
• JSON अनुवाद फ़ाइलें
• मैनुअल अनुवाद पाइपलाइनें
• अलग-थलग फ्रंटएंड बनाम बैकएंड लोकलाइज़ेशन लॉजिक
• अनुवाद प्रबंधन टूल्स

डेवलपर ऐसे सिस्टम बनाने के इरादे से शुरुआत नहीं करते। वे इसमें अनजाने में फँस जाते हैं, क्योंकि i18n की आम अड़चनें उन डेवलपर्स को उलझा देती हैं जो यह नहीं जानते कि अलग-अलग भाषाएँ वाक्यों की रचना बिल्कुल अलग तरीके से करती हैं… और मजबूरी में 20 साल पहले तय किए गए status quo को स्वीकार कर लेते हैं।

समय के साथ, अंतरराष्ट्रीयकरण स्टैक के सबसे जटिल हिस्सों में से एक बन जाता है।

आधुनिक UI अनुवाद स्ट्रिंग्स में फिट नहीं बैठता

एक साधारण UI पर विचार करें:

<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

यह समझना आसान है। यह सरल है।

किसी बिंदु पर हम इसे अंतरराष्ट्रीय बनाना तय करते हैं। इसलिए, हम टेक्स्ट को एक अनुवाद फ़ाइल में निकाल लेते हैं:

{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

और हम अपने कोड में उसका संदर्भ लेते हैं:

<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

लेकिन, रुको, क्या अब हमारे code में भी English text है, और हमारी translation file में भी? हाँ। अलग-अलग i18n libraries इसे अलग तरीके से पेश करती हैं, लेकिन जो text आंशिक रूप से formatted है उसे बाहर निकालकर human-readable JSON file में रखकर translate करने की कोशिश एक हारने वाली लड़ाई है।

आधुनिक UI संरचित होता है, लेकिन अनुवाद प्रणालियाँ सपाट स्ट्रिंग्स की नींव पर बनी होती हैं।

जैसे ही मार्कअप, वेरिएबल्स, और डायनामिक सामग्री सामने आती है, अमूर्तता में दरार पड़ने लगती है।

डायनेमिक और यूज़र-जनरेटेड कंटेंट पारंपरिक i18n को तोड़ते हैं

जब कंटेंट स्थिर नहीं होता, तो चीज़ें और भी कठिन हो जाती हैं।

इस उदाहरण को फिर से देखें:

<b>{serverResponse.productDescription}</b>

वह स्ट्रिंग एक API से आ रही है। हम उसे अनुवाद कुंजी में कैसे बदलें?

संकेत: नहीं। अब आपके बैकएंड को भी अंतरराष्ट्रीयकरण का समर्थन करना होगा।

अब आपके backend को यह सब संभालना होगा:

• मूल अर्थपूर्ण डेटा
• translated variants
• फ़ॉलबैक लॉजिक
• लोकेल का पता लगाना

ट्रांसलेटर्स को अचानक backend systems तक भी पहुँच चाहिए होती है।

और जब यूज़र-जनरेटेड कंटेंट तस्वीर में आता है, तो समस्या और बढ़ जाती है।

Reviews. Comments. Marketplace listings. Forums.

पारंपरिक i18n पाइपलाइन यह मानती हैं कि डेवलपर सारे टेक्स्ट को नियंत्रित करते हैं। अब यह बात लगातार सच नहीं रही।

यह तथ्य कि Amazon जैसी कंपनियों ने 2026 में अनूदित उपयोगकर्ता समीक्षाओं के साथ प्रयोग शुरू किए हैं, यह बहुत कुछ बताता है कि i18n इकोसिस्टम कितनी धीमी गति से विकसित हुआ है।

Locale Detection अभी भी एक गड़बड़झाला है

यह तय करना कि उपयोगकर्ता कौन-सी भाषा चाहता है, हैरान करने वाली हद तक जटिल है।

ब्राउज़र Accept-Language हेडर के ज़रिए भाषा प्राथमिकताएँ भेजते हैं:

Accept-Language: en-GB,en;q=0.9,fr;q=0.8

यह सर्वर को बताता है:

1. ब्रिटिश अंग्रेज़ी को प्राथमिकता दें
2. फिर अंग्रेज़ी का कोई भी रूप
3. फिर किसी भी तरह की फ़्रेंच

व्यावहारिक रूप से, इसे सही ढंग से लागू करने में यह शामिल होता है:

• पार्सिंग क्वालिटी वेट्स
• locales को normalise करना (en, en-GB, en-US)
• समर्थित भाषाओं का मिलान
• fallback logic को संभालना
• स्पष्ट उपयोगकर्ता ओवरराइड का सम्मान करते हुए

कई फ़्रेमवर्क यह सारी लॉजिक ज़्यादातर डेवलपर्स पर छोड़ देते हैं।

यहाँ तक कि basic locale detection भी अक्सर custom application code बन जाती है।

भाषा बदलना बाद में सोचा जाता है

अनुवाद इन्फ्रास्ट्रक्चर समस्या का सिर्फ आधा हिस्सा है।

उपयोगकर्ताओं को अब भी भाषा बदलने का तरीका चाहिए।

ज़्यादातर i18n लाइब्रेरीज़ अनुवाद की परत तो देती हैं, लेकिन बाकी समस्या डेवलपर पर छोड़ देती हैं:

• भाषा बदलने वाले विकल्प
• लोकेल रूटिंग
• कुकी की स्थायित्व सुविधा
• URL canonicalisation
• SEO के लिए hreflang टैग

ये बातें छोटी लगती हैं, लेकिन जल्दी ही एप्लिकेशन की काफ़ी जटिल ‘प्लंबिंग’ बन जाती हैं, खासकर अगर आपको i18n की सारी बारीकियों की जानकारी न हो। ज़्यादातर कंपनियाँ और डेवलपर ऐसे नहीं होते।

शॉर्टकट: स्वचालित वेबसाइट अनुवाद

इस सारी जटिलता को देखते हुए, कुछ teams automatic website translation tools की ओर मुड़ती हैं। ये platforms minimal effort के साथ आपकी site को automatically translate करने का वादा करती हैं।

इस विचार के और भी उन्नत संस्करण कई कंपनियाँ बना रही हैं। दुर्भाग्य से, वे समस्याओं का एक अलग सेट लेकर आती हैं:

• अनुवाद अक्सर क्लाइंट-साइड पर होते हैं
• SEO टूट जाता है
• डायनेमिक रूप से लोड किए गए कंटेंट का अनुवाद बिना गलत भाषा की एक झलक दिखाए नहीं किया जा सकता
• डेवलपर का नियंत्रण ख़त्म हो जाता है

नतीजा अक्सर ऐसी साइट होती है जो तकनीकी रूप से कई भाषाओं का समर्थन करती है, लेकिन अनुभव काफ़ी ख़राब देती है, और डेवलपर्स के लिए काम करने हेतु एक ब्लैक बॉक्स बन जाती है।

हम यहाँ तक कैसे पहुँचे

हमने कुछ बेहद सरल चीज़ से शुरुआत की थी:

<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

और नतीजे में translation keys, JSON dictionaries, टूटे-फूटे pipelines, अलग-अलग backend और frontend localisation layers, और बाहरी translation tooling रह गया।

आधुनिक web apps बेहद sophisticated systems हैं। फिर भी, i18n tooling ऐसे workflows की उम्मीद करता है जो किसी और दौर के लिए बनाए गए थे, जैसे Ferrari जिसे engine start करने के लिए हाथ से crank करना पड़े।

मॉडल पर फिर से विचार

अगर अंतरराष्ट्रीयकरण कुछ ऐसा दिखता तो क्या होता?

<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

कोई अनुवाद कुंजियाँ नहीं।

कोई JSON डिक्शनरी नहीं।

कोई मैन्युअल पाइपलाइन नहीं।

बस टेक्स्ट.

एक अलग तरीका

यही विचार 18ways के पीछे की नींव है।

18ways अनुवाद को एक अनुकूलित रनटाइम ज़रूरत मानता है। अनुवाद कुंजियों को निकालना और अनुवाद फ़ाइलों को संभालना मशीनों का काम है, इंसानों का नहीं।

डेवलपर बस उस टेक्स्ट को चिह्नित कर देते हैं जिसे वे अनुवादित करना चाहते हैं।

परदे के पीछे, 18ways:

• स्ट्रिंग्स को निकालता है
• AI का उपयोग करके अनुवाद तैयार करता है
• परिणामों को कैश करता है
• server से सीधे translated HTML serve करता है

सब कुछ SSR-फ्रेंडली और SEO-सुरक्षित रहता है।

संदर्भ-जागरूक अनुवाद

पारंपरिक i18n सिस्टम संदर्भ खो देते हैं।

एक अनुवादक को कुछ ऐसा दिखाई दे सकता है:

home

लेकिन इसका मतलब क्या है?

जर्मन में, इन अर्थों के लिए पूरी तरह अलग शब्द चाहिए होते हैं:

• Haus - एक घर
• Startseite - होमपेज
• Start - एक नेविगेशन लेबल
• zum Anfang - शुरुआत में लौटें

अगर आपको “home” का जर्मन में अनुवाद करना हो, तो आप क्या देखना चाहेंगे? एक अलग-थलग स्ट्रिंग, या वह पेज जहाँ यह असल में दिखाई देती है?

ऐसी translation systems जो केवल अलग-थलग strings देखती हैं, इन फर्कों को संभालने में जूझती हैं।

18ways वास्तविक UI के संदर्भ में अनुवादों का विश्लेषण करता है।

हमारे backend agents translations की समीक्षा करते हैं जैसे वे असली pages पर दिखाई देते हैं, और इन्हें बेहतर बनाते हैं:

• संदर्भ
• संगति
• लेआउट की सीमाएँ
• अनुवाद की गुणवत्ता

जो भी German compound nouns से परिचित है, चिंता न करें, overflow detection भी शामिल है।

मानवीय अनुवादकों को सशक्त बनाना

AI को बेहतर अनुवाद बनाने में मदद करने वाली हर चीज़ मानव अनुवादकों की भी मदद करती है।

18ways अनुवादकों को वही संदर्भ-सचेत वातावरण देता है जिसका उपयोग हमारे AI एजेंट करते हैं।

JSON फ़ाइलों को संपादित करने के बजाय, अनुवादक टेक्स्ट को सीधे UI में उसके दिखने के स्थान के साथ देखते हैं।

यह अनुवाद की सटीकता और वर्कफ़्लो की दक्षता में भारी सुधार करता है।

बेहतर i18n कैसा दिखता है

इंटरनेशनलाइज़ेशन को अनुवाद कुंजियों, स्ट्रिंग फ़ाइलों और पाइपलाइन ग्लू की एक और परत की ज़रूरत नहीं है।

आधुनिक applications में पहले से ही वह structure, context, और runtime information मौजूद है जिसकी हमें इसे बेहतर करने के लिए ज़रूरत है।

i18n की अगली पीढ़ी सर्वर-रेंडर्ड ऐप्स, डायनामिक कंटेंट, AI-native वर्कफ़्लोज़, और साथ-साथ काम करने वाले मानव अनुवादकों के लिए बनाई जानी चाहिए।

यही वह दिशा है जिसमें 18ways जा रहा है।