Wraz z Business Central otrzymaliśmy ciekawą nowość w postaci tłumaczeń z wykorzystaniem plików XLIFF. Jest to format znany w innych językach programowania od wielu lat, dzięki czemu dysponujemy sporą ilością gotowych narzędzi. Sam Microsoft przygotował dla partnerów chociażby: „Microsoft Dynamics Lifecycle Services” czy „Azure Translation Text API” (oparte na uczeniu maszynowym). Mimo, iż dysponujemy narzędziami które pozwalają zautomatyzować proces tłumaczenia, zdarza się często, że narzędzia te nie dają zadowalających rezultatów. Dlatego też powstał ten post w którym pokaże jak w sposób obsłużyć tłumaczenia w staromodny „ręczny” sposób.
Jak ręcznie tłumaczyć Extension?
Do pełnego sukcesu potrzebujemy tak naprawdę trzech rzeczy – umiejętności scalania plików tłumaczeń, bazy standardowych tłumaczeń i wygodnego oprogramowania. Baza tłumaczeń zapewni, że większość specyficznych słów używanych w NAV zostanie przetłumaczona poprawnie. Dobry program z kolei będzie potrafił wykorzystać taką bazę do automatyzacji tłumaczeń oraz pozwoli w dość przystępny sposób przetłumaczyć to czego nie udało się przetłumaczyć na podstawie bazy danych.
Włączenie plików tłumaczeń w projekcie
Jeżeli w twoim projekcie nie korzystasz z plików XLIFF możesz je włączyć modyfikując plik app.json dodając opcję “features”: [“TranslationFile”].
Podczas kompilacji tworzony jest plik bazowy tłumaczeń z rozszerzeniem *.g.xlf. Tworząc pierwszą wersję językową należy ten plik skopiować i zmienić „target-language”.
Przygotowanie bazy tłumaczeń Business Central
Myślę, że większość z was wie jak wyeksportować za pomocą Development Environment tłumaczenia systemu, ale niekoniecznie wszyscy zdają sobie sprawę jak uzyskać plik w formacie XLIFF. Moja metoda jest natomiast bardzo prosta i sprowadza się do następujących kroków:
- Przygotowanie bazy Cronus w interesującym nas języku
- Eksport obiektów z bazy do postaci tekstowej (Export-NAVApplicationObject)
- Podział tych obiektów na pojedyncze pliki (Split-NAVApplicationObjectFile)
- Konwersja obiektów do postaci .AL przy pomocy txt2al.exe
Po poprawnie wykonanej konwersji w katalogu z plikami .al powinien znajdować się także plik z tłumaczeniem – przykładowo „translation-pl-PL.xlf”
Uwaga! Jest tylko jeden warunek – należy użyć jednej z ostatni wersji narzędzia Txt2AL.exe. Pierwsze wersje nie tworzyły plików językowych.
Pierwsze tłumaczenie
Może nie tyle polecam co używam od wielu lat programu Poedit. Poza tym, że jest to program darmowy to pozwala on na zaimportowanie własnego słownika tłumaczeń, co pozwala na znaczne uproszczenie całego procesu.
Zanim zaczniemy go używać wypada zaimportować tłumaczenia przygotowane w poprzednim kroku. Aby to zrobić wystarczy wejść w menu File->Preferencse->Translation memory kliknąć Manage i Import translation file.
Tak przygotowany możesz otworzyć swój plik tłumaczeń przygotowany wcześniej i zabrać się za tłumaczenie. Zanim zaczniesz tłumaczyć ręcznie proponuję skorzystać z opcji „Pre-Translate”.
Dopiero później zabierz się za ręczne uzupełnianie brakujących tłumaczeń.
Scalanie plików tłumaczeń
Niestety podczas kompilacji będzie się odświeżał tylko plik bazowy tłumaczeń, co oznacza, że w stworzonym przez Ciebie pliku nie będzie nowych tekstów do przetłumaczenia. Oba pliki trzeba niestety scalić ręcznie. Ja osobiście do scalania plików tłumaczeń używam dodatku do VS Code o nazwie „Angular Localization Helper”. Nie jest to rozwiązanie dedykowane do Business Central co powoduje, że trzeba ręcznie usunąć grupę „Body” w pliku *.xlf aby on zadziałał. Po scaleniu grupę tą trzeba przywrócić.
Zapewne są już dostępne lepsze narzędzia dlatego zachęcam Cię do poszukiwań. Jeżeli znajdziesz coś godnego uwagi to daj proszę znać w komentarzu.
Dopiero po scaleniu obu plików możesz uzupełnić brakujące tłumaczenie, znowu korzystając z wcześniej wspomnianego programu Poedit.
Podsumowanie
Pokazałem Ci kilka kroków i narzędzi, być może coś z tego co napisałem przyda Ci się w pracy z Business Central. Ręczne tłumaczenie może nie jest tym co lubię robić ale nie miałem innego wyjścia bo rezultaty automatycznych tłumaczeń były niezadowalające. Innym wyzwaniem jest także praca w wieloosobowym zespole korzystającym z Gita. Niestety praca na pliku tłumaczeń przez wielu członków zespołu nie jest praktycznym rozwiązaniem ze względu na problemy ze scalaniem plików tłumaczeń. Dlatego w naszym zespole za tłumaczenia odpowiada jedna osoba, która uzupełnia tłumaczenie przed stworzeniem nowego builda. A jak to wygląda u Ciebie?