feat: translate frontend to Spanish#362
Conversation
Adds messages/es.json (full next-intl translation) and switches the default locale to es. Also translates hardcoded UI text that bypassed next-intl across app pages and components, plus user-facing strings in lib/ that render in the UI: dashboard activity feed, currency and template-status labels, flow/automation quick-start templates, flow/automation validation messages, interactive-payload validation, and theme names. Updates the handful of unit tests that asserted exact English message strings from the translated validation/interactive modules. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Nice contribution 👍 One thing I noticed is that this PR also translates hardcoded strings inside components and changes the default locale, not only Personally, I think it would be cleaner to keep translation PRs limited to language files and i18n keys, and avoid modifying global component text or the default locale. |
ArnasDon
left a comment
ArnasDon
left a comment
There was a problem hiding this comment.
Thanks for this — the es.json dictionary is solid work and I'd like to get language support in. But there are two blockers, both the same principle: a new language should be additive and opt-in, never the new default.
- Don't switch the default locale. Flipping
NEXT_PUBLIC_APP_LOCALEtoesmakes every fresh install and forker boot in Spanish. Keep the defaultenand documentesas an available locale. - Most strings are hardcoded Spanish instead of going through next-intl. With
enstill the default and the fallback, English is now broken — half the UI is driven byes.json, half by hardcoded Spanish (noteen.jsonwasn't touched). And the translatedlib/validators are returned by API routes, so this leaks Spanish into API responses for all consumers (incl. the MCP server).
The mergeable version: keep es.json, leave the default on en, move any UI text that bypasses i18n into t() keys in both dictionaries, and revert the lib/ + test changes (English stays canonical there). See inline notes.
| # Default language locale (e.g. en) | ||
| NEXT_PUBLIC_APP_LOCALE=en | ||
| # Default language locale (e.g. es) | ||
| NEXT_PUBLIC_APP_LOCALE=es |
There was a problem hiding this comment.
Please keep this on en. Changing the committed default makes every new install and every forker who hasn't set the var boot in Spanish — the language should be opt-in. Document es as an available locale instead.
|
|
||
| if (password !== confirmPassword) { | ||
| setError("Passwords do not match"); | ||
| setError("Las contraseñas no coinciden"); |
There was a problem hiding this comment.
This hardcodes Spanish and bypasses next-intl, so it shows even under the default/fallback en. Please route these through t() with keys in both en.json and es.json. Same pattern applies across the other component files in this PR.
| ): InteractiveValidation { | ||
| if (!payload || typeof payload !== 'object') { | ||
| return fail('Interactive message payload is required.') | ||
| return fail('Se requiere el contenido del mensaje interactivo.') |
There was a problem hiding this comment.
These validator strings are returned in API responses (/api/v1/messages, /api/quick-replies, /api/automations, automation engine) via NextResponse.json({ error: result.error }), not just shown in the UI. Hardcoding Spanish here changes the API contract for every consumer (incl. the MCP server) with no locale negotiation. Please keep lib/ messages English as the canonical output and translate at the UI layer.
Adds messages/ko.json — full next-intl translation covering all 12 namespaces (LoginPage, Sidebar, Header, ModeToggle, Dashboard, Inbox, Contacts, Pipelines, Broadcasts, Automations, Flows, Settings). Scoped to the language file only, per maintainer guidance on PR #362: no changes to the default locale, component text, or any other file. Verified 1:1 key parity with messages/en.json (1426/1426 leaf keys) and exact preservation of all interpolation variables and HTML-ish tags across every message.
3 participants
Adds messages/es.json (full next-intl translation) and switches the default locale to es. Also translates hardcoded UI text that bypassed next-intl across app pages and components, plus user-facing strings in lib/ that render in the UI: dashboard activity feed, currency and template-status labels, flow/automation quick-start templates, flow/automation validation messages, interactive-payload validation, and theme names.
Updates the handful of unit tests that asserted exact English message strings from the translated validation/interactive modules.
Summary
What changed
Test plan
npm run typecheckclean.npm run lint— no new errors beyond the pre-existing backlog.npm run buildsucceeds.Related