Partager via


Utilisation de solutions de batterie de module linguistique

Dernière modification : mercredi 2 février 2011

S’applique à : SharePoint Foundation 2010

Dans cet article
Qu’est-ce qu’un module linguistique personnalisé ?
Création d’un module linguistique
Ressources relatives aux fonctionnalités
Ajout et déploiement d’un module linguistique

Cette rubrique décrit comment développer et installer une localisation d’une solution de batterie de serveursMicrosoft SharePoint Foundation à l’aide de packages de solution qui ont été désignés en tant que modules linguistiques.

Notes

Le terme module linguistique utilisé dans cette rubrique ne fait pas référence aux modules linguistiques SharePoint Foundation et Microsoft SharePoint Server 2010 fournis par Microsoft, ceux-ci assurant la localisation de l’interface utilisateur intégrée de SharePoint Foundation et de SharePoint Server 2010. Les modules linguistiques fournis par Microsoft sont des fichiers .exe que vous pouvez télécharger à partir du Centre de téléchargement Microsoft et installer sur chaque serveur Web frontal. Pour plus d’informations, voir Préparation de la création de solutions SharePoint localisées, Modules linguistiques pour SharePoint Foundation 2010 et Modules linguistiques Server 2010 pour SharePoint Server 2010, Project Server 2010, Search Server 2010 et Office Web Apps 2010.

Qu’est-ce qu’un module linguistique personnalisé ?

Un module linguistique personnalisé est un package de solution (fichier .wsp) qui contient uniquement les ressources utilisées pour ajouter la prise en charge d’une langue supplémentaire à une solution de batterie de serveurs existante. Il possède le même ID de solution (GUID) que la solution d’origine. Une fois la solution d’origine ajoutée et déployée, le module linguistique peut être ajouté à la batterie et déployé dans celle-ci à tout moment. Un module linguistique personnalisé n’est pas nécessaire lorsque des ressources de localisation, telles que des chaînes, sont disponibles avant la distribution d’un package de solution. De telles ressources peuvent être incluses dans le package d’origine pour la solution. L’objectif principal des modules linguistiques personnalisés est de permettre aux développeurs d’ajouter la prise en charge de langues supplémentaires une fois le package de solution d’origine distribué, et ce sans qu’il soit nécessaire de le mettre à niveau.

Si vous préférez, vous pouvez créer des modules linguistiques pour une nouvelle solution et les inclure avec la solution d’origine. Toutefois, dans un souci de simplicité, cet article suppose que les modules linguistiques sont distribués après la solution d’origine.

Notes

Les modules linguistiques personnalisés ne sont pas pris en charge dans les solutions en bac à sable (sandbox). Pour plus d’informations sur la localisation d’une solution en bac à sable (sandbox), voir Localisation de solutions en mode bac à sable (sandbox).

Aucun élément dans le fichier .wsp ne le désigne en tant que module linguistique. En fait, la désignation réside dans l’entrée de la base de données de configuration du module linguistique. Cette désignation est enregistrée lorsque la solution de module linguistique est ajoutée au magasin de solutions de la batterie et lorsqu’elle est déployée.

Important

Il incombe à l’administrateur de batterie d’ajouter et de déployer correctement la solution, à l’aide de SharePoint Management Shell ou du modèle objet, de manière à la désigner en tant que module linguistique. Vous trouverez plus d’informations sur la façon de procéder plus loin dans cette rubrique. Nous recommandons aux développeurs d’inclure l’ID de paramètres régionaux dans le nom du fichier .wsp pour faciliter la tâche des administrateurs.

Tenez compte des points suivants lorsque vous développez un module linguistique, et veillez à ce que les administrateurs de batterie à qui vous distribuez les modules linguistiques aient également conscience de ces points :

  • La solution de batterie de serveurs d’origine peut contenir des ressources de localisation pour aucune langue ou plus. Les modules linguistiques ajoutent des ressources pour des langues supplémentaires.

  • Un module linguistique ne peut être lié qu’à une seule langue.

  • Un module linguistique ne peut être associé qu’à une solution d’origine.

  • Un module linguistique ne peut pas être ajouté au magasin de solutions, sauf si la solution d’origine qu’il localise se trouve également dans le magasin de solutions.

  • Un module linguistique ne peut être déployé que si la solution d’origine à laquelle il est associé est déployée.

  • Une solution ne peut être retirée que si tous les modules linguistiques qui lui sont associés sont retirés en premier.

Création d’un module linguistique

La création d’un module linguistique s’apparente à la création de n’importe quel autre package de solution (fichier .wsp).

