--- A00 Change Request Specification - Page 11 Internationalization Test Pages --- Create a new set of standalone Page 11 internationalization demo pages. Generate exactly 10 HTML files, one file per target locale, using this filename pattern: `page-11-internationalization..html` Required files: `page-11-internationalization.en-US.html` `page-11-internationalization.es-MX.html` `page-11-internationalization.de-DE.html` `page-11-internationalization.fr-FR.html` `page-11-internationalization.zh-CN.html` `page-11-internationalization.ja-JP.html` `page-11-internationalization.ar-SA.html` `page-11-internationalization.hi-IN.html` `page-11-internationalization.uk-UA.html` `page-11-internationalization.th-TH.html` Each file must be a complete standalone HTML document. Put all HTML, CSS, and JavaScript inside that one file. Do not use React. Do not use TypeScript. Do not use a build step. Do not load external CSS, external JavaScript, external fonts, external images, external data, external translation files, external locale files, or external APIs. Each file must work by opening the `.html` file directly in a browser. The goal is to create high-quality, realistic, culturally localized web UI test pages for internationalization testing. The selected examples must be adapted from the strongest previous form, booking, read-only, feed/card, search, table, layout, accessibility, and extraction-resistant patterns. The final Page 11 set must not feel like one English page machine-translated into nine other languages. Each locale page must feel like a plausible local web product for that region. Each locale page must contain the same 20 conceptual examples so test coverage is comparable across languages. The content, design, spacing, typography, examples, sample names, addresses, phone numbers, dates, currency, numbers, helper text, validation messages, controls, and interaction details must be adapted per locale. All visible page content must be localized into the target language for that file. Do not leave English headings, labels, buttons, descriptions, placeholders, validation messages, tooltips, status text, test intent text, or ordinary sample user data inside non-English files unless the English text is realistic in that specific locale and intentionally part of the data, such as an English product code, API key, SKU, airport code, invoice ID, or email address. Use natural, idiomatic language. Do not use literal translation. The coding agent should write each locale as if that page was designed directly for that locale. --- B00 Page-Level Purpose --- The purpose of Page 11 is to test internationalization behavior across realistic web UI surfaces. The pages must test: Text expansion and contraction. Non-Latin script rendering. Right-to-left layout and interaction for Arabic. IME-oriented text entry for Chinese, Japanese, Hindi, Thai, Ukrainian, and other non-English scripts. Localized date formatting. Localized time formatting. Localized currency formatting. Localized decimal and thousands separators. Localized address structure. Localized phone number structure. Localized personal name structure. Localized validation messages. Localized form conventions. Localized consent and legal text. Localized pluralization. Localized sorting and filtering text. Localized accessibility labels and error summaries. Localized custom controls. Localized table and dashboard values. Localized hidden, masked, truncated, and split values. The pages should be useful for testing both visual rendering and extraction. They should contain real form behavior and enough semantic structure to test extraction, accessibility, and localization together. --- C00 Required Page Structure For Every Locale File --- Each locale file must start with a localized top-level header. The English conceptual title is: `Page 11 - Internationalization` For each non-English locale, localize the visible title naturally. Every file must include the correct `lang` attribute on ``. Use: `` `` `` `` `` `` `` `` `` `` Only `ar-SA` must use `dir="rtl"` at the document level. All other locale pages must use left-to-right layout unless a specific field contains right-to-left sample content. Under the page title, include a localized introduction paragraph explaining that the page contains 20 realistic localized UI examples for testing forms, validation, layout, accessibility, formatting, interaction, and extraction behavior. After the introduction, render exactly 20 example sections. Each example section must have: A visible localized example number or marker. A visible localized heading. A visible localized explanation paragraph. A visible localized test intent paragraph or callout that explains what internationalization behavior this example exercises. The actual UI surface. Each example section must have a stable ID from `example-01` through `example-20`. Suggested structural pattern: ```html

Example 01

``` For non-English pages, localize `Example 01` or replace it with a locally appropriate marker. The `id` values must remain English and stable for test automation. Do not include large expected extraction output blocks. These pages are application-under-test fixtures, not result documentation. --- D00 Global Technical Requirements --- Every locale page must be one portable HTML file. Every locale page must include inline `

``` For `ar-SA`, the skeleton must use: ```html ``` For `ar-SA`, CSS must use logical properties where practical, such as `margin-inline`, `padding-inline`, `border-inline-start`, and `text-align: start`. Do not rely only on left and right. --- F00 Locale-Specific File Requirements --- Each locale page must define a local configuration object in JavaScript. The coding agent may use a pattern like this: ```html ``` The page may hardcode many localized values directly in HTML, but JavaScript interactions that update totals, character counters, status messages, dates, or currency should use locale-aware formatting where useful. Use `Intl.NumberFormat` and `Intl.DateTimeFormat` where dynamic formatting improves test value. Do not require browser features that make the page fail if unsupported. For `Intl.Segmenter`, provide fallback behavior. --- G00 Distinct Locale Design Directions --- Each locale file must have its own visual design direction. Do not copy the same CSS palette and spacing across all 10 pages. The examples must be comparable by concept, but each locale page must feel locally designed. For `en-US`: Use a modern US SaaS and ecommerce style. Medium density. Clear cards, rounded corners, neutral grays, blue accents, direct action labels, US address structure, 12-hour times with AM/PM, USD, and US phone formatting such as `(415) 555-0184`. Use dates like `May 31, 2026` or `06/03/2026` depending on context. Use names such as `Jordan Ellis`, `Renee Coleman`, `Maya Chen`, and `Theo Grant`. For `es-MX`: Use Mexican Spanish. Prefer natural labels such as `Código postal`, `Colonia`, `Alcaldía o municipio`, `Estado`, `RFC de facturación` only as a fictional format if used. Use MXN, Spanish validation messages, and date formats such as `31/05/2026` or `31 de mayo de 2026`. The visual style should feel like a Mexican banking, commerce, or government-adjacent web app: slightly warmer palette, clear section bands, practical forms, and compact helper text. Use names such as `Mariana López`, `Diego Ramírez`, `Sofía Herrera`, and `Luis Torres`. For `de-DE`: Use German. Use formal but concise UI language. Use EUR formatting such as `1.234,56 €`, dates such as `31.05.2026`, 24-hour time, German address order, and labels such as `PLZ`, `Ort`, `Bundesland`, `Rechnungsadresse`, and `Pflichtfeld`. The visual style should be dense, structured, precise, and grid-oriented. Use cooler neutrals, table-like layouts, and strong section boundaries. Use names such as `Anna Keller`, `Jonas Weber`, `Mira Hoffmann`, and `Lukas Schneider`. For `fr-FR`: Use French for France. Use EUR formatting such as `1 234,56 €`, dates such as `31/05/2026` or `31 mai 2026`, 24-hour time, address structure with postal code and city, and natural labels such as `Code postal`, `Ville`, `Adresse de facturation`, `Obligatoire`. The visual style should be elegant, spacious, polished, and restrained. Use soft contrast, thin borders, and grouped form sections. Use names such as `Camille Martin`, `Julien Moreau`, `Nadia Laurent`, and `Thomas Bernard`. For `zh-CN`: Use Simplified Chinese. Use CNY formatting such as `¥1,234.56` or localized Chinese currency text when appropriate. Use date formats such as `2026年5月31日`, Chinese address ordering from province or municipality to district to street, and mobile phone patterns such as `138 0000 1842`. The visual style should feel like a contemporary Chinese web product: compact, efficient, clear status tags, practical section cards, and strong information density. Use Chinese names such as `陈晓`, `王磊`, `李娜`, and `周明`. For `ja-JP`: Use Japanese. Use JPY formatting such as `¥12,340`, date formats such as `2026年5月31日`, Japanese address ordering, postal code labels, furigana or kana fields where useful, and clear polite UI text. The visual style should feel like a Japanese business web service: compact but clean, precise labels, grouped sections, subtle color, clear status chips, and orderly forms. Use names such as `田中美咲`, `佐藤健`, `鈴木遥`, and `山本蓮`. For `ar-SA`: Use Arabic for Saudi Arabia. The entire page must be RTL with `dir="rtl"`. Use SAR formatting such as `1,234.56 ر.س` or a natural Arabic equivalent. Use Arabic UI labels, right-aligned layout, Saudi address conventions, local phone patterns such as `+966 50 123 4567`, and Arabic validation messages. The visual style should use RTL-aware spacing, start/end alignment, strong card grouping, generous vertical rhythm, and a modern Saudi digital services feel. Use Arabic names such as `نورة الأحمد`, `خالد الحربي`, `سارة القحطاني`, and `ماجد العتيبي`. For `hi-IN`: Use Hindi in Devanagari. Use INR formatting such as `₹1,23,456.78`, Indian number grouping, dates such as `31 मई 2026`, Indian address structure with PIN code, state, city, and mobile phone patterns such as `+91 98765 43210`. The visual style should be clear, mobile-friendly, moderately dense, and service-oriented. Use warm accents, clear grouping, and accessible labels. Use names such as `अंजलि शर्मा`, `रोहित वर्मा`, `नेहा सिंह`, and `विवेक पटेल`. For `uk-UA`: Use Ukrainian. Use UAH formatting such as `1 234,56 грн`, dates such as `31.05.2026`, 24-hour time, Ukrainian address structure, and labels such as `Індекс`, `Місто`, `Область`, `Обов'язкове поле`. The visual style should be practical, high-contrast, administrative, and resilient. Use clear panels, blue and yellow accents only subtly, and readable spacing. Use names such as `Олена Коваленко`, `Андрій Шевченко`, `Марія Бондар`, and `Дмитро Мельник`. For `th-TH`: Use Thai. Use THB formatting such as `฿1,234.56`, Thai Buddhist Era dates where realistic, such as `31 พฤษภาคม 2569`, Thai address order, province, district, subdistrict, postal code, and phone patterns such as `08 1234 5678`. The visual style should feel like a Thai service or commerce page: friendly, rounded, clear, a bit more colorful, with spacious form rows and strong callout panels. Use Thai names such as `อัญชลี ศรีสุข`, `กิตติพงศ์ วัฒนา`, `มาลี จันทร์เพ็ญ`, and `ธนกร แก้วใส`. --- H00 Common CSS Requirements Across Locales --- Every page must include its own CSS. The CSS may share broad utility concepts, but it must not be identical across all locale files. Each page should include these kinds of reusable classes, with locale-specific styling: `page-hero`. `example-card`. `example-header`. `example-kicker`. `example-description`. `test-intent`. `example-surface`. `field-row`. `field-label`. `field-value`. `badge`. `chip`. `panel`. `summary-panel`. `detail-panel`. `error-summary`. `error-text`. `help-text`. `layout-grid-two`. `layout-grid-three`. `split-layout`. `wide-scroll`. `sr-only`. Each locale should define its own color palette, radius scale, spacing style, table density, button style, and focus style. Do not use external fonts. Use system font stacks appropriate to each script. Suggested font-family examples: For `en-US`, `system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif`. For `es-MX`, similar Latin system stack. For `de-DE`, similar Latin system stack. For `fr-FR`, similar Latin system stack. For `zh-CN`, `system-ui, "Microsoft YaHei", "PingFang SC", "Noto Sans CJK SC", sans-serif`. For `ja-JP`, `system-ui, "Hiragino Kaku Gothic ProN", "Yu Gothic", "Meiryo", sans-serif`. For `ar-SA`, `system-ui, "Segoe UI", Tahoma, Arial, sans-serif`. For `hi-IN`, `system-ui, "Nirmala UI", "Mangal", sans-serif`. For `uk-UA`, `system-ui, "Segoe UI", Arial, sans-serif`. For `th-TH`, `system-ui, "Tahoma", "Leelawadee UI", sans-serif`. The CSS must include visible focus states. The CSS must support text expansion. Do not use fixed heights for buttons or labels that would clip translated text. Use `min-height` rather than fixed `height`. Use flexible grids and wrapping. For `zh-CN`, `ja-JP`, and `th-TH`, ensure no-space line breaking works. Do not assume words are separated by spaces. For `ar-SA`, ensure icons, field alignment, and sidebars work in RTL. Use logical properties where practical. --- I00 JavaScript Behavior Requirements --- Each locale page must include JavaScript only where it improves test value. The following interactions should be implemented across the pages, localized per file: Error summary linking to invalid fields. Character counter using locale-aware grapheme counting. Dependent dropdowns, such as region to city, city to branch, service to appointment type, or destination to available times. Conditional fields, such as showing invoice fields only when business billing is selected. Multi-step flow navigation. Tab switching. Accordion expansion. Custom combobox or listbox selection. Token add and remove behavior. Date or time slot selection. Masked value reveal. Local search or filtering. Dynamic localized status messages. No JavaScript behavior should rely on external data. All dynamic visible messages must be localized. Use event listeners after `DOMContentLoaded`. Do not dynamically generate the entire page. Static HTML must remain visible and inspectable at page load. Suggested reusable JavaScript structure: ```html ``` The coding agent must localize button labels and status messages in each file. --- J00 The 20 Selected Conceptual Examples --- Every locale page must contain exactly these 20 conceptual examples in this order: Example 01: Multi-Step Checkout And Local Address Flow. Example 02: Contact Profile With Locale-Specific Name And Phone Fields. Example 03: Booking Or Reservation Flow With Dependent Pickers. Example 04: Validation-Heavy Form With Error Summary. Example 05: Custom Combobox And Localized Search Suggestions. Example 06: Appointment Calendar And Time Slot Picker. Example 07: Read-Only Confirmation Or Receipt Page. Example 08: Invoice, Billing, Or Tax Export Configuration. Example 09: Admin Permissions Matrix. Example 10: Search Results With Filters And Detail Sidebar. Example 11: Product, Travel, Or Service Comparison Cards. Example 12: Healthcare, Insurance, Or Public Service Intake Form. Example 13: File Upload And Document Review Flow. Example 14: Consent, Notification, And Communication Preferences. Example 15: Currency, Quantity, Tax, And Total Calculation Form. Example 16: Localized Table Or Admin Dashboard. Example 17: Accessible Tabs And Accordion Settings. Example 18: Tokenized Multi-Select And Recipient Fields. Example 19: Masked, Split, Or Ellipsized Values. Example 20: Dashboard With Data Visualization Text Equivalents. These examples were selected because they provide broad coverage of real-world internationalization risk: forms, validation, accessibility, custom controls, dynamic behavior, read-only extraction, tables, dashboards, locale formatting, text expansion, input methods, script rendering, and extraction-resistant UI. --- K00 Example 01 - Multi-Step Checkout And Local Address Flow --- Create a multi-step checkout flow adapted to the locale. This example must test localized address structure, localized delivery method labels, localized phone formatting, date formatting, text expansion, required fields, conditional business billing fields, and localized progress step labels. Visible example heading must be localized from: `Multi-Step Checkout And Local Address Flow` Visible test intent must explain that the example tests address format, localized validation, step labels, shipping choices, payment summary, and text expansion. The checkout must show at least four steps: Cart or basket. Delivery or address. Payment. Review. The current step must be visually clear and marked semantically using `aria-current="step"`. The delivery or address step must be open by default. Required checkout data: Order or cart ID. Customer name. Localized delivery address fields. Localized phone number field. Delivery method selector. Delivery instructions textarea. Billing type toggle: personal or business. Conditional business billing panel. Order summary sidebar. Localized currency totals. The address fields must be locale-specific. For `en-US`, use fields such as `Street address`, `Apartment, suite, or dock`, `City`, `State`, `ZIP code`. For `es-MX`, use fields such as `Calle y número`, `Colonia`, `Alcaldía o municipio`, `Estado`, `Código postal`. For `de-DE`, use `Straße und Hausnummer`, `Adresszusatz`, `PLZ`, `Ort`, `Bundesland`. For `fr-FR`, use `Adresse`, `Complément d'adresse`, `Code postal`, `Ville`. For `zh-CN`, use `省/直辖市`, `市`, `区/县`, `详细地址`, `邮政编码`. For `ja-JP`, use `郵便番号`, `都道府県`, `市区町村`, `町名・番地`, `建物名・部屋番号`. For `ar-SA`, use Arabic fields for region, city, district, street, building number, postal code, and additional directions. Layout must be RTL. For `hi-IN`, use Hindi fields for house or flat, street or area, city, state, PIN code, and landmark. For `uk-UA`, use Ukrainian fields for street, building, apartment, city, region, postal index. For `th-TH`, use Thai fields for house number, road, subdistrict, district, province, postal code. Required interaction: When the user selects business billing, show the business billing panel. When delivery instructions exceed a locale-specific character limit, show a localized validation message and character counter. When the tester clicks the Review step, update a localized status message such as `Review step selected` in the target language. Required fields in the order summary: Items count. Merchandise subtotal. Delivery fee. Tax or VAT where appropriate. Discount. Order total. Estimated delivery date. Extraction caveat: the extraction tool should preserve step state, localized address field names, conditional billing state, localized totals, and localized validation messages. --- L00 Example 02 - Contact Profile With Locale-Specific Name And Phone Fields --- Create a profile or account contact form with culturally appropriate name fields, phone fields, and communication language preference. Visible example heading must be localized from: `Contact Profile With Locale-Specific Name And Phone Fields` Visible test intent must explain that the example tests name order, script input, phone formatting, placeholders, helper text, and validation. The fields must vary by locale. For `en-US`, use given name, family name, preferred name, email, mobile phone, time zone. For `es-MX`, use nombre, primer apellido, segundo apellido, correo, teléfono móvil, estado. For `de-DE`, use Vorname, Nachname, Anrede, E-Mail, Mobiltelefon, bevorzugte Sprache. For `fr-FR`, use prénom, nom, civilité, adresse e-mail, téléphone mobile. For `zh-CN`, use 姓名 as a combined field, 拼音 or preferred display name, 手机号码, 电子邮箱, 所在地区. For `ja-JP`, use 氏名, フリガナ, メールアドレス, 携帯電話番号, 連絡可能時間. For `ar-SA`, use الاسم الكامل, اسم العرض, البريد الإلكتروني, رقم الجوال, المدينة, preferred contact channel. RTL required. For `hi-IN`, use पूरा नाम, पिता/माता का नाम only if realistic for the service, ईमेल, मोबाइल नंबर, राज्य, preferred language. For `uk-UA`, use ім'я, прізвище, по батькові where appropriate, електронна пошта, номер телефону, область. For `th-TH`, use ชื่อ, นามสกุล, ชื่อที่ต้องการให้แสดง, อีเมล, เบอร์โทรศัพท์, จังหวัด. Include at least one field with IME-friendly placeholder behavior for `zh-CN`, `ja-JP`, `hi-IN`, and `th-TH`. Include localized validation: Invalid phone format. Required display name or full name. Email helper text. Character counter for display name. Include a profile summary card that mirrors the entered values in localized field labels. Extraction caveat: the extraction tool should not assume Western first-name and last-name structure for all locales. It should preserve the local name model. --- M00 Example 03 - Booking Or Reservation Flow With Dependent Pickers --- Create a realistic booking or reservation form with dependent dropdowns, date selection, time selection, guest or participant count, and special requests. Visible example heading must be localized from: `Booking Or Reservation Flow With Dependent Pickers` Visible test intent must explain that the example tests dependent dropdowns, localized dates, localized time formats, custom pickers, localized availability messages, and dynamic validation. The scenario must be adapted per locale. Use examples such as: Hotel or delivery appointment for `en-US`. Restaurant reservation or parcel pickup for `es-MX`. Train or service appointment for `de-DE`. Medical or administrative appointment for `fr-FR`. Hotel, clinic, or service booking for `zh-CN`. Clinic or restaurant reservation for `ja-JP`. Government service or clinic appointment for `ar-SA`. Public service appointment or delivery slot for `hi-IN`. Administrative service appointment for `uk-UA`. Clinic, bank, or delivery appointment for `th-TH`. Required controls: Service category selector. Location selector dependent on selected service. Date picker or date input. Time picker dependent on date. Party size, guests, or participants. Special request textarea. Availability status message. Booking summary panel. Required JavaScript: Changing service category should update available locations. Changing location should update available times. Selecting a time should update the summary panel. If party size exceeds available capacity, show a localized warning. Extraction caveat: the extraction tool should capture the selected service, selected location, localized date, selected time, party count, warning state, and summary values. --- N00 Example 04 - Validation-Heavy Form With Error Summary --- Create a form with multiple invalid fields, an accessible error summary, inline errors, helper text, required states, and localized validation messages. Visible example heading must be localized from: `Validation-Heavy Form With Error Summary` Visible test intent must explain that the example tests localized error messages, required markers, `aria-invalid`, `aria-describedby`, error summary links, and long translated validation text. The scenario should be localized but comparable. Use an account setup, application, onboarding, or registration form. Required sections: Identity or applicant section. Address or organization section. Contact section. Agreement or consent section. Error summary at top with at least four errors. Each error summary item must link to a field. Invalid fields must have `aria-invalid="true"`. Invalid fields must have `aria-describedby` pointing to the inline error. Required example errors: Missing required name or organization field. Invalid phone number. Invalid postal code or local address field. Date outside allowed range. Required checkbox not checked. Localized error messages must be idiomatic. Do not use English error text in non-English pages. Extraction caveat: the extraction tool should extract both field values and validation context. It should not treat the error summary as unrelated navigation. --- O00 Example 05 - Custom Combobox And Localized Search Suggestions --- Create a custom combobox with localized search suggestions and a detached or portaled listbox. Visible example heading must be localized from: `Custom Combobox And Localized Search Suggestions` Visible test intent must explain that the example tests localized search strings, selected option text, accessible combobox relationships, detached listbox DOM, IME input, and no-space line breaking where relevant. Required controls: Visible label. Input or trigger with `role="combobox"`. `aria-expanded="true"`. `aria-controls` pointing to the listbox. `aria-activedescendant` pointing to the selected or active option. Hidden submitted value. Detached listbox panel outside the immediate form group. At least five localized suggestions. Each suggestion must include: Primary label. Secondary supporting text. Local identifier or code. Selected state. Examples: Destination city. Clinic branch. Bank branch. Product category. Document type. Government service. For `zh-CN`, `ja-JP`, `hi-IN`, and `th-TH`, suggestions must include non-Latin script and should not require spaces between tokens. For `ar-SA`, listbox direction must be RTL and aligned to the right. Extraction caveat: the extraction tool should connect trigger value, selected suggestion, active descendant, hidden submitted value, and detached option text. --- P00 Example 06 - Appointment Calendar And Time Slot Picker --- Create a localized appointment calendar and time slot picker. Visible example heading must be localized from: `Appointment Calendar And Time Slot Picker` Visible test intent must explain that the example tests localized weekday names, localized date formatting, selected date state, unavailable dates, time formats, calendar grid semantics, and locale-specific reading order. Required fields: Provider, branch, or service name. Calendar month. Selected date. Available dates. Unavailable dates. Selected time slot. Other available time slots. Booking summary. Use either semantic table markup or `role="grid"` with accessible labels. Each date cell must include: Visible date number. Accessible full date label. Availability state. Selected or disabled state. For `ar-SA`, the calendar must be RTL. Weekday order should feel appropriate for the locale. Do not force a US calendar layout. For `th-TH`, dates should use Buddhist Era in visible text where appropriate. For `ja-JP` and `zh-CN`, include natural localized date strings. Extraction caveat: the extraction tool should capture selected date, localized full date, time slots, disabled dates, and availability labels. --- Q00 Example 07 - Read-Only Confirmation Or Receipt Page --- Create a read-only confirmation page. It should be visually rich and localized, not a simple key-value table. Visible example heading must be localized from: `Read-Only Confirmation Or Receipt Page` Visible test intent must explain that the example tests localized read-only records, confirmation numbers, currency, dates, status badges, nested line items, and receipt summaries. Scenario may vary by locale: Order confirmation. Bank transfer receipt. Hotel booking confirmation. Clinic appointment confirmation. Government service receipt. Required fields: Confirmation number. Status. Created date and time. Customer or applicant. Localized address or branch. Payment or fee amount. Localized currency. Nested line items or service items. Total. Important note or cancellation policy. Action buttons such as download, print, copy reference, or add to calendar. Include at least one uneditable or readonly-looking value. Include at least one masked or partially hidden value, such as card ending, account ending, phone ending, or masked reference. Extraction caveat: the extraction tool should preserve nested line items and not merge them with receipt totals. --- R00 Example 08 - Invoice, Billing, Or Tax Export Configuration --- Create a billing export or tax report configuration form with localized fiscal terminology. Visible example heading must be localized from: `Invoice, Billing, Or Tax Export Configuration` Visible test intent must explain that the example tests localized fiscal fields, checkboxes, CSV/export field selection, date ranges, tax labels, encoding concerns, and locale-specific number and currency formatting. Required fields: Report or export name. Date range. Tax or VAT mode. Export format. Encoding or file format selection where realistic. Recipient email field. Checkboxes for included columns. Scheduled export toggle. Localized preview summary. Export field multi-select or checklist. Include at least six export fields. Fields should vary naturally by locale. For example: `en-US`: sales tax, invoice number, payment reference. `es-MX`: IVA, RFC de facturación, folio fiscal as fictional demo. `de-DE`: USt., Rechnungsnummer, Zahlungsreferenz. `fr-FR`: TVA, numéro de facture, référence de paiement. `zh-CN`: 增值税, 发票号, 付款参考. `ja-JP`: 消費税, 請求書番号, 支払参照. `ar-SA`: ضريبة القيمة المضافة, رقم الفاتورة, مرجع الدفع. `hi-IN`: GST, चालान संख्या, भुगतान संदर्भ. `uk-UA`: ПДВ, номер рахунку, посилання на оплату. `th-TH`: ภาษีมูลค่าเพิ่ม, เลขที่ใบแจ้งหนี้, อ้างอิงการชำระเงิน. Extraction caveat: the extraction tool should capture selected export fields, date range, file format, schedule, and localized tax terminology. --- S00 Example 09 - Admin Permissions Matrix --- Create a localized admin permissions matrix with role columns and permission rows. Visible example heading must be localized from: `Admin Permissions Matrix` Visible test intent must explain that the example tests localized table headers, role names, permission names, checked states, disabled states, group labels, dense UI, and screen-reader-friendly labels. Required groups: Billing or finance. User management. Security. Reports or analytics. Required role columns: Admin. Billing manager or equivalent. Editor or staff. Viewer or read-only user. At least 10 permission rows total. Use checkboxes or check-like symbols with accessible labels. Some permissions must be checked. Some must be unchecked. Some must be disabled. Include a selected permission detail panel. The selected detail panel must include: Permission name. Group. Description. Risk level. Recommended roles. Extraction caveat: the extraction tool should preserve row header and column header context. It should not output only checked boxes. --- T00 Example 10 - Search Results With Filters And Detail Sidebar --- Create localized search results with filters, repeated results, status badges, and selected detail sidebar. Visible example heading must be localized from: `Search Results With Filters And Detail Sidebar` Visible test intent must explain that the example tests localized search query, filters, sort controls, result cards, repeated field labels, selected record state, and sidebar context. The scenario may vary by locale but must remain comparable: Jobs. Bookings. Support tickets. Invoices. Service providers. Products. Required search area: Search query input. Sort selector. Result count. Active filter chips. Filter sidebar with at least three groups. Result list with at least five records. Selected result detail sidebar. Each result must include at least six fields. Examples of fields: Title. Source or organization. Location. Date. Status. Amount or rating. Tags. Snippet. Primary link. Selected detail sidebar must add at least six more fields. Extraction caveat: the extraction tool should keep result records separate from filters and selected detail sidebar. --- U00 Example 11 - Product, Travel, Or Service Comparison Cards --- Create a localized comparison layout with three or four compared options. Visible example heading must be localized from: `Product, Travel, Or Service Comparison Cards` Visible test intent must explain that the example tests repeated labels across comparison columns, localized currency, localized units, status tags, and visual grouping. The compared entity may be: Product plans. Hotel rooms. Rental vehicles. Service packages. Bank accounts. Delivery options. Required comparison data: Option name. Provider. Price. Localized currency. Availability. Primary benefit. Limitation. Status. Localized note. Selected or recommended option. Shared criteria panel. Selected option summary. Each option column must reuse labels such as price, status, included items, and notes. Extraction caveat: the extraction tool should preserve each column as a distinct option. It should not merge all repeated `Price`, `Status`, or `Notes` fields. --- V00 Example 12 - Healthcare, Insurance, Or Public Service Intake Form --- Create a complex localized intake form. Choose a scenario that feels realistic for the locale. Visible example heading must be localized from: `Healthcare, Insurance, Or Public Service Intake Form` Visible test intent must explain that the example tests long localized labels, sensitive-form layout, local identity conventions without real identifiers, conditional questions, consent, validation, and grouped fieldsets. Possible scenarios: Clinic intake. Insurance claim. Public benefit application. Appointment registration. Municipal service request. Required sections: Applicant or patient information. Contact information. Service or claim details. Address or location. Documents or evidence. Consent or declaration. Use at least three fieldsets or visually grouped panels. Use at least one conditional field. Use at least one long localized helper text. Use at least one localized consent checkbox. Use at least one date input or date-like localized value. Do not use real government ID numbers. If an ID-like field is included, clearly make it fictional and avoid realistic sensitive identifiers. Extraction caveat: the extraction tool should preserve group context and not flatten sensitive intake fields into an unstructured list. --- W00 Example 13 - File Upload And Document Review Flow --- Create a localized document upload and review interface. Visible example heading must be localized from: `File Upload And Document Review Flow` Visible test intent must explain that the example tests localized upload labels, document statuses, file names, validation, accepted file types, progress, and review notes. Required fields: Document category selector. Upload control. Accepted file types help text. At least four document rows. Each document row must include: Document name. File name. File size. Upload date. Review status. Reviewer note. Action button. Include at least one missing document. Include at least one rejected or needs-correction document. Include at least one approved document. Include progress or completion summary. For non-English pages, file names may include localized script where realistic. Keep file extensions ASCII. Extraction caveat: the extraction tool should preserve document status and review notes per document. It should not treat all file names as generic attachments. --- X00 Example 14 - Consent, Notification, And Communication Preferences --- Create localized consent and communication preferences with switches, checkboxes, radio buttons, legal helper text, and channel-specific options. Visible example heading must be localized from: `Consent, Notification, And Communication Preferences` Visible test intent must explain that the example tests localized consent wording, opt-in or opt-out conventions, channel labels, legal text expansion, switch state, and accessibility labels. Required groups: Transactional notifications. Marketing or promotional messages. Security alerts. Digest frequency. Preferred language or locale. Preferred channel. Required controls: Switch or checkbox for email notifications. Switch or checkbox for SMS or local equivalent. Radio group for digest frequency. Select for preferred language. Consent checkbox with long localized legal text. Preview panel showing current preferences. At least one disabled channel with a localized explanation. Extraction caveat: the extraction tool should capture consent states and channel-specific preferences without merging legal helper text into unrelated fields. --- Y00 Example 15 - Currency, Quantity, Tax, And Total Calculation Form --- Create a localized price calculation form with quantity, unit price, tax, discount, shipping or service fee, and total. Visible example heading must be localized from: `Currency, Quantity, Tax, And Total Calculation Form` Visible test intent must explain that the example tests locale-aware currency, decimal separators, thousands separators, tax terminology, numeric input, totals, and validation. Required fields: Item or service. Quantity. Unit price. Discount. Tax rate. Tax amount. Shipping or service fee. Subtotal. Total. Localized currency. Localized number formatting. At least one inline validation message for invalid quantity or amount. Required JavaScript: Changing quantity or discount updates totals with localized formatting. Do not assume dot decimal separators for all locales. Use `Intl.NumberFormat`. For India, use Indian grouping for large numbers. For Thailand, use THB and optionally Buddhist Era dates elsewhere. Extraction caveat: the extraction tool should capture both input values and calculated localized display values. --- Z00 Example 16 - Localized Table Or Admin Dashboard --- Create a localized admin dashboard with KPI cards and a table or grid. Visible example heading must be localized from: `Localized Table Or Admin Dashboard` Visible test intent must explain that the example tests localized table headers, dense data, status labels, dates, numbers, currency, sorting controls, and selected row details. Required dashboard: At least four KPI cards. A toolbar with date range, status filter, and search field. A table or grid with at least six rows. Selected row detail panel. Fields should include: Record ID. Name or title. Owner. Localized date. Localized amount or count. Status. Priority or category. Action buttons. Use localized status badges. Use localized date and number formats. Extraction caveat: the extraction tool should preserve KPI cards separately from table rows and selected row details. --- AA00 Example 17 - Accessible Tabs And Accordion Settings --- Create localized settings that combine tabs and accordions. Visible example heading must be localized from: `Accessible Tabs And Accordion Settings` Visible test intent must explain that the example tests localized tab labels, active tab state, accordion expansion, repeated labels, hidden content, and accessibility state. Required structure: Tab list with at least three tabs. The first tab active by default. Each tab panel contains at least two accordion sections. At least one accordion section expanded by default. At least one accordion collapsed by default with visible summary. Use `role="tablist"`, `role="tab"`, and `role="tabpanel"`. Use `aria-selected`, `aria-controls`, `aria-expanded`, and `hidden`. Settings categories may include: Billing. Security. Notifications. Data retention. Integrations. For non-English pages, all visible labels, section titles, and status messages must be localized. Extraction caveat: the extraction tool should capture visible active tab content and expanded accordion content, while respecting hidden content. --- AB00 Example 18 - Tokenized Multi-Select And Recipient Fields --- Create a localized tokenized multi-select control. Visible example heading must be localized from: `Tokenized Multi-Select And Recipient Fields` Visible test intent must explain that the example tests selected tokens, remove buttons, hidden values, listbox options, locale-specific email or contact labels, and no-space script behavior. Required groups: Recipients. Export fields, topics, categories, or notification channels. Selected tokens. Remove buttons with localized accessible labels. Search input. Available options listbox. Hidden submitted values. At least three selected tokens. At least four available options. At least one option already selected. For non-English locales, token visible labels should be localized where not email addresses. Use `example.test` emails if emails are included. Extraction caveat: the extraction tool should preserve selected tokens separately from available options and remove button labels. --- AC00 Example 19 - Masked, Split, Or Ellipsized Values --- Create a localized extraction-resistant but safe example with masked, split, or ellipsized values. Visible example heading must be localized from: `Masked, Split, Or Ellipsized Values` Visible test intent must explain that the example tests masked visible values, split DOM values, truncated text, reveal behavior, and localized labels. Required hostile patterns: At least one masked value. At least one reveal button. At least one split value across multiple spans. At least one ellipsized long value with full value in `title` or `aria-label`. At least one hidden backing value. Suggested scenario: Bank account settings. API webhook settings. Shipment tracking. Invoice reference. Required data: Record title. Status. Masked value. Revealed demo value hidden by default. Split ID or reference number. Ellipsized URL or address. Summary panel. Extraction caveat: the extraction tool should extract exactly what is visible by default, and only extract revealed values after the tester reveals them. --- AD00 Example 20 - Dashboard With Data Visualization Text Equivalents --- Create a localized dashboard with CSS-only chart placeholders and text equivalents. Visible example heading must be localized from: `Dashboard With Data Visualization Text Equivalents` Visible test intent must explain that the example tests localized chart titles, text alternatives, data tables, percentage formatting, trend language, pluralization, and accessible summaries. Required dashboard: Dashboard title. Period. Owner. Status. At least three chart cards. Each chart card must include: Chart title. CSS-only visual placeholder. Text equivalent using visible description and `aria-describedby`. Small localized data table or field rows. Trend summary. Status badge. Include at least one plural-sensitive phrase that differs by count in that language where applicable. No canvas. No chart library. Do not encode chart data only in CSS. Extraction caveat: the extraction tool should extract text equivalents and data tables, not infer chart values from bar widths alone. --- AE00 Per-Locale Content Adaptation Requirements --- Each page must include the same 20 example concepts, but the sample data must be localized. Do not use the same fictional customer across all locales. Do not use US addresses in non-US files. Do not use USD outside the `en-US` page unless it is intentionally a foreign-currency field and clearly labeled as such. Do not use English-only service names in non-English pages unless it is a code, product name, or email address that would realistically stay in English. Do not use direct literal translations of headings if a local phrase is more natural. Do not use the same visual hierarchy across all pages. Do not use the same validation message wording across all pages. Do not use the same color palette across all pages. Do not assume all locales use the same address order. Do not assume all locales use first name then last name. Do not assume all locales use `MM/DD/YYYY`. Do not assume all locales use 12-hour time. Do not assume all locales use dot decimal separators. Do not assume all locales use spaces between words. Do not assume all locales are left-to-right. For every page, use content that looks like a complete local page, not a translation file test harness. --- AF00 Required Locale Data And Formatting Matrix --- Use this matrix as the baseline. The coding agent may improve details, but must preserve the intent. `en-US`: Currency: USD. Date examples: `May 31, 2026`, `06/03/2026`. Time examples: `10:42 AM`, `5:00 PM`. Phone: `(415) 555-0184`. Address style: street, unit, city, state, ZIP. Number format: `1,234.56`. Direction: LTR. `es-MX`: Currency: MXN. Date examples: `31/05/2026`, `31 de mayo de 2026`. Time examples: `10:42`, `17:00`. Phone: `55 1234 5678`. Address style: calle, número, colonia, municipio or alcaldía, estado, código postal. Number format: `1,234.56` is common in many Mexican digital products; use consistently. Direction: LTR. `de-DE`: Currency: EUR. Date examples: `31.05.2026`. Time examples: `10:42 Uhr`, `17:00 Uhr`. Phone: `+49 30 123456`. Address style: street and house number, postal code, city. Number format: `1.234,56`. Direction: LTR. `fr-FR`: Currency: EUR. Date examples: `31/05/2026`, `31 mai 2026`. Time examples: `10:42`, `17:00`. Phone: `06 12 34 56 78`. Address style: street, postal code, city. Number format: `1 234,56`. Direction: LTR. `zh-CN`: Currency: CNY. Date examples: `2026年5月31日`. Time examples: `10:42`, `17:00`. Phone: `138 0000 1842`. Address style: province or municipality, city, district, street, detail address. Number format: `1,234.56`. Direction: LTR. `ja-JP`: Currency: JPY. Date examples: `2026年5月31日`. Time examples: `10:42`, `17:00`. Phone: `090-1234-5678`. Address style: postal code, prefecture, city, ward, block, building. Number format: `1,234`. Direction: LTR. `ar-SA`: Currency: SAR. Date examples: Arabic localized date text or `31/05/2026` with Arabic labels. Time examples: 24-hour or localized AM/PM in Arabic. Phone: `+966 50 123 4567`. Address style: region, city, district, street, building number, postal code. Number format: Arabic-localized digits may be used. Be consistent inside the page. Direction: RTL. `hi-IN`: Currency: INR. Date examples: `31 मई 2026`. Time examples: `10:42`, `17:00`. Phone: `+91 98765 43210`. Address style: flat or house, street, area, city, state, PIN code. Number format: `1,23,456.78`. Direction: LTR. `uk-UA`: Currency: UAH. Date examples: `31.05.2026`. Time examples: `10:42`, `17:00`. Phone: `+380 50 123 45 67`. Address style: street, building, apartment, city, region, postal index. Number format: `1 234,56`. Direction: LTR. `th-TH`: Currency: THB. Date examples: `31 พฤษภาคม 2569` where Buddhist Era is appropriate. Time examples: `10:42`, `17:00`. Phone: `08 1234 5678`. Address style: house number, road, subdistrict, district, province, postal code. Number format: `1,234.56`. Direction: LTR. --- AG00 Localized Page Design Requirements By File --- For `page-11-internationalization.en-US.html`: Design should feel like a polished US SaaS admin and ecommerce page. Use roomy cards, strong primary buttons, clear form labels, blue or indigo accent, concise helper text, and straightforward validation messages. Use examples such as US checkout, clinic appointment, billing export, admin dashboard, and service comparison. For `page-11-internationalization.es-MX.html`: Design should feel like a Mexican service portal or commerce platform. Use warm accents, compact but clear form rows, practical section headers, and labels that match Mexican address and billing conventions. Use examples such as delivery checkout, appointment reservation, invoice or tax export with IVA terminology, and local service comparison. For `page-11-internationalization.de-DE.html`: Design should feel precise and administrative. Use structured panels, dense tables, subdued colors, formal tone, and clear validation. Use examples such as billing dashboard, permission matrix, appointment booking, tax export, and official-style intake. For `page-11-internationalization.fr-FR.html`: Design should feel polished and service-oriented. Use elegant cards, moderate density, soft accents, and careful section grouping. Use examples such as service reservation, invoice configuration with TVA, customer profile, document review, and notification preferences. For `page-11-internationalization.zh-CN.html`: Design should feel like a modern Chinese web product. Use compact sections, strong status tags, practical dashboards, clear search and picker controls, and dense data cards. Use examples such as service appointment, invoice export, document upload, dashboard, and localized combobox. For `page-11-internationalization.ja-JP.html`: Design should feel like a Japanese business web system. Use orderly spacing, compact labels, clear status labels, restrained color, and detailed helper text. Use examples such as clinic appointment, delivery confirmation, billing export, settings accordion, and document review. For `page-11-internationalization.ar-SA.html`: Design must be fully RTL. Use a modern Saudi service portal feel. Use right-aligned labels, RTL grids, logical CSS properties, Arabic copy, local phone and address patterns, SAR formatting, and Arabic validation text. Be careful with mixed LTR data such as email addresses, order IDs, and URLs. Wrap them in elements with `dir="ltr"` where needed. For `page-11-internationalization.hi-IN.html`: Design should feel like an Indian service or commerce form. Use accessible spacing, warm accents, Hindi labels, Indian number grouping, PIN code fields, and clear mobile-friendly forms. Some technical IDs and email addresses may remain ASCII, but visible labels and messages must be Hindi. For `page-11-internationalization.uk-UA.html`: Design should feel practical and reliable. Use clear panels, accessible contrast, Ukrainian labels, UAH formatting, administrative form patterns, and 24-hour time. Use examples such as service appointment, document review, billing table, permissions, and notification settings. For `page-11-internationalization.th-TH.html`: Design should feel like a Thai service or commerce page. Use friendly rounded cards, clear help text, Thai labels, Thai date text, postal code and province fields, and THB formatting. Ensure Thai text wraps naturally. Do not rely on spaces for line breaks. --- AH00 Accessibility Requirements --- Every locale page must include accessible form labels. Every input must have a label or accessible name. Error summaries must be accessible. Inline error text must be connected to fields through `aria-describedby`. Invalid fields must use `aria-invalid="true"`. Required fields must use either the native `required` attribute or a clear accessible indication. Tabs must use `role="tablist"`, `role="tab"`, `role="tabpanel"`, and `aria-selected`. Accordions must use buttons with `aria-expanded` and `aria-controls`. Custom comboboxes must use `role="combobox"`, `aria-expanded`, `aria-controls`, and where useful `aria-activedescendant`. Custom listboxes must use `role="listbox"` and `role="option"`. Token remove buttons must have localized accessible labels. Icon-only buttons must have localized `aria-label`. Calendar dates must have accessible full date labels. Data visualization examples must include text equivalents. Masked-value reveal buttons must have localized labels. For `ar-SA`, ensure screen-reader order and visual order remain coherent in RTL. --- AI00 Internationalization Edge Cases To Include --- Across the 20 examples in every page, include these edge cases somewhere: Long localized labels that wrap onto multiple lines. Long localized validation message. Localized date formatting. Localized currency formatting. Localized decimal or thousands separator. Localized phone number. Localized address structure. Localized name structure. At least one custom widget. At least one table. At least one dynamic total calculation. At least one character counter. At least one multi-step UI. At least one conditional section. At least one hidden or revealed value. At least one selected state. At least one disabled state. At least one error summary. At least one tooltip or helper text. At least one live status message. At least one accessible tab or accordion. At least one tokenized multi-select. At least one comparison layout. At least one read-only confirmation. At least one non-Latin script example for non-Latin locales. For `ar-SA`, include at least one mixed-direction row with Arabic labels and LTR technical values such as an email, URL, invoice ID, or API key. For `zh-CN`, `ja-JP`, and `th-TH`, include at least one example with long text that has no spaces or limited spaces to test wrapping. For `hi-IN`, include at least one Indian-number-grouped currency value such as `₹1,23,456.78`. For `th-TH`, include at least one Buddhist Era date. --- AJ00 Page-Level Localized Content Requirements --- Each page must include localized versions of these page-level concepts: Page kicker, equivalent to `Internationalization Test Page`. Page title, equivalent to `Page 11 - Internationalization`. Intro paragraph. Each example heading. Each example explanation paragraph. Each test intent paragraph. All labels. All helper text. All validation text. All placeholder text. All button labels. All table headers. All chart titles. All status badge text. All field values that are ordinary user-facing words. All action menu labels. All empty states. All live region messages. Technical strings may remain ASCII if realistic: Email addresses. URLs. Order IDs. Invoice IDs. Tracking IDs. API keys. SKU codes. Airport codes. File extensions. Internal IDs. Do not translate technical IDs themselves, but localize their labels. --- AK00 Example Implementation Depth --- Each example must be rich enough to be useful. Do not create 20 tiny examples with one or two fields. Each example should have at least eight visible extractable values. Many examples should have 15 or more extractable values. At least eight examples must include JavaScript interaction. At least five examples must include a table, grid, repeated cards, or repeated row records. At least five examples must include inline validation, helper text, warnings, or error states. At least four examples must include conditional or hidden content. At least three examples must include accessible custom widget semantics. At least two examples must include masked, split, truncated, or revealed values. At least one example must include a localized data visualization with text equivalent. Each example must include enough realistic context that it could plausibly exist as part of a real web product. --- AL00 Suggested Localized Data Themes --- The coding agent should choose locally realistic themes while preserving the conceptual structure. Use these as suggested themes, not rigid requirements: `en-US`: online order checkout, clinic appointment, billing exports, workspace admin, support tickets. `es-MX`: delivery checkout, restaurant or government appointment, invoice export with IVA, document upload, notification settings. `de-DE`: service booking, invoice export with USt., account permissions, administrative application, payment confirmation. `fr-FR`: service reservation, VAT invoice export, public service intake, document review, account settings. `zh-CN`: hotel or service booking, invoice export, work order search, document upload, dashboard. `ja-JP`: clinic appointment, delivery order, billing export, account settings, document review. `ar-SA`: government or clinic appointment, delivery checkout, invoice export with VAT, document upload, communication preferences. `hi-IN`: service appointment, ecommerce checkout, GST invoice export, document upload, notification consent. `uk-UA`: administrative appointment, payment confirmation, document review, dashboard, permissions. `th-TH`: clinic or delivery appointment, ecommerce checkout, tax invoice export, document review, dashboard. Do not force every locale into the exact same fictional scenario if a different local scenario makes the example more realistic. Preserve the conceptual test coverage. --- AM00 Code Snippet - Locale-Aware Character Counter --- Use a localized character counter in at least Example 01, Example 02, or Example 14. Suggested implementation: ```html Display name

