We hope to add multilingual support.

[firstip-cpu]

Description

Chinese users have driven the development of OpenCaw and Hermes-agent.

Alternatives Considered

No response

Additional Context

No response

[jaberjaber23]

Thanks for filing. A few thoughts on where the boundary should sit, since "multilingual" can mean three different things in this codebase and each has a different fix.

Three surfaces, three strategies:

1. LLM-generated agent output (already works). The runtime is locale-neutral; replies are whatever the agent decides. No code change needed beyond agent prompts. We can ship a language hint in AgentManifest that gets prepended to the system prompt (e.g., "Respond in Simplified Chinese unless the user writes in another language"). Cheapest win, biggest user impact for firstip-cpu's use case.

2. Channel adapter formatting (crates/openfang-channels/src/formatter.rs). The current format_for_channel / format_for_wecom work on Markdown structure, not natural language, so they're already locale-safe. Verified: zero hardcoded English strings in formatter.rs. No work here.

3. Operator-facing UI strings: the SPA dashboard at crates/openfang-api/static/index_body.html (Alpine.js), the WebChat at crates/openfang-api/static/js/app.js, chat commands (/new, /compact, /model, /stop, /usage, /think) and their help text in channel_bridge.rs::handle_command(), plus error messages surfaced from llm_errors.rs::sanitize_for_user(). This is where the real i18n work lives.

Proposed path:

• Adopt fluent-rs (Mozilla Fluent, fluent-bundle + fluent-resource-loader) over gettext. Fluent handles CJK plural rules and message references natively, and the .ftl format is reviewable in PRs without msgfmt tooling.
• Add a Locale newtype in openfang-types and thread it through KernelConfig.locale (default en-US) and ChannelOverrides.locale (per-channel override).
• Extract a MessageBundle trait that wraps FluentBundle; inject it into ChannelBridgeHandle and the dashboard handlers. UI strings move to crates/openfang-api/locales/{en-US,zh-CN,ja-JP}/messages.ftl.
• Frontend: ship locale bundles as include_str!() and pick at request time via Accept-Language or a ?lang= query param.

Blocker: the dashboard's Alpine.js code interpolates strings inline (x-text="'Status: ' + agent.status"). Before we can i18n it, we need to extract user-visible strings to a JS message catalog that mirrors the Fluent bundles, or accept a one-time refactor where every interpolation becomes a t('status_label', {status}) call. That refactor is the gating work — once it's done, adding zh-CN is hours, not days.

If there's appetite, a sensible first PR is just (1) + (2) above: ship the agent language hint and confirm formatter.rs is locale-clean. That unblocks Chinese-language deployments today without waiting for the dashboard refactor.