Localising Power BI Reports - What Australian Businesses Need to Know

A surprising number of Australian businesses end up needing multi-language Power BI reports. It's not just the global enterprises. Mid-sized firms with operations in Asia-Pacific. Companies acquired by overseas parents who want consistent reporting across regions. Education providers serving international students. Once you start looking, the need shows up everywhere.

The problem is that almost no one plans for it. Reports get built in English first, work fine, then someone says "can we make this work in Mandarin?" and the team discovers they have to rebuild most of it. I've sat in too many meetings where we've had to deliver the bad news: yes, we can localise it, but it's going to cost about as much as building it from scratch.

This post is about avoiding that. If there's any chance you'll need multi-language reports, plan for it now. The cost of building with localisation in mind from day one is small. The cost of retrofitting is huge.

Why localisation in Power BI is harder than it should be

Power BI wasn't really designed with multi-language reporting as a core feature. The tooling has improved a lot recently with Translations Builder and proper translation support in semantic models, but compared to web applications or proper software localisation frameworks, it's still rough around the edges.

The biggest issue is that many common Power BI design patterns actively work against localisation. Hardcoded text in visual titles. Text labels embedded in images. Custom tooltips with English strings baked in. All of these need to be undone before you can even start adding translations.

A typical engagement involves more time fixing patterns that don't support localisation than actually adding translations. This catches teams by surprise. We're paying you to add Spanish, why is half the budget going to changing the report?

Two approaches to packaging your work

Before you start localising, you need to decide how your semantic models and reports are packaged. There are two approaches and they have different implications for how you handle multi-language support.

The first is the single .pbix file. Your semantic model and report layout are bundled together. You publish it as one unit and update it as one unit. This is simpler for small projects but limits your flexibility.

The second is the shared semantic model approach. You have one .pbix file with the semantic model and possibly an empty report. You publish that to your Power BI workspace. Then you build separate .pbix files that connect to the published semantic model and contain just the report layouts. Multiple report files can connect to the same semantic model.

For localisation, the shared semantic model approach has clear advantages. You can have different report files for different languages or regions, all sharing the same underlying model. Updates to the model propagate to all reports. Updates to a specific language version only affect that version.

The single file approach can still work for localisation, but you end up either maintaining separate copies of the file (which is painful) or using one file with all language translations embedded (which is fine for smaller solutions).

We typically recommend the shared semantic model approach for any client doing serious work in Microsoft Fabric or Power BI. The flexibility pays back quickly, not just for localisation but for general maintenance.

Plan for text size variation

Here's a problem you don't think about until it bites you. English is compact. A label that fits in 200 pixels in English might need 300 pixels in German. Or might shrink in Chinese. The width of your labels matters when the text changes.

If you optimise your visual layout for English text and then translate to a language with longer words, you get truncation. Important text gets cut off or wrapped in awkward ways. Buttons overflow. Labels overlap. The report looks broken.

The fix is to add padding everywhere from the start. Don't shrink labels to fit perfectly. Give them room to grow. This feels wasteful when you only have English content but pays off when translations land.

Real numbers from a project we did last year. A report built tightly in English needed about 20% layout rework when adding German and 15% rework when adding French. The same report with padding built in needed almost no layout changes. The rework time alone covered the initial padding effort several times over.

This applies to visual titles, column headers, axis labels, slicer labels, and any other text element in the report. Test with realistic translated content during development. Don't wait until production to discover something doesn't fit.

What needs to be translated

People underestimate the scope of localisation. It's not just the report titles. A proper multi-language Power BI report needs translation for:

Semantic model object names. Tables, columns, measures, hierarchies. The names visible to users when they interact with the model.

Display folders. The folders that organise measures and columns in the field list.

Descriptions. The tooltip text that appears when users hover over fields.

Report visual elements. Visual titles, axis labels, data labels, conditional formatting rule names.

Static text on the report canvas. Text boxes, headings, instructions.