0 / 40

``` The visible counter label or surrounding helper text must be localized in each file. The raw `0 / 40` format may be adapted if the locale naturally uses different wording. --- AN00 Code Snippet - Locale-Aware Currency Totals --- Use locale-aware currency calculations in Example 15. Suggested implementation: ```html ``` Each locale file must localize labels such as quantity, unit price, discount, tax, subtotal, and total. Do not require users to type locale-formatted numbers into JavaScript parsing for this fixture. Keep raw numeric data in `data-raw-value` and display localized values. --- AO00 Code Snippet - RTL-Safe Mixed Direction Values For ar-SA --- For `ar-SA`, wrap LTR technical strings inside `dir="ltr"` where needed. Use this pattern: ```html

رقم الفاتورة INV-2026-00841

البريد الإلكتروني billing@example.test

``` Do not let invoice IDs, URLs, email addresses, API keys, or file names become visually scrambled inside RTL text. The Arabic page must also use logical CSS properties where practical. --- AP00 Code Snippet - Localized Error Summary --- Every locale page must include at least one accessible localized error summary. Suggested structure: ```html

``` Do not leave English error text in non-English files. --- AQ00 Code Snippet - Localized Custom Combobox --- Example 05 must include a custom combobox. Suggested structure: ```html

``` The listbox may be visually adjacent but structurally detached. This is intentional. --- AR00 Code Snippet - Localized Tabs And Accordion --- Example 17 must include tabs and accordions. Suggested structure: ```html

