Twenty freelance specialists know their field. They need references, style guides and answers to context questions. Twenty-five colleagues want something translated. The work itself sits on a drive and in a spreadsheet only you can read.
Choose what each job deserves
Product descriptions, autumn range
12,400 words · 6 languages
Safety notice, DE market
340 words · DE
Launch campaign copy
2,100 words · FR, ES, IT
UI strings, release 4.2
1,100 words · 6 languages
The reason the queue forms
Three questions arrive on an average Tuesday. None of them are difficult. All three come to you, because you are the only person who can answer them.
Marketing is asking, reasonably, and you cannot answer without opening two systems and a folder. Neither can they, which is why they asked.
Your Italian freelancer needs thirty seconds of context to get it right. The answer exists. It is in an email from March, from an engineer who has since changed teams.
Finance is asking before the budget round. Nothing is wrong with the question. It just takes you two days, because the numbers live in five places and one of them is your memory.
Where are we with the German?
VisibleProgress by file, language and person
What do we call this in German?
ConsistentApproved terminology, visible while they work
What is localization costing us per market?
AnswerableReporting by market, content type and time
Give the work one address. Most questions stop being yours.
The German file has a status. The photograph of the carrier plate exists. The cost per market is recorded in five places. You are the only person who can reach these three answers.
One morning, five decisions
You decide which of the five jobs needs a professional translator, which needs your own reviewer, and which can go out on AI with partial supervision. You make that decision from years of knowing the product and the markets. It happens in your head, and everyone else sees only that the work got sorted.
Twelve thousand words across six languages is seventy-four thousand words of catalogue copy. Most of it comes from memory of the spring range.
Your judgment is deciding which quality tier does not need individual review.
Organized, in one system
OneLanguage is a multilingual content system: one place that holds translation projects, terminology, translation memory, the files and the people working on them. Your colleague opens the project and sees how far German has got, without sending you a message. Your Italian freelancer opens the segment and finds the photograph of the carrier plate attached to it, without emailing you. Finance opens the report and sees what each market cost.
Where are we with this language? | Progress per file, per language and per person, on the project. |
What do we call this in German? Asked by your freelancer, mid-job | Approved terminology, enforced on AI, visible while they work. |
Why is it phrased this way? | Language data: segments, states and the comments around them. |
What did we already agree? Asked by everyone, eventually | Translation memory, applied before anyone starts translation, including AI. |
The trade
Stops needing you
— Status. Anyone with access can see where a language stands without sending you a message.
— Context. Instructions, reference files and approved terms travel with the job instead of living in your sent folder.
— Counting. Volume analysis runs on the project rather than in a spreadsheet you maintain.
— File repair. Tag and placeholder protection is built in, so what comes back opens.
Back in your hands
— Terminology, without asking anyone. Add, change, bulk-clean, hunt duplicates, check a term across every language you run. Talk to your terminology through a connected AI assistant.
— What gets translated. Filters decide which parts of an XML or JSON file are in scope. You set that, not a ticket.
— Your history, imported. Bring existing translation memories and termbases with you. TMX and TBX in, TMX and TBX out.
— Who works on what. Assign the reviewer or translator who knows the product, per language, per package.
The system does the administration. You keep the judgment, and the system records each decision you make.
Twenty freelancers and twenty-five colleagues
A correction made outside the system is a correction you will pay for again, because it never reaches the memory. So the question of who gets access should never be a budget conversation, and on the plan built for this profile, it isn't.
Your bench
No tax on adding people
The freelancer who has translated your manuals since 2019 knows why you stopped using one of the two German words for the carrier plate. No migration plan counts her, and no business case has a line for her.
What finance asks
Your CFO does not ask about fuzzy match rates. She asks what the German market cost this quarter and what it returned. Reporting runs on Power BI: you describe the report you need to show her, and we build that report. You can also ask your AI assistant about projects and data.
What did this quarter cost us, by market? (Next to what those markets returned)
How much of it never had to be paid for twice? (Against your own approved history)
Where is time actually going, translation or waiting? (Per language pair)
How much went out on AI plus internal review, and how much needed a professional? (By content type)
The reporting is built to order, so promising specific dashboards would be a claim we can't keep.
Where the boundary sits
Worth being precise about, because "you'll never need anyone again" is the promise every platform makes and none of them keeps.
Anything that is a judgment about language is a judgment you make, in the interface, without a ticket.
Reporting. Gated quality features. Automatic routing by content type. Connections into your CMS, PIM or repository. Reuse your language data for content creation. You can build with us or have your dev team build on top.
The second column is the one that has grown. It is cheap to start, and the bill arrives later, worth having in writing before the meeting rather than after it.
| Classic TMS | Build it in-house | TextUnited | |
|---|---|---|---|
| Getting everyone inside | A seat, and a conversation about whether they need one | You build the access layer too | Unlimited users on the plan built for this |
| Changing terminology | Often an admin or engineer task | Whatever you built, if you built it | You, in the interface or by prompt |
| Bringing your own vendors | Usually yes | Yes | Yes, at their own rates |
| What is translatable in a file | Filter set up for you | You write and maintain the parser | You choose it yourself |
| Internal and external work | Separate processes | Not usually built | One screen, per job |
| Reporting | Fixed dashboards and CSV export | You build it and keep building it | You describe it, we build it |
| When requirements change | Change request, next release | The last stretch is where the cost lives | Platform work we do with you |
| Your language data if you leave | Usually exportable | Yours | Yours, TMX and TBX out |
Questions
You start by bringing what you already have: translation memories and termbases import as TMX and TBX, so years of accumulated decisions come with you rather than being abandoned. From there the work has one address, files, versions, comments, terminology, people and progress, which is what makes it possible for anyone other than you to answer a question about it.
Yes. You add your existing freelancers and vendors and keep working with the people you already trust, at the rates you already agreed. You can also order from our linguists inside the same project when a language pair has nobody on it.
No, and this is the part most localization managers care about most. Adding terms, changing them, bulk-cleaning, finding duplicates and checking a term for consistency across every language you run are all things you do yourself. You can work in the interface, or connect an AI assistant and ask it to do the same operations.
The plan built for this profile carries unlimited users, so twenty freelancers and twenty-five colleagues from other departments cost the same as a handful of each. This matters more than it looks: a person working outside the system produces decisions that are never kept.
Yes, progress per file, per language and per person sits on the project. Which is less about convenience than about the fact that you are currently the only index your organisation has.
Yes. File filters decide which parts of an XML, JSON or IDML file are in scope and which are left untouched, and you set that when you create the project rather than requesting it from an engineer.
Reporting runs on Power BI. Rather than choosing from fixed dashboards, you tell us what you need to be able to show and that report is built for you. It is not self-service analytics, and we would rather say so than have you discover it in month two.
A prototype that translates a file is genuinely easy now. The distance between that and a system the whole company can work inside is where the cost sits: file structure that survives updates, memory that stays clean, and access for people who are not developers. We are API-first, so the honest answer is that your engineers can build on top of this rather than instead of it.
Yes. Translation history keeps segment translations, their states and the comments attached to them, so a question about why a phrase reads the way it does has an answer that does not depend on anyone's memory.
It belongs to your organisation and leaves with you. Terminology, translation memory and approved wording export in standard formats.
Most teams begin with a free trial on their own content, then a call to set up terminology and the workflows that match how the work actually arrives.
Start with real work
Not a demo dataset. Something that actually landed on your desk this morning.
