Localizing Antigravity into Japanese is not a single setting. The classic confusion — "I chose Japanese in Settings, but the AI still replies in English" — happens because UI language and AI response language are configured separately.
As an indie developer maintaining the Dolice Labs sites in both Japanese and English, Antigravity is my daily tool — and once I understood how the layers split, the configuration guesswork disappeared.
This guide walks through localization as five layers — UI, AI responses, prompting, IME, and encoding — in the order you actually touch them.
Layer 1: UI Language — Start with Settings → Language
There's only one thing to do right after installing: open Settings, set "Language" to Japanese (or your target language), and restart. Menus, dialogs, and button labels switch over.
This applies to Antigravity as a whole, not per project, so moving between projects won't mix languages.
Note that since Antigravity 2.0, the language pack, command palette, and AI response language are configured as three separate settings. If you're on 2.0, the Antigravity 2.0 Japanese UI setup guide has the exact steps.
Layer 2: AI Response Language — Why the UI Is Japanese but Replies Are English
Switching the UI doesn't change the chat agent's response language — that's a separate setting. If replies stay in English, either set the response language to Japanese in settings, or add a line to your project's custom instructions: "Always respond in Japanese."
I prefer writing it into a project settings file, because the behavior survives switching machines and stays identical when a teammate clones the repo.
// Project custom instructions (example)
Always respond in Japanese.
Write all prose, plans, and comments in Japanese.
Keep variable names, function names, and commit messages in English.
That last line matters more than it looks. Once you steer responses toward Japanese, the model occasionally tries to write variable names and commit messages in Japanese too. Drawing an explicit line — "natural language in Japanese, code vocabulary in English" — keeps things stable.
When you want it everywhere, not per project
If you want the same behavior across every project, it's easier to set a global rule once than to repeat per-project instructions. Register "always respond in Japanese" as a global rule, and even freshly opened projects answer in Japanese from the first turn. Write project-specific instructions only when you need to override that.
In my own setup, the global rule fixes "prose in Japanese, code vocabulary in English," and only the projects where I draft the English version of an article override it with "respond in English here." Since adopting this two-tier approach, the response language stopped drifting as I move between languages.
Layer 3: Prompting in Japanese — Keep Technical Terms in English
Japanese prompts are plenty accurate, but how you write them changes the result. In rough order of impact for me:
First, specificity. "Create a button" gets you much less than "Create a React button that calls an API on click and shows a spinner while loading." This is true in English too, but Japanese tends to drop subjects and objects, so it's worth consciously filling them back in.
Second, don't force-translate technical terms. A mix — concepts in English, requirements in Japanese — communicates best, e.g. "a React component using Redux for state management." Replacing "Redux" or "state" with a Japanese rendering only blurs the intent.
Third, use bullet points once you have more than three requirements. Line-separated bullets are recognized one item at a time, so fewer requirements get dropped than when you string them into one long sentence.
Layer 4: Japanese IME Quirks
Antigravity works with the Windows IME, macOS Japanese input, and fcitx on Linux. Still, the in-progress conversion string and editor completion do occasionally collide. If pre-commit characters get stolen by tab completion or conversion gets garbled, the guide on fixing Japanese IME conversion issues has OS-by-OS fixes.
As a day-to-day precaution, when writing a long Japanese comment, confirming one phrase at a time tends to cause fewer problems than drafting it in a notes app and pasting it in — that's what I've found from heavy use.
Layer 5: Garbled Text and Unifying on UTF-8
Garbled Japanese is almost always caused by inconsistent file encoding. Dropping an .editorconfig at the project root that pins UTF-8 keeps everyone on the same state.
# .editorconfig
root = true
[*]
charset = utf-8
Especially in projects that carry Shift_JIS files brought over from an old Windows environment, the context breaks the moment the AI reads such a file — so align encoding before touching any localization settings.
When only some files garble, suspect that those files aren't actually UTF-8. On macOS or Linux the file command checks this quickly.
# Check encoding (look for anything other than UTF-8)
file -I src/*.ts
# → anything other than charset=utf-8 (shift_jis / iso-2022-jp, etc.) needs convertingIf you find Shift_JIS files, convert them to UTF-8 in bulk with iconv so that both the AI and people read the same characters from then on.
iconv -f SHIFT_JIS -t UTF-8 legacy.ts -o legacy.utf8.tsVerifying the Setup Took Effect
After configuring the three layers (UI, AI response, encoding), it's reassuring to confirm they actually took. I always check in this order.
First, are the UI menus in Japanese? You can see that at a glance. Second, ask the agent a single question — "what's your current response language?" A Japanese answer means the response layer is wired up. Third, write one line of Japanese comment, save, and reopen to confirm it doesn't garble. With that, the foundation for a Japanese environment is in place.
When only the responses revert to English, it's usually the global setting from Layer 2 and a project instruction canceling each other out via an override. Temporarily removing the project-side instruction isolates which layer is responsible.
Symptom Quick Reference
A cheat sheet for guessing the cause first when you're stuck.
- UI is Japanese but the AI replies in English → Layer 2 (response language, or project instruction)
- Variable names and commit messages turn Japanese too → the "code vocabulary in English" line is missing from Layer 2
- Typing Japanese gets characters stolen by completion → Layer 4 (IME vs. completion collision)
- Only specific files garble → Layer 5 (that file is still Shift_JIS)
- New projects keep reverting to English → no global rule set (the two-tier approach in Layer 2)
Japanese Comments Double as Context for the AI
Japanese comments in your code are read correctly by Antigravity. Beyond that, they work as context supply for the AI.
// Initialization when a user visits the page
const initializeApp = () => {
// Load user settings from local storage
const userSettings = localStorage.getItem('userSettings');
// Fetch user info from the API
fetchUserData();
};Writing your intent in comments nudges the model's suggestions toward your requirements when you ask it to continue the implementation. In my projects I leave "why it's done this way" comments in Japanese, and both my future self and the AI end up leaning on them months later.
The settings work comes down to just three things: UI language, AI response language, and encoding. Lock those three first, then gradually bend your prompting toward your own style — that roundabout-looking path is, in my experience, the fastest way to a Japanese setup.