``` All labels and dynamic button text must be localized. --- AS00 Quality Bar --- The final result must be a complete 10-file internationalization test suite. Every file must be standalone. Every file must contain exactly 20 examples. Every file must contain the same 20 conceptual examples in the same order. Every file must be localized for its target language and region. Every file must have its own distinct CSS and visual design direction. Every file must include realistic localized sample data. Every file must include enough interaction to test dynamic localized UI behavior. Every file must include accessible labels, error summaries, and custom control semantics where required. Every file must include localized test intent text for each example. Every file must avoid shallow placeholder examples. Every file must avoid direct English leftovers in visible UI text. Every file must avoid using one global visual design copied across locales. Every file must use locale-appropriate formatting for dates, times, numbers, currencies, phone numbers, names, and addresses. Every file must support text expansion and script-specific rendering. The `ar-SA` file must be fully RTL and must handle mixed LTR technical strings correctly. The implementation should favor realism, cultural localization, accessibility, and extraction test value over code compactness. The coding agent may improve local phrasing, visual styling, sample names, and scenario choices, but it must not remove examples, reduce complexity, skip locales, merge files, or create a single shared page. Final output must be these 10 portable HTML files: `page-11-internationalization.en-US.html` `page-11-internationalization.es-MX.html` `page-11-internationalization.de-DE.html` `page-11-internationalization.fr-FR.html` `page-11-internationalization.zh-CN.html` `page-11-internationalization.ja-JP.html` `page-11-internationalization.ar-SA.html` `page-11-internationalization.hi-IN.html` `page-11-internationalization.uk-UA.html` `page-11-internationalization.th-TH.html` --- AT00 Appendix - Internationalization Quality Guidance For Page 11 --- This appendix adds implementation guidance for the Page 11 internationalization test suite. It is intended for the coding agent that will generate the 10 locale-specific HTML files. The goal of this appendix is to raise the quality bar beyond basic translation. The coding agent must treat every locale page as a locally designed product page, not as a translated clone. The same 20 conceptual examples must appear in every locale file, but the visual design, data, layout density, writing style, form conventions, and interaction details must be adapted per locale. This appendix is additive. It does not replace the Page 11 specification. Follow the main Page 11 specification first, then apply this appendix to improve realism, coverage, accessibility, design quality, and extraction-test value. --- AU00 Strong Rule - Do Not Build A Translation Harness --- Do not create one English page and swap strings. Do not create one shared CSS design and reuse it across all locales with only text changes. Do not create pages that look like an internal translation QA table. These must look like real product pages. Each locale page must feel as if a local product team designed it for that market. The conceptual examples remain the same, but the local form structure, labels, examples, pacing, line length, helper text, density, button placement, address structure, phone structure, and validation style must change. A weak implementation would create the same checkout card in every locale with translated labels. A strong implementation would make the US checkout feel like a modern ecommerce checkout, the German checkout feel like a precise administrative checkout, the Japanese checkout feel like an orderly business workflow, the Arabic checkout feel like a native RTL service portal, and the Thai checkout feel like a friendly local service page. The coding agent should repeat this mindset for every example. --- AV00 Locale Page Personality Matrix --- Each file must have a distinct visual and interaction personality. For `en-US`, use a modern SaaS and ecommerce product feel. Use white cards, clear blue or indigo accents, direct headings, short helper text, prominent primary buttons, and medium density. Buttons may say things like `Continue to review`, `Save preferences`, or `Update total`. For `es-MX`, use a warm practical service-portal feel. Use warm accent colors, compact but readable panels, strong section headers, practical address fields, and friendly Spanish copy. Helper text should be clear and conversational without sounding like Spain Spanish. For `de-DE`, use a precise, structured, administrative feel. Use dense layouts, clear table borders, compact labels, formal German copy, strong grouping, and exact values. Do not make it playful. German text expansion is expected, so label columns and buttons must wrap cleanly. For `fr-FR`, use a polished public-service or account-management feel. Use calm spacing, thin borders, elegant grouping, restrained colors, and natural French phrasing. Avoid awkward literal translations. Prefer labels like `Adresse de facturation`, `Code postal`, `Montant total`, and `Préférence de contact`. For `zh-CN`, use a compact modern web-product feel. Use efficient spacing, strong status tags, dense cards, clear headings, and practical labels. Support no-space Chinese text wrapping. Use Chinese names, addresses, and realistic mobile phone formatting. For `ja-JP`, use an orderly Japanese business-system feel. Use compact controls, detailed helper text, polite UI language, subtle status labels, precise grouping, and structured sections. Include kana/furigana-style fields where useful. For `ar-SA`, use a native Arabic RTL service-portal feel. Use right-to-left flow throughout. Use logical CSS properties. Align labels and sections to the right. Wrap technical IDs, emails, URLs, invoice IDs, API keys, and file names with `dir="ltr"`. Do not allow mixed-direction values to visually scramble. For `hi-IN`, use a clear Indian service or commerce feel. Use warm accents, mobile-friendly rows, Hindi copy, Indian number grouping, PIN code fields, and practical helper text. Do not assume Western name structure. Keep technical IDs in ASCII when realistic. For `uk-UA`, use a reliable administrative feel. Use clear panels, strong contrast, practical Ukrainian labels, 24-hour time, UAH formatting, and direct validation messages. The page should feel robust and usable. For `th-TH`, use a friendly Thai service or commerce feel. Use rounded cards, clear callouts, spacious form rows, Thai date text, Thai address structure, and natural wrapping for Thai text. Do not rely on spaces for line breaks. --- AW00 Recommended File-Level CSS Strategy --- Every locale file should define its own CSS variables and visual rhythm. The class names may be the same for maintainability, but the values must differ. A good pattern is to keep structural class names stable while changing color, radius, density, shadow, spacing, and panel style per locale. Example for a US-style file: ```html ``` Example for a German-style file: ```html ``` Example for an Arabic RTL file: ```html ``` The coding agent should write one CSS block per locale. It may reuse utility class names, but the page should not visually look cloned. --- AX00 Localized Design Checklist Per File --- Before finalizing each locale file, check the following manually in the generated HTML. The visible title is localized. The introduction is localized. All 20 example headings are localized. All 20 example descriptions are localized. All 20 test intent paragraphs are localized. All labels are localized. All placeholders are localized. All validation messages are localized. All button labels are localized. All status badges are localized. All table headers are localized. All chart descriptions are localized. All live-region messages are localized. All tooltip text is localized. All empty states are localized. Names are locally plausible. Addresses use local order and field names. Phone numbers use local formatting. Dates use local formatting. Currency uses local formatting. Number separators are local. RTL works correctly for `ar-SA`. No English UI remains in non-English pages except technical strings that realistically stay ASCII. No locale page shares an identical visual design with another locale page. --- AY00 Suggested 20-Example Scenario Mapping By Locale --- The 20 conceptual examples remain identical, but scenario flavor may shift per locale. The coding agent should use this mapping as a guide. For `en-US`, use online order checkout, customer profile, hotel or clinic booking, support-ticket validation, destination combobox, appointment calendar, order receipt, sales-tax export, workspace permissions, job or support search, delivery option comparison, clinic intake, document review, communication preferences, sales-tax total calculation, admin dashboard, account settings tabs, report recipients, masked API key, and quality dashboard. For `es-MX`, use delivery checkout, customer contact, restaurant or service reservation, registration validation, branch or destination combobox, appointment calendar, payment receipt, IVA export, account permissions, invoice search, service package comparison, public service or insurance intake, document upload, notification preferences, IVA total calculation, service dashboard, settings tabs, recipient tokens, masked CLABE-like fictional value, and dashboard trends. For `de-DE`, use account checkout or service order, formal contact profile, administrative appointment, registration validation, branch combobox, appointment calendar, payment confirmation, USt. export, permissions matrix, invoice search, tariff comparison, administrative intake, document review, consent preferences, VAT calculation, operations dashboard, settings tabs, recipient tokens, masked IBAN-like fictional value, and metrics dashboard. For `fr-FR`, use service reservation checkout, client profile, appointment booking, onboarding validation, agency combobox, calendar picker, confirmation receipt, TVA export, permissions, document search, service comparison, public service intake, file upload, consent preferences, TVA calculation, admin dashboard, settings tabs, recipients, masked payment value, and quality dashboard. For `zh-CN`, use service order, contact profile, hotel or clinic booking, account validation, city or branch combobox, appointment calendar, service confirmation, 增值税 export, permissions matrix, work order search, package comparison, service intake, document review, notification preferences, tax total calculation, operations dashboard, settings tabs, recipient tags, masked phone or account, and compact analytics dashboard. For `ja-JP`, use delivery checkout, profile with furigana, clinic reservation, validation-heavy account setup, branch combobox, appointment calendar, delivery confirmation, 消費税 invoice export, permissions matrix, document or support search, service plan comparison, clinic or public intake, upload review, consent preferences, tax total calculation, dashboard, settings tabs, recipient chips, masked account or membership number, and dashboard text equivalents. For `ar-SA`, use delivery checkout or service application, Arabic contact profile, government or clinic appointment, validation-heavy service form, city or branch combobox, RTL calendar, service receipt, VAT export, permissions matrix, application search, service package comparison, public service intake, document upload, communication preferences, VAT calculation in SAR, admin dashboard, RTL settings tabs, recipient tokens, masked bank or API value, and data dashboard with Arabic summaries. For `hi-IN`, use ecommerce checkout, contact profile, service appointment, onboarding validation, city/branch combobox, appointment calendar, order receipt, GST export, permissions matrix, service search, plan comparison, public service or insurance intake, document upload, consent preferences, GST total calculation with Indian grouping, dashboard, settings tabs, recipients, masked UPI-like fictional value or account ending, and localized dashboard. For `uk-UA`, use administrative service checkout or application, contact profile, appointment booking, validation form, service center combobox, calendar, payment confirmation, ПДВ export, permissions, request search, service comparison, public service intake, document upload, preferences, VAT total calculation in UAH, admin dashboard, settings tabs, recipient tokens, masked account or IBAN-like fictional value, and reliability dashboard. For `th-TH`, use delivery checkout, contact profile, clinic or bank appointment, validation-heavy account setup, province or branch combobox, appointment calendar using Buddhist Era where appropriate, receipt, VAT invoice export, permissions, service search, package comparison, clinic or service intake, document upload, preferences, VAT total calculation in THB, dashboard, tabs and accordions, recipients, masked account or phone value, and dashboard text equivalents. --- AZ00 Example 01 Enhancement - Multi-Step Checkout --- The checkout example should not be a static form. It should behave like a real step-based UI. It should include a visible progress indicator with four localized steps. The current step must use `aria-current="step"`. The page should show the address or delivery step by default. It should not hide all non-current steps entirely. Completed steps may show small localized summaries. Add conditional business billing behavior. The field may be a radio group, segmented control, or checkbox depending on locale. For example, the US page might show: `Personal order`. `Business order`. If `Business order` is selected, reveal fields: `Company name`. `Tax ID or resale certificate`. `Billing contact`. For `es-MX`, use localized business billing fields such as: `Razón social`. `RFC de facturación`. `Uso de CFDI` as fictional demo if used. For `de-DE`, use: `Firmenname`. `USt-IdNr.`. `Rechnungs-E-Mail`. For `fr-FR`, use: `Raison sociale`. `Numéro de TVA intracommunautaire`. `Contact de facturation`. For `ar-SA`, use Arabic VAT-related business fields and keep IDs in LTR spans. Suggested structure: ```html

