fix(stt): pass language parameter to Groq Whisper API

[alaamohanad169-ship-it]

The Groq STT provider ignored stt.groq.language and stt.local.language from config.yaml, forcing auto-detection. This garbled non-English audio (e.g. Hebrew detected as English).

Read language from config (stt.groq.language > stt.local.language) and pass it to client.audio.transcriptions.create() when set.

Fixes #55551

[rodriguez46p-ui]

Hermes Agent Review — PR #55713

Verdict: no blocking issues found.

Scope reviewed: tools/transcription_tools.py change that passes configured stt.groq.language, falling back to stt.local.language, into the Groq/OpenAI-compatible transcription request.

Checks performed:

• Reviewed PR metadata and diff (gh pr view, gh pr diff --name-only, git diff origin/main...HEAD).
• Ran an ad-hoc isolated Python probe with a fake OpenAI client to verify:
  • stt.groq.language wins over stt.local.language.
  • stt.local.language is used as fallback.
  • no language kwarg is sent when neither config value is set.
• Ran git diff --check origin/main...HEAD.
• Rechecked hosted CI: all required checks are passing; Docker image builds remain in progress/non-required at review time.

Notes:

• The behavior looks correct and low-risk.
• A focused regression test for _transcribe_groq language propagation would be useful, but I do not consider it blocking given the small diff and passing ad-hoc probe/CI.

Ad-hoc probe result:
AD_HOC_GROQ_LANGUAGE_PASS calls= 3 last_keys= ['file', 'model', 'response_format']

Reviewed by Hermes Agent hourly commander.

[alt-glitch]

This was generated by AI during triage.
Duplicate of #55608 — same fix (pass stt.groq.language / stt.local.language to the Groq Whisper transcription call in tools/transcription_tools.py), both targeting #55551. #55608 is the earlier open PR and is the canonical one.

[teknium1]

Thanks for the focused fix. Current main still lacks language in the Groq request at tools/transcription_tools.py:1297-1301, so the reported behavior remains reproducible by code inspection.

Problems

• tools/transcription_tools.py:1294 in this PR is not null-safe: stt.groq: null makes .get("groq", {}) return None, then .get("language") raises before the function's try block. Current main's provider reads use .get("section") or {} after null-guard hardening in 3a394210ffae0358100e9d14cf1639f764d7eab7.
• The PR changes only tools/transcription_tools.py; no regression test covers this new configuration-resolution behavior.

Suggested changes

• Load the STT config once and use null-safe groq and local section lookups.
• Add tests for Groq override, local fallback, no configured language, and stt.groq: null.

Automated hermes-sweeper review.

[teknium1]

stt.groq has no default subsection, so a user configuration containing stt.groq: null makes this expression call .get() on None before the surrounding try block. Please match current main's null-safe provider pattern: (stt_config.get("groq") or {}).get("language").

[alaamohanad169-ship-it]

👋 All CI checks are passing (fixed test mocking for Groq STT language config). Could a maintainer merge this when you have a moment? Thanks!

[teknium1]

Resolved by PR #73067, which unified language resolution across all STT providers (stt..language > global stt.language > env > auto-detect). The Groq language parameter fix from #23161 (earliest submitter, credited) plus the OpenAI/local halves were salvaged there with authorship preserved. Your analysis of the Groq auto-detect failure was spot on — thanks for the work, and sorry we couldn't take both duplicate implementations.