Add or review RTL compatibility for Orderly Web pages and components. Use this skill whenever the user asks to make a page/component support RTL, Arabic/Farsi/Hebrew, direction switching, mirrored layout, RTL bugs, or compatibility with the feature/rtl implementation in this repository.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Add or review RTL compatibility for Orderly Web pages and components. Use this skill whenever the user asks to make a page/component support RTL, Arabic/Farsi/Hebrew, direction switching, mirrored layout, RTL bugs, or compatibility with the feature/rtl implementation in this repository.
Page RTL Compatibility
Use this skill to add RTL compatibility for pages, components, tables, charts, modals, trading modules, etc. in Orderly Web. The goal is not simply to flip the page, but to ensure that visual direction, interaction direction, number display, charts, scrolling, and third-party components all work correctly on top of the existing html[dir] and useDocumentDirection() foundation.
Scope
This skill is responsible only for RTL compatibility at the page and component level, not for implementing or modifying global direction infrastructure.
Do not add or rewrite the direction sync logic of syncDocumentDirection, isRTLDirectionLanguage, or LanguageProvider.
Do not add RTL language entries, locale files, or date-fns locale mappings unless the user explicitly requests language integration.
Assume the project already has html[dir] and useDocumentDirection() from @orderly.network/ui; pages should consume them directly when direction judgment is needed.
Workflow
First, identify the target scope: page entry, desktop/mobile variants, dependent shared components, table column configurations, dropdown/sheet/dialog, charts, or canvas/poster.
When logical direction can be used, prioritize replacing with logical direction; only fix to LTR for explicit financial/chart/numeric scenarios.
For components that need to change behavior based on direction, use useDocumentDirection() to get the direction; do not read global state yourself.
After modification, perform at least static checks: grep for remaining physical direction classes, check for accidental changes to numeric directions, run lint/build for the related package or the target storybook page (when feasible).
Tailwind and Style Replacement Rules
Prioritize using Orderly's oui- prefixed logical direction classes:
Physical Direction
RTL-Compatible Replacement
oui-ml-* / oui-mr-*
oui-ms-* / oui-me-*
oui-pl-* / oui-pr-*
oui-ps-* / oui-pe-*
oui-left-* / oui-right-*
oui-start-* / oui-end-*
oui-text-left / oui-text-right
oui-text-start / oui-text-end
oui-border-l / oui-border-r
oui-border-s / oui-border-e
oui-rounded-l-* / oui-rounded-r-*
oui-rounded-s-* / oui-rounded-e-* or corner-level ss/se/es/ee
oui-space-x-*
oui-gap-x-* or oui-gap-*
pseudo before:left/right / after:left/right
before:oui-start/end / after:oui-start/end
Notes:
space-x often causes spacing or border-radius overlap issues in RTL due to one-sided margins; prefer changing to gap-x.
For complex border-radius, avoid hardcoding rounded-tl/tr/bl/br; use rounded-ss/se/es/ee. For example, the border-radius of two side-by-side cells in an order entry should be encapsulated with logical start/end corner helpers.
If third-party/host styles override border-radius under [dir="rtl"] :first-child, you can use !oui-rounded or !oui-rounded-md to fix the component's own border-radius semantics.
CSS variables, gradient angles, and financial colors generally do not need mirroring; only directional gradient shadows need to be rotated or swapped for RTL.
Numbers, Prices, and Trading Symbols Stay LTR
Financial numbers, prices, quantities, percentages, order book cumulative values, addresses, IDs, and trading pair symbols must not be broken by Arabic/Hebrew text direction. Common approaches:
Tables are a high-risk area for RTL compatibility. Reference the implementation approach in packages/ui/src/table:
useScroll needs to detect getComputedStyle(element).direction and return isRTL.
Do not use scrollLeft > 0 or scrollLeft + clientWidth >= scrollWidth directly to judge left/right shadows; browsers have default, negative, and reversescrollLeft models in RTL.
Normalize to fromStart / fromEnd before determining leading/tailing shadows.
Fixed columns prefer semantic values: fixed: "start" | "end", then resolve to TanStack's left / right based on isRTL.
Pinning styles use insetInlineStart / insetInlineEnd, not left / right.
Pinned column shadows use start/end and rotate gradients based on isRTL.
If adding new table column configurations, prefer writing:
{
fixed: "start";
}
{
fixed: "end";
}
Only keep "left" / "right" when strongly bound to business semantics.
ScrollIndicator, Tabs, and Horizontally Scrollable Areas
Horizontally scrollable tab bars, market lists, and filter chips need leading/tailing semantics:
API naming uses leading / tailing, not left / right to indicate logical scroll direction.
Scroll button positions can map to physical left/right based on isRTL, but click behavior should be based on offsetFromStart.
Before scrollTo({ left }), convert logical offset to actual scrollLeft through the RTL scroll model.
Containers use oui-min-w-0 oui-flex-1 to avoid overflow in RTL/flex contexts.
Tabs root node should receive dir; explicit dir takes precedence, otherwise use useDocumentDirection().
Charts, TradingView, Canvas/Poster
Charts typically need to stay LTR locally, but outer containers can follow page direction:
Recharts / SVG axes: set direction: ltr, unicode-bidi: plaintext for chart or tick labels.
Chart containers can use style={{ direction: "ltr" }} to prevent coordinate axes and number order from being affected by RTL.
TradingView: pass the direction obtained from useDocumentDirection() into widget options, and add dir={direction} to the UI root node.
In TradingView locale mapping, Arabic can be passed as "ar" directly; other unsupported locales should use existing fallbacks.
Canvas/poster: pass direction?: "ltr" | "rtl" in DrawOptions. If the background image needs mirroring, wrap drawing with ctx.save(), translate(width, 0), scale(-1, 1), restore(); handle text/numbers and alignment separately by coordinates.
Page and Component Checklist
When adapting pages, check by area; don't just change the first layer of JSX in the current file:
Top navigation, sidebars, bottom navigation: absolute icons, external link icons, badges, arrows use start/end.
Portfolio / assets / orders / positions: stat cards, table columns, mobile list items, detail label/value alignment use text-start/end.
Trading / order entry / order book: prices and quantities stay LTR, depth bar and pending dot use logical positions, qty/total input border-radius handled by logical corners.
Transfer / wallet / chain/token select: dropdown align, token icon + name order, suffix absolute position switch based on direction.
Dialog / Sheet / Select / Calendar / Pagination / Slider / Switch: first check if packages/ui base components are already compatible, avoid duplicating workarounds on every business page.
