Jak określić zakres integracji tłumaczeń w istniejącej aplikacji firmowej
Zaplanuj tłumaczenie w aplikacji firmowej. Przed zapytaniem o wycenę określ treści, języki, weryfikację, zasady dotyczące danych, obsługę błędów i testy odbiorcze.
Warto zacząć od jednego kompletnego zadania, które Państwa zespół musi wykonywać w innym języku. Następnie należy określić, jak tłumaczenie wpisuje się w to zadanie. Daje to dostawcy oprogramowania lepszą podstawę do wyceny niż prośba o dodanie przycisku tłumaczenia.
Zakres powinien obejmować tekst, ludzi, dane i rezultat. Powinien też wyjaśniać, co się dzieje, gdy tłumaczenie się nie powiedzie. Poniższe kroki pomogą przygotować taki zakres przed wyborem podejścia technicznego.
Wybór jednego procesu na pierwsze wydanie
Proszę zapisać, skąd pochodzi tekst źródłowy i dokąd ma trafić zatwierdzone tłumaczenie. Na przykład pracownik działu wsparcia może potrzebować przeczytać przychodzącą wiadomość i przygotować odpowiedź w języku klienta. To przykładowe wymaganie, a nie opis instalacji Vavus.
Warto wypisać każdy krok: otwarcie wiadomości, zlecenie tłumaczenia, przeczytanie tekstu źródłowego obok wyniku, edycję odpowiedzi i zatwierdzenie jej do wysłania. Należy zdecydować, czy tłumaczenie uruchamia się automatycznie, czy dopiero po wybraniu go przez pracownika.
Pierwsze wydanie powinno być niewielkie. Jeden ekran i jedno jasno określone zadanie biznesowe łatwiej przetestować niż wszystkie pola tekstowe w aplikacji.
Określenie potrzeb dotyczących treści i języków
Proszę sporządzić listę pól wymagających tłumaczenia. Warto rozdzielić krótkie etykiety, tekst swobodny, dokumenty i mowę. Mogą one wymagać innego przetwarzania i innych testów. Należy też wypisać pola, które muszą pozostać bez zmian, takie jak numery zamówień i kody produktów.
Proszę określić języki źródłowe i docelowe, w tym ewentualne warianty regionalne. Warto zanotować typową długość tekstu i przewidywaną dzienną liczbę tłumaczeń. Należy zapytać, jakie pary językowe i formaty wejściowe obsługuje proponowana usługa.
Przy krótkich tekstach kontekst może mieć znaczenie. Na przykład API DeepL do tłumaczenia tekstu obsługuje parametr kontekstu, który może wpływać na tłumaczenie, choć sam kontekst nie jest tłumaczony. Dokumentacja podaje też, że oddzielne fragmenty tekstu w jednym żądaniu nie współdzielą kontekstu. [1] Zakres powinien wskazywać, skąd pochodzi przydatny kontekst.
Terminologia i weryfikacja przez człowieka
Proszę zebrać terminy, których Państwa firma często używa. Warto uwzględnić preferowane tłumaczenia, nazwy produktów i słowa, które mają pozostać bez zmian. Za prowadzenie tej listy powinna odpowiadać jedna osoba.
Niektóre usługi tłumaczeniowe obsługują glosariusze. Google Cloud Translation opisuje swój glosariusz jako słownik niestandardowy zapewniający spójną terminologię branżową. [2] Należy sprawdzić tę funkcję dla konkretnych par językowych i wybranej usługi. Glosariusz nie dowodzi, że cała wiadomość jest poprawna.
Proszę zdecydować, które wyniki wymagają sprawdzenia przez wykwalifikowaną osobę weryfikującą tłumaczenie. Osoba ta powinna mieć dostęp do tekstu oryginalnego. Przed wysłaniem lub opublikowaniem tekstu dla klientów należy przewidzieć wyraźny krok zatwierdzenia.
Zasady dotyczące danych i dostępu
Proszę opisać, jakie informacje obejmuje proces. We wczesnych testach warto używać sztucznych przykładów. Nie należy kopiować prawdziwych danych klientów do wersji próbnej tylko po to, by sprawdzić, czy przycisk działa.
Warto zapytać, gdzie tekst będzie przetwarzany, co aplikacja będzie przechowywać, kto będzie mógł to odczytać i kiedy dane zostaną usunięte. Rozmowa powinna objąć też logi i kopie zapasowe. Należy potwierdzić aktualne warunki dostawcy oraz mechanizmy kontroli dostępne w wybranym planie.
Sam interfejs na zamówienie nie sprawia, że zewnętrzna usługa tłumaczeniowa staje się prywatna lub działa offline. Jeśli projekt wymaga lokalnego przetwarzania, trzeba to zaznaczyć na samym początku i przetestować pod tym kątem cały przepływ danych.
Planowanie na wypadek opóźnień i błędów
Proszę zapisać oczekiwany czas odpowiedzi oraz to, co pracownicy mają zrobić, gdy usługa jest niedostępna. Aplikacja powinna pokazywać jasny stan, na przykład: oczekiwanie, gotowe do weryfikacji lub błąd. Tekst oryginalny musi zostać zachowany.
Warto poprosić programistę o odróżnianie awarii przejściowych od błędów wymagających zmiany. DeepL opisuje na przykład ponawianie prób z opóźnieniem przy błędach przekroczenia limitu żądań, natomiast wyczerpany limit wymaga innej reakcji. [3] Ponawiane żądania nie powinny powodować zdublowanych działań biznesowych, takich jak dwukrotne wysłanie tej samej odpowiedzi.
Należy uzgodnić alerty dotyczące wykorzystania oraz to, kto odpowiada za wsparcie. Porównując koszty projektu, warto uwzględnić opłaty za usługę, utrzymanie i przyszłe zmiany.
Testy odbiorcze przed rozpoczęciem prac
Proszę wybrać reprezentatywne przykłady dla każdej wymaganej pary językowej. Warto uwzględnić długie wiadomości, nietypowe znaki, brakujące pola i terminy z zatwierdzonej listy. Należy przetestować całe zadanie, od rekordu źródłowego do zapisanego lub wysłanego wyniku.
Kryteria zaliczenia powinny dać się sprawdzić: kody produktów pozostają bez zmian, niezatwierdzonego tłumaczenia nie da się wysłać, nieudane żądanie jest widoczne, a osoba weryfikująca może wrócić do tekstu źródłowego. Znaczenie i ton powinna ocenić wykwalifikowana osoba weryfikująca. Usterki należy zapisywać, a po zmianach powtarzać te same testy.
Przygotowanie jasnego zapytania o wycenę
Proszę przesłać opis procesu, przykładowe pola, pary językowe, szacowaną liczbę tłumaczeń, zasady dotyczące danych i testy odbiorcze. Przy każdym elemencie warto zaznaczyć, czy jest niezbędny do uruchomienia, czy może trafić do późniejszego wydania. Założenia i wyłączenia należy uzyskać na piśmie.
Vavus przygotowuje pisemne określenie zakresu dla projektów na zamówienie. [4] Na stronie wyceny mogą Państwo opisać swoją obecną aplikację i zadanie, które chcą Państwo usprawnić. Proponowana integracja, wdrożenie i testy powinny zostać potwierdzone w zakresie projektu.