L’exportation de gabarits de sites et l’affichage multilingue

Avez-vous déjà tenté d’utiliser les principes du ALM de Microsoft quant au développement dans la plateforme SharePoint 2010 ? Évidemment, plusieurs éléments facilitent le travail de transfert de requis entre l’analyste et le développeur.  Par exemple, le développeur n’a plus à créer les différents schémas XML permettant de publier les types de contenu ainsi que les colonnes de sites.  Bien que fort pratique, cette façon de faire amène un problème néfaste à la réalisation de sites multilingues.

Le principe est fort simple.  Il suffit d’utiliser le menu de sauvegarde d’un gabarit de site offert par SharePoint 2010!  Le menu suivant permet de sauvegarder la structure du site actuel et génère un .wsp qui peut être utilisé plus tard dans Visual Studio afin d’importer un gabarit et de ne pas avoir à tout refaire les éléments simples (colonnes, types de contenu, pages, définitions de listes, etc.)

Le problème

Dans le cas simple d’un site unilingue, ce principe semble fonctionner à la perfection. Par contre, lorsqu’on veut permettre à l’usager de changer de langue dans le même site, quelques problèmes se posent. Les titres (autant des types de contenus que des colonnes de site) et descriptions ne sont jamais traduits. Ils prennent la valeur de la langue par défaut du site dans lequel ils apparaissent. Comme dans l’exemple ci-dessous :

En français :

En anglais :

Ce problème se pose aussi dans les définitions de listes. Les colonnes ainsi que les types de contenu imbriqués directement dans les types de contenu (sans l’utilisation de ContentTypeRef) ne changent pas d’une langue à l’autre.

La solution

L’exportation des sites (et donc de tous ses archétypes) injecte une propriétés dans les types de contenu et dans les colonnes de site qui semble totalement inoffensive, mais qui empêche quelconque changement dynamique de langue dans un site.

Voici un schéma généré par une exportation d’un site via l’outil d’exportation de SharePoint 2010 :

  <Field     
    ID="{14F74BA9-3AD9-4F68-8387-ADA4F6F866C3}"     
    Name="TestLocalizationField1"
    StaticName="TestLocalizationField1"     
    DisplayName="$Resources:TestLocalization,Field1Name"
    Description="$Resources:TestLocalization,Field1Description"
    Group="$Resources:TestLocalization,Field1Group"
    Type="Text"
    Overwrite="TRUE" />

L’attribut “Overwrite=’TRUE’” (voir sa définition ici) permet d’écraser un type de contenu (ou une colonne de site) avec le même identifiant que celui spécifié.  Malheureusement, cet attribut empêche aussi d’avoir un dynamisme quant à l’interface multilingue de SharePoint 2010.  En retirant cet attribut, les types de contenu et les colonnes de site reprennent leur comportement normal.

Le schéma qui fonctionne et qui permet d’afficher les éléments dans les bonnes langues est le suivant :

  <Field
    ID="{278BBA30-1D02-42DC-A5DE-5618C236D2D7}"
    Name="TestLocalizationField1NoOverwrite"
    StaticName="TestLocalizationField1NoOverwrite"
    DisplayName="$Resources:TestLocalization,Field1NameNoOverwrite"
    Description="$Resources:TestLocalization,Field1DescriptionNoOverwrite"
    Group="$Resources:TestLocalization,Field1GroupNoOverwrite"
    Type="Text" />

Le résultat final devient donc fonctionnel et beaucoup plus efficace que celui généré par les outils d’exportation de base de SharePoint 2010.

En français :

En anglais :

Conclusion

Veuillez toujours valider que vos archétypes ne contiennent pas l’attribut “Overwrite=’TRUE’” dans le cas où vous voulez utiliser les interfaces multilingues de SharePoint 2010!  Et espérons, qu’un jour, les groupes de catégories de champs et de types de contenu seront, eux aussi, localisables…

Pour télécharger la solution de test de localisation, utilisez le lien suivant :

Laisser un commentaire

NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>