From translation
to true localization.
An architecture direction for how PADI.com resolves region and language independently — built from this week's engineering working sessions and updated following tonight's 7:30pm discussion with Kristina and the PADI technology team.
PADI.com does translation today — not even regionalization, let alone localization.
PADI.com's live selector is a single language dropdown in the top utility nav — not a region+language grid. Most entries just translate the page in place; four of them quietly redirect to a different country domain instead. Nothing in it reads a PADI RHQ. Regionalization does exist here and there across PADI's properties — China and Japan run genuinely separate platforms, and Store.padi.com already does partial region detection to set currency — but it's pocketed, not a holistic strategy. That gap is exactly what tonight's direction closes.
Translation
On PADI.com itself, region and language are entangled in one control, but there's no actual regionalization behind it. Picking German, French, Spanish, Italian, Dutch, Arabic, Portuguese, or Thai just translates the page text in place. Picking Simplified Chinese, Traditional Chinese, Japanese, or Korean instead silently redirects the visitor to an entirely different ccTLD domain (.cn, .tw, .jp, .kr) — a site switch dressed up as a language option, with no region logic driving either path.
True localization
True localization goes past swapping text. Imagery, pricing display, promotions, and even which features show up can genuinely differ by locale — a user's language changes what they read, but their region can change what they're shown and able to buy at all. Full-stack localization means every layer, from the database up through the API to the rendered UI, is built to vary this way — not just the copy.
What this looks like in practice
- Region-specific imagery or promotions — a banner appropriate for one market hidden or swapped in another
- Locale-aware formatting — dates, numbers, currency display, and right-to-left layout where needed
- Feature or payment-method availability that follows the market, not just the language
Today: one dropdown, two hidden behaviors
PADI.com's actual selector today is a lightweight dropdown, not a full-page grid — it lives under "English ⌄" in the top nav. It looks like a simple language switcher, but four of its thirteen entries are region redirects wearing a language label.
Target: silent routing + header/footer selector
Fixing this means treating region and language as two separate settings — the principle laid out next. Applied here: geo-IP auto-routes the visitor straight to localized content, with a quiet header/footer control to change region and language independently, any time.
Every region offers the full language catalogue. Kristina confirmed region determines content availability, regulatory scope and currency — not which languages a customer can choose. So unlike Amazon's region-restricted model, every language is reachable in every region.
Region and language are two separate settings.
This is the split behind the target-state selector in Section 01 — and it's the architectural principle for PADI's future-state vision more broadly, independently converged on in this week's engineering working sessions too. It's the single decision everything else in this deck follows from.
🇫🇷 A diver in France
Sees the France regional experience — pricing, promotions, regulatory copy — while reading it in German, if that's their language preference.
🇺🇸 A diver in the US
Stays in the US experience while reading it in Chinese — selecting Chinese never redirects them into the China regional site, the way it does today.
Region is never stored as a preference — always auto-detected via geo-IP. Language persists: for authenticated users via their profile, and for unauthenticated users via device intelligence where a device is linked to a known user. With no device intelligence, it falls back to the visitor's OS/device language, then to the region's default language.
The happy-path localization flow.
Co-created with the PADI engineering team this week, this is the one-pager expected on every open topic — five layers, from the visitor's device down to the business rules that decide what they see. Enterprise Content Repository sits outside this diagram; it's tracked as its own, separate conversation.
This diagram is directional, not final — expect it to keep evolving as other open topics (payments, cart, search, and more) get solutioned in parallel.
Where does the service live?
Proposed direction: not Drupal, not Next.js alone — the Localization Service sits at the API Gateway, in front of every system (payments, storefronts, mobile, travel) so all of them can call it the same way. Immediate scope: region identification (geo-IP) + language preference resolution. Translation stays with Crowdin — this service is never a translation source. Tonight's call confirmed the shape shown above: downstream services (account, user, payment, and others as they come into scope) consume locale context via headers rather than calling the service on every request.
What it does not do
It doesn't manage translations, and it doesn't decide layout. Content-only regional variation (show/hide, e.g. hiding the AWARE promo banner for China) is in scope; full layout variants per language/region are a Phase 2 conversation, not November. Acquia DAM's role also depends on taxonomy work not yet done — assets need region/country tagging before the CMS can resolve, say, a China-specific hero image versus an EMEA one. That taxonomy is being scoped in an upcoming DAM meeting.
Kristina raised a central place to control which features are on/off per region (and eventually device / application). For November, the CMS-hosted content features can be toggled per region from Drupal, driven off the Feature Inventory. For the cross-application single control plane — one place spanning web, mobile, store, etc. — we'll explore LaunchDarkly, already used on some PADI properties, and assess integrating the CMS content features into it, or keep them under Drupal for now and consolidate later. A flag only takes effect where the feature is built to read it.
Country-code domains, confirmed — not slugs.
This flipped on tonight's call. The direction going in was a single domain with region+language as a URL slug. Kristina redirected it: PADI keeps full country-code domains, citing the Live Nation / Ticketmaster precedent for regional sites, and because China and France both have cultural and regulatory reasons to require local domain formats.
Today
| Market | URL |
|---|---|
| US / Global default | padi.com |
| China | padi.com.cn |
| Korea | padi.co.kr |
| Taiwan | padi.com.tw |
| Japan | padi.co.jp |
Target — confirmed tonight
| Market | URL |
|---|---|
| France | padi.fr |
| Germany | padi.de |
| China | padi.cn (unchanged) |
| Unsupported market (e.g. Bulgaria) | routes to nearest domain (e.g. padi.de) |
The one open thread: whether country-code domains still carry the SEO weight they used to. PADI and Axelerant still need to discuss this with Nathan to confirm whether current Google guidance still rewards this pattern — if it doesn't, this direction could reopen. Otherwise, it's the confirmed target: no more slug-based URL model.
Kristina, JWB, and Charles are mapping every country PADI operates in to a region (EMEA / Americas / Asia Pacific), plus defining fallback routing for countries PADI doesn't yet have a domain for — e.g. Bulgaria routing to the nearest EMEA domain. Target: Tuesday COB.
Americas
RHQ region. Covers US, Canada, and Latin America markets.
EMEA
RHQ region. UK English (en-GB) ships as its own locale, distinct from US English.
Asia Pacific
RHQ region. Australia is the default here — India currently resolves to this RHQ too (AUD currency), a known gap not yet resolved. Korea, Taiwan, China stay distinct sites for November; Japan is excluded — see Section 06.
Three properties, three different language sets.
Before we can localize consistently, PADI's own properties need to agree on one shared language list. Right now they don't.
| Language | PADI.com | Blog | Pro Blog |
|---|---|---|---|
| English | ✓ | ✓ | ✓ |
| Spanish (Spain) | ✓ | ✓ | — |
| Spanish (Latin America) | — | — | ✓ |
| French | ✓ | ✓ | ✓ |
| German | ✓ | ✓ | ✓ |
| Italian | ✓ | ✓ | ✓ |
| Dutch | ✓ | ✓ | ✓ |
| Portuguese | ✓ | ✓ | ✓ |
| Portuguese (Brazil) | — | ✓ | — |
| Arabic | ✓ | ✓ | ✓ |
| Thai | ✓ | ✓ | ✓ |
| Simplified Chinese | ✓ | ✓ | ✓ |
| Traditional Chinese | ✓ | ✓ | ✓ |
| Japanese | ✓ | ✓ | ✓ |
| Korean | ✓ | ✓ | ✓ |
| Greek | — | — | ✓ |
| Polish | — | — | ✓ |
| Turkish | — | — | ✓ |
| Finnish | — | — | ✓ |
| Russian | — | ✓ | ✓ |
| Total | 13 | 15 | 18 |
JWB's full list is now in: PADI supports 43 languages across the platform — roughly 30 live today and the rest planned. Kristina wants the set standardized across all entity types — consumer, Pro, and store personas currently each carry a different subset, and that's the fragmentation she wants closed. The November footprint is already larger than PADI.com's 13, because Blog and Pros Blog are migrating onto the new platform and bring their own languages — so the November set is the union across PADI.com + Blog + Pros Blog, with UK English added and Russian removed. Full platform-wide convergence to the 43 is the direction; enabling each additional language is configuration, with the real effort being translation volume and review.
Removing: Russian
PADI blocks Russian IPs at the network level, so Russian content has no audience that can legally reach it. It appears on Blog and Pro Blog today (not PADI.com) and should come out everywhere as part of the unification.
Adding: UK English
Confirmed with PADI — en-GB ships as its own locale, distinct from en-US (spelling: colour vs. color, etc.). Both Crowdin and Drupal support this natively; scoped for the November go-live.
What ships in November — and what deliberately doesn't.
PADI's stated preference holds here too: fewer things done right beats many things half-done. This is the line we're proposing to present as final for the November release.
Regional routing & the new selector
- Geo-IP auto-detection routing to the nearest regional homepage — no forced landing page
- Header/footer selector-based region/language override, set independently
- URL model moved to
padi.com/[language]-[region]for supported markets - Americas, EMEA, and Asia Pacific (Korea, Taiwan, China) regional homepages — Japan excluded
Language baseline & quality gate
- The union of PADI.com, Blog and Pros Blog languages as the November baseline (already beyond PADI.com's 13)
- Russian removed site-wide; UK English (en-GB) added as a distinct locale
- Content-only regional variation (show/hide components); no full layout variants
- CMS-hosted content features toggleable per region via a feature registry, driven off the Feature Inventory
- Localization completeness gate — Missing / Stale / Complete — enforced at Drupal publish and in CI/CD
Japan stays on padi.co.jp, as-is
- Japan's platform, and its own localization needs, don't fold into this November release
- All traffic for the Japan locale continues to redirect to padi.co.jp exactly as it does today — no changes, no regressions
- Needs its own discovery track once November ships, given its distinct platform and market requirements
Everything that depends on business or exec decisions
- Full per-region / per-language layout variants (beyond show/hide)
- New multi-currency transactions — requires Stripe MID setup per region; India → Asia Pacific / AUD gap remains open
- Cards, payments, and market-specific payment methods (e.g., Apple Pay / Google Pay by device) — separate stream with product owners
- Feature Registry — the cross-application control plane (LaunchDarkly, already used on some PADI properties; each app reading from one place). CMS-content toggling lands in November; consolidating all applications is later.
What's resolved, and what's still open.
Tonight's call resolved the region-persistence conflict and the URL/domain model; Kristina's emailed response has since settled more. Below: what's now closed, then the items still open.
Resolved
Full language set per region
Confirmed with Kristina — every region offers the full language catalogue. Region governs content availability, regulatory scope and currency, not which languages a customer can choose. (Closes the Section 01 question.)
Language persistence model
Region is never persisted (always geo-IP). Language persists via profile (authenticated) or device intelligence (unauthenticated, device linked to a known user), else the OS/device language, else the region default. November feasibility to be confirmed once PADI's device-intelligence requirements and data-storage approach are finalized.
Still open
Locale service caching & reliability
The API Gateway placement is confirmed, but not the caching strategy. Kristina wants to move away from cookies toward server-side resolution, with cookies only as a short-term cache — but that raises latency and single-point-of-failure questions nobody's answered yet.
Multi-user shared-device resolution
A dive center with many users on one shared machine — device- and cookie-based resolution break down here. Now being worked within the device-intelligence workstream.
UAT / validation gap for translations
QA doesn't mirror production, so there's no near-production stage for a human to validate translations before they go live — matters especially for China. Needs a validation process, not just a translation pipeline.
Feature Registry — mechanism & scope
CMS-content toggling is planned for November via Drupal. Open: which Feature-Inventory items need flags (a large list — needs review), and whether to integrate into LaunchDarkly (PADI's existing tool) as the cross-application control plane.
What tonight's call actually produced.
- Send this artifact to Kristina (Vivek)Within a couple of hours of tonight's call, so she can review the open questions ahead of Tuesday.
- Country-to-region mapping (Kristina, JWB, Charles)Map every country PADI operates in to a region (EMEA / Americas / Asia Pacific), and define fallback routing for countries without their own domain yet — e.g. Bulgaria → nearest EMEA domain. Target: Tuesday COB.
- Current + future language lists (JWB) — receivedThe full list is in: 43 languages total (~30 live today, the rest planned), now reflected in Section 05.
- SEO check on country-code domains (Kristina / JWB, with Nathan)Confirm whether Google's current guidance still rewards country-code domains over a slug-based model — this could reopen the Section 04 decision if it doesn't.
- Answer high-priority requirements-doc questions (Ralph, Charles)Needed by Monday/Tuesday to unblock November-vs-February feasibility marking across all seven PADI unification topics, not just localization.
- Monday's weekly call — direction validation onlyThis call validates the overall approach across all PADI unification topics; it is not the full readout. The architecture one-pager and feasibility detail come later — see below.
- DAM taxonomy & asset-tagging schema (Vivek, Hardik)Upcoming DAM meeting to define region/country tagging so Acquia DAM can resolve locale-specific assets correctly.
- Tuesday–Wednesday working sessionsTwo hours each morning (7–9 AM PST) with Ralph, Charles, Aref, and Jeff, covering the five prioritized November topics.
- Architecture + November feasibility vs. future iterations readoutTo be planned, following the Tuesday–Wednesday working sessions with the PADI technology team — no date committed yet.