E-commerce
June 30, 2026
Your help center exists in French. You activate German on Shopify Markets. Six weeks later, the German return page still quotes an obsolete 30-day period that has changed since the French policy redesign. The bot answers in German with an incorrect rule.
HappySupport warns that expanding into too many languages without local freshness creates more tickets than a well-maintained monolingual help system: a language should only be enabled if it represents at least 5% of turnover or a credible plan to get there within 12 months (HappySupport, multilingual help center 2026).
This guide #268 addresses the multilingual structuring of support answers: taxonomy, content tiers, translation workflow, outdated content reporting. Distinct from bot localization (#267) (tone-of-voice on the fly) and catalog maintenance (#140) (SKU sync).
Summary
Why structure a multilingual database before translating?
A multilingual answer base is not a folder of pages translated in parallel. It is a system: source language, local versions, owners, freshness statuses, and metadata usable by agents and bots.
Three Classic Failures
One-shot translation: DE launch, never reviewed
Orphaned pages: FR article updated, DE forgotten
Inconsistent bot chunks: Indexed FR policy, ES answer
Support Impact
eDesk notes that most AI support failures come from scattered, contradictory, or outdated sources, not from the model (eDesk, eCommerce AI base 2026).
DTC Example
Fashion brand, 4 help center languages. Before tiers + stale flag: 31% tickets "contradictory site vs email info". After workflow #268: −44%, DE self-service deflection +22 pts.
How does it differ from neighboring guides?
Five pieces of content, five questions.
Bot localization (#267)
Bot localization (#267): tone and prompts upon response. The #268: multilingual article architecture upstream.
Multilingual bot (#16)
Multilingual bot (#16): when to automate. The #268: what content to feed the bot per language.
General KB structure
KB structure: monolingual taxonomy. The #268: local layer by market and language.
Catalog maintenance (#140)
Catalog maintenance (#140): Shopify SKU drift. The #268: translation parity when policy changes.
International support (#100)
International (#100): global customer service ops. The #268: help center and corpus structured by locale.
How to choose the source language and priority languages?
The KB source language is the one in which you write and validate before any translation.
Selection criteria
Team language: native or near-native writing
Master policy: legal validated in this language
Main revenue: often FR or EN depending on the brand
Language opening rule
Open a help center locale if: market revenue ≥ 5%, or documented 12-month plan, or language ticket volume > 8% of total support. Below that, ticket-by-ticket assisted MT is often sufficient. Specialized documentation guides recommend not treating all pages the same: prioritize by tier and traffic (2026 multilingual KB guide).
Decision matrix
Columns: language, revenue %, tickets/month, existing help pages, named owner, status (pilot / live / frozen). Maximum of 3 live languages as long as parity stale < 10%.
What taxonomy for categories × languages × markets?
The multilingual KB taxonomy aligns customer navigation, internal tags, and bot chunks.
Recommended levels
Category: Order, Delivery, Return, Product, Account, Payment
Sub-category: WISMO, country delivery time, return portal, size, VAT
Locale: fr-FR, de-DE, en-GB, es-ES (BCP 47)
Market overlay: specific UK vs EU rule if policies diverge
Stable identifiers
Each article carries an invariant kb_id (e.g., KB-RET-001). DE/ES/EN versions share the same kb_id. The bot retrieves by kb_id + locale, not by URL alone.
Shopify Markets
Shopify policy pages translated via Translate & Adapt feed the help center, but detailed CS articles still need to be structured in your help CMS (Shopify Translate & Adapt).
What is the T1, T2, and T3 tier system per item?
The three-tier multilingual content system avoids translating 200 pages with the same level of rigor.
Tier 1 (mission-critical)
Returns, refunds, legal warranty
Delivery times by export zone
Order tracking portal, account access
Top 10 N-1 ticket questions by language
Professional translation + native proofreading + updated within 48 hours if the source changes.
Tier 2 (frequent use)
Size guides, product care, payment, exchange. Assisted MT + 20% sample proofreading. Quarterly review.
Tier 3 (long tail)
Niche articles, old release notes. Can remain in source language with auto-summary, or translation on-demand if search traffic > threshold.
Mandatory tag
tier field on each kb_id. Dashboard: % T1 stale by locale.
Which KB-MULTI-* article template and which metadata?
Six multilingual article templates cover 90% of DTC customer service needs.
KB-MULTI-POLICY-01 (policy)
2-line summary + numbered conditions + exceptions + portal link + effective date. Metadata: market[], tier=T1, review_cycle=30d.
KB-MULTI-HOWTO-01 (procedure)
Numbered steps, local UI screenshots, single CTA. 1 goal per article.
KB-MULTI-PRODUCT-01 (product sheet)
SKU, compatibility, maintenance, local PDP link. Shopify metafield sync.
KB-MULTI-TROUBLE-01 (troubleshooting)
Symptom → cause → action → escalation. Chunkable for RAG.
Common metadata fields
kb_id, locale, tier, source_version, status (draft/review/live/stale), owner, last_reviewed, market[], search_terms[] per language.
Local search terms
The DE customer searches for "Rücksendung", not "return". Fill in native search_terms for help search and bot retrieval.
How to organize Shopify URLs, hreflang, and pages?
The multilingual URL structure helps SEO, self-service, and bot indexing.
Common Patterns
Subfolder: /fr/aide/retours, /de/hilfe/rucksendung
Subdomain: help.de.brand.com (less common for DTC)
Parameter: ?lang=de (not recommended for SEO)
Hreflang and switcher
One crawlable URL per locale, cross-referenced hreflang tags, visible language switcher on the help center. knowledge-base.software points out that without separate URLs, analytics by language becomes inaccurate (Knowledge Base Software, multilingual guide).
Shopify Alignment
Markets policy pages = legal source. Help articles = educational layer. Bidirectional cross-linking policy ↔ return how-to article.
What is the source → local → publishing translation workflow?
The eight-step KB translation workflow prevents ghost versions.
Identify need or policy change
Draft / update source language article
Support lead validation + legal validation if T1
Increment
source_versionAuto-flag all linked locales: status=stale
Translation according to tier (pro / MT+review / deferred)
Native proofreading + locale search_terms
Publish + bot chunks re-indexing within 24 hours
TMS Tools
Lokalise, Crowdin or Smartling for translation memory: reuse past segments when a source paragraph changes partially. HappySupport insists: the stale flag cannot remain manual for more than a quarter.
SLA by tier
T1 stale → live locale within 48 hours. T2 within 7 days. T3 within 30 days or translation freeze.
How to detect outdated content and measure local parity?
Multilingual KB freshness is measured, not felt.
Indicators
Parity index: % of T1 articles locally where source_version = locale_version
Stale backlog: articles flagged > 7 days
Search no-result: help queries per language with no hit
"False site info" ticket: suspected kb_stale tag
Knowledge Freshness Index (KFI)
Score per locale: T1 freshness (60% weight), T2 (30%), average stale→publish delay (10%). Goal: KFI ≥ 85 before opening a 4th language.
30-min weekly ritual
Export stale list. Process top 3 T1 by revenue market. Log in Notion #kb-locale. Fin.ai recommends flagging gaps from the frontline: Slack channel #kb-gap (Fin.ai, AI base).
How to chunk and synchronize the bot corpus by language?
The multilingual RAG corpus indexes by locale, not just by kb_id.
Chunking rules
1 chunk = 1 idea or 1 procedure step
Metadata: kb_id, locale, tier, market[], source_version
No mixed multilingual chunks
Max 500 tokens, overlap 50 tokens
Retrieve bot
Strict filter locale=detected_language then fallback to source language with the mention "automatic translation" if T3 only. Link clean corpus (#103).
Sync publish
Locale article goes live → webhook re-index within 15 min. Stale article → remove locale chunks from index or mark as deprecated. See Markets bot (#157).
How does Qstomy rely on a structured multilingual KB?
Qstomy performs when sources are clean, versioned, and filterable by locale.
Capabilities aligned with KB #268
Ingest help center: chunks by locale + kb_id
Filtered retrieve: client language + Shopify market
Stale guard: ignores chunks with status=stale
Gap report: questions without local chunk
Handoff: kb_id + locale for agent
Encrypted DTC scenario
Skincare brand, FR/EN/DE help, 180 articles of which 42 are T1. Before structuring #268: bot quotes FR policy to DE client (18% policy errors). After kb_id + tiers + stale flag + re-index: policy errors −67%, DE self-service +19 pts, T2 translation writing time −35% via TMS memory.
Explore AI customer support, Shopify, request a demo.
Which playbooks can be deployed in 2 weeks?
Playbook 1: language audit (1 day)
Revenue, tickets, help pages per locale. Decide on 2-3 live languages max. Section 3 matrix.
Playbook 2: kb_id inventory (2 days)
List existing articles, assign kb_id + tier. Migrate top 15 T1 first.
Playbook 3: KB-MULTI templates (1 day)
Deploy 4 section 6 templates in Notion or help CMS. Train writers.
Playbook 4: stale workflow (4 hrs)
Automate stale flag on source_version change. SLA section 8 in Slack #kb-locale.
Playbook 5: pilot T1 translation (3 days)
10 return/delivery articles in DE. Native proofreading. Publish + re-index bot.
Playbook 6: monthly KFI dashboard
Parity index, stale backlog, no-result search. 1 language frozen if KFI < 75. Link to answer quality (#116).
Useful linking
A sustainable multilingual base is not born from a DeepL export. It comes from a clear source language, explicit tiers, stable identifiers, and a workflow that treats translation as continuous maintenance, not a one-off project.
Enzo
June 30, 2026
