How to work with freelance translators

Most problems blamed on translator quality are actually setup problems. A capable professional given a bare list of strings, no context and no way to ask questions will produce mediocre work, and you will conclude they were the wrong hire.

This page is about the parts that are within your control.

Freelancers or an agency#

Both work. The trade is coordination versus continuity.

A freelancer you work with directly learns your product. After six months they know your terminology, your tone and which strings are risky. They ask better questions. They cost less per word. You handle finding them, contracting, briefing, scheduling and chasing — multiplied by every language.

An agency absorbs all of that, guarantees availability, and handles languages you have no way to source yourself. They cost more, and they typically rotate translators, so product knowledge accumulates in their process rather than in a person — if it accumulates at all.

A common and sensible split: freelancers for your two or three primary markets where quality matters most, an agency for the long tail.

The thing to check in either case is continuity. Ask an agency directly whether you get the same translators over time. It changes the value considerably.

Finding them#

The signal you want is someone who translates software, not someone who translates. These are different skills — software translation means working with placeholders, character limits, fragments without sentences around them, and a tolerance for ambiguity that document translation does not require.

Ask candidates:

• Which localization tools have you worked in? Familiarity with any TMS means the workflow will not be the obstacle.
• What do you do when a string is ambiguous? The answer you want is “ask”. An answer describing how they infer from the key name is a warning.
• Have you worked with placeholders and plural forms? If the question needs explaining, they will learn on your product.

Pay for a small paid test, on real strings from your product, including a few deliberately ambiguous ones. What you are looking for is not just the translation quality — it is whether they flagged the ambiguous ones. That single behaviour predicts most of the value you will get.

Briefing#

The brief is where most of the outcome is determined, and it is usually a paragraph in an email.

A useful one covers:

• What the product does, in a few sentences. Astonishingly often omitted.
• Who the users are. Consumers or professionals; the register follows from this.
• Tone and formality. Formal or informal address, decided once. Every language with a T–V distinction needs this answered.
• The term base, including the terms that must never be translated.
• What to do when stuck — where to ask, and the expectation that asking is welcome rather than a nuisance.
• Constraints — character limits, placeholder rules, and that markup must survive.

Then give them access to the product. A translator who has used the thing they are translating produces noticeably better work, and a free account costs you nothing.

Access and permissions#

Grant the narrowest role that lets them work without waiting on you. Blocking a translator on a permission is a slow, silent cost.

WebTranslateIt’s roles map onto this directly:

The pattern that works for a team of freelancers is one Language Coordinator per language, with Translators under them if the volume needs more than one person. The coordinator becomes the person accountable for that language’s quality, which is the thing you actually want and cannot get by supervising a language you do not read.

For an ongoing team across several projects, group people into a team and assign the team to projects, rather than adding individuals to each project. It makes onboarding and offboarding a single action, which matters more than it sounds when someone leaves.

Paying#

Rate structure. Per source word is the norm for volume. Hourly suits review, proofreading and small ad-hoc work. Per-string pricing exists and tends to penalise short strings, which is most of a UI.

Translation memory discounts. Standard practice is a sliding scale — full rate for new text, reduced for fuzzy matches, token or nothing for exact matches. Agree it in writing before the first invoice. Nearly every dispute here comes from the topic never having been raised.

Minimum charges. A translator asked to handle eleven new strings on a Tuesday is spending more time on context-switching than translating. A sensible minimum per batch, or batching work weekly, prevents this being a recurring irritation.

Pay promptly. Freelancers talk to each other, and reliability is a real competitive advantage in a market where it is not the norm.

Judging quality without speaking the language#

You cannot assess it directly. You can build a process that surfaces problems:

Separate review for the first batches. A second translator reviewing the first few thousand words tells you a great deal — about the translation and about whether your brief was adequate. Taper once it is consistently clean.

Mechanical validation. Localization QA catches placeholders, plural categories and length. These are the errors that break the product, and they are not judgement calls.

Watch the questions. A translator who asks nothing is guessing. A translator asking two or three good questions per batch is doing the job properly. This is the most reliable signal available to a manager who does not read the language.

Ask a native-speaking user or colleague to spend twenty minutes in the app. Not a formal review — just “does this read like a product or like a translation?” It catches tone problems no checklist finds.

Track rework. Rising correction volume is a signal. Whether it points at the translator, at your source copy or at a terminology change is the question to ask next.

Keeping them#

Good software translators are scarce, and the cost of replacing one is higher than it looks — the product knowledge goes with them.

Answer questions quickly; a blocked translator is idle and paid. Give steady work rather than unpredictable bursts. Send feedback in both directions, including when something was done well. Tell them what changed in the product before they discover it in the strings. And when a reviewer overrides their choice, explain why — silent corrections are how you lose someone competent.

Scaling past one translator per language#

At some point one language needs two people, and the coordination problem changes shape.

The instinct is to split by file. It is the wrong split — the same terminology appears across files, and two people working from different files diverge without ever seeing each other’s work.

Better splits, in rough order of preference:

By feature area, with a shared term base. Two translators working on different parts of the product still pull from one vocabulary, and the translation memory surfaces each other’s decisions automatically.

Translator plus proofreader. One writes, one reviews. Slower per word and noticeably more consistent, which is the right trade for a small, high-visibility surface.

By content type. Interface strings to the person who knows the product; documentation and help content to whoever is available. The skills genuinely differ.

Whichever split you use, keep one Language Coordinator accountable for the language as a whole. Two peers with equal authority and no tiebreaker produce two styles, and the inconsistency is invisible to you.

The most common mistakes#

• No context. Screenshots and developer comments are the fix, and their absence is the single biggest quality lever most teams have not pulled.
• No term base, so terminology drifts and nobody can say what the right word was.
• Batching too tightly. Eleven strings on a Tuesday, sixteen on a Thursday.
• No named owner per language. Quality has to be somebody’s job.
• Treating questions as friction. They are the mechanism working correctly.
• Sending spreadsheets. Version drift, no memory, no validation, no history.