Processed words: how localization stopped being priced by what you own and started being priced by what you touch

Seats and keys counted inventory, so the bill tracked the size of the product. A meter that counts processed words tracks something else entirely: how often your own pipeline moves a string. That moves the largest input to localization spend out of procurement and into code review.

A long ribbon of blank cards running in a closed loop through a hand-cranked wringer, drawn in white line on a slate ground

The meter stopped counting what you own

For most of the last decade a localization invoice had two numbers on it: seats and hosted keys. Both count inventory. A key exists whether or not anybody touched it this quarter, a seat exists whether or not the person logged in, and the bill therefore tracked the size of the product. You could forecast it off the roadmap, which is why finance liked it and why nobody in engineering ever thought about it.

That is not how the current generation of contracts works. Through late 2025 and 2026 the large platforms restructured, and the direction was the same everywhere even though the details were not. One vendor withdrew its public entry tier and moved the business floor to roughly fifteen thousand a year behind a sales conversation¹. Another replaced seat limits and hosted-key quotas with a single meter it calls processed words ¹. In the same move, keys became unlimited on every paid plan².

Read those two sentences together. The thing that used to be metered became free, and the thing that used to be free became metered. Unlimited keys is not generosity. It is a change of unit.

The bill used to look like a library card, where you paid for how much you were holding. It now looks like a database, where you pay for reads and writes and the rows are free.

Prices move and tiers get renamed, so treat every number here as something to re-check rather than to quote. The unit is the part worth learning, and units change far more slowly than price lists.

What a processed word actually counts

The useful thing about a meter is that it has to be defined in public. One published definition reads: the number of words a customer actively processes during translation work, including updates made by humans, AI and machine translation engines, imports, API calls, or automations ².

That sentence is marketing-shaped and tells you almost nothing on its own. The exclusion list beside it is where the shape of the meter actually shows.

Operation	Metered	What it implies
Importing or updating base-language content	Yes	The source string is the billable event
First translation of a key, per target language	Yes	A new string costs once in every locale
Re-translation caused by a base-language change	Yes	Editing English re-bills every locale at once
A memory suggestion below a 100% match	Yes	A near match is still work to be paid for
Content created or modified inside a branch	Yes	A branch is not a free copy of the catalog
A 100% translation memory match	No	Your own history is a discount, not a re-purchase
Editing a target string with no base change	No	Human review of an existing string is free
A re-import with nothing changed	No	The meter reads diffs, not files
Metadata, tags and key attribute updates	No	Description and context are not content

One vendor's published meter, exclusion list included. The rows that read No are the interesting half: they are the vendor stating, contractually, what it does not consider work.

Two of those rows do most of the damage. The first is that the source is the billable event: a change to the English is what triggers re-translation, and it triggers it once per target language. The second is that a manual edit to a target string, with no base change behind it, is not metered at all. A linguist can rewrite the German all afternoon for free. Change one word of the English and you have bought twenty-six re-translations.

So the unit of billing is not a word in your product. It is a word crossing a boundary. Two products with identical catalogs, identical locales and identical traffic can differ by an order of magnitude on this line, and the only thing separating them is how often somebody edits the source.

Churn is the line item

Which makes churn the line item. Not volume, churn: the rate at which strings that already exist get touched again.

text

one English word changed, 26 target locales  1 x 26  =    26 processed wordsa 40-word onboarding screen, reworded once  40 x 26 = 1,040 processed wordsthe same screen reworded four times during design review  4 x 40 x 26 = 4,160 processed wordsthe copy that shipped: 40 words

The multiplier is the locale count, and it applies to every pass, including the three that were thrown away. Design review is normally free. Under a meter it is not, if the review happens after the copy has entered the catalog.

The expensive habits are not the ones anybody would flag in a code review, because until recently none of them cost anything.

Renaming a key for tidiness. A rename is a delete plus a create, and the create is a first-time translation in every locale. It is the most expensive no-op in localization, and it usually arrives inside a commit whose message says “tidy up namespaces”.

Rewording during review. Copy that lands in the catalog and is then polished three times has been translated four times. The cheapest version of this is entirely procedural: settle the wording before the string enters the pipeline, not after.

Branch-per-feature localization. Branching is the right engineering answer and it is not a free copy. Work done inside a branch is work, and two branches that both touch the same screen pay for it twice.

Adding a locale. A new language is sold as one more item on the list. It is really a change to the multiplier on every future edit you will ever make. The twenty-seventh locale does not add a twenty-seventh of the cost, rather, a twenty-seventh to the price of every subsequent word of English is added.

Change	Change seen by the meter	Cheaper shape
Renaming a key for tidiness	A new key, translated from scratch in every locale	Leave the key alone and change its description
Rewording a string during design review	A base change, re-billed in every locale, per pass	Settle the copy before it enters the catalog
Reformatting or re-ordering the catalog file	Nothing at all, as long as no value moved	Safe. Keep the formatter
Splitting one string into two for reuse	Two first-time translations, and the original is now waste	Decide the granularity when the string is written
Adding the twenty-seventh locale	A larger multiplier on every future edit	Price a locale as a multiplier, never as an item

The third row is worth noticing. A meter that reads diffs rather than files makes a formatting pass genuinely free, which is the opposite of what most people assume and the reason it is worth reading the exclusion list rather than guessing at it.

