Wielojęzyczny raport Power BI pozwala udostępnić jedno rozwiązanie użytkownikom z różnych krajów bez utrzymywania osobnych wersji raportu dla każdego języka. To ma znaczenie szczególnie w firmach, w których ten sam model sprzedaży, finansów czy operacji jest używany przez zespoły w Polsce, Niemczech, Francji lub innych lokalizacjach.
Samo przestawienie języka Power BI nie rozwiązuje jednak całego problemu. Interfejs aplikacji, nazwy pól, etykiety raportu i dane tekstowe to różne warstwy. Jeśli chcemy zbudować środowisko wielojęzyczne poprawnie, trzeba zaplanować je osobno.
Co właściwie trzeba tłumaczyć w Power BI?
Rozróżniamy trzy główne rodzaje tłumaczeń. Pierwszy to tłumaczenia metadanych, czyli nazw tabel, kolumn, miar, hierarchii i poziomów hierarchii. Dzięki nim użytkownik może zobaczyć na przykład miarę Sprzedaż netto jako Net Sales albo Nettoumsatz.
Drugi obszar to etykiety raportu: tytuły, opisy sekcji, podpisy przycisków i inne teksty widoczne na stronie. Trzeci to tłumaczenie danych, czyli wartości przechowywanych w wierszach tabeli, na przykład nazw produktów, kategorii albo statusów.
To rozróżnienie jest ważne, bo każda z tych warstw wymaga innego podejścia. Tłumaczenie nazwy kolumny nie przetłumaczy automatycznie wartości znajdujących się w tej kolumnie.
Translations Builder – praktyczne narzędzie do wielojęzycznego Power BI
Do zarządzania tłumaczeniami metadanych istnieje narzędzie Translations Builder. Jest to zewnętrzne narzędzie dla Power BI Desktop, które łączy się z modelem za pomocą Tabular Object Model i pozwala dodawać tłumaczenia w formie czytelnej siatki.
W praktyce można dodać język angielski, niemiecki lub inny język pomocniczy, a następnie uzupełnić odpowiedniki dla tabel, kolumn i miar. Ważny detal: narzędzie modyfikuje model załadowany w pamięci, dlatego po zmianach trzeba wrócić do Power BI Desktop i zapisać plik.
Przykład: jeden raport sprzedażowy dla Polski i Niemiec
Załóżmy, że firma ma jeden model sprzedażowy używany w Polsce i Niemczech. W modelu znajdują się miary Sprzedaż netto, Marża i Liczba zamówień. Dla użytkowników niemieckich dodajemy tłumaczenia nazw tych miar, ale samych obliczeń DAX nie trzeba duplikować.
Tytuł strony „Wyniki sprzedaży” i podpisy przycisków można obsłużyć jako lokalizowane etykiety. Jeżeli natomiast użytkownik ma zobaczyć przetłumaczone nazwy kategorii produktów, źródło danych powinno zawierać odpowiednie wartości językowe, a w raporcie można wykorzystać mechanizm parametrów pól do wyboru właściwej kolumny.
Dzięki temu firma nadal utrzymuje jeden model, jeden zestaw miar i jedną logikę biznesową. Zmienia się sposób prezentacji informacji, a nie definicja KPI.
Język i ustawienia regionalne to nie to samo
W środowisku międzynarodowym trzeba rozróżnić język od lokalizacji użytkownika. Użytkownicy w Stanach Zjednoczonych i Wielkiej Brytanii mogą korzystać z języka angielskiego, ale oczekiwać innego formatu dat i liczb. Power BI rozpoznaje lokalizacje użytkownika, na przykład en-US, en-GB albo de-DE.
W usłudze Power BI można testować raport dodając parametr języka do adresu raportu, na przykład ?language=de-DE. To prosty sposób na sprawdzenie, czy tłumaczenia metadanych są poprawnie wyświetlane bez zmiany ustawień całej przeglądarki.
Warto też pamiętać o formatach dat i liczb. Power BI potrafi uwzględniać ustawienia regionalne przy formatowaniu wartości, dlatego nie należy bez potrzeby zamieniać dat lub liczb na tekst tylko po to, aby wymusić jeden sposób prezentacji.
Czego Power BI nie przetłumaczy automatycznie?
- Dane tekstowe, takie jak nazwy produktów czy statusy, nie są automatycznie tłumaczone.
- Teksty wpisane na stałe w polach tekstowych i przyciskach wymagają osobnej strategii lokalizacji.
- Nazwy kart stron raportu nie są automatycznie lokalizowane, dlatego w bardziej rozbudowanych projektach warto rozważyć własną nawigację.
- Tłumaczenia metadanych i etykiet należy testować w Power BI Service, a nie tylko w Power BI Desktop.
Jak podejść do wdrożenia wielojęzycznego raportu?
Najbezpieczniej zacząć od jednego istniejącego raportu i stworzyć listę elementów, które rzeczywiście muszą być tłumaczone. Najpierw warto uporządkować nazwy tabel, kolumn i miar, później dodać tłumaczenia metadanych, a następnie przejść do etykiet raportu i danych tekstowych.
Nie polecamy tworzenia osobnego pliku PBIX dla każdego kraju, jeśli logika raportu jest taka sama. Na początku wydaje się to prostsze, ale każda nowa miara, poprawka wizualizacji albo zmiana modelu musi być później powielana w kilku wersjach. Jedno rozwiązanie z warstwą tłumaczeń jest zwykle łatwiejsze do utrzymania i ogranicza ryzyko różnic między raportami.
Trzeba również dobrze zaplanować język bazowy modelu, ponieważ nie można go później zmienić, dlatego decyzję warto podjąć świadomie przed rozpoczęciem większego projektu.
Kiedy takie podejście ma sens biznesowy?
Wielojęzyczny Power BI ma największy sens wtedy, gdy różne kraje korzystają z tych samych KPI, definicji i procesu raportowego. Użytkownik otrzymuje raport w swoim języku, ale organizacja nadal zarządza jednym modelem semantycznym i jedną wersją logiki biznesowej.
To zmniejsza koszty utrzymania, upraszcza rozwój raportów i ułatwia kontrolę jakości. Zespół BI może rozwijać jeden produkt analityczny zamiast kilku niemal identycznych kopii.
Podsumowanie
Środowisko wielojęzyczne w Power BI to nie tylko zmiana języka interfejsu. Trzeba osobno zaplanować tłumaczenia metadanych, etykiet raportu i danych tekstowych, a także uwzględnić ustawienia regionalne dat i liczb.
Najbardziej praktyczne podejście to utrzymywanie jednego modelu i jednej logiki biznesowej, a tłumaczenia traktować jako warstwę prezentacyjną. Dzięki temu raport może obsługiwać wiele krajów bez tworzenia osobnych wersji całego rozwiązania.
Polecane źródła
⚡ Planowanie tłumaczeń w wielojęzycznych raportach Power BI
⚡ Tworzenie raportów wielojęzycznych z Translations Builder
⚡ Ustawienia języka i lokalizacji w raportach Power BI