[feature]: Expand localization coverage for hardcoded UI surfaces

Is there an existing issue for this?

• I have searched the existing issues

Summary

Plane already supports multiple languages, but some user-facing surfaces still render English even after a non-English language is selected. This happens because several labels, empty states, error messages, tooltips, and action strings are hardcoded in TS/TSX instead of being routed through the i18n namespace JSON files.

This issue tracks expanding the existing localization coverage so those surfaces participate in the current i18n system.

Affected areas include Web onboarding, workspace invitations and workspace access states, inbox filters and create flows, Space public/auth/work-item surfaces, and editor link editing UI.

Why should this be worked on?

Hardcoded English makes the multi-language experience feel incomplete for non-English users. It also makes future localization harder because new strings are hidden in component code instead of being tracked by the locale sync checks.

Moving these strings into namespace JSON files improves coverage, keeps the existing i18n system as the source of truth, and makes future translation updates easier to review and maintain.

Linked PR

Resolved by #9082.

What the linked PR changes

PR #9082 wires the remaining hardcoded UI strings in the affected Web, Space, editor, and shared component surfaces into the existing react-i18next namespace JSON structure introduced after #8898.

It adds the new keys to the relevant existing namespaces instead of creating a catch-all namespace:

• auth
• common
• editor
• empty-state
• inbox
• page
• project
• work-item
• workspace

It also fills the matching keys across all currently supported locales.

Validation from the linked PR

Baseline from PR #9082:

• Scope: changed non-JSON TypeScript/TSX UI files in the PR, excluding locale JSON files.
• Method: heuristic scan for user-facing English literals in JSX text, visible JSX attributes, and label/title/message-like object properties.
• Result: candidate hardcoded English occurrences dropped from 269 to 13, a 95.2% reduction.
• Remaining hits are intentionally left out of scope because they are brand/contact/example/technical/static metadata values such as support@plane.so, name@company.com, OAuth provider logo alt text, Plane Publish, Plane logo, Popper's preventOverflow, and the static 404 - Page Not Found meta title.

Verification run in the linked PR includes:

• pnpm --filter=@plane/i18n run check:sync
• pnpm turbo run check:types --filter=@plane/i18n --filter=web --filter=space --filter=@plane/editor --filter=@plane/propel
• targeted lint/format checks for touched files

Start with the linked PR #9082 and its changed TypeScript/TSX UI files, then review the existing react-i18next namespace JSON files for auth, common, editor, empty-state, inbox, page, project, work-item, and workspace. The work is resolved by that PR; its checks include i18n sync, targeted type checks, and lint/format validation.