Rediger

Localization in the SharePoint Add-in model

Important

SharePoint Add-ins reached end of life in SharePoint Online on April 2, 2026. Both SharePoint-hosted and provider-hosted Add-ins are retired and no longer work in SharePoint Online, including government clouds. Add-in development, deployment, and usage guidance is retained for historical reference and for applicable SharePoint Server scenarios, not for new SharePoint Online solutions.

SharePoint Server Add-ins deployed through an on-premises app catalog are not retired by this change. Acquiring SharePoint Add-ins from the public marketplace ended on April 2, 2026 for SharePoint Server.

This retirement does not retire SharePoint REST APIs, CSOM, JSOM, or SharePoint Framework (SPFx). For SharePoint Online, use SPFx for user interface extensions and Microsoft Entra ID for authentication to external applications. See the retirement announcement and Add-in migration guidance.

The approach you take to implement localization for Add-ins is different in the new SharePoint Add-in model than it was with Full Trust Code. In a typical Full Trust Code (FTC) / Farm Solution scenario, localization for custom components such as web parts, User Controls, and Web Controls was implemented with a combination of resource files, .Net managed code, properties, and declarative code. All the artifacts were packaged in features deployed via SharePoint Solutions.

In an SharePoint Add-in model scenario, you use JavaScript or the localization capabilities associated with the web technology you build your Add-ins with to implement localization. Depending on the localized resource, you might also use classic resources files, for example when you need to localize elements deployed to add-in web using feature framework elements in the add-in definition.

High-level guidelines

As a rule of a thumb, we would like to provide the following high-level guidelines for implementing localization.

  • You must install the appropriate Language Packs in your SharePoint on-premises and Office 365 environments to enable users to create websites in a specific language and culture.
  • Using JavaScript to implement localization in SharePoint Add-ins is also an approach you may use to localize content in Script Editor Add-in Parts.

Localization scenarios

There are two distinct scenarios where you may need to implement localization for an Add-in.

  • SharePoint-hosted Add-ins
  • Provider-hosted Add-ins

Add-in web components or assets

In this scenario localization is applied to the Add-in via JavaScript.

  • SharePoint-hosted Add-ins do not have access to server-based resource files in the SharePoint servers, but you have access on the feature element *.resx files.
  • The approach to localize a SharePoint-hosted Add-in and an Office Add-in are very similar because they both use JavaScript.

When is it a good fit?

When you are creating a SharePoint-hosted Add-in, using JavaScript is your best fit because you can implement localization with JavaScript and deploy all of the JavaScript files necessary to support localization with the SharePoint-hosted Add-in. You can also take advantage of this approach if your provider hosted add-in contains also specific add-in web.

Getting Started

Scenario 2 in the Core.JavaScriptCustomization (O365 PnP Sample)) demonstrates how to use JavaScript to localize the text in an Add-in as well as attributes associated with the HTML elements in the Add-in.

The Localize SharePoint Add-ins also demonstrates how to use JavaScript to localize assets in the add-in web.

Remote components

In this scenario localization is applied to the Add-in via the localization technologies associated with the web technology hosting the Add-in.

  • When ASP.NET is used to implement the Add-in, resource files and JavaScript files are used to localize it.
  • When another technology such as PHP, Python, or Ruby are used to implement the Add-in the localization capabilities associated with those platforms is used.

When is it a good fit?

When you are creating a Provider-hosted Add-in, using the localization technology that comes with the web hosting platform is the best fit because you are building the Add-in in a way that does not introduce custom code or additional complexity.

Getting Started

The following articles describes how to localize Provider-hosted Add-ins with resource files and JavaScript.

PnP samples

Applies to

  • Office 365 Multi Tenant (MT)
  • Office 365 Dedicated (D)
  • SharePoint 2013 on-premises
  • Sidst opdateret den