feat(tts): pass lang_code to OpenAI-compatible TTS providers (Kokoro multilingual support)

[ganzziani]

Problem

When using Kokoro TTS (or any OpenAI-compatible TTS backend that supports lang_code) via the openai provider, the language field in config.yaml is ignored. The _generate_openai_tts() function reads model, voice, base_url, and speed but never passes language through to the API.

This means users configuring Kokoro for non-English languages (Spanish, French, etc.) get English phonemization — the voice reads the text with an English accent regardless of the language: es config setting.

Solution

Read the language config field from tts.openai.language and pass it as extra_body={"lang_code": language} to the OpenAI SDK's audio.speech.create() call. The OpenAI SDK passes extra_body fields directly to the underlying API, which Kokoro uses to select the correct phonemizer for the target language.

Changes

• Add language = oai_config.get("language") to read the config value
• Add extra_body={"lang_code": language} to create_kwargs when language is set
• No breaking changes — language is optional and only used when explicitly configured

Config example

tts:
  provider: openai
  openai:
    model: kokoro
    voice: af_v0sarah
    language: es          # Now actually passed to Kokoro as lang_code=es
    base_url: http://localhost:8880/v1

Testing

Tested against Kokoro-FastAPI with Spanish text:

• Without patch: af_v0sarah reads Spanish text with American English phonemization
• With patch: same voice produces natural Spanish pronunciation via lang_code: es

[teknium1]

Thanks for the focused OpenAI-compatible TTS improvement. The premise remains valid on current main: tools/tts_tool.py:1029-1068 reads OpenAI model, voice, base URL, and speed, then calls audio.speech.create() without forwarding a language value.

Problems

• The PR adds request construction behavior without regression coverage. tests/tools/test_tts_speed.py:71-114 already captures audio.speech.create() kwargs, but has no lang_code case.
• The setting is not documented in the OpenAI TTS config example at website/docs/user-guide/features/tts.md:54-58, which currently documents the compatible-endpoint base_url override.

Suggested changes

• Add tests for configured language forwarding as extra_body={"lang_code": ...} and omission when unset.
• Document tts.openai.language and that it is intended for OpenAI-compatible endpoints supporting lang_code.

This is an automated hermes-sweeper review.

[teknium1]

Please add a regression test for this branch using the existing mocked OpenAI TTS kwargs harness in tests/tools/test_tts_speed.py: assert extra_body == {"lang_code": "es"} when configured and that it is omitted when language is unset.

[ganzziani]

Thanks for the review — both points are addressed in f26d93d:

Regression tests (tests/tools/test_tts_speed.py): new TestOpenaiTtsLangCode class covering:

• tts.openai.language: "es" is forwarded as extra_body == {"lang_code": "es"}
• extra_body is omitted when language is unset
• extra_body is omitted when language is an empty string
• a top-level tts.language is not forwarded (only the provider-scoped setting is honored)
• lang_code and speed are forwarded independently in the same call

All 24 tests in the file pass locally.

Docs (website/docs/user-guide/features/tts.md): added language to the tts.openai config example and a note explaining it is intended for OpenAI-compatible endpoints that support lang_code (e.g. Kokoro-FastAPI), and should be left unset for the official OpenAI API.

[teknium1]

Merged into main via consolidated salvage PR #73513 (merge 4aac89b429). Your tts.openai.language → lang_code via extra_body (Kokoro multilingual) was cherry-picked (20a87e9 + fccf781) with your authorship, folded in as a config knob.

Your contribution is credited to you in git history. Thank you! Closing this PR as merged-via-salvage.