अरबी इंटरफ़ेस की RTL टेस्टिंग

dir और lang से शुरू करें

हर RTL पेज के root element पर दो एट्रिब्यूट चाहिए: lang, जो भाषा घोषित करता है (ar या ar-SA), और dir="rtl", जो base direction सेट करता है। W3C की internationalization गाइडेंस है कि दिशा markup में dir एट्रिब्यूट से सेट करें, सिर्फ़ CSS की direction property से नहीं, क्योंकि दिशा कंटेंट के अर्थ का हिस्सा है और उसे तब भी बचे रहना चाहिए जब styles न हों, कंटेंट कॉपी हो, या assistive technology उसे पढ़े। यही HTML ईमेल और PDF बनाने वाले टेम्पलेट पर भी लागू होता है।

lang एट्रिब्यूट भाषा दर्ज करने से ज़्यादा करता है: यह screen reader को अरबी आवाज़ चुनने देता है, ब्राउज़र को उपयुक्त फ़ॉन्ट चुनने देता है, और लिपि-विशेष styling के लिए इस्तेमाल होने वाले :lang() selector को चलाता है। lang="en" और dir="rtl" वाला पेज डिफ़ेक्ट है, भले ही वह सही दिखे।

• हर पेज का root element जाँचें, जिसमें error पेज, ईमेल, प्रिंट व्यू और PDF शामिल हैं।
• Runtime पर भाषा बदलें और वापस करें: दिशा, फ़ॉन्ट और cached लेआउट सब बदलने चाहिए, कोई स्क्रीन आधी-mirrored न बचे।

क्या mirror होता है और क्या नहीं

Right-to-left लेआउट में पढ़ना दाईं ओर से शुरू होता है, इसलिए इंटरफ़ेस ऊर्ध्वाधर अक्ष पर mirror होता है। Apple की Human Interface Guidelines व्यावहारिक नियम देती हैं: उन कंट्रोल को flip करें जो एक वैल्यू से दूसरी तक प्रगति दिखाते हैं (slider, progress indicator), जो तय क्रम में आइटम के बीच नेविगेट करते हैं (back और next), और उन आइकन को जो टेक्स्ट या पढ़ने की दिशा या आगे-पीछे की गति दर्शाते हैं; जब क्रम का अर्थ हो तो इमेज का क्रम उलटें। फ़ोटो और आर्टवर्क, लोगो और check mark जैसे सार्वभौमिक चिह्न, घड़ी जैसी असली दुनिया की चीज़ें दिखाने वाले आइकन, असली भौतिक दिशा बताने वाले कंट्रोल, और फ़ोन या कार्ड नंबर जैसी एक संख्या के भीतर के अंक flip न करें।

मीडिया प्लेबैक कई प्लेटफ़ॉर्म पर जान-बूझकर अपवाद है: Material Design की bidirectionality गाइडेंस, जिसकी ओर Android का documentation इशारा करता है, playback कंट्रोल और मीडिया progress bar को left-to-right रखती है क्योंकि वे समय की दिशा नहीं, चल रहे मीडिया (टेप) की दिशा दर्शाते हैं। आपका प्रोडक्ट जो भी तय करे, उसे डिज़ाइन स्पेसिफ़िकेशन में लिखें और उसी के विरुद्ध टेस्ट करें, क्योंकि असली डिफ़ेक्ट स्क्रीनों के बीच असंगत व्यवहार है। Source code, terminal आउटपुट और गणितीय अभिव्यक्तियाँ भी left-to-right रहती हैं।

• Mirror करें: पेज लेआउट, navigation drawer, टैब क्रम, breadcrumbs, back/forward तीर, stepper, carousel, progress bar, slider, सूचियों के chevron, टेबल कॉलम का क्रम, labels के सापेक्ष आइकन की जगह।
• Mirror न करें: लोगो, check mark, घड़ियाँ और असली clockwise गति दिखाने वाले गोल refresh आइकन, फ़ोटो, मैप, फ़ोन और कार्ड नंबर, code blocks, और समय दर्शाने वाले अक्ष वाले चार्ट, जब तक डिज़ाइन कुछ और न कहे।

CSS logical properties और प्लेटफ़ॉर्म लेआउट

