Batch support for the next gen model

[rakeshv247]

This change adds

• Support for the language hints feature, which is applicable only for the batch next-gen models. The language_hints info will be a new field in the transcription_config. For example:

  {
      "language": "multi",
      "language_hints": ["en", "es"],
      "language_hints_strict": True
  }
  

• Support new fields in the metadata.language_pack_info from transcript.json-v2 results.

[giorgosHadji]

Have you tested this with an actual worker?

[giorgosHadji]

LGTM in general

[rakeshv247]

Have you tested this with an actual worker?

Tested the changes with omni and non-omni workers in a SaaS dev environment.

[J-Jaywalker]

I'm probably ignorant to whether this has been discussed before, but would it be worth putting language_hints and language_hints_strict into a single config class like our other configs?

That way users could call

lang_config = LangConfig(
    hints = ["en", "jp"],
    strict = True

config = TranscriptionConfig(
    model = OperatingPoint.OMNI,
    lang_config = lang_config
)

Thoughts?

[giorgosHadji]

Ah, that's a valid point! Forgot these! Nice shout

[rakeshv247]

I didn't do that because language_hints and language_hints_strict are flat scalar fields in the transcription_config, just like their peers max_delay + max_delay_mode in the transcription_config. The other fields that are defined as dataclasses are real JSON objects rather than scalar types, for example: TranscriptFilteringConfig and AudioFilteringConfig. Does this make sense?

[J-Jaywalker]

Makes sense, and understand that point. Just wondered if it might be good from a user perspective to group everything that way. Happy with the explanation though :)

[J-Jaywalker]

Feels strange that users will call the OperatingPoint enum for a field called model.

[rakeshv247]

Users can set either model or operating_point — both are accepted. When model is set, it takes precedence and is sent as operating_point in the request; only operating_point ever goes over the wire. The model field is purely an alias added for ergonomic familiarity and it mirrors how LLM APIs (OpenAI, Anthropic, etc.) expose model selection, making the omni-v1 use case feel natural to users coming from that ecosystem.

[J-Jaywalker]

Oh no, I understand that. This is just a nit from me. It feels odd calling

model = OperatingPoint.OMNI

If someone were to use the model field.

[rakeshv247]

Unfortunately 😞, we have to close this PR for now (if you have followed the thread).

[J-Jaywalker]

Reviewed, left a couple of minor comments.