CX-LED Architecture · One-pagerPADI Web Modernization
PADI.com Localization Architecture
v0.2 · Directional — for validation
00
What this document explains
One picture that ties together the visitor experience (region + language selector), the five architecture layers, the federated content & commerce ecosystem, and — most importantly — what is in scope for November and the decisions still open.
It is capability-based and application-agnostic: the same picture holds across every PADI property. Each section explains what exists today, what changes, and where a decision is needed.
What is the smallest, coherent localization experience we can ship for November — and what is the architecture it grows into across the whole estate?
01
Region ≠ Language — the core distinction
The single most important idea, and the one PADI.com doesn't yet separate today: region and language are two independent signals. Collapsing them into one dropdown is the root problem this work fixes.
Region — the market (where)
Drives the business experience: currency, pricing, applicable products, regulation, region-specific content. Resolved from the visitor's country.
Language — presentation (how)
A separate user preference: which language the content is rendered in, plus RTL, date/number/currency formatting, glyphs. Changing it never changes the market.
Why it matters
A French speaker in Mexico stays in the Mexican market but reads French. A Chinese speaker in the US transacts in USD but reads 中文. One signal must not override the other.
What exists today
PADI.com folds region and language into a single selector, so choosing a language can silently change the market (and vice versa). Blog, Pros Blog and PADI.com each ran as separate properties with their own independent language sets — there was never a need to reconcile them.
What changes
Region and language become orthogonal across the estate, and the properties that are merging into PADI.com must share one coherent region-and-language model rather than three independent ones.
02
How a visitor is routed
Auto-detect the market once at the edge, default to that market's primary language, and let the visitor override either signal — no forced modal (the Nike / Amazon model).
First visit · anonymous
Edge · GeoIP
Detect country
From the IP at the CDN edge — e.g. US.
→
Mapping
Country → market
Business rule · US → United States (Americas). Unmapped falls back — e.g. India → Australia.
→
Language
Market default or preference
English by default · Español if the visitor prefers it — independent of market.
→
Result
Localized page
Language-first URL — /en-us (or /es-us).
Signed-in visitor
Identity · Profile
Preference on file
Saved market + language travel with the account — no re-detection needed.
→
Precedence
Profile over GeoIP
The stored preference wins; location is a fallback only — e.g. a US member abroad still gets their market.
→
Language
As saved
Renders in the saved language regardless of where they are — e.g. Español.
→
Result
Consistent page
Same locale on any device or network — e.g. /es-us everywhere.
The signed-in path is the target model. A single preference that also drives email and app is a post-November item.
Auto-detected once at the edge, no forced landing screen — then overridable by the selector or a signed-in profile. The URL (with cookie / profile) becomes the source of truth. Region drives content; the country sets currency; language drives presentation.
Was Sub-domain regional sites
Regional experiences lived on separate hosts — padi.co.jp, padi.com.cn, padi.co.kr, padi.com.tw — each its own site, its own history, its own SEO surface. Existing live domains (CN, KR, TW) must not go dark at the November launch.
Is Inline path routing
One platform, region and language expressed in the path — a distinct homepage per region with a language toggle. Selecting a language never redirects the region.
padi.com/en-uspadi.com/es-uspadi.com/en-au
How each regional site converts
padi.com.cn→padi.com/zh-cnChina · Asia Pacific
padi.co.kr→padi.com/ko-krKorea · Asia Pacific
padi.com.tw→padi.com/zh-twTaiwan · Asia Pacific
padi.co.jp→padi.com/ja-jpJapan · not in Nov — separate discovery
The legacy domain doesn't go dark — it redirects to its new inline path, preserving the SEO surface. The regional content and language move into PADI.com behind that path. Japan is out of November scope:/ja-jp is the eventual target, but until its separate discovery completes, Japan continues to serve from padi.co.jp.
Who it serves — audiences & markets
Markets — every region PADI operates in, each with its own supported languages
Divers & members — course, learning & community content
Instructors & Pros — professional / trade content
Travellers — trip & destination content
Shoppers — B2C and B2B store experiences
Who delivers it — roles
Content & editorial — authors of the source content on each property
Localization team — translation coordination & linguists
Engineering — integration, routing & the completeness gates
Media / DAM ops — localized imagery & asset governance
Roles span all properties — co-owned with PADI
03
The five architecture layers
A single request flows down through the layers; the localized response is assembled and rendered back at the top. Each layer owns its domain and contributes one part of the localized experience.
Request▼
01ExperienceProven · POC
Owns region + language selector · RTL · date / number / currency formatting · per-locale block visibility
For localization decides what the visitor sees and how it is presented
02API / ServicesProven · POC
Owns locale resolution · content delivery per language · completeness signal to release checks
For localization resolves the locale and serves already-stored localized content — translation management sits outside the request path
03Content RepositoryProven · web
Owns per-locale content variants · UI strings · DAM assets
For localization a content plane + asset plane federated behind one API — the DAM is one capability within the broader Enterprise Content Repository
For localization enforces quality (fails if incomplete) and defines locales — including UK English as a locale distinct from US English
▲Response
04
Localization as a flow across systems
Localization is best understood as a flow across capabilities — content authoring, assets, storefront, pricing — rather than a feature of any single site. The same flow holds regardless of which property a visitor is on.
Any front-end — marketing pages, the course catalog, learning content, the store, travel, club, pro — is a consumer of the same localization signal. For a given request that signal answers three questions: which market, which language, and what that implies (currency, formatting, applicable content). The systems behind it stay authoritative for their own domain — content comes from the CMS, assets from the DAM, pricing from commerce / ERP. Localization coordinates across them; it does not own them.
Translation is only one part of localization. Regional formatting (RTL, date / number / currency), region-specific media, and governance are equally part of adapting the experience for a market — not just translating the words.
Framing localization at this level — as a shared capability rather than one property's feature — is what lets the same model serve every property consistently.
05
Content & commerce ecosystem
Everything localization draws on sits inside one federated ecosystem — the Enterprise Content Repository. Each system stays authoritative for its own domain and is integrated via APIs rather than merged into a single database.
Enterprise Content Repository
Structured content, metadata, taxonomy, localization & governance, rich media, and the commerce & member systems — integrated via APIs, not a single database.
rich media / assets · region-specific imagery (future)
Personalization
CDP + analytics · audience & experiments
Transaction management — “PADI Connect” (custom)
The commerce & member systems localization lines up with — region & country drive which apply and how (currency, payment methods, tax).
CRM
member / customer records
Commerce
catalogue & storefront
ERP
system of record · currency structure
Payments
per-region methods & processors
Subscription
recurring / membership
Certs & eCards
codes, grades, credentials
06
Where does the localization / routing API live?
This is the single most consequential unresolved decision before November scope can be locked. Region-to-language mapping, country→region fallbacks, each market's default and featured languages, and currency all need one owner. Two shapes are on the table.
Current state — what "the edge" is today
The generic flow above says "CDN edge" deliberately. In practice today, that edge is Acquia's Cloudflare (Acquia Edge is Cloudflare-powered), and it fronts PADI.com. Whether the wider estate — store, travel, club, pro — sits behind the same edge is not yet confirmed; those properties may not route through Acquia's Cloudflare. That open question is exactly why the choice below matters: an edge-bound config only works estate-wide if there is one shared edge.
A · CMS-managed edge config
Config authored in the CMS, published to a Cloudflare edge KV store; front-ends read from the edge.
Sub-millisecond reads at the edge; no runtime call to the CMS.
Simple to author where a content team already lives in the CMS.
Sync is automatic — saving in the CMS publishes the JSON to the edge KV and invalidates the cache, so the edge always reflects the latest config.
Assumes every property shares the same Cloudflare/edge — true for PADI.com on Acquia, not guaranteed for store.padi.com, travel.padi.com, etc.
Frames an estate-wide capability inside one property's platform.
B · Standalone microservice
A dedicated localization/routing service any system calls; the config lives independently of any one CMS or edge.
Genuinely platform-agnostic — web, mobile and every property consume the same source of truth.
One place to own country→region, defaults, featured languages, currency; no per-property drift.
Scales to payment/currency and future consumers without routing through a CMS.
An extra network hop per request — performance must be measured (PADI app reviews already cite slowness from too many external calls).
Operational ownership of a hub-and-spoke service must be maintained rigorously.
Our recommendation
Treat the localization/routing layer as a standalone microservice (Option B), cached aggressively (edge/CDN caching in front) to neutralise the extra hop — combining B's single-source-of-truth with A's latency profile. We propose to prototype and measure the cached-microservice latency and bring the numbers to PADI as a co-created decision, rather than assert it. A CMS-only edge config is acceptable only if the whole estate is proven to sit behind the same edge — which it currently is not.
07
Target language coverage & scope
Because Blog, Pros Blog and PADI.com are merging into one platform, their historically independent language sets need to be reconciled into a single, coherent set. Rather than leave this open, we propose a clear baseline to align on — one consistent language experience across the merged properties.
Problem Three independent sets
~24 languages are enabled across the estate combined (PADI.com, Blog, Pros Blog), each content type using a different subset. When they unify under one domain and one region+language selector, three separate answers to "which languages" can't coexist cleanly.
Recommendation One baseline set
Adopt PADI.com's current set as the common baseline across all merged properties — the lowest-common-denominator that avoids shipping untranslated pages. Everything enabled surfaces everywhere; a missing translation should mean the locale isn't offered for that type, not a silent English fallback that hurts SEO and brand.
Russian is excluded — Russian IPs are blocked (legal constraint). The exact baseline count (≈13) is confirmed against PADI.com's live enabled set; shown here for illustration.
Where PADI's input is needed
If a single baseline doesn't fit, the question to resolve together is: what one consistent set works across all PADI domains? Any variation in how Blog / Pros Blog handle languages carries added maintenance, so it's worth confirming the trade-off is intended before building for it.
08
Scaling coverage as regions grow
Coverage isn't static — it expands along the region axis. Each RHQ region carries a primary language and a set of supported languages; as PADI opens or deepens a region, the language set for that region grows. The architecture must express this so the selector and the config service scale by region rather than by ad-hoc per-site edits.
RHQ region
Primary language
Also supported (grows over time)
Americas
English
Español, Português, Français (CA)
EMEA
English
Deutsch, Français, Italiano, Español, Nederlands, Polski, Türkçe, العربية (RTL)
Asia Pacific
English
日本語, 中文, 한국어, ไทย, Bahasa
Illustrative grouping to show the growth model — region drives which languages are surfaced, and the config service is the one place that mapping lives.
09
November scope — and what waits
Ship fewer things, done right. The November program is the PADI.com surface plus the properties merging into it; the wider estate follows.
In · November PADI.com + merged Blog / Pros Blog + MyPADI
Separated region + language switcher — auto-detect with no forced modal (Nike / Amazon reference pattern), overridable by the visitor
Auto-routing by GeoIP; a homepage per region with a language toggle; component-based headless approach
What is real today, stated plainly — so the target model above isn't mistaken for what already exists.
A POC, not production. Localization was validated on a separate proof-of-concept instance with a minimal set of data points — translation workflow, currency / date / number formatting, RTL, pluralization, login + preference. Once the infrastructure and content architecture are finalised, the POC approach will likely need to be revisited before it is ported to the live site.
Two-system translation reality today. padi.com is managed in one translation instance (Crowdin Enterprise); padi.travel runs on a separate instance managed by a partner (Django Stars); commerce ↔ translation integration is not yet verified.
Media is manual today. Per-language imagery is uploaded by hand; automated region-based asset switching via the DAM is the proposed future state, not yet built.
No unified currency / pricing source yet — held per system; ERP is the commerce system of record; the data layer is deferred.
Preferences reset per property today; there is no unified preference centre — a single cross-channel preference is a post-November item.
Market-specific payments (Apple Pay / Google Pay, per-market methods) are out of the November padi.com scope — handled in the B2C / B2B store workstreams.
11
Open questions for PADI
These are the decisions to resolve together before November scope can be locked — some are PADI's to make, others we can co-create. Each lists our current lean as a starting point for the discussion.
#
Question
Our lean
1
Where does the localization/routing config live — CMS edge config, front-end, or a centralized microservice?