Built for
every market.
Every locale.
Language in dForge 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. Provide the translated strings for a locale and it's available immediately — every screen the metadata defines picks it up. Modules ship with their own translations, so installing a module brings its labels in every language it supports.
- 01 provide the translated strings for the new locale
- 02 the tenant enables it — no redeploy, no rebuild
- 03 every label, menu, view and message picks it up
- 04 users 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.