Etant donnés les contextes très souvent multilingues en entreprise (le français bien sûr, mais aussi l'anglais, l'allemand, espagnol...), vos développements (webparts, pages layouts, types de contenu, ... et bien sûr les features associées) se doivent de présenter une interface en phase avec le site qui les héberge.

Sans tomber dans une présentation générale de la localisation ("globalization"), j'aimerai vous parler d'une petite méthode disponible dans la classe SPUtility (qui comme son nom l'indique contient tout plein de petites méthodes fort pratiques allant de la transformation de date au format ISO8601 pour les requêtes CAML à l'envoi de mails) du namespace Microsoft.SharePoint.Utilities : GetLocalizedString.

Cette méthode prend 3 paramètres :
      public static string GetLocalizedString(string source, string defaultResourceFile, uint language);

• source : nom de la clé de resource, sous la forme "$Resources:NomDeLaClef"
• defaultResourceFile : base du nom des fichiers de ressources, par exemple "SupaResources" pour les fichiers "SupaResources.resx", "SupaResources.fr-FR.resx", "SupaResources.en-US.resx", ...
• language : LCID (code langue) utilisée pour la localisation, par exemple 1033 pour l'anglais, 1036 pour le français...

Et voici un petit exemple d'utilisation prenant en compte le contexte courant (site web affichant l'info) le tout englobé dans une petite méthode Helper histoire de gagner en simplicité : 

        internal static string ResourcesPrefix = "SupaResources";

        public static string GetResource(string key, uint language)

        {

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

        }

Et là où vous désirez récupérer le texte dans la langue adéquate:

        this.label1.Text = GetResource("BlogTitle");

Simple non ?

Et super utile puisque les fichiers resx situés dans le répertoire 12\Resources peuvent être mis à jour facilement via le déploiement d'une solution. En revanche, ces fichiers ne sont pas ajoutés au répertoire "App_GlobalResources" de votre application web. En effet, seuls les fichiers situés dans 12\CONFIG\Resources seront déployés, et encore, uniquement lors de la création de l'application web.

Bref, dans ce cas, soit votre solution a été déployée avant, soit c'est un peu mort.. ou presque car il existe quelques moyens détournés proposés par Mikhail Dikov, MVP SharePoint:

• dans son article "SharePoint Resources, Types, Use and Deployment" il propose une solution utilisant le système des jobs SharePoint
• dans une mise à jour de cet article il utilise cette fois-ci les événements sur activation des Features (les SPFeatureReceivers)

J'ai tout de même un doute sur le fonctionnement en ferme de serveur, il faudrait sans doute rajouter quelques lignes de code, mais l'essentiel est là.

J'espère vous avoir donné plein (de bonnes) idées

Gat, je traduis, you translate, er übersetzt, traducimos, lei traduce, они переводят  (je remercie mon sponsor: www.reverso.fr :D)