Partager via

Meilleures pratiques pour le développement d’applications prêtes à l’échelle mondiale

Cette section décrit les meilleures pratiques à suivre lors du développement d’applications prêtes à l’échelle mondiale.

Meilleures pratiques de globalisation

  1. Rendez votre application Unicode en interne.

  2. Utilisez les classes prenant en charge la culture fournies par l’espace System.Globalization de noms pour manipuler et mettre en forme les données.

    • Pour le tri, utilisez la SortKey classe et la CompareInfo classe.
    • Pour les comparaisons de chaînes, utilisez la CompareInfo classe.
    • Pour la mise en forme de date et d’heure, utilisez la DateTimeFormatInfo classe.
    • Pour la mise en forme numérique, utilisez la NumberFormatInfo classe.
    • Pour les calendriers grégoriens et non grégoriens, utilisez la Calendar classe ou l’une des implémentations de calendrier spécifiques.

  3. Utilisez les paramètres de propriété de culture fournis par la classe System.Globalization.CultureInfo dans les situations appropriées. Utilisez la propriété CultureInfo.CurrentCulture pour les tâches de mise en forme, telles que la date et l’heure, ou la mise en forme numérique. Utilisez la CultureInfo.CurrentUICulture propriété pour récupérer des ressources. Notez que les propriétés CurrentCulture et CurrentUICulture peuvent être définies par thread.

  4. Permettez à votre application de lire et d’écrire des données pour un large éventail d'encodages en utilisant les classes d'encodage du namespace System.Text. Ne supposez pas les données ASCII. Supposons que les caractères internationaux seront fournis partout où un utilisateur peut entrer du texte. Par exemple, l’application doit accepter des caractères internationaux dans les noms de serveur, les répertoires, les noms de fichiers, les noms d’utilisateur et les URL.

  5. Lorsque vous utilisez la UTF8Encoding classe, pour des raisons de sécurité, utilisez la fonctionnalité de détection d’erreurs proposée par cette classe. Pour activer la fonctionnalité de détection d’erreurs, créez une instance de la classe à l’aide du constructeur qui accepte un throwOnInvalidBytes paramètre et définissez la valeur de ce paramètre truesur .

  6. Dans la mesure du possible, gérez des chaînes entières au lieu d’une série de caractères individuels. Ceci est particulièrement important lorsque vous effectuez un tri ou que vous recherchez des sous-chaînes. Cela empêche les problèmes associés à l’analyse des caractères combinés. Vous pouvez également utiliser des unités de texte plutôt que des caractères uniques à l’aide de la System.Globalization.StringInfo classe.

  7. Afficher du texte en utilisant les classes fournies par l’espace de noms System.Drawing.

  8. Pour assurer la cohérence entre les systèmes d’exploitation, n’autorisez pas les paramètres utilisateur à remplacer CultureInfo. Utilisez le CultureInfo constructeur qui accepte un useUserOverride paramètre et définissez-le sur false.

  9. Testez la fonctionnalité de votre application sur les versions internationales du système d’exploitation, à l’aide de données internationales.

  10. Si une décision relative à la sécurité est basée sur le résultat d’une opération de comparaison de chaînes ou de changement de casse, utilisez une opération de chaînes indépendante de la culture. Cette pratique garantit que le résultat n’est pas affecté par la valeur de CultureInfo.CurrentCulture. Consultez la section « Comparaisons de chaînes qui utilisent la culture actuelle » des meilleures pratiques pour l’utilisation de chaînes pour un exemple qui montre comment les comparaisons de chaînes sensibles à la culture peuvent produire des résultats incohérents.

  11. Pour tout élément utilisé pour l’échange (par exemple, un champ dans un document JSON dans un appel d’API) ou pour le stockage, utilisez le CultureInfo ; de plus, vous devez spécifier explicitement un format aller-retour (par exemple, le spécificateur de format date-heure"O""o"). Bien que les chaînes de format pour la culture invariante soient stables et peu susceptibles de changer, la spécification d’une chaîne de format explicite permet de clarifier l’intention de votre code.

  12. Les données de globalisation ne sont pas stables, et vous devez donc écrire votre application et ses tests en tenant compte de cela. Il est mis à jour plusieurs fois par an via des canaux de système d’exploitation hôtes sur toutes les plateformes prises en charge. Ces données ne sont généralement pas distribuées avec le runtime.

