Suggestion: lightweight UI string override hook for community-driven localization

[gaoyuoppa]

Summary

A lightweight "UI string override" hook would let the community localize the web console without burdening you with maintaining translations in every release.

Background

Thank you so much for Technitium DNS Server — it is an excellent, reliable piece of software and the single-developer effort behind it is genuinely impressive.

I understand fully why a complete i18n framework has not been planned (and I appreciate the clear, honest answers you have given on issues #1165 and #1969): every GUI change would need to be re-translated into every language for every release, which is a heavy ongoing burden for a one-person project.

Suggestion

Please consider a much smaller, lower-maintenance mechanism instead of a full i18n framework:

1. Allow the web console to load an optional, same-origin JSON/JS file (for example www/i18n-overrides.js or a path settable in dns.config/webservice.config) that maps UI strings to overrides.
2. The file is optional and empty by default — zero impact on existing installs.
3. The community maintains the translation files themselves, per language, as separate projects. You would not need to translate or maintain any language yourself.

Because the hook is same-origin and loaded directly by the console, it stays compatible with the existing CSP (script-src 'self') and requires no third-party service at runtime.

Why this matters

Browser translation add-ons work for many pages, but they do not reliably translate dynamically rendered content (charts, table row actions, button tooltips, modal dialogs), which is exactly the content that matters most in a DNS management console. Chinese users in particular are a large segment that would benefit, and a community-maintained override file would let us share one consistent translation instead of each relying on browser add-ons.

Offer

I have already built a working proof-of-concept of exactly this approach (a read-only overlay for index.html plus a same-origin dictionary file, with a language toggle persisted in localStorage, version-pinned to the upstream frontend). I would be very happy to share the implementation details or a sample dictionary file if you ever consider adding such a hook — and I completely understand if now is not the right time.

Thank you for reading, and for all the work you put into this project.

[Apachez-]

Wouldnt it be more efficient if you let google translate or some other browserbased plugin do this on the fly for you?

Personally I prefer a proper english based application rather than the community driven translations which often are shitty or will miss translations here and there mainly when a new release is out.

Another issue is that when certain terms are best wording in their original english form rather than being community or "AI/LLM" translated into something noone knows what it is.

Something else to consider (which I assume already exists with the application support) is the possibility of injected malware through these files who you are supposed to autoload.