We have argued before that a message catalog should grow with a business decision and not with a code change. That was a payload argument at the time. Under a metered contract it is also an invoice argument, and the invoice is the version of it that people act on.

Your pipeline is a billing client

If the meter counts operations, then the thing performing most of the operations is your CI job. That makes a pipeline a billing client, and it should be built like one.

The single highest-value property is a deterministic export. A meter that ignores an unchanged re-import is only useful if your unchanged re-imports are actually unchanged. If the exporter emits keys in map order, or re-escapes a quote, or drops a trailing newline depending on which machine ran it, then every sync presents as a base-language edit and every base-language edit is billed in every locale. The catalog did not change. The bytes did, and the bytes are what got uploaded.

The second is to make the pipeline talk less. Published limits are real: one platform documents 6 requests per second, applied per API token and per IP address ³. A job that pushes key by key does not merely run slowly against that, it turns a deploy into a retry storm at exactly the moment a release is waiting on it.

bashscripts/sync-source.sh

01# only talk to the platform when the source catalog actually moved.02# an unchanged re-import is free, but only if it is genuinely unchanged.03if git diff --quiet "$BASE".."$HEAD" -- locales/en.json; then04  echo "source unchanged, nothing to sync"05  exit 006fi0708# one upload of the whole file, not one request per key.09# the published ceiling is 6 requests per second, per token and per IP.10tms push --file locales/en.json --lang en1112# and prove the export is byte-stable before it is ever pushed:13# a re-serialized file with the same content must produce no diff at all.14npm run i18n:export && git diff --exit-code -- locales/en.json

Two guards. The first stops the job when the source did not move, the second fails the build when the exporter is not byte-stable, which is the failure that makes the first guard a lie.

Neither of these is a localization idea. They are the same discipline any team applies to a paid API: do not call it when nothing changed, batch when you do, and make the payload a function of the content rather than of the machine that produced it.

The quality threshold is a budget dial

There is a second number that decides the bill, and it is usually buried in a project setting.

Modern pipelines route rather than translate. Machine output is scored by a quality estimation model, which predicts how good a translation is without access to a reference translation⁴. That is a real research discipline with a shared task behind it, and the strong systems are neural estimators built on the same encoders as the reference-based metrics ⁵. Segments that score above a threshold publish. Segments below it go to a human.

That threshold is presented as a quality control. It is also the only thing deciding how many segments a person is paid to read. Move it two points and the invoice moves; nobody reviews it the way they would review a price change, because it does not look like one.

It is worth being precise about what the score can do. Quality estimation is a prediction about language, and it carries an error rate in both directions. The human benchmarks it is trained and validated against are themselves methodological artifacts: expert annotators working with document context under an explicit error taxonomy rank systems substantially differently from crowd raters, to the point that embedding-based automatic metrics outperform the crowd⁶. A quality figure quoted without its annotators, its context window and its severity weights is not a measurement. It is a claim.

Which is why the threshold should not be the first gate in the pipeline. Placeholder survival, ICU plural category validity, escaping and markup balance are decidable. You do not need a model to tell you whether {count} came back; a parser answers it, in both directions, every time. A deterministic check costs nothing per segment and has no false negatives on the thing it checks. Run it first, and the paid probabilistic judgement never gets spent on a segment that was already invalid.

The ordering matters more than it looks. A structural failure sent to a human is billed twice: once for the review, and again for the corrected string coming back through the meter.

The questions that actually price a platform

The comparison table everybody writes lists integrations, connectors, file formats and seats. None of that decides what you pay. These questions do, and every one of them has a published answer at the vendors worth using.

Question	Exposes	Desired answers
What increments the meter	Whether the unit is content or activity	A published list of counted and uncounted operations
What a 100% memory match costs	Whether your own history is a discount or a re-purchase	Nothing, applied automatically, before any engine runs
What a base-language edit triggers	The multiplier on every copy tweak for the rest of the contract	One unit per target language, stated plainly
Where the overage line sits	Whether a bad month is a bill or a stop	A cap you set yourself, with an alert well before it
What the routing threshold defaults to	Who chose your review budget	A number you own, versioned with the project
Whether the export is byte-stable	Whether a routine re-sync reads as an edit	Identical bytes for identical content, on any machine

Ask the last one of your own tooling rather than of the vendor. It is the only row on this table you control completely, and it is the one that quietly decides how often the others fire.

The market moved the unit from inventory to activity, and it is not moving back. The consequence is that the largest single input to a localization bill is now how often your own pipeline touches the source. That is not a procurement decision, and it will not be fixed by negotiating a rate. It is a code review decision, made a few dozen times a week, by people who have never seen the invoice.

References

1.Locize, 2026 Phrase and Lokalise Changed Their Pricing: What Happened and Your Options in 2026 locize.com, July 2026
2.Lokalise Help Center New price plans: Everything you should know docs.lokalise.com
3.Lokalise developer documentation Rate limits developers.lokalise.com
4.Zerva, Blain, Rei, Lertvittayakumjorn and others, 2022 Findings of the WMT 2022 Shared Task on Quality Estimation WMT 2022
5.Rei, Treviso, Guerreiro, Zerva and others, 2022 CometKiwi: IST-Unbabel 2022 Submission for the Quality Estimation Shared Task WMT 2022
6.Freitag, Foster, Grangier, Ratnakar, Tan and Macherey, 2021 Experts, Errors, and Context: A Large-Scale Study of Human Evaluation for Machine Translation TACL 2021