content_generate / generate_mind_map return French output — uiLocale defaults to 'fr' and overrides the language parameter

[Javiergomezdev]

Summary

content_generate and generate_mind_map produce output in French, ignoring the language parameter, because the UI locale is hardcoded to fr by default and leaks into the generation request.

The notebook, the sources and the Google account are all Spanish. Chat answers (notebook_ask) come back in Spanish correctly — only the generated artifacts are affected.

What gave it away

A transient failure surfaced the URL the server actually navigates to:

page.goto: net::ERR_CONNECTION_CLOSED at
https://notebooklm.google.com/notebook/<id>?hl=fr

?hl=fr is appended regardless of the language argument passed to the tool.

Root cause

src/config.ts:156 sets the default:

uiLocale: 'fr',

and parseLocale (src/config.ts:211-220) only accepts four values:

if (lower === 'fr' || lower === 'en' || lower === 'de' || lower === 'ja') {
  return lower;
}
return defaultValue;   // silently falls back to 'fr'

I understand why hl= is forced — the comment in src/session/browser-session.ts:81 and the test in src/__tests__/notebook-domain.test.ts:38 explain that text selectors are written against one UI language, and letting Google pick the account language would silently break them. That reasoning is sound. The problem is the side effect on generated content.

Steps to reproduce

1. Notebook with Spanish sources, Google account in Spanish.
2. content_generate({ content_type: "audio_overview", language: "Spanish", custom_instructions: "<in Spanish>" })
3. The audio is generated, but titled Vendre l'automatisation sans parler technique — French.

Same with generate_mind_map: every node comes back in French (Détection d'Opportunités, Règles d'Or, …) even though the sources contain no French at all.

generate_mind_map has no language parameter, so there is no way to steer it from the call site.

Impact

The tool succeeds and reports status: "ready", so nothing signals that the artifact is unusable. In my case the deliverable was sales onboarding material for a Spanish-speaking team — silently getting French back is worse than a hard failure, because it only surfaces when someone opens the file.

Workaround

Setting NOTEBOOKLM_UI_LOCALE=en in the MCP server env avoids French. Spanish is not selectable, since parseLocale rejects anything outside the four supported locales and falls back to fr.

Suggested fixes

Roughly in order of effort:

1. Do not let uiLocale reach the content-generation request. The selector-stability argument applies to driving the UI; it should not dictate the language of the artifact. If the generation flow can take a separate locale, pass the caller's language there.
2. Warn on silent fallback. parseLocale currently discards an unsupported value without a word. Logging NOTEBOOKLM_UI_LOCALE=es not supported, falling back to fr would have saved a long debugging session.
3. Give generate_mind_map a language parameter, matching content_generate.
4. Document the fr default and its effect on generated content in the README — it is surprising, and nothing in the tool descriptions hints at it.

Happy to test a patch. Thanks for the project — the dual RPC + Playwright fallback is what made me pick it over the alternatives.

---

Environment: @roomi-fields/notebooklm-mcp via npx -y, macOS, Claude Code.

[roomi-fields]

Thank you for this — the report is unusually good, and the part I want to single out is that you told me what convinced you rather than just what you concluded. That transient ?hl=fr in the error message is what let me reproduce this in minutes instead of days.

You were right on all four counts, and the cause turned out to be deeper than the one you found. Fixed in 3.1.1, along the lines you suggested.

What was actually happening

Three faults were stacked here, and each one alone was enough to produce French output.

1. uiLocale was choosing the content language — as you diagnosed. content_generate fell back to it, and generate_study_aid used it outright with no override at all. Output language is now its own setting (NOTEBOOKLM_CONTENT_LANGUAGE, defaulting to English), completely independent of the interface locale. Your reading of why hl= is forced was correct, and that reasoning is untouched — it just no longer reaches the generation request.

2. language: "Spanish" was never going to work, whatever the locale was. This one is on our documentation. The tool description tells you to pass "French", "Spanish", "Japanese" — but NotebookLM identifies an output language by a BCP-47 code. A display name lands in the payload slot, matches nothing, and gets discarded. So the argument you passed was being dropped before the locale ever came into it.

All 81 supported languages are now resolved from whichever form you have: a code (es, pt_BR, zh_Hans), an English name ("Spanish"), or the native name ("Español"). Anything unrecognised is now an error — this tool should never again generate in a language you did not ask for and report success.

There is a mirror-image version of the same bug in the browser fallback: it picks the language from a menu that lists native names, so "Spanish" never matched an option there either, and the menu was silently left alone. It now receives "Español".

3. The one neither of us could have guessed: hl on the request outranks the payload entirely. I tested this rather than assumed it. I sent a mind-map request carrying "es" in exactly the slot the protocol specifies, with the interface locale set to German:

payload: ["interactive_mindmap", [["[CONTEXT]",""]], "es"]
request: hl=de
result:  "Ziele setzen mit Kaizen und Ikigai"   ← German

The language field was ignored outright. Generation calls now send the content language as hl, and the identical request returns:

result:  "Cómo establecer metas con Kaizen e Ikigai"   ← Spanish

That is why your mind map came back French even though generate_mind_map had no language parameter to get wrong: hl=fr was deciding on its own. Separately, the mind-map payload was sending an empty language slot and an empty prompt slot; both are now filled.

Your four suggestions

1. Don't let uiLocale reach generation — done, that is the core of the fix.
2. Warn on silent fallback — done. NOTEBOOKLM_UI_LOCALE=es now says it is unsupported, says what it fell back to, and points at the content-language setting instead. You should not have had to lose a session to that.
3. Give generate_mind_map a language — done, plus a focus prompt, since the payload had an unused slot for one.
4. Document it — done in the README and the configuration reference.

