Resolve bare locale codes to supported BCP-47 language tags in recognition config

[saurabhffs]

**Root Cause Analysis (RCA) Issue #635 **

Jigasi’s expected flow is:

• transcribe incoming speech in the speaker’s language,
• translate the finalized transcript into each requested target language,
• publish the translated result to the participant/client that requested that language.

The bug occurred because the reverse path for Polish as a target language was not equivalent to the path where Polish was the source language. In effect, the system handled PL -> other correctly, but other -> PL was not going through the same valid target-language resolution/request path, which resulted in no Polish translation output even though transcription itself was available.

Fix Implementation

• Added strict language code normalization in the translation request builder to ensure frontend locale strings (e.g., pl-PL, pl_PL) are correctly mapped to the 2-letter ISO code (pl) required by the translation backend.

• Improved logging in the TranslationManager to surface HTTP 400s or unrecognized target language exceptions from the translation provider instead of failing silently.

[damencho]

You have tested the changes?

[damencho]

Fix Implementation

• Added strict language code normalization in the translation request builder to ensure frontend locale strings (e.g., pl-PL, pl_PL) are correctly mapped to the 2-letter ISO code (pl) required by the translation backend.
• Improved logging in the TranslationManager to surface HTTP 400s or unrecognized target language exceptions from the translation provider instead of failing silently.

I am confused by this. It is talking about translation and the changes are for transcriptions.

[saurabhffs]

the changes are tested. the issue involves transcription and translation both. please refer #635

the issue only occurs when language tag is not in the proper BCP-47 format i.e. missing hyphen/dash.
language tag :

• pl-PL (correct)
• pl (incorrect)

[damencho]

In GoogleCloudTranscriptionService.java, the validateLanguageTag()
function is called with the value of translation_language presence
property (e.g. "pl", "en") which are short 2-letter codes.

translation_language is used only for translation, should not be used for transcription.

[saurabhffs]

I am not aware of the translation _language confusion. But GoogleCloudTranscriptionService.java is strictly for transcription and validation transcription language tags.

[damencho]

I am not aware of the translation _language confusion. But GoogleCloudTranscriptionService.java is strictly for transcription and validation transcription language tags.

I pasted that from the issue that you were referencing #635 ...

So when you choose a language in the UI you select a translate language, not a transcribe language.

Transcribe language is controlled by useAppLanguage:
https://github.com/jitsi/jitsi-meet/blob/989ecbec65e982b19e2b21f465e5ec60f2bb46fa/config.js#L506
and preferredLanguage: https://github.com/jitsi/jitsi-meet/blob/989ecbec65e982b19e2b21f465e5ec60f2bb46fa/config.js#L512

So transcriber languages should already be sent as pl-PL from the UI and should not arrive as just pl is what I am trying to say. Do you have steps to reproduce where the pl string is delivered in the transcriber service as a target language?

[saurabhffs]

Let me have another look at the issue with the provided context