हमने अपनी पूरी वेबसाइट में जापानी और ब्राज़ीलियाई पॉर्चुगीज़ जोड़ी, सिर्फ़ €31 में

29 सितंबर को हमने globalize.now को जापानी और ब्राज़ीलियन पुर्तगाली में लॉन्च किया — हर पेज, हर प्राइसिंग टेबल और सभी 61 ब्लॉग पोस्ट। ट्रांसलेशन में खुद बस आठ मिनट लगे, और ऐप ने लगभग €31 का बिल बनाया। globalize.now एक AI-संचालित स्थानीयकरण इन्फ्रास्ट्रक्चर है, और इसे अपनी ही साइट पर चलाने का अनुभव कुछ ऐसा रहा — हर आँकड़ा जॉब पेज और Git हिस्ट्री से लिया गया है, याददाश्त से नहीं।

हमारी पोस्ट 2017 में स्थानीयकरण ग्रोथ प्लेबुक की लागत कितनी थी के आख़िर में हमने लिखा था कि हम अभी अपने आँकड़े प्रकाशित नहीं करते। यह पहली बार है। यह लागत का आँकड़ा है, ग्रोथ का नहीं: अभी तक किसी को /ja/ देखने का समय ही नहीं मिला है।

हमने असल में क्या ट्रांसलेट किया?

पूरी साइट, दो बार। यहाँ है रिपॉज़िटरी से निकाली गई पूरी लिस्ट:

• इंटरफ़ेस: पाँच मैसेज कैटलॉग (मुख्य साइट, प्राइसिंग, तुलना पेज, इंटीग्रेशन्स और ट्रांसलेशन उदाहरण) में फैले 1,782 अंग्रेज़ी स्ट्रिंग्स, लगभग 21,000 शब्द।
• ब्लॉग: 61 पोस्ट, लगभग 110,000 शब्द।
• टारगेट भाषाएँ: जापानी (ja) और ब्राज़ीलियाई पॉर्चुगीज़ (pt-BR)।

यानी लगभग 130,000 सोर्स शब्द दो भाषाओं में ट्रांसलेट हुए। पुल रिक्वेस्ट ने 170 फ़ाइलों को छुआ और 34,681 लाइनें जोड़ीं। मर्ज होने के बाद साइटमैप 11 locale में 811 URL लिस्ट करता है, और साइट 962 स्टैटिक पेज बिल्ड करती है।

इसमें कितना समय लगा?

आठ मिनट का ट्रांसलेशन, फिर एक लंबा क्वालिटी पास। हमारे CTO Arturs ने प्रोजेक्ट में दोनों भाषाएँ जोड़ीं, और जॉब main 08:56 UTC पर शुरू हुई। जॉब पेज पर पूरा ब्यौरा इस तरह है:

दोनों भाषाओं वाला कमिट 09:29 UTC पर लैंड हुआ। जॉब की बाकी 45,106 स्ट्रिंग्स ट्रांसलेशन मेमोरी से आईं, क्योंकि मौजूदा आठ भाषाओं में कोई बदलाव नहीं हुआ था।

जब Arturs ने हमारे टीम चैट में इसका ज़िक्र किया था, तो उन्होंने दस मिनट का अनुमान लगाया था। ट्रांसलेशन के मामले में उनका अंदाज़ा सही था, और पूरे जॉब को लेकर वे थोड़े आशावादी रहे — और यही फ़र्क QA पास की वजह से आया। हम मशीन के 27 मिनट खर्च करके जाँच करना पसंद करेंगे, बजाय इसे छोड़ने के।

ऑटोमेटेड QA ने क्या पाया?

11,264 नई स्ट्रिंग्स में से 72 फ्लैग हुईं, और सभी को मामूली दर्जा दिया गया। 11,192 बिना किसी दिक्कत के पास हुईं, और इस दौरान QA ने 182 ऑटोमैटिक फ़िक्स भी लागू किए।

जो फ्लैग हमने खोलकर देखे, वे ज़्यादातर लंबाई-जाँच (लेंथ चेक) की सावधानी की वजह से थे, खासकर जापानी को लेकर। “Pricing” का अनुवाद 料金 होता है, जो सिर्फ़ दो अक्षरों का है, और इसका लेंथ रेशियो 0.29, तय की गई 0.3 की न्यूनतम सीमा से थोड़ा ही कम रह जाता है। यह असल में एक सही अनुवाद है जो अल्फ़ाबेटिक भाषाओं के लिए बनाए गए एक हेयुरिस्टिक को ट्रिगर कर देता है, कोई गलती नहीं है। फिर भी हम इन फ्लैग्स को दिखाए रखते हैं — जो चेक कभी सक्रिय ही न हो, वह चेक कहलाने लायक नहीं।

इसमें कितनी लागत आई?