ज़्यादातर mirroring डिफ़ेक्ट physical लेआउट कोड से आते हैं। margin-left, padding-right, left, right और text-align: left जैसी CSS properties दिशा चाहे जो हो, उसी तरफ़ रहती हैं; उनके logical समकक्ष — margin-inline-start, padding-inline-end, inset-inline-start, text-align: start — लेखन-दिशा के साथ चलते हैं। Flexbox और grid दिशा अपने-आप मानते हैं; absolute positioning, transforms, background positions और shadow offsets नहीं। दिशा वाले आइकन को स्पष्ट flip चाहिए, और सिर्फ़ दिशा वालों को।

मोबाइल प्लेटफ़ॉर्म पर यही अवधारणा दूसरे नामों से है। Android पर ऐप android:supportsRtl="true" घोषित करता है, लेआउट left और right की जगह start और end इस्तेमाल करते हैं, और सरल दिशा वाले drawables android:autoMirrored="true" सेट कर सकते हैं। iOS पर Auto Layout की leading और trailing constraints mirror होती हैं जबकि left और right constraints नहीं, और दिशा वाली इमेज को right-to-left लेआउट में flip होने के लिए चिह्नित करना होता है। टेस्टर को यह कोड लिखने की ज़रूरत नहीं, पर review या developer tools में physical properties पहचानना ज़्यादातर "यह एलिमेंट हिला ही नहीं" डिफ़ेक्ट समझा देता है।

/* Physical properties: do not mirror */
.card   { margin-left: 16px; text-align: left; }
.badge  { position: absolute; right: 8px; }

/* Logical properties: follow the writing direction */
.card   { margin-inline-start: 16px; text-align: start; }
.badge  { position: absolute; inset-inline-end: 8px; }
.list   { padding-inline-start: 24px; border-inline-end: 1px solid; }

/* Directional icons flip explicitly; logos, check marks and media icons do not */
[dir="rtl"] .icon-chevron-next { transform: scaleX(-1); }

/* Arabic text: no letter-spacing, room for diacritics */
:lang(ar) { letter-spacing: 0; line-height: 1.8; }

Bidirectional टेक्स्ट और Unicode Bidirectional Algorithm

