If you install Antigravity 2.0 and reach for the Japanese Language Pack the same way you would in VS Code, you end up in a confusing middle state: menus are in Japanese, but the AI chat responses are still in English, the command palette is a half-translated mix, and parts of the settings page still show their English section labels. I have been an indie developer at Dolice since 2014, running six sites in production, and the first few days after the 2.0 release I lost time on this — I couldn't tell whether I was misconfiguring it or whether the localization was incomplete.
The short version: Antigravity 2.0 has three independent localization layers. Configure all three in order and the entire experience settles into Japanese. There are also a few places worth keeping in English on purpose, and I will explain which and why based on six months of running both single-developer and shared-team repositories.
The three layers to think about
- UI language pack: menus, status bar, tabs, notifications
- Command palette dictionary: the language of the entries that appear in
Cmd+Shift+P - AI response language: chat agent replies, inline completions, planning view narration
Set only layer 1 and you have a Japanese-looking IDE talking to you in English. Add layers 2 and 3 and the experience becomes coherent.
Installing the UI language pack
Identical to VS Code:
1. Cmd+Shift+X (macOS) / Ctrl+Shift+X (Windows/Linux) to open Extensions
2. Search for "Japanese Language Pack"
3. Install the official "Japanese Language Pack for Antigravity"
4. Cmd+Shift+P → "Configure Display Language" → select "ja"
5. Restart the IDE
After this, the menu bar, sidebar, and status bar speak Japanese. The command palette and AI still don't.
Command palette: localized, with English aliases
The second layer is controlled by these settings:
{
"antigravity.commandPalette.language": "ja",
"antigravity.commandPalette.showEnglishAlias": true
}I strongly recommend showEnglishAlias: true. Every translated command shows its English name in parentheses afterward. This solves a real problem: command palette search is fast precisely because you can type partial English commands without IME switching. Forcing yourself to type Japanese into the palette for a command you knew by its English name is a regression in practice.
My own habit:
- Daily commands (Save, Find, Replace, Go to Definition): type in English
- Rarely-used commands (Configure Display Language, Reset Workspace State): the Japanese label is helpful
The aliases let me have both.
AI response language — the layer most people forget
The third layer is what fixes the "Japanese-looking IDE that talks to you in English" feeling:
{
"antigravity.ai.responseLanguage": "ja",
"antigravity.ai.codeCommentLanguage": "ja",
"antigravity.ai.planningView.language": "ja"
}These are three settings on purpose:
responseLanguage: chat agent's reply languagecodeCommentLanguage: language of comments the AI emits in generated codeplanningView.language: planning view (task plan) display
I usually keep codeCommentLanguage in English. For repositories that may be shared with collaborators or eventually open-sourced, English code comments age better. For my four Next.js lab repos that are private indefinitely, all three go to Japanese. For the Lacrima / Mystery WordPress themes that I might distribute later, only codeCommentLanguage is set to English.
Three places that will stay in English no matter what
These aren't translation bugs — they're intentional or technically unfixable:
- Error message tails: "ENOENT: no such file or directory" — the part bubbling up from the runtime
- Setting keys and command IDs:
antigravity.ai.responseLanguageitself - Extensions that don't support i18n: those keep their own English labels
Treat these as permanent. Honestly the English error message tail is more searchable on the web anyway.
When the AI starts switching to English mid-conversation
Even with responseLanguage: "ja" set, longer or more technical conversations sometimes drift to English mid-thread. Three usual causes:
- The files in context contain lots of English comments → the AI infers the conversational language from context
- You pasted an English error message earlier in the thread → same drift
- Your custom system prompt is in English
The fix is to make the language directive explicit at the start of the conversation, or — better — in a project-level .antigravity/system-prompt.md checked into git: "respond in Japanese at all times. Use Japanese for explanations, task plans, and comments outside of code blocks."
Exporting the setup so it travels with the repo
I prefer committing a project-local .antigravity/settings.json to relying on Settings Sync:
// .antigravity/settings.json — committed to the repo
{
"antigravity.commandPalette.language": "ja",
"antigravity.commandPalette.showEnglishAlias": true,
"antigravity.ai.responseLanguage": "ja",
"antigravity.ai.codeCommentLanguage": "en",
"antigravity.ai.planningView.language": "ja"
}I move between a desktop Mac and a travel MacBook regularly, and committing the file is more reliable than relying on sync. Cloning the repo, opening Antigravity, and getting the same language experience instantly is the single quality-of-life win that pays for the setup work.
June 2026 update — the Antigravity CLI and language settings after I/O 2026
At Google I/O 2026 on May 19, Antigravity 2.0 shipped as a stable release, adding an Antigravity CLI (written in Go, replacing the older Node.js-based Gemini CLI) alongside the desktop app. The CLI lets you launch agents straight from the terminal and run several subagents in parallel.
The response-language settings described above still apply in the CLI. Using the same approach as the GUI settings.json — response language set to Japanese, code comments to English — the terminal returns its task plans and summaries in Japanese too. In my own setup I keep a single source of truth in .antigravity/settings.json, committed to git, so the GUI and the CLI never drift apart.
If you also run a local LLM, the response language tends to follow the model more strongly. For how to pin the settings in that case, the local LLM selection guide for Antigravity (Ollama / LM Studio / Gemma 4) is worth a look.
Antigravity 2.0's Japanese localization is more configurable than VS Code's, but once the three layers are set, it stays out of the way. Hope this helps anyone wrestling with the half-translated middle state.
Update (July 2026): When Your Language Settings Revert After an Upgrade
Several readers have written to say their UI flips back to English right after updating Antigravity. In nearly every case the settings were not lost — the workspace settings are overriding the user settings.
If you commit .antigravity/settings.json to git and share it, that workspace value wins the moment someone opens the repository on another machine. Your local user preference for a Japanese UI loses to whatever the repository declares.
So I split the configuration into two layers.
- Keep in user settings: UI language (
locale), fonts, keybindings — anything that belongs to the person and their machine - Keep in workspace settings: AI response language, code comment language — anything that shapes the project's output
Since making that split, opening a shared repository no longer flips my interface. The same benefit applies if you are an indie developer moving between two machines.
If the problem is that Japanese input itself will not commit, or composition breaks mid-word, the cause is an IME and keybinding clash rather than a language setting — "Fixing IME Input Issues in Antigravity" walks through that separately. And if you want to eliminate machine-to-machine drift entirely by sealing the configuration inside a container, "Antigravity DevContainer: A Complete Setup Guide" is the place to start.