1 Cart
2 Delivery
3 Payment
4 Review

``` For non-English pages, localize all labels. For `ar-SA`, the visual order should read naturally in RTL. Do not use the same address data across locales. --- BA00 Example 02 Enhancement - Locale-Specific Profile --- The contact profile example is one of the most important i18n examples. It must not force every locale into first name and last name. Use locally appropriate name fields. For `zh-CN`, prefer a combined full name field: `姓名`. Optional additional fields may include: `拼音`. `显示名称`. Do not force separate first and last name fields. For `ja-JP`, include: `氏名`. `フリガナ`. `表示名`. For `hi-IN`, include: `पूरा नाम`. `राज्य`. `संपर्क की भाषा`. For `ar-SA`, include: `الاسم الكامل`. `اسم العرض`. `المدينة`. For `es-MX`, two surnames are realistic: `Nombre`. `Primer apellido`. `Segundo apellido`. For `uk-UA`, a patronymic may be realistic in some administrative contexts: `Ім'я`. `Прізвище`. `По батькові`. The character counter should count grapheme clusters when possible, not JavaScript UTF-16 code units. Use this pattern: ```html

``` The counter text must be localized, not just `0 / 40` in every page. For example: `en-US`: `12 of 40 characters`. `es-MX`: `12 de 40 caracteres`. `de-DE`: `12 von 40 Zeichen`. `fr-FR`: `12 caractères sur 40`. `zh-CN`: `已输入 12 / 40 个字符`. `ja-JP`: `40文字中12文字`. `ar-SA`: `12 من 40 حرفًا`. `hi-IN`: `40 में से 12 वर्ण`. `uk-UA`: `12 із 40 символів`. `th-TH`: `12 จาก 40 อักขระ`. --- BB00 Example 03 Enhancement - Dependent Booking Pickers --- The booking example must include real dependency behavior. Changing the service should update locations. Changing the location should update available dates or times. Changing the date or time should update the summary. Do not overbuild a scheduler. A small deterministic local data object is enough. Suggested JavaScript pattern: ```html ``` For each locale, localize the labels and time formats. For `de-DE`, use `10:30 Uhr`. For `fr-FR`, use `10:30`. For `ja-JP`, use `10:30`. For `ar-SA`, use Arabic labels and either localized AM/PM or 24-hour time consistently. The visible summary should update with localized phrasing. Do not update only a hidden value. --- BC00 Example 04 Enhancement - Error Summary Quality --- The validation-heavy form should be one of the strongest accessibility examples. Use a top error summary with at least four errors. Each error should link to an invalid field. Each invalid field should have inline error text. Each invalid field should use `aria-invalid="true"`. Each invalid field should use `aria-describedby`. Do not use vague errors like `Invalid value`. Use specific localized errors. Good examples: `en-US`: `Enter a ZIP code with 5 digits.` `es-MX`: `Ingresa un código postal de 5 dígitos.` `de-DE`: `Geben Sie eine fünfstellige Postleitzahl ein.` `fr-FR`: `Saisissez un code postal à 5 chiffres.` `zh-CN`: `请输入 6 位邮政编码。` `ja-JP`: `郵便番号は7桁で入力してください。` `ar-SA`: `أدخل الرمز البريدي بالصيغة الصحيحة.` `hi-IN`: `6 अंकों का पिन कोड दर्ज करें।` `uk-UA`: `Введіть поштовий індекс у правильному форматі.` `th-TH`: `กรุณากรอกรหัสไปรษณีย์ 5 หลัก`. Suggested structure: ```html

