A multilingual website brief helps a Kenyan business decide which pages need translation, who approves the wording and how customers move between languages. It is useful when you serve people who need different languages to understand a service, rather than simply wanting a language button as decoration. Before commissioning web development in Kenya, describe those journeys and the people responsible for maintaining them.
This guide focuses on preparing the content and approval plan. It is not another website pricing guide or a promise that translation automatically increases search traffic. Bring the completed brief to your website development team so language support becomes a defined part of the build rather than an unfinished addition after launch.
Start with the customer task, not a language count
Identify who needs another language and what they are trying to accomplish. A visitor researching a professional service may need a clear explanation before making an enquiry. A returning customer may need support instructions. Those are different journeys, and they do not necessarily require translating every historical announcement on the website.
Write one sentence for each priority audience: the language they prefer, the information they need and the action they should be able to complete. Avoid claiming an audience exists solely because a language is widely spoken. Use genuine customer questions, existing enquiry patterns or an agreed expansion plan to justify the scope.
An illustrative brief might prioritise a service overview, eligibility explanation and contact journey in English and Kiswahili. That is a planning example, not a recommendation that every business needs those exact languages. Your own readers and review capacity should decide the selection. A smaller, maintained journey is more useful than many partially translated pages.
Build a page and language inventory
Create a worksheet with one row per page. Record its purpose, existing address, proposed language versions, content owner, translation status and approver. Mark whether the page is essential for launch, can follow later or should remain in its original language. Include navigation labels and important interface messages as separate items rather than assuming they are covered by the page text.
Check the complete journey behind each button. A translated service page leading to an untranslated form, error message and confirmation can leave visitors uncertain about what happened. Include form labels, validation, success states and any acknowledgement that the customer receives. The same applies to downloadable brochures linked from the page.
Keep original material identifiable while the site is being developed. Label the approved source version and record when it was last reviewed. If sales changes the service description during translation, the reviewer should know which version they are approving. Otherwise the website can launch with two languages describing different offers without anyone intending that difference.
Agree terminology before translating long pages
Prepare a short glossary for product names, technical phrases, service labels and brand expressions. Decide what should remain unchanged and what should be explained in the reader's language. A company name is different from a descriptive heading, and a customer-facing term may need clearer wording than an internal operations label.
Ask a competent reviewer to assess meaning and tone, especially for promises, exclusions and instructions. Translation software can assist a workflow, but business approval should not depend on the fact that a tool produced a fluent sentence. The reviewer needs enough context to recognise when an accurate-looking phrase describes the wrong service.
Give translators clean source material. Remove obsolete prices, draft claims and contradictory instructions before the work starts. Keep questions for the business in a separate review list rather than hiding them inside the final copy. This avoids treating translation as a way to resolve decisions that the company has not actually made.
Define how the language switch should behave
Describe what a visitor expects when choosing another language. If a corresponding page exists, decide whether the switch opens that equivalent page. If it does not exist, agree a helpful explanation or destination. Do not silently imply that the entire website is available in a language when only one page has been prepared.
Keep the choice easy to find on a phone and readable without relying on flags alone. A flag identifies a country more readily than a language, while a language can serve people in several countries. Use language names your visitors can recognise and test the selector with the intended audience where practical.
Also consider links shared outside the site. If someone sends a translated service-page address to a colleague, the recipient should be able to use that version directly. Ask the developer how the proposed address structure supports this requirement and how a customer can change language without losing their place in the journey.
Include search requirements without promising rankings
Google's guidance on localized page versions describes how alternate language or regional pages can be indicated using hreflang. Ask the developer to document which pages are equivalents and how that relationship will be implemented and checked. A language selector alone does not describe the complete technical scope.
Have the content reviewer approve translated titles, summaries and visible headings as well as body text. These should accurately describe the page in its chosen language. Do not produce mechanical location variants or repeat keywords merely to create more addresses. Every indexed version should have a clear purpose for the people expected to read it.
For an existing website, retain a map of current addresses and any proposed replacements. Language expansion should not accidentally remove useful pages or leave existing links broken. Coordinate that work with the broader website handover checklist, including who controls the domain, content and ongoing maintenance.
Test long wording, forms and mobile layouts
Translation can change the space needed by a heading or button. Review the real translated text inside the layout rather than accepting a demonstration with short placeholder words. Check menus, cards, confirmation messages and narrow screens. The goal is readable content and clear actions, not forcing every translation into the dimensions of the original sentence.
Use a simple acceptance record: page, language, device, task, expected result, observed result and owner of any correction. Include an incomplete form submission and an unavailable page so error messages are reviewed too. A polished opening screen is insufficient if the visitor cannot finish the task in their selected language.
Ask the business reviewer to follow the entire path without help from the developer. They should identify the service, understand important conditions and reach the correct contact route. Record confusing language separately from technical defects so each problem reaches the person able to fix it. Retest the corrected journey before approval.
Plan maintenance before launch
Name the person who updates each language when a service changes. Specify whether translated pages are held for review, temporarily withdrawn or visibly updated together. Leaving the second language untouched indefinitely can create conflicting expectations even when the original launch was carefully checked.
Agree a workable process for small changes. A changed phone number, revised qualification or new downloadable document should enter the same review queue as a full paragraph. Give the editor a checklist of places where the information appears. This is particularly useful when a contact detail is repeated in page text, a footer and a brochure.
Keep a change log containing the source update, translations affected, reviewer and publication date. The log does not need to be complicated. Its purpose is to make unfinished work visible and prevent a team member from assuming that updating one language automatically updates another. Include these responsibilities in the maintenance scope you approve.
Frequently asked questions
Should every page be translated at launch?
Not necessarily. Prioritise complete customer journeys that the business can review and maintain. Record excluded pages and decide how visitors are guided when a translation is unavailable. Do not advertise full language coverage if the approved scope is limited.
Does adding Kiswahili guarantee more Google traffic?
No. Language support should answer an audience need, and search performance depends on many factors. The brief should define useful content and correct implementation. Review actual search and enquiry evidence after launch without treating a translation as a guaranteed ranking improvement.
Who should approve the final translated wording?
Assign a reviewer who understands both the language and the service being described. The business should own promises, conditions and instructions. A developer can implement approved text, but should not be expected to invent service meaning or resolve uncertain commercial statements.
What should I send Mocky before requesting a scope?
Send the existing website, priority languages, page inventory, glossary and names of your reviewers. Include examples of the customer tasks you want to support. Request a website project quote with that material so translation, development and ongoing content responsibilities can be discussed together.
