How to use it
- 01
Name the readers
Say who each language is for and which audience matters most. That answer decides which pages must exist in both languages on launch day and which can wait.
- 02
Go through the page list
Mark each kind of page as both, later or one only. Include the invisible ones: emails, error messages and legal text are where a second language is most often forgotten.
- 03
Assign three people
A writer, a reviewer and someone who approves later changes. If you cannot name the third, plan fewer pages in both languages, because unowned translations go stale.
- 04
Record the wording rules
Choose the tone and list the terms that must stay fixed. Giving these to the writer at the start costs minutes and avoids a round of corrections.
What a two-language content plan decides
Translation is the smallest part of running a site in two languages. The plan has to settle what exists, who looks after it and what the build must support, before design begins.
| Part | What it settles | Why it matters |
|---|---|---|
| Languages | Which two, for which readers, at which addresses | Sets priorities and the structure of the site |
| Pages | What exists in both, later or one language only | Defines the real size of the content work |
| People | Writer, reviewer, approver and the update routine | Decides whether the two versions stay level |
| Wording | Tone, fixed terms and numerals | Keeps the second language consistent from the first page |
| Design and system | Direction, content system support and search settings | Tells the designer and developer what to build for |
A worked example
An engineering consultancy adds Arabic
The example is an invented consultancy preparing for public tenders. Load it to see the plan. It keeps the Arabic site smaller than the English one on purpose, and says so.
- PagesCore pages, forms, legal text and every automatic message are planned in both. Case studies follow later, and the blog and careers stay in English.
- PeopleA technical writer, an engineer as reviewer and one approver for changes. Arabic follows English within days.
- SystemRight to left is needed and the content system needs setting up for a second language, which goes into the build scope.
The plan is honest about capacity. An Arabic site of fewer, well-kept pages serves tender evaluators better than a complete one that falls out of date.
What this tool does not do
The planner organizes decisions about content. It does not write or translate anything.
- It does not judge translation quality. A native reviewer does that.
- It does not check legal requirements on language in the countries you sell to. Ask a legal adviser.
- It gives no estimate, since effort depends on the number of pages and the state of the design.
- Everything you enter stays in this browser until you export it.
What to do with the finished document
Give the plan to your writer and to whoever is building the site, and ask both what it leaves unclear. If you would like us to look at it, send it with a link to your current website. Send it through the contact page or book a 30-minute call and bring it along.
Common questions
Do all pages need to exist in both languages?
No. Each audience should be able to learn what you offer, contact you and read the legal terms in its own language. Beyond that, plan what you can keep current. A smaller second-language site that is accurate serves readers better than a full copy that slips out of date, as long as nothing essential is missing.
Why does the planner include emails and error messages?
Because they are part of the experience and are forgotten more than any page. A visitor who fills in an Arabic form and receives an English confirmation, or sees an English error message, concludes that the site was not really made for them. Listing these items early gets them written and built.
Can the same person write and approve the second language?
For a small site that may be unavoidable, though a second native reader catches errors the writer cannot see. The more important separation is between launch and upkeep: someone must be responsible for approving changes after launch, so that an edit to the first language always raises the question of the second.
What if our content system does not support two languages?
Then choosing or configuring one that does becomes part of the project. It should hold each page in each language, link the versions, show right-to-left text correctly where needed and tell editors which translations are missing or older than their originals. Ask for this to be demonstrated with real text.