Skip to content

ADR-0004: English-only language scope for M1/M2

Context

961tech is a Lebanese tech-product aggregator. Lebanese buyers move between Arabic, French, and English depending on context — so on the surface, multi-language support looks load-bearing. The persona research in #36 (docs/reference/personas.md) and the competitive landscape research in #35 contradict that surface read:

  • Every Lebanese tech retailer profiled (PCAndParts, 961Souq, Macrotronics, plus the long tail) ships an English-only UI. There is no observable Arabic-UI tech-retailer in the Lebanese market we'd be matching parity with.
  • All six personas default to English for technical content — including the older "Office IT buyer" cohort where French is more common in non-tech domains.
  • Lebanese-Arabic SERP queries for PC parts collapse into classifieds (OpenSooq, Olx) and cross-ranking Saudi retailers (PCD, La3eb, PCPalace), not into a Lebanese-Arabic aggregator audience. Translating wouldn't capture a missing cohort; the cohort isn't there.
  • Code-switching is real but asymmetric — Lebanese buyers code-switch into English for tech, not out of it.

The ticket #37 originally framed this as a research-heavy RFC comparing single vs multi-language paths and assumed Arabic-first might be defensible. The persona research collapsed that scope: there is no decision to weigh between options of comparable evidentiary support. English-only is the only path with a clear evidence base for M1/M2.

The cost of being wrong (i.e., shipping English-only and discovering later we need Arabic) is not "retrofit RTL into every component, brutal" — it is "ship Arabic+RTL once we have telemetry from real Casual-track users showing the gap." The component library can adopt logical CSS properties (margin-inline-start etc.) opportunistically without committing to a full RTL/i18n stack now. ADR-0007 (or whichever ADR closes the i18n revisit) will pay that cost when warranted.

Decision

961tech ships in English only for M1 and M2. No translation pipeline, no per-language URL prefixes, no RTL CSS work, no hreflang SEO planning. Component code may adopt logical CSS properties where natural (cheap, future-friendly), but no work is done specifically to enable Arabic or French.

The ticket #37 collapses to this ADR. RFC for #37 is intentionally not produced — there is no decision to defend with options.

i18n is revisited when either of these triggers fires:

  • Casual-track telemetry (post-launch) shows ≥10% of sessions originating from Arabic-preferring devices/locales with above-average bounce vs the English baseline; or
  • A specific business reason to expand outside Lebanon emerges (e.g., a UAE / KSA partner ask) where a non-English market is in scope.

Until then: English-only is the working assumption everywhere — UI copy, microcopy, error messages, marketing surface, scraper category labels.

Consequences

Positive

  • Smaller M1/M2 surface. No translation tooling (next-intl, next-i18next, hand-rolled), no schema columns for translatable fields, no per-locale formatting.
  • Simpler SEO (#38). Single canonical URL set, no hreflang, no per-language sitemaps. Aligns naturally with the competitive-landscape finding that English SERP is where the buyer cohort lives.
  • Simpler component design (#27, #28). No RTL constraint on layout decisions; designers can use directional patterns freely.
  • Lower QA burden. One language to copy-edit, one buyer journey to user-test.
  • Aligns with retailer reality. When 961tech displays a priceUsd and a titleRaw lifted from PCAndParts or 961Souq, both are already English; we're not rewriting retailer content into a translated mode.

Negative

  • Closes the Lebanese-Arabic-only buyer cohort, if one exists. Persona research found no evidence of one, but absence of evidence ≠ evidence of absence. We accept that risk and plan to detect it via Casual-track telemetry rather than pre-empt it via translation work.
  • Marketing copy in English only may slightly reduce reach in Arabic-preferring social channels (FB groups conducted in mixed Arabic+English). Mitigated by the fact that the dominant Lebanese PC community (Lebanon PC Gamers FB) operates in English-with-Arabic-aside.

Neutral

  • Copy still respects Lebanese tone. "English-only" is a UI scope decision, not a brand-voice one — see #42 for voice / microcopy. Lebanese English (informal, code-switch-friendly, not transatlantic-corporate) remains the target.
  • Component code can use logical CSS properties (padding-inline, margin-inline-start, text-align: start) where natural. Cheap, doesn't commit to RTL, makes future revisit smaller.

Alternatives considered

Alternative A: Multi-language from M1 (English + Arabic + French)

Rejected because:

  • Persona and competitive research surface no Arabic or French aggregator audience to capture. Translation cost would be paid against a hypothetical user.
  • RTL-aware component library is a significant constraint on design system #27 — every layout decision becomes "does this work in both directions?" Defaulting to RTL-friendly logical CSS is cheap; designing for RTL from day one without a clear audience is expensive.
  • Translation maintenance (UI strings + dynamic content) is a recurring cost — every new feature multiplies by N languages. Carrying this for a M1/M2 prototype that may pivot is wasteful.

Alternative B: English + Arabic with RTL, no French

Rejected because:

  • Same Arabic audience problem as Alternative A. The strongest argument for Arabic was "code-switching means buyers want it" — the persona research showed code-switching goes the other direction (into English for tech).
  • Halves the maintenance cost vs Alternative A but still pays for a cohort with no evidence base.

Alternative C: English + French, no Arabic

Rejected because:

  • Francophone Lebanese (Lycée Verdun / Saint Joseph cohort) read English tech content fluently. Adding French gives almost no marginal coverage.
  • French retailer content (LDLC, Cowcotland) is European, not Lebanese — translating creates a parity that doesn't map to actual buyer demand.
  • Zero Lebanese tech retailer ships French UI. Adding it makes 961tech less parity-aligned with the market.

Alternative D: Defer i18n indefinitely without an ADR (status quo)

Rejected because:

  • "Defer indefinitely" without a written decision becomes "no one ever decides" — the ticket #37 sits open and gets re-litigated every time a contributor sees it.
  • The personas research is deep enough that the deferral is a decision, with a real evidence base. An ADR records that, sets the revisit triggers, and closes the ticket cleanly.

References