Meilleures pratiques de localisation

  1. Déplacez toutes les ressources localisables vers des bibliothèques DLL séparées, consacrées exclusivement à ces ressources. Les ressources localisables incluent des éléments d’interface utilisateur, tels que des chaînes, des messages d’erreur, des boîtes de dialogue, des menus et des ressources d’objet incorporées.

  2. Ne codez pas en dur les chaînes ou les ressources d’interface utilisateur.

  3. Ne placez pas de ressources non localisables dans les DLL réservées aux ressources. Cela confond les traducteurs.

  4. N’utilisez pas de chaînes composites générées au moment de l’exécution à partir d’expressions concaténées. Les chaînes composites sont difficiles à localiser, car elles supposent souvent un ordre grammatical anglais qui ne s’applique pas à toutes les langues.

  5. Évitez les constructions ambiguës telles que « Dossier vide » où les chaînes peuvent être traduites différemment en fonction des rôles grammaticals des composants de chaîne. Par exemple, « vide » peut être un verbe ou un adjectif, ce qui peut entraîner différentes traductions dans des langues telles que l’italien ou le français.

  6. Évitez d’utiliser des images et des icônes qui contiennent du texte dans votre application. Ils sont coûteux à localiser.

  7. Prévoyez beaucoup d'espace pour que les chaînes puissent s'allonger dans l'interface utilisateur. Dans certaines langues, les expressions peuvent nécessiter plus d’espace de 50 à 75 % que dans d’autres langues.

  8. Utilisez la System.Resources.ResourceManager classe pour récupérer des ressources en fonction de la culture.

  9. Utilisez Visual Studio pour créer des boîtes de dialogue Windows Forms afin qu’elles puissent être localisées à l’aide de l’éditeur de ressources Windows Forms (Winres.exe). Ne codez pas les boîtes de dialogue Windows Forms manuellement.

  10. Organiser la localisation professionnelle (traduction).

  11. Pour obtenir une description complète de la création et de la localisation des ressources, consultez Ressources dans les applications .NET.

Meilleures pratiques de globalisation pour ASP.NET et d’autres applications serveur

Conseil / Astuce

