DIALØGUE को Shipping करने से मुझे Multilingual AI Products के बारे में क्या सीख मिली

AI अभी हमें जो सबसे seductive चीज़ करने देती है, उनमें से एक है बहुत जल्दी नई भाषाएँ जोड़ देना। मुझे यह इसलिए पता है क्योंकि मैं यही बार-बार कर रहा हूँ। मैंने 48 घंटों में DIALØGUE में 5 भाषाएँ जोड़ीं, फिर अपने पूरे blog archive का अनुवाद 4 दिनों में 10 भाषाओं में कर दिया।

वे posts speed के बारे में थे। यह वाला post उन सब चीज़ों के बारे में है जिन्हें speed cover नहीं करती।

Translation वह हिस्सा है जिसे demo में दिखाना सबसे आसान है, और जिसे overestimate करना सबसे dangerous है।

Machine एक भाषा से दूसरी भाषा में text को हैरान कर देने वाली speed से ले जा सकती है। लेकिन इसका मतलब यह नहीं कि product अब native महसूस होगा। मेरे experience में असली multilingual काम चार जगहों पर सामने आता है: time, voice, UI systems, और fallback behavior। वहीं से product thoughtful लगना शुरू करता है, या fake लगना शुरू करता है।

Practical रूप में यह कुछ ऐसा दिखा:

	Translation Work	Product Work
यह क्या cover करता है	Strings, copy, labels	Dates, layout, voice, fallbacks
गलती होने पर कौन notice करता है	Bilingual reviewers	उस locale का हर user
AI कैसे मदद करती है	जल्दी translations बना देती है	Product-level fit judge नहीं कर सकती
ठीक करने की मेहनत	String को फिर से translate करो	Component को redesign करो
कब पता चलता है	Code review में	जब कोई सच में app use करता है

---

पहला bug translation नहीं था। वह time था।

एक fix जिसने मुझे यह बहुत साफ़ करके दिखाया, उसका copy से कोई लेना-देना नहीं था।

Recurring shows के लिए DIALØGUE episode titles अपने आप generate करता है। सबसे straightforward version सुनने में harmless लगता है: शो का नाम plus आज की तारीख।

यह harmless तब तक लगता है जब तक आपकी audience Tokyo में हो और आपका server अभी भी California time में सोच रहा हो।

अगर कोई Japanese listener daily show खोलता है और Tokyo में तब तक 14 March हो चुका है, लेकिन episode title अब भी 13 March कह रहा है क्योंकि server को वही सच लग रहा है, तो product तुरंत off महसूस होता है। Broken नहीं। बस careless।

तो आख़िरकार मुझे episode titles इस तरह बदलने पड़े कि वे audience की local date इस्तेमाल करें, audience के locale और timezone में, server default में नहीं।

यह implementation का छोटा detail है। और वही असल point भी है।

Multilingual products सिर्फ शब्दों के बारे में नहीं होते। वे context के बारे में होते हैं।

Local context के बिना language अक्सर बस गलत होने का थोड़ा ज्यादा polished version होती है।

---

Lesson 1: Voice product का हिस्सा है

जितना मैं DIALØGUE में गहराई से गया, उतना यह साफ़ होता गया।

यह product dialogue, pacing, personality, और audio के आसपास बना है। इससे इसकी quality bar किसी normal SaaS interface से बहुत ऊपर चली जाती है।

जब मैंने नए templates जोड़े, तो मुझे जल्दी समझ आ गया कि multilingual support सिर्फ यह नहीं है:

• template name को translate करना
• landing page copy को translate करना
• फिर shipping

एक template के लिए मुझे यह सब सोचना पड़ा:

• host profiles
• audience profiles
• dialogue guides
• TTS के लिए voice instructions
• हर भाषा के लिए localized naming conventions

यह काम English में मौजूद था, लेकिन इसे Japanese और Vietnamese versions भी चाहिए थे, क्योंकि hosts के बीच की chemistry product का हिस्सा है, ऊपर चढ़ा हुआ cosmetic layer नहीं।

अगर आपका product content generate करता है, तो voice decoration नहीं है। Voice infrastructure है।

कोई चीज़ grammar के हिसाब से सही हो सकती है और फिर भी dead महसूस हो सकती है।

मुझे यह Chinese variants में और spoken content में खास तौर पर महसूस हुआ। Standard Mandarin technically सही हो सकती है, लेकिन किसी context में फिर भी बहुत formal लग सकती है। English का casual conversational rhythm किसी दूसरी भाषा में literal product language से गुज़रते ही bureaucratic लग सकता है। एक बाज़ार में चलने वाला joke दूसरे बाज़ार में flat exposition बन सकता है।

