संक्षेप में जवाब
बहुभाषी UI तब टूटता है जब कॉम्पोनेंट अंग्रेज़ी आकार के टेक्स्ट को मान लेते हैं। टोकन रणनीति विस्तार, लिपि की ऊँचाई, RTL प्रवाह और विज़ुअल रिग्रेशन को देर से आने वाले अपवादों के बजाय सिस्टम का हिस्सा बना सकती है।
टोकन की समस्या अनुवाद नहीं, छिपी हुई ज्यामिति है
बहुभाषी इंटरफ़ेस आमतौर पर तब ही टूट चुका होता है जब अनुवादक ने उसे छुआ तक नहीं होता। यह विफलता पहले से ही किसी तय बटन-चौड़ाई में, बिना ओवरफ़्लो नीति वाले दो-पंक्ति कार्ड शीर्षक में, ऐसे नेविगेशन आइटम में जिसकी padding छह अंग्रेज़ी अक्षरों के हिसाब से तय की गई थी, या हार्ड-कोडेड बाएँ ऑफ़सेट से रखे गए आइकन में दर्ज होती है। अनुवाद बस इन मान्यताओं को उजागर कर देता है। इसलिए एक उपयोगी टोकन सिस्टम केवल रंग और स्पेसिंग मान ही नहीं बताता, बल्कि यह भी बताता है कि सामग्री बदलने पर कोई कॉम्पोनेंट किस ज्यामिति पर मोल-भाव कर सकता है।
W3C की इंटरनेशनलाइज़ेशन गाइडेंस अंतर्निहित जोखिम को ठोस रूप में सामने रखती है: अनुवादित टेक्स्ट स्रोत की लंबाई नहीं बनाए रखता, और बहुत छोटी स्ट्रिंग्स लंबे पैराग्राफ़ों की तुलना में कहीं अधिक फैल सकती हैं। जर्मन और फ़िनिश लंबे समास-शब्द भी बना सकती हैं जिनमें स्वाभाविक रैप-पॉइंट कम होते हैं, जबकि थाई, अरबी, देवनागरी, चीनी और जापानी जैसी लिपियाँ अलग ऊर्ध्वाधर स्थान माँग सकती हैं। सिस्टम को चौड़ाई, ऊँचाई और पंक्ति-विच्छेद के बदलाव एक साथ सहने होंगे, न कि “लंबा टेक्स्ट” को ही एकमात्र लोकलाइज़ेशन समस्या मानना होगा।
इससे डिज़ाइन का सवाल “बटन की चौड़ाई कितनी है?” से बदलकर “इस बटन का न्यूनतम आकार, inline padding, अधिकतम वृद्धि का व्यवहार और रैपिंग नियम क्या हैं?” बन जाता है। टोकन तब सबसे मज़बूत होते हैं जब वे ऐसे टिकाऊ निर्णयों को दर्ज करते हैं। कोई तय पिक्सेल मान अब भी रह सकता है, पर उसे एक सिमैंटिक अनुबंध के भीतर बैठना चाहिए जो बताए कि क्या फैल सकता है, क्या स्थिर रहना चाहिए, और सामग्री पसंदीदा आकार से बाहर जाने पर क्या होता है।
संबंधों को टोकनाइज़ करें, स्क्रीनशॉट को नहीं
स्क्रीनशॉट सामग्री की केवल एक सफल व्यवस्था है। डिज़ाइन टोकन को उस संबंध का वर्णन करना चाहिए जिसने उस व्यवस्था को सफल बनाया। बहुभाषी उत्पादों के लिए इसका अर्थ है तय आवश्यकताओं को लचीली आवश्यकताओं से अलग करना। टच टारगेट का न्यूनतम आकार तय हो सकता है। किसी कॉम्पोनेंट परिवार के भीतर inline padding स्थिर रह सकती है। टेक्स्ट कॉलम की पसंदीदा अधिकतम माप हो सकती है। पर किसी लेबल को दी गई दूरी को केवल इसलिए कठोर चौड़ाई के रूप में दर्ज करना शायद ही उचित है कि वह स्रोत locale में संतुलित दिखती थी।
एक व्यावहारिक टोकन परत में control-inline-padding, control-block-padding, label-gap, compact-line-height, reading-line-height, content-max-inline-size और minimum-control-block-size जैसे सिमैंटिक मान शामिल हो सकते हैं। सटीक नामकरण से ज़्यादा अहम इसके पीछे का तर्क है। इसके बाद कॉम्पोनेंट स्थानीय संख्याएँ गढ़ने के बजाय इन्हीं सिमैंटिक मानों का उपयोग करते हैं। जब टाइपोग्राफ़ी locale के हिसाब से बदलती है, तो एक टोकन उपनाम line height या फ़ॉलबैक फ़ॉन्ट को समायोजित कर सकता है, बिना डिज़ाइनरों को हर कार्ड और डायलॉग अलग-अलग दोबारा ट्यून करने पर मजबूर किए।
यही सिद्धांत घनत्व पर भी लागू होता है। “कॉम्पैक्ट” का अर्थ “कभी नहीं बढ़ेगा” नहीं होना चाहिए। कोई कॉम्पैक्ट कॉम्पोनेंट कम padding बनाए रखते हुए भी दूसरी पंक्ति या अतिरिक्त ब्लॉक ऊँचाई की अनुमति दे सकता है। यह उन एंटरप्राइज़ इंटरफ़ेस में विशेष रूप से महत्वपूर्ण है जहाँ अनुवादित लेबल, उपयोगकर्ता द्वारा बनाए गए नाम और स्थानीयकृत तिथियाँ साथ-साथ रहती हैं। लक्ष्य वैध स्थितियों की एक नियंत्रित सीमा है, यह वादा नहीं कि हर locale अंग्रेज़ी स्क्रीनशॉट को पिक्सेल-दर-पिक्सेल दोहराएगी।
टेक्स्ट विस्तार को कॉम्पोनेंट अनुबंध में शामिल करें
हर टेक्स्ट वाले कॉम्पोनेंट के पास तीन सवालों का स्पष्ट उत्तर होना चाहिए: क्या टेक्स्ट रैप हो सकता है, क्या कंटेनर बढ़ सकता है, और जब ये दोनों गुंजाइशें ख़त्म हो जाएँ तो क्या होगा? बटन अक्सर पहले क्षैतिज वृद्धि के साथ बेहतर काम करते हैं, और रैपिंग तभी सीमित रूप में जब उत्पाद का संदर्भ इसकी अनुमति दे। टैब को स्क्रॉलिंग या किसी वैकल्पिक ओवरफ़्लो पैटर्न की ज़रूरत पड़ सकती है। कार्ड आमतौर पर ऊर्ध्वाधर रूप से बढ़ सकते हैं। टेबल कॉलम को एक-समान संपीड़न के बजाय प्राथमिकता नियमों की ज़रूरत हो सकती है। ये निर्णय कॉम्पोनेंट स्पेसिफ़िकेशन में एक बार दर्ज होने चाहिए और हर locale में परखे जाने चाहिए।
W3C का reflow मानदंड तब भी उपयोगी अनुशासन है जब तात्कालिक काम सुलभता नहीं बल्कि लोकलाइज़ेशन हो। यह पूछता है कि सीमित जगह में सामग्री को पुनर्व्यवस्थित होना पड़े तो क्या जानकारी और कार्यक्षमता उपलब्ध रहती है। बहुभाषी सिस्टम को भी यही दृष्टिकोण फ़ायदा देता है: जब चौड़ाई ख़त्म हो जाए, सामग्री चुपचाप ग़ायब होने के बजाय ख़ुद को पुनर्व्यवस्थित करे। तय ऊँचाई वाले कंटेनर विशेष रूप से जोखिम भरे हैं, क्योंकि अनुवाद दूसरी या तीसरी पंक्ति बना सकता है जो बिना किसी स्पष्ट क्षैतिज ओवरफ़्लो संकेत के कट जाती है।
इसलिए pseudo-localization केवल इंजीनियरिंग QA का नहीं, डिज़ाइन समीक्षा का भी हिस्सा होना चाहिए। स्रोत स्ट्रिंग्स को ऐसे बढ़ा-चढ़ाकर बनाए संस्करणों से बदलें जिनमें मोटे तौर पर फैलाया गया टेक्स्ट, उच्चारण-चिह्न वाले वर्ण और जान-बूझकर लंबे टोकन हों। मक़सद किसी असली भाषा की सटीक नक़ल करना नहीं है; मक़सद कमज़ोर लेआउट मान्यताओं को उजागर करना है। यदि कोई कॉम्पोनेंट कृत्रिम दबाव में टूटता है, तो प्रोडक्शन लोकलाइज़ेशन आख़िरकार वही कमज़ोरी किसी कम अनुमानित और अधिक महँगी जगह पर ढूँढ़ ही लेगा।
फ़्लूइड टाइपोग्राफ़ी में चौड़ाई के साथ लिपि की ऊँचाई भी गिनें
रिस्पॉन्सिव टाइपोग्राफ़ी अक्सर व्यूपोर्ट की चौड़ाई के इर्द-गिर्द बनाई जाती है, पर बहुभाषी टाइपोग्राफ़ी एक दूसरा अक्ष जोड़ देती है: लिपि और चुने गए फ़ॉलबैक फ़ॉन्ट की मेट्रिक्स। एक ही नाममात्र आकार पर सेट दो फ़ॉन्ट की x-height, ascender, descender और दिखने वाला घनत्व अलग हो सकते हैं। कुछ लेखन प्रणालियों को पठनीय बने रहने और चिह्नों की टकराहट से बचने के लिए अधिक पंक्ति-अंतराल चाहिए। लैटिन कैपिटल अक्षरों के लिए चुना गया एक ही कसा हुआ line-height टोकन तब स्पष्ट रूप से टूटा दिख सकता है जब उसी कॉम्पोनेंट में कोई दूसरी लिपि आ जाए।
सुरक्षित मॉडल टाइप की भूमिका को उन सटीक फ़ॉन्ट मेट्रिक्स से अलग करता है जिनसे वह भूमिका रेंडर होती है। एक “label-small” सिमैंटिक टोकन locale के अनुरूप फ़ॉन्ट फ़ैमिली, आकार, वज़न और line height से जुड़ सकता है। जहाँ किसी लिपि को अतिरिक्त ब्लॉक स्थान चाहिए, वहाँ locale परत कॉम्पोनेंट संरचना बदले बिना यह मैपिंग समायोजित कर सकती है। यह हर प्रोडक्ट सतह में विशेष-स्थिति वाला CSS गाड़ने से अधिक टिकाऊ है, और अपवाद को डिज़ाइन तथा इंजीनियरिंग दोनों टीमों के सामने दृश्यमान रखता है।
फ़्लूइड साइज़िंग की भी न्यूनतम और अधिकतम सीमाएँ होनी चाहिए। यदि टाइप व्यूपोर्ट चौड़ाई के साथ लगातार घटता-बढ़ता है, पर अनुवादित लेबल पहले ही अधिक पंक्तियाँ ले रहा है, तो स्रोत संरचना को ज़बरदस्ती वापस बिठाने के लिए टाइप छोटा करना पठनीयता को नुक़सान पहुँचा सकता है। रैपिंग और reflow को वैध परिणाम मानें। टाइपोग्राफ़िक सिस्टम को पहले पढ़ने की गुणवत्ता बचानी चाहिए; ज्यामितीय परिणाम कॉम्पोनेंट को सोखना चाहिए। यह भाषा को किसी पूर्वनिर्धारित डिब्बे में फ़िट होने तक निचोड़ने के ठीक विपरीत है।
दिशा-निर्धारण टोकन और API में हो, आख़िरी क्षण के CSS में नहीं
दाएँ-से-बाएँ समर्थन पूरी स्क्रीन को किसी छवि की तरह पलट देने से नहीं मिलता। अरबी और हिब्रू इंटरफ़ेस RTL टेक्स्ट को अंकों, लैटिन उत्पाद नामों, ईमेल पतों और अन्य LTR टुकड़ों के साथ मिलाते हैं। Unicode Bidirectional Algorithm इसीलिए मौजूद है, क्योंकि इन मिश्रित क्रमों को दृश्य क्रम के नियम चाहिए। प्रोडक्ट कोड को फिर भी सही आधार दिशा देनी होती है और अंतर्निहित सामग्री के चारों ओर आइसोलेशन रखना होता है, ताकि विराम-चिह्न, अंक और आसपास की स्ट्रिंग्स अप्रत्याशित ढंग से क्रम न बदलें।
डिज़ाइन-सिस्टम स्तर पर, जहाँ भी अर्थ पढ़ने की दिशा के अनुसार चलता है, वहाँ margin-left और border-right जैसी भौतिक अवधारणाओं की जगह inline-start, inline-end, block-start और block-end जैसी तार्किक अवधारणाएँ रखें। कॉम्पोनेंट API को “बायाँ आइकन” और “दायाँ आइकन” के बजाय “leading” और “trailing” स्लॉट उपलब्ध कराने चाहिए। इससे लेआउट को उचित रूप से मिरर होने की छूट मिलती है और कॉम्पोनेंट की सिमैंटिक संरचना बरकरार रहती है।
आइकन के लिए अलग निर्णय चाहिए। किसी दिशात्मक क्रम में “अगला” दर्शाने वाले शेवरॉन को उलटना पड़ सकता है; कैमरा, माइक्रोफ़ोन, चेतावनी चिह्न या ब्रांड मार्क को आमतौर पर नहीं। यहाँ तक कि विराम-चिह्नों का व्यवहार भी दिशा-संवेदी है: W3C बताता है कि कोष्ठक जैसे मिरर होने वाले वर्ण दिशात्मक संदर्भ के अनुसार संभाले जाते हैं। भरोसेमंद नियम यह है कि अर्थ को मिरर करें, पिक्सेल को नहीं। हर दिशात्मक ऐसेट को किसी वैश्विक ट्रांसफ़ॉर्म के हवाले करने के बजाय वर्गीकृत, परीक्षित और प्रलेखित किया जाना चाहिए।
ट्रंकेशन सामग्री नीति है, स्पेसिंग का इलाज नहीं
इलिप्सिस टूटे हुए लेआउट को सुथरा दिखा सकते हैं और साथ ही यह छिपा सकते हैं कि जानकारी हटा दी गई है। यह सौदा कुछ जगहों पर स्वीकार्य है, जैसे किसी सीमित सूची में गौण फ़ाइल-नाम, पर अन्यत्र ख़तरनाक। मुख्य कॉल टू एक्शन, त्रुटि का कारण, एक रिकॉर्ड को दूसरे से अलग करने वाला खाता नाम, या कोई क़ानूनी स्थिति ठीक वही सामग्री हो सकती है जिसकी उपयोगकर्ता को ज़रूरत है। इसलिए काटने का निर्णय दृश्य असुविधा से नहीं, सूचना की प्राथमिकता से तय होना चाहिए।
टोकन ट्रंकेशन व्यवहार को टाइपोग्राफ़ी से अलग करके मदद कर सकते हैं। कोई कॉम्पोनेंट एक-पंक्ति, दो-पंक्ति और बिना प्रतिबंध वाले सामग्री मोड दे सकता है, जिनमें से हर एक में ओवरफ़्लो संभालने का तरीक़ा परिभाषित हो। तब प्रोडक्ट टीमें सोच-समझकर चुनाव कर सकती हैं। जहाँ व्यावहारिक हो, पूरी स्ट्रिंग पहुँच में रहनी चाहिए, और उसे दिखाने वाला इंटरैक्शन कीबोर्ड, टच और सहायक तकनीक के साथ काम करना चाहिए। सिर्फ़ माउस होवर पर दिखने वाला टूलटिप पूरा रिकवरी तंत्र नहीं है।
लोकलाइज़ेशन यह भी बदल देता है कि क्या संक्षिप्त करना सुरक्षित है। W3C चेताता है कि संक्षेपाक्षर भाषाओं के बीच साफ़-साफ़ स्थानांतरित नहीं होते; कुछ भाषाओं में स्वाभाविक छोटा समकक्ष हो ही न। यदि कोई इंटरफ़ेस जगह में समाने के लिए “Acct.” या “Qty.” पर निर्भर है, तो डिज़ाइन पहले ही एक लेआउट समस्या अनुवादकों पर डाल रहा है। ऐसे लेबल पसंद करें जो परिवर्तनशील जगह ले सकें, या सूचना संरचना को दोबारा गढ़ें ताकि कॉम्पोनेंट अंग्रेज़ी-विशिष्ट संपीड़न पर निर्भर न रहे।
स्क्रीनशॉट टेस्टिंग हर locale नहीं, भाषाई जोखिम दर्शाए
किसी वैश्विक उत्पाद को विज़ुअल रिग्रेशन से लाभ पाने के लिए हज़ारों पूरे-पेज स्नैपशॉट की ज़रूरत नहीं। उसे एक छोटा, सोचा-समझा मैट्रिक्स चाहिए जो प्रमुख विफलता-प्रकारों पर दबाव डाले। इसमें लंबी स्ट्रिंग वाला एक LTR locale, एक RTL locale, अधिक ऊँची या दृश्य रूप से सघन लिपि वाला एक locale, और विस्तार को बढ़ा-चढ़ाकर दिखाने वाला एक pseudo-localized बिल्ड शामिल करें। साथ में उत्पाद के सबसे जोखिम भरे कॉम्पोनेंट जोड़ें: नेविगेशन, फ़ॉर्म, टेबल, मोडल, टोस्ट, फ़िल्टर और तय ऊँचाई वाली सामग्री वाली हर सतह।
ये स्क्रीनशॉट उन्हीं रिस्पॉन्सिव ब्रेकपॉइंट पर चलने चाहिए जो स्रोत locale के लिए इस्तेमाल होते हैं, क्योंकि लोकलाइज़ेशन और रिस्पॉन्सिव व्यवहार आपस में जुड़े हुए हैं। जो लेबल डेस्कटॉप पर समा जाता है, वह टैबलेट चौड़ाई पर रैप करा सकता है; वह रैप कार्ड की ऊँचाई बढ़ा सकता है; और बढ़ी हुई ऊँचाई किसी क्रिया को पहली स्क्रीन से नीचे धकेल सकती है या absolute में रखे बैज से टकरा सकती है। रिग्रेशन टेस्ट तब सबसे उपयोगी हैं जब वे इस पूरी शृंखला को पकड़ें, न कि केवल यह साबित करें कि ग्लिफ़ दिखाई दिए।
स्वचालित तुलना को भी मानवीय समीक्षा चाहिए। पिक्सेल डिफ़ इतना बता सकता है कि लेआउट बदला, यह नहीं कि नया पंक्ति-विच्छेद अर्थ की दृष्टि से अच्छा है या नहीं, आइकन सही तरह मिरर हुआ या नहीं, या मिश्रित दिशा वाला टेक्स्ट स्वाभाविक पढ़ा जाता है या नहीं। महत्वपूर्ण प्रवाहों के लिए स्वचालित स्क्रीनशॉट के साथ समय-समय पर मातृभाषी या लोकलाइज़ेशन विशेषज्ञ की समीक्षा जोड़ें। टेस्ट सुइट संरचनात्मक नियमों की रक्षा करती है; भाषा समीक्षा अर्थ की रक्षा करती है। कोई भी दूसरे का विकल्प नहीं है।
मौजूदा डिज़ाइन सिस्टम के लिए व्यावहारिक अपनाने का क्रम
टोकन को दोबारा लिखने के बजाय प्रमाण से शुरू करें। मौजूदा प्रोडक्शन बग की सूची बनाएँ और बार-बार आने वाले विफलता-प्रकार पहचानें: कटे हुए लेबल, तय ऊँचाई वाले कंट्रोल, ग़लत क्रम में लगी RTL सामग्री, ज़रूरत से ज़्यादा कटी नेविगेशन, आइकन की ग़लतियाँ और टाइपोग्राफ़ी की टकराहटें। हर बग को उस डिज़ाइन निर्णय से जोड़ें जिसने उसे संभव बनाया। इससे सिस्टम-स्तरीय बाधाओं की एक छोटी सूची बनती है जिन्हें टोकनाइज़ करना सार्थक है, और आप ऐसी बड़ी सैद्धांतिक वर्गीकरण-प्रणाली बनाने से बच जाते हैं जिसे कॉम्पोनेंट कभी इस्तेमाल ही न करें।
इसके बाद साझा प्रिमिटिव में भौतिक स्पेसिंग को तार्किक स्पेसिंग में बदलें, सबसे अधिक दोहराए जाने वाले टेक्स्ट कॉम्पोनेंट के लिए वृद्धि और रैपिंग के अनुबंध तय करें, और locale-सजग टाइपोग्राफ़ी उपनाम पेश करें। pseudo-localization फ़िक्स्चर सीधे कॉम्पोनेंट प्लेग्राउंड में जोड़ें ताकि डिज़ाइनर इंजीनियरिंग की मदद के बिना उन्हें चला सकें। फिर प्रतिनिधि विज़ुअल रिग्रेशन केस जोड़ें। सबसे मूल्यवान पहले लक्ष्य वे प्रिमिटिव हैं जो हर जगह इस्तेमाल होते हैं: बटन, इनपुट, सूची पंक्तियाँ, कार्ड, डायलॉग और नेविगेशन आइटम।
अंत में, बहुभाषी सहनशीलता को रिलीज़ की शर्त बनाएँ। कोई कॉम्पोनेंट इसलिए “पूरा” नहीं होता कि वह एक Figma फ़्रेम से मेल खाता है; वह तब पूरा होता है जब उसकी वैध सामग्री-स्थितियाँ, दिशा-स्थितियाँ और ओवरफ़्लो व्यवहार तय और परीक्षित हों। इससे लोकलाइज़ेशन का काम ख़त्म नहीं होता। इसका अर्थशास्त्र बदल जाता है। अनुवादक और locale विशेषज्ञ बार-बार यह खोजने के बजाय कि उत्पाद की ज्यामिति असली भाषा को समाने के लिए कभी बनाई ही नहीं गई थी, भाषा और सांस्कृतिक शुद्धता पर ध्यान दे सकते हैं।
व्यावहारिक चेकलिस्ट
- जहाँ दिशा बदल सकती है, वहाँ बाएँ/दाएँ स्पेसिंग टोकन की जगह तार्किक start/end टोकन रखें।
- बटन, टैब, कार्ड और टेबल को फैलाई गई तथा ऊँची लिपि वाली नमूना स्ट्रिंग्स से परखें।
- हर टेक्स्ट वाले कॉम्पोनेंट के लिए रैपिंग, वृद्धि और ट्रंकेशन के नियम तय करें।
- RTL लेआउट में मिरर करने से पहले आइकन की सिमैंटिक दिशा का ऑडिट करें।
- LTR, RTL और लंबी स्ट्रिंग वाले locale के लिए प्रतिनिधि स्क्रीनशॉट लें।
सवाल और जवाब
क्या डिज़ाइन सिस्टम को हर भाषा के लिए अलग टोकन बनाने चाहिए?
आमतौर पर नहीं। अधिक टिकाऊ तरीक़ा यह है कि उन व्यवहारों के लिए सिमैंटिक टोकन बनाए जाएँ जिन पर भाषाएँ दबाव डाल सकती हैं: inline स्पेसिंग, block स्पेसिंग, line height, कंट्रोल का न्यूनतम आकार, सामग्री की चौड़ाई, रैपिंग और दिशा। locale-विशिष्ट ओवरराइड तब उपयोगी हैं जब कोई लिपि या उत्पाद-आवश्यकता सचमुच उनकी माँग करे, पर हर भाषा के लिए पूरा टोकन सेट दोहराने से बिखराव पैदा होता है। साझा सिमैंटिक नियमों से शुरू करें, और सीमित दायरे वाले locale उपनाम तभी जोड़ें जब परीक्षण किसी दोहराई जाने वाली ज़रूरत को साबित कर दें।
अनुवादित इंटरफ़ेस टेक्स्ट के लिए डिज़ाइनरों को कितनी अतिरिक्त चौड़ाई रखनी चाहिए?
कोई एक सुरक्षित प्रतिशत नहीं है। W3C की गाइडेंस बताती है कि छोटी अंग्रेज़ी स्ट्रिंग्स अनुवाद में नाटकीय रूप से फैल सकती हैं, जबकि लंबे अंश आमतौर पर अनुपात में कम फैलते हैं। व्यावहारिक उत्तर यह है कि कोई एक तय बफ़र रखने के बजाय कॉम्पोनेंट को स्पष्ट नियमों के अनुसार बढ़ने, रैप होने या reflow होने दिया जाए। जान-बूझकर लंबी की गई स्ट्रिंग्स वाली pseudo-localization किसी सार्वभौमिक गुणक का अंदाज़ा लगाने से अधिक भरोसेमंद है, ख़ासकर बटन, टैब, फ़िल्टर और संकुचित नेविगेशन के लिए।
क्या दाएँ-से-बाएँ इंटरफ़ेस में हर आइकन को मिरर करना चाहिए?
नहीं। जो आइकन भौतिक दिशा या क्रम व्यक्त करते हैं उन्हें मिरर करने की ज़रूरत पड़ सकती है, जबकि स्थिर वस्तुओं, ब्रांड, मीडिया कंट्रोल या सांस्कृतिक रूप से स्थापित प्रतीकों को दर्शाने वाले आइकन को शायद न पड़े। यह निर्णय यांत्रिक नहीं, अर्थ-आधारित होना चाहिए। टेक्स्ट की दिशा Unicode Bidirectional Algorithm के ज़रिए विराम-चिह्नों और मिश्रित-लिपि सामग्री को भी प्रभावित करती है। इसलिए मज़बूत सिस्टम आइकन की दिशा, टेक्स्ट की दिशा और लेआउट क्रम को आपस में जुड़े पर अलग-अलग विषयों की तरह देखता है और संदर्भ में उनकी समीक्षा करता है।
क्या लोकलाइज़ेशन के ओवरफ़्लो के लिए ट्रंकेशन स्वीकार्य समाधान है?
हो सकता है, पर केवल तब जब छिपी हुई सामग्री अनावश्यक हो या किसी दूसरे इंटरैक्शन—जैसे विस्तार, टूलटिप या विवरण दृश्य—से वापस पाई जा सके। किसी मुख्य क्रिया, क़ीमत, त्रुटि संदेश या क़ानूनी लेबल को काटना अर्थ ही नष्ट कर सकता है। पहले रैपिंग, लचीली चौड़ाई या reflow को प्राथमिकता दें। यदि ट्रंकेशन रखना ही है, तो उसे कॉम्पोनेंट-स्तर की सामग्री नीति के रूप में परिभाषित करें और जाँचें कि स्क्रीन रीडर तथा कीबोर्ड उपयोगकर्ता अब भी पूरी जानकारी तक पहुँच सकते हैं।