/* ========================================================================== Vertex - Arabic / RTL corrections for the admin panel. Loaded UNCONDITIONALLY and LAST IN . Every rule below is scoped under [dir="rtl"], so with dir="ltr" this file contributes nothing and the English panel renders exactly as it did before. Bootstrap's own mirroring is deliberately NOT duplicated here. Bootstrap 5.3.5 supplies 679 of the 930 physical directional declarations the admin panel loads, and it publishes an official RTLCSS-processed build for precisely this. The layout blades swap bootstrap.min.css for bootstrap.rtl.min.css when the document is RTL. This file covers only what that swap does not reach. ========================================================================== */ /* -------------------------------------------------------------------------- 1. Typeface The panel loads one webfont: Public Sans. Google Fonts ships it in the latin / latin-ext / vietnamese subsets only - it contains NO Arabic glyphs. style.css:98 binds it as --bs-font-sans-serif, so every Arabic character falls through to the bare `sans-serif` keyword: whatever the operator's OS happens to pick. Latin chrome renders in Public Sans and Arabic renders in Arial or Segoe UI, two typefaces on the same line. On a machine whose sans-serif has no Arabic it degrades to tofu. Overriding the VARIABLE rather than `font-family` is deliberate: the icon faces (Material Icons, Material Symbols Outlined, uicons) declare font-family explicitly and must not be touched. Bootstrap's reboot already sets `font-family: inherit` on button/input/select/textarea, so form controls follow the variable too. :root[dir="rtl"] has specificity (0,1,1) and beats the plain :root (0,0,1) block in style.css regardless of load order. -------------------------------------------------------------------------- */ :root[dir="rtl"] { --bs-font-sans-serif: "Noto Sans Arabic", "Noto Naskh Arabic", "Segoe UI", Tahoma, "Geeza Pro", "Arabic Typesetting", Arial, sans-serif; /* Arabic has no capitals and sits on a smaller optical size than Latin, so the panel's 0.875rem (style.css:100) reads roughly a pixel small in Arabic. One step up, nothing else. If anything overflows, deleting this single declaration reverts it. */ --bs-body-font-size: 0.9375rem; } /* -------------------------------------------------------------------------- 2. toastr - every success / error / warning notification in the panel toastr.css DOES ship an RTL variant, but only behind a `.rtl` class that toastr.js adds when options.rtl is true. Nothing in this codebase sets that option, and the toastr calls are scattered across dozens of blades with inline option objects. Re-bind the same three declarations from `#toast-container > div.rtl` (toastr.css:124-128) to the document direction instead: no JS change, no call-site edits. -------------------------------------------------------------------------- */ [dir="rtl"] #toast-container > div { direction: rtl; padding: 15px 50px 15px 15px; background-position: right 15px center; } /* toastr.css:22-26 pins the close button to the right and floats it right. */ [dir="rtl"] .toast-close-button { right: auto; left: -0.3em; float: left; } /* toastr.css:181-184 anchors the progress bar to the left. */ [dir="rtl"] .toast-progress { left: auto; right: 0; } /* -------------------------------------------------------------------------- 3. Bidirectional data - numbers, dates, currency, phone numbers There is no element and no unicode-bidi declaration anywhere in the admin surface. Inside an RTL paragraph the Unicode bidi algorithm reorders any mixed run: the leading + of "+963 11 000 0000" jumps to the far end, the separators in "2026/08/31" transpose, a trailing currency symbol lands on the wrong side of its amount. The declaration is `plaintext`, NOT `isolate`. Isolate stops a cell from disturbing its NEIGHBOURS but leaves the ordering WITHIN the cell alone, so the leading + would still jump and the date separators would still transpose. Plaintext resolves each cell by the first-strong rule: a cell beginning with a digit or a + renders left-to-right, one beginning with an Arabic letter renders right-to-left. The cell itself stays right-aligned with the rest of the RTL table, so columns of amounts, dates and references line up again AND read correctly. -------------------------------------------------------------------------- */ [dir="rtl"] table td, [dir="rtl"] table th { unicode-bidi: plaintext; } /* Inherently left-to-right data. The standard Arabic-UI convention: the field stays flush with its RTL label (text-align: right) while its contents read left to right, so a phone number or an email address is never scrambled while it is being typed. Deliberately NOT applied to type="number": bare digits are already bidi-safe and flipping them would misalign the currency inputs against their labels. */ [dir="rtl"] input[type="tel"], [dir="rtl"] input[type="email"], [dir="rtl"] input[type="url"] { direction: ltr; text-align: right; }