[Feature][Dashboards] Support localization (i18n) for shipped dashboard content (panel titles, labels)
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- json
Research direction
Start by locating the shipped dashboard JSON for Four Keys, DORA, and DORA Details, then inspect how dashboards are provisioned and whether config-ui or an environment variable can select variants. Done means panel titles, axis labels, and legends can be localized through a maintainable approach that does not drift from future dashboard updates.
Written by the indexing model from the issue text.
Description
Search before asking
- I had searched in the issues and found no similar feature requirement.
Use case
As an engineering lead on a non-English-speaking team, I want the DevLake dashboards (Four Keys, DORA, etc.) to support localized panel titles and labels, so that stakeholders who are not fluent in English can read metrics like Deployment Frequency or Lead Time for Changes without a mental translation step.
Description
Grafana itself supports UI localization via user Preferences (the menu, buttons, and other chrome can be switched to another language), but this only affects Grafana's own UI shell. The dashboards DevLake ships (Four Keys, DORA, DORA Details - *, etc.) are provisioned as static JSON with English panel titles, axis labels, and legend text hardcoded into the JSON. Switching Grafana's Preferences → Language does not change any of that content, so a non-English team still sees an all-English dashboard.
Possible directions (not mutually exclusive):
- Ship localized JSON variants of the built-in dashboards (e.g. one folder per locale) that users can opt into via config-ui or an env var, similar to how some BI tools ship translated report packs.
- Support templating panel titles from a small key→string map per locale, so a fork only needs to maintain a translation file instead of a full dashboard JSON copy (which then drifts from upstream on every dashboard update).
- At minimum, document a supported/low-friction way to fork+translate a shipped dashboard's JSON without losing the ability to pull future upstream changes into it.
I don't have a strong opinion on which direction is best, but I'm willing to help prototype one (see below) if a maintainer can point at the preferred approach.
Related issues
None found.
Are you willing to submit a PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
- Dominant language
- Go
- Stars
- 3.1k
- Forks
- 812
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 48
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/devlake
-
type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Stale type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
type/bug
Difficulty 4/5 3-5 days Newbie friendliness 52/100
-
apache/devlake#9142 · 2 comments · 1 reaction · 1 assignee ·
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100