eSignet-Thunder: Add i18n bundle support for multi-language authentication flow in eSignet UI

[rachik-hue]

1. Problem Statement

eSignet UI currently supports only English. With multiple login ID type support (Mobile, Email, UIN, etc.) being added, the UI needs to support multiple languages so users across different regions can complete authentication in their preferred language. No i18n bundles currently exist for any language other than English.

Purpose

To make eSignet UI accessible to a wider user base across regions/countries by allowing users to authenticate in their preferred language, improving usability and inclusivity.

Pre-Requisites

• Backend configuration to define the list of supported languages (comma-separated).
• i18n bundle files/translations for each target language.
• Existing eSignet UI text/labels and error messages identified and extracted for translation.

2. Goals

• Add i18n bundles for the following languages: English (default), Hindi, French, Spanish, Tamil, Kannada, Telugu, Sinhala (Sri Lanka), Arabic.
• Add a language selector dropdown on all eSignet UI screens, visible from the point the user is redirected to eSignet UI for authentication.
• Language list in the dropdown should be driven by backend config (comma-separated list of supported languages).
• On language change, all UI text labels and error messages should update to the selected language, without losing user progress in the auth flow.
• Right-to-left (RTL) layout mirroring for Arabic (text translation only; layout direction remains LTR).
• User should be able to switch languages at any point during the auth flow.

3. Out of Scope

• Translation of content outside eSignet UI (e.g., relying party/partner application screens).
• Auto-detection of user's preferred language based on browser/device locale.
• Addition of languages not listed in the Goals section.

4. Acceptance Criteria

• Given a user is redirected to eSignet UI to begin authentication, When the screen loads, Then a language selector dropdown shall be visible on the screen.
• Given a user is on any screen within the eSignet UI auth flow, When the screen renders, Then the language selector dropdown shall be visible on that screen.
• Given the backend config defines a comma-separated list of supported languages, When the eSignet UI loads, Then the language dropdown shall display only the languages configured in the backend.
• Given a user selects a language from the dropdown, When the selection is made, Then all text labels and error messages on the current screen shall update to the selected language.
• Given a user has selected a non-default language, When the user navigates to a subsequent screen in the auth flow, Then the selected language shall persist across screens.
• Given no language is explicitly selected by the user, When the eSignet UI loads, Then English shall be displayed by default.

Business Rules

• Given a language is not present in the backend-configured supported list, When the UI loads, Then that language shall not appear in the dropdown.
• Given a user switches language mid-flow, When the switch occurs, Then the user's current authentication progress/state shall not be reset or lost.

Exceptions & Error Handling

• Given a translation/i18n bundle is missing or incomplete for a selected language, When a label/message has no translation, Then the UI shall fall back to displaying the English text for that label/message.
• Given the backend language config is empty or not provided, When the UI loads, Then only English shall be available/displayed.

Basic Flow

1. User initiates authentication from the relying party application.
2. User is redirected to eSignet UI (per eSignet OAuth flow).
3. eSignet UI loads with the language dropdown visible, defaulted to English, options populated from backend config.
4. User optionally selects a different language from the dropdown.
5. UI labels and error messages update to the selected language.
6. User proceeds through the authentication steps (ID entry, OTP/validation, etc.) with the selected language retained across screens.
7. User completes authentication and is redirected back to the relying party application.

Scenarios

• User completes the full authentication flow in English (default).
• User switches language on the first screen and completes the flow in the selected language.
• User switches language midway through the flow (e.g., after ID entry, before OTP screen) and the rest of the flow continues in the newly selected language.
• User attempts authentication when backend config lists only a subset of the 8 supported languages; dropdown reflects only that subset.

Data Fields

Field Name	Data Type (String/Text/Number/Boolean/Date/DateTime/Enum/List)	Data Length	Mandatory/Optional	Field Validations	Error Messages
Language Selector	Enum/List	NA	Mandatory (default: English)	Value must be one of the backend-configured supported languages	NA
Supported Languages Config	String (comma-separated list)	NA	Mandatory	Must be a valid comma-separated list of supported language codes	NA

Non-Functional Requirements

• Backward compatibility: Existing English-only flow must continue to work unaffected when no other language is configured.
• Browser compatibility: Language switch behavior should be consistent across supported browsers.
• Integration compatibility: Language config mechanism should not require changes to existing relying party integrations.

Definition of Done

• Code implemented
• Unit tests added
• Integration tests added (if applicable)
• Existing tests passing
• Documentation updated
• Acceptance criteria validated

5. References

UI/UX Design Link

TBA

Related Issues / PRs

TBA