OOGO

OOGO

Overview

OOGO is a multi-vendor marketplace built for the UAE, where localization is architecture, not translation. The entire spatial model inverts for Arabic: layouts, navigation, carousels, icons, typography. Three portals (customer, vendor, admin) share one Redux entity layer, and checkout routes between Stripe and regional gateways based on locale and currency.

The product unifies customer, seller, and admin experiences into one connected ecosystem backed by a shared Redux state layer. Three distinct portals share entity logic (products, orders, vendors, inventory) while maintaining role-specific interfaces and workflows. This multi-portal architecture required careful state management to ensure that an order status update in the admin portal is immediately reflected in both the customer and vendor views.

Business Context: Localizing Commerce for the UAE

The UAE market demanded more than a standard marketplace solution with translated strings. The region has unique commerce characteristics: a predominantly mobile-first shopping culture, a bilingual population that switches between Arabic and English fluidly (often within the same session), regional payment methods that complement international processors, and logistics patterns built around proximity-based delivery rather than national shipping networks.

The core problem: Most e-commerce platforms treat localization as a translation layer - swap the text, add direction: rtl, and ship. This approach fails in markets like the UAE where Arabic users expect the entire spatial layout to mirror: navigation flows right-to-left, carousels swipe in the opposite direction, progress indicators reverse, and icon metaphors change (e.g., a "back" arrow points right, not left). Building this correctly requires localization to be an architectural concern, not an afterthought.

Stakeholder perspective:

• ›UAE shoppers expect a native-feeling experience in their preferred language. Awkward Arabic layouts - where text is RTL but buttons and navigation remain LTR - immediately signal a low-quality product.
• ›Vendors need efficient catalog management tools that work in either language, with the ability to create product listings that appear correctly in both Arabic and English to reach the full market.
• ›Administrators need cross-portal visibility into orders, vendors, and customer activity with the ability to manage the platform in their preferred language.

Constraints that shaped the architecture:

• ›The platform had to support real-time language switching without page reloads - users in the UAE frequently toggle between Arabic and English during a single browsing session.
• ›Payment integration needed to support both international processors (Stripe for card payments) and regional methods common in the UAE market.
• ›The three portals (Customer, Vendor, Admin) needed to share core business logic (order state machines, inventory rules, pricing calculations) without duplicating code, while maintaining distinct UI and workflow requirements per role.
• ›Mobile performance was critical - the UAE has high smartphone penetration, and the majority of e-commerce browsing happens on mobile devices.

What I Built

1. Multi-Portal Marketplace Architecture

• ›Shared Entity Layer, Isolated Portal Logic: Architected the application so that core entities (Products, Orders, Vendors, Users) are managed by shared Redux slices with common reducers and selectors. Each portal (Customer, Vendor, Admin) imports these shared slices and adds portal-specific UI state (cart state for Customer, inventory management state for Vendor, moderation state for Admin). This approach prevents business logic duplication while allowing each portal's UI to evolve independently.
• ›Role-Based Routing & Access Control: Implemented a routing architecture where each portal has its own route tree with role-based guards. The Admin portal exposes moderation, analytics, and configuration routes. The Vendor portal exposes catalog management, order fulfillment, and financial reporting. The Customer portal handles browsing, cart, checkout, and order tracking. Shared authentication logic determines which portal routes are accessible to each user.
• ›Cross-Portal State Synchronization: Built real-time state consistency patterns so that actions in one portal reflect immediately in others. When an admin approves a vendor's product listing, the Customer portal's catalog updates. When a customer places an order, the Vendor portal's order queue updates. This synchronization happens through the shared Redux store and API polling mechanisms.

2. Structural RTL & Bilingual System

