Allow custom UI translations (locale files / plugin) maintained by users, with English fallback

Open
  • Is something wrong?
#5,675 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
nextjs, typescript
Domain
frontend, internationalization

Research direction

This is design work, not a starter task: the request asks for a locale-loading extension point with English fallback, and the maintainers removed translations on purpose (see #3119 and #3240). Read those two threads first to learn why they were dropped, then find where UI strings are rendered in the Next.js frontend and whether any translation keys exist today. Done would mean a written proposal that the maintainers accept, not a patch.

Written by the indexing model from the issue text.

Description

enhancement
What problem will this feature address?

Dokploy used to have UI translations (i18n via next-i18next, with community-contributed languages). In current releases (we run v0.30.8) there is no language selector anymore and the UI is English-only.

Some teams use the panel with developers and operators who are not comfortable with English. Browser auto-translation breaks the panel (React re-renders, broken layouts and inputs), so it is not a usable replacement.

I understand from #3119 and #3240 that translations were removed on purpose because keeping them up to date is a lot of work for the core team. This request is not to bring back translations maintained by Dokploy, but to provide an extension point so that teams who need a language can maintain it themselves.

Describe the solution you'd like

Keep English as the only built-in language, but allow custom translations as a plugin / customization:

  • UI strings go through translation keys, with English as the always-complete fallback (missing keys silently show English, so new features never wait for translations).
  • An instance can load its own locale files, for example JSON files from a mounted directory (/etc/dokploy/locales/<lang>.json) or uploaded in Settings, and pick the UI language.
  • Dokploy does not ship or review these files; they are maintained by whoever needs them (a company, or a community repo outside Dokploy).

This keeps the maintenance cost for the core team close to zero, and lets users do the work.

Describe alternatives you've considered
  • Browser auto-translate (Chrome / Edge): breaks the panel UI, not usable.
  • Translating only selected text with a browser extension: works, but is slow for daily use.
  • Maintaining our own fork or CSS overrides: has to be redone after every Dokploy update.
Additional context

Related: #3119 (Complete and improve translation system), #3240 (Full i18n coverage PR, closed), #1729 (Catalan language).

Will you send a PR to implement it?

No

Dominant language
TypeScript
Stars
38.2k
Forks
3.1k
Avg merge
2d 11h
Merged PRs (30d)
65

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Dokploy/dokploy

All issues in Dokploy/dokploy

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.