/* ========================================================================== Vertex - Arabic / RTL corrections for the PROVIDER (wash-bay) 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. This is the provider twin of admin-module/css/rtl.css. It is deliberately SHORTER, and the reason is worth recording so nobody "completes" it later: provider-module/css/style.css is the RTL-aware build of this theme. Its layout chrome is already written in logical properties - .aside uses inset-inline-start, .main-area uses padding-inline-start, .count-btn .count uses inset-inline-end - and it already carries 21 [dir=rtl] blocks of its own, including the one that flips the collapsed mobile sidebar (style.css:3477-3481, transform: translateX(100%)). The sidebar, the header badges and the custom dropdowns therefore mirror correctly on their own. Do not re-mirror them here: a second flip would put them back on the wrong side. Bootstrap's own mirroring is likewise NOT duplicated here. Counting physical left/right/float/clear/text-align/direction declarations across every stylesheet each layout loads gives 1036 for master and 1045 for new-master, and 766 of them - three quarters - come from bootstrap.min.css alone. Bootstrap 5.2.0 publishes an RTLCSS-processed twin of that one file, so one swap fixes three quarters of the problem with no markup changes at all. It works because the blades already speak Bootstrap's logical vocabulary: across the 63 blades reachable from the two layouts (45 direct @extends plus what they @include) there are 107 form-floating, 70 justify-content-end, 44 form-check, 41 text-start, 22 input-group, 11 offcanvas-end and 6 dropdown-menu-end. Both provider layouts do the swap behind file_exists(). ONE UTILITY DOES NOT SURVIVE THE SWAP, and it is worth knowing before it costs somebody a day. Bootstrap ships `.text-break` with rtl: false, so the RTL build simply does not contain it - verified: the two builds carry the same 2295 distinct selectors except for `.text-break` (LTR only) and `[type=email],[type=number],[type=tel],[type=url]{direction:ltr}` (RTL only). No blade under either provider layout uses .text-break today. If one is added, it will wrap in English and overflow its cell in Arabic, silently. Use `.text-wrap` with `overflow-wrap: anywhere`, not `.text-break`. What is left - and all this file contains - is the handful of provider components whose CSS is still written in physical left/right, plus the two things no stylesheet swap can supply: an Arabic typeface and correct bidirectional ordering inside table cells. ========================================================================== */ /* -------------------------------------------------------------------------- 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:72 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. Both provider layouts now load Noto Sans Arabic alongside Public Sans - naming a face here without downloading it there is what left the admin panel on Segoe UI for months. Overriding the VARIABLE rather than `font-family` is deliberate: the icon faces (Material Icons, Material Symbols Outlined, uicons regular/solid rounded) 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. IF YOU ARE VERIFYING THIS IN DEVTOOLS, do not inspect . style.css:126 sets `html { font-family: sans-serif }` outright, so the root element's own computed font-family stays "sans-serif" and always will - that rule is not ours to touch and does not matter, because no text is a direct child of it. Inspect a real text node instead (a sidebar link, a table cell): Bootstrap's `body { font-family: var(--bs-body-font-family) }` resolves through --bs-font-sans-serif, and that is what this block redefines. The check is that the computed value BEGINS with "Noto Sans Arabic". -------------------------------------------------------------------------- */ :root[dir="rtl"] { --bs-font-sans-serif: "Noto Sans Arabic", "Noto Naskh Arabic", "Segoe UI", Tahoma, "Geeza Pro", "Arabic Typesetting", Arial, sans-serif; /* Line-height, not size. The font SIZE is deliberately left alone: the admin panel raised it once, found the apparent smallness was an artefact of Arabic arriving from a fallback face at the wrong optical size, and put it back. The real face is loaded here from day one, so there is nothing to compensate for. Line-height is the part that genuinely needs more room. Arabic carries marks above and below the baseline that Latin does not, and at the theme's 1.4 (style.css:74) the diacritics of one line press into the descenders of the one above. 1.65 is what stops that. */ --bs-body-line-height: 1.65; /* Arabic is a joined script: letter-spacing does not track it, it BREAKS it, severing the connections between letters in a word. Any inherited tracking has to be cancelled. */ letter-spacing: 0; } /* -------------------------------------------------------------------------- 2. toastr - every success / error / warning notification in the panel Both layouts load provider-module/css/toastr.css and js/toastr.js, and fire toastr.success / .error / .warning from inline handlers scattered across dozens of blades. 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 every call site passes its own inline option object. Re-bind the same 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 - amounts, dates, booking references, phone numbers There is no element and no unicode-bidi declaration anywhere in the provider 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. This is the booking list and the earnings tables - the two screens the bay owner reads every morning. 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 booking 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, an IBAN or an email address is never scrambled while it is being typed. `direction: ltr` LOOKS redundant - Bootstrap's RTL build ships its own `[type=email],[type=number],[type=tel],[type=url]{direction:ltr}` reboot rule, which the LTR build does not have. It is not redundant: the layouts serve the RTL build behind file_exists(), so on a deployment where bootstrap.rtl.min.css is missing the page is still dir="rtl" with the LTR build and no such rule, and this file is what keeps phone numbers readable. What is genuinely new here is `text-align: right`, which Bootstrap does not set. text-align is deliberately NOT extended to type="number": bare digits are already bidi-safe, and right-aligning them would pull the payout and price inputs away from their labels. Bootstrap's rule still gives number fields direction: ltr, which is all they need. */ [dir="rtl"] input[type="tel"], [dir="rtl"] input[type="email"], [dir="rtl"] input[type="url"] { direction: ltr; text-align: right; } /* -------------------------------------------------------------------------- 4. The provider components still written in physical left/right Everything below is a rule in style.css that the Bootstrap swap cannot reach because it is the theme's own CSS, and that the theme's own [dir=rtl] block missed. Each one is reachable from a screen the bay actually uses - dead rules were left out on purpose so this file stays auditable. -------------------------------------------------------------------------- */ /* Icon-in-field inputs: 27 uses across 6 blades - bank-info, profile-update, the three advertisement forms and service/make-request. style.css:5494-5513 parks the leading icon at left:10px and reserves padding-left:44px for it, so in Arabic the icon sits on top of the text instead of in front of it, and the 44px of reserved space opens on the empty side. The password eye (.togglePassword, style.css:5505-5509) is the mirror case - it is pinned to the trailing edge and has to move the other way. */ [dir="rtl"] .form-floating__icon .material-icons, [dir="rtl"] .form-floating__icon .material-symbols-outlined { left: auto; right: 10px; } [dir="rtl"] .form-floating__icon .material-icons.togglePassword, [dir="rtl"] .form-floating__icon .material-symbols-outlined.togglePassword { right: auto; left: 10px; } [dir="rtl"] .form-floating__icon .form-control { padding-left: 0.75rem; /* back to Bootstrap's own .form-floating padding */ padding-right: 44px; } /* The booking status timeline (#service_schedule__span hover panel) on the four provider booking screens that render it - booking/details, booking/status, booking/rebooking-ongoing, booking/repeat-status. style.css:5254 anchors the popover at left:0 and :5284-5313 draws the spine as a border-left with the dots hung off it at left:-6px. Unflipped, the popover opens away from its trigger and the spine ends up on the far side of the text it belongs to, with the dots floating in the gap. */ [dir="rtl"] .timeline-container { left: auto; right: 0; } [dir="rtl"] .timeline-container li { border-left: 0; border-right: 2px solid #f0ecec; padding-left: 0; padding-right: 12px; } [dir="rtl"] .timeline-container li.active { border-left: 0; border-right: 2px solid var(--bs-primary); } /* style.css:5295-5298 strips the spine off the final step so it does not dangle past the last dot. The two rules above tie with it on specificity and load later, so without this the last step would sprout a border only in Arabic. It must stay AFTER the .active rule, exactly as in style.css. */ [dir="rtl"] .timeline-container li:last-child { border: 0; } [dir="rtl"] .timeline-container li::before { left: auto; right: -6px; } [dir="rtl"] .timeline-container li:last-child::before { left: auto; right: -4px; } /* The service-details hover card on the subscribed-services and service-request screens. style.css:5576-5586 anchors it to right:0 of its wrapper, i.e. the trailing edge in English; in Arabic the trailing edge is the left one, so unflipped the card hangs off the wrong corner and, on a narrow column, off the edge of the viewport. */ [dir="rtl"] .service-details-info { right: auto; left: 0; } /* The close button on the subscription / renewal modals - the screens a bay with a lapsed plan is locked into, so this one is not cosmetic. The blade pins it with the physical utility .right-8 (style.css:5610-5612). In English the physical right is the empty trailing corner; in Arabic it is where the heading starts, so the X lands on top of the modal title. Scoped to .btn-close so a genuinely physical use of .right-8 keeps its meaning. */ [dir="rtl"] .btn-close.right-8 { right: auto; left: 8px; } /* -------------------------------------------------------------------------- 5. Utilities whose NAME is logical but whose implementation is physical These are the trap in this theme. A blade author reads `.ps-20` as "padding-start 20" and `.border-lg-start` as "border on the start edge", uses them on an Arabic-first screen, and gets the English edge anyway. Neither class is Bootstrap's - both are the theme's own, written with padding-left / border-left - so swapping the Bootstrap build cannot reach them and nothing else will. Not cosmetic: .border-lg-start is the divider between the two halves of the provider DASHBOARD (dashboard.blade.php:216 and :259), the first screen of the shift, and .ps-20 indents the chart heading on all four REPORT screens (report/booking, report/business/earning, /expense, /overview) - the pages the bay owner opens to see what he was paid. -------------------------------------------------------------------------- */ /* style.css:4429-4431 */ [dir="rtl"] .ps-20 { padding-left: 0; padding-right: 1.25rem; } /* style.css:5571-5576. The original carries !important, so the override has to as well - otherwise the left border survives and the column gets a rule down BOTH sides, which reads as a stray divider rather than a missing one. */ @media screen and (min-width: 992px) { [dir="rtl"] .border-lg-start { border-left: 0 !important; border-right: var(--bs-border-width) var(--bs-border-style) var(--bs-border-color) !important; } } /* -------------------------------------------------------------------------- 6. The fixed demo-reset warning rendered by both layouts above this file master.blade.php and new-master.blade.php each render #demo-reset-warning as .alert--message-2 when APP_ENV=demo. style.css:6671-6688 (repeated verbatim at :6898) pins it with `position: fixed; right: 20px` and draws its accent as `border-left`. In Arabic the sidebar is on the right, so unflipped this notice docks ON TOP of the sidebar instead of away from it, and its accent bar ends up on the far side of its own icon. The sibling .alert--container two rules further down already carries exactly this [dir=rtl] block (style.css:6726-6729); .alert--message-2 was missed. Left/right are deliberately NOT !important here, so that an .alert--message-2 nested inside .alert--container still yields to that container's `left/right: unset !important` (style.css:6738-6741) and stays in flow. */ [dir="rtl"] .alert--message-2 { right: auto; left: 20px; border-left: 0; border-right: 3px solid var(--bs-primary); } /* -------------------------------------------------------------------------- 7. Checkbox and radio labels style.css:5071-5080 hangs `margin-left: 5px` on .form-check-label on top of Bootstrap's own .form-check padding. Bootstrap's padding is mirrored by the RTL build; this extra 5px is not. Unflipped, the gap opens on the far side of the label and the Arabic text sits flush against its own checkbox. 15 .form-check-label across 8 blades, including booking/details and booking/service-log - the screens where the bay ticks off what it washed. -------------------------------------------------------------------------- */ [dir="rtl"] .form-check .form-check-label { margin-left: 0; margin-right: 5px; } /* -------------------------------------------------------------------------- 8. The delete-X badge on an uploaded image Advertisement create / edit / re-submit (.remove-file-button, 29 uses across those 3 blades, style.css:5830-5840) and the chat attachment tray (.img-clear, style.css:5377-5391, injected by the jQuery in ChattingModule provider partials/_conversations.blade.php:219, which is why grepping the blades for the class finds nothing) both hang a remove button off the TRAILING corner of a thumbnail, written as `right:`. In Arabic the trailing corner is the left one. Unflipped, the X covers the leading corner of the image, and .img-clear at right:-6px overhangs into the thumbnail beside it - so the operator deleting one advertisement image aims at the neighbouring one. -------------------------------------------------------------------------- */ [dir="rtl"] .remove-file-button { right: auto; left: 15px; } [dir="rtl"] .input_msg_write .upload_img_box .img-clear { right: auto; left: -6px; } /* -------------------------------------------------------------------------- Review tooltip arrow. Found by the reviewer of the RTL package, not by the team that wrote this file - it is a theme class, so the Bootstrap RTL build cannot reach it, and it is not among style.css's own 21 [dir=rtl] blocks. style.css:7441-7446 pins the arrow with `left: unset; right: 0` and pulls it back 35px. In Arabic the balloon hangs off the other side, so the arrow sits detached from it - on the provider booking list, which a bay opens every day, and on the reviews and service-detail screens. The popper placement variants are mirrored too: popper resolves left/right from the writing direction, so [data-popper-placement=right] is the LEFT side of an Arabic screen and its `right: 100%` anchor points away from the balloon. -------------------------------------------------------------------------- */ [dir="rtl"] .review-tooltip .tooltip-arrow { right: auto !important; left: 0; transform: translateX(35px) !important; } [dir="rtl"] .review-tooltip[data-popper-placement="right"] .tooltip-arrow { right: auto; left: 100%; transform: translate(-13px) !important; } [dir="rtl"] .review-tooltip[data-popper-placement="left"] .tooltip-arrow { transform: translateX(1px) !important; } /* -------------------------------------------------------------------------- Profile-preview action buttons (style.css:5905-5924). Both are absolutely positioned at `right: 15px` over the top corner of a preview image. In Arabic the leading corner is the right one, so the button covers the part of the picture the eye lands on first instead of sitting out of the way. -------------------------------------------------------------------------- */ [dir="rtl"] .profile-preview-box .wishlist-btn, [dir="rtl"] .profile-preview-box .wishlist-btn-2 { right: auto; left: 15px; } /* -------------------------------------------------------------------------- 9. Tab-strip prev/next glyph never flips The circular prev/next buttons that scroll the horizontal Business Settings tab strip (.nav--tab__prev / .nav--tab__next, business.blade.php) render a static angle-left / angle-right glyph. main.js's own click handler already branches on `$("html").attr("dir") === "rtl"` to reverse the scroll direction, but the glyph itself is plain markup and never rotates with it, so in Arabic "previous" still points left and "next" still points right - backwards, since the tab strip now scrolls the other way. The button is a plain circle (rounded-full, no text, no asymmetric shadow), so mirroring the whole button is equivalent to mirroring just its icon and works regardless of which icon font a given page uses (this panel's own business.blade.php uses fi-rr-angle-left/-right; the admin twin of this rule in admin-module/css/rtl.css covers its material-symbols-outlined arrow_back_ios/arrow_forward_ios pages). transform: scaleX(-1) avoids needing a build step or touching any blade file. */ [dir="rtl"] .nav--tab__prev button, [dir="rtl"] .nav--tab__next button { transform: scaleX(-1); } /* -------------------------------------------------------------------------- 10. Bidi-safe utility for LTR data rendered outside a Section 3 already isolates
/
(unicode-bidi: plaintext) and forces direction:ltr + text-align:right on input[type=tel|email|url]. Neither reaches the same kind of mixed content (phone numbers, booking references, IBANs) when it is printed as plain text in a card, a badge, or a detail-page
instead of a table cell or an input - inside an RTL paragraph the leading "+" of a phone number or the digit grouping of a reference/IBAN can still reorder. This is a UTILITY, not a blanket fix: nothing in this stylesheet applies it to any element on its own. A future view change that prints such a value outside a table/input should add class="bidi-ltr" to that element's own tag - that edit belongs to whoever owns the corresponding blade (booking list, earnings tables, bank-info), since it is a view-template change, not a stylesheet one. */ [dir="rtl"] .bidi-ltr { unicode-bidi: plaintext; }