Frequently asked questions

A place to keep every piece of translatable text your product ships. You write each string once in your source language, your team translates it into the other languages, reviewers approve it, and then you tag a release — a snapshot Localeo compiles into ready-to-use translation files and serves from a CDN. Your app fetches those files instead of you shipping a code change every time a word is corrected.

After you create an account there is a four-step setup: name your organization, tell us your industry and team size, pick a plan, and enter your billing details. On a paid plan the last step hands you to our payment provider to complete the first payment.

You are the owner of the organization you create. You can change your plan later, so pick the one that fits today.

Localeo currently bills only to Netherlands addresses, and a valid Dutch VAT identification number is required on every paid plan. Sign-up will refuse any other billing country.

This is deliberate rather than an oversight: charging the right VAT elsewhere means destination rates and reverse-charge handling we have not built yet, and we would rather decline than tax you incorrectly. If you need to be billed from another country, email [email protected] so we can weigh it up.

All address fields in setup are required, including address line 2 and state or province.

Use the workspace switcher at the top of the sidebar and choose Create project. You give it a name and pick its base language. A project is normally one app, website, or product surface — anything that ships its own set of translation files.

The language you author in — the source your translators translate from. It is chosen when you create the project and is added as the project’s first language automatically.

It matters more than it looks: the base value is part of what Localeo uses to detect that a translation has gone out of date. Editing the source text marks its translations as needing another look.

Seven at the moment: English, Spanish, French, German, Italian, Dutch and Portuguese.

If you need one that is not on that list, tell us at [email protected] — the catalogue is something we extend based on what people ask for.

Open Project → Languages and choose Add languages. Every key already in the project immediately becomes available to translate into it, starting out untranslated. Adding a language does not change releases you have already published — see that question.

On Project → Languages, use Manage contributors on a language row. People assigned there are the translators for that language: they are the ones who can be @mentioned on its translations and who receive its weekly digest. Someone can be assigned to several languages.

They are two different things, and two different lists.

• Interface language is the language Localeo itself is shown to you in, set per person under Settings → Account. Nine are available: English, Nederlands, Deutsch, Español, Français, Italiano, Polski, Русский and 简体中文.
• Project languages are the languages your content is translated into, and there are seven.

Changing your interface language affects only your own screen. It has no effect on your projects.

A key is one piece of text in your product, identified by a name your code uses — its source text, its context and any parameters belong to the key.

An entry is one translation of one key into one language. A key in a project with five languages has up to five entries.

Use dot notation to namespace them, for example checkout.summary.total. It keeps related strings together and makes the list navigable once you have hundreds.

Context describes where and how the text is used — “button on the empty cart screen”, “column header, max 20 characters”. Translators cannot see your product while they work, and context is the difference between a correct translation and a merely plausible one. It is also carried into the exported ARB files.

Declare them as parameters on the key, written in braces in the text: Hi {name}, you have {count} items. Translators see them as protected tokens they can move around but not break.

A parameter can be typed as String, int, double, num, DateTime or Object. Leaving the type off means String. Types are carried into the ARB output, so typed code generators pick them up.

They are the three stages of one translation:

• Draft — saved, still being worked on.
• In review — the translator has submitted it and is asking for a check.
• Approved — a reviewer has accepted it. This is what you want everything to be before you publish.

A reviewer can also request changes, which sends it back with a note explaining what to fix.

That the key has no entry at all in that language yet — nobody has written anything. It is not a fourth status; it is the absence of one. Untranslated keys still appear in published files, with an empty value, so a release never silently drops a key.

It means the source text changed after this translation was written, so the translation may no longer say the right thing. Localeo records what the source looked like when each translation was saved and compares it with the source now.

Changing the base-language value, the key name, the context or the parameters is what triggers it. Re-saving the translation clears it — that is your confirmation that you have looked and it is still right, whether or not you changed a word.

Outdated does not reset the status. An approved translation that goes outdated stays approved, so “outdated” overlaps the other counts rather than being separate from them. You can filter the translations table by it.

They are the two directions of the same conversation, attached to one translation:

