fix(desktop): use DesktopLanguage for i18n slash command descriptions#3876
Conversation
When the user selects a language in desktop settings, it saves to DesktopLanguage field. However, the i18n system for slash command descriptions only reads from cfg.Language (CLI setting), causing the / commands to show English descriptions even when Chinese is selected in desktop settings. Fix: Fall back to cfg.DesktopLanguage() when cfg.Language is empty, so the desktop language preference is respected. Fixes esengine#3850 (upstream) Signed-off-by: Bernardxu123 <bernardxu123@users.noreply.github.com>
When the user selects a language in desktop settings, it saves to DesktopLanguage field. However, the i18n system for slash command descriptions only reads from cfg.Language (CLI setting), causing the / commands to show English descriptions even when Chinese is selected in desktop settings. Fix: Fall back to cfg.DesktopLanguage() when cfg.Language is empty, so the desktop language preference is respected. Fixes esengine#3875 (upstream) Signed-off-by: Bernardxu123 <bernardxu123@users.noreply.github.com>
esengine
left a comment
There was a problem hiding this comment.
Good catch on the root cause — desktop i18n init only ever read cfg.Language, so the desktop language picker never reached the slash descriptions. Right place to fix it, too.
One substantive point before merging: the comment and the code disagree, and I think the comment has it right. The comment says "Prefer DesktopLanguage (desktop UI setting) over Language (CLI setting)", but the code makes cfg.Language win and only falls back to DesktopLanguage() when it's empty. For a user with language = "en" in their toml who then picks 中文 in desktop Settings, the frontend UI switches to Chinese but slash descriptions stay English — which is exactly the mixed-language state #3875 complains about.
In the desktop app the desktop-specific setting is the user's most direct intent (it's also what the rest of the desktop UI follows), so the precedence should be:
lang := cfg.DesktopLanguage()
if lang == "" {
lang = cfg.Language
}
i18n.DetectLanguage(lang)That matches your comment as written, keeps CLI users unaffected (they have no desktop.language), and fully fixes the issue for users with both set. Happy to merge right after that flip.
|
Fixed! Thanks for the clear explanation. Changed the precedence to: lang := cfg.DesktopLanguage()
if lang == "" {
lang = cfg.Language
}
i18n.DetectLanguage(lang)Now DesktopLanguage takes priority, matching the comment and the rest of the desktop UI behavior. CLI users are unaffected since they have no desktop.language set. |
Per maintainer feedback: in the desktop app, the desktop-specific
setting is the user's most direct intent (it's also what the rest
of the desktop UI follows), so the precedence should be:
lang := cfg.DesktopLanguage()
if lang == {
lang = cfg.Language
}
This matches the comment and fully fixes the issue for users with
both settings configured.
Signed-off-by: Bernardxu123 <bernardxu123@users.noreply.github.com>
esengine
left a comment
There was a problem hiding this comment.
That's exactly the flip — DesktopLanguage() first, CLI language as fallback, matching the comment and the rest of the desktop UI. CLI users are untouched (no desktop.language), and the mixed-language state from #3875 is gone for users with both set. Merging, thanks for the quick turnaround.
Summary
Fixes #3875
When the user selects a language in desktop settings, the
/command descriptions in chat still show English because the i18n system only reads fromcfg.Language(CLI setting), notcfg.DesktopLanguage()(desktop setting).Changes
desktop/app.gocfg.DesktopLanguage()whencfg.Languageis emptyTesting
Build succeeds ✅
Backward Compatibility
reasonix.tomlor env vars)Signed-off-by: Bernardxu123 bernardxu123@users.noreply.github.com