Built for
every market.
Every locale.
Operating across countries? Teams that each need the app in their own language? In dForge, language is metadata, not strings baked into code. The platform's own UI is localized — and so is everything you build: entities, columns, views, reports, menus, options, validation messages. Add a language and every screen picks it up. No redeploy, no rebuild.
The chrome
and everything
you build.
It isn't just buttons and menus in the shell. Every label a user reads — including the ones you define when you model your data — is a translatable value the runtime resolves per request.
The whole application shell — navigation, buttons, dialogs, grid controls, date pickers, system messages — ships localized out of the box.
And every label you author translates the same way — no separate string files to maintain, no code to touch.
Object names and field labels on every form, grid and detail page.
Grid, kanban, calendar and list view names — and the column headers inside them.
Report titles, column labels and dashboard widgets render in the reader's language.
The whole navigation tree — menu titles and folder names — translates.
Dropdown, radio and flag choices carry a label per locale, not a raw code.
What a user sees when input is rejected reads in their language too.
Action labels and their parameter names translate alongside the rest.
Configurable labels a module ships are translatable like everything else.
One definition.
Every language,
per request.
Each request carries a locale — from the signed-in user's language, falling back to the browser. The API returns labels and messages already translated, so the same module serves every language from one definition. No per-language build.
Two people in the same workspace can use the app in different languages against the same data.
A tenant turns on the languages it wants. Users choose from those, independently of each other.
$1,234.56 for en-US, 1.234,56 € for de-DE — the same value renders correctly for each user.
Ship a locale,
not a build.
Adding a language is a content change, not a code change. Translate however you like — AI-assisted or by hand — and a person always ships the locale; nothing goes live on its own. Provide the strings once and every screen the metadata defines picks them up. Modules ship with their own translations for the cultures they support.
- 01translate the new locale — AI-assisted or by hand
- 02a person ships it — nothing auto-deploys
- 03the tenant enables it — no redeploy, no rebuild
- 04every label, menu, view and message picks it up
- 05users switch to it the moment it's live
One build.
Every language.
See how the metadata runtime serves every locale from a single definition — or talk to us about the languages your team needs.