Building a multilingual Power BI report has always been one of those requirements that sounded simple but turned out painful to implement. A French-speaking user opens your report and sees English category names. A Spanish-speaking user opens the same report and sees the same English values. You end up either maintaining multiple reports — one per language — or wrestling with external tools and complex workarounds just to get translations working properly.
Published by Reza Rad | RADACAD
📺 Watch the full video on YouTube: Power BI Multilingual Made Simple — User-Context-Aware Calculated Column
🌐 RADACAD Blog: radacad.com
That story has now changed.
A newly announced feature in Power BI — user-context-aware calculated columns — makes multilingual reports dramatically simpler to build. And in this article, I am going to show you exactly how it works, step by step.
What Is a Multilingual Power BI Report? (Video: 0:00)
The idea is straightforward. You have a single Power BI report and a single semantic model. When a user from a French-speaking country opens that report in the Power BI service, they see category names, product names, and other text values in French. When a user from an English-speaking country opens the same report, they see everything in English. When a Spanish-speaking user opens it — Spanish.
One report. One semantic model. Multiple language outputs — automatically, based on the user’s browser locale.
This is called translation in Power BI. And the way we have done translation historically has been anything but straightforward.
How Translation Worked Before — And Why It Was Painful (Video: 0:57)
Translation support in Analysis Services and tabular models has existed for a long time. In SQL Server Analysis Services multidimensional models, you could set up translations through Visual Studio or the old SSDT tool. In tabular models, the same was available through Visual Studio.
When Power BI Desktop arrived, translation support was not included. That gap forced the community to rely on external tools — primarily Tabular Editor — to define and manage translations in Power BI semantic models. Tools like Translations Builder also emerged to help manage the process. But it was always additional overhead — a separate tool, a separate workflow, complexity that most teams struggled to maintain.
That changes now.
What Are User-Context-Aware Calculated Columns? (Video: 1:37)
In Power BI, a standard calculated column is pre-calculated at refresh time. When your semantic model refreshes, the engine evaluates every row in your calculated column expression and stores the result. The calculation is static — it does not change based on who is viewing the report. It is fixed the moment the data loads.
That is why, historically, certain DAX functions have been forbidden inside calculated columns. Functions like USERPRINCIPALNAME(), USERCULTURE(), and CUSTOMDATA() have only been available inside measures — because measures are evaluated dynamically at query time, and these functions need to know who is running the query right now.
The new user-context-aware calculated column breaks that constraint.
When you create a calculated column and change its expression context from Standard to User Context — in the Advanced tab of the column properties — the column no longer pre-calculates at refresh time. Instead, it calculates on the fly, similar to a measure, but it remains row-based like a calculated column.
Think of it as something that sits between a calculated column and a measure. It has the row-level behaviour of a calculated column — which means you can use it as an axis, a slicer, or a grouping field in a visual. But it has the dynamic evaluation behaviour of a measure — which means it can respond to who is currently logged in.
This is a meaningful architectural addition to DAX. If you want to understand the existing difference between measures and calculated columns in more depth, I have a full article on that here: Measure vs Calculated Column: The Mysterious Question? Not!
How to Enable the Feature (Video: 2:56)
At the time of this writing, user-context-aware calculated columns are a preview feature in Power BI Desktop. To enable it:
- Open Power BI Desktop
- Go to File → Options and Settings → Options
- Navigate to the Preview Features section
- Find User context aware calculated column and enable it
- Restart Power BI Desktop
Once it is enabled, you will have access to the User Context expression context option when creating or editing calculated columns.
💡 Important note: This feature requires a recent version of Power BI Desktop. If you do not see it in Preview Features, update to the latest version first.
Building the Multilingual Calculated Column — Step by Step (Video: 3:41)
Let me walk you through exactly how to build this.
The Data Setup
For this to work, you need your translation data already present in your semantic model. In my example, I have a Customer table with three columns for the Education field:
Education— values in EnglishEducation_ES— values in SpanishEducation_FR— values in French
This is the standard translation table pattern — you store all language variants as separate columns. What we are building is a single calculated column that automatically picks the right one based on the user’s locale.
Creating the User-Context-Aware Calculated Column
Go to your Customer table and create a new calculated column. Write your expression — and before committing it, go to the Advanced tab of the calculated column and change the Expression Context from Standard to User Context.
Here is the DAX expression I used:
Education =
VAR _Culture = USERCULTURE()
RETURN
SWITCH(
LEFT( _Culture, 2 ),
"en", Customer[Education],
"es", Customer[Education_ES],
"fr", Customer[Education_FR],
Customer[Education]
)
Let me break this down:
Step 1 — Capture the user culture into a variable. USERCULTURE() returns the locale of the currently logged-in user — for example, en-US, fr-FR, es-ES, en-GB, en-AU. I store it in a variable called _Culture.
Step 2 — Extract just the language code. I use LEFT(_Culture, 2) to get only the first two characters — en, fr, or es. This means I do not need to handle en-US and en-GB separately. Any English locale resolves to en and returns the English column.
Step 3 — Use SWITCH to return the right column. The SWITCH statement checks the two-character language code and returns the appropriate column. The final clause — without a match value — acts as the ELSE case and defaults to English if no other match is found.
You can read more about the SWITCH function and how it works in Power BI DAX in my dedicated article on DAX SWITCH expression. And if you want to understand why using a variable here is good practice, the basics of DAX expressions article covers that as well.
Why Not Just Use USERPRINCIPALNAME or CUSTOMDATA?
USERCULTURE() is used for locale-based scenarios like translation. But this same user-context-aware calculated column pattern works with other user-aware functions too:
USERPRINCIPALNAME()— returns the email address of the logged-in user. Useful for personalised content, dynamic row-level security logic, or audit columns.CUSTOMDATA()— returns a custom string passed in the connection string. Useful for multi-tenant scenarios.
The pattern is the same — change the expression context to User Context, and these functions become available inside a calculated column. For more on Row-Level Security patterns where these functions are relevant, I have covered this in depth here: Row Level Security Types in Power BI.
Using the Column in Your Report (Video: 10:00)
Because the result of a user-context-aware calculated column is still a column — not a measure — you can use it anywhere a column is valid in Power BI:
- As a field in a table or matrix visual
- As a slicer field
- As the axis of a bar chart or column chart
- As a grouping field in any aggregation
This is the key difference from doing the same thing with a measure. If you returned the translated value from a measure, you could only use it as a value — you could not group or slice by it. With a user-context-aware calculated column, you get the full flexibility of a dimension column while still responding to the logged-in user’s context.
Publishing to the Power BI Service (Video: 10:30)
Once you have built your calculated column and verified it works in Power BI Desktop, publishing to the Power BI service is exactly the same as any other report. No special steps.
💡 Good news: You do not need a Fabric capacity to use this feature. It works on standard Power BI Pro workspaces. Publish as normal.
Once published, the behaviour works like this:
- A user with English browser settings opens the report → they see English values
- A user with French browser settings opens the report → they see French values
- A user with Spanish browser settings opens the report → they see Spanish values
All from the same report. The same semantic model. No report duplication. No user-specific filters. No manual language switching. It just works.
You can even test this in the browser by appending ?language=fr or ?language=es to the Power BI service report URL. This overrides the browser locale for testing purposes, which is how I demonstrated the French and Spanish outputs in the video.
One Important Performance Warning (Video: 7:37)
User-context-aware calculated columns are calculated on the fly — not pre-calculated at refresh time. This means they behave more like measures from a computation perspective.
The practical implication: do not put heavy calculations in a user-context-aware calculated column.
Simple lookups, SWITCH statements, string manipulations — these are fine. But if your expression involves complex iterators, large table scans, or expensive aggregations, you will feel that in query performance. Keep the expression lean. The scenarios this feature is designed for — translation, user personalisation, conditional content — are naturally simple expressions that are well suited to this evaluation model.
If you are generally interested in understanding when to use calculated columns versus measures and the performance implications of each, my article on Measure vs Calculated Column goes into this in detail.
What Else Can You Do With This Feature?
Translation and multilingual reports are the headline scenario — but user-context-aware calculated columns open up a broader set of possibilities:
- Dynamic Row-Level Security — build RLS logic using
USERPRINCIPALNAME()directly in a calculated column, enabling more flexible security patterns. I covered RLS patterns in depth here: Dynamic Row Level Security in Power BI. - Personalised content — show user-specific labels, greetings, or annotations based on the logged-in user’s identity.
- Multi-tenant models — use
CUSTOMDATA()to return tenant-specific content from a single shared model. - Audit columns — track which user last interacted with a record (useful in combination with write-back scenarios).
Key Takeaways
- User-context-aware calculated columns are a new type of calculated column in Power BI that evaluates dynamically based on the logged-in user — not at refresh time.
- They unlock DAX functions like
USERCULTURE(),USERPRINCIPALNAME(), andCUSTOMDATA()inside calculated columns, which were previously only available in measures. - The expression context is changed in the Advanced tab of the calculated column from Standard to User Context.
- The result is still a column — so you can use it as an axis, slicer, or grouping field, unlike a measure.
- This makes multilingual Power BI reports dramatically simpler to build — one report, one model, multiple language outputs automatically based on user locale.
- No Fabric capacity required. Works on standard Power BI Pro workspaces.
- Keep expressions simple. These columns calculate on the fly, so performance matters.
Related Resources on RADACAD
- 📝 Measure vs Calculated Column: The Mysterious Question? Not!
- 📝 Basics of DAX Expression in Power BI
- 📝 Row Level Security Types in Power BI
- 📝 Dynamic Row Level Security in Power BI
- 📝 Power BI DAX Back to Basics: Scalar vs Tabular Functions
- 📝 Dynamically Change the Format of Values in Power BI
- 📖 Power BI Books by Reza Rad
Reza Rad is a Microsoft Regional Director, Data Platform MVP, Author, and Trainer. He is the co-founder of RADACAD and the author of multiple books on Power BI, Power Query, and Microsoft Fabric. You can follow him on LinkedIn and subscribe to the RADACAD YouTube channel.
Reza is author of more than 14 books on Microsoft Business Intelligence, most of these books are published under Power BI category. Among these are books such as Power BI DAX Simplified, Pro Power BI Architecture, Power BI from Rookie to Rock Star, Power Query books series, Row-Level Security in Power BI and etc.
He is an International Speaker in Microsoft Ignite, Microsoft Business Applications Summit, Data Insight Summit, PASS Summit, SQL Saturday and SQL user groups. And He is a Microsoft Certified Trainer.
Reza’s passion is to help you find the best data solution, he is Data enthusiast.
His articles on different aspects of technologies, especially on MS BI, can be found on his blog: https://radacad.com/blog.