Starting from the May 2020 version of Power BI Desktop, regardless of the Windows locale settings DAX always uses standard separators by default. This change does not affect most Power BI users around the world; but if you use the comma as a decimal separator and 10,000 is just ten and not ten thousand, then you are affected by this change.

First of all, you can restore the previous behavior as I describe in this post, but the recommendation and the default are now to use the standard DAX separators. I want to describe why this (I think good) choice was made and how I contributed to making this happen.

If you used Power BI Desktop before the May 2020 version and your Windows locale settings use list and decimal separators other than comma (,) and period (.), you always had a different user experience when writing DAX code. In all examples and articles, you have been seeing code like this:

Taxes := 
SUMX ( Sales, Sales[Quantity] * Sales[Net Price] ) * 0.10

In your Power BI Desktop, this code should have been written as:

Taxes := 
SUMX ( Sales; Sales[Quantity] * Sales[Net Price] ) * 0,10

Over time, Power BI Desktop inherited from Excel this idea of customizing separators in a formula. But Excel goes beyond that and translates the function names. While this could be a good idea for the user interface, when applied to a language it has the negative side effect of making the code samples available on the Internet harder to use with various languages.

Luckily, Power BI never went so far and only limited the translation to the separators. The more common situation is having the semicolon (;) as a list separator and the comma (,) as a decimal separator. However, having a different presentation of the DAX formulas in the user interface creates several issues:

  • Internally, DAX is not translated according to locale settings. The engine uses the period character (.) as a decimal separator and the comma (,) as a list separator. The PBIX file always uses this DAX syntax. Therefore, the Power BI user interface must translate the expressions back and forth by changing these separators.
  • There could be bugs in this conversion. I have seen several of these bugs over the years, and some of them were never fixed because of the ambiguity of certain expressions when using the comma as a decimal point separator.
  • The copy & paste of an expression from a web page is often a pain when there is a different separator convention at play. This “conversion tax” does not help people be more productive.
  • Tools like DAX Studio and DAX Formatter had to deploy an additional effort to support options for separators. The time spent developing and maintaining these features could have been better spent on more productive features.

In October 2019, I suggested implementing an option to choose separators characters in Power BI Desktop regardless of the Windows locale settings.

As part of the Power BI Contributor program, I have been able to work on this feature from December 2019 to April 2020. While the feature did not require months of development, the process of defining requirements, getting approval, implementing the code, and testing use cases requires coordination with many people – and this takes time.

Starting from May 2020, by default Power BI Desktop uses what I call “the standard separators” and ignores the Windows locale settings. We finally have one DAX syntax. You can copy and paste a code sample without having to worry about separators.

In order to minimize the impact, the following message appears the first time you edit DAX code in Power BI.

To be more accurate, this message dialog box is shown when:

  • You enter the DAX formula bar to edit a measure, a calculated column, or a calculated table,
  • AND the separators used by the Windows locale settings are different than the “standard” ones for DAX (comma as a list separator, period as a decimal separator),
  • AND it is the first time you enter the DAX formula bar,
  • AND you have never clicked the “Dismiss” button in the message dialog box.

So if you close the window by clicking on the close button, the same message appears again when you edit another DAX formula. Once you click “Dismiss”, the message is no longer displayed when you edit a DAX formula.

At this point, you should be happy. Really, you should!

Now, what if you prefer to keep your old habits? What if you just need to help Power BI users who do not like the new behavior, and you cannot convince them that it is right? You can restore the previous behavior of Power BI, which respects the localized separators. The Regional Settings dialog box shows the DAX separators section you see below, if and only if the Windows locale settings provide a different choice of list and decimal separators other than the standard ones used by DAX.

You cannot see the “DAX separators section” if your Windows locale settings are set to “English US”.

DAX Formatter and DAX Studio will continue to support the conversion of separators. However, going forward the feature should be taken as is – no more bug fixes, no more improvements, more time available for other features in the backlog!

AND

Checks whether all arguments are TRUE, and returns TRUE if all arguments are TRUE.

AND ( <Logical1>, <Logical2> )