Internationalization, or i18n, designs software to support multiple languages, cultures, regional conventions, dates, time zones, measurements, and sorting rules without major code changes. In .NET, it is a three-step process: globalization, a localizability review, and localization. section 12.0 section 12.5
Apply internationalization as a production process:
- Globalize the application by separating user-facing concerns from assumptions about one language, region, or convention. section 12.0
- Perform a localizability review to identify code and content that must adapt for other cultures. section 12.0 section 12.5
- Localize the application with culture-specific content and behavior; .NET localization files become embedded resources and satellite assemblies. section 12.6
- Keep timestamps in UTC for internal handling and present local time only when users need it. section 12.1
- Use ASP.NET Core culture providers to obtain culture codes from query strings, cookies, or request headers; the current culture follows asynchronous tasks. section 12.6
World-ready air-conditioner API
An ASP.NET Core API originally assumes English-speaking customers in California. Its response exposes sensor descriptions, decimal measurements, and a UTC timestamp such as 2022-10-10T00:05:00.000Z. Internationalization challenges those assumptions before the service reaches customers in other regions. section 12.1
Listing 12.1 Example response from the air conditioner's API
{
"UnitId": 1, #1
"Site": "TIJ1",
"Timestamp": "2022-10-10T00:05:00.000Z", #2
"Measurements": {
[
"SensorName": "ExhaustAirTemp", #3
"Value": 15.2,
"Description": "Exhaust Air Temperature" #4
],
[
"SensorName": "CoolantTemp",
"Value": 3.4, #5
"Description": "Coolant Temperature"
],
[
"SensorName": "OutsideAirTemp",
"Value": 24.1,
"Description": "Outside Air Temperature"
]
}
}
Inspect the sample API response to see how timestamps, measurements, sensor names, and descriptions become user-visible internationalization concerns. section 12.1