Mobile phone

Use a number where we can reach you.

Enter a valid phone number.

``` For non-English files, localize every visible string in this structure. --- BD00 Example 05 Enhancement - Custom Combobox --- The custom combobox must be realistic and must test both i18n and extraction. The combobox should include: A visible label. A current typed or selected value. A hidden submitted ID. A detached listbox. At least five localized options. A selected option. A secondary line per option. A local code or identifier per option. Use `aria-activedescendant` to identify the active option. Do not put the listbox inside the same immediate field wrapper. Place it after the form group or in a sibling container to imitate a portaled popup. Suggested structure: ```html

Destination

``` For `zh-CN`, do not rely on spaces in option labels. For `ja-JP`, include natural Japanese labels. For `ar-SA`, use RTL listbox alignment but wrap technical codes in `dir="ltr"`. --- BE00 Example 06 Enhancement - Calendar And Time Slot Picker --- The calendar example must not be a plain list of dates. It must show a grid or grid-like structure with selected and unavailable states. Every date cell should include: Visible date number. Full accessible date label. Availability text. Selected state if applicable. Disabled state if unavailable. The selected time panel should show at least three time slots and one disabled time slot. For `ar-SA`, the calendar must flow RTL. Use Arabic weekday names. Mixed numeric dates may remain Western or Arabic digits, but be consistent. For `th-TH`, at least one visible date should use Buddhist Era, such as `31 พฤษภาคม 2569`. Suggested grid cell: ```html ``` For non-English pages, localize `selected` and `appointments available` in the accessible label. Do not use English `available` or `selected` in non-English pages. --- BF00 Example 07 Enhancement - Confirmation Or Receipt --- The read-only confirmation example should be visually rich. It should not look like a form. Use a receipt or confirmation style with: Large confirmation number. Status badge. Created timestamp. Customer or applicant. Branch, address, or service location. Nested line items. Masked payment or phone value. Total. Note or cancellation policy. Action buttons. Use real local formatting. Examples: `en-US`: `Order ORD-2026-104922`, total `$159.07`. `es-MX`: `Recibo RCP-2026-7712`, total `$2,845.50 MXN`. `de-DE`: `Zahlungsbestätigung ZLG-2026-8841`, total `1.284,60 €`. `ja-JP`: `受付番号 RCP-2026-4418`, total `¥12,340`. `ar-SA`: `رقم التأكيد RCP-2026-8841`, total `١٬٢٣٤٫٥٦ ر.س` or consistent Arabic page formatting. The masked value must be visible and not fictionalized into a real-looking sensitive value. Use values such as: `Card ending in 4242`. `Cuenta terminada en 1842`. `Konto endet auf 1842`. `下4桁 1842`. `الحساب المنتهي بـ 1842`. --- BG00 Example 08 Enhancement - Billing Or Tax Export --- This example must test locale-specific fiscal terminology. It is a high-value i18n example. Include: Export name. Date range. Tax mode. File format. Encoding or delimiter where realistic. Recipients. Schedule. Selected export columns. Preview summary. At least six export fields. For `de-DE`, use terms such as `USt.`, `Rechnungsnummer`, `Zahlungsreferenz`, `Leistungszeitraum`. For `fr-FR`, use `TVA`, `numéro de facture`, `référence de paiement`, `période de service`. For `es-MX`, use `IVA`, `RFC de facturación`, `folio fiscal de demostración`, `referencia de pago`. For `hi-IN`, use `GST`, `चालान संख्या`, `भुगतान संदर्भ`, `कर योग्य राशि`. For `th-TH`, use `ภาษีมูลค่าเพิ่ม`, `เลขที่ใบแจ้งหนี้`, `อ้างอิงการชำระเงิน`. Do not use English column names like `Invoice number` in non-English pages. Suggested export field checklist: ```html

