How do you measure linguist productivity?

Last reviewed: October 15, 2026

Which metrics make up a fair measure of linguist productivity?

A fair measure combines four metrics with three normalizing variables, so each number is read in the context that produced it:

• Throughput in weighted words — completed weighted words per linguist, per workflow step type (translation, edit, review, post-edit) and per language for a fixed period. Weighted words already discount translation memory matches, so a linguist working on highly leveraged content is not overstated.
• Post-edit effort (edit distance) — the number of characters or words a linguist changes between the text they received and the text they submitted. For a post-editor it shows how much the machine output needed; for a translator, the edit distance a reviewer applies downstream shows how much of their work was rewritten. Smartling's String Changes Report records Edit Distance, Edit Word Distance and Edit Distance to Publish for each step.
• Rework rate — strings rejected back to a linguist divided by strings that linguist submitted. Rejections are recorded as a REJECT workflow action in the String Changes Report, which turns rework from an anecdote into a count.
• Quality of delivered work — MQM score and error density per 1,000 words from LQA, on the same schema for everyone. How the score itself is calculated is covered in how translation quality scoring works.
• Normalizers, not metrics — fuzzy-match band, Language Quality Estimation level and content type. Compare linguists only inside the same band, language and content type, or the comparison measures the work mix rather than the person.
• Active time, used with care — time spent editing can explain a throughput change, but it penalizes research, terminology queries and careful checking, so treat it as a diagnostic for workload conversations rather than a score.

Where does linguist productivity data live in Smartling?

Eight documented reports and measures supply the raw material for a productivity view:

How do you set up linguist productivity measurement step by step?

Most teams can build a defensible productivity view in five steps, using reports they already have:

1. Define the unit and the segments — Agree that the unit is weighted words per workflow step type, per language, per month, and decide the segments you will never mix: content type, fuzzy-match band and, for machine translation post-editing, Language Quality Estimation level. Writing these down before the first report prevents arguments about the numbers later.
2. Pull throughput by linguist — Run the Word Count Report filtered by Linguist (and by Agency for vendor teams), split by Workflow Step Type and Translation Language, and use the Weighted Words column. The Translation Activity Report adds a per-job CSV with User Name, Agency Name, Language, Word Count Type, Fuzzy Score and Word Count when you need to check a single job.
3. Add effort and rework — Download the String Changes Report for the same period, filtered by user, and sum Edit Distance and REJECT actions per linguist; Account Owners and Project Managers can also filter by workflow step once a single project is selected. To keep a longer history than the report's 6-month window, load the Data Access Tool's Translator Quality Performance - 90 Days dataset, which carries the same edit-distance signal and refreshes every 24 hours, into Tableau or another BI tool on a schedule.
4. Pair every throughput line with quality — Score sampled work with LQA on one schema, then attribute results by scoping the LQA Dashboard and Error Density Report to the jobs and locales each linguist worked. A linguist whose throughput rises while error density holds steady is genuinely more productive; one whose throughput rises with error density is shifting work to reviewers.
5. Review trends with the linguist, then act — Look at three or more periods, discuss outliers with the person before drawing conclusions, and use the result to route content, adjust post-editing rates by quality band or plan coaching. Comparing agencies rather than individuals is a different exercise, covered in how to build a translation vendor scorecard.

This approach fits teams that...

• Manage several in-house or freelance linguists and need an objective basis for assignments, rates or coaching.
• Run machine translation post-editing and want to know whether post-editors, engines or content types explain slow output.
• Pay post-editing by predicted effort and need evidence that the bands match the edits linguists actually make.
• Report localization efficiency to leadership and want a number that survives the question "but what about quality?"

When linguist productivity metrics may not be the right priority

• Very small teams where a manager already sees every job; formal metrics add overhead without adding information.
• Transcreation and creative work, where effort per word is driven by concept development that edit distance and word counts cannot see.
• Programs with no shared quality schema yet; productivity without a quality line rewards speed alone, so set up LQA first.
• Work routed entirely through a managed service, where the provider owns linguist staffing; the Security at Smartling page states that Smartling cannot give customers special control over its independent contractors' assignments or provide lists of those contractors, so individual-level metrics are not the lever there.

Evaluation checklist: questions to ask about linguist productivity analytics

Which tools measure translator performance, and can they support vendor comparisons?
Look for a platform that reports weighted-word throughput, edit distance, rejections and MQM quality per linguist from the same system, rather than separate exports. Vendor-level comparison then reuses the same data at the agency level, as described in the translation vendor scorecard.

How is post-editing productivity measured, and which tools support it?
Ask whether the platform records edit distance between machine output and the post-edited translation, and whether predicted machine translation quality is stored per string so post-editors can be compared within the same quality band.

How accurate are reviewer metrics?
Check how review work is credited. If a review step is credited on submission regardless of changes, word counts cannot distinguish a careful reviewer from a rubber stamp; edit distance, rejection counts and LQA errors recorded per reviewer can.

Do productivity metrics connect to reviewer feedback loops?
Productivity data is most useful when the edits and errors behind it reach the linguist and the linguistic assets. How a correction becomes a translation memory update, a glossary entry and a blocking quality check is covered in building a localization QA feedback loop.

Can you normalize for translation memory leverage and content mix?
Confirm the report carries weighted words and the fuzzy-match tier, and that you can filter by language and workflow step, so linguists on heavily leveraged content are not overstated.

How far back does the data go, and can it reach your BI tool?
Ask for each report's retention window and refresh cadence; a 6-month report is enough for coaching, while annual reviews need an export with a longer history.

Who can see the numbers?
Linguists should be able to see their own data. In Smartling, translators, editors and reviewers can run the Word Count Report and the String Changes Report on work they took part in, which keeps the conversation about the same numbers.

How does Smartling support linguist productivity measurement?

Smartling records every linguist's completed work, edits and quality results in one platform, so throughput, effort and quality can be read side by side instead of reconciled from separate files. The Word Count Report breaks completed work down by Linguist, Agency, Translation Language and Workflow Step Type, with a Weighted Words column that applies fuzzy-match discounts and a Fuzzy Breakdown column that shows either the fuzzy tier or, for machine-translated strings, the Language Quality Estimation level. That combination lets a manager compare post-editors within the same predicted-quality band rather than across a mixed workload.

The String Changes Report shows what changed at each workflow step, with Edit Distance, Edit Word Distance and Edit Distance to Publish, plus workflow actions such as REJECT and POST_MACHINE_REVISION, which turns post-edit effort and rework into countable measures. For longer trends, the Data Access Tool delivers a Translator Quality Performance - 90 Days dataset based on edit distance by project, job and workflow step, alongside Job Workflow Word Counts, as CSV files for Tableau or another BI tool; the Customer Success Manager activates it. Quality comes from LQA, where human linguists, LQA Agent or both record errors by category and severity against one schema, and the LQA Dashboard, Errors & Arbitration and Error Density reports supply the quality line that keeps a productivity view honest.

For the editing environment that shapes post-editing speed in the first place, see what a post-editing environment for AI translation should include; for balancing the workload those metrics reveal, see how to manage translator workload across a team.

Related questions

• How do you manage translator workload across a team?
• How do you build a performance scorecard for translation vendors?
• What should a human reviewer's editing environment include when post-editing AI translation?
• How do you manage and staff a team of translators and linguists?