What we all agree localization requires — end to end, for any market, any time.
Not a list of what's in or out yet, just the shared definition of "done." Everything after this is about when we build toward each piece, not whether we will.
Region-aware imagery & promotions
Localized pricing & currency display
Feature availability by market
Full-stack: database → API → UI
Formatting, RTL, and locale-aware dates/numbers
Device intelligence for returning-user context
2 The system, not the slice
We're not building a November-only system.
We're building one architecture designed to stretch to everything in Step 1 — region resolution, a central localization service, and the content, data, and config layers underneath it. November is which pieces of this we switch on first. It is not a different, smaller system we'll have to rebuild later.
Same five-layer architecture regardless of what's switched on — directional, not final. We'll keep updating it iteratively as we understand more (device fingerprinting and other services can grow into this over time).
3 What ships when
Out of everything in Step 1, here's what ships first — and what's sequenced for later.
In scope
Regional routing & the selector
Geo-IP auto-detection routing to the nearest regional homepage — no forced landing page
Header/footer selector to override region and language independently — design team looped in on accounting for region, not just language
Country-code domains — .cn, .fr, .de, .bg — signed off by Kristina July 30; regions will not fold into .com
Country-to-region mapping is done; Kristina is now mapping which countries PADI actually operates in (dive center presence), target Friday
Open item: what shows on .bg/.cn/.fr/.de before those markets are fully ready — static content, or route to another region in the interim? No rush — the architecture supports swapping regions in later
In scope
Language baseline & quality gate
13–14 languages as the unified November baseline across PADI.com, Blog, and Pro Blog — UK English (en-GB) now confirmed required for November
Every language reachable in every region — region shapes content, regulatory, and currency, not language choice — confirmed
Russian removed
Target: scale to 29–30 languages by February, matching what the mobile app already supports (~28 today); course-level language coverage on the app varies per course and is tracked separately
Content-only regional variation (show/hide); localization completeness gate at publish
Data capture is now confirmed non-negotiable — Kristina needs device ID as a conversion-reporting attribute for the board, a better unit than session. Device ID is expected to attach to an anonymous profile, then link to the user post-login
Whether this can actually power localization for November stays a separate, still-tight question — depends on the capabilities document still to come; Bassam to align with PADI technology on where this data is stored and how it flows
Terms of use for this data lives under Account Creation (T&Cs) and Preferences (privacy) — not something localization needs to solve
Out of scope
Japan
Stays on padi.co.jp exactly as-is — a Japan selection keeps routing there just like today
Its move to the new platform (separate stack, third-party vendor) is a dedicated track after November — not a drop in support
Why .co.jp and not .jp came up as an SEO question — likely historical (Japan owned its own site before the domain transferred over); Aref confirming
Japan's site runs its own regionalized stack (ASP, static DSL) that's never been migrated — feature parity needs assessing before any future move to the shared Drupal platform
Later
Sequenced for Phase 2 and beyond
Full per-region/language layout variants beyond show/hide
New multi-currency transactions (Stripe MID per region) — India/APAC/AUD gap tracked; converges with the unified payments and cards workstream
Content residence (service, DAM, or a broader enterprise content repository) — DAM kicks off for November for PADI Blog and assets; broader property-wide integration is later
Full platform-wide language convergence beyond the February 29/30 target
4 Feature Registry
An emerging approach for November.
In progress
A content-side registry for November
A record of which features are on or off by region, for the items already in scope — built from the Feature Inventory list you shared
Managed within the Drupal instance for now, with the toggling mechanism applied to CMS-hosted content features
Confirmed on today's call — PADI (Charles) already uses LaunchDarkly for feature flags on some properties; known cost and prior challenges noted, so Bassam is also exploring alternatives. Deeper solution conversation planned next week
5 What we need from PADI
A few things only PADI can unblock — and a few we're still aligning on.
Confirmed todayOwner: PADI (product)
Internal alignment on languages
Baselining 13–14 languages, based on PADI.com today, for November — with expansion to ~30 languages in 2027 (February or Q2, depending on further discovery and discussion) — what remains is executing the downstream communication below
In progressOwner: Kristina
Region & country mapping
Country-to-region mapping is done. Now mapping which countries PADI actually operates in (dive center presence) — target Friday
Owners assignedOwner: Kevin (marketing), Kristina (product)
Downstream team communication
Kevin owns telling Marketing, Kristina owns Product — Courses, Travel, Learning, and other business units still need to hear about the language standardization from them
Vivek to add the exact per-property delta (e.g., which specific languages differ on Pro Blog) directly into the language table on the Main Deck, so Kristina and Kevin don't have to hunt across decks
Owner: PADI Product
Incremental language path
Confirmed on today's call: 13–14 languages for November, scaling to 29–30 by February — matching what the mobile app already supports
QA doesn't mirror production, so there's no near-production stage to have a human validate translations before they go live — matters especially for China
The architecture one-pager shows this as the central hub, but the technology and implementation still need solutioning — how it's built, how it's called, how it scales
Axelerant investigatingOwner: Bassam, with PADI technology
Device fingerprinting — data flow & storage
Data capture itself is now non-negotiable (see Step 3); Bassam to align with PADI technology on where the device ID is stored and how it attaches to an anonymous profile, then a logged-in user
To be scheduled
Definition-of-Done session
Separate session with Ed and Axelerant — November vs. February thresholds, automated vs. manual checks, and security posture across all features, not just localization
Confirmed todayOwner: PADI Product
Does this framing land?
Yes — confirmed on today's call. The one callout: device fingerprinting data capture is a must-have (board conversion reporting), while full feature integration stays flexible; terms of use for that data sits under Account Creation and Preferences, not localization.