[augustobrizio]

Pull Request

Summary

interface.customWelcome is a plain string, so a deployment whose users work in several languages shows its landing greeting in one of them, while every other string follows the user's interface language. Removing it does not help: the time-of-day greeting keys (com_ui_greeting_*) are not translated in several bundles, Spanish among them.

This PR lets customWelcome take the same LocalizedString that interface.mcpServers.trustCheckbox already uses: either a plain string, as today, or a map from language to message. Landing.tsx resolves it with the existing useLocalizedConfig hook: exact locale, then base language, then en, then the first entry. {{user.name}} substitution is unchanged, and a plain string behaves exactly as before.

We run LibreChat for Spanish- and English-speaking users, and the greeting was the one line our Spanish-speaking users saw in English. Until a release carries this, we work around it by rewriting the /api/config answer client-side, which we would like to drop.

Related to #17362. #11136 addresses a similar need with a new config object (several messages per language, a random pick, time greetings), but it predates useLocalizedConfig and no longer merges onto dev. This is the smaller version that reuses the existing type. If you prefer that direction, I'm glad to help bring #11136 up to date instead.

How it works

-    customWelcome: z.string().optional(),
+    customWelcome: localizedStringSchema.optional(),

+  const getLocalizedValue = useLocalizedConfig();
 ...
+  const configuredWelcome = startupConfig?.interface?.customWelcome;
   const customWelcome =
-    typeof startupConfig?.interface?.customWelcome === 'string'
-      ? startupConfig.interface.customWelcome
-      : undefined;
+    configuredWelcome != null ? getLocalizedValue(configuredWelcome, '') : undefined;

interface:
  customWelcome:
    en: 'Welcome, {{user.name}}!'
    es: '¡Bienvenido, {{user.name}}!'

Type of change

• Feature

Testing

The resolution order is the one useLocalizedConfig already applies to trustCheckbox; the new cases pin it for the landing greeting.

Tested environments/configuration:

• Unit tests only. I did not run this branch end to end; the behaviour it targets was checked in our own deployment through the client-side workaround above.

Automated tests:

• Added three cases to client/src/components/Chat/__tests__/Landing.agent-contact.spec.tsx: es-AR resolves the es entry, en-US the en entry, and fr falls back to en. They fail on the current Landing.tsx and pass with this change. The existing single-string case still passes.
• packages/data-provider specs/config passes.
• npm run static-checks:full -- --against origin/dev passes (ESLint, Prettier, import sorting, circular dependencies, TypeScript, config migration tests, unused i18n keys). The unused-packages check was skipped because depcheck is not installed.
• Rechecked after merging the current dev into a local copy: the Landing spec (13/13), the data-provider build and tsc --noEmit pass.
• Not run: the full test:client / test:api suites and e2e.

Screenshots / recordings

No visual change: the greeting keeps its component and styling, and only which configured string it shows depends on the language.

Risk / compatibility

Backwards compatible: a plain string validates and renders as before. The schema change widens customWelcome from string to string | Record<string, string>. Server code only passes it through (data-schemas/src/app/interface.ts), and admin config overrides that set it to a string keep working. Documentation for librechat.ai would follow if this direction is accepted.

Checklist

• I reviewed my own changes
• Relevant tests have been added or updated
• Existing relevant tests pass
• The change does not introduce new warnings or errors
• User-facing or complex behavior is documented where necessary
• Required dependency changes have been merged/published
• Required documentation PR: N/A until the direction is accepted

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.