Generate Machine Translations in Power BI Translation Builder - What It Does Well and Where You Still Need a Human

Australia likes to think of itself as an English-speaking country, and in the boardroom it mostly is. But walk onto a factory floor in western Sydney, a farm in the Riverina, an aged care facility in Melbourne or a mine site in the Pilbara, and the picture changes fast. Plenty of the people who actually run the operation, and who could use a good dashboard, do not have English as their first language. And the moment you do any business across the Tasman or into Asia, the assumption breaks entirely. A report that only speaks English is a report that only speaks to some of the people who need it.

This is where multilingual Power BI comes in, and specifically the Translation Builder tool and its ability to generate machine translations. Translation Builder is an external tool that helps you manage translations for the metadata in your semantic model, the table names, column names, measure names and descriptions that users see. The machine translation feature lets you auto-generate those translations rather than typing every one by hand. Microsoft's documentation on generating machine translations covers how to wire it up. I want to talk about what it is genuinely good for, where it falls down, and the step teams keep trying to skip and then regret.

What Translation Builder actually translates

First, a clarification that saves a lot of confusion, because people expect the wrong thing. Translation Builder does not translate your data. It translates your model's metadata. If your report has a column called "Revenue," Translation Builder can make that column display as "Ingresos" for a Spanish-language user or "Recettes" for a French one. It does not touch the actual values in the rows. The customer names, the product descriptions sitting in your data, those stay as they are. It is the labels, the structure, the vocabulary of the report that gets translated, not the contents.

That distinction matters because it sets expectations. A German-speaking user gets a report where every heading, field name and measure reads in German, so they can find their way around without guessing what "YTD Margin %" means. But the data underneath is still the data. For most business reporting that is exactly right. The numbers are universal; it is the framing around them that needs to speak the user's language.

This all rides on a Power BI feature that has been there for a while but rarely gets used: metadata translations in the semantic model. Power BI can store translated versions of object names and show the right one based on the user's language setting. The problem has always been that entering all those translations by hand, across dozens of fields and several languages, is tedious enough that nobody bothers. Translation Builder exists to remove that friction, and the machine translation feature is the part that removes the most.

How the machine translation piece works

Rather than typing each translation, you point Translation Builder at a translation service, and it generates translations for your metadata automatically. It calls a machine translation engine, an Azure translation service, to produce the translated strings for the languages you have added to the model. You add your target languages, trigger the generation, and it fills in the translations for every object across those languages in one pass.

The value is obvious the first time you see it. A model with fifty or sixty visible objects across four languages is hundreds of individual strings. Doing that by hand is a day of soul-destroying work. The machine translation feature turns it into a few minutes. For getting a multilingual model off the ground, it is a genuine time-saver, and I would not go back to hand-entry for the first pass.

Because it runs against an Azure translation service, there is a small amount of setup on the connection side, and there can be a cost depending on volume, though for the amount of text involved in metadata translation it is usually trivial. The heavier lift is not the setup. It is what comes after.

The review step you cannot skip

Here is the honest bit, and it is the whole reason I wanted to write this. Machine translation of metadata is very good at the easy words and quietly wrong on the ones that matter most, which are your domain-specific terms.

"Date," "Quantity," "Customer," "Region," the machine handles these fine. Where it stumbles is your business vocabulary. Take a measure called "Net Margin." A general translation engine might render "Margin" as the physical edge of a page rather than the financial concept, because without context it cannot know which "margin" you mean. Industry terms, internal jargon, acronyms and abbreviations are where machine translation produces something that is grammatically fine and professionally embarrassing. A finance user in your Singapore office reading a mistranslated financial term does not think "the machine got that wrong." They think "these people do not know what they are doing."

Then there is the abbreviation problem. Report fields are full of short forms, "Qty," "YTD," "FY," "GL," and machine translation handles these unpredictably. Sometimes it leaves them, sometimes it expands them incorrectly, sometimes it translates the letters as if they were a word. You need eyes on every one.

And there is tone and formality, which varies by language in ways English speakers underestimate. Several languages have formal and informal registers, and a business report should generally use the formal one. Machine translation does not always pick correctly, and getting it wrong reads as either cold or unprofessional to a native speaker, depending on which way it lands.

So the workflow that actually works is not "generate and ship." It is generate, then have a native speaker who knows the business domain review and correct the output. The machine does the volume, the human fixes the terms that carry meaning. Translation Builder supports exactly this, because you can edit the generated translations, so the machine gives you a strong first draft and the reviewer polishes the twenty percent that matters. Skipping the review is the mistake I see most, and it is a false economy. You save an afternoon and hand a professional-looking report full of subtle errors to the exact audience most likely to notice.

Is it worth doing at all?

For genuinely multilingual audiences, absolutely. If you have staff, partners or customers who work better in another language, a report they can read properly is a report they will actually use, and adoption is the only measure of a dashboard that means anything. We have seen operational dashboards go from ignored to essential simply because the frontline team could finally read the field names without translating them in their heads.

But be honest about whether you have that audience. Building four-language support into a report that only three English-speaking managers will ever open is effort spent on nobody. Multilingual is worth it when the language barrier is real and it is keeping people from using the data. It is overhead when you are adding it because it sounds thorough. Match the feature to the actual audience, same as any other design decision.

The other thing worth saying is that translation is not a one-off. Every time you add a measure or rename a field, you have new untranslated metadata, and the model drifts back toward monolingual if nobody maintains it. Machine translation makes the ongoing maintenance cheap, which is arguably its bigger long-term value than the initial pass. But someone still has to run it and review the new terms, so build that into how the model is maintained rather than treating translation as a launch-day task you tick off once.

This is the kind of detail our Power BI consultants think about when a report has an audience beyond head office, because a genuinely usable report meets people in the language they work in. It connects to the broader Microsoft Fabric and data platform work we do, where the semantic model is the shared layer everything else reads from, so getting the metadata right, in every language your business needs, pays off across every report built on top of it. And because the machine translation piece runs on Azure's translation service, it sits alongside the wider Azure AI work we do for clients who want language and AI capability built into their reporting properly rather than bolted on.

If you have got a Power BI estate that needs to speak more than one language, and you want it done so it reads well to native speakers rather than just technically translated, get in touch and we will help you get it right.