← Comparisons

i18n tools and help content

· Prices and facts as published by each vendor on

If your product already runs i18next with locize, or Tolgee, you have a system that stores text under keys, delivers it at runtime and lets someone edit it without a deploy. Putting your help text in it looks like the obvious move. Often it half works, and the half that does not is the same half every time.

The difference is where the text comes from.

What an i18n tool is built around

A translation key exists because a developer wrote it in the code. The source string sits in the call, the key names the place it is used, and the tooling follows from that: extraction from your source, namespaces per screen or feature, pluralisation rules, and a CLI that syncs what the code needs with what the platform holds.

The pricing follows the same shape. locize meters words and CDN downloads: Free gives 2,000 words and 100K standard downloads, Starter $7 a month gives 15,000 words, Growth $49 gives 60,000, Enterprise $199 gives 200,000, and extra words cost $5 per 10,000. Tolgee counts keys and seats: Free covers 30,000 words with 3 seats, Translate is €58 a month billed annually with unlimited seats, Optimise €133, Manage €373, and self-hosting is available under a custom licence.

Both are reasonable prices for what they do. Both assume the same thing: that the English already exists, in the code, and the job is to carry it into other languages.

Where help text does not fit that assumption

There is no source in your code. Nobody writes a 300-word explanation of your invoicing rules inside a t() call. The help text is the artefact, not a translation of something. So the key cannot be extracted; someone has to decide it, and the tool has no opinion about who or how.

The value is a string. An i18n entry holds one piece of text. A help topic is a title, a short description, steps in order, a warning that must stand out, and a reference to a button whose label changes next quarter. You can encode that as HTML inside a string. Then you own the escaping, your reviewers read markup in a translation grid, and a structural change means find-and-replace across every language.

The author is not the developer. i18n tooling is built for a loop that starts and ends in the repository: extract, translate, sync, deploy. Help text is written by whoever knows what confuses users, edited after a support ticket, and published on a Tuesday afternoon. The i18n loop can be made to allow that. It was not designed for it.

Words are the meter. A UI label is two words. A help topic is three hundred. On locize's ladder, one hundred help topics of average length is most of the Growth plan's 60,000 words before a single interface string is counted. Your translation budget starts paying for prose it was not sized for.

Structure gets lost in the middle. Even when the text arrives correctly, your application receives a string. Everything about which part was a step and which was a warning has to be re-derived from markup at render time, in every component, in every language.

The arrangement that works

Keep both, and split them by who writes them.

UI labels stay in your i18n tool. Button text, field names, validation messages, empty states: strings your code defines, extracted from your code, translated in the loop that already works. i18next, locize and Tolgee are good at this, and nothing here suggests replacing them.

Help content lives in a system built for content. Topics with structure, written by the person who answers the questions, published without a release, fetched by your application under a key of its own. That is what HelpCCMS does: one GET request returns the current published text as HTML and as plain text, in the locale you ask for.

The two never collide, because they are addressed differently and rendered by different components. A label is t("billing.invoice.download"). A topic is GET /api/deploy/{collection}/billing.invoice.explained.

When the i18n tool is enough

Stay with what you have when:

That case is real, and adding a second system to it would be overhead. The moment to reconsider is when someone who is not a developer needs to write a paragraph, or when a piece of help needs steps and a warning rather than a sentence.

A headless CMS is the other common answer here, and it has the opposite trade: real structure, but you build the help model and pay for the roles. How to manage in-app help puts all of it on one ladder.

Sources

All read on 22 September 2026.