TextSetu as a Crowdin alternative

If you are evaluating a move off Crowdin, the feature comparison is rarely the thing that decides it. The thing that decides it is whether the work already inside the platform comes with you: the approved translations, the translation memory that stops you paying twice for the same sentence, and the glossary that keeps your product's vocabulary straight.

So that is what this page is about. Not a feature grid, but the migration itself, stated precisely enough that you can check it before you commit to anything.

Your data moves with one command

npx @textsetu/cli@latest migrate crowdin --from 123456 --dry-run
npx @textsetu/cli@latest migrate crowdin --from 123456

The command reads your Crowdin project through Crowdin's own API and writes it into a TextSetu project. Three things about how it runs:

It only reads. Nothing in your Crowdin account is modified, renamed or deleted. Your existing setup keeps working exactly as it did while you evaluate ours.

It runs on your machine, with your token. You create a read-only personal access token in Crowdin, and it never leaves your computer. We never ask for your Crowdin credentials and never store them.

It tells you what will happen first. --dry-run reads both sides in full and prints the entire plan: which languages get created, how many keys, translation memory segments and glossary terms will land, and every single thing that will be lost or changed, as a number. Nothing is written. If the plan is not what you expected, you have lost five minutes.

What arrives

What does not

A migration is judged on what did not arrive, so the tool counts each of these in the dry run instead of letting you discover it later:

• Approval state. Translations arrive as values. Crowdin's approved and unapproved distinction is not carried across, so if you use approval as a gate, plan to re-approve in bulk on arrival.
• History, comments, authors and timestamps. Only the current translation moves.
• Screenshots. Crowdin maps many screenshots to many strings with bounding boxes. TextSetu holds one screenshot per key, so there is nowhere for that mapping to land.
• Your file and directory layout. Keys arrive as keys. If the file tree is the thing you need preserved, there is a second path: crowdin download, then textsetu push --translations, which keeps your structure exactly.
• Deliberately empty translations, which arrive as untranslated.
• Project settings such as QA checks and workflow steps. Configure those on our side first.

One detail worth knowing before you start, because it is the only part that needs a decision from you: a Crowdin identifier is unique per file, while a TextSetu key is unique per project. If common.json and errors.json both contain title, those are two different strings competing for one key. The migration refuses and names them both rather than letting one silently overwrite the other. One flag namespaces every key by its file instead, which is how most teams want it anyway.

Where TextSetu is actually different

Three differences worth your attention. Each of them is about cost or control rather than a feature checkbox.

You bring your own AI account. Connect your own Claude, OpenAI, Gemini or DeepSeek key, and the model charges land on your provider's invoice at their published rate. We do not mark them up, because we never touch them. That is the opposite of paying per word, where the cost of the machine is buried inside a price that also scales with how much copy your team happens to write that quarter. Our per-word pricing page works through the arithmetic, and the calculator runs it on your own numbers.

Your glossary and translation memory feed the model, not just the humans. A term with a defined translation is given to the model as a constraint before it writes, and its output is checked against your placeholders afterwards. Terminology that used to be a review comment becomes something the draft already respects.

Everything is reachable from a script. The same API drives the web app, the CLI and an MCP server, so your translations are addressable from CI, from a deploy step, or from an AI agent working in your repo. The migration command is itself just one of those endpoints.

What to check before you switch platforms

This applies to any vendor you are considering, including us. The questions that separate platforms fastest are rarely the ones on the comparison table:

• What does it cost to leave? Try the export before you commit to the import. A platform you can leave in an afternoon is a different kind of purchase from one you cannot.
• Who pays the model provider? If it is the vendor, the AI price is inside your price and you will never see what it really was.
• What does the tenth language cost compared with the first? If the answer is the same, nothing is being reused.
• Are reviewers charged per seat? If they are, you will ration exactly the colleagues most likely to catch an error.
• Can you see spend while it accrues, or only on the invoice? After the fact is the worst moment to learn what a release cost.

Frequently asked

Can I try the migration without committing to anything? Yes, and it is the recommended first step. --dry-run writes nothing to either side and tells you precisely what a real run would do.

Can I move only part of it? Yes. --only translations, --only tm or --only glossary, in any combination. Many teams bring the translation memory and glossary first, since those are the assets that took years to build.

What if something fails half way? The command reports what already landed and stops. Every step is repeatable, so you fix the cause and run the same command again. Nothing is duplicated and nothing is deleted.

How long does it take? A project of a few thousand keys is a minute or two, most of it spent reading from Crowdin.

Does it work with Crowdin Enterprise? Yes, with one extra flag naming your organization.

The complete runbook, including every warning the tool can print and what to do about each one, is in the migration guide.