Importuj swoje dotychczasowe tłumaczenia

Większość zespołów nie zaczyna z pustymi rękami. Mają już gotową aplikację z tekstami po niemiecku i francusku, instrukcję przetłumaczoną w zeszłym roku czy grę dostępną w czterech wersjach językowych. Ponowne tłumaczenie tego wszystkiego kosztowałoby sporo Wörter, a co gorsza – oznaczałoby utratę już zatwierdzonego słownictwa. Transept pozwala na ich import: istniejące tłumaczenia są przejmowane, a nie generowane na nowo.

Mechanizm ten opiera się na imporcie tabeli ciągów znaków (.tstrings.json), opisanym w sekcji Automatyzacja Transept za pomocą API. Każdy ciąg jest jednostką ze stałym kluczem i może zawierać przypisane już tłumaczenia – mapę targets z jednym wpisem na język (lub pojedynczy target, gdy plik jest przypisany do jednej lokalizacji). Podczas importu każde z nich staje się aktywnym tłumaczeniem dla danego języka i zostaje zapisane bezpośrednio w systemie. Nie jest wywoływany żaden model, a żadne Wörter nie są naliczane – praca została już wykonana, Transept po prostu ją przejmuje.

Importowanie tłumaczeń służy nie tylko oszczędności na kosztach ponownego przekładu. Każda para wprowadzona przez seeding jest indeksowana w pamięci tłumaczeniowej tak samo jak nowo wygenerowany tekst, dzięki czemu Twoja pamięć jest zasilona od pierwszego dnia – gdy następnym razem pojawi się podobny fragment, Transept wykorzysta sformułowania wybrane przez Ciebie, a nie przypadkowy domysł. Twoje Glossare i Stilrichtlinien nadal obowiązują w przypadku wszystkiego, co wymaga tłumaczenia, więc nowe i zmienione ciągi znaków będą spójne z tymi, które już zaimportowano.

Gdy korpus znajdzie się już w systemie, możesz go aktualizować, przesyłając ponownie cały aktualny plik przy każdej zmianie. Transept porównuje go według kluczy: niezmienione ciągi zachowują swoje tłumaczenia (oraz status ewentualnej weryfikacji), a tłumaczone są wyłącznie faktycznie nowe lub zmienione jednostki. To to samo zachowanie typu Uruchamiaj tylko dla zmian, z którego korzysta edytor, tyle że po stronie API. Poprawienie jednego ciągu w pliku zawierającym ich setki kosztuje tyle, co jeden ciąg, a nie setki.

Tłumaczenie wprowadzone przez seeding musi być faktycznym przekładem źródła, a nie przypadkową wartością, która mogłaby spowodować błąd przy eksporcie. Dlatego każdy importowany element jest sprawdzany pod kątem symboli zastępczych tekstu źródłowego – pól typu {name}, które muszą pozostać nienaruszone. Jeśli symbole zastępcze w tekście docelowym nie zgadzają się z tymi w źródle, dana jednostka zostanie pominięta i zaraportowana, zamiast zostać po cichu zaakceptowana; pozostałe elementy zostaną zaimportowane normalnie. Wynik importu informuje o liczbie zaimportowanych i pominiętych tłumaczeń wraz z przykładowymi powodami błędów, dzięki czemu wadliwy eksport wyjdzie na jaw, zamiast zostać przeoczonym. (Kontrola ta dotyczy tabel ciągów znaków w formacie ICU, w których nawiasy klamrowe są faktycznymi symbolami zastępczymi; w zwykłych tabelach nawiasy są traktowane jako tekst dosłowny i pozostawiane bez zmian).