Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Adapt [screen] for [supported left-to-right and right-to-left locales] using the current internationalization setup. Include realistic fixture text with a person’s name, a Latin product code, punctuation, numbers, a URL, and a long translated label. Identify the document or container direction and isolate runtime phrases when their direction is unknown.
Inspect logical spacing, alignment, icon meaning, text wrapping, input behavior, and reading order. Mirror directional controls only when their meaning calls for it; do not reverse strings or every icon mechanically. Format dates and numbers through the supported locale facilities while keeping stored identifiers stable.
Verify both directions at narrow width and zoom, including mixed-script content inside the same sentence and a validation error. Record remaining translation or assistive-technology review needs. Deliver fixtures and observed behavior, not a claim that changing one CSS direction property completes localization.Make this prompt yours
Supply real target-language examples or ask a fluent reviewer to validate the fixtures; pseudolocalization alone cannot establish translation quality.
You might also hear
- i18n
- RTL
- bidi
- Arabic
- Hebrew
- localization
- mixed direction
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Supported: Original localization review. W3C supports inline direction isolation and MDN supports locale date formatting; number formatting and icon decisions require the chosen locale facilities and real-language review. No one-property localization claim is made.