• ›Layout Inversion Architecture: Built the RTL system as a structural concern rather than a CSS override. Component composition respects reading direction - flex layouts reverse, padding/margin assignments swap (padding-left becomes padding-right), and absolute positioning mirrors. Custom Bootstrap overrides handle grid-level RTL behavior, ensuring that column ordering and gutter alignment invert correctly.
• ›Runtime Language Switching: Implemented seamless language toggling that updates the entire UI without a page reload. When the user switches languages, the i18n provider updates translation strings, the document dir attribute changes, CSS custom properties for direction-dependent values recalculate, and React re-renders all direction-sensitive components.
• ›Arabic Typography Handling: Arabic text requires different typographic treatment than Latin text - different line heights, different font stacks (system Arabic fonts vs. Google Fonts Arabic variants), and different text rendering behaviors for connected script. The theming system applies font-specific adjustments based on the active locale.
• ›Bidirectional Content: Product listings contain both Arabic and English content (bilingual titles, descriptions, attributes). The rendering engine displays content in the user's active language while storing both versions, ensuring that a single product appears correctly regardless of the browsing language.

3. Regional Commerce Integration

• ›Multi-Gateway Payment Architecture: Built a payment method selection layer that presents appropriate payment options based on user locale and transaction context. International cards route through Stripe, while regional payment methods use UAE-specific processors. The checkout flow adapts its UI to show relevant payment options without exposing the routing complexity to the shopper.
• ›Location-Aware Vendor Discovery: Integrated Google Maps API with custom bilingual map labels (Arabic labels for Arabic users, English for English users) for vendor proximity search. Users can discover nearby vendors, view delivery radius coverage, and get location-based recommendations. The map component handles RTL layout (map controls position swap) and Arabic address formatting.
• ›Currency & Number Formatting: Implemented locale-aware formatting for prices (AED currency symbol placement differs between Arabic and English), quantities, dates, and phone numbers. Arabic numeral display follows Eastern Arabic numeral conventions when the active locale is Arabic.

4. Performance Engineering

• ›Redux Selector Optimization: The three-portal architecture creates complex state trees. Naive selectors that derive data from large state slices caused unnecessary re-renders in listing views. Refactored with memoized selectors (reselect) that compute derived state (filtered products, sorted orders, aggregated analytics) efficiently, recalculating only when their specific input slices change.
• ›State Shape Denormalization: For high-frequency read paths (product listing pages, order dashboards), implemented denormalized state views that pre-compute the data shape components need, avoiding expensive state traversal and transformation on every render cycle.
• ›Mobile Performance Focus: Optimized the mobile shopping experience through image lazy loading, component-level code splitting for portal-specific features, and touch-optimized interaction patterns (swipe gestures for product galleries, pull-to-refresh for order lists).

5. Vendor Management Ecosystem

• ›Catalog Management Interface: Built comprehensive product listing tools for vendors - create, edit, bulk update, and manage inventory across product variants (size, color). The interface supports bilingual content entry (Arabic and English fields side by side) and image upload with preview.
• ›Order Fulfillment Workflows: Implemented vendor-side order management with status tracking (new → accepted → preparing → shipped → delivered), customer communication tools, and fulfillment timeline visibility.
• ›Vendor Analytics Dashboard: Built sales analytics views showing order volume, revenue trends, top-selling products, and customer metrics. Charts and data tables respect the active locale (Arabic labels, Eastern Arabic numerals, RTL chart axis orientation).

Architecture Highlights

RTL as Structural Architecture

The RTL implementation goes deeper than most localization approaches. Rather than using a single direction: rtl CSS property and hoping everything inverts correctly, the system uses a layered approach:

1. ›

   CSS Logical Properties: Where possible, layout uses CSS logical properties (margin-inline-start instead of margin-left) so that values automatically flip with the document direction. This handles the majority of spacing and alignment without conditional logic.

2. ›

   Direction-Aware Components: Components that have inherent directionality (carousels, progress bars, breadcrumbs, pagination) receive a direction prop from the i18n context and render their internal layout accordingly. A carousel swipes left-to-right in LTR mode and right-to-left in RTL mode.

3. ›

   Icon Mirroring: Directional icons (arrows, chevrons, navigation indicators) are mirrored in RTL mode using CSS transforms. Non-directional icons (search, settings, user) remain unchanged. The icon system maintains a registry of which icons are directional to handle this automatically.

4. ›

   Bootstrap Grid Overrides: Bootstrap's grid system required custom overrides for RTL column ordering. A utility layer swaps col-*-push and col-*-pull classes in RTL mode and reverses flex direction on row components.

This structured approach means that new components automatically handle RTL correctly when they use the provided layout primitives, rather than requiring manual RTL testing and adjustment for every new feature.

