How Babelize Works

When you start a babel (one translation pass over your project), here's what happens under the hood. The same pipeline runs in the cloud for dashboard and babelize run start babels, and on your machine for npx babelize.

The pipeline

Validate → Extract → Key generation → Locale files → Lockfile → Translate → Inject → Format inject → Finalize → Summary

Which steps run depends on the framework Babelize detects. Static HTML and Django skip format injection.

1. Validate

Babelize detects the framework (React, Next.js, Django and static HTML/CSS/JS; Vue and React Native in beta), the i18n library and the locale files you already have, discovers the source files, and checks dependencies.

2. Extract

Translatable text is found in your source files (.js, .jsx, .ts, .tsx, .vue, .html) with AST-based parsing; Django .py files and templates are read with a dedicated tokenizer:

• JSX text content and translatable attributes (e.g. placeholder, title, alt, label)
• Sentences split across elements become one message, so they're translated as a whole
• Variables and string interpolations are preserved as placeholders; counts become plural messages
• Values your code uses as data (IDs, statuses, colors, types) are left alone

3. Key generation

Every text gets a clean, unique i18n key. Keys you already have are reused.

4. Locale files

Reads and updates the source locale file (for example en.json), keeping your existing keys and translations.

5. Lockfile

The lockfile records each source string and its translations. It sorts keys into unchanged, new, changed and missing, so only new and changed text is translated. This is what makes later babels fast and cheap.

6. Translate

For each text that needs translating:

1. Your edits from Results and matches from translation memory are reused first
2. Glossary terms are applied ("Never Translate" and "Always Translate As")
3. The rest is translated with Babelize's translator (a dictionary of common interface phrases, then the NLLB model), or with your own key (Anthropic, OpenAI, Gemini, Groq, OpenRouter), using the surrounding code as context
4. Every result is checked (placeholders, tags, plural forms, glossary terms, text returned untranslated). A string that fails isn't written and is retried on the next babel

7. Inject

Wraps the extracted text in your framework's translation calls (like t()), adding imports and hooks as needed. Only the lines with translated text change.

8. Format inject

Where you turned it on (Configure → General → Formats), wraps hardcoded dates, prices and numbers so they're formatted for each language.

9. Finalize

Adds the i18n setup if it's missing (for example i18n.ts, the provider wiring and the i18n dependency) and prepares the output.

10. Summary

Counts files scanned, texts found and translations made, and lists any issues (strings that failed checks, right-to-left and length warnings).

Output

• One locale file per target language, matching your project's i18n structure: JSON for JavaScript projects, gettext .po catalogues for Django
• The code changes that use those files
• For GitHub projects, a pull request with a table of languages, how to try it, and a checklist of what to check before you merge. ZIP projects get the translated project to download

You can review all of it in the app first. See Results.

Stable translations

Unchanged text keeps its translation from one babel to the next: the lockfile and translation memory reuse it instead of translating it again. A translation changes only when its source text changes, a glossary rule that applies to it changes, you edit it, or you choose Re-translate everything.

Processing Times

Times vary based on repository size, number of target languages, and current system load. Later babels only translate what's new, so they're usually much faster.