इसीलिए मैं अब tone guides और host profiles को इतना seriously लेता हूँ। इसलिए नहीं कि मैं चाहता हूँ हर output "branded" लगे। बल्कि इसलिए कि voice drift multilingual AI product को generic महसूस कराने के सबसे तेज़ तरीकों में से एक है।

और generic महँगा पड़ता है।

---

Lesson 2: UI length एक product problem है, translation problem नहीं

यह छोटी बात तब तक लगती है जब तक आप कोई असली app ship नहीं करते।

उसके बाद यह हर जगह दिखाई देने लगती है।

जब मैंने DIALØGUE iOS app को localize किया, तो बात सिर्फ कुछ screens translate करने की नहीं रही। यह 7 भाषाओं में 253 strings का काम बन गया।

और तब भी काम खत्म नहीं हुआ था।

मुझे input components को फिर से wire करना पड़ा ताकि app language picker सच में UI language को consistently control करे। Placeholders, buttons, pricing labels, status text, सब कुछ। नहीं तो आपको half-translated app problem मिलती है:

• एक screen चुनी हुई भाषा को respect करती है
• दूसरी अभी भी English placeholder दिखाती है
• status labels original language में रहते हैं
• app technically कई भाषाओं को support करती है, लेकिन experience नहीं

English में जो button साफ़-सुथरा लगता है, वह German में awkward लग सकता है। एक tidy pricing line French में wrap हो सकती है। एक punchy settings label Japanese में अलग behave कर सकता है।

अगर आपका localization workflow text generation पर ही रुक जाता है, तो ये problems आपको embarrassingly late पता चलेंगी।

इसीलिए मैं increasingly मानता हूँ कि multilingual काम को full product system की तरह treat करना चाहिए:

• copy
• layout
• spacing
• truncation rules
• component behavior
• screenshot QA

Machine words generate कर सकती है। किसी इंसान को फिर भी Simulator खोलना पड़ेगा।

---

Lesson 3: Fallback behavior बताता है कि product वास्तव में कितना mature है

यह text products की तुलना में audio products में और भी ज्यादा important है।

हाल में DIALØGUE में मैंने जो सबसे useful fixes किए, उनमें से एक बाहर से boring लगता था: TTS thresholding और per-segment consistency।

Original whole-script TTS gate बहुत optimistic था। लंबे podcasts actual input limit cross कर रहे थे, कई failed retries waste कर रहे थे, और उसके बाद fallback हो रहे थे। कुछ runs में इसका मतलब लगभग 12 seconds की avoidable latency था, उससे पहले कि system खुद को ठीक करे।

English में भी यह irritating है।

Multilingual flows में यह और भी खराब है, क्योंकि voice consistency वैसे भी मुश्किल होती है।

Fix यह नहीं था कि "बेहतर model use करो"। Fix product work था:

• whole-script synthesis के लिए threshold कम करना
• लंबे episodes को जल्दी per-segment mode में भेजना
• हर segment की energy के लिए opening / middle / closing guidance जोड़ना
• continuity context के लिए पिछले dialogue की कुछ lines pass करना ताकि अगला segment नए show जैसा न लगे

यही fallback behavior है। यही maturity है।

अगर किसी language-specific TTS voice की sound गलत लगे, तो क्या होगा? अगर generated answer भाषाएँ mix कर दे, तो क्या होगा? अगर localized flow के बीच में untranslated error message आ जाए, तो क्या होगा? अगर लंबा script model limit cross कर जाए, तो क्या होगा?

ऐसे moments बताते हैं कि multilingual support feature है या foundation।

Users अक्सर माफ़ कर देते हैं जब system साफ़ तौर पर मदद करने की कोशिश कर रहा हो। जब product careless लगे, तब वे बहुत कम माफ़ करते हैं।

---

Lesson 4: यह जानना कि coverage कब worth it नहीं है

Business question यह नहीं है: "क्या मैं एक और भाषा support कर सकता हूँ?"

असल question यह है:

• क्या यह भाषा real usage या real distribution unlock करेगी?
• क्या मैं UI और output दोनों में believable quality bar maintain कर सकता हूँ?
• क्या मैं support debt बनाए बिना failure cases संभाल सकता हूँ?

अगर जवाब नहीं है, तो आप multilingual capability launch नहीं कर रहे। आप multilingual surface area launch कर रहे हैं। और surface area बिना quality के trust को चुपचाप कमजोर करता है।

---

Lesson 5: Multilingual products को अपनी अलग eval layer चाहिए

यह शायद DIALØGUE और मेरे blog archive दोनों से मिला सबसे बड़ा takeaway है।

