Hmm, but if we lean on HTTP then does that not mean that we have no standard for stdio servers? We can introduce that later, but then we need to have two ways to do i18n.

@pja-ant I both agree but

• STDIO servers can be directly configured, so a config convention could emerge without requiring a spec change
• we already did this for auth where we lean into HTTP ... I kind of thought that was setting the precedent for leaning into the http transport for what it already has more generally - one of the key drivers for choosing it, it's very mature.

Personally I could go either way on this, but it feels like we should be careful about reinventing the wheel. I wouldn't be against also adding this to the initialize payload for other transports lacking the envelope that http offers. I'm not sure that should prevent this being available now though, we are literally about to go the other direction with the http spec where we are replaying payload values as http headers, so values being both in the payload and in headers will become the standard soon I expect.

It seems like we should try to minimize the gaps between transports as much as possible. Is there a reason we couldn't put this as a field in _meta and mirror it to the header like we're doing for some other values?

@kurtisvg no, except that the mirroring proposal isn't baked in yet, but do you agree that the http model is likely the sensible i18n communication/resolution mechanism to copy? I feel like it makes sense to at least lift and shift it, rather than come up with something else.

@kurtisvg no, except that the mirroring proposal isn't baked in yet, but do you agree that the http model is likely the sensible i18n communication/resolution mechanism to copy? I feel like it makes sense to at least lift and shift it, rather than come up with something else.

Yes, I'm +1 to reusing over reinventing (unless we have a good rationale why)

Superseded by #2792, which converts this into a cross-transport SEP per the feedback from @pja-ant and @kurtisvg above.

The SEP defines language preference in _meta first (so stdio works the same way) and mirrors into the standard Accept-Language / Content-Language HTTP headers on Streamable HTTP — applying the header/payload mirroring pattern established by SEP-2243, and the per-request stateless model from SEP-2575 (so a user can switch language mid-conversation without renegotiation).

I'll close this PR once #2792 has a sponsor; happy to close sooner if maintainers prefer.

Closing in favor of #2792, which converts this into a cross-transport SEP per the feedback above. See the SEP for full motivation, the per-request _meta field, the strict HTTP header/body mirror, and the alignment with SEP-2243 and SEP-2575.