``` --- BH00 Example 09 Enhancement - Permissions Matrix --- The permissions matrix must be dense and extraction-rich. It should include: At least four role columns. At least four permission groups. At least ten permission rows. Checked state. Unchecked state. Disabled state. Selected permission detail panel. Use row group headers. Use table semantics where practical. Suggested semantic table pattern: ```html

``` All `aria-label` text must be localized. --- BI00 Example 10 Enhancement - Search Results With Filters --- The search example should include three extraction layers: Search state. Result list. Selected detail sidebar. Search state must include: Query. Sort order. Result count. Active filter chips. Filter groups. Result cards must include at least five records. Each record must include at least six values. The selected detail sidebar must include at least six additional values and should duplicate only a few primary fields. Do not make the same type of search in every locale. Localize the scenario naturally. For example: US: support tickets or jobs. Mexico: invoice records or service appointments. Germany: invoices or administrative requests. France: service requests or invoices. China: work orders or service providers. Japan: clinic or delivery records. Saudi Arabia: service applications or appointments. India: service requests or orders. Ukraine: administrative requests. Thailand: service appointments or document requests. The extraction caveat must be localized and must explain that filters, results, and selected detail must remain separate. --- BJ00 Example 11 Enhancement - Comparison Cards --- Comparison cards are high-risk for repeated labels. Each option column should reuse labels like: Price. Status. Includes. Limitations. Availability. Notes. The selected or recommended option must be visually clear and semantically clear. Use `aria-selected="true"` where appropriate. Add a shared criteria panel so extraction must distinguish shared criteria from option-specific data. Suggested layout: ```html

