Is your feature request related to a problem?
ObsidiBot's UI is English-only. Users whose primary language isn't English face friction using the plugin — labels, notices, modal text, settings descriptions, and error messages are all hardcoded in English. As ObsidiBot grows, this limits adoption in large non-English-speaking Obsidian communities.
Describe the solution you'd like
Implement full localization support using Crowdin for community-driven translations.
- Extract all user-facing strings into a locale resource file (e.g.
en.json)
- Integrate Crowdin for translation management and contributor workflows
- Load the appropriate locale at runtime based on Obsidian's language setting
- Fall back to English for any untranslated strings
Priority languages
Based on Obsidian's own localization community and forum/plugin ecosystem activity, the recommended first-pass priority languages are:
- Chinese (Simplified) — the largest non-English Obsidian community by a significant margin
- Japanese — strong PKM culture; active plugin translation community
- German — large, technically engaged user base
- French — active Obsidian forum presence
- Spanish — broad global reach across multiple regions
Describe alternatives you've considered
- Manual per-locale JSON files maintained in-repo — viable for bootstrapping but doesn't scale; Crowdin's contributor model is far better for ongoing maintenance
- Relying on users to translate prompts themselves — too much burden on end users
Use Case
A Japanese researcher using Obsidian in Japanese opens ObsidiBot and sees all UI elements in Japanese. They can use the plugin naturally without switching mental context to English for every interaction.
A community contributor who doesn't code can go to Crowdin, pick their language, and translate strings without needing a GitHub PR workflow.
Additional Context
Obsidian itself uses a community localization model and already has strong translation coverage for the languages listed above — an engaged translator base likely already exists and could be recruited for ObsidiBot.
Crowdin offers a free open-source plan which would cover this project.
Implementation Suggestions
- Follow the pattern used by other popular Obsidian plugins that have adopted i18n
- Use Obsidian's
moment.locale() or window.moment.locale() to detect the active language
- Consider a
t('key') helper function pattern for clean string lookup throughout the codebase
- Crowdin GitHub integration can auto-sync locale files via PR on translation completion
Is your feature request related to a problem?
ObsidiBot's UI is English-only. Users whose primary language isn't English face friction using the plugin — labels, notices, modal text, settings descriptions, and error messages are all hardcoded in English. As ObsidiBot grows, this limits adoption in large non-English-speaking Obsidian communities.
Describe the solution you'd like
Implement full localization support using Crowdin for community-driven translations.
en.json)Priority languages
Based on Obsidian's own localization community and forum/plugin ecosystem activity, the recommended first-pass priority languages are:
Describe alternatives you've considered
Use Case
A Japanese researcher using Obsidian in Japanese opens ObsidiBot and sees all UI elements in Japanese. They can use the plugin naturally without switching mental context to English for every interaction.
A community contributor who doesn't code can go to Crowdin, pick their language, and translate strings without needing a GitHub PR workflow.
Additional Context
Obsidian itself uses a community localization model and already has strong translation coverage for the languages listed above — an engaged translator base likely already exists and could be recruited for ObsidiBot.
Crowdin offers a free open-source plan which would cover this project.
Implementation Suggestions
moment.locale()orwindow.moment.locale()to detect the active languaget('key')helper function pattern for clean string lookup throughout the codebase