Linguistic Localization Protocol

Global and cross-provincial expansion fails less often on translation quality and more often on architecture: language, market, currency, and tax get tangled into one variable, and the first edge case — a Quebec customer who prefers English, a checkout step nobody remembered to translate — breaks either the compliance story or the transaction. This protocol is how we structure localization as a systems problem, with Quebec's Charter of the French Language as the concrete regulatory case study, because it's one of the few jurisdictions where the requirement is specific, enforced, and routinely misunderstood by engineering teams building "a translated site."

What Quebec's Charter Actually Requires for Ecommerce

The OQLF (Office québécois de la langue française) treats a website as subject to the Charter whenever it promotes or offers goods or services in Quebec. That covers marketing content and the transactional functionality needed to complete a purchase: product titles, descriptions, and specifications; search, filters, and validation messages; cart, checkout, and payment flows; terms of sale, privacy policy, and warranty text; transactional emails and customer-service forms; and cookie-consent interfaces. The requirement is not "provide a French version somewhere" — it's that the French version contains the same information and is available under conditions at least equivalent to the other language. A French link buried on an otherwise-English page, or a French microsite that's missing half the catalog, does not satisfy it.

A frequently misapplied detail: the "markedly predominant" rule — French occupying at least twice the visual space of other-language text in the same field — governs public signage, posters, and commercial advertising under the regulation effective June 1, 2025. It is not the general test for product pages or checkout copy. For ordinary ecommerce content, the operative bar is completeness and equivalence, not visual proportion.

The June 1, 2025 changes primarily affected product-level trademark rules: a recognized trademark may appear in a non-French language on a product only if no French-registered version of that trademark exists, and any generic or descriptive term embedded in it must still appear in French on the product or its permanent packaging. This is narrower than it's often reported — it's a labeling exception, not a general website carve-out, and it doesn't touch product description copy on the page itself.

Penalties under the Charter run roughly $3,000–$30,000 per offense for a legal entity (higher for repeat offenses, with statutory doubling/tripling provisions), separate from the reputational and conversion cost of an incomplete French experience for a market that notices. This is a compliance overview, not legal advice — a Quebec-facing catalog of any real size should get counsel review on trademark treatment and checkout copy specifically.

Architecture: Separate Language, Market, and Currency as Distinct Variables

The single most common engineering mistake in cross-border commerce is conflating "which language is displayed" with "which market, currency, and tax rules apply." They're independent dimensions:

Locale:    fr-CA | en-CA
Market:    CA-QC | CA-ON
Currency:  CAD
TaxProfile: ca-qc | ca-on

A French-speaking shopper can browse in English; an English speaker can be billing from Quebec. The browser's Accept-Language header or a saved locale preference should never be used to infer tax jurisdiction or currency — those get resolved server-side from the shipping/billing destination at checkout, and the tax decision gets calculated and persisted on the server, not recomputed client-side on a whim.

Headless i18n, structurally

• Locale in the URL, not just a cookie. /fr-ca/produits/... and /en-ca/products/... — indexable, shareable, and explicit for both users and crawlers. Domain-based routing works too, but for a single-country, dual-language market like Canada, a subpath strategy keeps one deployment, one analytics property, and shared domain authority.
• Translation status as a field, not an afterthought. Every localized product record needs a translationStatus and review metadata. Untranslated content under a French URL should return a deliberate fallback or noindex — never silently render English under a /fr-ca/ path, which is both an SEO problem and, for Quebec traffic specifically, a compliance one.
• Classify every string before translating it. Brand/trademark, product name, generic term, technical spec, safety/legal text, and user-generated content each get different translation treatment — SKUs, model numbers, and registered trademarks generally should not be auto-translated at all.

hreflang: Correctness Over Cleverness

hreflang tells search engines which localized page to serve for which language/region — it does not create legal compliance, and a French URL with English content behind it can still violate the Charter even if hreflang is implemented perfectly. The mechanics that matter:

• Every localized page emits a self-referencing tag plus reciprocal alternates for every other locale — Google ignores non-reciprocal annotations.
• Use region-specific codes (fr-CA, en-CA) rather than generic fr, which is ambiguous between France and Quebec French and can misroute traffic or dilute the wrong regional signal.
• x-default is a fallback for unmatched locales, not a substitute for a properly built fr-CA page.
• Test the rendered HTML output, not just server config or React source — a common failure mode is correct-looking route logic that never actually emits the tag into the response.

Currency and Tax: Server-Side, Always

Money handling belongs entirely on the server, keyed to a MarketContext object (locale, country, province, currency, tax profile, customer type) that's reused identically across pricing, cart calculation, tax quoting, payment intent creation, checkout copy, and order confirmation — one context, one source of truth, no drift between what the cart shows and what the invoice says. Store amounts as integer minor units with an explicit ISO currency code; floating-point arithmetic on money is still a live bug source in commerce systems that should have retired it a decade ago. Quebec sales tax (QST) logic should be modeled separately from GST/HST, and shipping labels, delivery estimates, and carrier-returned service names need translation even when the carrier's API only returns them in English.

Performance: Localization Shouldn't Cost You Core Web Vitals

Translation libraries and locale-detection middleware are common, overlooked sources of hydration delay and layout shift. The pattern that holds performance steady: resolve locale server-side (from the URL segment, not client-side JS), load only the active locale's dictionary rather than shipping every language to every visitor, and keep locale-aware structured data (JSON-LD offers, priceCurrency, availability) generated server-side from the same MarketContext used for pricing — one computation, reused everywhere, instead of a client-side reconciliation step that adds work after first paint.

Localization done as an architecture — not a translation layer bolted onto an English-first site — is what lets a brand expand into Quebec, or any other regulated linguistic market, without every new locale becoming a fresh source of compliance risk and page-speed regression.