Redux Multi-Portal State Design

The state architecture separates concerns across three layers:

• ›Entity Layer (shared): Normalized stores for Products, Orders, Users, Vendors. All three portals read from and write to these same slices through shared action creators and reducers. An order entity has the same shape regardless of which portal is viewing it.
• ›Domain Layer (portal-specific): Each portal has its own state slice for domain workflows. The Customer portal has cart and checkout state. The Vendor portal has inventory management and fulfillment state. The Admin portal has moderation queues and platform configuration state.
• ›UI Layer (portal-specific): Each portal manages its own UI state - sidebar visibility, active tabs, modal state, filter selections. This state is never shared across portals.

This layered approach prevents the common multi-portal pitfall where shared state becomes entangled with portal-specific UI concerns, making the codebase hard to maintain as portals evolve independently.

Payment Gateway Routing

The payment architecture uses a strategy pattern where each payment gateway implements a common interface (initialize, tokenize, confirm, handleWebhook). A routing layer selects the appropriate strategy based on:

• ›User locale: UAE-based users see regional payment options alongside Stripe.
• ›Transaction currency: AED transactions can use regional processors; USD transactions route through Stripe.
• ›Payment method type: Card payments vs. bank transfers vs. wallet payments each route to the gateway that supports them.

The checkout UI dynamically renders payment method options based on the routing layer's determination, so users only see payment methods that are available for their specific transaction context.

Technical Deep Dive: Bilingual RTL Rendering Architecture

The most architecturally challenging aspect of OOGO was building a truly bidirectional interface that doesn't just translate text but inverts the entire spatial model of the application.

The Problem: Most RTL implementations are superficial - they add dir="rtl" to the HTML document and let CSS direction handle the rest. This works for basic text alignment but fails for complex UI patterns: flex layouts with mixed-direction children, absolutely positioned elements (tooltips, dropdowns, popovers), Canvas/SVG-based visualizations, and third-party components (Google Maps, Stripe Elements) that have their own layout assumptions.

The Challenges Solved:

1. ›

   Mixed-Direction Content: Product listings contain both Arabic and English text (a product might have an Arabic title but an English brand name). The rendering engine uses Unicode bidirectional algorithm (Bidi) attributes to handle inline mixed-direction text correctly, wrapping segments with appropriate dir attributes so the browser's text rendering engine handles character ordering.

2. ›

   Third-Party Component Integration: Google Maps and Stripe Elements have their own layout engines that don't automatically respond to document-level dir changes. The map component manually repositions controls (zoom buttons, fullscreen toggle) for RTL mode and renders Arabic map labels through the Maps API's language configuration. Stripe Elements are configured with locale-appropriate formatting but render in an iframe with its own document context.

3. ›

   Animation Direction: CSS transitions and JavaScript animations that use horizontal movement (slide-in menus, carousel transitions, progress bar fills) need to reverse their direction in RTL mode. The animation system reads the current locale direction and applies transform adjustments so that a "slide-in from left" animation becomes "slide-in from right" in RTL.

4. ›

   Form Layout: Form fields in RTL mode need label-to-input alignment reversal, placeholder text direction changes, and validation message positioning swaps. The form component system handles this through direction-aware wrapper components rather than requiring each form to implement its own RTL adjustments.

5. ›

   Data Table Direction: Tables with both Arabic and English column headers need intelligent alignment - text columns align based on content language, while numeric columns maintain consistent right-alignment regardless of document direction. The table component inspects content type to apply appropriate alignment rules.

Why this approach: The investment in structural RTL support (rather than quick CSS fixes) paid off as the application grew. New features built using the provided layout primitives automatically render correctly in both directions without dedicated RTL testing or bug-fixing cycles. The alternative - fixing RTL bugs reactively as they're reported - creates an ever-growing maintenance burden and degrades the Arabic user experience.

Key Challenges & Solutions

