Respondo दुबई में बना, और इस तथ्य ने प्रोडक्ट को हमारे किसी भी roadmap फ़ैसले से ज़्यादा आकार दिया। यहाँ एक अकेली सपोर्ट कतार में एक ग्राहक अरबी में लिख रहा हो सकता है, दूसरा अंग्रेज़ी में, तीसरा हिंदी में, और चौथा उर्दू में — अक्सर एक ही घंटे के भीतर। इस प्रोडक्ट का ऐसा कोई संस्करण कभी था ही नहीं जो किसी एक भाषा को डिफ़ॉल्ट और बाक़ी को अनुवाद माने। तीस से ज़्यादा भाषाएँ, right-to-left वाली भी, बुनियाद होनी थीं, न कि कोई परत जो हम बाद में जोड़ते।

वह बाधा साफ़-सूझ लाने वाली निकली। जब बहुभाषीपन वैकल्पिक न हो, तो बहुत सारे शॉर्टकट जो किसी अंग्रेज़ी-पहले प्रोडक्ट में वाजिब लगते हैं, ख़ुद को बंद गलियों के रूप में उजागर कर देते हैं। यह वह है जो हमने AI और interface दोनों के आर-पार उस हक़ीक़त के लिए बनाते हुए सीखा।

अनुवाद, समझ नहीं है

लुभावना architecture एक pipeline है: आने वाला संदेश लो, उसे किसी translation API से अंग्रेज़ी में चलाओ, अपने अंग्रेज़ी models से उसे संसाधित करो, एक अंग्रेज़ी जवाब बनाओ, और उसे वापस अनुवादित कर दो। यह सस्ता है, बनाने में तेज़ है, और ठीक उन्हीं हालात में नाकाम होता है जिनसे ग्राहक सेवा बनी है।

ग्राहक की बातचीतें उस संदर्भ से घनी होती हैं जिसे सामान्य अनुवाद चपटा कर देता है। Slang, मुहावरे, शिष्टाचार के रजिस्टर, और क्षेत्र-विशिष्ट शब्दावली — इस आने-जाने में सब घिस जाते हैं। क्लासिक उदाहरण है एक अकेला शब्द जिसके अर्थ में एक शाखा है: retail संदर्भ में "return" पूछने वाला ग्राहक किसी प्रोडक्ट को वापस भेजने के बारे में जानना चाहता है; वही शब्द किसी वित्तीय संदर्भ में निवेश की उपज के बारे में है। अनुवाद-संसाधन-अनुवाद सिरा खो देता है, क्योंकि जब तक अंग्रेज़ी model उसे देखता है, तब तक अर्थ स्पष्ट करने वाला संदर्भ पहले ही मसल दिया जा चुका होता है।

Respondo इसके बजाय भाषा-विशिष्ट models इस्तेमाल करता है। अरबी में आया कोई संदेश अरबी में ही, मूल रूप से, समझा और उत्तरित किया जाता है, बिना कभी अंग्रेज़ी से एक मध्यवर्ती प्रतिनिधित्व के रूप में गुज़रे। जो भेद मायने रखते हैं — लहजा, रजिस्टर, किसी अस्पष्ट शब्द का सही अर्थ — वे उसी भाषा में पकड़े जाते हैं जिसमें वे असल में रहते हैं। किसी ऐसे जवाब में, जो तकनीकी रूप से सही है, और किसी ऐसे जवाब में, जिसे कोई मातृभाषी प्रवाहपूर्ण के रूप में पहचानता है, यही फ़र्क़ है।

जब interface पलट जाता है

model में भाषाओं को संभालना आधी समस्या है। दूसरी आधी है interface, और right-to-left भाषाएँ वह जगह हैं जहाँ अधिकांश design systems चुपचाप बिखर जाते हैं।

अरबी और हिब्रू का समर्थन करना strings के अनुवाद की बात नहीं है। पूरा layout उलट जाता है। टेक्स्ट दाईं ओर संरेखित होता है। पढ़ने का क्रम दाएँ से बाएँ चलता है, यानी किसी बातचीत का दृश्य प्रवाह, back button की स्थिति, किसी तीर के इशारे की दिशा — यह सब आईना हो जाता है। स्थिर स्थितियों में left-to-right धारणाओं के साथ पका हुआ कोई डिज़ाइन RTL में अनूदित नहीं होता; वह टूट जाता है।

सूक्ष्म बात यह है कि हर चीज़ नहीं पलटती। यही वह जाल है जिसमें टीमें तब गिरती हैं जब वे CSS direction property की खोज करती हैं और सोचती हैं कि काम पूरा हो गया।

  • Layout, टेक्स्ट संरेखण, और पढ़ने का क्रम आईना होते हैं। अंग्रेज़ी में बाईं ओर की कोई sidebar अरबी में दाईं ओर की होती है।
  • दिशा वाले icons उस पलटाव को विरासत में पाते हैं। किसी "reply" तीर या "next" chevron को दूसरी ओर इशारा करना होता है, क्योंकि उसका अर्थ दिशात्मक है।
  • जो सामग्री स्वभावतः LTR है वह नहीं पलटती। फ़ोन नंबर, Latin-script ब्रांड नाम, code snippets, और URLs इर्द-गिर्द की भाषा चाहे जो हो, बाएँ से दाएँ पढ़े जाते हैं। इन्हें आईना करेंगे तो आपने निरर्थकता रच दी।

