Blazor Basics: Globalization in Blazor

In this article, we explore the globalization options for Blazor web application development.

In a previous article of this series, we learned about localization for Blazor web application development.

You can access the code used in this example on GitHub.

Introduction

Globalization describes a set of actions performed to make an application work in the context of a globalized world. Besides language selection, which is usually included in localization, globalization includes cultural differences such as number or date formatting.

For example, the U.S. uses a date format of MM/dd/yyyy (09/21/2023), while most of the world uses dd/MM/yyyy (21/09/2023). There are also differences in how the dates are formatted. In most of Europe, we use a decimal point instead of a slash as a date separator (21.09.2023).

Blazor uses the built-in .NET types from the System.Globalization namespace, such as the CultureInfo class and its CurrentCulture property.

In this article, we will mainly focus on how to format dates and numbers according to the culture settings of the .NET application.

Hint: To make it interesting, I will use the de-CH culture for the examples in this article. It’s my native culture, and I assume that most developers reading the article will have a different culture setting on their computer.

Formatting Dates

The .NET base class libraries provide methods for formatting date strings based on the current culture of a .NET application.

The following two methods produce a culture-dependent result:

@DateOfBirth.ToShortDateString()
@DateOfBirth.ToLongDateString()

The definition of the DateOfBirth property within the code block looks like this:

public DateTime DateOfBirth { get; set; } = new DateTime(1990, 9, 21);

The ToShortDateString method returns the date portion of the DateTime object in the following format: 21.09.1990. Remember, I’m using the de-CH culture for the examples in this article. Your result might look different, but the format will look like that.

The ToLongDateString method returns the name of the day followed by the day and the month in written letters before the year. In my case, it returns Freitag, 21. September 1990.

There are similar methods to output the time portion of the DateTime object as well.

We can also use the ToString method and provide custom format patterns. For example:

@DateOfBirth.ToString("MM-dd-yyyy")

The following shows the date formatting and the number formatting (see the following chapter) using the de-CH culture in action.

Formatting Numbers

The .NET base class libraries also provide methods for number formatting, including decimal numbers, currencies, percent, hexadecimal numbers and even scientific notations.

For number formatting, we use the ToString method and provide a format pattern. For example, we can express a monetary amount in the currency of the current culture like this:

@DecimalValue.ToString("c")

Or we can format a decimal number, including a thousand separator and decimal point.

@DecimalValue.ToString("n")

There are many more formatting patterns we can use. For more information, look at the .NET number format documentation.

Supported Form Field Types

Besides formatting dates and numbers to display in the browser, we also need to handle form fields in Blazor applications.

Blazor uses the invariant culture settings when using the following form input types:

• date
• number

For both input types, the parsing of the user input and the rendering of the field values are handled by the browser and its users’ settings.

Therefore, we do not need anything special to make those fields work with the current culture of the application’s users.

Not Supported Form Field Types

The following input types are currently not supported by Blazor because they lack official browser support in major browsers:

• datetime-local
• month
• week

For example, the input type week is currently only supported by Google Chrome and Microsoft Edge.

This might change in the future, and you can use caniuse.com for future reference.

Invariant Globalization

Sometimes the app can be without localization or globalization. In this case, we can configure the application to use the invariant culture, which is generally based on the en-US (United States, English) culture.

There are two main options on how to configure the app for invariant culture support:

We can set the following property in the project file (.csproj):

<PropertyGroup>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

Or we can configure it using the runtimeconfig.json file:

{
  "runtimeOptions": {
    "configProperties": {
      "System.Globalization.Invariant": true
    }
  }
}

A common use case for using invariant culture are internal tools used by people from the same region.

Hint: This is especially helpful when developing an application target for an international or English-only audience from a developer environment with another default culture.

Conclusion

Globalization is an important part of any web application that different people in different countries use. Language is the most important part of localization. And date and number formatting are the most important part of globalization.

Blazor uses built-in .NET functionality to implement globalization for web applications. We can adjust the culture settings for an entire application or use the user’s preference.

The built-in input types use the user’s browser settings when rendering and parsing dates and numbers.

User interface control libraries, such as Telerik UI for Blazor, often come with components that simplify dealing with globalization and are more convenient than what basic Blazor or the default browser behavior provides.

If you want to learn more about Blazor development, you can watch my free Blazor Crash Course on YouTube. And stay tuned to the Telerik blog for more Blazor Basics.