Tout d’abord, petit rappel pour planter le décor. Avec SharePoint 2010, vous avez 2 mécanismes pour supporter le multilingue :

• les variantes (ou l’anglicisme “variations”) permettent de gérer “n” copies d’une arborescence de sites “source”, généralement pour chacune des langues désirées, avec un système de redirection entre les différentes versions . On est ici principalement dans de la localisation de contenu (les pages) pour des sites de publication, l’interface se basant sur la langue du site
• le MUI ou Multilingual User Interface permet de bénéficier d’une interface multilingue (configuration au niveau du site), facilitant ainsi l’administration et les manipulations dans l’interface. En revanche, le contenu reste localisé.

Dans les 2 cas, l’utilisateur, par défaut, est redirigé vers le site correspondant à sa langue de navigation pour les variantes, et profite de l’interface localisée dans le cas du MUI. Si la langue du navigateur n’est pas trouvée, c’est la langue par défaut qui sera de fait proposée.

Cependant, les 2 systèmes ont été conçus à la base pour 2 besoins distincts. Mais que se passe-t-il si on active les 2 ?

Et bien, cela dépend de la configuration des sites :

• votre langue correspond à une des variantes et à une des langues du MUI : super, vous avez tout bon (c’est la même chose que le cas où vous n’avez que le mécanisme des variantes)
• votre langue ne correspond pas à une variante mais elle est référencée dans le MUI du site “source/défaut” : là, vous allez débarquer sur un site qui risque de vous proposer un contenu dans une langue, et une interface dans une autre. D’où problème !

Pourquoi ça ? Parce que la localisation de l’interface s’appuie sur le système de localisation ASP.NET à base de RESX retournant les labels par rapport à la langue de la culture courante (au niveau du Thread, le CurrentCultureUI).

Si vous n’avez pas activé le MUI, cette culture se base sur la langue du site courant. Si vous l’avez activé, ce sera la langue courante du MUI, qui peut donc différer de celle du site. C’est après tout ce que l’on cherche quand on fait du collaboratif, mais pour des sites de publications (intra/internet) utilisant les variantes, ce n’est pas toujours la même histoire .Et même nul besoin de  variantes à vrai dire ! Imaginez le cas “simple” de site créé en anglais mais avec le français en plus au niveau du MUI ==> vous tomberez sur un site en franglais (pour les composants standards et les références à “$Resources…”). Vous pouvez aussi avoir des soucis avec vos scripts et vos feuilles de styles si vous avez eu recours à SPUrl et au token ~language : celui-ci utilisera aussi la culture courante et non la langue du site !

Bref, attention à ne pas activer le MUI pour vos sites de publication sans avoir bien réfléchi aux conséquences que cela pourrait provoquer.

Il existe cependant une alternative. J’avais écrit il y a quelques années un bout de code permettant d’utiliser l’API SharePoint et les fichiers de ressources du “12” pour la localisation : http://www.sharepointofview.fr/gat/archive/2008/06/08/expression-builder-et-localisation.aspx. Vous trouverez le code au sein du projet SharePoint of View sur Codeplex.

Et bien dans le même ordre d’idée, vous pouvez créer votre propre expression builder qui ira récupérer la langue du site courant et le passera à la méthode de globalisation :

Ainsi, vous n’aurez plus qu’à déclarer cet expression builder dans votre web.config et remplacer vos “$Resources:…” en “$SPResources:…” et rester cohérent avec la langue du site.

Gat, localement vôtre