• ›

  Challenge: CSS direction: rtl doesn't handle all layout patterns - flex containers with explicit margin-left/padding-right, absolutely positioned elements, and CSS Grid column placement all break in RTL mode. Approach: Adopted CSS logical properties (margin-inline-start, padding-inline-end) throughout the codebase and built direction-aware wrapper components for patterns that logical properties don't cover (absolute positioning, canvas rendering). Created a linting rule that flags physical direction properties (margin-left, padding-right) in code review. Why: Logical properties let the browser handle direction switching automatically for the majority of layout cases. The linting rule prevents regression by catching new code that uses physical properties instead of logical ones.

• ›

  Challenge: Three portals sharing entity state (Products, Orders) created a risk of state mutations in one portal causing unexpected behavior in another. Approach: Enforced immutable state updates through Redux Toolkit's Immer integration and strict action typing. Each portal dispatches domain-specific actions that are handled by shared reducers with well-defined state transitions. Added integration tests that verify cross-portal state consistency after multi-step workflows. Why: Without immutability guarantees, shared state in a multi-portal architecture becomes a debugging nightmare. Redux Toolkit's Immer integration makes immutable updates ergonomic while TypeScript ensures action payloads are correct at compile time.

• ›

  Challenge: Arabic typography required different line heights, letter spacing, and font sizes than the English layout, causing text overflow and alignment issues when switching languages. Approach: Created locale-aware design tokens that adjust typography values based on the active language. Arabic font stacks use dedicated fonts optimized for connected Arabic script (Noto Sans Arabic, Tajawal) with adjusted line-height multipliers. Theme values switch dynamically when the locale changes. Why: Latin and Arabic scripts have fundamentally different vertical metrics - Arabic script has more pronounced ascenders and descenders, and connected letter forms create different visual density. A single set of typography values produces poor results in one language or the other.

• ›

  Challenge: Integrating regional UAE payment processors alongside Stripe required handling different authentication flows, tokenization approaches, and error response formats. Approach: Built a payment gateway abstraction layer using the strategy pattern, where each gateway implements a common interface. The checkout flow interacts with the abstraction layer, unaware of which gateway is processing the transaction. Gateway selection happens automatically based on locale and payment method type. Why: Direct integration of multiple payment gateways without an abstraction layer would scatter gateway-specific logic throughout the checkout code. The strategy pattern isolates gateway-specific complexity while presenting a unified interface to the rest of the application.

Outcomes

• ›Native bilingual experience: Arabic users get a fully mirrored interface; new features inherit RTL support through the structural layout system.
• ›Multi-portal efficiency: Shared entity state with isolated UI state lets each portal evolve without business-logic duplication or cross-portal bugs.
• ›Payment reliability: The gateway abstraction routes each transaction to Stripe or a regional processor by locale and currency, so shoppers only see methods that work.
• ›Listing performance: Memoized selectors and denormalized read shapes keep product listing rendering fast as the catalog grows.

Engineering Takeaways

OOGO demonstrated that localization is an architectural challenge, not a content challenge. Building for the UAE market required thinking about "the direction of the user journey" from day one - not just which language the text is in, but which direction the eye scans, which side navigation anchors to, and which way gestures flow.

Patterns I'd reuse:

• ›CSS logical properties as the default for all layout code, enforced by linting. This single decision eliminates the majority of RTL bugs before they occur.
• ›The multi-portal architecture with shared entity state and isolated UI state. This pattern applies to any product serving distinct user roles that operate on the same underlying data.
• ›Payment gateway abstraction using the strategy pattern. Any platform integrating multiple payment providers benefits from isolating gateway-specific logic behind a common interface.

What I'd reconsider:

• ›Bootstrap's RTL support required extensive custom overrides. A utility-first CSS framework like Tailwind CSS with built-in RTL support (rtl: variant) would reduce the custom override surface significantly.
• ›The JavaScript-based i18n system loads all translation strings on initial page load. For larger translation files, a namespace-based lazy loading approach would reduce initial bundle size.

Trade-offs acknowledged:

• ›Chose Bootstrap over Tailwind CSS for team familiarity at the time, accepting the RTL override maintenance burden in exchange for faster initial development velocity.
• ›Chose client-side locale switching over server-side locale routing (e.g., /ar/ and /en/ URL prefixes), accepting slightly heavier client bundles in exchange for instant language switching without navigation.
• ›Chose Redux for state management across all three portals, accepting the boilerplate overhead in exchange for predictable state management that's critical when multiple portals share entity data.