Language support question: Prompt API seems to understand non-en/es/ja inputs when inputLanguage is omitted (e.g., hu)

[scsinfo]

Hi team - I have a language-support question from a production integration.

Docs mention limited/explicit support for inputLanguage (e.g. en/es/ja). However, in practice we observe that if we omit inputLanguage, and provide sharedContext / context / prompt text in another language (e.g. Hungarian hu), the model often appears to understand and respond almost correctly.

Real-world context (why this matters)

We ship a WordPress plugin used by agencies. Editors often work in non-English (e.g. hu), while we keep model output in English for consistency and translate separately. In production this means prompts/context can be multilingual, and we need to know what language behavior is guaranteed vs. accidental.

What we observe

• inputLanguage not provided
• sharedContext and/or prompt content is hu (or other languages outside en/es/ja)
• The model produces Hungarian output based on the non-English input

Questions

1. Is this behavior supported/expected, or is it just “best effort” and not guaranteed?
2. When inputLanguage is omitted, is there any automatic language detection happening, or is this purely model-dependent behavior?
3. If we rely on this, what are the failure modes you've seen (e.g., worse quality, higher latency, silent misinterpretation)?
4. Would you recommend always setting inputLanguage to a "closest supported" value, or leaving it unset when inputs are multilingual?

Happy to provide anonymized minimal examples if useful.

p.s. Translator + Language Detector are extremely fast - great job.

[michaelwasserman]

Thanks for raising this issue. In short, that behavior is not guaranteed.

While the API isn't fully specified, it's reasonable to expect implementation-defined behavior when input content diverges from supported input languages (or even beyond those specified in calls to create()). Some request might yield best-effort responses, and some requests might be rejected.

The Language Detector API can help clients ensure that input conforms to supported languages, and future API enhancements might provide choices around unsupported language behaviors. We know supported language expansion is important, and appreciate thoughts, feedback, and analysis around related topics.

I'm not sure there's a common practice for sharing examples, but Chromium definitely appreciates when feedback can be shared with examples in supported languages yielding poor results.