Translate pure.
Ship secure.

Your locale files stay exactly where they are, in your repository, in the format they already use. There is no portal to upload them to and nothing to keep in sync afterwards, which removes the largest source of drift in a migration. What is not built yet is bulk import of an existing translation memory or glossary, so today your terminology decisions become pins as reviewers make them rather than arriving on day one. If you are sitting on a large memory, tell us before you plan the migration and we will give you a date rather than a maybe.

People you already employ, usually. A reviewer needs an email address and nothing else: no account, no password, no seat, no training. They receive a link, read one string, and approve it or rewrite it. Most teams assign the German-speaking engineer, the French salesperson, or a contractor they already work with. You can point several reviewers at the same language, and the first one to act resolves the string.

You correct it the way you correct any other line in your repository, or you reopen the review link and rewrite it there. Either way the correction becomes a pin, and a pin is never machine-overwritten. The same mistake cannot recur in that language, and if the English later changes underneath the pin, Purelex stops and asks rather than quietly reusing your old wording or quietly discarding it.

The translating is the easy part, and it is the part you would finish in a weekend. What you would then have to build is the placeholder integrity gate that counts every occurrence and fails the build, the format adapters that rewrite a file without disturbing the keys you did not touch, the escalation ladder, the reviewer routing and single-use links, the pin store that makes a correction permanent, and the metering that does not charge you twice for a string that did not change. That is the product.

Yes, and it refuses to guess. A plural string is presented as one field per plural branch of the target language, in CLDR order, and an empty required branch blocks the submit rather than shipping a sentence with a hole in it. Placeholders are masked before translation and restored verbatim afterwards, then compared per occurrence, so a repeated variable cannot lose one copy. Right-to-left targets are rendered right-to-left with placeholders bidi-isolated, so they cannot be visually reordered into nonsense.

Nothing, for every string that did not change. Memory hits, pinned strings and cache hits are billed at zero, always, and that is a product promise rather than an optimization we might revisit. You pay only for new and modified strings, at the tier you chose for that path. In practice the bill falls over time as pins accumulate, which is the opposite of how per-word pricing behaves.

Yes, up to the point where a person is the point. The MCP connector and the REST API are first-class surfaces, not an afterthought bolted onto a dashboard, and an agent key can translate a diff, read the queue and read its own usage without anyone in the loop. What it cannot do is approve, pin, or add a reviewer. All three refuse an API key outright, on the API and on the connector alike, and the error names the two places a person approves: the review link we email the assigned reviewer, and the review queue in the portal. Adding a reviewer is on that list because a reviewer receives signed links that approve, so a key able to add one could send those links to an address it controls. An agent signing off on its own translation is the one thing the review loop exists to prevent, so it is a refusal in the product rather than a role you could grant by mistake.

You do. The translations are files in your repository, in your format, and there is no format we could hold hostage even if we wanted to. Your pins and corrections are scoped to your account and never enter another customer’s prompts. Self-serve export and self-serve deletion are not built yet; both happen by request today, and the schema is already wired so that deleting an account removes its strings with it.