feat(i18n): add Russian (ru) locale

[oshuej198]

Summary

Add Russian (ru) as a first-class Windshift UI locale with the same catalog coverage and runtime behavior as the existing supported locales.

Context

Windshift already has a mature localization layer with lazy-loaded locale modules, browser-language negotiation, persisted user preference, localized date formatting, fallback to English, and automated catalog validation.

The English reference catalog currently contains 5,651 leaf keys (approximately 20,000 source words) split across 16 translation modules.

Russian needs locale-specific CLDR plural categories (one, few, many, and other). The runtime already uses Intl.PluralRules, but the locale parity validator currently treats locale-specific plural variants such as _few and _many as unexpected extra keys.

Scope

• Register ru / Русский as an LTR locale in SUPPORTED_LOCALES.
• Add a complete frontend/src/lib/locales/ru catalog matching the English reference catalog.
• Preserve all interpolation placeholders, product names, URLs, query syntax, and technical identifiers.
• Add natural Russian plural variants for every count-dependent message.
• Update the i18n validator so valid locale-specific CLDR plural variants are accepted and checked for placeholder parity.
• Ensure browser negotiation selects ru for Russian browsers when no saved preference exists.
• Ensure the language can be selected and persisted from the user profile.
• Perform a focused audit of user-visible hard-coded English strings encountered on primary application, portal, and public-board flows; migrate them to i18n or document follow-up issues.
• Add regression coverage for Russian locale negotiation and plural selection.

Acceptance criteria

• “Русский” is available in the language selector.
• Selecting Russian updates the interface without requiring a restart and persists across sessions.
• A browser locale such as ru-RU resolves to ru when no explicit preference is stored.
• The Russian catalog has full reference-key coverage and no unexpected non-plural keys.
• Interpolation placeholders match the English reference catalog.
• Russian plural forms render correctly, including representative values such as 1, 2, 5, 11, 21, 22, and 25.
• Missing translations fall back to English without exposing raw translation keys.
• Core navigation, authentication, workspace/item views, settings, mobile UI, portal, and public surfaces receive a desktop/mobile smoke test.
• Long Russian labels do not cause obvious clipping, overflow, or broken controls at supported breakpoints.
• npm run check, npm run typecheck, relevant tests, and the production frontend build pass.

Translation guidance

Create a small glossary before bulk translation so recurring domain terms remain consistent, especially “workspace”, “work item”, “collection”, “iteration”, “milestone”, “workflow”, “issue”, “request”, and “approval”.

Product names, API/CLI syntax, code identifiers, URLs, and user-provided content should remain unchanged.

Out of scope

Backend logs, API field names, CLI commands, and user-created content. Localizing transactional email templates or the TUI can be handled separately if they are not already covered by the frontend catalog.

[stefan-ernst]

Hello, thank you for the suggestion. Yes, it would be no problem to do so. However since these locals are AI generated - would you be able to help us verify the quality of the translation?

[oshuej198]

Yes, absolutely.

I’m a native Russian speaker, and I can manually review the entire Russian locale for accuracy, natural wording, consistent terminology, plural forms, and UI context. I can also test the main application screens in Russian and address any translation feedback during the PR review.

[oshuej198]

Just to clarify,

I’m planning to implement the Russian locale myself and submit it as a PR. I’ll also manually review the full translation in context, including terminology, plural forms, placeholders, and the main UI screens.

[stefan-ernst]

Even better, thank you! Waiting for the PR then