Meertalige Power BI-rapporten: 3 manieren om te vertalen
Een Power BI-rapport vertalen klinkt onmogelijk, of als heel veel teksten omzetten. Werk je voor een organisatie die in meerdere landen opereert, dan is de kans groot dat er een vraag komt of het rapport in meerdere talen kan worden weergegeven.
De eerste gedachte is vaak om het rapport te kopiëren en de teksten te vertalen. Dat kan eventueel werken voor één rapport, maar heb je er meerdere, dan weegt de hoeveelheid werk niet op tegen de baten die het oplevert.
In deze blog beschrijf ik welke varianten er zijn, wat het kost qua inspanning, en wanneer je welke nodig hebt.
Vertaalmogelijkheden
Microsoft onderscheidt in de documentatie voor meertalige rapporten drie soorten vertalingen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stuur je op budget? Dan is het volgende belangrijk om te onthouden: er is geen knop die “alles vertaalt”. Met de eerste twee varianten kom je al heel ver. De derde variant heeft invloed op je semantische model en is een project op zich. Microsoft geeft daarvoor ook aan: data-vertaling vraagt planning en inspanning. Maak er dus alleen werk van als het echt een harde eis is.
De praktische vraag is daarom niet: “Hoe vertaal ik alles?”, maar: “Welke vertaling heeft mijn gebruiker daadwerkelijk nodig?” Een controller die dagelijks met het rapport werkt, heeft vaak genoeg aan labels in zijn eigen taal. Een klant die één keer per maand inlogt en de cijfers zelfstandig moet kunnen begrijpen, heeft waarschijnlijk meer nodig.
Variant 1: de namen in je model
Power BI kan de namen van tabellen, kolommen en measures opslaan per cultuur. Een cultuur is een combinatie van taal en regio, zoals nl-NL, fr-FR of fr-BE. Bij het openen van het rapport bepaalt de Power BI Service welke cultuur geldt, op basis van de taalinstelling van de gebruiker of diens browser, en toont daarbij automatisch de bijbehorende vertaalde namen.
Je beheert deze vertalingen met een externe tool. Translations Builder is daarvoor de meest voor de hand liggende keuze en wordt ook in de Microsoft-documentatie beschreven. De tool verzamelt alle vertalingen in één overzicht. Je exporteert het bestand, laat een vertaler de teksten controleren en aanvullen en importeert het daarna weer in je model.
Translations Builder kan ook machinevertalingen genereren, bijvoorbeeld via Azure Translator. Daarmee kun je snel een eerste vertaling maken die je vervolgens door een menselijke vertaler laat controleren en verbeteren. Microsoft benadrukt zelf dat machinevertalingen niet altijd van voldoende kwaliteit zijn voor productie.
Functioneel gezien is dit je fundament. Het kost relatief weinig moeite, werkt direct door in je hele rapport en vereist geen maatwerk. Dit is dus een goede optie om mee te starten.
Culturen moeten exact overeenkomen
Dit gaat in de praktijk regelmatig mis. Voor tabellen en kolommen moet de cultuur exact overeenkomen. Bevat je model alleen fr-FR en opent een Belgische gebruiker het rapport met fr-BE, dan krijgt hij wél de Franse measurenamen, maar vallen de tabel- en kolomnamen terug op de standaardtaal van je model. Microsoft noemt dit een bekend probleem en adviseert daarom elke cultuur die je wilt ondersteunen apart toe te voegen, ook als de vertalingen identiek zijn. Een dynamische titel op basis van een cultuur kan er als volgt uit zien:
Titel omzet =
SWITCH(
USERCULTURE(),
"nl-NL", "Totale omzet per reseller",
"fr-FR", "Chiffre d'affaires total par revendeur",
"de-DE", "Gesamtumsatz nach Wiederverkäufer",
"Total sales by reseller"
)
Test in de Service, niet in Desktop
In de Service kan je een taal forceren door “?language=fr-FR” achter de rapport-URL te zetten, wat handig is om je vertalingen te controleren zonder je browserinstellingen te wijzigen.
Variant 2: de teksten in je rapport
Metadata-vertaling lost niet automatisch alle teksten in je rapport op. Zo worden titels van visuals die je zelf hebt aangepast niet vanzelf vertaald. En dat aanpassen doe je vrijwel altijd, want “Sum of Sales Amount by Reseller Name” wil je waarschijnlijk niet aan je klant tonen.
Ook tekst die je rechtstreeks in de rapportlay-out zet, bijvoorbeeld in een tekstvak of button label, valt niet automatisch onder de modelvertalingen. Wil je dat zulke teksten met de taal van de gebruiker meebewegen, dan moet je ze dynamisch maken, bijvoorbeeld met measures. Dat kan op verschillende manieren. Het verschil zit vooral in hoeveel onderhoud je eraan hebt.
De snelle manier
Je maakt per titel een measure die op basis van de taal van de gebruiker de juiste tekst teruggeeft. Voor een handvol titels werkt dat prima. Maar bij dertig titels heb je al snel dertig measures en moet je bij een nieuwe taal veel van die logica aanpassen.
De manier die meegroeit
Je zet alle vertalingen in één tabel met drie kolommen: een sleutel, een taalcode en de vertaling. Die tabel kun je bijvoorbeeld vanuit Excel vullen. Je vertaler werkt dan in Excel, niet in Power BI en niet in DAX, en jij ververst vervolgens je model.
Je maakt nog steeds één measure per titel, maar die measure blijft klein: hij haalt alleen de juiste tekst op uit de tabel.
Titel omzet =
LOOKUPVALUE(
Vertalingen[Vertaling],
Vertalingen[Sleutel], "TitelOmzet"
)
Eén voorwaarde: deze lookup werkt alleen als de vertaaltabel al is teruggebracht tot één taal. Staan alle talen er nog in, dan vindt de functie meerdere rijen bij dezelfde sleutel en krijg je een foutmelding. Je hebt dus altijd een filter op de taal nodig, bijvoorbeeld via de taaltabel in combinatie met row-level security, of door de taalcode als tweede zoekvoorwaarde mee te geven in de DAX measure.
Waarom dit functioneel beter is: het haalt de vertaling weg bij de ontwikkelaar en legt het bij degene die de taal spreekt. Een nieuwe taal toevoegen is een kolom in Excel, geen wijziging in je model. En het scheelt rekentijd, want een lookup op een al gefilterde tabel (door bijvoorbeeld de RLS) is lichter dan een lange keuzelijst die bij elke visual opnieuw wordt doorlopen.
AI kan hier veel voorwerk uit handen nemen. De vertalingen staan in een eenvoudige tabel, waardoor je een eerste versie eenvoudig kan laten genereren op basis van een Nederlandse of Engelse brontekst. De vertaler hoeft daarna vooral te controleren en te corrigeren, in plaats van elke tekst vanaf nul te vertalen.
Variant 3: de waarden in je data
Je measurenamen en titels zijn vertaald, maar de waarden in je grafiek heten nog steeds “Elektronica”, “Witgoed” en “Cosmetica”. Die waardes komen rechtstreeks uit je data. Ze worden daarom niet automatisch vertaald door de modelvertalingen. Hiervoor beschrijft Microsoft een specifieke aanpak: data-vertaling met field parameters.
Hoe het functioneel werkt
Het principe is eenvoudiger dan het misschien lijkt. Je breidt je brontabel uit met een tekstkolom per taal: een kolom met Engelse productnamen, een met Franse en een met Italiaanse. Vervolgens maak je een field parameter die bepaalt welke kolom voor de gekozen taal wordt gebruikt.
Vertaalde productnamen = {
("Product", NAMEOF('Producten'[NaamEN]), 0, "en"),
("Produit", NAMEOF('Producten'[NaamFR]), 1, "fr"),
("Prodotto", NAMEOF('Producten'[NaamIT]), 2, "it")
}
Elke regel koppelt een taalcode aan de bijbehorende kolom.
In je visual gebruik je vervolgens niet langer rechtstreeks de kolom met productnamen, maar de field parameter. Staat de taal op Frans, dan gebruikt de visual de Franse productnamen. Die vertaling zie je vervolgens terug op de plekken waar die waarden worden gebruikt, zoals in de grafiek, legenda, tooltip of as.
Een detail dat je makkelijk over het hoofd ziet: de eerste waarde in elke regel is de weergavenaam van de kolom. Vergeet je die te vertalen, dan zien Franse gebruikers wel Franse productnamen, maar kan het label erboven nog steeds “Product” zijn.
Tot slot voeg je een taaltabel toe met dezelfde taalcodes en koppel je die aan de field parameter. Daarmee kun je met één taalkeuze bepalen welke kolom in je rapport wordt gebruikt, in plaats van dit per visual afzonderlijk in te stellen. Mocht je bijvoorbeeld geen externe tools kunnen gebruiken zoals Translations Builder, dan kun je hetzelfde principe dat je voor de kolommen gebruikt, ook toepassen op measurenamen.
Dezelfde techniek werkt ook voor je measures
Field parameters worden meestal uitgelegd aan de hand van kolommen, maar je kunt er net zo goed measures mee vertalen. Dat is interessant als metadata-vertaling voor jou geen optie is, bijvoorbeeld omdat je geen externe tools mag installeren. In plaats van de measurenamen in het model te vertalen, zet je ze in een field parameter met een vertaalde weergavenaam per taal.
De opzet is identiek aan die voor kolommen. Elke measure krijgt een regel per taal, waarbij alleen de weergavenaam en de taalcode verschillen. De measure zelf blijft ongewijzigd. De laatste waarde is een neutrale interne naam. Die houdt de regels van dezelfde measure bij elkaar, zodat je ze later kunt filteren zonder afhankelijk te zijn van de vertaalde weergavenaam.
Vertaalde measures = {
("Omzet", NAMEOF('Berekeningen'[Omzet]), 0, "nl", "Omzet"),
("Sales", NAMEOF('Berekeningen'[Omzet]), 0, "en", "Omzet"),
("Chiffre d'affaires", NAMEOF('Berekeningen'[Omzet]), 0, "fr", "Omzet"),
("Marge", NAMEOF('Berekeningen'[Marge]), 1, "nl", "Marge"),
("Margin", NAMEOF('Berekeningen'[Marge]), 1, "en", "Marge"),
("Marge", NAMEOF('Berekeningen'[Marge]), 1, "fr", "Marge")
}
Dezelfde measure, drie weergavenamen. De sorteervolgorde is per measure gelijk.
In je visual plaats je vervolgens de field parameter in plaats van de measure zelf. Is de taal Frans, dan toont de visual de Franse naam boven de kolom of in de legenda. De onderliggende berekening verandert niet.
Let op de sorteervolgorde. Het derde getal in elke regel bepaalt de volgorde waarin de measures verschijnen. Geef dezelfde measure in alle talen hetzelfde nummer. Doe je dat niet, dan staan de measures per taal in een andere volgorde en kan Power BI de sortering niet eenduidig bepalen. Bij het verversen krijg je dan een waarschuwing dat de kolom niet gesorteerd kan worden.
Deze aanpak heeft nog een ander voordeel: omdat de vertaling in een tabel staat in plaats van in je modelmetadata, kun je er ook andere logica aan koppelen. Wil je bijvoorbeeld dat gebruikers in de ene markt met liters werken en in de andere met gallons, dan neem je die measures alleen op bij de bijbehorende code. Measures die niet bij die gebruiker horen, verschijnen dan simpelweg niet in de lijst.
Waar kan AI je werk versnellen?
Bij field parameters zit veel herhaalwerk. Voor iedere measure maak je per taal een regel aan. Alleen de vertaalde naam en taalcode veranderen. Met vijftig measures en vier talen kom je al snel op honderden regels DAX. En hoe meer regels, hoe groter de kans dat er ergens een taal ontbreekt of de sorteervolgorde niet klopt.
Daar kan AI je werk versnellen. Geef je vertaaltabel als uitgangspunt mee, met de measurenamen, vertalingen en taalcodes. AI kan daar vervolgens de DAX voor je field parameter van maken. Voeg je later een taal toe? Dan kun je op dezelfde manier de nieuwe regels laten genereren, in plaats van alles handmatig te kopiëren en aan te passen.
Er zijn wel twee dingen om scherp op te blijven. Je bronbestand blijft leidend. Laat AI de DAX-code voor de field parameter altijd genereren vanuit je vertaaltabel en niet vanuit een losse chatsessie. Zo blijft duidelijk waar je vertalingen vandaan komen. Controleer daarna de output. Heeft iedere measure alle talen? Klopt de sorteervolgorde? En gebruikt iedere eenheidsspecifieke measure de juiste taalcode?
Maar waar komt die taalinstelling vandaan?
Dit is de vraag die in veel uitleg blijft liggen. De field parameter kan filteren op “fr”, maar iemand moet die code aanleveren. Daarvoor zijn drie manieren en ze komen alle drie uit op dezelfde taaltabel.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
De handmatige variant
Je zet de taalkolom in een filter in het rapport en zet ‘één selectie verplicht’ aan. Dit is niet de mooiste oplossing, omdat de gebruiker dan zelf de taal moet selecteren.
De automatische variant
Bij gebruikers die rechtstreeks via Power BI toegang hebben tot het rapport, kun je de cultuur van de huidige gebruiker uitlezen met USERCULTURE(). Power BI kan de cultuur van de huidige gebruiker uitlezen met USERCULTURE(). Die functie geeft bijvoorbeeld nl-NL, en-US of fr-FR terug. Wat je met deze waarde doet, hangt af van de variant die je gebruikt. Voor losse teksten kun je hem rechtstreeks in een measure gebruiken, bijvoorbeeld om de juiste visual-titel terug te geven.
Wel geldt hierbij een belangrijke voorwaarde. USERCULTURE() geeft de juiste cultuur terug wanneer je de functie binnen je semantisch model gebruikt, dus in measures, in row-level security of in berekeningsitems. Roep je hem aan van buiten het model, bijvoorbeeld vanuit een measure die in een live-connected rapport is gemaakt, dan is de uitkomst niet betrouwbaar. Zet je vertaallogica dus altijd in het model zelf.
En in een klantportaal?
Daar moet je een onderscheid maken. Als je Power BI-rapporten in je eigen applicatie embedt, is de gebruiker niet noodzakelijk een Power BI-gebruiker met een cultuurinstelling die je op dezelfde manier kunt uitlezen.
In dat geval is het logischer om de taal vanuit je eigen applicatie te bepalen en die informatie te gebruiken bij het laden of filteren van het rapport. Je klantportaal weet immers al of iemand bijvoorbeeld Nederlands, Frans of Engels gebruikt.
Welke aanpak past bij jouw situatie?
De varianten sluiten elkaar niet uit. In de praktijk kunnen ze worden gecombineerd: metadata-vertaling als basis, een vertaaltabel voor je teksten, en field parameters alleen daar waar de data zelf vertaald moet worden.
|
|
|
|
|
|
|
|
|
|
|
|
Waar je rekening mee moet houden
- Vertalen is onderhoud, geen project. Elke nieuwe measure moet worden vertaald. Regel dat proces, en wie het doet, voordat je uitrolt.
- Je field parameter groeit hard. Elke measure krijgt meerdere regels per taal. Split de field parameter op in measure-categorieën.
- Data-vertaling raakt je databron. Er moet een kolom per taal bij. Betrek de beheerder van die bron op tijd. Dit is niet iets wat je alleen in Power BI oplost.
- AI versnelt, maar beslist niet. Laat vertalingen en repetitieve DAX genereren, maar laat het resultaat controleren door iemand die de taal spreekt. Zeker bij rapporten die je met klanten deelt.
Tot slot
Meertaligheid in Power BI is geen kwestie van een vinkje. Maar het is ook geen reden om je rapport vijf keer te bouwen. Met metadata-vertaling, een vertaaltabel en waar nodig field parameters kom je heel ver, en dat allemaal binnen één model dat je één keer onderhoudt.
Deel je rapporten met klanten of leden buiten je organisatie, en loop je tegen taal, eenheden of toegang aan? We denken graag met je mee.