आप multilingual quality को सिर्फ instinct से judge नहीं कर सकते, खासकर scale पर।

आपको explicit checks चाहिए:

• locale-specific date और timezone behavior
• terminology consistency
• UI overflow
• fallback language rules
• segments के बीच TTS consistency
• host/personality drift
• real user flows में output quality

दूसरे शब्दों में, multilingual products को भी evals चाहिए।

और मुझे लगता है कि यहीं AI builders फँस सकते हैं। हम इस बात से fascinated हो जाते हैं कि model कितना कुछ produce कर सकता है, और "good" की durable definition तय करने में कम समय लगाते हैं।

छोटे scale पर यह manageable है।

बड़े scale पर यह dangerous हो जाता है।

---

इससे मैं कहाँ पहुँचा हूँ

मैं multilingual AI products को लेकर पहले से ज्यादा optimistic हूँ।

AI सच में economics बदल देती है। यह सच में उस चीज़ को expand करती है जिसे एक व्यक्ति या छोटी टीम ship कर सकती है। यह सच में उन product ambitions को possible बनाती है जो कुछ समय पहले तक unrealistic लगतीं।

लेकिन यह product judgment का standard भी ऊपर उठा देती है।

क्योंकि जैसे ही language expansion आसान हो जाती है, quality differentiator बन जाती है। और multilingual products में quality सिर्फ translation से नहीं आती। वह context, voice, interface fit, fallbacks, review loops, और "native enough" का ईमानदार definition तय करने से आती है।

यह वही है जो DIALØGUE ने मुझे सिखाया। आप जितनी ज़्यादा भाषाएँ support करते हैं, उतना ज़्यादा product management आप सच में कर रहे होते हैं, चाहे आप उसे जो भी नाम दें।

अगर आपका product सच में multilingual है, तो काम strings translate होने पर खत्म नहीं होता। असली काम तो वहीं से शुरू होता है।

अगर आप उस सोच का परिणाम देखना चाहते हैं, तो DIALØGUE अभी 7 भाषाओं में live है। और मुझे शक है कि multilingual layer मुझे आगे भी नई बातें सिखाती रहेगी, जितने ज़्यादा लोग इसे use करेंगे। ज़्यादातर वे lessons जो थोड़ा humble कर दें।

अगर आप भी multilingual products बना रहे हैं, तो मैं सच में जानना चाहूँगा: वह कौन सा moment था जब आपको एहसास हुआ कि सबसे कठिन bug का translation से कोई लेना-देना ही नहीं था?

Cheers, Chandler

---

अक्सर पूछे जाने वाले प्रश्न

Multilingual AI product बनाने का सबसे कठिन हिस्सा क्या है?

Translation नहीं। AI यह हिस्सा अब काफ़ी अच्छी तरह संभाल लेती है। सबसे मुश्किल हिस्सा translation के आसपास की सारी चीज़ें हैं: timezone-aware formatting, TTS segments के बीच voice consistency, अलग-अलग string lengths पर टूटने वाले UI components, और fallback behavior जब किसी specific locale में कुछ गलत हो जाए। ये product problems हैं, सिर्फ language problems नहीं।

क्या मुझे अपने AI product में और भाषाएँ जोड़नी चाहिए?

सिर्फ तभी जब आप quality maintain कर सकें। हर नई भाषा ongoing product work लाती है: layout QA, voice tuning, locale-specific date और number formatting, और fallback paths। अगर आपका product nuance और generated content पर निर्भर है, जैसे podcasts, long-form writing, या conversational AI, तो इसकी bar simple transactional interface से ऊँची है।

Multilingual AI features को test कैसे करते हैं?

एक explicit eval layer बनाइए। DIALØGUE के लिए इसका मतलब है locale-specific dates check करना, TTS segment consistency, सभी 7 भाषाओं में UI overflow, और generated host dialogue में personality drift। जब आप दो-तीन से ज़्यादा भाषाएँ support करते हैं, तब सिर्फ instinct पर भरोसा नहीं किया जा सकता। Surface area manual spot-check के लिए बहुत बड़ा हो जाता है।

क्या AI localization को आसान बनाती है या कठिन?

दोनों। AI शुरुआती translation को बहुत तेज़ और सस्ता बना देती है। लेकिन यह completion का false sense भी पैदा करती है। Words सही होते हैं और आप मान लेते हैं कि product ready है। असली काम, context, voice, UI fit, और fallbacks, अभी भी human judgment माँगते हैं। AI ने multilingual coverage का floor ऊपर उठाया है, लेकिन ceiling अब भी product craft ही है।