The SharePoint Service Application Starter Kit is built with localization support for all of its administration components.

Resources used in the custom administration pages of the Starter Kit are deployed to the App_GlobalResources directory for the Central Administration web site when the Service solution WSP is deployed. This is done by a bit of code in the farm-scoped feature receiver:

    // Ensure that the resource files in CONFIG\ADMINRESOURCES are copied to App_GlobalResources.
    // If you have Central Administration on another server, you will need to run 
    // stsadm -o copyappbincontent or Install-SPApplicationContent on that server directly, 
    // as the call below only runs on the server that the WSP is deployed on.
catch (Exception ex)
     SPDiagnosticsService.Local.WriteTrace(0, new SPDiagnosticsCategory("Service Applications", TraceSeverity.Unexpected, EventSeverity.Error), TraceSeverity.Unexpected, ex.Message, ex.StackTrace);

Note: ApplyApplicationContentToLocalServer() will only deploy the resource files to App_GlobalResources on the local server where the WSP was deployed to (the shortcomings of this method have been well documented). If you are deploying the WSP on a server that does not have Central Administration on it, or have Central Administration running on other servers, then you will need to run the following PowerShell command on the Central Administration server(s):


Localization of Administration Pages

Each administration page deployed by the solution has all of its strings in resource files located in the CONFIG\ADMINRESOURCES mapped folder.

AdminResources files

In this folder, you will find two resource files by default, a language neutral resource file, and a culture specific resource file for the en-US culture.

if you don’t plan to localize your service application to languages other than English, it is still a good practice to have both the language neutral and culture specific resource files. If you only have the language neutral resource file, you may see Exceptions in the ULS logs as SharePoint tries to load the culture specific file first and cannot find it. No sense in having SharePoint throw and log exceptions when the easy fix is to just add a culture specific resource file.

The localization of administration pages uses the Resource expression syntax in the .aspx files (<%$ Resources:key,name %>), and when used in code-behind, the HttpContext.GetGlobalResourceObject method.

Localization Without an HttpContext

Some localizable pieces of a service application can be accessed without an HttpContext, for example the TypeName of a ServiceApplication when accessed via PowerShell. For these pieces, HttpContext.GetGlobalResourceObject will not work, and instead SPUtility.GetLocalizedString will need to be used instead. This also means that additional resource files are needed in the RESOURCES mapped folder (since SPUtility.GetLocalizedString only works with resource files deployed to the RESOURCES hive). This is why you’ll see a couple of additional resource files in the RESOURCES mapped folder:

Resources mapped folder

Feature Localization

The Service project of the Starter Kit contains a single farm-scoped feature. This feature also supports localization via resource files in the Feature folder. These control elements such as the Feature Title, Description, and the Custom Action group name, title, and description.

Feature localization

Last edited Feb 19, 2013 at 6:02 PM by adamtoth, version 2


No comments yet.