Back to Blog

Using Locale Values in Power BI Reports - USERCULTURE, Date Formats and Multi-Language Labels

October 25, 2026•8 min read•Michael Ridland

If you've built Power BI reports in Australia for any length of time, you've had this conversation. A report goes out, and somebody in the finance team rings up asking why the sales for 3 July look odd. Turns out the report is showing 7/3/2026, half the room is reading it as 7 March, and the other half as 3 July.

Locale is one of those things nobody thinks about until it bites. And for Australian businesses it bites more than you'd expect, because so much of our tooling defaults to US settings, and because a growing number of our clients run reports across New Zealand, Singapore, Japan, Germany or the US.

Microsoft's guidance on using locale values in multiple-language Power BI reports is part of a wider set of docs on building reports for multiple languages. This post pulls out the parts I think matter most, plus a few things we've learned the hard way.

What locale actually controls

A locale is a language and region pair: en-AU, en-US, de-DE, ja-JP, fr-CA and so on. In Power BI it affects two separate things that people tend to blur together:

  1. Language. Which translations get shown for the report UI, for metadata translations (table, column and measure names), and for any custom labels you've built.
  2. Formatting. How dates, numbers and currencies render. Whether a decimal is written 1,234.56 or 1.234,56. Whether a date is 25/10/2026 or 10/25/2026.

The language half needs work from you: translations have to exist somewhere. The formatting half is mostly automatic, as long as you let Power BI do it and don't hard-code format strings that fight it.

Where Power BI gets the locale from

This is where people get confused, so it's worth being exact.

In the Power BI service, the locale comes from the user's language setting. By default that follows the browser language. Users can override it in Settings under General, Language, and there's a separate regional format setting for dates and numbers. A user in Sydney with a browser set to English (United States) will see US date formats unless they change it. This happens a lot, because plenty of corporate Windows builds ship with en-US defaults that nobody ever corrects.

In a URL, you can force a language by adding a language query string parameter to the report link, for example ?language=de-DE. This is useful for testing, and for embedding scenarios where you want to control the experience.

In Power BI Desktop, the locale comes from Desktop's own options under Regional settings. There's also a model language setting, which is fixed when you create the model and determines things like sorting and string comparison behaviour. You can't easily change it later, so get it right on day one.

In embedded scenarios, your application passes the locale when it embeds the report, and you're responsible for picking the right value.

USERCULTURE - the function that makes this useful

The DAX function USERCULTURE() returns the locale of the current user as a string, like "en-AU" or "fr-FR". On its own it's not very exciting. But it's the building block for every dynamic localisation pattern in a report.

The common uses:

Dynamic labels. Report titles, button text, card headings and other text that isn't model metadata won't be translated by metadata translations. The usual pattern is a localised labels table with one row per label key and one column per language. A measure looks up the right column based on USERCULTURE(), and you bind visual titles and text to that measure using conditional formatting (the fx button).

Something along these lines:

Sales Title =
VAR Culture = LEFT ( USERCULTURE (), 2 )
RETURN
    SWITCH (
        Culture,
        "fr", "Ventes par région",
        "de", "Umsatz nach Region",
        "ja", "地域別売上",
        "Sales by Region"
    )

That's fine for three labels. For forty, put them in a table so a translator can edit it without touching DAX. We usually keep the labels in a SharePoint list or a simple Excel file the business owns, and import it into the model.

Locale-aware formatting in text. When you build a sentence in a measure, something like "Revenue is up 12.4% on last month", you're turning numbers into text with FORMAT. By default FORMAT uses the model's locale, not the user's. The function accepts an optional locale argument, so you can pass USERCULTURE() in and get output that matches the user:

Revenue Text =
"Revenue " & FORMAT ( [Revenue], "Currency", USERCULTURE () )

Be careful here. Formatting a number as currency in a German locale gives you euro symbols. If your revenue is in Australian dollars, that's wrong. Locale controls display conventions, not what currency the underlying number is in. For currency values, we often format the number with the user's locale and attach the currency code explicitly.

Filtering data translations. If you're translating actual data values, like product names or category names, the usual approach is a translations table keyed by locale, and a filter driven by USERCULTURE() or by a field parameter. We've written about that separately in our post on data translations with field parameters.

The Australian date problem

I want to spend a bit of time on this because it's the locale issue we see most, and it's almost never about translation.

Things that go wrong:

  • Hard-coded format strings. Somebody sets a date column format to mm/dd/yyyy in the model because that's what Desktop offered. Every user, regardless of locale, now sees US dates. Use the built-in "short date" or "long date" formats, which follow the user's locale, unless you have a good reason not to.
  • Dates converted to text in Power Query. Once a date is text, Power BI can't localise it. Worse, it sorts alphabetically. Keep dates as dates until the very last step.
  • Source system locale mismatches. A CSV exported from a US-configured system lands in Power Query and gets parsed with the wrong locale, so 03/07 becomes 7 March. Use "Change type with locale" (or Table.TransformColumnTypes with a culture argument) when importing text dates. This one fix has solved more support tickets for us than anything else in this post.
  • Users with en-US browsers. As above, the report is fine, but the user's browser says they're American. A short note in your report onboarding about checking the language setting saves a lot of confusion. Some organisations push the setting through browser policy.

A tip we give every client: when you're testing a report, test it with at least two locales. Append ?language=en-US to the URL and look at it, then try ?language=en-AU. If the dates change format and nothing breaks, you've probably done it right. If any date stays stubbornly the same, something has a hard-coded format.

When you need full multi-language support

For organisations operating across several countries, locale is only one piece. The full picture usually involves:

  • Metadata translations for table, column and measure names, so field lists and visual headers appear in the user's language. These are stored in the model and managed with tools like Translations Builder.
  • Report label translations using the USERCULTURE() pattern above.
  • Data translations for the actual values in the data.
  • Locale-aware formatting for numbers and dates.

Honestly, it's a fair bit of work. It's not a checkbox. Microsoft's approach is flexible but it puts the plumbing on you. If you're supporting two languages and a handful of reports, it's manageable. If you're supporting eight languages across fifty reports, you need a process: a single source of truth for labels, a translator workflow, and some automation to keep translations in sync as the model changes.

What's still rough

A few things I'd like Microsoft to fix:

  • Not everything follows the locale. Some visual elements and some custom visuals ignore the user's locale or handle it inconsistently. Test the specific visuals you're using.
  • The model language is sticky. Changing it after the fact is awkward. If you're building a model that will be used internationally, think about it early.
  • Copilot and locale. Copilot in Power BI handles multiple languages reasonably, but the interaction between report translations, metadata translations and Copilot answers is still uneven. If you're relying on Copilot for an international audience, test properly in each language.
  • Subscriptions and exports. Emailed subscriptions and exported PDFs may render with a locale you didn't expect. Check them before you roll out.

Getting started

If you're an Australian business with only Australian users, the job is simple: make sure your dates and numbers follow en-AU, stop hard-coding US formats, and parse source data with the right culture. That alone fixes most locale complaints.

If you're operating across regions, start with USERCULTURE() and a labels table for one report, get the process working end to end with real translators, and then scale it.

We help clients with both of these through our Power BI consulting work, and for teams moving towards a broader reporting platform, our business intelligence solutions cover how locale, translations and AI features fit together. If you're unsure where to start, get in touch and we'll have a look at your reports with you.

The fix for the 7/3 versus 3/7 problem is rarely hard. Somebody just has to care enough to look.