SharePoint v3 Localized Resources
For localization in SharePoint to work, a particular site must be created specifying the designated language. In order to create a site for a particular language, you must first install the language pack for that language. Therefore, begin your multilingual project by installing the language packs for each of your targeted languages.
Localized resources in SharePoint v3 utilize the localization features of the .Net Framework 2.0 for displaying user interface labels appropriate for a particular user’s culture and locale.
Information on the .Net Framework 2.0 localization features can be found at:
https://msdn2.microsoft.com/en-us/library/c6zyy3s9.aspx
Info specifically on Resource files can be found at:
https://msdn2.microsoft.com/en-us/library/f45fce5x(VS.80).aspx
SharePoint v3 implements Resource (.resx) files in different ways and locations depending upon the particular type of SharePoint functionality that is being localized:
1. Site and List Definitions can have resources located in the 12\Resources folder
2. Features can have resources located in the ..\12\Features\<Feature Name>\Resources folder
3. Web applications and custom pages can have resources that are located in the ..\12\CONFIG\Resources folder and are copied at Web App creation time to the App_GlobalResources folder located under each SharePoint Web Application
4. Web parts and other applications:
a. can have their resources compiled into their own set of resource dlls which can then be located either in the GAC, or in a sub-directory of the bin folder
b. can have their resources located in their assembly’s wpresources folder which can be accessed through the ClassResourcePath method
This blog will describe the implementation of resource files in each of these locations.
Site and List Definition Resource Files
Sites and List Definitions have resource files located in the Resources folder located in the 12 hive:
..\12\Resources
Each language installed on the server will have its own resource file named as follows:
<filename>.<culture-locale>.resx
The keys in these files are referenced from the ONET.xml files for a Site Definition by referencing the file names as follows:
$Resources:<filename>, <resource-key>
e.g.: <DocumentTemplate Path=”STS” Name=”” DisplayName=”$Resources:core,doctemp_None;” Type=”100” Default=”FALSE” Description=”$Resources:core,doctemp_None_Desc;” />
If you go to the 12\Resources\core.resx and open this file in Notepad, and then do a find on “doctemp_None” or “doctemp_None_Desc” you can see the default values that will be displayed.
You can then go to the core.resx file for a particular culture and locale and search for these same keys to find what will be displayed based on the browser’s Language Preference setting.
Developer’s can deploy their own resx files to the 12\Resources folder and reference them from a custom site definition using the same syntax. But note that these resources are copied into the database for a particular site when that site is created. Changes made to resources in the 12\Resources folder will not affect sites that have been previously created, only new sites.
Feature Resource Files
Each feature located in the ..\12\Features folder can have a Resource sub-folder which contains a .resx file for each targeted culture-locale named as follows:
resources.<language-LOCALE>.resx
e.g.: resources.en-US.resx
For instance take a look at the ..\12\FEATURES\SignatureWorkflow\Resources folder.
These resources can be referenced from a feature such as a Workflow using a string expression in much the same way as the strings for Site Definitions except that you do not include the file name. For instance:
$Resources:<resource-key>
The Workflow will then display the string that is appropriate for the browser’s Language Preference if such a resource file exists for that culture-locale. If not, then the resource from the default culture-locale file will be returned.
Web Application Resource Files
The Web Application Resources are located in the ..\12\Config\Resources folder. When you create a new Web Application these resources are copied to the App_GlobalResources folder located at:
C:\inetpub\wwwroot\wss\VirtualDirectores\[port]\App_GlobalResources
Like the resource files deployed for a Feature or a Site Definition, these files use the .Net Framework naming convention for localized resources:
<filename>.<culture-locale>.resx
The culture-locale of the user’s Language Preference will be automatically used if it exists, otherwise the values in the default resource file will be used.
If you were to create custom publishing pages for SharePoint, you can add your own Resource files to the 12\Config\Resources folder and these resources will then be copied to the App_GlobalResources folder along with the out-of-the-box resource files every time a new Web Application is created.
These resources are automatically compiled in the Resources namespace and are available to any aspx pages. You can also add your own Resource files directly to the App_GlobalResources folder on any existing web application, and your custom pages can access them using the standard .Net 2.0 syntax.
Declarative: <%$ Resources:<filename>,<resource-key> %>
e.g. from the global navigation in the default master page:
SkipLinkText=”<%$Resources:cms,masterpages_skiplinktext%>
Strongly typed: Resources.<filename>.<resource-key>
e.g.: MyLabel.Text == Resources.MyResourceFile.Description;
Web Part Embedded Resource Files
To use localized resources in a Web Part class you add your resource files directly to the Web Part project and these resources are then compiled into the dll that is then deployed to SharePoint.
A code sample along with a sample project are located at the end of the Building Multilingual Solutions white paper:
The _wpresources Folder
The wpresources (Web Part Resources) folder is created when a solution deploys a web part assembly. The wpresources folder is created in two different places depending on whether the web part assembly is deployed to the GAC or to a web application’s bin folder.
If the assembly is deployed to the GAC, then the folder structure containing the web parts resources will be in the virtual _wpresources folder and the folders will be named as follows:
<AssemblyName>/<versionNumber>_<PublicKeyToken>/<resources>
This folder is physically located in this global location:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\wpresources
If the web part assembly is deployed to the Web Application’s bin folder, then the web part’s resources will be in the physical wpresources folder (no underscore) in a sub-folder named after the AssemblyName.
In either case, the folder name can be retrieved from the web part code by using the ClassResourcePath property on the web part – if it is a SharePoint native web part (inherits from Microsoft.SharePoint.WebPartPages.WebPart):
string resoucePath = this.ClassResourcePath;
SharePoint.WebPartPages.WebPart also has the ReplaceTokens() method that you can use to replace the token “_WPR_” with the wpresource path at runtime.
If you are building an Asp.net web part (inherits from System.Web.UI.WebControls.WebParts.WebPart) then you have to do a little more work:
SPWeb currentWeb = SPControl.GetContextWeb(Context);
Type currentType = BaseWebPart.GetType();
string resourcePath = SPWebPartManager.GetClassResourcePath(currentWeb, currentType);
You can deploy many kinds of resources to the wpresources folder: images, xml files, css files, and javascript files.
Resx files will not be compiled in the wpresource folder, but you can load them via your own application logic using the XmlDocument class.
Comments
Anonymous
January 10, 2009
הרבה פעמים אני שומע תלונות על הגיור של מוצרי מיקרוסופט שונים.. הכוונה היא לתרגום לעברית, ובואו נהיה כניםAnonymous
January 10, 2009
הרבה פעמים אני שומע תלונות על הגיור של מוצרי מיקרוסופט שונים.. הכוונה היא לתרגום לעברית, ובואו נהיה כנים