Gdy tłumaczenie ruszy, pociąg już odjechał. Zakładamy, że struktura dokumenty jest poprawna, segmentacja właściwie dobrana, a po zakończeniu procesu całość zostanie poprawnie przywrócona do formatu źródłowego.
To jednak idealny świat. Im bardziej świat tłumaczeń zbliża się do świata IT, tworzonych nowych usług, apek i serwisów internetowych, tym bardziej odczuwalne będą konsekwencje decyzji podjętych na długo przed tym, zanim dokumenty trafiły do tłumaczenia.
W branży tłumaczeniowej wciąż prym wiodą formaty docx, xlsx, pptx oraz oczywiście pdf. To jednak jedynie fragment większego obrazu. Wszędzie tam, gdzie pojawiają się usługi elektroniczne, pojawią się formaty programistyczne oraz dokumentacyjne. Będą to przede wszystkim xml, jason, yaml, dita, markdown, properties, resx, resw, rc, a rzadziej wprost biblioteki dll czy pliki wykonywalne exe.
Formaty kończące się na *ML to języki znacznikowe, gdzie można w miarę łatwo zauważyć, gdzie dana właściwość tekstu się zaczyna, a gdzie kończy.
Narzędzia CAT całkie nieźle radzą sobie z większością tych formatów. Część z nich, tak jak XML, nie ma zamkniętej listy znaczników, więc każdorazowo trzeba przygotowywać specjalne ustawienia, które powiedzą programowi, jak poprawnie wyodrębnić tekst do tłumaczenia. Z reguły jest to jednak proces możliwy do realizacji.
Prawdziwy problem zaczyna się, gdy formaty przestają być tym, za co się podają. Nic nie stanowi na przeszkodzie, by HTML zapisać jako Markdown, a XML jako JSON, yml jako XML, itd. Tak naprawdę, możliwości jest wiele. Część z nich to wynik pomyłki, a część to praktyka polegają na osadzaniu fragmentów obcego kodu w innym formacie, np. jako cytacie. To częsty zwyczaj w dokumentacji, gdzie warto od czasu do czasu przywołać kod z innego języka.
Część problemów rozwiązują tak zwane filtry kaskadowe, czyli sekwencja filtrów narzędzia CAT. Najpierw program przetwarza plik za pośrednictwem filtru od głównego formatu, a następnie aplikuje dodatkowy filtr dla osadzonych treści (ang. embedded content). Dopóki jest to np. Excel z fragmentami tekstu skopiowanymi wprost z HTML-a, wszystko jest względnie proste.
Proces kontroli jakości źródła to jedyne rozwiązanie, aby uniknąć kłopotów na etapie finalizacji projektu. Tylko rozwiązując problem na etapie projektowania można uniknąć ciężkich bojów z tekstem pełnym artefaktów, pociętych fragmentów czy przyklejonych znaczników.
Przykład z życia: format Markdown z fragmentami JSON-a, z akapitami zapisanymi w HTML i zaszytą w nich błędną segmentacją, a to wszystko z wstawkami z RUBY. Wszystko w jednym pliku, który musi trafić do tłumaczenia. Tak wygląda dzisiejsza rzeczywistość biur tłumaczeń i takim zagadnieniom poświęcamy nasze szkolenia.