Slicer headers. Even when the data inside is just IDs or codes, the slicer header itself needs translation.

Filter pane labels. The text used in the filter pane to describe each filter.

Default report labels. Things like "Page" and "of" in pagination, "More options" in tooltips. Some of these are controlled by the user's Power BI language setting, but others need explicit handling.

Data values where applicable. Status fields, category names, anything that's text content rather than numbers. This often requires translation tables in the model rather than runtime translation.

The list is long. Build a checklist before you start translating anything so nothing gets missed.

Using Translations Builder

Translations Builder is the open-source tool from Microsoft that has become the standard way to manage Power BI translations. It exports your model's translatable strings to Excel, lets translators work in that familiar tool, and imports the results back into the model.

It works well for the structured parts of localisation. Object names, descriptions, display folders. Less well for unstructured content like text boxes in reports, which still need manual handling.

The workflow we recommend is to keep translations in source control alongside your .pbix files. The Excel files that Translations Builder produces should be tracked in Git. When translators update them, those updates go through code review like any other change. This catches errors and gives you a real history of changes.

A common gotcha is that Translations Builder works with the .pbit template format better than the .pbix format. You may need to export your file as a template, apply translations, and then save back. Test the workflow carefully before committing to it for a large project.

The data layer often needs help too

If your data contains text in only one language but you need to display it in multiple languages, you have a data problem before you have a Power BI problem. Power BI can't translate "Category: Beverages" to "Categoría: Bebidas" if your database only has "Beverages."

You need to build the translations into the data model itself. Either translation tables that join to the main tables, or translated columns on the main tables. Both approaches work. Translation tables are cleaner for data with many translatable fields. Translated columns are simpler for data with just a few fields.

Either way, this is a data engineering task, not a Power BI task. Plan it in advance and budget for it. We see clients get caught here all the time. They've planned the Power BI work but not the data preparation work, and the project stalls until the data team catches up.

For organisations with serious data engineering needs, this usually fits into existing data pipelines but adds complexity that needs to be designed for.

Testing with each language

This is where projects often fail. Teams add translations, smoke test in one language, and call it done. Then users in another region complain about layout issues, wrong characters, broken sorting.

Test thoroughly with every language you support. Switch your Power BI language setting and open the report. Check every page. Check every visual. Check filter behaviour, sort order, data formatting.

Pay attention to language-specific quirks. Date formats vary. Decimal separators vary. Currency symbols vary. Some scripts read right to left. Some languages have unusual character widths. All of these can break visuals in ways that don't appear in English.

Allocate proper testing time per language. We usually budget at least 20% of the original development time for testing each additional language. For a complex report, that's a lot of testing. Skipping it leads to embarrassment when international users find problems you didn't.

When localisation isn't worth it

Honest assessment: not every report needs to be localised. Some organisations have small enough non-English-speaking user bases that the cost of localisation outweighs the benefit. Sometimes a separate simpler report for that audience is better than translating the full thing.

Have the conversation with stakeholders early. Who actually needs the localised version? How many users? Are they likely to read English well enough? Could a simpler translated summary report meet their needs without translating everything?

For a recent client, we started a localisation project and after the first week of analysis recommended scaling it back significantly. Of fifteen reports they wanted translated, only four were actually used regularly by non-English-speaking staff. The other eleven could stay English-only. Massive cost saving from asking the right questions early.

Where to start

If you're planning multi-language Power BI work, start with one report. Get the patterns right. Establish your tooling, your translation workflow, your testing approach. Then scale.

Trying to localise an entire Power BI estate at once is a mistake. The first report teaches you what your specific organisation needs, and that learning shapes everything else. Build one, learn from it, then apply the learnings broadly.

If you're considering this and want a conversation about scope and approach, we help organisations plan this kind of work. Often the conversation reveals more options than people realise.

Reference: Use best practices to localize Power BI reports - Microsoft Learn