Skip to content

Add Japanese UI localization #180

Description

@tami1A84

Before filing

  • I searched open and closed issues for duplicates.
  • I am using the current release, Berd v0.6.2, and this doesn't already exist.
  • This is one request, not several bundled together.

Closest existing issue

None found. I searched open and closed issues for Japanese, 日本語, i18n, localization, locale, and translation. #101 concerns right-to-left layout rather than Japanese localization.

Is this new, or an improvement?

New capability — Berd can't do this at all today.

The problem, in your terms

I use Berd in a Japanese-language environment, but its menus, settings, onboarding, dialogs, and messages are only available in English or Spanish. This adds continual translation overhead and makes the app less approachable for Japanese-speaking users, especially during setup and when interpreting errors or permission-sensitive actions.

Berd already detects the system locale, but a ja-JP system currently falls back to English because Japanese is not a supported app locale.

What you do today

I keep Berd in English and translate unfamiliar interface text manually. There is no skill, agent, extension, or automation that can localize Berd's own application chrome.

What you'd like to see

Add Japanese (ja) as a supported UI locale and make it available in Settings → General → Language. When the language preference is set to “System default,” ja-JP and other Japanese system locale variants should resolve to Japanese.

The existing i18n architecture appears ready for this: register ja, add the Japanese lazy resource loaders, and provide Japanese catalogs for the existing translation namespaces. Dates, numbers, relative time, the document lang attribute, explicit preference persistence, and English fallback should continue using the current locale infrastructure.

Translation catalogs should preserve interpolation placeholders, plural keys, newlines, URLs, and technical identifiers. Automated checks for English/Japanese key and placeholder parity would help prevent drift.

Why this belongs in Berd itself

This affects Berd's native menus, settings, onboarding, dialogs, toasts, and accessibility metadata before and outside any agent session. Skills, agents, extensions, and automations cannot replace the renderer's built-in translation resources or make locale detection and the language selector support Japanese. It therefore needs to be part of Berd's core i18n setup.

Non-goals

  • This request is not for translating agent-generated responses or user-authored content.
  • It does not request machine translation at runtime or a new translation service/dependency.
  • It does not request changes to model/provider language behavior.
  • It does not include right-to-left layout work; Japanese is left-to-right, and RTL support is tracked separately in Composer and message bubbles don't respect right-to-left text direction #101.
  • It does not require Japanese installer localization as part of the first iteration.

Alternatives you considered

  • Keep using the English UI: workable, but it creates recurring friction and does not help users who are not comfortable reading English.
  • Use a translation skill or agent: rejected because those cannot translate Berd's own application chrome or setup screens.
  • Maintain a private fork: technically possible, but translations would drift as the product evolves and would not benefit the broader Japanese-speaking user base.

Mockups, prior art, or other context

Berd already ships English and Spanish catalogs under src/shared/i18n/locales/ and has locale detection, persistence, lazy loading, and Intl-based formatting. Japanese can follow that established pattern without introducing a parallel localization system.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions