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, updated through the July 30 architecture readout with Kristina and the PADI technology team.
Call-ready readout companion (30-min walkthrough) →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 the direction below 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.
Amazon restricts language options by region (Amazon Mexico offers only English + Español). PADI's audience is a global diving community, not a region-first retail base — so should every region offer the full language set, or should specific languages map to specific regions? We need PADI's call on this before locking the selector's behavior.
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.
An earlier requirements document had called for a user's location to persist as a saved preference — conflicting with the direction above. Kristina's team confirmed: region is never stored as a preference, always auto-detected via geo-IP. Only language persists, and only for authenticated users, in their profile.
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 config for which features are on/off per region, device, and platform — the kind of thing that would let PADI turn on the AWARE banner in China without a full release cycle. No such registry exists today, and it isn't shown as a solved component above. Axelerant will investigate further to evaluate whether it's feasible for November or belongs in a later phase — tracked in Open Questions.
Country-code domains, confirmed — not slugs.
This flipped on the July 24 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 — signed off
| 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) |
SEO sign-off is now confirmed in place, reaffirmed at the July 30 architecture readout — country-code domains are the locked target, not slug-based URLs.
Every country PADI operates in is now mapped to a region (EMEA / Americas / Asia Pacific) — that piece is complete. Kristina is now working through which countries PADI actually has a presence in (dive center footprint), target Friday. The header/footer selector design has also been looped in with PADI's design team to account for region, not just language.
.bg, .cn, .fr, .de domains are being stood up now — but what renders on them before PADI has fully entered that market? Static placeholder content, or a temporary redirect to the nearest active region? No rush on this one; the hybrid architecture supports swapping regions in later without rework.
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 |
Confirmed at the July 30 readout: the November baseline is 13–14 languages (UK English is now a required add, likely making it 14 — Vivek to confirm the exact count and publish it here). Target: scale to 29–30 languages by February, which is what the mobile app already supports today (~28 languages) — course-level language coverage within the app varies per course and is tracked as a separate line item. Kristina's stated preference remains firmer than "eventually": she wants the language 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. Content governance, translation validation, and downstream communication of this standardization are still being worked through — see Section 07.
See the confirmed baseline as presented in the readout →
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 required for November at the July 30 readout — en-GB ships as its own locale, distinct from en-US (spelling: colour vs. color, etc.). Both Crowdin and Drupal support this natively.
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
- Country-code domains —
.cn,.fr,.de,.bg— signed off, SEO-confirmed; regions will not fold into .com - Americas, EMEA, and Asia Pacific (Korea, Taiwan, China) regional homepages — Japan excluded
Language baseline & quality gate
- ~13–14 languages as the unified baseline — UK English (en-GB) now confirmed required for November
- Russian removed site-wide
- Target: scale to 29–30 languages by February, matching the mobile app's current ~28-language support
- Content-only regional variation (show/hide components); no full layout variants
- Localization completeness gate — Missing / Stale / Complete — enforced at Drupal publish and in CI/CD
Device intelligence / fingerprinting
- Data capture confirmed non-negotiable by PADI — needed as a conversion-reporting attribute for the board, a more reliable unit than session
- Device ID attaches to an anonymous profile, then links to the user post-login; storage and data-flow approach still to be aligned with PADI technology
- Whether this can power localization specifically for November remains open and tight, pending the capabilities document; terms of use sits under Account Creation and Preferences, not localization
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
- Runs its own regionalized stack (ASP, static DSL) that's never been migrated; feature parity needs assessing before any future move to the shared platform
- Why
.co.jprather than.jpcame up as its own SEO question — likely historical (Japan previously owned its own site before the domain transferred); Aref confirming
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; converges with the unified payments and cards workstream
- Cards, payments, and market-specific payment methods (e.g., Apple Pay / Google Pay by device) — separate stream with product owners
- Feature Registry — central per-region/device/platform feature toggling, raised by Kristina. PADI (Charles confirmed) already uses LaunchDarkly for feature flags on some properties; known cost and prior challenges noted, so Axelerant is also exploring alternatives — deeper solutioning conversation planned next week
- Enterprise DAM integration across all properties — DAM itself kicks off for November for PADI Blog and assets; broader cross-property integration is later
What's still open, following the July 30 architecture readout.
The July 24 call resolved the region-persistence conflict and the URL/domain model. Seven items remain.
All languages everywhere, or region-specific mappings?
Flagged in Section 01 — Amazon restricts by region, but PADI's diver audience is global and travel-driven. Which model fits?
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 — cookies only as a short-term cache — but that raises latency and single-point-of-failure questions nobody's answered yet. It matters most where users move between web and mobile: someone reading padi.com in French shouldn't open the app and see a different language.
Multi-user shared-device resolution
Raised by Kristina — think a dive center with 50 different users on one shared machine. Cookie-based and even authenticated-preference approaches break down here; no resolution strategy exists yet.
UAT / validation gap for translations
Raised by Kristina — QA doesn't mirror production, so there's no near-production stage to have a human validate translations before they go live, which matters especially for China. Needs a validation process, not just a translation pipeline.
Localization Service / API Gateway
The architecture one-pager shows this as the central hub (Section 03), but the technology and implementation still need solutioning — how it's built, how it's called, how it scales. Axelerant (Bassam, Suraj) is working through this.
Feature Registry — November or later?
Kristina's proposed central config for per-region/device/platform feature toggling (see Section 06). PADI already uses LaunchDarkly for feature flags on some properties — confirmed by Charles — with known cost and prior challenges; Axelerant is exploring alternatives too. Deeper solutioning conversation planned next week.
Definition of Done
November vs. February thresholds, automated vs. manual checks, and security posture — spans every unification topic, not just localization. Separate session to be scheduled with Ed and Axelerant.
Where things stand after the July 30 readout.
- Finalize and publish the exact language count (Vivek)Confirm 13 or 14 languages for November (including UK English) and publish the final list in this artifact.
- Add per-property downstream impact detail to this document (Vivek)Kristina and Kevin need the delta per property (e.g., which specific languages differ on Pro Blog) without having to hunt across decks — going directly into Section 05.
- Communicate language standardization internally (Kevin, Kristina)Kevin owns telling the marketing team; Kristina owns the product team.
- Country-to-operation mapping (Kristina)Country-to-region mapping is done; now mapping which countries PADI actually has a dive center presence in. Target: Friday.
- Device fingerprinting data flow (Bassam)Align with PADI technology on where the device ID is stored and how it attaches to an anonymous profile, then a logged-in user.
- Feature Registry deep-dive (Bassam, with PADI technology)Follow-up conversation next week on LaunchDarkly vs. alternatives, now that PADI has confirmed existing LaunchDarkly usage on some properties.
- Definition-of-Done session (Ed, Axelerant)To be scheduled — November vs. February thresholds, automated vs. manual checks, and security posture across every unification topic.
- Part 2 readout — unified locator (Vivek)Scheduled for after Kristina's vacation; locator has more system dependencies than initially scoped and needs its own dedicated session.