Localization Sources & Overrides

Power Portals Pro composes localized strings from three sources, in order: Dataverse table metadata (the language packs installed in your environment), PowerPortalsPro web resources, and JSON files on disk. Later sources override earlier ones — so any label, tooltip, choice option, or view name Dataverse provides can be replaced with a JSON entry in your project, no managed-solution round-trip required. The same JSON files also let you translate into cultures Dataverse offers no language pack for at all.

Try it on this site

This demo is fully localized with these same mechanisms. Use the language selector in the site header to switch cultures and watch the labels, choices, dates, and messages across the site update live — including this page.

What you can localize

Every translatable surface in the framework flows through the same source pipeline, so the same JSON file can supply, override, or fill gaps for any of:

• Tables — display names, collection names, and descriptions
• Columns — display names and descriptions (used as field labels and tooltips)
• Choices — option labels and descriptions for both table-scoped and global option sets
• Boolean (Yes/No) columns — the true/false labels are localized just like option-set choices, so they can be translated or overridden per culture
• Views — display names and descriptions for system and personal views
• Framework UI strings — button labels, validation messages, dialog text, grid chrome, and FluentUI component text
• Your application's strings — page titles, copy, navigation labels, anything you reach for via IStringLocalizer or React's useT()

See the String Localizer page for the JSON file shape that backs each of these.

Source precedence

At cache-warmup time the localizer loads from each source in turn, and a later source's non-empty value replaces whatever an earlier source supplied for the same key. The order is:

1. Dataverse table metadata — labels, descriptions, choices, and views from whichever language packs are installed in your environment. Pulled with one RetrieveAllEntities call per warmup.
2. Dataverse web resources — JSON files stored in Dataverse under the /PowerPortalsPro/Localization/ prefix. Useful when you'd rather ship translations alongside your solution than alongside your app's code.
3. JSON files on disk — every directory registered through options.AddLocalizationDirectory(...). These load last, so they win.

The practical consequence: drop a tables.en.json or app.fr.json into your project, register the folder, and any matching key overrides whatever Dataverse or the framework defaults provided. An empty incoming value is ignored, so a partial file can't blank out a perfectly good Dataverse label by omission.

Any culture, with or without a language pack

The culture segment of a JSON filename (app.{culture}.json, tables.{culture}.json, etc.) is authoritative — the loader doesn't check whether Dataverse has a language pack for that culture before honoring the file. Ship app.kk.json and the portal will serve Kazakh when a user picks it, even if Dataverse has no Kazakh metadata at all. The list of cultures a portal advertises is controlled by ASP.NET Core's RequestLocalizationOptions.SupportedCultures, independent of what Dataverse offers.

Default UI strings shipped by the framework

ppp-server.defaults.en.json ships in PowerPortalsPro.Web.Server and defines the cross-cutting app.* strings used by every framework consumer — page titles, button labels, validation messages, confirmation dialogs, grid chrome, FluentUI Blazor component text, and the like. Loaded automatically by AddPowerPortalsProWebServer(). Override any key in your own app.en.json (or culture-specific variants like app.fr.json) and the loader will prefer your value over the default. The file below is mirrored live from its source project on every build of this site, so the contents always match the version of the package you're consuming.