इसे हाथ से, component-दर-component, पूरे प्रोडक्ट भर सही करना ठीक वैसा काम है जिसे प्रोडक्ट के बढ़ने के साथ एकसमान रखना असंभव है। इसलिए हमने इसे हाथ से किया ही नहीं।

constraint-आधारित, न कि position-आधारित

जिस फ़ैसले ने RTL को टिकाऊ बनाया वह यह था कि हम अपने components को निरपेक्ष स्थितियों के हिसाब से बताना बंद करें और रिश्तों के हिसाब से बताना शुरू करें।

एक position-आधारित component कहता है "यह label बाएँ किनारे से 16 पिक्सेल पर बैठता है।" वह निर्देश उसी पल ग़लत हो जाता है जब layout पलटता है। एक constraint-आधारित component कहता है "यह label पंक्ति की शुरुआत पर बैठता है, सामग्री शुरू होने से 16 पिक्सेल पहले।" अब "शुरुआत" अपने आप अंग्रेज़ी में बाएँ और अरबी में दाएँ में सुलझ जाती है, और वही component परिभाषा एक भी शर्त के बिना दोनों दिशाओं में सही render होती है।

इसे व्यक्त करने के लिए हम browser के अपने logical properties पर टिके — वह आधुनिक CSS जो *left* और *right* के बजाय *start* और *end* में, और horizontal तथा vertical के बजाय *inline* और *block* में सोचता है। इस तरह लिखा गया कोई component न जानता है न परवाह करता है कि वह किस दिशा में render हो रहा है। दिशा एक बार, जड़ पर, सेट होती है, और नीचे का हर component उसके अनुसार ढल जाता है।

फ़ायदा चक्रवृद्धि होता जाता है। अगली RTL भाषा जोड़ना लगभग कुछ ख़र्च नहीं करता, क्योंकि layout का तर्क शुरू से ही किसी ख़ास दिशा से बँधा ही नहीं था। साझा primitives पर बना कोई नया component डिफ़ॉल्ट रूप से दोनों दिशाओं में सही होता है — किसी इंजीनियर को उसे तोड़ने के लिए अपने रास्ते से बाहर जाना पड़ेगा।

टेक्स्ट को साँस लेने की जगह

आख़िरी सबक़ सबसे कम चमकदार और सबसे अकसर अनदेखा किया जाने वाला है: भाषाओं के आर-पार टेक्स्ट की लंबाई भारी अंतर के साथ बदलती है, और जिस layout ने कभी सिर्फ़ अंग्रेज़ी देखी है वह उन भाषाओं के नीचे चटख जाएगा जो उसमें समाती नहीं।

वही वाक्यांश जर्मन में 30% ज़्यादा लंबा चल सकता है, चीनी में बिलकुल अलग character set में आ सकता है जहाँ कुछ ही glyphs वह ढो लेते हैं जिसके लिए अंग्रेज़ी को एक वाक्य चाहिए, या अरबी लिपि के ऊपर-नीचे बैठने वाले diacritics के लिए ज़्यादा ऊर्ध्वाधर जगह माँग सकता है। अंग्रेज़ी शब्द "Send" के नाप का बना कोई button उसी पल कतर जाता है या उफन पड़ता है जब उसमें कोई लंबा अनुवाद आ बैठता है।

हमारे components शुरू से ही यह मानते हैं कि वे नहीं जानते कि उनका टेक्स्ट कितना लंबा होगा। वे अपनी सामग्री के साथ बढ़ते हैं, शालीनता से wrap होते हैं, और कभी इस पर निर्भर नहीं होते कि कोई string किसी ख़ास लंबाई की हो। यह एक छोटा अनुशासन है जो बाद में हज़ार अलग-अलग layout सुधारों से बचाता है — और, दिशा-प्रबंधन की तरह, यह ऐसी चीज़ है जो अगर आप इसे पहले दिन से बना दें तो लगभग मुफ़्त है और बाद में जड़ने में बेहद महँगी।

साझा सूत्र

इनमें से हर फ़ैसला उसी एक विचार से तुक मिलाता है: बहुभाषीपन कोई ऐसी सुविधा नहीं हो सकती जिसे आप जोड़ते हों, क्योंकि किसी एक-भाषा प्रोडक्ट की धारणाएँ model, layout, और अलग-अलग component तक अपनी पहुँच बना लेती हैं। अंग्रेज़ी-पहले बनाइए और आप प्रोडक्ट की बाक़ी ज़िंदगी उन जगहों को पैबंद लगाने में बिताएँगे जहाँ वे धारणाएँ रिसती हैं। शुरू से तीस भाषाओं के लिए बनाइए और इकत्तीसवीं लगभग मुफ़्त है। ऐसी जगह पर आधारित होना जहाँ हमारे ग्राहक रोज़ दर्जन भर भाषाएँ बोलते हैं, इसने इसे कठिन नहीं बनाया — इसने इसे चुपचाप ग़लत कर पाना असंभव बना दिया, जो डिज़ाइन करने के लिए सबसे अच्छी क़िस्म की बाधा है।