Meilleures pratiques pour développer des applications mondialisables
Cette section décrit les meilleures pratiques pour développer des applications mondialisables.
Meilleures pratiques de globalisation
Utilisez le codage Unicode en interne dans votre application.
Servez-vous des classes fournies par l'espace de noms System.Globalization pour manipuler les données et les mettre en forme.
Pour trier, utilisez la classe SortKey et la classe CompareInfo.
Pour les comparaisons de chaînes, utilisez la classe CompareInfo.
Pour la mise en forme des dates et heures, utilisez la classe DateTimeFormatInfo.
Pour la mise en forme des nombres, utilisez la classe NumberFormatInfo.
Pour les calendriers grégoriens et non grégoriens, utilisez la classe Calendar ou l'une des implémentations de calendrier spécifiques.
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, par exemple la mise en forme des dates, des heures ou des nombres. Utilisez la propriété CultureInfo.CurrentUICulture pour récupérer des ressources. Notez que les propriétés CurrentCulture et CurrentUICulture peuvent être définies par thread.
Permettez à votre application de lire et d'écrire des données dans divers systèmes d'encodage à l'aide des classes d'encodage de l'espace de noms System.Text. Ne supposez pas que les données entrées dans votre application seront par défaut codées en ASCII. Supposez que des caractères internationaux seront fournis partout où un utilisateur peut entrer un texte. Par exemple, l'application doit accepter les caractères internationaux dans les noms de serveurs, de répertoires, de fichiers et d'utilisateurs, ainsi que dans les URL.
Lorsque vous utilisez la classe UTF8Encoding, pour des raisons de sécurité, utilisez la fonctionnalité de détection d'erreurs offerte par cette classe. Pour activer la fonctionnalité de détection d'erreurs, l'application crée une instance de la classe à l'aide du constructeur qui prend un paramètre throwOnInvalidBytes et lui affecte la valeur true.
Autant que possible, traitez les chaînes comme des chaînes entières, et non comme une série de caractères. Ceci est particulièrement important lorsque vous effectuez un tri ou que vous recherchez des sous-chaînes. Vous éviterez ainsi les problèmes liés à l'analyse de caractères combinés.
Affichez le texte à l'aide des classes fournies par l'espace de noms System.Drawing.
Pour préserver la cohérence parmi les divers systèmes d'exploitation, ne permettez pas aux paramètres utilisateur de se substituer à CultureInfo. Utilisez le constructeur CultureInfo qui accepte un paramètre useUserOverride et lui affecte la valeur false.
Testez les fonctionnalités de votre application sur des versions internationales des systèmes d'exploitation, en utilisant des données internationales.
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, l'application doit exécuter une opération indépendante de la culture. Cette pratique garantit que le résultat n'est pas affecté par la valeur de CultureInfo.CurrentCulture. Consultez Mappages de casse et règles de tri personnalisés pour un exemple qui montre comment des comparaisons de chaînes dépendantes de la culture peuvent produire des résultats incohérents.
Meilleures pratiques de localisation
Déplacez toutes les ressources localisables vers des bibliothèques DLL séparées, consacrées exclusivement à ces ressources. Les ressources localisables incluent les éléments d'interface utilisateur, tels que les chaînes, les messages d'erreur, les boîtes de dialogue et les menus, ainsi que les ressources d'objet incorporé.
Ne codez pas en dur les chaînes ou les ressources d'interface utilisateur.
Ne placez pas de ressources non localisables dans les DLL consacrées exclusivement aux ressources. Vous éviterez ainsi de compliquer la tâche des traducteurs.
N'utilisez pas de chaînes composites qui sont construites au moment de l'exécution à partir d'expressions concaténées. Les chaînes composites sont difficiles à localiser parce qu'elles supposent souvent un ordre grammatical anglais qui ne s'applique pas à toutes les langues.
Évitez les constructions ambigües telles que « Empty Folder », dans lesquelles les chaînes peuvent être traduites différemment selon les rôles grammaticaux de leurs composants. Par exemple, « empty » peut être un verbe ou un adjectif, ce qui conduit à des traductions différentes dans des langues telles que l'italien ou le français.
Évitez d'utiliser des images et des icônes qui contiennent du texte dans votre application. Le coût de leur localisation est élevé.
Prévoyez beaucoup de place pour la longueur des chaînes à développer dans l'interface utilisateur. Dans certaines langues, les phrases sont de 50 à 75 % plus longues que dans d'autres.
Utilisez la classe System.Resources.ResourceManager pour récupérer des ressources selon culture.
Utilisez Visual Studio 2010 pour créer des boîtes de dialogue Windows Forms, que vous pourrez localiser à l'aide de Windows Forms Resource Editor (Winres.exe). Ne codez pas les boîtes de dialogue Windows Forms manuellement.
Confiez la localisation (la traduction) à des professionnels.
Pour une description complète de la création et de la localisation des ressources, consultez Ressources dans les applications.
Meilleures pratiques de globalisation pour les applications ASP.NET
Définissez explicitement les propriétés CurrentUICulture et CurrentCulture dans vote application. Ne comptez pas sur leurs valeurs par défaut.
Notez que les applications ASP.NET sont des applications managées et, par conséquent, peuvent 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.
Gardez à l'esprit que vous pouvez spécifier les trois types d'encodage suivants dans ASP.NET :
requestEncoding spécifie l'encodage reçu du navigateur du client.
responseEncoding spécifie l'encodage à envoyer au navigateur du client. Dans la plupart des situations, 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.
Spécifiez les valeurs des attributs requestEncoding, responseEncoding, fileEncoding, culture et uiCulture aux 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 <globalization>, élément.
Dans une directive de page. Notez que lorsqu'une application se trouve dans une page, le fichier a déjà été lu. De ce fait, il est trop tard pour spécifier fileEncoding et requestEncoding. Seuls uiCulture, Culture et responseEncoding peuvent être spécifiés dans une directive de page.
Par programme, dans le code de l'application. Ce paramètre peut varier par demande. Comme dans le cas de la directive de page, il est trop tard pour spécifier fileEncoding et requestEncoding au moment où le code de l'application est atteint. Seuls uiCulture, Culture et responseEncoding peuvent être spécifiés dans le code de l'application.
Notez que la valeur uiCulture peut être définie sur la langue acceptée par le navigateur. Pour plus d'informations, consultez l'exemple Utilisation de contrôles localisés dans le Démarrage rapide ASP.NET.
Voir aussi
Concepts
Ressources dans les applications