``` For `ar-SA`, the option order should feel natural in RTL. For long German and French labels, card widths must allow wrapping. For Chinese, Japanese, and Thai, cards must handle no-space wrapping. --- BK00 Example 12 Enhancement - Intake Form --- The intake form must feel serious and locally plausible. It must include at least three grouped sections. Use fieldsets where possible. Required groups: Applicant or patient. Contact. Service, claim, or request details. Address or location. Documents or evidence. Consent or declaration. At least one conditional section is required. Example conditional logic: If the user selects `incident happened at another address`, reveal another address group. If the user selects `representative is submitting`, reveal representative fields. If the user selects `business applicant`, reveal organization fields. The consent checkbox must have long localized text. This is intentional to test wrapping and extraction. Do not include real national ID numbers. If a demo ID field is necessary, label it clearly as fictional or use an internal reference number. --- BL00 Example 13 Enhancement - File Upload And Review --- The file upload flow should test file names, statuses, validation, and review notes. Include: Upload control. Accepted file types. Maximum file size. Document category selector. Progress summary. At least four document rows. A missing document. An approved document. A rejected document. A needs-correction document. A reviewer note per row. For non-English locales, use localized file names where realistic, but keep extensions ASCII. Example: `justificatif-domicile.pdf`. `rechnungsnachweis.pdf`. `住所確認書類.pdf`. `เอกสารยืนยันที่อยู่.pdf`. Use realistic file sizes with localized decimal separators where relevant. Do not create fake file upload behavior that tries to read local files. A normal file input plus static rows is enough. --- BM00 Example 14 Enhancement - Consent And Preferences --- The consent/preferences example should test localized legal text expansion. Include: Transactional messages. Security alerts. Marketing or promotional messages. Digest frequency. Preferred channel. Preferred language. Disabled channel with explanation. Preview panel. At least one long consent sentence. Do not use the same opt-in model language across all countries. The details can be fictional, but the tone should feel locally plausible. A strong example includes a disabled SMS channel with a local explanation: `SMS is unavailable until a mobile number is verified.` Localize the entire explanation. Tokenize states carefully: `enabled`. `disabled`. `required`. `not available`. All these status labels must be localized. --- BN00 Example 15 Enhancement - Currency And Total Calculation --- The price calculation form must not parse user-entered locale-formatted decimals. Use raw numeric data in attributes and display localized values. The visible form should still look local. Include: Quantity. Unit price. Discount. Tax rate. Tax amount. Service or shipping fee. Subtotal. Total. Inline validation. Dynamic updates. Use `Intl.NumberFormat`. Use correct currency per locale. For `ja-JP`, avoid decimals for yen totals. For `hi-IN`, verify Indian grouping appears in formatted totals, such as `₹1,23,456.78`. For `de-DE`, show decimal comma, such as `1.234,56 €`. For `fr-FR`, use French spacing and comma, such as `1 234,56 €`. Suggested markup: ```html

