Multi-Language Power BI Reports with Translations Builder - What Works and What Hurts

Australia likes to think of itself as an English-speaking market, and then you look at who's actually using the reports. A logistics client of ours has depot supervisors whose first language is Vietnamese. A manufacturer we work with runs shifts where the working languages on the floor are Mandarin and Filipino. Government service teams report against community language cohorts. And plenty of Australian companies now have a Singapore or Jakarta office opening the same Power BI workspace every morning.

For years the answer to "can we get this report in another language" was either "no" or "we'll build a second copy", and the second copy always rotted. There is a proper answer now, and the tooling that makes it workable is Translations Builder. It's not a polished product feature - it's an external tool you bolt onto Power BI Desktop - but it turns something that used to be an afternoon of hand-editing XMLA scripts into something an analyst can actually do.

We've used it on a few projects now. Here's the honest state of it.

What Power BI translation actually covers

Before the tool, understand the model, because Power BI's translation story comes in three layers and they are not equally easy.

The first layer is metadata translations. These are translated names for the objects in your semantic model - tables, columns, measures, hierarchies. When a French-speaking user opens the report, the "Sales Amount" measure shows as "Montant des ventes" in every visual that uses it. These translations live inside the model itself, they survive republishing, and they're the layer Translations Builder was built for.

The second layer is report label translations - the text that lives in the report layer rather than the model. Visual titles, text boxes, button captions. Power BI has no native translation support for these at all, which surprises everyone the first time. The workaround is a technique called the Localized Labels table - you create hidden measures whose only job is to carry a label, translate those measures like any other model object, and then bind your titles to them with conditional formatting. It's a hack. It's also the accepted hack, Microsoft documents it, and Translations Builder has tooling to generate the table for you.

The third layer is data translations - translating the actual rows, so "Bicycle" in the product column becomes "Vélo". This is real modelling work. You need translation tables in your source, and you filter them by the user's culture with the USERCULTURE function. No tool automates it away, because the translations have to come from your data. If someone tells you their tool handles data translation automatically, ask more questions.

Most projects need layer one, should budget for layer two, and only some genuinely need layer three. Scoping that early saves a lot of grief.

Where Translations Builder fits

Translations Builder is an open-source external tool from Microsoft. You install it, it appears in Power BI Desktop's External Tools ribbon, and when you launch it, it connects to the model of whatever .pbix you have open and shows you a grid - your translatable objects down the side, your languages across the top. Add a language, and you get an empty column to fill.

Filling it is where the tool earns its place. You can type translations by hand into the grid, which is fine for a dozen measures and miserable for four hundred. You can generate machine translations through Azure Translator, which needs an Azure key but then populates an entire language column in seconds. Or you can export a translation sheet, send it to a professional translator or the bilingual person in your Melbourne office, and import the result back in.

The workflow we've settled on with clients is machine-translate first, then human-review the sheet. Machine translation gets the grammar right and the business vocabulary wrong. "Churn" and "pipeline" and "write-off" all have specific meanings in your organisation that a translation model will cheerfully mangle. A native speaker reviewing a spreadsheet for an hour catches nearly all of it. Pure machine translation with no review is how you end up presenting a board pack where a column header translates back as something mildly absurd, and yes, we've seen it happen.

The traps, because there are a few

The biggest one: you cannot see your translations in Power BI Desktop. Desktop always shows the model's default language, full stop. Translations only come alive in the Power BI service, and only when the workspace sits on capacity - Fabric, Premium, or Premium Per User. So the test loop is publish, open the report in the browser with a language parameter on the URL, check, fix, republish. It's clunky, and if your organisation hasn't got capacity licensing, metadata translations simply won't load for your users at all. That licensing dependency is the first thing to check before you promise anyone a multilingual report, and it's one more item on the list of reasons clients end up talking to us about Microsoft Fabric capacity planning.

Second trap: translations are tied to objects, and objects get renamed. When an analyst renames a measure six weeks later, the translations for the old name don't follow automatically in every workflow, and machine-generated columns silently go stale as new measures arrive untranslated. Multilingual models need a light process around them - a check before each release that the translation grid has no gaps. Translations Builder shows you the gaps clearly, but someone has to look.

Third: locale-aware formatting is a separate problem and translation doesn't solve it. Dates, decimal separators, currency symbols. A German-speaking user reading translated column names next to dates formatted as MM/DD is still going to misread the report. Plan formatting alongside translation, not after it.

And a soft one that bites hardest: nobody owns the second language. The English version of the report has an owner who cares. The translated version often has no one reviewing it after go-live, so quality drifts. If a language matters enough to ship, name a human who checks it quarterly. This is an organisational fix, not a technical one, which is exactly why it gets skipped.

Is it worth doing?

When there's a real audience, absolutely. The lift is smaller than people expect - for a mid-sized model, the first pass with machine translation plus review is a day or two, not weeks. And the alternative, maintaining parallel report copies per language, is so much worse that I'd treat it as off the table. Every duplicated report is a future inconsistency with a due date.

Where I'd push back is translating speculatively. "We might expand into Japan next year" is not a reason to add Japanese to forty reports now. Translation carries a maintenance tail, and an unmaintained translation is worse than none, because it looks authoritative while being wrong. Add languages when there are named users who will read them.

The other thing worth saying: a multilingual report estate rewards the same discipline as any well-run reporting setup - shared semantic models, agreed definitions, one version of each number. If your underlying models are a sprawl, translation multiplies the sprawl by the number of languages. Getting the foundations straight is most of what our Power BI consulting engagements end up being about, and translation is one more reason to do it before scaling out rather than after.

Getting started

Take one report with a genuine non-English audience. Confirm the workspace is on capacity. Install Translations Builder, add one language, machine-translate, and get a native speaker to review the exported sheet. Generate the Localized Labels table for your visual titles while you're in there, because a report with translated data labels and English titles looks half-finished. Publish, test with the language URL parameter, and put the report in front of two or three of the actual users.

Microsoft's guidance on building reports with Translations Builder is genuinely good - detailed, honest about the workarounds, and kept current. Read it before you start.

And if you're weighing up how multilingual reporting fits into a broader analytics platform, or you've got a reporting estate that needs untangling before you dare multiply it by three languages, get in touch. Sorting exactly that kind of thing out is a normal week for us.