Add Hebrew translations and localization

[lidorshimoni]

Summary

This PR fixes remaining onboarding UI strings that were still fully English in Hebrew mode.

Localized remaining hardcoded onboarding copy in:

• packages/web-core/src/features/onboarding/ui/LandingPage.tsx
• packages/web-core/src/i18n/locales/en/common.json
• packages/web-core/src/i18n/locales/he/common.json

What was localized

• Loading state text
• Safety notice sentence + “Learn more”
• Notification sound option labels
• Footer legal sentence (“By continuing… terms… privacy…”)
• Action button labels (“Continue” / “Saving…”)

Technical flags/product tokens that should remain in English (e.g. --yolo, --dangerously-skip-permissions) are preserved.

Validation

• pnpm run web-core:check
• pnpm --filter @vibe/local-web run lint:i18n
• Manual verification in Hebrew mode:
  • Onboarding screen now shows Hebrew for previously full-English UI strings.

Screenshot

---

Note

Medium Risk
Adds a new supported UI language (Hebrew) and switches the app to dynamically set RTL/LTR direction when changing languages, which can affect layout/styling across the web UI.

Overview
Adds Hebrew as a supported UiLanguage across the Rust config model and shared TS types, and wires Hebrew resources into the web i18n initialization.

Completes onboarding landing page localization by replacing remaining hardcoded English strings with react-i18next keys (including sound option labels, safety notice, footer legal text, and action/loading states), and updates i18n language switching to also set document.dir/lang based on the resolved language (RTL for he).

^{Written by Cursor Bugbot for commit ad15044. This will update automatically on new commits. Configure here.}

[Copilot]

Pull request overview

Adds Hebrew (HE) language support and completes localization of the onboarding landing UI by moving previously hardcoded strings into i18n resources, including right-to-left (RTL) document direction handling.

Changes:

• Add Hebrew as a supported UI language across shared TS types, Rust config, and i18n language mappings.
• Introduce Hebrew locale bundles (common/settings/projects/tasks/organization) and wire them into the i18n resource configuration.
• Localize onboarding landing page UI strings via react-i18next keys (loading state, safety notice, sound labels, footer legal text, and action buttons).

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
shared/types.ts	Adds HE to the UiLanguage union type.
packages/web-core/src/i18n/locales/he/common.json	Adds Hebrew common strings including onboarding landing keys.
packages/web-core/src/i18n/locales/he/settings.json	Adds Hebrew settings translations.
packages/web-core/src/i18n/locales/he/projects.json	Adds Hebrew projects translations.
packages/web-core/src/i18n/locales/he/tasks.json	Adds Hebrew tasks translations.
packages/web-core/src/i18n/locales/he/organization.json	Adds Hebrew organization translations.
packages/web-core/src/i18n/locales/en/common.json	Adds onboardingLanding keys in English (default fallback).
packages/web-core/src/i18n/languages.ts	Adds HE mapping and introduces RTL helpers (isRtlLanguage, updateDocumentDirection).
packages/web-core/src/i18n/config.ts	Registers Hebrew resources and updates language switching to also update document direction.
packages/web-core/src/features/onboarding/ui/LandingPage.tsx	Replaces hardcoded onboarding strings with i18n keys and translates sound option labels.
crates/services/src/services/config/versions/v6.rs	Adds Hebrew variant to the Rust UiLanguage enum for config serialization.

---

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[Juanlucasbg]

Aggressive review summary — PR #3288

2024-line PR adding Hebrew language pack plus first-class RTL (right-to-left) document-direction infrastructure. 11 files: 5 Hebrew JSON translations + RTL handling in i18n/config.ts and i18n/languages.ts + landing page tweak + versions/v6.rs + generated types. Verdict: structurally distinct from the other language-pack PRs — recommend the RTL infrastructure piece even if the language packs are deferred.

What sets this apart from #3096 (Portuguese), #3212 (Russian), etc.

The other queued language packs are pure JSON-translation additions. This PR also adds:

const RTL_LANGUAGE_CODES = ['he'];
export function isRtlLanguage(langCode: string): boolean { ... }
export function updateDocumentDirection(langCode: string): void {
    document.documentElement.dir = isRtlLanguage(langCode) ? 'rtl' : 'ltr';
    document.documentElement.lang = langCode;
}

Wired into the language-resolution path so the document <html dir> flips when an RTL locale is selected. This is reusable infrastructure — Arabic (ar), Persian (fa), Urdu (ur) future PRs would just extend RTL_LANGUAGE_CODES.

Findings

• Structural — PASS: RTL_LANGUAGE_CODES.some((rtl) => langCode.startsWith(rtl)) correctly handles he, he-IL, etc. Hardcoded list is fine — RTL languages are a small closed set.
• CSS-side — important question: Setting <html dir="rtl"> flips browser-default flow for text-align, inline-start/end, and HTML form layouts. But Tailwind classes like pl-4 (padding-left) and mr-2 (margin-right) are not RTL-aware unless the project uses Tailwind's logical-property utilities (ps-4, me-2). If the codebase still uses pl-*/pr-* extensively, the Hebrew layout will look broken (margins on the wrong side). Worth a quick visual QA pass with the locale switched to Hebrew.
• Adversarial — LOW:
  • Mixed-direction content: A Hebrew interface displaying English-language code blocks needs dir="ltr" on the code containers, otherwise punctuation flows wrong. Verify code-block components don't inherit the <html dir>.
  • Unicode bidi: Hebrew/English mixed strings rely on Unicode bidirectional algorithm. Generally handled by browser; just don't override unicode-bidi to bidi-override anywhere.
• Sunsetting context: Same concern as the other language-pack PRs (Add Portuguese language support to Vibe-Kanban #3096, feat: add Russian language support #3212, feat(i18n): add Turkish language support #2785, Feature/add turkish language support #2434) — bundle into a single language-pack policy decision. However, if the maintainer wants to leave the door open for any future locale work (forks, archives), the RTL infrastructure should land regardless. Consider splitting:
  • Part A (RTL infra): merge — small, useful, reusable.
  • Part B (Hebrew translations): bundle with the other language packs for batched ruling.
• crates/services/src/services/config/versions/v6.rs in the file list is suspicious — config schema migration tied to a language-pack PR? Verify what v6 adds and whether it's needed to persist the user's RTL/locale preference.

Verdict

Approve the RTL infrastructure portion. Defer the Hebrew translations to the same batched ruling as #3096 / #3212 / #3288 / #2785 / #2434.

— Reviewed by automated single-pass review (i18n + RTL infra; full 4-tool battery skipped — translation quality requires native review and the infrastructure is mechanically reviewable).