Co-authored by

What Makes Building an Arabic Power BI Dashboard Different?

Quick answer: Arabic Power BI dashboards require right-to-left text rendering, mirrored visual layouts, Hijri calendar support, and bilingual label management — none of which Power BI handles natively out of the box, particularly in Power BI Desktop.

If you have ever tried to build an Arabic Power BI dashboard for a GCC organization, you already know the gap between what Microsoft officially supports and what your stakeholders actually need. The Power BI Service supports Arabic as a UI language. Power BI Desktop does not. Desktop explicitly excludes right-to-left languages, and as Microsoft's own documentation states, "the layout of visuals doesn't change if you're using a right-to-left language." That single sentence defines the core challenge.

In practice, this means every Arabic Power BI dashboard is a custom engineering effort. You are working against the default assumptions of the tool — left-to-right text flow, Gregorian calendars, Latin script font metrics — and building workarounds for each. This guide walks through the specific techniques that work, the ones that do not, and the trade-offs involved in each decision. If you are deploying Power BI for a GCC government agency, our GCC government analytics guide covers the broader compliance and deployment context.

How Does RTL Support Differ Between Power BI Desktop and the Power BI Service?

Quick answer: Power BI Desktop does not support right-to-left languages at all — the UI and canvas are LTR only. The Power BI Service supports Arabic as a UI language and renders RTL text in some visuals, but canvas layout mirroring and full RTL visual rendering remain incomplete.

The distinction matters because most report development happens in Desktop. Here is the current state as of early 2026:

The practical impact: you design reports in a left-to-right environment, manually position visuals in a right-to-left arrangement, test Arabic text rendering by publishing to the Service, and iterate. There is no canvas-level RTL toggle in any Power BI surface. Every mirrored layout is manual — you place the navigation and primary visual on the right side of the canvas, secondary content on the left, and position text boxes with explicit right-alignment.

For embedded scenarios, you can pass locale settings like ar-SA or ar-AE through the JavaScript API's localeSettings object. This triggers metadata translations and locale-aware date/number formatting, but it does not mirror the visual layout.

How Do You Set Up Translations Builder for Arabic Localization?

Quick answer: Translations Builder is a free external tool for Power BI Desktop that manages metadata translations, report label translations, and localized labels — enabling Arabic column names, measure labels, and UI text without maintaining separate PBIX files.

Microsoft identifies three types of translation for multilingual Power BI reports:

1. Metadata translations — Localized names for tables, columns, measures, hierarchies, and hierarchy levels. When a user loads the report with an Arabic locale, Power BI displays the Arabic names instead of the English defaults.
2. Report label translations — Localized text for report titles, section headings, button captions, and other UI elements that are not tied to the semantic model. Translations Builder handles these through a hidden Localized Labels table with DAX measures.
3. Data translations — Translated values within the data itself (e.g., product names in Arabic). These require field parameters to switch between language-specific columns.

Setting Up Arabic Translations

Install Translations Builder from the GitHub repository. It appears in the External Tools ribbon in Power BI Desktop and connects to your model via the Tabular Object Model (TOM) API.

To add Arabic support:

1. Open your PBIX file in Desktop, then launch Translations Builder from the External Tools ribbon.
2. Add ar-SA (Saudi Arabia) or ar-AE (UAE) as a secondary language.
3. In the translations grid, enter Arabic translations for each table, column, and measure name. You can also use Translations Builder's machine translation feature as a starting point, then review with a native speaker.
4. For report labels, use Generate Translated Tables > Create Localized Labels Table, then add labels for report titles, navigation buttons, and section headings.
5. Generate the Translated Localized Labels table, which creates DAX measures using USERCULTURE() and SWITCH() to return the correct label based on the user's locale.

The generated DAX for a report title label looks like this:

Report Title Label =
SWITCH(
    USERCULTURE(),
    "ar-SA", "تقرير المبيعات",
    "ar-AE", "تقرير المبيعات",
    "Sales Report"
)

When the report loads in the Power BI Service under an Arabic locale, all metadata labels and report text switch automatically. No bookmark toggling, no duplicate pages.

Important limitation: USERCULTURE() only works reliably in measures called from within the model. It does not return the correct locale in live-connect report measures or queries from outside the model. For GCC compliance deployments, verify that your locale detection works correctly in your specific hosting configuration.

Which Fonts Work Best for Arabic Text in Power BI?

Quick answer: Sakkal Majalla is the strongest general-purpose Arabic font available in Power BI for headlines and body text. Segoe UI provides reliable Arabic script support for UI elements and smaller text. Both are pre-installed on Windows and do not require custom font deployment.

