To serve people from any culture who use any language, most web applications nowadays have localization support.
Localization is a process that translates content for a specific culture. It can be used to serve a multilingual, worldwide audience and achieve better market reach.
In this blog, we are going to learn about how to use localization in an ASP.NET Core web API with resource (.resx) files.
The following are the prerequisites to integrate localization in an ASP.NET Core web API:
Create an ASP.NET Core REST API application
Follow these steps to create an ASP.NET Core REST API application in Visual Studio 2019:
Step 1: In Visual Studio 2019 (v16.4 or higher), go to File > New, and then select Project.
Step 2: Choose Create a new project.
Step 3: Select the ASP.NET Core Web Application template.
Step 4: Enter a Project name, and then click Create. The project template dialog will be displayed.
Step 5: Select the .NET Core, ASP.NET Core 3.1, API template (highlighted in the following screenshot).
Step 1: Register the necessary services for the localization process in the ConfigureServices method in the Startup.cs class: AddLocalization() and Configure<RequestLocalizationOptions>().
Step 2: Add the request localization middleware in the Configure method from the Startup.cs class.
Strategy for resource files
Resource files contain localizable strings based on the culture and the controller. We can maintain the resource files in two ways:
- Single culture resource file per controller.
- Single culture resource file for all controllers.
Single culture resource file per controller
In this method, you need to maintain a separate resource file for each culture and each controller in any file structure (i.e. dot or path) as mentioned in this documentation.
If you have two controllers and support for two cultures, then you need to maintain the resource files in the structure shown in the following screenshot.
Here, we have support for the US English and French languages.
Single culture resource file for all controllers
In this method, you should maintain a single resource file based on culture for all the controllers.
To do this, you need to create an empty class with the same name as the resource file. The namespace of this empty class will be used to find the resource manager and resolve IStringLocalizer<T> abstractions.
Despite of the number of controllers, you should only maintain one resource file for every culture supported.
Refer to the following screenshot to see this approach in practice.
How to use localized values in controllers
ASP.NET Core provides built-in support for IStringLocalizer and IStringLocalizer<T> abstractions. These abstractions are used to get the values based on the name of the string resource passed from the respective culture resource file (e.g., HomeController.en-US.resx).
To use localized values in the controllers, you need to inject the IStringLocalizer<T> abstraction based on the resource file structure mapped as shown in the following table.
|Controller Name||Dependency Injection of IStringLocalizer<T>||Resource File Structure|
|For all controllers||IStringLocalizer<Resource>||Resource.en-US.resx|
Based on injecting the IStringLocalizer<T> abstraction, the string localizer will map the resource file through the value passed to the shared resource (T). This string localizer will then return the mapped value from the resource file based on the name of the string resource you have passed.
You can find a copy of these samples in the following GitHub locations:
In this blog, we learned about implementing localization in an ASP .NET Core web API application. This feature helps to serve multilingual people from diverse cultures.
Syncfusion provides over 70 high-performance, lightweight, modular, and responsive ASP.NET Core UI controls such as DataGrid, Charts, and Scheduler, and all of them have built-in support for localization. You can use them to improve your application development.
Please share your feedback on this blog in the comments section. You can also contact us through our support forum, Direct-Trac, or feedback portal. We are waiting to hear from you!
can we have comman resource files for all controllers ?
Hi ABHIJEET SHARMA,
Yes we can have a single common resource file for all controllers per culture based. You can refer the below sample for your reference.
Localization Sample: https://github.com/RaguMP/Samples/tree/master/LocalizationSampleSingleResxFile
Ragunaathan M P
Hello. I am wondering if I can move single resource culture file to any library project? Are does need to be part of the project where Controllers are present?
Yes, we can maintain resource files in any library project and can refer in API project. But we need to maintain an empty class with the same name as the resource file where the namespace of this empty class will be used to find the resource manager, and resolve IStringLocalizer abstractions as explained in this blog.
Ragunaathan M P
can you provide an example? I am struggling to make it work. I am using the resource file on another project
Kindly find the below sample which I have prepared by referring resource files from another project.
Localization Sample: https://github.com/RaguMP/Samples/tree/master/LocalizationSampleSingleResxFileSeparateProj
Ragunaathan M P
In the same approach can i externalize my resource files and put in CDN, so that when i add new language resource files there is no need to rebuild and deploy the application? also in that case can i load the resx file using some options like IConfiguration to map to resource manager and use it?
In ASP.NET Core, localization resource files (i.e. “.resx”) will be generated with extension “.dll” based on each culture language we maintain, while building the project with “AddLocalization()” services which we add in service collection in Startup class. Hence resource manager can not be configured using “IConfiguration” and so it is better to maintain the resource files locally.
However we need to deploy our application whenever we plan to release new features on regular basis and include the localization changes along with the release.
Ragunaathan M P
Comments are closed.