fix(i18n): fallback to server locale for "Default" user lang in notifs

[fallenbagel]

Description

When a user's display language is set to "Default", their stored locale is
an empty string, ignoring the server's configured application language.

Affects all per-user agents (email, Telegram, Pushbullet, Pushover,
webpush, Discord with useUserLocale: true). Channel agents (Slack,
Gotify, ntfy, Discord with useUserLocale: false) pass an explicit locale
and are unaffected, though they now also correctly fall back to the server
default if their configured locale is somehow empty.

• Fixes Email notifications use English instead of server default language when user's display language is set to "Default" #3151

How Has This Been Tested?

(no need)

Screenshots / Logs (if applicable)

Checklist:

• I have read and followed the contribution guidelines.
• Disclosed any use of AI (see our policy)
• I have updated the documentation accordingly.
• All new and existing tests passed.
• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

Summary by CodeRabbit

• Chores
  • Updated default locale resolution to use server-configured settings instead of hardcoded fallback values.

[coderabbitai]

📝 Walkthrough

Walkthrough

server/i18n/index.ts imports getSettings and updates getIntl() to read getSettings().main.locale as the default locale when no locale argument is supplied, falling back to 'en' only if that setting is also absent. The previous locale ?? 'en' direct fallback is removed.

Server i18n locale default

Layer / File(s)	Summary
getIntl() locale resolution from server settings server/i18n/index.ts	Adds getSettings import; replaces locale ?? 'en' with a serverLocale derived from getSettings().main.locale, so getIntl() without an explicit locale argument now uses the server-configured language before falling back to 'en'.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐇 A hop through the settings, a peek at the config,
No more English-by-default, that old sneaky trick!
serverLocale now leads the email parade,
In whatever fine language the admin has made.
The rabbit cheers loudly — correct tongues at last! 🌍

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: fixing i18n fallback to use server locale for users with 'Default' language setting.
Linked Issues check	✅ Passed	The PR directly addresses issue #3151 by modifying locale resolution in getIntl() to fall back to server settings when no explicit locale is provided.
Out of Scope Changes check	✅ Passed	All changes are directly related to fixing the i18n locale fallback issue described in #3151; no out-of-scope modifications detected.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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 and usage tips.}

[Copilot]

Pull request overview

This PR fixes notification localization when a user’s display language is set to “Default” (stored as an empty string), by falling back to the server’s configured application language and then to English.

Changes:

• Update server-side getIntl locale resolution to treat falsy/empty user locale as “use server locale”.
• Ensure agent-provided locales also fall back to English if an unexpected empty value is encountered.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[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 `@server/i18n/index.ts`:
- Around line 42-45: The issue is that getSettings().main.locale is being cast
to AvailableLocale without validation, and the MainSettings interface declares
locale as a plain string instead of constraining it to valid locale values. To
fix this, update the MainSettings interface to declare the locale property as
type AvailableLocale instead of string, ensuring type safety at compile time.
Additionally, add validation logic at the points where locale values are
assigned (such as API endpoints or settings forms) to verify that only valid
AvailableLocale values are stored in the settings, preventing invalid data from
being persisted in the first place.

🪄 Autofix (Beta)

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: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1f15d04a-23e6-4b5f-b848-68b45a678f36

📥 Commits

Reviewing files that changed from the base of the PR and between 0a1f703 and 3759e1e.

📒 Files selected for processing (1)

• server/i18n/index.ts

[0xSysR3ll]

LGTM