Skip to main content
Out of Scope

is producing a second-language version of the deliverable out of scope?

Yes — a second-language or localized version multiplies the deliverable into a new one with its own production, so it falls outside a contract scoped for a single language. The exception is a contract that named multiple language versions from the start.

Why this answer

A localized version isn't a copy of the deliverable — it's another deliverable that happens to share a layout. Producing it means new text that has to be written or adapted rather than translated word-for-word, design that has to flex for different string lengths, and frequently cultural adaptation so the result reads as native rather than converted. Even when the structure stays identical, the content inside it is new, and content is where the work lives. So when a client asks for the deliverable 'in Spanish too,' they're not asking you to duplicate a file; they're commissioning a parallel production that consumes much of the effort the original did. The reason this reads as out of scope is straightforward: a contract priced for one language version priced one set of content. A second language doesn't extend that work — it repeats and re-authors it. The visual shell may be reusable, but the substance has to be made again, and reuse of the frame doesn't make the contents free. Each language is a deliverable, and the contract bought the languages it named.

When the answer flips

The verdict changes when multiple languages were in the agreement from the beginning — if your contract listed language versions, named locales, or scoped the project as multilingual, then producing them is owed and the only question is volume. It also softens slightly if the 'localization' is genuinely trivial: swapping a single tagline a client provides fully translated, with no design or adaptation work, edges toward a courtesy rather than a deliverable. The flip stays firmly Out of Scope for the real case — a deliverable scoped, produced, and accepted in one language, now to be remade in another. The more the request involves actual adaptation rather than placement of client-supplied translation — rewriting for tone, reflowing design for new string lengths, adjusting culturally specific references — the more unmistakably it's a separate commission.

What to do next

Treat each language as its own deliverable and price it that way, while making the expansion feel like a natural extension of a project that's going well. Confirm the original language version is complete, then position the new one clearly: 'The English version is done — a Spanish edition is a separate production, and I can scope it for you.' Decide what the request actually contains, because it changes the price sharply: are you placing a translation the client supplies, or are you adapting and re-authoring the content yourself? Quote accordingly, as standalone work with its own fee and timeline rather than a small markup on the original. If design has to reflow for different text lengths, name that too, since localized layouts rarely drop in cleanly. Use a fresh scope line per language. And going forward, write your deliverables clause to state the language explicitly, because a deliverable described without a named language is what lets a client assume every other language came along for free.

Settled reads your contract and gives you the exact verdict for this situation — try it free →

Frequently asked questions

The layout is identical — I'm just swapping the text. Why isn't that nearly free?+

Because the text is the deliverable, and the layout is only its container. Swapping languages means producing or adapting a whole new set of content, which is most of where the original effort went, even when the frame stays the same. A reused layout saves you the design-from-scratch step, and you can reflect that, but it doesn't touch the cost of the words themselves. The instinct that an identical layout makes a second language cheap mistakes the shell for the substance; the shell was the easy part, and the substance has to be made again.

What if the client gives me the translation already done?+

Then the work shrinks, but it usually doesn't vanish. Placing a client-supplied translation is far lighter than adapting one yourself, and you should price it as the lighter task it is. But even dropped-in translation rarely flows perfectly into an existing layout — different languages run longer or shorter, break differently, and can throw off spacing and hierarchy you'll need to fix. Scope it as a localization-and-layout pass rather than fresh writing, priced below a full adaptation but above zero, and flag any design reflow the new text forces so the client isn't surprised by it.

Isn't translation just a mechanical conversion I shouldn't really charge much for?+

Real localization is closer to rewriting than to converting. Word-for-word translation reads as foreign; making a deliverable feel native means adapting tone, idiom, and culturally specific references so it lands for a new audience the way the original landed for its own. That's authorial work, not mechanical substitution, and it carries authorial value. Even when you're working from a base translation, the adaptation that makes it actually usable is skilled effort. Pricing localization as a cheap conversion undersells both the craft and the result; price it as the parallel production it genuinely is.

They want three languages at once. How do I scope that?+

As three deliverables, with the shared setup reflected once. Each language is its own production of content and its own layout pass, so a three-language request is fundamentally three parallel jobs rather than one job done thrice for free. You can price in the efficiency of doing them together — shared design groundwork, one batched workflow — but the per-language content and adaptation work scales with the count. Quote a base plus a per-language rate so the client sees both the bundle benefit and the honest reality that each additional language is real additional work.

My contract didn't mention language at all. Does that mean any language is included?+

No — silence defaults to the language you actually produced and the client accepted, not to all languages. If the work was briefed, written, and delivered in one language, that's the scope the contract bought, regardless of the clause never naming it. An unstated language can't reasonably be read as 'every language is free.' Honor the version you made, treat additional languages as new deliverables, and remove the ambiguity next time by stating the language explicitly in the deliverables clause so no client can infer a multilingual deal from a contract that simply didn't say.

How do I write contracts so language scope is never in question?+

Name the language of every deliverable, and if multiple languages are part of the deal, list each one as its own scoped item with its own fee. A deliverables clause that says 'landing page copy, English' draws the boundary cleanly, and a multilingual project should read as a set of named language versions rather than a single vague output. The recurring cause of these disputes is a clause that specifies what to produce but never in which language. One added word per deliverable converts 'can I also get it in French' from an assumed freebie into an obvious new-commission conversation.

Related reading

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.

Try it free →Read the scope creep guide