When creating solutions in SharePoint, it often is necessary to deploy the solution for several languages. Because we can use resource files in our solution that is not really a problem. But what should we do, when our solution is already deployed and we then need to add resources for another language? Simple answer: create a language pack for the solution.
Microsoft has a rough description in the SharePoint SDK how to create such a language pack. This post will show a short description of the steps to create a language pack.
1. step: the core solution
First of all we need the core solution, to implement the functionality that should be added. It’s a good way to create a Visual Studio solution, when we start this implementation.
In this solution, we map the resources folder of the 14-hive (or the 15-hive for SharePoint 2013 J).
In this folder we store our resx-file for the resource keys. Although it is possible to create feature related resource files it has proven in practice to create one central resource file. This method makes it easier to translate the resources into other languages, because there is just one file to translate.
If some of the resources are needed on the web frontend, what means, they need to be deployed into the App_GlobalResources folder in inetpub, we have to add additional lines to the package file.
When these initial steps are finished, we can implement all the stuff for our solution. Whenever we use any text used for output, we just enter the link to the resource file. Never use explicit text for output.
The deployment of our solution is as simple as shown in several other posts or books. We use Add-SPSolution to add the solution to our farm and Install-SPSolution to deploy the solution.
Add-SPSolution C:\Folder\MySolution.wsp Install-SPSolution MySolution.wsp -WebApplication http://...
That’s all for the core solution. The important part: use a resource file for each output.
2. step: the language pack
The next step is the creation of the language pack. The language pack is another solution. That means we create a second wsp-package. The two important notes for this package:
- The SolutionID of the package is the same as for the core solution.
- There is no additional functionality in this package, just the translated resource file.
So, first we create another project in our Visual Studio solution. The template we use is an “Empty SharePoint Project”. To show the language, we implement in this solution, we add a two-letter identifier to the name of the core solution, we translate in this solution.
Next we double click the Package.package file of the solution and add the Solution ID of our core solution. This ID could be copied from the Package.package file in the core solution project.
Then we map the resources folder of our 14-hive and copy the resx-file from the core solution to this folder. This resx-file is then renamed so it gets the correct language part. In this example we create a language pack for the german language, so the resx-file should end with “.de-DE.resx”.
As for the core solution, when resources need to be deployed to the inetpub folder, we have to add some nodes to the package file.
Now, we can translate the text in the resource file of our language pack project. When this part is finished, we can create the package for installation from within Visual Studio.
The installation of the language pack is done with PowerShell with the same cmdlets as the deployment of the core solution. The only difference: when have to add the language parameter. So, we have to call these two commands:
Add-SPSolution C:\Folder\MySolution-DE.wsp -Language 1031 Install-SPSolution MySolution-DE.wsp -WebApplication http://... -Language 1031
Important: the language ID has to match the language we install with this language pack and when the language pack for a solution is added and installed, the core solution must already be added and installed.
When we have a look into the farm solution in Central Administration, we see both solutions.
When looking into the details of these solutions we see the different types of the solution. Here the core solution:
And the details of the solution for the language pack:
When the solution needs to be retracted, we first have to retract all language packs and then the retraction of the core solution could be startet.
When you have to translate the solution in several languages, use one language pack for each language. That makes it easier to get an overview, which language packs are created for the solution. Never mix several languages in one language pack.