Tłumaczenie bloga c-rex.net za pomocą MT
Scenariusz
Nasze wpisy na blogu c-rex.net są tworzone w oXygen XML Editor w środowisku DITA/XML.
Pliki źródłowe DITA są tłumaczone. I to bezpośrednio, bez użycia systemu pamięci tłumaczeniowej.
Powód wyboru tej konstelacji?
Jesteśmy przekonani, że Machine Translationczłowieka będzie odgrywać kluczową rolę w przyszłości. Dlatego przygotowaliśmy odpowiedni scenariusz tłumaczenia i przedstawiamy go tutaj.
Ten scenariusz z pewnością nie jest odpowiedni dla każdego rodzaju tekstu. Nadal istnieją przypadki użycia, w których tłumaczenie Translation-Memory jest właściwym wyborem.
Jesteśmy bezpieczni: Istnieje znacznie więcej przypadków, niż wielu sądzi, w których proces zautomatyzowany w ten lub podobny sposób, tak jak go wdrożyliśmy, jest właściwy!
Przyjrzyjmy się temu procesowi w szczegółach!
Trzy kliknięcia i tłumaczenie jest gotowe
Zbudowaliśmy środowisko narzędziowe, w którym redaktorzy techniczni przeprowadzają cały proces od tworzenia, przez tłumaczenie, aż po publikację w jednym środowisku.
Wszystko z jednego źródła z bardzo wysokim poziomem automatyzacji!
Gdy wpis na blogu w języku niemieckim jest gotowy, uruchamiamy wstępnie skonfigurowane scenariusze transformacji, które wykonują cały proces tłumaczenia w ciągu kilku sekund.
Następnie przenosimy przetłumaczone pliki do folderu języka docelowego.
Po tym następuje publikacja HTML - również oparta na przygotowanym przez nas scenariuszu transformacji.
O tym, co kryje się za tą "magią", jakie automatyczne procesy się za nią kryją, przeczytasz w kolejnych sekcjach.
Nasze środowisko redakcyjne
Jak działa nasz proces tłumaczenia MT? Jakie narzędzia są używane?
Edytor XML Oxygen XML Editor
DITA-OT c-rex.net do rozszerzenia DITA-OT Frameworks
nasza usługa w chmurze Data Transformation Service DTS
Machine Translation Engine DeepL
Pracujemy z następującymi narzędziami:
Gromadzenie i organizacja danych za pomocą DITA-OT-Plug-ins
Używamy samodzielnie opracowanych wtyczek, które rozszerzają DITA-OT-Framework w celu gromadzenia, organizowania i kompilowania danych, tak aby można je było następnie przetwarzać za pomocą c-rex.net DTS.
Wtyczki te płynnie integrują funkcjonalność i dostęp do usługi w chmurze DTS ze standardowymi procesami DITA.
Są one dostępne dla naszych klienci jako standardowe rozszerzenia dla DTS do zastosowania w istniejących DITA-OT OT po zakończeniu fazy testowej.
Zbierz pliki do przetłumaczenia. W naszym przypadku odniesienia są ignorowane (xref, conref, grafika). W razie potrzeby zachowanie to można dostosować, konfigurując interfejs.
Rozpakowywanie plików
Wysyłanie pakietów zip do usługi c-rex.net Data Transformation Service DTS
W naszym przypadku DTS tłumaczy pliki za pośrednictwem DeepL i zwraca przetłumaczony pakiet zip.
Oczywiście można również zintegrować alternatywne Machine Translation Engines, takie jak Google, Bing lub inne.
Pakiet Zip zawiera
raport
Pliki XLIFF w języku źródłowym
dwujęzyczne pliki XLIFF z językiem źródłowym i tłumaczeniami DeepL
przetłumaczone DITA-XML(w naszym przypadku bez grafiki i powiązanych tematów)
Rozpakowywanie wyniku tłumaczenia
Skopiuj zależne zasoby do katalogu wyjściowego, aby DITA-Map była ponownie kompletna.
Proces gromadzenia i organizacji danych przebiega następująco:
Proces tłumaczenia na serwerze DTS
Generowanie XLIFF dla każdego pliku do przetłumaczenia
Oznaczanie tłumaczenia zgodnie z ITS Rules
Custom Rules można określić we DITA-OT-Plug-in.
Segmentacja jednostek tłumaczeniowych na podstawie SRX Rules
Custom Rules można określić we DITA-OT-Plug-in.
Rozdzielczość zmiennych w postaci zwykłego tekstu
W przypadku DeepL rozwiązujemy zmienne (keyrefs) i wprowadzamy je do tłumaczenia wraz z tłumaczonym tekstem. Okazało się to przydatne dla DeepL w celu podniesienia jakości tłumaczenia, szczególnie w zakresie gramatyki.
Jeśli ich nie określisz i zdefiniowałeś termin płci w liczbie mnogiej, DeepL zwróci tłumaczenie dla liczby pojedynczej, na przykład.
Inne Machine Translation Engines zachowują się tutaj inaczej; dlatego zachowanie w tych i innych punktach jest konfigurowalne.
Automatyczne etykietowanie określonej zawartości
Dla ważnego tematu terminologii korporacyjnej stworzyliśmy bazę terminologiczną w naszym środowisku edycyjnym, w której przechowujemy terminy, cytaty i inne teksty wraz z wymaganym tłumaczeniem.
Można to również zrobić za pomocą zmiennych. Zdecydowaliśmy się jednak użyć terminologicznej bazy danych w formacie tbx.
Prawidłowe tłumaczenie tych terminów ma kluczowe znaczenie. Uważamy nawet, że jest to ważniejsze niż prawidłowe tłumaczenie otaczającego go tekstu.
Szukamy tych terminów na tym etapie procesu i automatycznie je oznaczamy, aby można było się nimi odpowiednio zająć w procesie tłumaczenia.
W ten sposób nikt nie musi się o to martwić podczas tworzenia.
Przygotowanie danych dla DeepL
Wsparcie dla danych strukturalnych jest podstawowe w DeepL, mimo że DeepL ma przełącznik konfiguracji dla XML. Jednakże, nie jest przetwarzany XML jako taki, ale minimalnie inne procedury sprawdzania są używane w zwykłym tekście.
W związku z tym rozwiązujemy głęboko zagnieżdżone struktury XML w DITA i w wynikowych XLIFF-ach w zakresie, w jakim ciąg jest generowany tak blisko, jak to możliwe, do optymalnego zwykłego tekstu i przekazywany do DeepL w celu tłumaczenia.
Ogranicza to do minimum możliwe źródła błędów podczas obsługi znaczników.
Przekazujemy również treści, które nie mają być tłumaczone, takie jak zmienne, do DeepL, dzięki czemu DeepL ma pełny kontekst tłumaczenia, a tym samym zapewnia dobre tłumaczenie.
Zawartość przetłumaczona maszynowo jest zapisywana w elemencie "target" w XLIFF.
Eksport XLIFF z powrotem do DITA
W drodze powrotnej treść, która nie ma zostać przetłumaczona, jest ponownie zastępowana tekstem w dokumencie źródłowym. Dotyczy to również zmiennych i automatycznie oznaczonej zawartości.
W ten sposób usuwamy teksty w "keyrefs" i zastępujemy termin przetłumaczony przez DeepL w automatycznie oznaczonej treści ponownie tekstem z termbase tbx.
To czasami prowadzi do problemu, że słowo lub cudzysłów są usuwane, ponieważ DeepL zapisuje je w tagach, a my nadpisujemy je podczas procesu zastępowania.
Na koniec dokument DITA jest odbudowywany z zawartości elementu target za pomocą Skeleton.
Usługa c-rex.net Data Transformation Service wykonuje następujące operacje:
Reprezentacja tłumaczenia na blogu c-rex.net
Opcja wyboru wariantów tłumaczenia jest zintegrowana z naszym blogiem.
automatyczne tłumaczenie przez DeepL,
wariant stworzony przez automatyczny post-processing przez c-rex.net
oraz prezentację porównawczą obu wariantów.
Do wyboru są następujące opcje
Podsumowanie i perspektywy
Podsumujmy. Co pokazało nam spojrzenie zza kulis?
Zastosowanie DITA-OT OT i wynikająca z tego integracja DTS Cloud Usługi ze standardowym procesem DITA prowadzi do wysokiego stopnia automatyzacji i bardzo szybkich wyników tłumaczenia.
Praca z bazą terminologiczną w celu zapewnienia terminologii korporacyjnej, ważnych terminów, cytatów z ustalonym tłumaczeniem jest niezbędna.
Jakość tłumaczenia jest dobra. Są pewne nieprzyjemności, a także błędy, ale możemy z nimi żyć. Mamy nadzieję, że nasi czytelników również!
W jaki sposób Machine Translation jest odpowiednie dla naszego bloga?
Opisany tutaj scenariusz jest również bardzo odpowiedni dla obszaru dokumentacji technicznej.
Istnieją bowiem zarówno treści, które muszą w 100% spełniać standardy jakości, jak i takie, które tego nie wymagają.
Metadane, zwłaszcza w przypadku korzystania z CCMS lub DITA, mogą być używane do kontrolowania procesu i oddzielania tłumaczenia krytycznych treści (instrukcje bezpieczeństwa, teksty prawne) od tłumaczenia reszty tekstu.
Krytyczne treści w takim scenariuszu nigdy nie przechodziłyby przez proces MT i zawsze przez Translation-Memory z tłumaczeniem ludzkim.
W innych przypadkach można to połączyć, najpierw za pomocą MT ze względu na czas realizacji (użytkownicy czekają na informacje), a następnie za pomocą procesu tłumaczenia przez człowieka ze względu na wymóg wysokiej jakości.
A co z Machine Translation w dziedzinie dokumentacji technicznej?