How To Use Localization In ASP.NET Core - Day Ten

In the previous article of this series, we discussed web socket implementation in .NET Core application. Now, in this article, we will discuss how we can use globalization and localization in the ASP.NET Core application.

If you want to look at the previous articles of thse series, please visit the links given below.

• Day 1 - Jumpstart .NET Core
• Day 2 - Building .NET Core Basic Application With Visual Studio 2017
• Day 3 - Building .NET Core Basic Application With Static Files
• Day 4 - Read Configuration Files in .NET Core Application
• Day 5 - Create Shared Library or Packages in .Net Core Application
• Day 6 - Route Concept in .Net Core Application
• Day 7 - Route Concept With MVC Pattern
• Day 8 - URL Rewriting Middleware in Asp.Net Core
• Day 9 - Use Web Socket in Asp.Net Core

English is not the first language for a sizable population of the world; therefore building a website that just renders in English may not be a very wise idea. Imagine, with just some content localization, how much we can gain in terms of application reach. Internationalization is all about designing our application so that anyone in any region of the world can use the application in their native language. Internationalization involves Globalization and Localization. Globalization is the process of designing apps that support different cultures. Globalization adds support for input, display, and output of a defined set of language scripts that relate to specific geographic areas. Actually localization is one of the processes of adapting a globalized application, which we have already processed for localization to a particular country or culture/locale. Basically application localization involves the following key functionalities,

1. Make the application's content localizable
2. Provide localized resources for the languages and cultures which we support
3. Implement a strategy to select the language/culture for each request or each page

How Localization Implemented in Application

ASP.NET Core introduced two interfaces namely IStringLocalizer and IStringLocalizer<T> for implementing or developing localized applications. IStringLocalizer interface uses the ResourceManager and ResourceReader to provide user defined culture-specific resources at run time. This simple interface contains an indexer and an IEnumerable for returning localized strings to the application. IStringLocalizer doesn't require we to store the default language strings in a resource file. We can develop an application which developed for localization and not need to create resource files at the beginning of development. The code below shows how to wrap the string "Hello World" for localization.

using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Localization;
namespace Localization.StarterWeb.Controllers
{
   [Route("api/[controller]")]
   public class HelloController : Controller
   {
      private readonly IStringLocalizer<HelloController> _localizer;
      public HelloController(IStringLocalizer<HelloController> localizer)
      {
         _localizer = localizer;
      }
      [HttpGet]
      public string Get()
      {
         return _localizer["Hello World"];
      }
   }
}

In the above code sample, the IStringLocalizer<T> implementation comes by using Dependency Injection. If the localized value of "Hello World" is not found, then the indexer key is returned, that is, the string "Hello World". We can leave the default language message strings in the application and use them in the localizer, so that we can focus on developing the application. For this purpose, we can use the IHtmlLocalizer<T> implementation for resources that contain HTML. Actually IHtmlLocalizer HTML encodes arguments that are formatted in the resource string, but not the resource string. In the sample highlighted below, only the value of name parameter is HTML encoded.

using System;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Localization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Localization;
namespace Localization.StarterWeb.Controllers
{
   public class EmployeeController : Controller
   {
      private readonly IHtmlLocalizer<EmployeeController> _localizer;
      public EmployeeController(IHtmlLocalizer<EmployeeController> localizer)
      {
         _localizer = localizer;
      }
      public IActionResult Hello(string name)
      {
         ViewData["Message"] = _localizer["<b>Hello</b><i> {0}</i>", name];
         return View();
      }
      …
    }
}

Localization in the View Page in Application

If we want to implement localization in the view of our application, then we need to use IViewLocalizer interface. Basically IViewLocalizer interface service provides localized strings for a view. Actually ViewLocalizer class implements this interface and finds the resource location for the localized string from the view file path. The following code shows how to use the default implementation of IViewLocalizer :

@using Microsoft.AspNetCore.Mvc.Localization
@inject IViewLocalizer Localizer
@{
   ViewData["Title"] = Localizer["AboutMe"];
}
<h2>@ViewData["Title"].</h2>
<h3>@ViewData["Message"]</h3>
<p>@Localizer["Use this area to provide extra information."]</p>

The actual implementation of IViewLocalizer basically depends on view’s file name which means it finds the resource file based on the view's file name. That means there is no option to use a global shared resource file in the application for the view. ViewLocalizer implements the localizer using IHtmlLocalizer , so Razor doesn't need HTML encoder for the localized string. So we can parameterize resource strings and IViewLocalizer will encode the parameters, but not the resource string. Consider the following Razor markup:

@Localizer["<i>Hello</i> <b>{0}!</b>", UserManager.GetUserName(User)]

View localization requires the "Localization.AspNetCore.TagHelpers" NuGet package.

DataAnnotations localization for Validation Purpose

For implementing localization string to display DataAnnotations error messages, we can develop the same with the help of IStringLocalizer<T> . Using this option ResourcesPath = "Resources", the error messages in RegisterViewModel can be stored in the resource file.

public class RegisterViewModel
{
   [Required(ErrorMessage = "The Email field is required.")]
   [EmailAddress(ErrorMessage = "The Email field is not a valid e-mail address.")]
   [Display(Name = "Email")]
   public string Email { get; set; }
   [Required(ErrorMessage = "The Password field is required.")]
   [StringLength(8, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
   [DataType(DataType.Password)]
   [Display(Name = "Password")]
   public string Password { get; set; }
   [DataType(DataType.Password)]
   [Display(Name = "Confirm password")]
   [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
   public string ConfirmPassword { get; set; }
}

Working with Resource File

A resource file is a useful mechanism for separating localizable strings from code. Translated strings for the non-default language are isolated .resx resource files. For example, you might want to create German resource file named Welcome.de.resx containing translated strings. "de" is the language code for Spanish. To create this resource file in Visual Studio:

1. In Solution Explorer, right click on the folder which will contain the resource file > Add > New Item.
   
   
   
   
2. In the "Search installed templates" box, enter "resource" and name the file.
   
   
   
   
3. Enter the key value (native string) in the Name column and the translated string in the Value column.
   
   

You can read the next part here,

• Configuration API In ASP.NET Core - Day Eleven