Font selection matters more for Arabic dashboards than English ones because Arabic script has connected letterforms, diacritics, and variable glyph widths that many fonts handle poorly at small sizes. Power BI only renders fonts installed on the machine running the report (Desktop) or the server rendering it (Service), so you are limited to system fonts unless your organization deploys custom fonts to the Power BI Service via Fabric capacity.

Practical recommendation: Use Sakkal Majalla as your primary font for Arabic text in cards, titles, and tables. Use Segoe UI as the fallback for bilingual elements where English and Arabic must coexist in the same text run. In your Power BI theme JSON, set font families with Arabic fonts first in the stack:

{
  "visualStyles": {
    "*": {
      "*": {
        "general": [{
          "fontFamily": "Sakkal Majalla, Segoe UI, sans-serif"
        }]
      }
    }
  }
}

Avoid using fonts that lack full Arabic Unicode support — you will see broken ligatures, disconnected letters, or missing glyphs. Test every visual at actual dashboard zoom levels, not just in the Desktop editor.

How Do You Build a Hijri Calendar Date Table in Power BI?

Quick answer: The most reliable approach is generating Hijri dates in Power Query using the ar-SA culture code with Date.ToText, which invokes the Umm al-Qura calendar — then splitting the result into separate year, month, and day columns for use in DAX time intelligence.

DAX does not have native Hijri calendar functions. The CALENDAR and CALENDARAUTO functions generate Gregorian dates only, and standard time intelligence functions like SAMEPERIODLASTYEAR and TOTALYTD assume a Gregorian structure. Building a Hijri date table requires a different approach.

Power Query Approach (Recommended)

Use Date.ToText with the ar-SA culture to extract Hijri components from Gregorian dates:

let
    StartDate = #date(2020, 1, 1),
    EndDate = #date(2030, 12, 31),
    DateList = List.Dates(StartDate, Duration.Days(EndDate - StartDate) + 1, #duration(1, 0, 0, 0)),
    DateTable = Table.FromList(DateList, Splitter.SplitByNothing(), {"Date"}),
    ChangeType = Table.TransformColumnTypes(DateTable, {{"Date", type date}}),
    AddHijriYear = Table.AddColumn(ChangeType, "HijriYear", each Number.From(Date.ToText([Date], "yyyy", "ar-SA")), Int64.Type),
    AddHijriMonth = Table.AddColumn(AddHijriYear, "HijriMonth", each Number.From(Date.ToText([Date], "M", "ar-SA")), Int64.Type),
    AddHijriDay = Table.AddColumn(AddHijriMonth, "HijriDay", each Number.From(Date.ToText([Date], "d", "ar-SA")), Int64.Type),
    AddHijriMonthName = Table.AddColumn(AddHijriDay, "HijriMonthName", each Date.ToText([Date], "MMMM", "ar-SA"), type text)
in
    AddHijriMonthName

This generates a table with both Gregorian and Hijri columns. The ar-SA culture triggers the Umm al-Qura calendar, which is the official calendar in Saudi Arabia and the most widely used Hijri variant in the GCC.

Hijri DAX Measures

Once the date table exists, write DAX measures that reference the Hijri columns directly. Standard time intelligence will not work — you need explicit filtering with CALCULATE:

Sales Hijri YTD =
CALCULATE(
    [Total Sales],
    FILTER(
        ALL('DateTable'),
        'DateTable'[HijriYear] = MAX('DateTable'[HijriYear])
            && 'DateTable'[HijriMonth] <= MAX('DateTable'[HijriMonth])
    )
)

Sales Previous Hijri Year =
CALCULATE(
    [Total Sales],
    FILTER(
        ALL('DateTable'),
        'DateTable'[HijriYear] = MAX('DateTable'[HijriYear]) - 1
    )
)

The Hijri month names (Muharram, Safar, Rabi al-Awwal, Rabi al-Thani, Jumada al-Ula, Jumada al-Thani, Rajab, Shaban, Ramadan, Shawwal, Dhu al-Qadah, Dhu al-Hijjah) are generated automatically by the MMMM format in the Power Query step above. For a comprehensive reference on DAX functions used in these patterns, see our DAX functions reference guide.

Key caveat: The Hijri calendar is lunar — 354 or 355 days per year. Year-over-year comparisons do not align with Gregorian periods. A Hijri month drifts roughly 11 days earlier each Gregorian year. Your stakeholders need to understand this when comparing Hijri YTD figures against Gregorian fiscal targets.

How Do You Build a Bilingual Language Toggle in Power BI?

Quick answer: The cleanest approach combines Translations Builder for metadata and report labels with field parameters for data translations, using the language URL parameter or a bookmark-based slicer to let users switch between English and Arabic on demand.

There are three viable patterns for bilingual English-Arabic dashboards. Each has distinct trade-offs:

Pattern 1: URL-Based Language Switching (Recommended for Service and Embedded)

Append ?language=ar-SA to the report URL in the Power BI Service. This triggers all metadata translations and USERCULTURE()-based label measures automatically. Users in Arabic-speaking regions get Arabic by default based on their browser Accept-Language header.

No user interaction required — the report language follows the user's locale. For embedded reports, pass the locale through the JavaScript API:

let config = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: accessToken,
    settings: {
        localeSettings: {
            language: "ar-SA",
            formatLocale: "ar-SA"
        }
    }
};

