Added ui_locales support and resolve localized client names.

[SajidMannikeri17]

Purpose

Fixes two i18n bugs in the OIDC authorization / flow-metadata pipeline:

1. ui_locales from the /authorize request was read into the request context but never forwarded anywhere — it never reached the login page, so it had no effect on the UI language.
2. /flow/meta's application.name always returned the client's flat default name, ignoring the requested UI language even when the RP had registered per-language names.

Approach

ui_locales forwarding — added RequestParamUILocales; extracted ui_locales in both the standard (authz/service.go) and PAR (par/service.go) authorization paths into a new OAuthParameters.UILocales field; forwarded it into the login-page redirect query params alongside authId/applicationId/executionId in initiateFlowAndStoreRequest.

Localized client name — flowmeta.GetFlowMetadata already resolves the requested language once per request; that lang is now threaded through populateTypeMetadata into actorprovider.BuildApplicationMetadata, which resolves a per-language name from an optional nameLangMap attribute via a new resolveLocalizedName/matchByBaseLanguage helper. Matching is by BCP-47 base language (golang.org/x/text/language) rather than literal string equality, so 2-letter and 3-letter ISO codes ("hi" vs "hin") and region-qualified tags ("fr-CA") all resolve correctly; an exact tag match is preferred over a base-language match, with sorted (deterministic) iteration when multiple candidates share a base language. Falls back to English, then the existing default name, if nothing matches — response shape is unchanged.

Related Issues

• NA

Related PRs

• NA

Checklist

• Followed the contribution guidelines.
• Manual test round performed and verified.
• Documentation provided. (Add links if there are any)
  • Ran Vale and fixed all errors and warnings
• Tests provided. (Add links if there are any)
  • Unit Tests
  • Integration Tests
• Breaking changes. (Fill if applicable)
  • Breaking changes section filled.
  • breaking change label added.

Security checks

• Followed secure coding standards in WSO2 Secure Coding Guidelines
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.

Summary by CodeRabbit

• New Features
  • Added localized application names based on the requested language, including regional-language matching and English fallback.
  • Added support for the OAuth ui_locales parameter.
  • Preserved the requested locale through authorization requests, login redirects, and pushed authorization requests.

[coderabbitai]

📝 Walkthrough

Walkthrough

The change propagates OAuth ui_locales values and uses resolved languages to select localized application names. Language matching supports exact, base-language, and English fallback behavior.

Changes

Localized metadata and locale propagation

Layer / File(s)	Summary
Localized application name resolution backend/internal/actorprovider/utils.go, backend/internal/actorprovider/utils_test.go	BuildApplicationMetadata accepts a language and resolves localized names by exact or base-language matches. It falls back to English or the default name. Tests cover matching and fallback cases.
Flow metadata language wiring backend/internal/flow/flowmeta/service.go	GetFlowMetadata passes the resolved language through type metadata population to BuildApplicationMetadata.
OAuth UI locale propagation backend/internal/oauth/oauth2/...	OAuth models and constants define ui_locales. Authorization and PAR services retain the value and add it to login redirects when present.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Suggested reviewers: thamindudilshan, thiva-k

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant OAuthAuthorizationService
  participant OAuthParameters
  participant PARService
  participant LoginRedirect
  participant GetFlowMetadata
  participant BuildApplicationMetadata

  Client->>OAuthAuthorizationService: Send ui_locales
  OAuthAuthorizationService->>OAuthParameters: Store UILocales
  PARService->>OAuthParameters: Store ui_locales
  OAuthAuthorizationService->>LoginRedirect: Propagate ui_locales
  GetFlowMetadata->>BuildApplicationMetadata: Pass resolved language
  BuildApplicationMetadata->>BuildApplicationMetadata: Select localized application name

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes both primary changes: forwarding ui_locales and resolving localized client names.
Description check	✅ Passed	The description explains the purpose and approach, and it records testing and security details; documentation and integration tests remain unchecked.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@backend/internal/actorprovider/utils.go`:
- Around line 135-149: Update matchByBaseLanguage in
backend/internal/actorprovider/utils.go#L135-L149 to normalize the requested and
candidate language tags, return an exact tag match before falling back by base
language, and use a stable ordering when multiple candidates share the base
language. Add the regression test in
backend/internal/actorprovider/utils_test.go#L183-L207 with both fr and fr-CA
entries, asserting that a fr-CA request selects the exact localized name.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 394ae51d-13e9-4fc7-94b9-e8ffd5bad43b

📥 Commits

Reviewing files that changed from the base of the PR and between 5e7daef and 243b238.

📒 Files selected for processing (7)

• backend/internal/actorprovider/utils.go
• backend/internal/actorprovider/utils_test.go
• backend/internal/flow/flowmeta/service.go
• backend/internal/oauth/oauth2/authz/service.go
• backend/internal/oauth/oauth2/constants/constants.go
• backend/internal/oauth/oauth2/model/parameter.go
• backend/internal/oauth/oauth2/par/service.go

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

[ThaminduDilshan]

Are we storing a key called nameLangMap in the database? I couldn't find any valid usages.

Also we already decode the name field at line 86 and set it to metadata. But here we override it again. In our design, if the name can be localized/ stored as a localized field, stored name field should contain a i18n key (I.e. attrs["name"].(string) will be a i18n key).

Then it should be resolved by invoking the i18n mgt service. This resolution logic is a responsibility of the i18n package. I don't prefer to have i18n related logic in other packages.

[ThaminduDilshan]

On a side note, if the frontend gate app is getting the requested locale, it should be able to resolve it based on the flow meta response. Currently also if the application is created with a localizable name (i.e. if the application name is a i18n key), flow/meta response will contain the localizable application name.

Ex:

{
...
    "application": {
        "name": "{{t(custom:console.app.name)}}",
...

Gate should be able to resolve it with the i18n translations returned in the same flow/meta response.

    "i18n": {
        "languages": [
            "en-US"
        ],
        "language": "en-US",
        "totalResults": 1608,
        "translations": {
            "custom": {
                "console.app.name": "Console"
            },