• Note for the reviewer — the translator explaining a choice, or flagging a doubt.
• Feedback for the translator — the reviewer explaining what needs changing. Posting feedback is what puts the “changes requested” banner on the translation.

Comments attach to a translation, not to a key, so save the translation first — until then there is nothing for the thread to hang on.

Type @ in a note or feedback and pick someone. They get an email containing the comment, unless they have turned mention emails off. Mentions are resolved on our side from the people actually eligible for that translation, so a mention always reaches a real participant.

The picker only offers people who can act on that translation: contributors assigned to that language, plus the project’s managers. If someone is missing, they are usually not assigned to the language yet — add them under Project → Languages → Manage contributors and they will appear.

No. While you have a project open, Localeo pushes changes to keys, translations and releases as they happen, so two people working on the same language see each other’s work without reloading.

It writes first drafts. You pick a source language and one or more targets, and Localeo generates a translation for every key that has none yet. Each one lands in the translations table as an ordinary draft, marked with an AI badge.

That is the whole feature. It does not approve anything, does not publish anything, and does not change your review process — a person still reads every string before it ships, exactly as if a colleague had typed it.

No. AI translation runs on servers Localeo operates in the EEA. Your source strings and the generated translations are never sent to a third-party AI provider, and are never used to train any model — ours or anyone else’s.

This is the main reason the feature is built the way it is. Your content stays inside the same infrastructure, under the same data processing agreement, as the rest of your Localeo data.

No. AI writes only where nothing exists. A key that already has a translation in that language is skipped and reported as skipped, so an approved string can never be touched by it. This also means running the same job twice is harmless — the second run finds the translations already there and does nothing.

Yes, and there is no way to skip it. Everything arrives as a draft and moves through the same draft → in review → approved workflow as human work. You can filter the translations table to AI-generated entries to review them as a batch. The AI badge stays on the entry even after someone edits it, so it is always clear where a string started.

Project managers and translators. Generating a draft is writing a translation — it just saves the typing — so it needs the same access as writing one by hand. Developers and viewers cannot start a job.

Everyone on the project can still see which translations came from AI — the badge on a translation is not restricted, so a draft never appears without an explanation of where it came from. The job history and the controls that start a job are limited to the two roles above.

One thing that surprises people: organization owners and managers count as project managers on every project, so they can start a job even on a project where they hold no explicit role. See that question.

They are checked, not trusted. Every generated translation is compared against its source: it must contain exactly the same set of placeholders, with the same names. Word order may change — {count} items becoming elementi {count} is fine — but a placeholder that is renamed, dropped, invented or translated fails the check.

A translation that fails is retried on its own, and if it fails again it is discarded rather than saved. You get a count of what failed instead of a broken string in your table.

No, and deliberately. A variant exists to override its parent language where the wording genuinely differs, so generating one would replace correct Dutch with speculative Flemish for every key — the opposite of what a variant is for. Variants are left out of the language picker entirely; translate the parent language with AI, then write the handful of variant overrides yourself.

AI translation works on source strings up to 500 characters, which covers almost all interface text. Longer entries are skipped and counted, so you can see exactly which ones need doing by hand. Keys with no source text are skipped too — there is nothing to translate from.

One generated translation counts as one, whatever its length. Nothing else counts: translations that were skipped, failed or cancelled cost you nothing. Your plan’s monthly allowance and what you have used are shown on the Usage page and on Settings → Billing.

A job that would exceed the allowance is refused before it starts, rather than running partway and stopping, so it can never produce a surprise charge or a half-translated language. You can buy extra translations from Settings → Billing; they never expire and are used only once the monthly allowance is gone.

Good enough to save a translator most of the typing, not good enough to publish unread — which is why it only ever produces drafts. Quality is strongest on widely-spoken European languages and falls off on smaller ones.

If a language is not up to standard we leave it out of the picker rather than hand you a draft you cannot trust, so the languages offered may be fewer than the languages you can add to a project.

On the project’s translations screen choose Import translation keys and upload a .csv file. It needs a header row; column order does not matter and column names are not case-sensitive.

