Localizing a Solution
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Both solutions and Web Part packages support language packs. A language pack is a collection of resources that are used to add language support to an existing core solution.
Windows SharePoint Services treats language packs in the same way as any other solutions; however, whether they are declared as language packs is based on how an administrator submits the package to the solution store. By specifying the language parameter on the command line (or through the object model), the administrator explicitly declares that a solution is a language pack.
Following are considerations for working with language packs:
A core solution can contain zero or more language sets. It can contain no language-specific resources (and therefore be nonfunctional without a language pack), or it can be multilingual and contain resources for several languages (where no additional language packs are required, or where language packs contain additional language support).
A language pack can be bound to only one language.
A language pack can be associated with only one core solution.
A language pack cannot be added to the solution store unless the core solution it modifies is also in the solution store.
A language pack cannot be deployed unless the core solution it is associated with is deployed.
A solution cannot be retracted unless all the language packs associated with it are retracted first.
Note
These restrictions do not apply to Web Part package language packs. For reasons of backward-compatibility, a Web Part package language pack can be added to the store and deployed, even if the core solution is not deployed.
Creating a Language Pack
A solution contains no localizable resources; therefore, by itself a solution is not bound to a language. Localizable resources that bind a solution to a particular language include the following:
Feature-specific resource files
Web Part package satellite assemblies and satellite resources
Language-specific Web template (webtemp*.xml) files
Language-specific _layout files
As with any other solution, a language pack contains a manifest.xml file at its root. It should have the same solution ID as the culture-neutral solution.
Note
For more information about the manifest.xml file, see Creating a Solution.
To add resources to a solution, define a section in the language pack's manifest file inside the <Resources> tag. When this tag is present in a manifest file, a culture sentinel file is automatically written.
Local feature resource files are placed in the path <featuredir>\Resources\resources.<culture>.resx. The following example shows that the resource files are placed in <featuredir>/Resources/resources.1033.resx.
<Resources>
<Resource Location="\Resources\Resource.en-us.resx">
</Resource>
</Resources>
If the local resource file does not exist, the base shared resource file located in the path 12\Resources\core.en-us.resx is used.
Application resources are placed in the Resources directory of the Web application's virtual directory, and are designed to be used across features and site definitions, as shown in the following example.
<ApplicationResources>
<ApplicationResource Location="wss.fr-fr.resx">
</ApplicationResource>
</ApplicationResources >
In addition, language packs can contain one or more <TemplateFiles> tags to deploy any Web-based resources, such as .gif or static .htm files.
Localizing Web Part Language Packs
In most ways, Web Part package language packs are managed in the same manner as language packs for any solution. However, there are ways in which the solution framework handles Web Part language packs differently from the stsadm utility. Some of these ways are described earlier in this topic, while following are two additional important differences:
When using stsadm to add Web Part language packs, the language pack file name must be the same as the core solution file name. For example, if a developer creates a Web Part package named Weather.wpp that contains the core assemblies and definition for the Weather Web Part, and wants to add a language pack that contains the resource files for the French language, that language pack must also be named Weather.wpp. At deployment time, the administrator adds the .cab file with the –lcid 1036 parameter.
When using the object model, the language pack can have any file name; it does not need to be the same as the core solution file name.