Souvenez-vous : je donnais il y a quelques temps une astuce pour pouvoir localiser (comprendre traduire) facilement ses développements SharePoint (webparts, pages d'administration, ...) grâce à l'API SharePoint, puis une discussion sur la mise à jour des ressources (dont les resx) vers toutes les applications web grâce à la commande "stsadm -o copyappbincontent".

Au final :

• D'un côté je peux utiliser directement l'API pour que mes développements supportent plusieurs langues sans nécessairement déployer les resx dans les applications web (répertoire App_GlobalResources) et donc utiliser les mêmes méthodes pour des composants webs autant que dans des applications hors contexte web (jobs, certains receivers, ...)
• De l'autre je peux gérer comme dans n'importe quel site ASP.Net mes ressources de localisation, dont la fort pratique expression <% $Resources:file,key %>

Ce qui m'ennuie en tant que développeur, c'est que :

• si je décide de n'utiliser que l'API, localiser des page layouts, master pages ou des pages d'administration s'avère beaucoup (beaucoup) plus fastidieux qu'avec la méthode traditionnelle ASP.Net
• si je veux garder mes habitudes de développeur ASP.Net, je ne pourrai pas proprement déployer mes fichiers resx dans le répertoire App_GlobalResources, sauf si l'application web cible sera créée pour l'occasion ou si je passe par la case stsadm avec un compte administrateur de la machine (et ce sur tous les serveurs frontaux)

Bref, j'ai des avantages des 2 côtés, mais aussi certains inconvénients.

Mon objectif étant de n'avoir que des avantages (tant qu'à faire !), voici une proposition d'implémentation grâce à l'utilisation des Expression Builders :

• créer un nouvel expression builder permettant ainsi d'avoir la même syntaxe et facilité que pour celui d'ASP.Net mais utilisant l'API SharePoint : on se débarrasse ainsi plus de problématique de déploiement des fichiers de ressources dans l'application web => un seul fichier resx qui sera utilisé dans l'ensemble des éléments de mon application (interfaces web autant que features, jobs, ...)
• enregistrer proprement cet expression builder dans le fichier de configuration des applications web cibles grâce aux SPWebConfigModification (oui je sais, ça faisait longtemps que je n'en avais pas parlé ;))

En synthèse (je fournirai très bientôt le sample complet sur CodePlex, sachez cependant qu'il est déjà intégré au projet CKS:EBE mais pas disponible avant la prochaine release) :

• Définition de l'expression builder et surtout de sa méthode ParseExpression qui va nous permettre de récupérer la traduction suivant la langue du site:
  

  public override object ParseExpression(string expression, Type propertyType, ExpressionBuilderContext context)

  {

    // Format : $SPResources:file,key

    string[] parts = expression.Split(',');

    string resKey = null;

    // Default resource file

    string resFile = "core";

    if (parts.Length == 1)

    {

       resKey = parts[0];

    }

    else

    {                

      resFile = parts[0];

      resKey = parts[1];

    }

    // Return translation

    return SPUtility.GetLocalizedString("$Resources:" + resKey, resFile, SPContext.Current.Web.Language);

  }

• Ecriture de la feature avec événement sur activation et désactivation pour ajouter la ligne suivante au fichier de configuration via une SPWebConfigModification :

  <add expressionPrefix="SPResources" type="MonType, MonAssembly, Version=0.1.0.0, Culture=neutral, PublicKeyToken=[PublicKeyToken]" />

Et le tour est joué !

Ensuite, pour l'utiliser, il n'y a plus qu'à déployer ses fichiers de ressources dans le répertoire 12\Resources (ça c'est facile à faire avec les solutions et leur générateur, par exemple pour WSPBuilder il suffit de les mettre dans le répertoire 12\Resources de votre projet), déployer la feature et l'utiliser au sein des pages sous la forme :

<asp:Label id="lbHelloWorld" runat="server" Text="<%$ SPResources:gat,HelloWorld %>" />

Et obtenir au choix "Hello world", "Bienvenue le monde", etc...

Gat, SPLocalisateur