Comprendre l'internationalisation avec ASP.NET AJAX

Cet article est la traduction la plus fidèle possible de l'article original : Understanding ASP.NET AJAX Localization

La technologie Microsoft ASP.Net apporte un modèle orienté objet, gérable via les évènements, et l'unit avec les bénéfices d'un code compilé. Pourtant, son modèle d'exécution côté serveur a plusieurs inconvénients inhérents à la technologie, pour lesquels beaucoup peuvent être abordés grâce à la nouvelle fonctionnalité incluse dans l'espace de nom System.Web.Extensions, qui encapsule les services Microsoft AJAX dans le Framework .Net 3.5. Ces extensions permettent plusieurs riches fonctionnalités clientes, qui étaient jusqu'alors accessibles en tant que partie des extensions ASP.Net 2.0 AJAX, mais qui maintenant sont incluses dans la bibliothèque de classe de base du Framework. Les contrôles et fonctionnalités de cet espace de nom incluent le rendu partiel des pages sans nécessité un rafraichissement complet de la page, la possibilité d'accéder à des Web Services via un script client (incluant l'API de profiling ASP.Net) et un API côté client étendu architecturé pour recoder côté client, une partie des schémas de contrôle que l'on pouvait trouver côté serveur.

Ce livre blanc examine les fonctionnalités d'internationalisation présentent dans le Framework AJAX de Microsoft et dans la bibliothèque Microsoft AJAX Script Library, dans un contexte professionnel du besoin de prise en charge de la localisation dans une application ASP.Net. La bibliothèque Microsoft AJAX Script LibraryThe Microsoft AJAX Script Library utilise le format de fichier .resx déjà utilisé par les applications .Net, qui fournit un format directement éditable via un IDE et un type de ressource partagé.

Ce livre blanc est base sur la beta 2 de Microsoft Visual Studio 2008. Ce livre blanc estime que vous utiliserez Visual Studio 2008 et non Visual Web Developer Express et vous fournira des guides d'utilisation basés sur l'interface de Visual Studio. Certains exemples de code utilisent des templates de projets qui ne sont pas disponibles avec Visual Web Developer Express.

Particulièrement pour les développeurs d'applications d'entreprise ou de composants, la possibilité de créer des outils pouvant utiliser plusieurs langues ou cultures devient de plus en plus nécessaire. Concevoir des composants pouvant s'adapter à la langue du client améliore la productivité et réduit la quantité de travail requis pour adapter un composant à fonctionner de façon globale.

L'internationalisation est le processus de design et de l'intégration du support d'un langage particulier ou d'une culture dans une application ou dans un composant d'application. La plateforme Microsoft ASP.Net fournit un support étendu pour internationaliser les applications ASP.Net standards, en intégrant le modèle standard d'internationalisation ; le Framework Microsoft AJAX utilise le modèle intégré pour supporter les divers scénarios dans lesquels l'internationalisation peut être effectuée.

Avec le Framework, les scripts peuvent être localisés soit en les déployant dans des bibliothèques satellites, soit en utilisant une structure de fichier script statique.

Respectant la stratégie d'internationalisation du Framework .Net, les ressources peuvent être incluses dans des bibliothèques satellites. Les bibliothèques satellites fournissent plusieurs avantages par rapport à l'inclusion traditionnelle de ressources dans les binaires : mise à jour d'une des langues sans tout recompiler, possibilité d'ajouter une nouvelle bibliothèque de langue, et surtout possibilité de déployer cette nouvelle langue sans nécessiter le rechargement de la bibliothèque principale du projet. Particulièrement dans les projets ASP.Net, ceci est avantageux parce que cela peut réduire de façon conséquente la quantité de ressources système utilisées par les mises à jour incrémentielles, et dérange un minimum l'utilisation des sites en production.

Les scripts sont inclus dans les bibliothèques en les incluant dans les fichiers .resx managés (ou ressources compilées) , qui sont alors inclus dans les bibliothèques au moment de la compilation. Leurs ressources sont alors rendues accessibles par l'application script via le code AJAX, grâce à des attributs au de niveau de la bibliothèque.

C-1. Convention de nommage pour l'inclusion de fichiers de scripts▲

• 1. Créez un nouveau projet de type Site avec les extensions AJAX intégrées. Créez un second projet de type bibliothèque de classe dans la solution nommée LocalizingResources.
• 2. Ajoutez un fichier JavaScript nommé “VerifyDeletion.js »au projet LocalizingResources, ainsi que deux fichiers de ressources nommés “DeletionResources.resx » et “DeletionResources.es.resx. ». Le premier contiendra les ressources multicultures (neutre) tandis que le second contiendra les ressources espagnoles.
• 3. Ajoutez le code suivant à VerifyDeletion.js :

function VerifyDeletion(fileName) 
{      
    if (confirm(Message.VerifyDelete.replace(/FILENAME/, fileName)))      
    {           
        Delete(fileName);           
        return true;      
    }      
    return false; 
} 

function Delete(fileName) {      
    alert (Message.Deleted.replace(/FILENAME/, fileName)); 
}

Pour ceux qui ne sont pas familiers avec la syntaxe, Regex Javascript, le texte placé entre deux slashs (/FILENAME/ dans l'exemple précédent), dénote un objet RegExp. La MSDN contient une documentation complète sur le JavaScript et plusieurs ressources sur les objets natifs du JavaScript peuvent y être trouvées.

• 4. Ajouter les chaînes de ressources suivantes au fichier DeletionResources.resx :
• VerifyDelete: Are you sure you want to delete FILENAME?
• Deleted: FILENAME has been deleted.
• 5. Ajouter les chaînes de ressources suivantes au fichier DeletionResources.es.resx :
• VerifyDelete: ¿Está seguro que desee quitar FILENAME?
• Deleted: FILENAME se ha quitado.
• 6. Ajoutez les lignes suivantes au fichier AssemblyInfo :

[assembly: System.Web.UI.WebResource("LocalizingResources.VerifyDeletion.js",      "text/javascript")] 
[assembly: System.Web.UI.ScriptResource("LocalizingResources.VerifyDeletion.js",      "LocalizingResources.DeletionResources", "Message")]

• 7. Ajoutez les références à System.Web et System.Web.Extensions
• 8. Ajoutez une référence au projet LocalizingResources depuis le projet de site Web.
• 9. Dans le fichier default.aspx, mettez à jour le contrôle ScriptManager avec le marquage suivant :

<asp:ScriptManager ID="ScriptManager1" runat="server" EnableScriptLocalization="true">      
    <Scripts>           
        <asp:ScriptReference Assembly="LocalizingResources" Name="LocalizingResources.VerifyDeletion.js"/>      
    </Scripts> 
</asp:ScriptManager>

• 10. Dans le fichier default.aspx, placez le code suivant :

<asp:Button ID="btnDelete" runat="Server" OnClientClick="VerifyDeletion('a.txt');" Text="Delete" />

• 11. Appuyez sur F5. Si on vous le demande, activez le débogage. Lorsque la page est chargée, appuyez sur le bouton Delete. Remarquez que le message de confirmation apparait en anglais (sauf si votre ordinateur est configuré pour utiliser l'espagnol comme langue par défaut).
• 12. Fermez votre navigateur et retournez sur le fichier default.aspx. Dans la directive de page @Page, remplacer « auto » par « es-ES » pour les attributs Culture et UICulture. Appuyez sur F5 encore une fois pour lancer l'application. Cliquez sur le bouton Delete pour voir le message espagnol apparaitre :

Sachez que ce comportement peut être obtenu grâce à d'autres techniques. Vous pourriez par exemple enregistrer les scripts avec le contrôle ScriptManager via l'évènement Load de la page.

Lorsque vous utilisez des fichiers de scripts statiques pour le déploiement, vous perdez l'avantage d'utiliser le schéma inhérent de l'internationalisation .Net. Premièrement, vous perdez le typage automatique généré par l'inclusion des fichiers de ressources script ; dans l'exemple précédent, les ressources sont exposées via un type autogénéré par le contrôle ScriptManager nommé « Message ».

Il existe pourtant certains avantages à utiliser une structure de fichier script statique. Les mises à jour peuvent être exécutées sans recompiler et redéployer les bibliothèques satellites.

Microsoft recommande d'éviter les problèmes de version en générant automatiquement vos ressources script durant la compilation. Lorsque vous maintenez un code script de grande taille, il peut devenir très compliqué de s'assurer les modifications de code sont appliqués à tous les scripts localisés. Comme bonne alternative, vous pouvez maintenir un unique script de logique et plusieurs scripts de localisation et les fusionner à la compilation.

Comme ce ne sont pas des ressources, pour les inclure de façon déclarative, les fichiers scripts statiques doivent être référencés soit en ajoutant des éléments <asp:ScriptElement> au nœud <Scripts> du ScriptManager, soit en les ajoutant par le code en ajoutant des objets ScriptReference à la propriété Scripts du contrôle ScriptManager.

Le ScriptManager permet plusieurs comportements automatiques pour les applications multilangages.

• Il traduit automatiquement les fichiers de scripts en se basant sur les paramètres et les conventions de nommage. Par exemple, il charge les scripts lorsqu'il est en mode Debug et charge les scripts localisés en se basant sur la configuration du navigateur Web.
• Il permet la définition de cultures, y compris les cultures personnalisées.
• Il permet la compression de fichiers au travers du protocole HTTP.
• Il met en cache les scripts pour gérer efficacement plusieurs requêtes.
• Il ajoute une couche pour l'indirection des scripts en les passants à travers une URL encodée.

Les références aux scripts peuvent être rajoutées au contrôle ScriptManager soit par programmation, soit par des tags déclaratifs. Le marquage déclaratif est particulièrement utile lorsque vous travaillez avec des scripts intégrés dans des bibliothèques différentes que le projet lui-même comme le nom du script ne changera probablement pas lorsque les évolutions sont faites.

Comme les applications Web grandissent pour toucher un nombre sans cesse croissant d'utilisateurs, le besoin d'être capable de toucher des cultures et communautés étrangères devient central dans un business model; les applications Web d'e-commerce ont besoin d'être capables de prendre en compte les devises étrangères, les systèmes de gestion de contenu doivent être capables d'afficher leur contenu, mais également les conseils de navigations ou les champs de formulaires dans différentes langues et les entreprises ont besoin de savoir que ce besoin est accessible.

Le Framework .Net supporte intrinsèquement un riche Framework d'internationalisation, utilisant des bibliothèques satellites et des fichiers de ressources XML (.resx) pour présenter une façon uniforme de chercher des chaînes ou des images en ressources. Les extensions ASP.Net AJAX, incluant le Framework Microsoft AJAX et Microsoft AJAX Script Library, fournissent le support de ce modèle de programmation dans un code coté client, permettant la recherche rapide de chaîne de ressource. Les bibliothèques satellites supportent l'inclusion automatique de script de ressources (fichiers .js) via ScriptResource.axd aussi longtemps que les noms de fichiers suivent un schéma de nommage de fichier. Avec ce support, les extensions ASP.Net Ajax simplifient l'internationalisation de scripts et la globalisation des applications.

Scott Cate travaille avec les technologies Microsoft Web depuis 1997 et est le président de myKB.com (www.myKB.com) où il est spécialisé l'écriture d'applications ASP.N orientées autour de solution de base de connaissances. Scott peut être contacté par email vie scott.cate@myKB.com ou via son blog http://weblogs.asp.net/scottcate