Preparing business copy for translation starts before choosing the words in another language. A translator can produce fluent sentences and still be left guessing which audience a page addresses, whether a button label is fixed, or whether an example describes a real offer. The source material needs enough context to make those decisions responsibly.
This guide explains how to prepare an English business page for a translation project. It does not translate the page, recommend changing a site’s original language, or promise that one review makes a website fully localized. The workflow is practical editorial guidance. Its examples are fictional, and any product details, contractual wording, or market-specific requirements still need approval from the appropriate owner.
Define what is being translated and for whom
Write down the page’s purpose, intended audience, target language, and relevant market. A language does not identify a single country or customer context. Two audiences using the same language may expect different examples, date formats, or service descriptions. Record what has actually been decided and mark unresolved choices instead of asking the translator to infer them.
Separate translation from broader localization work. Google’s guidance on writing for a global audience distinguishes translating language from adapting material for a particular country, such as changing currencies or units. That distinction helps define a project: translating a service description does not automatically authorize changing the service’s availability, price, or terms.
For a hypothetical booking page, identify whether the assignment includes the explanatory text, calendar labels, confirmation messages, and help links. A polished translation of the main paragraph can still lead into untranslated instructions. List the boundaries so the project owner can decide which surrounding pieces must be included.
Prepare a complete source package
Provide the approved text in a usable format, together with its page location and enough visual context to show how each piece is used. Include headings, captions, link labels, button text, and messages that appear after an action. Do not assume that the longest paragraph is the only content that needs attention.
Keep the source version stable while translation is underway. If the business changes the English page, record exactly what changed and send the relevant update through the agreed process. Otherwise, the translator may work from one version while the reviewer compares another. A date and a clear version label are usually more useful than a filename containing several competing uses of “final.”
Explain the status of examples and quotations. Mark an invented customer scenario as hypothetical. Identify approved quotations that must retain their meaning and attribution. Remove private account details and internal comments that the translation team does not need. Sharing a whole folder is not automatically better than providing a carefully scoped package.
Resolve ambiguous references in the original
Read each sentence as if the reader cannot see the author pointing at the screen. Words such as “this,” “it,” and “the above” can become unclear when several items are nearby or the layout changes. Name the relevant item when the reference would otherwise require guesswork. Clarity in the source is preferable to expecting a translator to repair uncertainty silently.
For example, “After reviewing the request and the file, send it to the manager” leaves the object of “it” uncertain. Decide whether the manager needs the request, the file, or both. The corrected sentence should reflect the actual process. Do not resolve ambiguity by inventing an operational step that nobody has approved.
Also separate instructions that contain several decisions. A long sentence combining eligibility, an exception, and a next action may be difficult to review in any language. Give each condition a clear relationship to the action it controls. Preserve necessary qualifications rather than shortening the text until the business meaning changes.
Provide context for short labels
Short interface words are not necessarily simple translation tasks. “Open” can describe a status or an action. “Draft” can name a document state or a preliminary version. Provide the surrounding sentence, the control type, and the result of using it. A screenshot can help, but should accompany readable source text rather than replace it.
Create a small context note for repeated terms that have a specific business meaning. Identify product names, package names, and terms that should remain unchanged. Explain abbreviations at first use in the source or in the project notes. Your existing editorial style sheet can supply approved terminology, but the translator may still need language-specific decisions.
Do not force a translated label to match the English character count simply because the original fits a button. Give the designer an opportunity to review the available space. If a shorter alternative is needed, have it reviewed for meaning. An attractive control that says the wrong thing is not a successful translation.
Identify market-dependent details without changing them
Flag currencies, measurements, addresses, phone formats, dates, opening hours, and references to seasons or holidays. These details may require a market-specific decision rather than a literal translation. Record the question and its owner. Do not independently convert a price, replace a support number, or imply that a service operates in a new region.
A date such as “03/04” is a useful example of avoidable ambiguity in source material. Confirm the intended date, then provide it unambiguously for the translation team. Similarly, “tomorrow morning” in a permanent help page needs context that a translator cannot supply reliably. The source author should decide whether a specific date, a time zone, or a relative instruction is appropriate.
Keep these decisions separate from technical website changes. A writer can identify a question about text direction or language navigation without being authorized to change the site’s configuration. Escalate the requirement to the responsible implementer and retain a record of the intended outcome.
Review images and the surrounding experience
Look for text embedded inside screenshots, diagrams, or downloadable images. If the words need translation, provide editable source assets when available and within the approved sharing scope. A caption explaining an English diagram may not serve the same purpose as a diagram whose labels are readable to the target audience.
The W3C internationalization quick tips highlight language declarations, local formats, translatable images, and navigation to localized pages. They are starting points, not a complete implementation checklist. For an editorial handoff, identify these dependencies so the technical reviewer can test the finished experience instead of reviewing text in isolation.
Check examples for assumptions that may not fit the intended audience. A fictional scenario tied to a particular school calendar or seasonal event may need review. Avoid replacing it with a stereotype about the target market. Ask for a suitable, approved example or use a more broadly understandable situation.
Review the translated page in context
Plan for a qualified language reviewer to assess meaning, tone, and terminology, and for the responsible website reviewer to inspect the rendered page. These are related but different jobs. A person who can test a link may not be able to judge the translation, while a fluent reviewer may not see a layout problem in a text document.
Ask the reviewers to follow one realistic customer task through the page and its next step. Check the displayed labels, links, image text, and any messages encountered along the way. Record corrections against the exact source version. The aim is not merely to replace English words, but to give the translation team a clear, accurate starting point and verify the result where customers will use it.