The OAuth2/OIDC authorization endpoint (/oauth2/authorize) and its error pages are rendered only in the language selected via the website's `lang` cookie (see metabrainz/i18n.py -> get_locale(), wired through metabrainz/babel.py Babel(app, locale_selector=get_locale)).

OAuth clients such as MusicBrainz Picard open the authorization URL in an external browser where no `lang` cookie exists, so a user whose client is configured for, say, French always sees the authorization and error pages in English.

1. Honor the OpenID Connect `ui_locales` request parameter

Clients send `ui_locales` (a space-separated, preference-ordered list of BCP 47 language tags) to request the UI language. It is currently ignored. get_locale() should fall back to `ui_locales` when no supported `lang` cookie is present, matching on the primary language subtag against the supported locales (en, es, fr, de). Per spec, an unsupported/unknown locale must not cause an error.

2. Localize authorization error messages

Error descriptions returned/rendered by the OAuth endpoints are untranslated English. Per RFC 6749, `error_description` is a developer-facing, ASCII-only field and must not carry localized text; the user-facing message should instead be derived from the stable `error` code (e.g. access_denied, invalid_scope) via gettext. (Note: the underlying authlib library rejects non-ASCII `error_description` values outright, and its get_error_description() has no i18n hook – so translating by error code is the correct approach.)

Scope note: The client (in our case, Picard) has to translate known error codes for its own callback pages; this ticket covers the server-rendered authorize/consent and error pages.

References:

• OpenID Connect Core 1.0 section 3.1.2.1 – ui_locales definition (space-separated BCP 47, "An error SHOULD NOT result if some or all of the requested locales are not supported"):
  https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

• OpenID Connect Core 1.0 section 15.1 – Mandatory features ("OPs MUST support requests for preferred languages ... via the ui_locales and claims_locales request parameters ... the minimum level of support required ... is simply to have their use not result in errors"):
  https://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

• OpenID Connect Core 1.0 section 3.1.2.6 – Authentication Error Response (defines OIDC error codes: interaction_required, login_required, consent_required, account_selection_required, etc.): 
  https://openid.net/specs/openid-connect-core-1_0.html#AuthError

• RFC 6749 section 4.1.2.1 – Authorization error codes + ASCII restriction (error codes invalid_request, unauthorized_client, access_denied, unsupported_response_type, invalid_scope, server_error, temporarily_unavailable; and: "Values for the error_description parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E"):
  https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1

• RFC 6749 section 5.2 – Token error codes + same ASCII restriction on error_description:
  https://datatracker.ietf.org/doc/html/rfc6749#section-5.2

• RFC 5646 (BCP 47) – language tag format referenced by ui_locales:
  https://datatracker.ietf.org/doc/html/rfc5646

• oauth.com – "Possible Errors" (best practice: "the error description is not intended to be displayed to the user. Instead, you should present the user with your own error message ... gives you a chance to localize the error messages"):
  https://www.oauth.com/oauth2-servers/server-side-apps/possible-errors/