Sources et dérogations de localisation

Power Portals Pro compose des chaînes localisées à partir de trois sources, dans l’ordre : les métadonnées de la table Dataverse (les packs de langage installés dans votre environnement), les ressources web PowerPortalsPro et les fichiers JSON sur disque. Les sources ultérieures supplantent les précédentes — ainsi, toute étiquette, infobulle, option de choix ou nom de vue fourni par Dataverse peut être remplacée par une entrée JSON dans votre projet, sans besoin de faire un aller-retour de solution gérée. Les mêmes fichiers JSON permettent aussi de traduire en cultures, Dataverse n’offre aucun pack linguistique pour lequel il n’y a aucun pack.

Essayez sur ce site

Cette démo est entièrement localisée avec ces mêmes mécaniques. Utilisez le sélecteur de langue dans l’en-tête du site pour changer de culture et regardez les étiquettes, choix, dates et messages à jour en direct sur le site — y compris cette page.

Ce que vous pouvez localiser

Chaque surface traduisible dans le framework passe par le même pipeline source, de sorte que le même fichier JSON peut fournir, remplacer ou combler les lacunes pour l’un des suivants :

Voir la page String Localizer pour la forme du fichier JSON qui soutient chacun de ces aspects.

Préséséance de source

Au moment du réchauffement du cache, le localisateur se charge à tour de rôle depuis chaque source, et la valeur non vide d’une source ultérieure remplace celle fournie par une source antérieure pour la même clé. L’ordre est :

  1. Métadonnées de tableaux Dataverse — étiquettes, descriptions, choix et vues provenant des packs linguistiques installés dans votre environnement. Tiré avec un RetrieveAllEntities appel par échauffement.
  2. Ressources web Dataverse — Fichiers JSON stockés dans Dataverse sous le /PowerPortalsPro/Localization/ préfixe. Utile quand vous préférez livrer des traductions en même temps que dans votre solution plutôt qu’avec le code de votre application.
  3. JSON sur disque — chaque répertoire enregistré via options.AddLocalizationDirectory(...). Celles-ci se chargent en dernier, donc elles gagnent.

La conséquence pratique : insérer un tables.en.json or app.fr.json dans votre projet, enregistrer le dossier, et toute clé correspondante supprime les valeurs par défaut fournies par Dataverse ou le framework. Une valeur entrante vide est ignorée, donc un fichier partiel ne peut pas vider une étiquette Dataverse parfaitement valide par omission.

N’importe quelle culture, avec ou sans pack linguistique

Le segment culture d’un nom de fichier JSON (app.{culture}.json, tables.{culture}.json, etc.) est autoritaire — le chargeur ne vérifie pas si Dataverse possède un paquet linguistique pour cette culture avant d’honorer le fichier. Ship app.kk.json et le portail serviront le kazakh lorsqu’un utilisateur le choisit, même si Dataverse ne contient aucune métadonnée kazakhe. La liste des cultures qu’un portail annonce est contrôlée par ASP.NET RequestLocalizationOptions.SupportedCulturesCore, indépendamment de ce que propose Dataverse.

Chaînes d’interface utilisateur par défaut fournies par le framework

ppp-server.defaults.en.jsonPowerPortalsPro.Web.Server inclut et définit les chaînes de découpes app.* transversales utilisées par chaque consommateur de framework — titres de pages, labels de boutons, messages de validation, dialogues de confirmation, chrome en grille, texte composant FluentUI Blazor, et autres. Chargé automatiquement par AddPowerPortalsProWebServer(). Remplace n’importe quelle clé dans ta propre app.en.json touche (ou dans des variantes spécifiques à la culture comme app.fr.json) et le chargeur préférera ta valeur à celle par défaut. Le fichier ci-dessous est en miroir en direct depuis son projet source sur chaque version de ce site, de sorte que le contenu correspond toujours à la version du paquet que vous consommez.