Meilleures pratiques pour développer des applications mondialisables
Mise à jour : novembre 2007
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 spécifiques de Calendar.
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 de codage à l'aide des classes de codage 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, acceptez 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, il est recommandé, pour des raisons de sécurité, d'utiliser la fonctionnalité de détection d'erreurs offerte par cette classe. Pour activer la fonctionnalité de détection d'erreurs, créez une instance de la classe à l'aide du constructeur qui prend un paramètre throwOnInvalidBytes et affectez la valeur true à throwOnInvalidBytes.
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 affectez à ce paramètre 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, effectuez une opération indépendante de la culture en spécifiant la propriété CultureInfo.InvariantCulture de manière explicite. Cette application 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 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 expressions peuvent exiger de 50 à 75 % d'espace supplémentaire.
Utilisez la classe System.Resources.ResourceManager pour récupérer des ressources selon culture.
Utilisez Microsoft Visual Studio 2005 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 de codage suivants dans ASP.NET :
requestEncoding spécifie le codage reçu du navigateur du client.
responseEncoding spécifie le codage à envoyer au navigateur du client. Dans la plupart des cas, ce type de codage doit être identique à requestEncoding.
fileEncoding spécifie le codage 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 uiCulture peut être défini comme 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