Bilingual website planning for Atlantic Canada: governance, translation workflow and the technical setup
Most bilingual websites in Atlantic Canada are planned as an English site with a French copy attached. The ones that work are planned as one site with two audiences, and the difference is decided in the project plan, not in translation.
A planning problem, not a translation problem
Ask an organization why its French site is behind and the answer is rarely “bad translation.” It is that nobody was assigned to keep it current, the CMS did not show which pages were out of date, the launch schedule did not leave time for review, or the forms and confirmation emails were never in scope. Those are planning failures, and they are set in motion months before launch.
This article is about the planning: how to scope, staff, build and run a bilingual site. It deliberately does not cover the legal side. If you need to understand obligations under New Brunswick’s Official Languages Act, federal requirements, Quebec’s Law 25 or the Charter of the French Language, read Bilingual by default: what the Official Languages Act and Law 25 mean for your digital content first, and confirm the specifics with counsel. Then come back here to work out how to deliver on them.
Decide the language scope explicitly
The first planning decision is how much of the site exists in each language, and it should be made on purpose, in writing.
For public bodies in New Brunswick, and for organizations delivering services on their behalf, the working answer is usually full parity: everything, in both languages, at the same time. For private organizations the decision is more open, and an honest partial scope is better than an accidental one. Options include:
- Full parity. Every page, form, email and document in both languages, published together.
- Core parity. All service, contact and conversion paths in both languages; some secondary content (an older article archive, say) in one.
- Audience-led. A French section built for a specific market, such as Quebec buyers or francophone communities in northern and southeastern New Brunswick, with content written for them rather than mirrored.
Whatever you choose, be consistent and transparent. A French visitor who clicks the language switcher and lands on an English page with no explanation has been told something about your priorities. If a page is not available in French, say so in French and point to the closest equivalent that is.
An illustrative example: a regional engineering firm with offices in Fredericton and Moncton serves both municipal clients that require French and private developers who mostly work in English. It chooses core parity: all service pages, project case studies for public clients, careers and contact forms in both languages, while its technical blog stays in English with a French summary page. That decision, written down at the start, sets the translation budget, the CMS requirements and the content plan.
Governance: who owns parity
Parity does not maintain itself. It needs an owner and rules.
Roles to assign
- A parity owner accountable for both versions being complete and current. Usually the web or communications lead.
- A French language authority who signs off on French copy: a staff translator, a contracted professional or a qualified francophone reviewer. Not “whoever took French in school.”
- Section owners who know when their content changes and trigger an update in both languages.
Rules to write down
- Publish together or not at all for anything within the parity scope. If one language is not ready, neither goes live, with a defined exception for urgent notices (and a deadline for the second language).
- A parity register: a list of every page and asset in scope, its counterpart and the date each was last updated. Many CMSs can show this; if yours cannot, a shared spreadsheet will.
- A review cadence: each quarter, the parity owner checks the register for pages where one language has been edited and the other has not.
This is the part most organizations skip, and it is the part that decides whether the French site is still equal a year after launch.
Build a translation workflow that fits the schedule
Bilingual projects slip because translation is scheduled as a single step at the end. It should be a stage that runs alongside content production.
- Write for translation. Clear, plain source copy translates better and faster. Idioms, puns and English-only wordplay create work and rarely survive.
- Agree a glossary early. Service names, product names, job titles, place names and recurring phrases, with approved French equivalents. It keeps terminology consistent across translators and over time.
- Translate in batches as pages are approved, not all at once at the end. Each English page that gets sign-off goes straight into translation.
- Review in context. The French reviewer should see the page as it will appear, not a document. Headlines that are too long, buttons that wrap, and labels that read oddly next to an image are only visible on the page.
- Adapt, do not just translate, where the audience differs. Examples, case studies and calls to action aimed at francophone buyers may need to be different, not just in French. Some organizations write key pages in French first for that reason.
Machine translation can speed up first drafts, but nothing should be published without review by your French language authority. Errors in register, terminology and regional usage are visible to the audience even when invisible to an English-speaking editor.
Plan the design for this too. French text often runs longer than English, so layouts, navigation labels and buttons need room to expand. A design approved only with English copy will break in places nobody checked.
The technical setup that keeps versions equal
The technical decisions should be made during planning, because several of them are hard to change later.
- A CMS that links language versions. Each page should know its counterpart, so editors can see when one is out of date and the site can link between them. Test this in a demonstration; choosing a CMS for a growing organization covers what else to check.
- A consistent URL structure. Language folders (/en/ and /fr/) are the simplest to manage and measure for most organizations. Translate the slugs, so a French page has a French address.
- Hreflang on every page, referencing itself and its counterpart, reciprocally, so search engines show the right language to the right searcher. If you have a language selection page, an x-default value can point to it.
- A language switcher that keeps context. It should take the visitor to the equivalent page, not the other homepage. Let visitors choose and remember the choice, rather than forcing a language based on location or browser settings with no way back.
- Everything outside the page: form labels and validation messages, confirmation pages, automated emails, PDFs, cookie and consent banners, error pages, page titles, meta descriptions and structured data. This is where parity most often breaks.
- Search research in French. French-speaking searchers do not type translated English keywords. Research how they actually phrase the need, and write French titles and headings for that.
If you are restructuring an existing site to add or reorganize languages, it is a migration and should be treated as one. The website migration SEO checklist covers redirects and monitoring.
Accessibility in both languages
An accessible English site with an inaccessible French counterpart is not an accessible site. Plan these into the build and the content workflow:
- Declare the language of each page, and mark passages in the other language within a page, so screen readers pronounce the text correctly. WCAG addresses both the language of the page and the language of its parts.
- Translate alt text, captions and transcripts. Videos need captions in each language they are presented in.
- Make documents accessible in both languages. A French PDF that is a scanned image fails a francophone screen reader user just as surely as an English one.
- Test both versions. Automated checks and manual testing should be run on French pages, not only English ones, because longer text and different templates can introduce new issues.
For the standards themselves and how they apply in Canada, see website accessibility and Canadian law.
Measure both audiences
If analytics reports the site as one blended audience, you will not notice when the French experience underperforms. Set up measurement so each language can be read on its own: traffic, conversions and top pages by language, and search performance by language folder in Search Console. Route French inquiries to someone who can respond in French, and track that they do. A French form that produces an English reply three days later is a conversion problem no analytics tool will flag for you.
A planning checklist
- Confirm your obligations with counsel, using the legal overview linked above.
- Decide and document the language scope.
- Name the parity owner, the French language authority and section owners.
- Write the publish-together rule and create the parity register.
- Build a glossary and schedule translation alongside content production.
- Choose a CMS that links language versions, and test it with real tasks.
- Specify URLs, hreflang, the switcher and every off-page element in scope.
- Include French in accessibility testing and in analytics reporting.
Bilingual delivery is part of how we plan every relevant website project in the region, because it shapes the CMS, the schedule and the budget from day one. If you are at the start of a larger rebuild, the website redesign planning guide shows where these decisions fit in the overall sequence.
Key Takeaways
- Bilingual sites fail through planning gaps (no owner, no schedule, no scope for forms and emails), not usually through bad translation.
- Decide the language scope on purpose (full parity, core parity or audience-led) and write it down.
- Assign a parity owner and a French language authority, set a publish-together rule and keep a parity register.
- Run translation alongside content production with a glossary and in-context review, and design for longer French text.
- Plan URLs, hreflang, the language switcher, off-page elements, accessibility and analytics for both languages from the start.
Frequently Asked Questions
Should a bilingual website use separate domains or language folders?
For most organizations, language folders on one domain (such as /en/ and /fr/) are the simplest to manage, measure and maintain. Separate domains can make sense for distinct brands or markets but add cost and complexity. Whatever you choose, apply it consistently and give each page a true counterpart.
How do I keep the French version of my website up to date?
Assign one person to own parity, keep a register of every page and its counterpart with last-updated dates, and adopt a rule that content in scope is published in both languages together. A CMS that links language versions and flags outdated translations makes this much easier.
Can I use machine translation for my French website?
It can help produce first drafts, but publishing without review by a qualified French speaker is risky. Errors in register, terminology and regional usage undermine trust with francophone audiences. Build the review into the publishing workflow so nothing goes live unchecked.
Does a bilingual website need hreflang tags?
Yes. Hreflang tells search engines which language each page is in and where its counterpart is, so French-speaking searchers are shown French pages. Each page should reference itself and its equivalent, and the references must be reciprocal to work.