• key — required, the key name.
• description — required, the context for translators.
• value — optional, the base-language text. Supply it and translators have something to work from immediately.

Write them inline in the value, with the type after a colon: You have {count:int} new messages. Localeo registers the parameter and its type, and stores the text with the type stripped, so the string itself stays clean.

Only that row is skipped. Rows are imported independently, and the result tells you how many were imported, how many were skipped and what was wrong with each one — so a single typo never costs you the whole file. Fix the reported rows and import again.

By publishing a release and downloading its files. There is currently no CSV or spreadsheet export — releases are the supported way content leaves Localeo.

That is a deliberate shape rather than a missing button: a release is a fixed, versioned snapshot, so what you download is exactly what your app is running, not whatever the table happened to say this afternoon. If you need a one-off dump for another purpose, email [email protected].

A snapshot of your translations at a moment in time, with a name, a tag such as v1.2.0, and optional notes. Publishing it compiles the translation files and puts them on the CDN.

A tag is immutable. Later edits to translations do not rewrite a release you have already published — that is the whole point of having them. Ship a correction by publishing a new release.

Three, always all three, for every language in the project: .json, .yaml and .arb. The ARB files carry each key’s description and parameter metadata, for Flutter and other toolchains that read it. Use whichever your stack wants and ignore the rest. Every project language gets a file even if nothing is translated yet, so a URL you have wired up never suddenly 404s.

Open Project → Releases and use the downloads dialog on a published release. It lists a direct URL per language and format, ready to copy into your build or fetch at runtime. The path is shaped like /p/{project}/r/{release}/{language}.{format}.

Yes — the same path with latest in place of the release identifier. It re-points to the newest published release every time you publish, and it is stable, so you can hard-code it.

The trade-off is caching. latest is cached for about a minute so a publish rolls out quickly; a pinned release URL is cached indefinitely, because its contents can never change. Pin the release when you want a build to be reproducible, use latest when you want copy fixes to reach users without a deploy.

No — treat them as public. They are unguessable, not authenticated: the identifiers in the path are long random strings, but anyone holding the link can fetch the file without signing in, and the link does not expire.

That is intentional, because your app has to fetch these files from users’ browsers and devices without a secret. Just do not put anything in a translation that you would not publish. If a link is shared somewhere it should not have been, contact [email protected] and we can rotate it.

Because a release records the languages that existed when it was published, and stays that way — that is what makes it a snapshot. Publish a new release and the new language is included. If you use the latest URL, it follows the newest release, so it picks the language up as soon as you publish.

Go to Organization → Members and choose Invite member. Enter their email and the organization role you want them to have. You can add them to a project in the same step, or skip that and assign project access later. They get an email with a link.

Invitations are valid for 7 days. If it has lapsed, or the email never arrived, simply invite them again from Organization → Members. Ask them to check their spam folder, and to sign in with exactly the address you invited — the invitation is tied to it. Once signed in, they can also accept from Invitations in their account menu, without needing the email at all.

There are two levels. In the organization:

• Owner — full control, including billing. Created with the organization; you cannot invite someone directly as an owner.
• Manager — runs the workspace day to day, and can see billing.
• Member — belongs to the organization and works on the projects they are added to.

And on each project:

• Manager — looks after the project. The only role that can change its settings, members and languages, and the only one that can do everything the roles below can.
• Developer — the integration side: API tokens, webhooks, releases, and adding translation keys. Deliberately cannot write translations.
• Translator — the language side: writes and reviews translations, and can add keys.
• Viewer — read-only. Can see the project and its translations, and change nothing.

Developer and translator are siblings, not a ladder. They cover two different surfaces — shipping the strings versus writing them — so neither is senior to the other, and only a manager holds both. That is why a developer cannot translate: it is not a lesser permission, it is a different job.

By design: organization owners and managers count as project managers on every project in the organization, so they never have to add themselves one at a time. That is also why they are not offered in the list of people to add to a project — they are already there.

From Organization → Members you can change someone’s organization role or remove them entirely. From Project → Members you can change their project role, change which languages they are assigned to, or remove them from that one project while they stay in the organization. Work they have already done stays where it is.

