Menu (Dropdown Menu and Context Menu)

A submenu follows the reading direction: it opens to the right of its parent row in English and to the left in Arabic, which is the logical end of that row. Compute the side when the menu opens instead of writing it once in CSS, because it has to flip to the opposite side as soon as the remaining viewport width runs out. Floating UI is logical in its alignment only: the -start and -end suffixes read direction off the element, while the main side in placement is spelled physically (top, right, bottom, left), so either you pick "left-start" yourself under rtl, or you hand the job to a component that reads direction, such as Radix, where dir="rtl" belongs on DropdownMenu.Root or on a DirectionProvider around the tree and never on DropdownMenu.Sub, which takes no dir prop.

The arrow at the end of the row points at the side the submenu will open on, so it is purely directional and has to flip with the page. If you draw it as a text character, do not assume the bidi engine will handle it: Bidi_Mirrored is Yes for › (U+203A), which mirrors on its own, and No for → (U+2192) and ▸ (U+25B8), which stay exactly as drawn whatever the direction is. Put the flip in a dedicated class such as .flip-x { transform: scaleX(-1) } under [dir="rtl"] and apply it to this arrow alone, because a blanket rule on svg mirrors the checkmark and the copy and delete glyphs along with it.

Every row is three slots: the state mark at the logical start, the label in the middle, and the shortcut hint at the logical end, so the two outer slots trade places with page direction. Reserve the mark slot on every row with padding-inline-start or an empty element of the same width, and push the shortcut out with margin-inline-start: auto. The ready-made trap here is the DropdownMenuShortcut component in shadcn/ui: its class is ml-auto, which works in English and leaves the shortcut glued to the wrong side in Arabic until you swap it for ms-auto.

The slot moves with the page, but the order inside the run never changes: Ctrl+K reads the same in both directions. The risk sits in the symbols that lead it, because ⌘ (U+2318) and ⇧ (U+21E7) carry bidi class ON, meaning neutral, and a neutral standing at the edge of a run takes the direction of the paragraph around it, hops to the other side of the letter, and the eye reads K⌘ instead of ⌘K. Isolate the run as one block with dir="ltr" plus unicode-bidi: isolate, or wrap it in <bdi>, rather than patching it with an extra space or a control character typed into the string by hand.

The two keys trade jobs with direction: in Arabic ArrowLeft opens the submenu and ArrowRight closes it, and in English it is the other way round. Read the direction once from getComputedStyle(el).direction and derive openKey and closeKey from it, instead of scattering an rtl check through every branch of the key handler. Nothing else moves: ArrowDown, ArrowUp, Home, and End work on DOM order, Escape closes and restores focus, and first-letter type-ahead has no relationship to direction at all.