लगभग €31 का हिसाब: प्रोजेक्ट का प्रति-भाषा लागत व्यू दिखाता है कि जापानी के लिए €15.72 और ब्राज़ीलियन पुर्तगाली के लिए €16.15 खर्च हुए। यही वह राशि है जो ऐप चार्ज करता है — ठीक वही जो किसी ग्राहक को समान वॉल्यूम ट्रांसलेट करने पर दिखेगी। यह न तो हमारी आंतरिक मॉडल लागत है और न ही कोई छूट।

करीब 260,000 ट्रांसलेट किए गए शब्दों में, यह प्रति 1,000 शब्द लगभग 12 सेंट बैठता है। इसके ऊपर कुछ और बिल नहीं किया गया। न कोई प्रति-भाषा चार्ज है, न कोई प्रति-सीट चार्ज, इसलिए बारहवीं भाषा जोड़ने की लागत उतनी ही है जितनी तीसरी भाषा जोड़ने की। मौजूदा प्लान्स प्राइसिंग पेज पर देखे जा सकते हैं।

इंजीनियरिंग में असल में क्या शामिल था?

एक पुल रिक्वेस्ट, जो उसी दोपहर मर्ज हो गई, और उसमें कोई ट्रांसलेशन नहीं था। जब यह खुली, तो ट्रांसलेशन जॉब इस पर फिर से चली और 56,390 में से 56,370 स्ट्रिंग्स सीधे ट्रांसलेशन मेमोरी से ले लीं, यानी पहले से ट्रांसलेट किए गए कैटलॉग नई फ़ाइलों में सिर्फ़ सात मिनट में पहुँच गए। ट्रांसलेशन वह हिस्सा है जो ऑटोमेट हो गया है। किसी Next.js साइट में नया लोकेल रजिस्टर करना अब भी आपका कोड है, और इसे प्लान करने से पहले यह समझना ज़रूरी है कि “आपका कोड” का मतलब असल में क्या है।

next-intl में कोई locale जोड़ना routing config में बस एक लाइन का काम है। बाकी सारा diff उन जगहों का है जो URL बनाती हैं, locale पढ़ती हैं या आपके locales की सूची बनाती हैं:

• Routing: locale की सूची, साथ ही pt-BR के लिए एक URL prefix override (अगला सेक्शन देखें)।
• SEO मेटाडेटा: hreflang क्लस्टर, canonical टैग, og:locale (ja_JP, pt_BR) और वह locale सूची जिस पर मेटाडेटा हेल्पर्स लूप चलाते हैं।
• फ़ॉर्मैटिंग: Intl टैग ja-JP और pt-BR, ताकि तारीख़ें और संख्याएँ सही तरीक़े से दिखें।
• भाषा स्विचर: यह हर locale से असली <a href hreflang> के ज़रिए लिंक करता है, ताकि क्रॉलर उसे फ़ॉलो कर सकें।
• Sitemap और जाँचें: sitemap जनरेटर, lastmod जाँच, internal link जाँच और translation verifier — इन सभी को दोनों नए कोड सीखने पड़े।
• कैटलॉग: दोनों लोकेल्स के लिए खाली, सिर्फ़ हेडर वाली .po फ़ाइलें, जिन्हें उसी पुल रिक्वेस्ट में ट्रांसलेशन मेमोरी से भर दिया गया।

अगर आपकी साइट हमारी जितनी कस्टम नहीं है, तो इस लिस्ट का ज़्यादातर हिस्सा सिर्फ़ config में सिमट जाएगा। अगर आप कहीं भी हाथ से URL बनाते हैं — और ज़्यादातर साइटें कहीं-न-कहीं ऐसा करती ही हैं — तो आपको हर ऐसी जगह तभी पता चलेगी जब पहली बार कोई लिंक ग़लत निकलेगा। Developer guide में सेटअप का पूरा विवरण है, और AI localization एजेंट असल में क्या करता है में बताया गया है कि क्या ऑटोमेट होता है और क्या नहीं।

ब्राज़ीलियाई पुर्तगाली /pt-br/ पर क्यों है, /pt-BR/ पर क्यों नहीं?

क्योंकि language tag और URL segment दो अलग चीज़ें हैं, जिनका काम भी अलग-अलग है।

BCP 47 के अनुसार सही tag pt-BR है। हम इसे हर उस जगह इस्तेमाल करते हैं जहाँ कोई मशीन भाषा पढ़ती है: फ़ाइल नामों में, <html lang> में, hreflang में, og:locale में और Intl में। सिर्फ़ URL को lowercase किया जाता है:

// i18n/routing.ts (trimmed)
const prefixes = {
  "pt-BR": "/pt-br",
} as const;

export const routing = defineRouting({
  locales: ["en", "it", "de", "fr", "es", "lv", "hi", "lt", "et", "ja", "pt-BR"],
  defaultLocale: "en",
  localePrefix: { mode: "always", prefixes },
});

/** The URL path segment for a locale: `pt-BR` → `pt-br`, `de` → `de`. */
export function localeUrlSegment(locale: string): string {
  const prefix = (prefixes as Record<string, string | undefined>)[locale];
  return prefix ? prefix.slice(1) : locale;
}

