This article focuses on adapting ASP.NET Core for RTL languages such as Arabic. The goal is to keep text direction, layout flow, and localization settings aligned so you can resolve three common issues: broken right alignment, mixed-up character order, and incomplete page localization. Keywords: ASP.NET Core, RTL, Arabic.
Technical Specifications Snapshot
| Parameter | Description |
|---|---|
| Tech stack | ASP.NET Core, Razor, CSS |
| Target languages | Arabic, Hebrew, and other RTL languages |
| Core protocols/standards | HTML dir, Unicode Bidirectional Algorithm, RequestLocalization |
| Core dependencies | Microsoft.AspNetCore.Localization, System.Globalization |
| Code format | HTML + CSS + C# configuration |
| Original engagement | The original article shows 106 views, 1 like, and 1 favorite |
AI Visual Insight: This image serves as the article header visual. It emphasizes multilingual UI adaptation in ASP.NET Core and helps orient the reader toward RTL layout and internationalization concerns rather than specific code structure.
AI Visual Insight: This animated image works as a visual demo of switching layouts from LTR to RTL. The focus is typically on text flow, mirrored component order, and changes in the page reading direction.
RTL support in ASP.NET Core is not just right alignment
Many projects treat Arabic support as nothing more than text-align: right. That only moves text visually to the right. It does not change the browser’s reading order, component flow, or bidirectional text handling rules.
A working solution has three layers: declare dir="rtl" in HTML, handle direction and unicode-bidi in CSS, and use server-side culture configuration to drive view and resource selection.
Pitfall 1 is applying right alignment without declaring document direction
If an element does not declare dir, the browser still parses the document flow as LTR. As a result, the text may appear right-aligned, while punctuation, lists, input cursor behavior, and block layout can still be incorrect.
<!-- Incorrect: aligns text to the right but does not declare reading direction -->
<div style="text-align: right;">
كيف حالك؟
</div>
<!-- Correct: explicitly declares RTL direction -->
<div dir="rtl" style="text-align: right;">
كيف حالك؟
</div>This example shows that dir controls reading direction, while text-align controls only visual alignment.
Pitfall 2 is setting only direction while ignoring unicode-bidi
In mixed-content scenarios, using only direction: rtl can still produce broken character order, especially when the content includes numbers, English text, parentheses, or punctuation.
/* Incorrect: changes direction only, but bidirectional text can still break */
.rtl-broken {
direction: rtl;
}
/* Correct: handles Unicode bidirectional override as well */
.rtl-fixed {
direction: rtl; /* Set right-to-left layout direction */
unicode-bidi: bidi-override; /* Force characters to follow RTL rules */
}This style block fixes display order issues when Arabic text is mixed with English numbers.
ASP.NET Core must use culture configuration to drive multilingual behavior
Fixing the frontend styles does not mean the system is fully internationalized. Dates, numbers, validation messages, and resource loading still depend on ASP.NET Core culture configuration.
If you do not configure RequestLocalizationOptions, the application usually falls back to the default culture, which makes UI text, formatted output, and language direction detection unreliable.
A standard configuration should declare both supported cultures and UI cultures
using System.Globalization;
using Microsoft.AspNetCore.Localization;
public void ConfigureServices(IServiceCollection services)
{
services.AddControllersWithViews()
.AddViewLocalization() // Enable view localization
.AddDataAnnotationsLocalization(); // Enable validation message localization
services.Configure
<RequestLocalizationOptions>(options =>
{
var supportedCultures = new[]
{
new CultureInfo("en-US"),
new CultureInfo("ar-SA"), // Arabic culture
new CultureInfo("he-IL") // Hebrew culture
};
options.DefaultRequestCulture = new RequestCulture("en-US"); // Default language
options.SupportedCultures = supportedCultures;
options.SupportedUICultures = supportedCultures;
});
}This configuration allows ASP.NET Core to correctly recognize RTL languages and their localized resources.
Dynamic direction switching is the maintainable approach for production
Hardcoding dir="rtl" only works for single-language pages. For multilingual sites, a better approach is to render dir dynamically in the layout based on the current culture so LTR and RTL languages can share one template.
Compute page direction dynamically in a Razor layout
@using Microsoft.AspNetCore.Localization
@{
var cultureFeature = Context.Features.Get
<IRequestCultureFeature>();
var lang = cultureFeature?.RequestCulture.Culture.TwoLetterISOLanguageName;
var isRtl = lang == "ar" || lang == "he"; // Use RTL for Arabic or Hebrew
}
<!DOCTYPE html>
<html dir="@(isRtl ? "rtl" : "ltr")">
<head>
<meta charset="utf-8" />
<title>@ViewData["Title"]</title>
</head>
<body>
@RenderBody()
</body>
</html>This layout code switches the document direction automatically based on the current language and reduces manual mistakes.
CSS should use attribute selectors for targeted overrides
[dir="rtl"] {
direction: rtl; /* Switch the overall document flow to RTL */
}
[dir="rtl"] .arabic-text {
unicode-bidi: bidi-override; /* Fix bidirectional character order */
text-align: right; /* Preserve Arabic visual alignment */
font-family: "Segoe UI", Tahoma, sans-serif;
}The value of this CSS pattern is that it scopes RTL rules to the intended pages and avoids polluting LTR page styles.
A minimal fix path can resolve most garbled text and layout issues
First, check whether the root node or local container declares dir. Second, verify that Arabic sections include both direction and unicode-bidi. Third, confirm that the server has configured RequestLocalization.
If issues still remain, inspect mixed-content components first, such as forms, tables, label text next to badges or logos, order information with numbers, and messages that include parentheses or percentages. These areas are the most likely to trigger bidirectional text bugs.
Common misconceptions all point to the same root cause
Developers often blame RTL issues on fonts, browsers, or data encoding. In reality, most failures happen because semantic direction, visual direction, and culture settings are not aligned. If you fix only one layer, parts of the UI may look correct while the overall system remains unstable.
That is why the best practice is not to keep adding patch styles. Instead, establish a consistent direction strategy: let Culture determine dir, let dir drive CSS, and let CSS handle local mixed-text adjustments.
FAQ
1. Why does an Arabic page still look wrong after I set text-align: right?
Because text-align affects alignment only. It does not affect document reading direction. An RTL page must declare dir="rtl" first, or the browser will still interpret the layout as LTR.
2. Should I use direction: rtl or dir="rtl"?
They are not interchangeable. dir is a semantic declaration that defines document direction, while direction is a style-level override suited for local fixes. In production, you usually need both.
3. What is the key configuration for RTL support in ASP.NET Core?
The key is RequestLocalizationOptions. It determines the current Culture, resource selection, date and number formatting, and the logic you use in Razor when rendering dir dynamically.
AI Readability Summary
This article breaks down the core implementation details of RTL support in ASP.NET Core for multilingual applications. It focuses on three common pitfalls in Arabic scenarios: treating text-align as direction control, skipping unicode-bidi, and ignoring RequestLocalization culture configuration. It also provides practical Razor, CSS, and localization fixes you can apply in production.