Les meilleures pratiques suivantes concernent les applications ASP.NET Framework. Pour les applications ASP.NET Core, consultez Globalisation et localisation dans ASP.NET Core.

  1. Définissez explicitement les propriétés CurrentUICulture et CurrentCulture dans votre application. Ne vous fiez pas aux valeurs par défaut.

  2. Notez que les applications ASP.NET sont des applications managées et peuvent donc utiliser les mêmes classes que d’autres applications managées pour récupérer, afficher et manipuler des informations en fonction de la culture.

  3. N’oubliez pas que vous pouvez spécifier les trois types d’encodages suivants dans ASP.NET :

    • requestEncoding spécifie l’encodage reçu à partir du navigateur du client.
    • responseEncoding spécifie l’encodage à envoyer au navigateur client. Dans la plupart des cas, cet encodage doit être identique à celui spécifié pour requestEncoding.
    • fileEncoding spécifie l’encodage par défaut pour l’analyse des fichiers .aspx, .asmx et .asax .

  4. Spécifiez les valeurs des requestEncoding, responseEncoding, fileEncoding, culture, et uiCulture dans les trois emplacements suivants dans une application ASP.NET :

    • Dans la section globalisation d’un fichier Web.config. Ce fichier est externe à l’application ASP.NET. Pour plus d’informations, consultez l’élément< de globalisation>.
    • Dans une directive de page. Notez que, lorsqu’une application se trouve dans une page, le fichier a déjà été lu. Par conséquent, il est trop tard pour spécifier fileEncoding et requestEncoding. Seuls uiCulture, cultureet responseEncoding peuvent être spécifiés dans une directive de page.
    • Par programmation dans le code de l’application. Ce paramètre peut varier par requête. Comme avec une directive de page, au moment où le code de l’application est atteint, il est trop tard pour spécifier fileEncoding et requestEncoding. Seuls uiCulture, cultureet responseEncoding peuvent être spécifiés dans le code de l’application.

  5. Notez que la valeur uiCulture peut être définie sur la langue d’acceptation du navigateur.

  6. Pour les applications distribuées qui nécessitent des mises à jour sans interruption (par exemple, Azure Container Apps) ou dans des situations similaires, il est essentiel de prévoir des cas où plusieurs instances de l'application pourraient être en fonction avec différentes règles de format ou autres données culturelles, notamment des différences dans les règles de fuseau horaire.

    • Si votre déploiement d’application inclut une base de données, n’oubliez pas que la base de données aura ses propres règles de globalisation. Dans la plupart des cas, vous devez éviter d’exécuter des fonctions liées à la mondialisation dans la base de données.
    • Si votre déploiement d’application inclut une application cliente ou un front-end web à l’aide de ressources de globalisation du client, supposons que les ressources clientes diffèrent des ressources disponibles pour votre serveur. Envisagez d’exécuter exclusivement des fonctions de globalisation sur le client.

Recommandations pour les tests robustes

  1. Pour rendre les dépendances plus explicites et les tests potentiellement plus simples et parallélisables, vous devriez envisager de transmettre explicitement des paramètres spécifiques à la culture, tels que CultureInfo, aux méthodes qui effectuent le formatage et TimeZoneInfo à celles qui travaillent avec les dates et les heures. Vous devez également utiliser TimeProvider ou un type similaire lors de la récupération de l’heure.

  2. Pour la plupart des tests, vous ne devez pas valider explicitement la sortie exacte d’une opération de mise en forme donnée ou le décalage exact d’un fuseau horaire. La mise en forme et les données de fuseau horaire peuvent changer à tout moment et peuvent différer entre deux instances identiques d’un système d’exploitation (et potentiellement différents processus sur le même ordinateur). En s’appuyant sur une valeur exacte, les tests sont fragiles.

    • En règle générale, la validation de la réception d’une sortie est suffisante (par exemple, les chaînes non vides lors de la mise en forme).
    • Pour certains éléments et formats de données, la validation du fait que les données correspondent à la valeur d’entrée peut être utilisée à la place (validation par aller-retour). "Il faut faire attention dans les cas où des champs sont supprimés (par exemple, l'année pour certains champs liés à la date) ou lorsque la valeur est tronquée ou arrondie (comme pour un résultat en virgule flottante)."
    • Si vous avez des exigences explicites pour valider toutes les sorties de format localisée, vous devez envisager de créer et d’utiliser une culture personnalisée lors de la configuration du test. Pour la plupart des cas simples, cela peut être effectué en instanciant un objet CultureInfo avec son constructeur new CultureInfo(..) et en définissant les propriétés DateTimeFormat et NumberFormat. Pour les cas plus compliqués, la sous-classe du type permet de remplacer des propriétés supplémentaires. Cela pourrait offrir des avantages supplémentaires, tels que permettre potentiellement la pseudolocalisation avec des fichiers de ressources.
    • Si vous avez des exigences explicites pour valider les résultats de toutes les opérations de date/heure, vous devez envisager de créer et d’utiliser une instance personnalisée TimeZoneInfo pendant la configuration du test. Il existe des avantages supplémentaires à cela, tels que la réalisation de tests stables de certains cas particuliers (par exemple, les modifications apportées aux règles de l'heure d'été).

Voir aussi