``` The JavaScript should initialize totals on page load. --- BO00 Example 16 Enhancement - Localized Dashboard --- The dashboard example must combine KPI cards, a toolbar, a table, and a selected row panel. Include: Four KPI cards. Toolbar with search, date range, and status filter. Table with at least six rows. Selected row detail. Localized numbers and dates. Localized status badges. Do not make the table identical in all locales. The scenario may vary, but the structure must remain comparable. For `de-DE`, dense structured tables are appropriate. For `zh-CN`, compact dense rows with status tags are appropriate. For `fr-FR`, a more spacious service dashboard is appropriate. For `th-TH`, use friendlier rounded cards. For `ar-SA`, make the table readable in RTL and wrap LTR IDs. A selected row should be visually and semantically selected: ```html ``` If using div grids, use `role="grid"`, `role="row"`, and `role="gridcell"`. --- BP00 Example 17 Enhancement - Tabs And Accordions --- The tabs and accordion example must combine two interaction patterns. It should have: Three tabs. The first tab active by default. At least two accordion sections inside each tab. One expanded section. One collapsed section with visible summary. Localized active state. Localized expanded state. Localized hidden content. Do not make hidden accordion content visible unless expanded. Use the `hidden` attribute. When a collapsed section has a summary, keep the summary outside the hidden panel so it remains visible. Suggested pattern: ```html

``` Extraction should capture the summary when collapsed and the detailed content after expansion. --- BQ00 Example 18 Enhancement - Tokenized Multi-Select --- The tokenized multi-select must include selected tokens, remove buttons, a search field, available options, and hidden values. Do not treat tokens as plain badges only. They must be part of a field. Each remove button must have a localized accessible label. Example English: `Remove billing@example.test from recipients`. Example Spanish: `Quitar billing@example.test de destinatarios`. Example German: `billing@example.test aus Empfängern entfernen`. Example Arabic: `إزالة billing@example.test من المستلمين`. For `ar-SA`, wrap email addresses with `dir="ltr"` inside the Arabic aria-label where necessary or isolate the visible email. The available options list should include one already selected option. The hidden input values should be realistic internal submitted values, but visible labels should be user-friendly. --- BR00 Example 19 Enhancement - Masked, Split, Or Ellipsized Values --- This example should bring the Page 10 hostile extraction work into Page 11 in a localized way. Include these patterns in one coherent local scenario: A masked visible value. A reveal button. A split reference number. An ellipsized long URL or address. A hidden backing value. A localized summary panel. Default extraction should see masked values only. After clicking reveal, the revealed demo value becomes visible. Suggested masked patterns: `en-US`: `Account ending in 1842`. `es-MX`: `Cuenta terminada en 1842`. `de-DE`: `Konto endet auf 1842`. `fr-FR`: `Compte se terminant par 1842`. `zh-CN`: `尾号 1842`. `ja-JP`: `下4桁 1842`. `ar-SA`: `الحساب المنتهي بـ 1842`. `hi-IN`: `1842 पर समाप्त खाता`. `uk-UA`: `Рахунок із закінченням 1842`. `th-TH`: `บัญชีลงท้าย 1842`. Do not invent full sensitive values before reveal. The reveal panel must clearly state that revealed values are fictional demo values. --- BS00 Example 20 Enhancement - Data Visualization Text Equivalents --- The dashboard visualization example must not rely on canvas, SVG-only data, or CSS bar widths as the only data source. Each chart card must include: Localized chart title. CSS-only placeholder visualization. Visible text equivalent. `aria-describedby` relationship to the text equivalent. Small data table or field rows. Trend sentence. Status badge. At least three chart cards. Include at least one plural-sensitive localized phrase. For example, in English: `2 warnings remain`. In French: `2 avertissements restants`. In Ukrainian, use a form that is natural and correct for the count selected. The coding agent should not over-optimize plural grammar perfectly for every dynamic count, but visible text should be natural in the page. Suggested chart card: ```html

``` Do not hide the actual chart data in CSS only. --- BT00 Mixed Direction Guidance For ar-SA --- The Arabic page needs extra care. Use `dir="rtl"` on the root HTML. Use `direction: rtl` and `text-align: start`. Use logical CSS properties. For LTR technical values, use a class such as: ```html INV-2026-00841 ``` Use it for: Invoice IDs. Order IDs. Ticket IDs. Email addresses. URLs. API keys. File names. SKU codes. Phone numbers if the chosen formatting displays better LTR. CSS: ```html ``` Do not use left/right icons without considering RTL. If an arrow means "next", use a direction-neutral word label or flip the icon with CSS in the Arabic page. The Arabic page should not simply align English-style fields to the right. The layout should be designed as RTL from the start. --- BU00 CJK And Thai Text Wrapping Guidance --- For `zh-CN`, `ja-JP`, and `th-TH`, do not assume spaces separate words. Avoid fixed-width labels that clip text. Use CSS that allows natural wrapping: ```html ``` For Japanese, labels may be compact but helper text may be longer. Avoid clipping. For Chinese, dense cards are acceptable, but do not reduce line height too far. For Thai, use slightly more line height because Thai script benefits from vertical space. Suggested line-height: `zh-CN`: around `1.55`. `ja-JP`: around `1.6`. `th-TH`: around `1.65`. --- BV00 Hindi And Combining Character Guidance --- For `hi-IN`, character counting should not break Devanagari combining marks. Use `Intl.Segmenter` when available. Do not validate Hindi display names using simple ASCII-only patterns. Do not use placeholder text that implies only English letters. Avoid fixed-height input wrappers that clip matras or conjuncts. Use a line height around `1.6`. Use Indian currency grouping through `Intl.NumberFormat("hi-IN", { style: "currency", currency: "INR" })`. The coding agent should include at least one value like: `₹1,23,456.78` This is a high-value test case for grouping. --- BW00 Ukrainian Grammar And Apostrophe Guidance --- For `uk-UA`, use Ukrainian UI text naturally. Do not leave Russian forms. Use Ukrainian apostrophes correctly where needed, such as `обов'язкове поле`. Use 24-hour time. Use UAH formatting with `грн`. Use address labels such as: `Вулиця`. `Будинок`. `Квартира`. `Місто`. `Область`. `Поштовий індекс`. Use direct but polite validation messages. Avoid overlong translated English sentences. Ukrainian UI can be clear and concise. --- BX00 Localized Test Intent Requirements --- Every example must include a localized test intent paragraph. This paragraph is visible in the page. It should not be generic. It should explain the exact internationalization behaviors tested in that example. Weak: `This tests internationalization.` Strong: `This example tests Mexican address fields, Spanish validation messages, MXN currency formatting, conditional billing fields, and long helper text wrapping.` For non-English pages, the test intent itself must be localized. The coding agent should write these paragraphs in natural language for each locale. The test intent is important because it lets a tester understand why the example exists without opening the source code. --- BY00 Comment Guidance For Maintainability --- The HTML may include short internal comments in English for maintainability, but visible UI text must be localized. Good comments: ```html ``` Bad visible content: ```html

Test intent: This example tests custom combobox behavior.

``` inside a non-English page. If comments are included, keep them brief. Do not flood the HTML with comments. --- BZ00 Final Quality Review Procedure --- After generating each file, the coding agent should review it as follows. Open the page mentally from top to bottom. Confirm there are exactly 20 examples. Confirm IDs are `example-01` through `example-20`. Confirm all visible example headings are localized. Confirm every example has a localized description. Confirm every example has a localized test intent. Confirm at least eight examples include JavaScript interaction. Confirm at least five examples include repeated records, tables, cards, or rows. Confirm at least five examples include validation, warnings, helper text, or error states. Confirm at least four examples include hidden, conditional, collapsed, or revealed content. Confirm at least three examples include custom accessible widget semantics. Confirm at least two examples include masked, split, truncated, or ellipsized values. Confirm Example 20 has chart text equivalents and visible data values. Confirm all dynamic messages are localized. Confirm all visible buttons are localized. Confirm all status badges are localized. Confirm the locale's currency appears correctly. Confirm the locale's date and time formatting appears correctly. Confirm the locale's address structure appears correctly. Confirm the locale's phone number format appears correctly. Confirm no English UI text remains in non-English files except technical values. Confirm no external files are referenced. Confirm the page works offline by opening the HTML file directly. Confirm `ar-SA` uses `dir="rtl"` and LTR wrappers for technical values. Confirm CJK and Thai pages do not clip no-space text. Confirm Hindi page handles Devanagari line height and character counting. Confirm German page handles text expansion without broken buttons or clipped labels. Confirm French page uses natural French phrasing rather than literal English structure. Confirm Ukrainian page uses Ukrainian, not Russian or English leftovers. Confirm the pages look visually distinct from each other. --- CA00 Final Implementation Principle --- The coding agent should optimize for test value over brevity. A shorter page that technically contains 20 examples but lacks realistic data is not acceptable. A page with 20 rich localized examples, clear grouping, realistic sample values, visible test intent, accessible controls, and robust formatting is the target. The final output should feel like a serious internationalization QA suite for a production-grade extraction and form-understanding tool.