Pattern 2: Bookmark-Based Language Slicer

Create a Languages table with rows for each supported culture code. Add a slicer on the report page. Create bookmarks that filter the Languages table to a specific culture — one bookmark for ar-SA, one for en-US. Wire buttons or a dropdown to the bookmarks. This approach is documented in Microsoft's multi-language report loading guide.

When creating the bookmarks, disable Display and Current Page behaviors — enable only Data. This prevents the bookmark from overriding other visual states.

Pattern 3: Field Parameters for Data Translation

When your data itself needs to appear in both languages — product names, category labels, region names — field parameters provide the mechanism. Create translated columns in your source data (e.g., ProductNameEN, ProductNameAR), then define a field parameter:

Product Name =  {
    ("Product Name", NAMEOF('Products'[ProductNameEN]), 0, "en-US"),
    ("اسم المنتج", NAMEOF('Products'[ProductNameAR]), 1, "ar-SA")
}

Link the field parameter to the Languages table via a relationship on the culture code. When the user selects Arabic, all visuals using this parameter automatically display Arabic product names.

Practical advice for GCC enterprises: Most bilingual dashboard projects combine all three patterns. URL-based switching handles metadata and labels. Field parameters handle data translations. And a visible language toggle button (wired to bookmarks) gives users explicit control. Keep the toggle in a consistent position — typically upper-left for LTR users, upper-right for RTL users.

What Are the Known RTL Limitations in Power BI Visuals?

Quick answer: Power BI has no canvas-level RTL mirroring, matrix visuals lack an RTL option for row headers, chart axes do not reverse for RTL, and text alignment in tables must be set manually per column — these are long-standing gaps, not recently introduced bugs.

Here is a practical inventory of what does and does not work:

What works:

• Card visuals display Arabic text correctly when the font supports it
• Text boxes can be manually right-aligned
• Metadata translations render Arabic names for measures, columns, and table headers in the Service
• Slicer items display Arabic text
• Tooltip text renders in Arabic

What does not work or requires workarounds:

• No canvas mirroring. You must manually position every visual in a mirrored layout. There is no toggle to flip the entire canvas from LTR to RTL.
• Matrix and table visuals. Row and column headers do not have a native RTL alignment option. You can set individual column text alignment to "Right" in the formatting pane, but this is per-column, per-visual — tedious for large matrices.
• Chart axes. Bar and column chart category axes render left-to-right. Arabic text on axes may appear correctly but the axis direction does not reverse.
• Concatenated text. When Power BI auto-generates visual titles by concatenating measure and column names (e.g., "Revenue by Region"), mixing Arabic and English names in the same string can produce garbled bidirectional text.
• Page tab names. Page display names stored in the report layout cannot be localized — they are hard-coded strings. Microsoft recommends hiding page tabs entirely for multilingual reports and using navigation buttons instead.
• Conditional formatting rules. Rule labels remain in the authoring language regardless of the viewer's locale.

Workaround for mirrored layouts: Maintain two report pages — one with LTR visual arrangement, one with RTL — and use bookmarks or navigation buttons to switch between them. This doubles your maintenance surface but gives you full control over the spatial arrangement. Alternatively, if your organization uses Fabric capacity, custom visuals from AppSource that explicitly support RTL rendering can address specific gaps.

How Do You Handle Bilingual Number and Date Formatting?

Quick answer: Power BI automatically formats numbers and dates based on the user's locale when you use regional format strings like Short Date — Arabic locales (ar-SA, ar-AE) render Eastern Arabic numerals and locale-appropriate date formats without custom DAX.

Power BI's locale-aware formatting is one of the areas that genuinely works well. When a report loads with an ar-SA locale:

• Numbers display using Eastern Arabic-Indic numerals (٠١٢٣٤٥٦٧٨٩) by default
• Currency symbols switch to the Saudi Riyal (ر.س) or UAE Dirham (د.إ) based on locale
• Short Date renders as dd/MM/yyyy in the Arabic format
• Day and month names appear in Arabic

To leverage this, use format strings that support regional formatting — Short Date and Long Date rather than hard-coded patterns like MM/dd/yyyy. The DAX FORMAT function with USERCULTURE() enables dynamic formatting:

Formatted Date =
FORMAT(TODAY(), "dddd", USERCULTURE())

This returns "الثلاثاء" for Arabic users and "Tuesday" for English users — automatically.

One gotcha: If your stakeholders prefer Western Arabic numerals (0123456789) even when viewing reports in Arabic — which is common in UAE business contexts — you need to explicitly format numbers with a fixed locale rather than relying on USERCULTURE(). This is a presentation preference you should confirm with stakeholders early in the project.

Frequently Asked Questions

Q: Does Power BI Desktop support Arabic as a UI language?

No. As of early 2026, Power BI Desktop is available in 42 languages but explicitly excludes Arabic and Hebrew. The Desktop application does not support right-to-left languages for either the UI or the report canvas. You can author Arabic content (type Arabic text, use Arabic fonts, add Arabic metadata translations via Translations Builder), but the Desktop interface remains left-to-right. The Power BI Service does support Arabic as a UI language, so the Arabic experience is only available after publishing.

Q: Can I use USERCULTURE() to detect if a user is viewing a report in Arabic?

Yes. The USERCULTURE() DAX function returns the user's locale as a culture code string (e.g., ar-SA for Saudi Arabia, ar-AE for UAE). You can use it inside measures with a SWITCH statement to return Arabic or English text dynamically. However, USERCULTURE() only works reliably in measures and row-level security expressions defined within the semantic model. It may not return the correct locale in live-connect report measures or queries from outside the model. The feature requires Power BI Premium, Premium Per User, Fabric capacity, or Power BI Embedded.

Q: How do I add Hijri calendar dates to my Power BI report?

The recommended approach is generating Hijri dates in Power Query using Date.ToText with the ar-SA culture code, which invokes the Umm al-Qura calendar used in Saudi Arabia. This produces Hijri year, month, and day columns that you add to your date table alongside Gregorian columns. Standard DAX time intelligence functions like SAMEPERIODLASTYEAR do not work with Hijri calendars — you need custom DAX measures using CALCULATE and FILTER against the Hijri columns. See the Hijri calendar section above for complete Power Query M code and DAX patterns.

Q: What is the best font for Arabic dashboards in Power BI?

Sakkal Majalla is the strongest general-purpose choice for Arabic text in Power BI dashboards. It is based on Naskh calligraphy, renders cleanly at all sizes, and is pre-installed on Windows systems. Segoe UI is a good secondary option for UI elements and smaller labels, as it was designed for screen rendering and includes Arabic script support. Both fonts are available without custom deployment. Avoid fonts that lack full Arabic Unicode support, as they will produce disconnected letterforms and broken ligatures.

Q: Can I build one Power BI report that works in both English and Arabic?

Yes, but it requires a layered approach. Use Translations Builder for metadata translations (table, column, and measure names) and report label translations (titles, headings, button captions). Use field parameters for data translations (product names, category labels). Use the language URL parameter or USERCULTURE() to trigger the correct translations at load time. The main limitation is layout — there is no automatic canvas mirroring, so if your Arabic users expect a fully right-to-left visual arrangement, you may need duplicate pages with mirrored layouts linked via bookmarks or navigation buttons.

Q: Does Power BI support RTL chart rendering for Arabic?

Not natively. Chart category axes, legends, and data labels render in left-to-right order regardless of locale. Arabic text within these elements displays correctly as right-to-left text strings, but the chart structure itself (axis direction, legend position) does not mirror. For bar charts, this is usually acceptable because the visual reads naturally from the category labels on the left. For more complex layouts, some organizations use custom visuals from AppSource that offer explicit RTL rendering support.

Bilingual dashboard design is a specialized discipline that most Power BI teams encounter only when serving GCC organizations. The combination of RTL layout engineering, Translations Builder configuration, Hijri calendar DAX, and font testing is a distinct skill set. Beyond The Analytics provides Arabic localization services for Power BI, including reusable bilingual template libraries, Translations Builder configuration, and Hijri calendar semantic model design for GCC enterprises.