One change worth flagging: the default interface locale is now English, not French. The old default was justified in a comment as matching "the most common Google Account language", which was never true — it was the author's language. Nobody should have to discover that by opening a French audio file.

Two things I could not verify

CREATE_STUDIO is currently returning an empty result for every artifact type on a valid session, so content_generate and generate_study_aid fall back to the browser path. It is not a rotated RPC id — I checked ours against a reference implementation and they match — so the drift message suggesting NOTEBOOKLM_RPC_OVERRIDES is misleading, and I am tracking that separately. It means my audio and flashcard fixes are verified by construction and by unit tests, but not yet against a live generation. Mind maps are unaffected and are the path I proved end to end.

If you do try 3.1.1, I would value knowing whether your audio overview comes back Spanish now — you have the one setup that actually reproduces this.

Thanks again, genuinely. And on the dual transport: it is the reason this was hard to see from the outside, since the fallback keeps working and only the quality changes. Your report is what made that visible.

[roomi-fields]

Follow-up: the gap I flagged is closed. The language fix is now verified end to end on the RPC path, not just for mind maps.

What was blocking the check turned out to be our own error handling, not an upstream failure. CREATE_STUDIO was reporting "the id likely rotated" for calls NotebookLM was simply refusing — the refusal travels as a gRPC status in the response envelope and our client was discarding it. The notebook I was testing against was shared with the account rather than owned by it, and NotebookLM only lets you generate content in your own notebooks. Against an owned notebook:

POST /content/generate  {content_type: "report", language: "Spanish"}
→ "Informe Informativo: Naturaleza y Clasificación de los Volcanes"

Spanish, over RPC, from a French-titled source. So content_generate and generate_study_aid are confirmed working with the language argument, alongside the mind-map result from before.

Two things this changes for you, both in 3.1.1:

• If your Spanish notebook is one someone shared with you, generation will fail — but it will now say so plainly (PERMISSION_DENIED, and that ownership is the usual cause) instead of sending you after a protocol problem that does not exist. That misleading message is very likely part of what you would have hit next.
• The browser fallback is still the one path I have not been able to exercise here, so if you do try 3.1.1 I would value knowing whether your audio overview comes back Spanish.

[roomi-fields]

3.1.1 is published (npm, GitHub, MCP Registry).

The browser-path gap I flagged in my last comment is closed too. It turned out the language menu does exist — it just sits a level deeper than our code ever went, behind each format tile's pencil button rather than in the format dialog itself. Verified on the browser transport, same call before and after:

before → "Analysis of Volcanic Formation and Structural Classifications"
after  → "Análisis de la Formación y Tipología de los Volcanes"

So both transports now honour language, and your original report is fully addressed rather than half. Thanks again for the quality of the write-up — the ?hl=fr you spotted in that transient error is what unlocked all of it.

[roomi-fields]

One more, and it is a correction to what I told you an hour ago.

3.1.1's browser-path fix covered the report dialog, where the language menu hides behind each format tile's pencil. Audio Overview has no pencil — its card opens straight onto a panel with the language menu already on it. So the exact case you reported, an audio overview in the wrong language, was still not fixed by the release that claimed to fix it. My apologies for the premature all-clear.

3.1.2 handles both shapes: the menu is used when it is already there, and the pencil only sought when it is not. Verified on the audio dialog — 80 options listed, the control moving from English to español.

Testing that fix turned up two more faults in it, both worth naming because they are the same species as the original bug:

• The visibility wait was three seconds against dialogs measured taking over ten. A timeout that short does not detect a missing language menu, it manufactures one — and then generates in the wrong language while confidently explaining why.
• The generate button was searched page-wide, so it matched a stray button behind the overlay and the panel was declared to have none. The language had in fact already been set, so the caller got warned about a failure that had not happened.

Verified end to end across both dialog shapes and four languages: data table in Italian, report in Japanese and Brazilian Portuguese, audio menu selection in Spanish.

There is also now a warnings field on the result: if a language is requested and NotebookLM's UI genuinely offers no way to set it for that content type, you get the content and a note saying it came back in the account's default language. No more status: "ready" on an artifact that quietly ignored you.

3.1.2 is on npm, GitHub and the MCP Registry.

[roomi-fields]

Closing — I stopped waiting on your confirmation and ran your exact case myself.

Audio overview, browser transport, language: "Spanish", on a notebook whose sources are not Spanish:

✅  Output language set to Español
✅  Audio Overview generated successfully via Studio
→   "Física del magma y formas volcánicas"

That is the specific thing you reported — an audio overview coming back in the wrong language while the tool said ready — now generated in the language asked for, on the transport you were actually running.

The full set is verified end to end at this point, across both transports:

path	verified
RPC — report	Spanish, from a French-titled source
RPC — mind map	Spanish, with the UI locale forced to German
browser — audio overview	Spanish
browser — report	Japanese, Brazilian Portuguese
browser — data table	Italian

It took 3.1.2 to get there: 3.1.1's browser fix only handled the report-shaped dialog and missed the audio one, which is the case you actually filed. That is on me, and it is the reason I would rather measure than assume.

No obligation to test anything — if it still misbehaves on your setup, reopen and I will pick it straight back up. Thank you for a report that was precise enough to chase three levels down; the ?hl=fr you caught in that transient error is what made all of it findable.