Gotowe narzędzie do tłumaczenia czy proces na zamówienie
Porównaj istniejące narzędzie do tłumaczenia z procesem na zamówienie. Przed wyborem sprawdź nakład pracy zespołu, weryfikację, obsługę danych, integrację i utrzymanie.
Warto korzystać z istniejącego narzędzia do tłumaczenia, jeśli wykonuje ono Państwa zadanie przy akceptowalnym nakładzie pracy i wystarczającej kontroli. Proces na zamówienie warto rozważyć, gdy konkretna luka powoduje powtarzającą się dodatkową pracę, błędy lub opóźnienia. Przed podjęciem decyzji należy porównać obie opcje na tym samym zadaniu biznesowym.
Informacja handlowa: Vavus sprzedaje oprogramowanie na zamówienie. Ten poradnik wyjaśnia, kiedy taka praca może być przydatna, a kiedy wystarczy istniejące narzędzie. Nie zawiera rankingu dostawców tłumaczeń ani wyników testów wydajności.
Co dokładnie Państwo porównują
Gotowe narzędzie to produkt, z którego korzysta się przez jego istniejący interfejs i ustawienia. Może już obejmować obsługę plików, opcje terminologii lub mechanizmy kontroli dla zespołu. Zamiast zakładać, że takich funkcji brakuje, warto sprawdzić aktualny produkt i plan.
Proces na zamówienie to oprogramowanie zbudowane lub dostosowane do Państwa sposobu pracy. Może łączyć system źródłowy, tłumaczenie, weryfikację i miejsce docelowe. Pod spodem może korzystać z istniejącej usługi tłumaczeniowej. Tworzenie oprogramowania na zamówienie nie musi oznaczać budowania nowego modelu tłumaczeniowego.
Trzecią opcją jest skonfigurowanie konektora lub automatyzacji w oprogramowaniu, którego Państwo już używają. Tę opcję warto uwzględnić w analizie przed zleceniem nowych prac programistycznych.
Istniejące narzędzie do zadania o ograniczonym zakresie
Warto zacząć od standardowego narzędzia, jeśli jedna osoba tłumaczy teksty od czasu do czasu i może sprawdzić wynik przed użyciem. Może ono też pasować do powtarzalnego zadania związanego z dokumentami, jeśli obsługiwane formaty i proces weryfikacji spełniają Państwa potrzeby.
Należy przetestować całe zadanie. Czy pracownik potrafi znaleźć tekst źródłowy, przetłumaczyć go, sprawdzić i umieścić wynik z powrotem we właściwym rekordzie? Warto sprawdzić, czy wynik zachowuje wymaganą strukturę i czy pracownicy mogą stosować właściwe terminy.
Istniejące usługi mogą dawać więcej kontroli niż zwykłe kopiowanie i wklejanie. Na przykład Google Cloud Translation opisuje w dokumentacji funkcję glosariusza dla terminologii branżowej. [1] To funkcja API, a nie obietnica, że każdy interfejs dla użytkowników indywidualnych lub każda subskrypcja ją zawiera.
Jeśli dostępne narzędzie spełnia Państwa wymagania, nie warto bez wyraźnego powodu dodawać systemu na zamówienie.
Praca na zamówienie przy określonej luce w procesie
Proces na zamówienie może być wart rozważenia, gdy pracownicy wielokrotnie przenoszą tekst między systemami lub mają trudności ze śledzeniem zatwierdzeń. Lukę należy opisać w sposób dający się zaobserwować. Na przykład pracownicy mogą musieć kopiować zatwierdzone tłumaczenie z powrotem do właściwego zgłoszenia w systemie wsparcia.
Proponowane oprogramowanie mogłoby przechowywać tekst źródłowy razem z wynikiem, kierować tekst do osoby weryfikującej i zapisywać zatwierdzoną wersję w miejscu docelowym. To możliwe wymagania projektu. Nie są to twierdzenia o istniejącej integracji Vavus.
Najpierw należy sprawdzić, jakie interfejsy obsługuje aplikacja źródłowa. Pożądane połączenie może być ograniczone uprawnieniami dostępu, dostępnymi API lub umową dotyczącą tego systemu. Te ograniczenia trzeba uwzględnić w wycenie.
Warto zapytać, kto będzie utrzymywał połączenie, gdy którykolwiek z systemów się zmieni. Praca na zamówienie to nie tylko początkowa budowa, ale też stała odpowiedzialność.
Osobne porównanie jakości tłumaczenia
Lepszy interfejs może usprawnić weryfikację, ale nie dowodzi lepszego tłumaczenia. Rozważane podejścia należy przetestować na tych samych reprezentatywnych treściach i parach językowych. Warto poprosić wykwalifikowaną osobę o ocenę znaczenia, terminologii i tonu.
Należy sprawdzić, jak każde podejście dostarcza przydatny kontekst. API DeepL ma na przykład parametr kontekstu i opcje glosariuszy. [2] Te ustawienia trzeba skonfigurować i przetestować pod kątem danego zadania.
Podczas weryfikacji tekst źródłowy powinien być dostępny. Warto określić, które błędy blokują publikację i jak zapisywane są poprawki. Należy mierzyć czas do uzyskania zatwierdzonego wyniku, a nie tylko czas otrzymania tłumaczenia maszynowego.
Kontrola i koszt całkowity
Przy każdej opcji warto zapytać, gdzie treści są przetwarzane, kto ma do nich dostęp i co jest przechowywane. Te szczegóły należy potwierdzić dla konkretnej usługi i konfiguracji. Oprogramowanie na zamówienie, które wywołuje API w chmurze, nadal wysyła treści do tej usługi.
Koszty należy porównywać w tym samym okresie. Warto uwzględnić subskrypcje lub zużycie API, weryfikację przez pracowników, wielokrotne wprowadzanie danych, konfigurację, wsparcie i utrzymanie. W przypadku pracy na zamówienie trzeba doliczyć także testy i zmiany w połączonych systemach.
Nie należy zakładać, że automatyzacja zawsze się zwraca. Zadanie o małej skali może nie uzasadniać prac programistycznych. Częste zadanie z mierzalnymi błędami w obsłudze może uzasadniać dokładniejszą wycenę. Zamiast nieudokumentowanego procentu oszczędności warto opierać się na własnych pomiarach.
Małe porównanie przed decyzją
Proszę opisać jedno zadanie, reprezentatywny zestaw testowy i warunki odbioru. Tam, gdzie to możliwe, warto najpierw wypróbować istniejącą opcję. Należy zapisać ręczne kroki, nakład pracy na weryfikację, usterki i każdy rodzaj kontroli, którego nie udało się osiągnąć.
Jeśli pozostaje istotna luka, warto poprosić o konkretną ofertę na zamówienie, która ją rozwiązuje. Funkcje opcjonalne należy trzymać osobno. Trzeba wymagać jasnego wyjaśnienia, co zrobi pierwsze wydanie i jak Państwo to zweryfikują.
Vavus przeprowadza pisemną analizę wstępną dla projektów na zamówienie. [3] Na stronie wyceny mogą Państwo opisać obecny proces i lukę. Przed wyborem warto porównać wynikający z tego zakres z opcją istniejącego narzędzia.