Troubleshooting

My translation PR looks wrong: what do I do?

The pull request from globalize.now is the first time you see real output. If something looks off, most fixes are a project setting or a tab, not a support ticket. Fastest fix of all: edit the translation in the PR diff. Your edit becomes the approved version and goes into the translation memory, so it's reused next time and never re-translated. The translations sound wrong or unnatural - Wrong tone (too formal, too casual, wrong register): open Project → Style Guides and set the tone and formality for that language (for example du vs Sie, tu vs usted). If the language has no style guide yet, the dashboard drafts one from your own source content in one click; edit and save. The next job follows it. - Brand terms, product names or legal wording translated: add them to Project → Glossary with the required translation (or "keep in English") per language. Glossary terms are protected during translation. You can import a list in bulk. - Idioms translated literally: fix the string in the PR, and add a note in the language's style guide about how you want that kind of phrase handled. - The same string translated differently in two places: the translation memory reuses approved translations. Approve the version you want (edit it in the PR, or push it to the repo), and it wins from then on. Details on all four tools: How do I control tone, terms and quality? The translations are empty or contain key names instead of text If a locale file contains "" or key names like "checkout.submit": "checkout.submit", the translation job didn't run or failed. 1. Open the project dashboard and check the job for this PR. A failed job shows its error and can be retried. 2. Check Project → Settings → Repository → Watched branches: the branch you pushed to has to be on the list for a job to start automatically. Or run a manual job on that branch from the dashboard. 3. If credit has run out, translations pause and the app says so — see How is billing calculated? The PR is missing strings from my app If some strings are translated but others are still hardcoded, the conversion missed them. Common reasons: strings inside config objects (form labels, error messages, toast notifications); strings in files changed after the conversion ran; deeply nested component patterns. Fix: in your coding agent, ask it to finish wrapping the strings it missed: wrap the remaining hardcoded strings The agent re-scans, adds the missing keys without duplicating existing ones, and your next push to a watched branch translates them. Wrong strings are being translated If URL slugs, database field names or internal identifiers show up as translated strings, the wrong content was extracted. Open your source locale file and remove the keys that shouldn't be there. Then tell your agent: Do not translate strings in [path/to/file.ts] The PR changes files I didn't expect A translation PR only contains locale files. If you see other changes, it's usually locale files placed in a non-standard location during setup: review the diff, merge what's correct, move files to where you want them and update the locale path patterns in project settings. If something looks completely wrong, close the PR without merging — your default branch is untouched. Then chat with us at globalize.now with the PR link and we'll review what happened.

My translation job failed or shows an error

Need help fast? Chat with us at globalize.now — hit the chat icon on any page. Job shows "Failed" A failed job shows its error in the project dashboard and can be retried from there. The usual causes: - Repository access. The Git account you connected no longer has write access to the repo, or the repository connection was revoked. Reconnect it under Project → Settings → Repository. - Credit ran out. Translations pause and the app tells you why. Top up or upgrade under Settings → Billing, then retry the job. See How is billing calculated? - Budget limit reached. If you set a monthly limit under Project → Settings → Budget, jobs are rejected once it's hit — raise the limit or wait for the next month. If the error isn't one of those, chat with us with your project name and job ID. Re-scan shows "no i18n files detected" If you trigger a re-scan and the app shows "no i18n files detected", the job may already be running in the background — the status just hasn't updated yet. What to do: wait a few minutes and refresh. Check your repository for a new pull request — that's the clearest sign the job ran. If nothing changes after 10 minutes, check the locale path patterns in project settings match where your locale files actually are, then chat with us. Job shows "Completed" but contains an error The job likely partially succeeded — the strings were translated, but something went wrong at the commit or pull-request step. 1. Check your repository first. If a PR exists with the translated locale files, the translation worked and the error is about the repo connection. 2. If no PR exists, chat with us with your repo name and job ID. Common cause: an account mismatch — globalize.now connected with one GitHub or GitLab account while the repo belongs to another. The connected account needs write access to the repository. A translation job ran when I didn't expect it Jobs start on three triggers, all of them settings you control: - Pushes to watched branches — Project → Settings → Repository → Watched branches. Remove a branch from the list and pushes to it no longer start jobs. - Translate pull requests — if it's on, new strings in a PR are translated onto the PR branch. Turn it off, or turn on Skip draft pull requests, if you want to control the timing. - Manual jobs you run from the dashboard. The first job after connecting a repo translates everything that's already there, which is the largest job you'll see. To cap spend, set a monthly limit under Project → Settings → Budget: jobs are rejected, not silently run, once it's reached. If a job ran and the cost surprised you: Settings → Billing shows what each job cost per language. If something looks off, chat with us with the job ID — we'll review it and credit your account if appropriate.

