A bilingual website has two kinds of work: producing the first translation, and keeping both versions true. The first is a project with an end date. The second has no end date and, without an owner, tends to be done by nobody.
This guide is a handover checklist for the business that will run the site. It assumes no particular content system or maintenance contract. The example is fictional.
Inventory the pages and who each is for
List every page and mark the languages it needs: English, French or both. Then write the reader and purpose of each page, in one line.
Our fictional business is Savannah Highlands Coffee, an exporter selling to buyers in English- and French-speaking markets. Its site has a home page, a product page, an export terms page and a contact page. The terms page matters most to French-speaking buyers and carries delivery and payment rules. The home page carries a promotional offer.
Some pages need both languages, some one. Decide that now, because every page you publish in two languages is a page you must keep true in two languages.
Name one owner for the facts
Choose the person who approves facts, terminology, offers and changes, for every language. At Savannah Highlands that is the commercial manager. She does not need to read French. She decides whether a price, a delivery term or an offer is right, and the French reviewer follows her decision.
If two people can approve the same fact, they will eventually approve different versions. One source of truth, one approver.
Require a French review that checks meaning
A French review is not a line-by-line comparison with the English. The reviewer reads the French as a buyer would and checks:
- Meaning. Does it say the same thing as the approved English, including numbers and conditions?
- Register. Business French for your readers normally uses vous. Does the tone suit them?
- Local context. Terms, units, currencies and legal vocabulary differ by country. A phrase that reads well in one francophone market may confuse in another. State which countries the French page is for.
Machine translation can produce a first draft. It cannot judge whether a payment term is clear to a buyer in a particular market. Treat it as a draft that a human must review.
Assign page-level owners and review triggers
Give every page an owner, a reviewer and a trigger. A trigger is an event that forces a check: a price change, a new product, a policy update, an expiring offer, a change in who answers the phone. Also set a calendar check, say every quarter, for pages that no event touches.
Decide the path for urgent corrections. If a wrong delivery term goes live on the French terms page, who can change it today, whom do they tell, and who confirms it is fixed? Write this down before you need it.
Illustrative image, licensed from Magnific. The code on screen is unrelated to any website discussed here.
Confirm who controls the accounts
Ownership of the site is partly a legal question and partly a login question. In the signed project scope, confirm who controls:
- The domain. Registered in your organisation’s name, with your own contact email.
- Hosting. An account you can access, not only the developer.
- Content-system credentials. At least two named administrators from your side.
- Backups. What is backed up, how often, where it is kept and who can restore it.
- Change approval. Who may approve a change to the live site, and how.
A common failure is that everything works until the developer is unavailable, and the business discovers the domain is in a personal account. Check this on day one.
Know what support covers
“Post-launch support” means different things. Ask for it in writing, separated into:
- Fixing faults, such as a broken form or an expired certificate.
- Content changes, such as updating a price or adding a page.
- Security and software updates.
- Response times for each of these.
Do not assume the maintenance is bundled with the build price, and do not assume it is not. Chwezi’s public pages describe web design and development as a service but do not set a standard maintenance package or ownership terms, so treat ownership, content system and support as items to settle in each brief.
The bilingual content ownership register
Keep this register where the owner can open it. One row per page and language.
| Page and URL | Language | Source owner | French reviewer | Update trigger | Access owner | Backup and support scope | Last approval | Next check |
|---|---|---|---|---|---|---|---|---|
| Export terms, /fr/conditions-export/ | French | Commercial manager | Native French reviewer, export sector | Any change to delivery or payment terms | Operations manager | Backed up weekly; text changes within contract hours | 3 March | 3 June or on term change |
| Home, /en/ | English | Commercial manager | Not applicable | New offer or end of offer | Operations manager | As above | 3 March | End of current offer |
Add a row each time you publish a page. Delete a row only when the page is removed.
What changes by market
Prioritise the readers you actually have. For English, that is East African buyers first, then wider English-speaking Africa, the UK and international buyers. Check how those readers reach the site: on which devices and on what connections, as measured in your own visitor data, not assumed. For the French pages, choose the francophone African countries you serve and confirm their language conventions, your offer there and any legal context before you publish. Google’s guidance on localised versions of pages explains how to link language versions to each other. The W3C’s guide to involving users in web projects is a useful reference when you test pages with real readers, including people with disabilities.
Sources and scope
- Google Search Central, Localized versions of your pages. Implementation guidance, not a ranking guarantee.
- W3C Web Accessibility Initiative, Involving users in web projects for better, easier accessibility. Process guidance; no claim of conformance follows from reading it.
- Chwezi Core Systems, Website development. Public offer description, not evidence of results or a defined maintenance package.
- Savannah Highlands Coffee is fictional. Its pages, roles and dates are invented to show the method.
Common questions
- Who should approve the content: the web agency or the business?
- The business. An agency can build and publish, but only your team knows whether a price, a service description or a policy is correct. Name the approver in the project scope.
- Is machine translation enough for the French version?
- It can produce a first draft. It cannot confirm that a price, a legal term or a tone suits your francophone readers. A French reader who knows your sector should check meaning, register and local context before publishing.
- What accounts must I hold myself?
- At minimum the domain registration, the hosting account and the administrator login for whatever system holds your content, plus access to backups. Check that these are in your organisation's name, not a developer's personal account.
- Does post-launch support include content changes?
- Only if the signed scope says so. Many contracts cover fixing faults but not editing pages. Ask in writing what counts as a fault, what counts as a change and how long each takes.