Pour créer un module linguistique

  1. Créez une Solution SharePoint vide dans Microsoft Visual Studio. Donnez à la solution le même nom que la solution d’origine en cours de localisation, mais ajoutez un LCID au nom de la solution pour indiquer la langue que la nouvelle solution prend en charge. (Un module linguistique personnalisé ne peut prendre en charge qu’une seule langue.)

  2. Dans l’Explorateur de solutions, double-cliquez sur le fichier .package pour ouvrir la fenêtre Propriétés.

  3. Remplacez l’ID de solution généré automatiquement par le même ID de solution que la solution d’origine.

  4. Ajoutez les fichiers localisés à la solution, en gardant à l’esprit les points suivants :

    • N’ajoutez pas de fichiers de code ou d’autres fichiers non localisables au package.

    • Dans l’ensemble, la structure de dossiers dans l’Explorateur de solutions doit correspondre à la structure de dossiers de la solution d’origine lorsque celle-ci est ouverte en tant que projet Visual Studio (à ceci près que vous ne devez pas dupliquer les dossiers contenant uniquement des fichiers non localisables). Par exemple, si la solution d’origine a un dossier mappé SharePoint à %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\IMAGES, la solution de module linguistique doit se présenter de la même manière. (Les ressources relatives aux fonctionnalités constituent une exception à cette règle. Voir Ressources relatives aux fonctionnalités plus loin dans cette rubrique.)

    • Vous pouvez inclure n’importe quelle ressource localisable. Parmi les plus couramment utilisées, citons les suivantes :

      • Fichiers de ressources (.resx), qui peuvent être déployés globalement ou vers une application Web, une fonctionnalité ou un composant WebPart spécifique.

      • Assemblys satellites.

      • Fichiers de définition de site spécifiques à une langue (webtemp*.xml). Pour plus d’informations sur les fichiers de ce type, voirProcédure : créer des versions localisées de définitions de site personnalisées.

      • Pages d’application spécifiques à une langue.

      • Fichiers images, fichiers CSS et fichiers HTML spécifiques à une culture.

  5. Générez la solution Visual Studio, empaquetez-la et déployez-la dans votre environnement de développement à des fins de test. La solution d’origine qui est localisée doit déjà être déployée.

  6. Répétez la procédure pour chaque langue. Chaque langue doit être un package de solution distinct.

Ressources relatives aux fonctionnalités

Si l’un de vos fichiers de localisation s’applique uniquement à une fonctionnalité spécifique dans la solution d’origine, vous devez ignorer la règle habituelle qui consiste à faire correspondre la structure de dossiers de votre solution de module linguistique à celle de la solution d’origine. Cela est dû au fait que les ressources pour la langue supplémentaire doivent être déployées dans un sous-dossier du dossier %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES\MyOriginalFeature. Par exemple, un fichier RESX est généralement déployé dans %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES\MyOriginalFeature\Resources. Toutefois, vous ne pouvez pas réutiliser le nom et l’ID de fonctionnalité de la solution d’origine. (Une telle opération provoquerait une erreur au moment du déploiement de la solution.) Au lieu de cela, utilisez un élément RootFile dans le manifeste de votre package de solution pour spécifier le chemin d’accès de déploiement pour le fichier. Vous trouverez un exemple ci-après.

<Solution ... >
  <RootFiles>
    <RootFile Location="TEMPLATE\FEATURES\MyOriginalFeature\Resources\Resources.fr-ca.resx" />
  </RootFiles>
</Solution>

Ajout et déploiement d’un module linguistique

Les administrateurs de batterie déploient des modules linguistiques dans le magasin de solutions d’une batterie et les déploient avec SharePoint Management Shell (ou en exécutant un code de déploiement personnalisé à l’aide du modèle objet SharePoint Foundation).

La commande Add-SPSolution est utilisée dans SharePoint Management Shell pour ajouter la solution au magasin de solutions de la batterie. Le paramètre -Language doit être utilisé pour désigner la langue. Par exemple, la commande suivante ajoute le module linguistique Français (Canada). Notez que le LCID est également ajouté au nom du fichier de solution en vue de faciliter la tâche des administrateurs.

Add-SPSolution -LiteralPath C:\MySharePointSolutions\OriginalSolution_3084.wsp -Language 3084

Pour déployer la solution, utilisez la commande Install-SPSolution. Là encore, veillez à inclure le paramètre -Language.

Install-SPSolution -Identity OriginalSolution_3084.wsp -Language 3084

Les administrateurs doivent également utiliser le paramètre -Language lors du retrait et de la suppression d’un module linguistique, comme indiqué par les deux commandes suivantes. Ceci est important, car le package de solution d’origine et tous ses modules linguistiques ont le même ID de solution.

Uninstall-SPSolution -Identity OriginalSolution_3084.wsp -Language 3084
Remove-SPSolution -Identity OriginalSolution_3084.wsp -Language 3084

Pour programmer une installation et un déploiement personnalisés, utilisez les classes suivantes.

Voir aussi

Concepts

Création manuelle d’une solution

Localization of Farm Solutions in SharePoint 2010