Localization

In dForge, language is metadata — not strings baked into application code. Every label a user reads is a translatable value the runtime resolves per request, so adding a language is a content change, not a code change or a redeploy.

What’s translatable

Practically everything a user sees:

• Entity and field labels — the names on forms, grids, and detail pages
• Menu titles and folder names — the whole navigation tree
• View and column names — grids, kanbans, calendars, and their columns
• Dropdown / radio / flags option labels — the choices in pick-lists
• Action labels — buttons and their parameters
• Validation and error messages — what users see when input is rejected
• Settings — configurable labels a module ships

How it resolves

Each request carries a locale (from the signed-in user’s language, falling back to the browser’s Accept-Language). The API returns labels and messages already in that locale, so the same module serves every language from one definition — no per-language build.

Numbers, currency, and dates follow the locale too: $1,234.56 for en-US, 1.234,56 € for de-DE. The same value renders correctly for each user without the module doing anything special.

Tenants and users choose independently

• A tenant enables the languages it wants to offer.
• Each user picks their own — two people in the same workspace can use the app in different languages against the same data.

Adding a language

Provide the translated strings for a locale and it’s available immediately — no redeploy, no rebuild. Modules ship with their own translations, so installing a module brings its labels in every language it supports; add another locale later and every screen the module defines picks it up.

Module authors declare translations alongside the rest of a module’s metadata — see Module Studio and Core Concepts for where they live.

Related

• Fields Reference — field labels and option lists that translate
• Views — view and column names
• Core Concepts — how metadata flows through the runtime