Lokalise measures usage based on processed words — the number of words actively handled during translation operations. This includes base and target language content processed through imports, first-time translations, base language updates, AI/MT, automations, and other translation operations.
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 from base and target language content involved in applicable translation updates, such as initial translations, base language updates, imports that modify content, AI/MT actions, and automations.
When an applicable translation update is counted, Lokalise counts the words in the resulting translation field.
Why this matters?
Your subscription includes allowances for different usage metrics, including processed words. You can view your current usage and limits on the Usage overview page.
Here’s what’s important to know:
All plans include unlimited translation keys.
You can store as many keys as you need.All paid plans include unlimited hosted words.
Stored content does not consume your processed words allowance by itself.Processed words are separate from AI translation allowances.
Depending on the operation, both processed words and an AI-specific allowance may be consumed.
When are words processed?
Processed words are counted when content is created or updated through applicable translation operations, including imports, AI/MT, automations, integrations, and other supported workflows. 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
When you use pseudolocalization
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)
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 |
Target translation updated after a base language change: "amo la pizza" → "mi piace la pizza" | 4 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 | New or updated translation content is 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 an operation creates or updates countable translation content, it generally consumes processed words. Operations that don’t create or update translation content — such as reviewing an existing target translation without a base language change, restoring content, or reorganizing keys — generally do not.
What does this mean in practice?
Let’s say you import base content containing 10,000 keys, with an average of 6.9 words per key, and then translate it into three target languages with approximately the same average word count.
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.
The initial base content import also consumes 69,000 processed words.
Total processed usage: ~276,000 words