Next.js in Canada
Next.js development services for Canadian companies
A Next.js development company working with Canadian teams. Quebec is why this page exists: Law 25 and the French-language rules make i18n an architectural decision, not a feature.
Canada is the market where an architectural decision most often turns out to have been a legal one. The decision is i18n, and the reason is Quebec.
French is not a feature flag
Quebec's language legislation requires French to be at least as prominent as any other language for commercial material directed at consumers there. Read that as an engineering requirement and it rules out the pattern most teams reach for first: build in English, add a translation layer later, serve French from a subpath that has fewer pages and stale content.
An architecture that satisfies the requirement looks different from the start:
- Both languages are first-class routes, not a default and a fallback. Next.js supports this cleanly, but only if the routing is set up that way before the content model hardens.
- Content parity is enforced, not hoped for. If a page exists in one language and not the other, something should fail in CI rather than ship. We build that check into the content pipeline because the alternative is discovering the gap from a complaint.
- The alternate tags are generated from what exists, never hand-written. A hand-maintained hreflang cluster is wrong within two sprints - always, and for the same reason every time.
The retrofit is expensive. Doing it at the start costs a design conversation.
Law 25, and why it reaches the front end
Quebec's private-sector privacy reform brought in consent requirements, breach reporting, and a data portability right, on a schedule that ran ahead of the rest of the country. Federally, PIPEDA still applies. For a web build the consequences are concrete rather than abstract:
Consent has to be specific. A single blanket acceptance covering analytics, advertising and personalisation is the pattern being moved away from. Separating those in the UI means separating them in the code, which means your third-party scripts need individual load conditions rather than one boolean.
Portability has to be buildable. A right to receive your data in a usable format is only cheap if someone thought about it while designing the schema. Bolted on afterwards it becomes a quarter of engineering time.
Where we come in
Canadian engagements usually start as one of two conversations. Either there is an English site that now needs to be credibly bilingual, which is a migration with an i18n architecture underneath it. Or there is a new build where getting the routing right first is the whole point - application development, with the language model decided in week one rather than month six.
Either way the honest first step is an audit: two weeks, fixed price, and a written answer to what the retrofit would actually cost.