Mixed-case पाथ ग़लत टाइप हो जाते हैं, और जो साइट /pt-BR/ और /pt-br/ दोनों पर जवाब देती है, उसके पास हर पेज की दो कॉपियाँ हो जाती हैं जो आपस में ही टकराती हैं। इसलिए /pt-BR/, /pt-br/ पर redirect होता है, और localeUrlSegment() हर हाथ से बनाए गए URL को prefix map से बनाता है। एक ही सोर्स ऑफ़ ट्रुथ होने का मतलब है कि language switcher, canonical टैग और sitemap कभी एक-दूसरे से अलग दिशा में नहीं भटक सकते।

जापानी और ब्राज़ीलियाई पॉर्चुगीज़ ही क्यों?

ये दोनों बड़ी वेब भाषाएँ हैं जिन्हें हमने अभी तक कवर नहीं किया था। W3Techs के आँकड़ों के मुताबिक, जिस दिन हमने इसे शिप किया, उस दिन जापानी 4.9% वेबसाइटों की कंटेंट भाषा थी और पॉर्चुगीज़ 4.1% की।

इसे करने की वजह हमसे भी पुरानी है। CSA रिसर्च ने 2020 में 29 देशों के 8,709 उपभोक्ताओं का सर्वे किया था, और 76% ने कहा कि वे अपनी ही भाषा में जानकारी वाले प्रोडक्ट खरीदना पसंद करते हैं। यह डिमांड साइड है। जो बदला है वह सप्लाई साइड है: पहले दो भाषाओं का मतलब एक वेंडर रिलेशनशिप होता था, अब इसकी कीमत सिर्फ़ €31 है।

भाषाएँ चुनने का हमारा अपना नियम वही है जो growth playbook post में बताया गया है। देखें कि आपका ट्रैफ़िक अभी कहाँ से आ रहा है, दो भाषाएँ जोड़ें, बाकी कुछ भी न बदलें और एक क्वार्टर तक नतीजे मापें। हम इन दोनों भाषाओं के साथ ठीक यही करेंगे।

हमने अभी तक क्या चेक नहीं किया है?

नेटिव रिव्यू। अभी तक किसी ऐसे व्यक्ति ने आउटपुट नहीं देखा है जो जापानी या ब्राज़ीलियाई पॉर्चुगीज़ को नेटिव भाषा की तरह पढ़ता हो।

हमने जो जाँचा है: हर स्ट्रिंग पर ऑटोमेटेड QA, बिल्ड हर प्रीबिल्ड चेक को पास करता है, और स्टेजिंग पर हमने जो पेज बेतरतीब ढंग से जाँचे उन्होंने सही lang, कैनोनिकल और hreflang के साथ 200 रिस्पॉन्स दिया और पूरी तरह रेंडर हुए। लेकिन एक बिल्ड यह नहीं जाँच सकता कि कोई वाक्य पढ़ने में ऐसा लगता है मानो किसी इंसान ने लिखा हो या नहीं। यह हमें तब कठिन तरीके से समझ आया जब हमने अपनी ही जर्मन और फ़्रेंच सामग्री का ऑडिट किया और पूरे-पूरे पेजों में गलत लहजा (रजिस्टर) पाया।

तो अब रिव्यू की बारी है, और उसमें जो भी मिलेगा, उसमें कोई भी गड़बड़ी हो तो उसके साथ हम इस पोस्ट को अपडेट करेंगे।

क्या आप अपनी साइट पर भी यही कर सकते हैं?

अगर आपकी स्ट्रिंग्स पहले से ही कैटलॉग में हैं, तो हाँ, और ट्रांसलेशन वाला हिस्सा सिर्फ़ मिनटों में पूरा हो जाएगा। अगर वे अभी भी कॉम्पोनेंट्स में हार्डकोडेड हैं, तो पहले कन्वर्ज़न होगा। यह एक बार होता है, इन-ऐप कनेक्ट फ़्लो में, और उसके बाद पुश जॉब्स नई स्ट्रिंग्स का अनुवाद करते रहते हैं। vibe coder guide में उन ऐप्स को कवर किया गया है जो Lovable, Bolt या Cursor से बनाए गए हैं, जहाँ हार्डकोडेड स्ट्रिंग्स होना आम बात है।

लागत उन शब्दों के हिसाब से बढ़ती है जिनका आप अनुवाद करते हैं, न कि भाषाओं की संख्या या टीम में लोगों की संख्या के हिसाब से। यही वजह है कि "क्या भाषा जोड़ना फ़ायदेमंद है?" इस सवाल का जवाब बदल गया है। अब इसे मापना, इस पर होने वाली मीटिंग से भी सस्ता है।

इसे अपने रिपॉज़िटरी पर आज़माएँ

दो भाषाओं की कीमत हमें पड़ी सिर्फ़ आठ मिनट का ट्रांसलेशन और लगभग €31। अपना रिपॉज़िटरी कनेक्ट करें, वे दो भाषाएँ चुनें जिनकी ओर आपका एनालिटिक्स पहले से इशारा कर रहा है, और देखें कि आपकी अपनी रसीद कैसी दिखती है।