Two things: how many translation keys a workspace can hold, and how many translator seats it has. Projects, languages, releases and webhooks are not capped, under fair use. The current numbers for each plan are shown when you choose or change a plan, and what you are using right now is on Organization → Usage.

Settings → Subscription & Billing, then Change plan. Upgrades — and switching from monthly to yearly — take effect once paid: you are charged the difference for the remainder of your current period, and the new limits apply as soon as the payment confirms.

Nothing immediately, and nothing to pay. Downgrades — and switching from yearly to monthly — are scheduled for the end of your current billing period; you keep what you are already paying for until then. The pending change is shown on the billing page, and you can call it off at any point before it takes effect. Check Usage first if you are dropping to a smaller plan.

Settings → Subscription & Billing → Cancel subscription. Your workspace stays fully active until the end of the period you have already paid for, and then does not renew. Nothing is deleted on cancellation, but access becomes limited — so publish any release you still need, and grab your files, before that date.

Settings → Subscription & Billing, under billing history — every payment with its status, and a PDF invoice to download. If a payment failed or is still open, there is a link there to complete it.

No. Prices are shown excluding VAT, which is added on top at your billing country’s rate — 21% for the Netherlands. Your invoice shows the net amount, the VAT and the total.

The organization has no active subscription — usually a cancellation that has run its course, or a payment that did not go through. An owner or organization manager can put it right from Settings → Subscription & Billing, by completing the outstanding payment or starting a plan again. If that is not you, ask whoever owns the workspace.

Yes — a read-only public API for pulling your published content into your own systems. It lists projects, project languages and releases, and returns a single release with its download URLs. There is no write API: content is created in the app, not over the API.

Full reference, examples and error codes are in the developer documentation.

Project → API Tokens → Create token. A token belongs to one project, and the full value is shown only once, at creation — copy it into your secret store there and then, because we keep only a hashed copy and cannot show it to you again. Lost it, or leaked it? Revoke it and create another. The list shows when each token was last used.

1,000 requests per hour per token. Every response carries headers telling you your limit, what is left and when the window resets; go over and you get a 429 with a Retry-After. Note that rejected requests still count — a loop retrying with a bad token will exhaust the quota, so handle errors rather than hammering.

API responses are cached for about a minute, and that cache sits in front of authentication — so a request identical to one made just before you revoked can still be answered from cache for up to a minute afterwards. It stops on its own. If a token has genuinely leaked, revoke it (the exposure is bounded to that minute) and treat anything it could reach as public.

Set them up under Project → Integrations. Ten events are available:

• Keys — created, updated, deleted.
• Translations — created, updated, approved.
• Releases — created, updated, published, deleted.

Release published is the one most teams want: it is the trigger for pulling fresh translation files into a build or cache. Failed deliveries are retried automatically.

Give the webhook a secret when you create it. Each request is then signed with HMAC-SHA256 over the payload, and your endpoint recomputes the signature with the same secret and compares before trusting the body. Anyone can POST at a public URL, so if the webhook triggers anything that matters, verify it.

Settings → Account, under interface language. It applies to you only, everywhere you sign in.

Settings → Notifications. There are four switches, all on by default:

• Weekly contributor digest — your progress on the languages you work on.
• Weekly manager overview — activity across the projects you manage.
• Assignments & mentions.
• Mentions — when someone @mentions you on a note or on review feedback.

You will only see the ones that apply to your roles. Weekly emails go out on Monday mornings.

Yes — the toggle in the top-right of the app switches between light, dark, and following your operating system. It defaults to matching your system.

Those come from however you sign in, so they are managed there rather than in Localeo — in your Google account if you signed in with Google, or through the password reset link on the sign-in page if you use email and password. Localeo never sees or stores your password.

Settings → Account, in the danger zone. Note that your account is deactivated rather than erased, so get in touch with [email protected] if you need it back — or if you want your data permanently erased, which we handle on request. Deleting your account does not cancel an organization’s subscription; if you are the owner, cancel that first.