Frequently asked questions

No. It works on React and Next.js, React Native and Expo, Flutter, Angular, Vue and Nuxt, Svelte and SvelteKit, Astro, Solid, Qwik, Lit, Ember, Electron and Tauri, plain HTML sites, Rails, Django and Laravel templates, and Android layouts and Jetpack Compose. It sets up the matching i18n library for each: react-i18next, ngx-translate, vue-i18n or @nuxtjs/i18n, svelte-i18n, ember-intl, Flutter’s gen-l10n, Rails I18n, Django’s gettext, Android string resources, or a small script for static pages.

Yes. localize-dev translate fills in the missing translations in the locale files you already have, in any stack: JSON (i18next, react-intl, vue-i18n, ngx-translate), Rails YAML, gettext .po, Flutter .arb, Android strings.xml, Apple String Catalogs and .strings, and browser-extension messages. Code isn’t touched, existing translations aren’t changed, and in CI it opens a pull request whenever new keys land.

Only Node.js 22 or later to run the CLI: npx localize-dev runs it without adding a package.json to your project. Or skip local runs and use the GitHub Action, which runs on GitHub’s machines.

Yes. localize-dev sync push uploads your source locale files and sync pull brings translators’ work back into them, so machine translations, human review and your repo stay in step.

Yes. Run it from the root with --workspaces, or set workspaces: true in the GitHub Action, and every app is localized with its own locale files, in one pull request. Shared libraries without a dev or start script are left alone.

In Next.js, SvelteKit and Nuxt, pages render in the visitor’s language on the server. For static HTML sites, turn on htmlPages and Localize.dev writes a translated copy of every page per language, linked with hreflang, so each language can be indexed.

Only the strings being translated are sent to the Localize.dev API, with their file path and where they sit (the component, and the element such as a button or heading) as context. Whole files are never sent. Rewriting happens locally (or on your own CI runner), and scans and offline runs never touch the network.

No. Translation runs on the hosted Localize.dev model on every plan, including Free. Create an API key, run localize-dev login, and you’re done.

No. If your app has none yet, the pull request adds the right one (lockfile included), creates a module that loads every locale file and picks the language, and wires it into your entry file. Right-to-left languages set the page direction too. Apps that already have i18next, vue-i18n or svelte-i18n running keep their own setup.

Existing t(), $t() and $_() calls are left as they are, and keys already in en.json are reused when the text matches (for short copy like "Post", when the translations match too). It's safe to run on half-localized code.

It translates with context. Each string reaches the model with its file, component and element, so "Post" on a button becomes "Veröffentlichen" in German and "Post" as a card title becomes "Beitrag", each with its own key; identical copy shares a key only when its translations agree. Your glossary and style notes keep product terms and tone consistent, including a formal or informal "you" per language, and plurals get every form each language needs. Laravel and Django catalogs are keyed by the English text itself, so there one text has one translation.

The workflow file above and one repository secret, LOCALIZEDEV_API_KEY. It uses the built-in GITHUB_TOKEN with write access to contents and pull requests, keeps one pull request per branch up to date instead of opening a new one each push, and skips its own branches and pull requests from forks, whose token is read-only.

They are a strong first draft with correct placeholders and consistent keys. For regulated or brand-critical copy, assign a reviewer per language: they get an email when a run lands, approve or correct each translation on the Review tab, and corrections go into the open pull request and every later run. Corrections that keep coming up become glossary terms in one click.

One unique piece of UI copy sent for translation. A string counts once however many languages it goes into. Translating “Place order” into 10 languages uses 1, not 10. Copy that already has a key is never sent again.

The run stops before writing anything and tells you why, so your code is never left half-rewritten. Upgrade, or wait for the allowance to reset at the end of your 30-day period, and run again. The dashboard shows the date.

No. Scans and --offline runs work entirely on your machine and never call the API. You don't need a key for them at all.

No. The Action works on every plan, including Free. Add your API key as a repository secret and it opens a pull request on each push, within your plan's 3/10/50 languages per run.

Yes. The playground runs the same engine on a component or page you paste (React, Vue, Svelte, Angular, Astro, Flutter, Rails, Django, Laravel, Android or HTML), no account needed.

Delete your personal workspace in Dashboard → Settings. That deletes your account with it: your login, linked GitHub and Google sign-ins and team memberships, and you are signed out on every device. If you own team workspaces, delete those first. Strings used this period still count if you sign up again with the same email.

Yes. Email support@uselocalize.dev from the address on your account and we’ll send it. The Privacy Policy lists what we keep.

Email support@uselocalize.dev with what you ran and what you saw. For security issues, please email rather than posting the details publicly.