Setup stalled or producing unexpected output

If your agent is going off-script — writing long explanations instead of making changes, proposing the wrong i18n library, asking questions the skills should already know — it's likely lost the skills context. This is recoverable. How to recognize it - The agent writes long explanations instead of making code changes - It proposes a different i18n library than the one selected - It starts asking questions the skills should already know how to answer - Output looks inconsistent with earlier steps in the same session Recovery steps Step 1 — Refresh the skills npx skills add --all globalize-now/globalize-skills This re-installs the skill files and resets the agent's localization context. Step 2 — Re-ask for setup Set up i18n for my project The globalize-guide skill rescans from the current state of the repo and resumes the journey. It won't duplicate work already completed, it picks up where the code is. New translation keys merge back into your locale files, and keys from the previous partial run are preserved. Step 3 — Verify Use the verification steps to confirm the output looks right before calling it done. The conversion step is just taking a long time If the conversion step seems to be running for 30–45 minutes without obvious activity, that's normal on a large codebase. Don't cancel the session. Check your editor's source control panel — if files are still being modified, it's working. Interrupting mid-conversion leaves your codebase in a partial state. Prevention - Run setup steps in order, don't skip ahead - Keep your session focused — avoid mixing i18n work with other code changes in the same agent context - On very large repos (100+ components), break conversion into batches: "Convert only the /src/components directory first"

npx skills add isn't working

Using the app? If you connected your repo at globalize.now, you never run this command — skills are only for the agent path. This article is for people installing the globalize skills into their own coding agent. npx skills add --all globalize-now/globalize-skills is the install command. It uses the open skills CLI to copy the globalize.now skills into your AI coding agent. Here's what to check if it doesn't work. No agent detected If the CLI can't find a supported agent, it asks which one to install to. Pick yours from the list, or skip the prompt by naming the agent directly: npx skills add globalize-now/globalize-skills -a claude-code Swap claude-code for cursor, codex, or github-copilot as needed. Where the skills land The install location depends on your agent: - Claude Code: .claude/skills/ - Cursor, Codex, GitHub Copilot: .agents/skills/ After a successful install you'll see the globalize.now skill folders there: globalize-guide, globalize-now-cli-setup, globalize-now-cli-use, and css-i18n. Start a fresh agent conversation so it picks them up. Permission or symlink errors By default the CLI symlinks the skills into your agent's directory. If your environment blocks symlinks (some Windows setups, locked-down corporate machines), force plain copies instead: npx skills add globalize-now/globalize-skills --copy If you hit a write-permission error, make sure you have write access to the project directory, or install to your user directory with -g. Node.js The skills CLI runs through npx, which needs Node.js. If npx itself errors, confirm Node is installed with node -v. Node 18 or newer is recommended. Manual install You can always copy a skill in by hand. Browse globalize-now/globalize-skills on GitHub and copy the folder you need into your agent's skills directory, for example: cp -r skills/globalize-guide /path/to/your/project/.claude/skills/globalize-guide The skill is available the next time you start an agent conversation. Still stuck? Open a chat with support and share your Node.js version (node -v), your agent (Claude Code, Cursor, Codex), and the exact error. We'll get you unblocked.