कैसे एक एकल व्यक्ति की कंटेंट एजेंसी बिना अनुवादक के बहुभाषी साइटें प्रदान करती है
By Robert M
How a one-person content agency delivers multilingual sites without a translator
A client asks if you can deliver their new site in English, French, German, Spanish, and Dutch. You run a one-person shop. You do not have a translation budget baked into your retainer, and you do not have a network of freelance translators on call. But you also do not want to say no to a good project.
This is a situation a lot of small agencies and freelancers end up in. The demand for multilingual sites has grown steadily as more businesses try to reach audiences outside their home market, but the budget conversations have not caught up. Clients often treat translation as a line item they can shrink or cut, without really understanding what it costs to do properly.
This post is about how to handle that gap practically, without compromising on quality or taking a loss on the project.
The old options, and why they fall short
The traditional paths are familiar.
You could hire a freelance translator per language. For a five-language site with thirty pages of content, you are looking at a significant cost before you factor in revision rounds, turnaround time, and the overhead of briefing five different people on the client's tone and terminology. That cost either eats your margin or goes on the client's invoice and suddenly the project is in jeopardy.
You could use a consumer translation tool and clean it up manually. That works for plain sentences, but the moment your content has any structure (a JSON locale file, a Markdown blog post, an HTML page with attributes and tags) the output becomes unpredictable. Keys get translated. Markdown syntax breaks. HTML attributes get mangled. You end up spending more time fixing the output than you saved by not hiring a translator.
You could tell the client multilingual is out of scope and do a single-language site. Sometimes that is the right answer. But it is not always a conversation you want to have.
What actually changed
The thing that made this workflow viable is not AI translation in the abstract. It is format preservation specifically.
The problem with feeding structured content into a general-purpose translation tool was never really the translation quality. Modern machine translation is good. The problem was that the tools did not understand the difference between content and structure. They treated everything as text to be translated, including the parts that should have been left alone.
A locale file like this:
{
"nav": {
"home": "Home",
"about": "About us",
"contact": "Get in touch"
}
}
Would come back with the keys translated, the nesting collapsed, or the whole thing converted to prose. Any of those outcomes means manual cleanup before the file is usable, which is where the time saving evaporates.
An API that treats structure as off-limits changes the economics. You send the file, you get back an identical structure with only the string values changed. Drop the output file straight into the project. No cleanup pass required.
The workflow in practice
Here is how the process looks on an actual project.
At the content stage, everything goes into plain text or Markdown files rather than hardcoded strings. This is good practice anyway for maintainability, but it also means the content is in a format that can be translated cleanly.
At the build stage, a short script reads the source language file, sends it to the PolyLingo API with the list of target languages, and writes one output file per locale. For a site that needs five languages, that is one API call. The script takes a few seconds to run. The output files go straight into the project structure.
At the review stage, the client reviews the translated content. This is a step worth keeping. Machine translation handles most content well, but clients sometimes have preferred terminology, branded phrases, or regional conventions that need a human eye. The review is faster than translating from scratch because the structure is already correct and most of the content is accurate. You are reviewing rather than producing.
At the handoff stage, the site ships with all locale files in place. The language switcher works on day one. There is nothing to follow up on.
What this costs versus hiring translators
The numbers depend on the size of the project, but the structure of the comparison is consistent.
A typical small business site might have around 2,000 words of interface copy and page content. Translated into five languages, that is roughly 10,000 words of output. At a mid-range freelance translation rate, you are looking at several hundred pounds or dollars before revisions.
With PolyLingo, 2,000 words of content across five target languages sits comfortably inside the paid Starter plan at $9 per month, including capacity for multiple projects in the same billing period. The free tier (50,000 tokens per month) covers smaller projects without any cost at all.
The client still does a review pass, which means they are involved in the quality of the output rather than just receiving a bill. That tends to land better in project conversations.
The scope conversation with clients
One shift this workflow enables is changing how you talk about multilingual scope with clients.
Previously, "multilingual" meant "more expensive, longer timeline, dependency on third parties." Now it is closer to a configuration decision. You scope it, you run the script, the client reviews. The hard part is the content strategy and the site architecture, not the translation logistics.
That changes what you can offer. A client who was going to do a single-language launch with a vague plan to add languages later can do all five at launch without the project cost doubling. A client who keeps adding pages can re-run the script whenever content changes rather than going back to a translator with a new brief.
It also changes the conversation about what multilingual actually involves. The agency's job is to build a site with a proper i18n architecture, good copy in the source language, and a review process for the translations. That is a higher-value conversation than "we'll sort out the translations once the English version is done."
Where it still makes sense to use human translators
This is worth being honest about.
For marketing copy that needs to carry genuine emotional weight in the target language, a skilled human translator will produce better output. The difference matters most for campaigns, brand positioning statements, and anything where the phrasing itself is the product.
For highly regulated content (legal, medical, financial) a human translator with domain expertise is the right choice, and often a compliance requirement.
For long-form editorial content where the voice needs to feel native rather than translated, human review is more than a light pass.
The workflow described here is best suited to interface copy, page content, product descriptions, documentation, and marketing sites where accuracy and structural integrity matter more than stylistic nuance. That covers a large share of what a small agency actually ships.
Getting started
PolyLingo's free tier includes 50,000 tokens per month with no credit card required. For a small agency, that covers a meaningful amount of content before you need to think about a paid plan.
The API accepts plain text, Markdown, JSON, and HTML. The no-code translator in the dashboard handles one-off jobs without touching the API at all, which is useful for client review sessions where you want to show translated output without building anything first.