अरबी वाक्यों में अक्सर left-to-right कंटेंट होता है: अंग्रेज़ी ब्रांड नाम, ऑर्डर नंबर, SKU, ईमेल पते, URL, फ़ोन नंबर और code। दिखने का क्रम Unicode Bidirectional Algorithm (UAX #9) तय करता है। व्यावहारिक स्तर पर अक्षर strong होते हैं (अरबी और लैटिन अक्षरों की दिशा होती है), weak (अंक और कुछ separators) या neutral (spaces और ज़्यादातर विराम-चिह्न)। अलग-अलग दिशा वाले हिस्सों के बीच और पैराग्राफ़ के किनारे के neutral अक्षर base direction ले लेते हैं — इसीलिए अंग्रेज़ी वाक्यांश के बाद का विराम-चिह्न ग़लत तरफ़ कूद जाता है। संख्याओं के लिए अतिरिक्त नियम हैं: अरबी अक्षरों के बाद आने वाले अंक bidi type Arabic Number (AN) माने जाते हैं (उनका रूप नहीं बदलता), और ऐसी संख्याओं के बीच का hyphen या space, या उनसे पहले का + चिह्न, right-to-left दिशा ले लेता है, इसलिए अंकों का हर समूह अलग run के रूप में रखा जाता है — इसीलिए hyphen वाला ऑर्डर नंबर या spaces वाला फ़ोन नंबर अरबी वाक्य के भीतर अपने हिस्सों के बदले क्रम में दिख सकता है।

सुधार है isolation। HTML में ज्ञात दिशा वाले embedded कंटेंट को अपने dir वाले एलिमेंट में लपेटें, जिस कंटेंट की दिशा पहले से पता न हो (यूज़र नाम, रिव्यू, search शब्द) उसके लिए <bdi> या dir="auto" इस्तेमाल करें, और free-text इनपुट फ़ील्ड पर dir="auto" लगाएँ। HTML के बाहर — plain-text notification, SMS या native strings में — Unicode isolate कंट्रोल (U+2066 LRI, U+2067 RLI, U+2068 FSI, जिन्हें U+2069 PDI बंद करता है) यही काम करते हैं। पुराने embedding कंट्रोल (U+202A–U+202E) सही इस्तेमाल करना कठिन है और वे अपने बाद के टेक्स्ट को भी प्रभावित कर सकते हैं।

• एक bidi टेस्ट सेट बनाएँ: शुरुआत, बीच और अंत में अंग्रेज़ी ब्रांड वाले अरबी वाक्य; ऑर्डर नंबर, ईमेल, URL और फ़ोन नंबर के साथ; इकाई या प्रतिशत चिह्न के बाद आने वाली संख्याओं के साथ; कोष्ठक और उद्धरण-चिह्नों के साथ।
• अदृश्य अक्षर जाँचें: जो string "सही दिखती" है उसमें किसी दूसरे सिस्टम से कॉपी हुए भटके direction marks हो सकते हैं; उन्हें देखने के लिए उसे code points में decode करें।

<!-- page: base direction and language on the root element -->
<html lang="ar" dir="rtl">

<!-- order number that must keep its order -->
<p>رقم الطلب: <bdi dir="ltr">2026-0042</bdi></p>

<!-- identifiers that must always read left-to-right -->
<p>للتواصل: <span dir="ltr">+966 50 123 4567</span></p>

<!-- user-generated text of unknown direction -->
<p dir="auto">{review.text}</p>

<!-- English phrase inside Arabic: direction and pronunciation -->
<p>جرّب أداة <bdi lang="en">Mutqan Tools!</bdi> مجاناً</p>

Without isolation, an RTL paragraph can display (example):
  2026-0042            as  0042-2026
  +966 50 123 4567     as  4567 123 50 966+
  Mutqan Tools!        as  !Mutqan Tools

आज़माएँ: Unicode डिकोडर आज़माएँ: Unicode एन्कोडर आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर

अरबी रेंडरिंग: shaping, फ़ॉन्ट, तश्कील और truncation

अरबी जुड़ी हुई लिपि है: ज़्यादातर अक्षर इस पर निर्भर अलग रूप लेते हैं कि वे अकेले हैं या पहले, बाद या दोनों अक्षरों से जुड़े हैं, और लाम-अलिफ़ (لا) जैसे कुछ जोड़े अनिवार्य ligature बनाते हैं। Shaping engine ये रूप चुनता है, और उसमें दख़ल देने वाली कोई भी चीज़ अलग-अलग अक्षर बना देती है। अरबी टेक्स्ट पर letter-spacing एक क्लासिक कारण है — engine के अनुसार वह या तो जोड़ तोड़ने वाले gap डालता है या अनदेखा हो जाता है — इसलिए सुरक्षित नियम है अरबी के लिए letter-spacing: 0। शब्द के भीतर कोई अक्षर डालना (zero-width non-joiner, masking अक्षर, soft hyphen), animation के लिए टेक्स्ट एक-एक अक्षर बनाना, या शब्द के एक हिस्से को अलग styling से highlight करना भी कुछ engines पर जोड़ तोड़ सकता है।

जनरेट किया आउटपुट वह जगह है जहाँ रेंडरिंग सबसे ज़्यादा फ़ेल होती है। अरबी shaping चरण के बिना PDF generator, chart libraries, canvas drawing और इमेज watermark आमतौर पर अरबी को उलटे क्रम में अलग-अलग अक्षरों के रूप में दिखाते हैं। फ़ॉन्ट भी मायने रखते हैं: अरबी fallback वाला लैटिन-प्रथम फ़ॉन्ट आकार और baseline मिला सकता है, और Apple की गाइडेंस बताती है कि all-caps लैटिन के बगल में अरबी बहुत छोटी दिख सकती है और उसे थोड़ा बड़ा आकार चाहिए हो सकता है। तश्कील (diacritics), जैसे उदाहरण शब्द مُتْقَن में, लाइन के ऊपर और नीचे फैलते हैं, इसलिए fixed line height और hidden overflow उन्हें काट देते हैं। टेक्स्ट truncate होने पर ellipsis टेक्स्ट के logical अंत पर होना चाहिए — अरबी में बाईं ओर — और ऐसा तभी होता है जब एलिमेंट की दिशा सही सेट हो।

• असली जैसी अरबी इस्तेमाल करें: लंबे नाम, तश्कील वाले शब्द, लाम-अलिफ़, तत्वील (ـ) जिसे कुछ यूज़र टाइप करते हैं, अरबी-इंडिक अंक और अरबी विराम-चिह्न (، ؛ ؟)।
• हेडिंग, बटन, badge, tooltip, चार्ट, PDF, ईमेल और push notification जाँचें — सिर्फ़ पेज का मुख्य भाग नहीं।

आज़माएँ: अरबी टेस्ट डेटा जनरेटर आज़माएँ: फ़ेक नाम जनरेटर आज़माएँ: स्ट्रिंग लेंथ काउंटर

RTL फ़ॉर्म

फ़ॉर्म RTL की हर कठिनाई को एक जगह जोड़ते हैं। Labels, required-field चिह्न, help टेक्स्ट और error मैसेज mirrored तरफ़ जाते हैं; अरबी के free-text फ़ील्ड कंटेंट की दिशा मानते हैं; और पहचानकर्ता रखने वाले फ़ील्ड हर locale में left-to-right रहते हैं: फ़ोन नंबर, ईमेल पते, URL, IBAN, कार्ड नंबर, राष्ट्रीय ID और residence नंबर, पोस्टल कोड और verification कोड। तय करें कि ये LTR फ़ील्ड RTL फ़ॉर्म के भीतर कैसे align होंगे और इसे एकरूप लागू करें। ख़ाली फ़ील्ड के भीतर दिखने वाला hint टेक्स्ट उसी दिशा में होना चाहिए जिसमें यूज़र टाइप करेगा, वरना टाइप शुरू होते ही टेक्स्ट दूसरी तरफ़ कूद जाता है।

Validation को यूज़र की भाषा बोलनी चाहिए: client-side और server-side मैसेज, हर नियम (required, format, length, range) के मैसेज, और पेमेंट widget जैसे third-party कंपोनेंट से बने मैसेज। न्यूमेरिक फ़ील्ड को अरबी-इंडिक अंकों पर फ़ैसला चाहिए — अरबी कीबोर्ड उन्हें बना सकता है — और प्रोडक्ट को या तो उन्हें स्वीकार करके normalise करना चाहिए या साफ़ अरबी मैसेज के साथ अस्वीकार। उदाहरण के लिए, सऊदी मोबाइल नंबर को local और international दोनों रूपों (जैसे 05XXXXXXXX और +9665XXXXXXXX) में आज़माएँ, और राष्ट्रीय ID, Iqama व फ़ोन फ़ील्ड में वही अंक अरबी कीबोर्ड से टाइप करके ("٠٥٠١٢٣٤٥٦٧") डालें; जो फ़ील्ड न उन्हें स्वीकार करे न अरबी में नियम समझाए, वह डिफ़ेक्ट है।

• Date picker: कैलेंडर ग्रिड दाएँ-से-बाएँ चलता है, महीने के तीर mirrored होते हैं, और हिजरी या ग्रेगोरियन चयन प्रोडक्ट के नियम पर चलता है।
• Checkbox, radio button और toggle अपने labels की दाईं ओर होते हैं; toggle की "on" दिशा डिज़ाइन फ़ैसले पर चलती है।
• पते: जनरेट किए Saudi National Address–शैली डेटा से टेस्ट करें, जहाँ building number, street, district, city, postal code और additional number अरबी शब्दों और पश्चिमी अंकों को मिलाते हैं।

आज़माएँ: सऊदी एड्रेस टेस्ट डेटा आज़माएँ: अरबी टेस्ट डेटा जनरेटर आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

RTL इंटरफ़ेस में एक्सेसिबिलिटी

Screen reader lang पर निर्भर हैं। WCAG 2.2 का success criterion 3.1.1 Language of Page माँगता है कि पेज की भाषा प्रोग्राम से निर्धारित हो सके, और 3.1.2 Language of Parts दूसरी भाषा के अंशों और वाक्यांशों के लिए यही माँगता है, कुछ अपवादों के साथ जिनमें व्यक्तिवाचक नाम (proper names) और तकनीकी शब्द शामिल हैं। इसलिए अरबी टेक्स्ट के भीतर अंग्रेज़ी वाक्य को lang="en" चाहिए; अंग्रेज़ी ब्रांड नाम और शब्दों को भी इसी तरह चिह्नित करना अच्छी प्रैक्टिस है, भले ही यह criterion इसे अनिवार्य न करे, क्योंकि इसके बिना screen reader उन्हें अरबी उच्चारण नियमों से पढ़ता है। उन screen readers से टेस्ट करें जो आपके यूज़र्स के पास हैं (Windows पर NVDA या JAWS, Apple डिवाइस पर VoiceOver, Android पर TalkBack), अरबी आवाज़ इंस्टॉल करके।

Reading order और focus order DOM का पालन करते हैं। जब mirroring logical properties और dir से होती है, DOM क्रम अर्थपूर्ण रहता है और दृश्य क्रम उसके साथ mirror होता है। जब लेआउट row-reverse, order या absolute positioning से नक़ली बनाया जाता है, तो दृश्य क्रम और focus क्रम अलग हो जाते हैं, जो WCAG 1.3.2 Meaningful Sequence और 2.4.3 Focus Order से टकराता है। यह भी जाँचें कि tabs, sliders और carousels में क्षैतिज arrow-key का व्यवहार mirrored दृश्य दिशा से मेल खाता है, और आइकन बटनों के accessible names अनुवादित हैं।

RTL टेस्ट चेकलिस्ट

यह सूची हर लक्षित ब्राउज़र और डिवाइस वर्ग पर अरबी में हर स्क्रीन के लिए चलाएँ। जिन फ़ैसलों की यह माँग करती है (मीडिया कंट्रोल, LTR फ़ील्ड alignment, अंकों का व्यवहार) उन्हें डिज़ाइन स्पेसिफ़िकेशन में दर्ज करें ताकि हर टेस्टर एक ही नियम के विरुद्ध जाँचे। नीचे की सूची अंग्रेज़ी में है और पिछले सेक्शनों की जाँचों को छह समूहों में जोड़ती है: दिशा और भाषा, क्या mirror होता है और क्या नहीं, bidirectional टेक्स्ट, अरबी रेंडरिंग, फ़ॉर्म, और एक्सेसिबिलिटी।

RTL test checklist (ar, ar-SA)

Direction and language
[ ] <html lang="ar" dir="rtl"> on every page, email and PDF template
[ ] Switching language flips direction without a reload glitch or mixed state
Mirroring
[ ] Navigation, back/next arrows, breadcrumbs, steppers, sliders, progress bars mirror
[ ] Logos, check marks, clocks, photos, phone numbers, code do not mirror
[ ] Media playback controls follow the product's documented decision
Bidirectional text
[ ] Order numbers, SKUs, emails, URLs, phone numbers keep their order in Arabic sentences
[ ] Punctuation stays on the correct side of embedded English phrases
[ ] User content with unknown direction is shown with dir="auto" or <bdi>
Rendering
[ ] Arabic letters join (no letter-spacing, no characters inserted inside words)
[ ] Diacritics are not clipped; truncation ellipsis sits at the logical end
[ ] Arabic renders correctly in PDFs, emails, charts and canvas output
Forms
[ ] Labels, required markers, errors and hint text sit on the correct side
[ ] Phone, email, IBAN, ID and code fields are LTR; free-text fields follow content
[ ] Arabic-Indic digits are accepted or rejected with a clear Arabic message
Accessibility
[ ] Screen reader uses an Arabic voice; English phrases carry lang="en"
[ ] Focus order and reading order match the mirrored visual order

RTL जाँचों का ऑटोमेशन

ऑटोमेशन दिशा और लेआउट के रिग्रेशन अच्छी तरह पकड़ता है और भाषाई समस्याएँ कमज़ोर तरीके से। End-to-end smoke suite अंग्रेज़ी के साथ अरबी locale में भी चलाएँ; root का dir और lang assert करें; कुछ anchor एलिमेंट की जगह जाँचें (back link दाईं ओर होना चाहिए); assert करें कि embedded identifiers isolated हैं; और मुख्य स्क्रीन के लिए हर locale की screenshot तुलना जोड़ें, क्योंकि टेक्स्ट assertions DOM पढ़ते हैं और दृश्य reordering नहीं देख पाते। Stylesheets में physical CSS properties की खोज mirroring डिफ़ेक्ट को स्क्रीन तक पहुँचने से पहले पकड़ लेती है।

Android पर AR (XB) pseudo-locale debug बिल्ड को उलटे अंग्रेज़ी टेक्स्ट के साथ right-to-left कर देता है, और RTL layout direction force करने वाला developer option भाषा बदले बिना लेआउट पलट देता है। Xcode scheme के app-language विकल्पों में right-to-left pseudolanguage देता है।

// RTL smoke check (Playwright Test)
test("checkout is laid out right-to-left in Arabic", async ({ browser }) => {
  const page = await (await browser.newContext({ locale: "ar-SA" })).newPage();
  await page.goto("/ar/checkout");

  await expect(page.locator("html")).toHaveAttribute("dir", "rtl");
  await expect(page.locator("html")).toHaveAttribute("lang", /^ar/);

  // the back link sits in the right half of the viewport
  const box = await page.getByRole("link", { name: "رجوع" }).boundingBox();
  expect(box.x).toBeGreaterThan(page.viewportSize().width / 2);

  // the order id is isolated; text assertions cannot see visual reordering
  await expect(page.getByTestId("order-id")).toHaveAttribute("dir", "ltr");

  await expect(page).toHaveScreenshot("checkout-ar.png");
});

# Find physical CSS that will not mirror (review each hit)
grep -rnE "margin-(left|right)|padding-(left|right)|text-align: *(left|right)|float: *(left|right)|[^-](left|right): *[0-9]" src/

RTL डिफ़ेक्ट उदाहरण, बग टाइटल के रूप में

ये समझाने के लिए उदाहरण हैं, असली घटनाएँ नहीं। हर एक लक्षण, जगह और शर्त बताता है, जैसा बग रिपोर्ट गाइड में है।

• अरबी ऑर्डर सारांश में ऑर्डर नंबर 2026-0042, 0042-2026 के रूप में दिखता है
• अरबी प्रोफ़ाइल पेज पर फ़ोन नंबर के अंक-समूह उलटे क्रम में दिखते हैं
• अरबी success मैसेज में विस्मयादिबोधक चिह्न अंग्रेज़ी ब्रांड नाम से पहले दिखता है
• अरबी checkout हेडर का back तीर बाईं ओर इशारा करता है और अगले स्टेप पर ले जाता है
• letter-spacing: 0.1em वाली section headings में अरबी अक्षर अलग-अलग दिखते हैं
• इनवॉइस PDF अरबी ग्राहक का नाम उलटे क्रम में अलग-अलग अक्षरों के रूप में दिखाता है
• कार्ड की fixed line height से अरबी प्रोडक्ट नामों की तश्कील कट जाती है
• मोबाइल नंबर फ़ील्ड अरबी-इंडिक अंकों को सिर्फ़ अंग्रेज़ी error मैसेज के साथ अस्वीकार करता है
• Screen reader अंग्रेज़ी ब्रांड नाम को अरबी नियमों से बोलता है — lang="en" गायब

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

संदर्भ

• Unicode Standard Annex #9: Unicode Bidirectional AlgorithmUnicode Consortiumवह एल्गोरिदम जो मिश्रित right-to-left और left-to-right टेक्स्ट का डिस्प्ले क्रम तय करता है — ज़्यादातर bidirectional-text बग का स्रोत।
• Structural markup and right-to-left text in HTMLW3Chtml और संरचनात्मक एलिमेंट पर dir एट्रिब्यूट से base direction कैसे सेट करें, और इसके लिए केवल CSS पर क्यों न निर्भर रहें।
• Inline markup and bidirectional text in HTMLW3Cbidirectional एल्गोरिदम inline हिस्सों — अरबी टेक्स्ट के भीतर संख्याएँ, नाम, URL — को कैसे संभालता है, और उन्हें अलग करने वाला markup (bdi, dir)।
• Arabic & Persian Layout RequirementsW3C · 2025अरबी लिपि की लेआउट और टाइपोग्राफ़ी आवश्यकताएँ — दिशा, joining, justification, अंक — जिन्हें सॉफ़्टवेयर को सपोर्ट करना चाहिए (W3C Draft Note)।
• Right to left — Human Interface GuidelinesAppleright-to-left भाषाओं के लिए इंटरफ़ेस पलटने पर Apple की गाइडेंस: कौन-से एलिमेंट mirror होते हैं, कौन-से नहीं, और टेक्स्ट व संख्याएँ कैसे व्यवहार करती हैं।
• Support different languages and culturesAndroid Developers (Google)Android ऐप का लोकलाइज़ेशन: locale resources, right-to-left भाषाओं के लिए layout mirroring और RTL-aware एट्रिब्यूट।
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
• Internationalization (i18n) ActivityW3Cबहुभाषी वेब कंटेंट बनाने और टेस्ट करने के लिए W3C के internationalization लेख, ट्यूटोरियल और जाँचें।