Lokalise measures usage based on processed words — the number of words actively handled during translation operations. This includes both base and target language content processed through manual edits, imports, AI/MT, and automation.
In this article, you’ll learn what qualifies as a processed word, what doesn’t, and how this usage metric applies across different workflows in Lokalise.
What are processed words?
Overview
Processed words are the core unit used to measure how much translation work is happening in your Lokalise projects. This includes words in both your base and target languages that are actively translated, updated, or processed through the platform — whether by a human, AI/MT, API, import, or automation.
Processed words are calculated as the number of source language words plus the number of target language words that have been modified through manual edits, imports, AI or MT actions, or automations. In other words, Lokalise counts the output — the text that ends up changed in your project.
Why this matters?
Lokalise enforces fixed quotas for each billing metric. If a limit is exceeded, the affected feature will stop working until usage returns within the limit or the subscription is adjusted.
Your subscription plan now includes a specific allowance of processed words per year, and that allowance determines how much content you can translate or retranslate using Lokalise. The more translation work your team does, the more processed words you'll use.
Here’s what’s important to know:
All plans include unlimited translation keys.
You can store as much content as you need — no key or storage limits apply.All paid plans include unlimited hosted words.
You can manage large amounts of base language content without worrying about storage limits.Only processed words count toward your usage.
Each time words are translated or processed (manually or automatically), they count toward your plan’s word allowance. The more you translate, the more processed words you consume.
When are words processed?
Processed words are counted when content is actively translated, updated, or modified: either by a person, automation, or integration. This applies to both base and target language content.
Words are processed in the following cases
Base content:
When base language content is imported for the first time
When base content is updated (via UI, API, import, or 3rd-party integrations)
When a key is deleted and then re-imported, even if the key name and value are identical to the previous version
Deleted keys are treated as new content when re-created
Target content:
When a key is translated for the first time (regardless of method: UI, import, AI/MT, etc.)
When target content is created via bulk actions (e.g., copying source content into an empty target translation)
This applies even if the copied content already exists in the project in another language or variant, and no edits are made. If the target field was previously empty, creating the translation (regardless of method) counts as processed words.
When a translation is updated due to:
A change in the base language
AI/MT applied through workflows, tasks, automations, or bulk actions
API, import and other similar operations like bulk actions
When a TM (translation memory) suggestion below 100% match is accepted
When translation is created or modified inside a branch
Words are not processed in the following cases:
Manual edits to target content without any base language changes
TM suggestions with 100% match
Re-imports of the same content with no changes (determined by key–value comparison)
This applies only if the keys already exist in the project. If a key was deleted and then re-imported, it is treated as new content and will be counted as processed words.
This applies only to re-imports within the same project, since the word count is based on key-specific content.
Supported placeholders and markup in supported formats
This applies only to the placeholder or markup syntax itself. Any translatable text inside placeholder structures is still counted.
Unsupported placeholder-like content is treated as regular text and may count toward processed word usage.
Downloading (exporting) translations
Creating or merging branches
Editing key metadata (e.g., tags, descriptions, custom attributes)
Copying or moving keys between projects
Linking keys via the duplicate finder
Note: When you update translation value for the linked keys, processed words are counted only for the parent.
Clearing translations (manual or bulk)
Pseudotranslation (not counted unless it triggers AI/MT or retranslation)
Importing TMX files to populate translation memory
Using AI LQA or translation scoring
How placeholders, plurals, and markup affect processed word count
Placeholders are treated differently from regular text when Lokalise calculates processed words.
In general, supported placeholders in supported placeholder formats are not counted as processed words. This means that if a string contains a placeholder used for a dynamic value, such as a name, number, amount, link, or other variable content, the placeholder itself is removed before the remaining text is counted.\
For example:
String | Processed word logic |
|
|
|
|
|
|
| 0 processed words if the whole string is a supported placeholder. |
Unsupported placeholders are treated as regular text for word-counting purposes. In simple terms: if Lokalise does not recognize a placeholder as supported, it may count toward processed word usage.
For example, a custom placeholder-like block such as {name:...} may be valid in another ICU or framework-specific context, but if it is not supported by Lokalise as a placeholder, it is counted as text. In this case, it would typically count as 1 processed word.
List of supported placeholder formats and placeholder types that Lokalise doesn't count as processed
List of supported placeholder formats and placeholder types that Lokalise doesn't count as processed
Lokalise Universal Placeholders
[%s] – string
[%i] – integer
[%f] – float
[%.2f] – float with precision
[%1$s] – positional string
[%1$.2f] – positional float with precision
[%s:name] – named string
[%i:name] – named integer
[%.2f:name] – named float with precision
Lokalise Special Placeholders
[VOID] – absent translation (exported as empty string)
[TRUE] – boolean true
[FALSE] – boolean false
[%] – literal % character
[SPACE] – special client case (undocumented)
Key Reference Placeholders
[%key_id:some_key_name%]
[%key_name:some_key_name%]
ICU Message Format Placeholders
{variable_name}
{0}, {1}, {2} – positional
{count, plural, one {# item} other {# items}} – plural
{gender, select, male {...} female {...}} – select
{name, date, short} – date/time
{value, number, currency} – number format
i18n / Rails Double-Bracket Placeholders
Placeholders matching regex pattern: /({{)([[:alnum:]_\-.:]+)(}})/.
{{variable_name}}, {{count}}
Ruby / Python %{name} Style
Placeholders matching regex pattern: /(%)({)([[:alnum:]_\-.:]+)(})/.
%{variable_name}, %{count}
Printf Placeholders
%s – string
%d – decimal integer
%f – float
%@ – iOS string
%i – integer
%u – unsigned int
%x – hexadecimal
%b – binary
%c – character
%e, %E – scientific notation
%F – float (uppercase)
%o – octal
%X – hex uppercase
%ld – long decimal
%li – long integer
%lu – long unsigned
%lx – long hex
%1$s – positional string
%2$d – positional int
%.2f – float with precision
Python / Named Printf Placeholders
Placeholders matching regex pattern: /%\([0-9a-zA-Z_\-.:]+\)(...type)/.
%(name)s, %(count)d, %(variable)f, %(key)s
Symfony Placeholders
%s, %d, %name%, %variable_name%, %some.key%
.NET Placeholders
Placeholders matching regex pattern: /{\\d+(:\\d+\\.\\d+)?}/.
{0}, {1}, {0:0.00}
NSString / iOS Named Placeholders
iOS string formatting for plurals
%#@count@, %#@variable_name@
HTML Tags
This covers full HTML/XML tag pattern including namespaced tags and attributes.
<b>, </b>
<br/>, <br />
<xliff:g id="count">
<span style="color:red">
HTML Entities
Regex pattern: /&[0-9a-zA-Z]+;/.
& < > " '
Escape Sequences
And their Unicode counterparts.
\n – newline
\r – carriage return
\t – tab
\u00A0
\u0041\u0042
[\u00A0]
Text inside placeholder structures
Some placeholder structures may contain translatable text. In those cases, Lokalise does not count the placeholder syntax itself, but it does count the translatable words inside it.
For example, in plural or select-style messages, the technical parts of the expression are ignored where supported, but the words shown to users are still counted.
String | Processed word logic |
| The placeholder/plural syntax is ignored where supported. The user-facing words |
This is important because placeholders are often used around real translatable content. Lokalise only excludes the recognized placeholder or markup structure itself, not the words that users may actually see in the product.
Plural keys
For plural keys, Lokalise counts the words across plural forms together.
If a plural key stores its forms as structured values, the plural forms are combined and then counted as one text value. Supported placeholders and markup are removed from that combined text before the remaining words are counted.
For example:
Plural forms | Processed word logic |
|
|
Markup and tags
Supported markup and tags are also removed before counting processed words. This means HTML-like formatting or supported inline tags are not counted by themselves.
For example:
String | Processed word logic |
|
|
| 0 processed words if the string only contains supported markup. |
However, visible text inside markup is still counted.
Word-counting behavior after placeholders are removed
After supported placeholders and markup are removed, Lokalise counts the remaining text.
The counting behavior depends on the language/script:
For Chinese, Japanese, and Korean text, each matched CJK character counts as 1 word.
For Dravidian scripts, each word-like unit counts as 1 word.
For other scripts, punctuation and other non-word characters are treated as separators, and words are split by whitespace.
Hyphens and apostrophes inside words are preserved, so a term like
well-roundedis counted as 1 word.
If the remaining content has no countable words, but the original string is not empty and still contains visible content after sanitization, Lokalise applies a minimum count of 1 word.
This means that strings containing only supported placeholders or markup usually count as 0 processed words, while a string containing only a visible symbol such as ! may still count as 1 processed word.
Examples
Let’s break it down with some real cases:
Counted as processed
Scenario | Word count logic |
Base content imported: "I love pizza" | 3 words |
Base content updated: "I love pizza!" → "I used to like pizza" | 5 words |
Target language first-time translation: "amo la pizza" (Italian) | 3 words |
Re-translation triggered by base change: "amo la pizza" → "mi piace la pizza" | 5 words |
Machine translation used (workflow/automation/inline suggestion) | Word count of translated string |
Clicking Google-translate empty values | Translated string word count |
Accept TM match at <100% | Translated string word count |
Upload offline XLIFF file | All newly translated word content counted |
Automations: Insert translation, pseudolocalize, or copy source to target | Counted |
Bulk actions: Fill with text, Copy keys to translations, Find & Replace | Counted |
Unsupported placeholder-like text, such as | Counted as regular text |
Not counted as processed
Scenario | Counted? |
Manual edit of target with no base change | No |
TM suggestion accepted with 100% match | No |
Re-import of content with no changes | No |
Restore previous translation (via history or snapshot) | No |
Branch creation or merge | No |
Updating metadata, tags, or key settings | No |
Copy/move key to another project | No |
Bulk action: Clear translations | No |
Bulk action: Cross-reference languages | No |
Duplicate finder used to link keys | No |
Supported placeholder-only string, such as | No |
Rule of thumb
If a word flows through an active operation (like import, AI, machine translation, API update, or first-time human translation) it's processed and counted. If it's just being stored, reviewed, or copied around, it’s not.
What does this mean in practice?
Let’s say your base content has 10,000 keys, and each key contains an average of 6.9 base words.
That’s 69,000 hosted words stored on the platform (hosted words are unlimited on paid plans).
Translating this content into 3 target languages adds approximately 207,000 processed words.
Total processed usage: ~276,000 words