Jak jednoosobowa agencja treści dostarcza wielojęzyczne strony bez tłumacza
By Robert M
Jak jednoosobowa agencja treści dostarcza wielojęzyczne strony bez tłumacza
Klient pyta, czy możesz dostarczyć ich nową stronę w języku angielskim, francuskim, niemieckim, hiszpańskim i niderlandzkim. Prowadzisz jednoosobową działalność. Nie masz budżetu na tłumaczenia w ramach swojej umowy retencyjnej i nie masz sieci freelancerów-tłumaczy na wezwanie. Ale też nie chcesz odmawiać dobrego projektu.
To sytuacja, w której często znajdują się małe agencje i freelancerzy. Zapotrzebowanie na strony wielojęzyczne stale rośnie, ponieważ coraz więcej firm próbuje dotrzeć do odbiorców poza swoim rynkiem macierzystym, ale rozmowy o budżecie nie nadążają. Klienci często traktują tłumaczenia jako pozycję kosztową, którą można zmniejszyć lub wyciąć, nie rozumiejąc naprawdę, ile kosztuje ich prawidłowe wykonanie.
Ten wpis dotyczy tego, jak praktycznie poradzić sobie z tą luką, nie rezygnując z jakości ani nie ponosząc strat na projekcie.
Stare opcje i dlaczego zawodzą
Tradycyjne ścieżki są znane.
Możesz zatrudnić freelancera tłumacza na każdy język. Dla strony w pięciu językach z trzydziestoma stronami treści, czeka cię znaczny koszt, zanim uwzględnisz rundy poprawek, czas realizacji i koszty związane z briefowaniem pięciu różnych osób na temat tonu i terminologii klienta. Ten koszt albo zjada twoją marżę, albo trafia na fakturę klienta i nagle projekt jest zagrożony.
Możesz użyć narzędzia do tłumaczenia konsumenckiego i ręcznie je poprawić. To działa dla prostych zdań, ale w momencie, gdy twoja treść ma jakąkolwiek strukturę (plik lokalizacyjny JSON, wpis na blogu Markdown, strona HTML z atrybutami i tagami), wynik staje się nieprzewidywalny. Klucze są tłumaczone. Składnia Markdown się psuje. Atrybuty HTML są zniekształcone. Kończysz spędzając więcej czasu na poprawianiu wyniku niż zaoszczędziłeś, nie zatrudniając tłumacza.
Możesz powiedzieć klientowi, że wielojęzyczność jest poza zakresem i zrobić stronę w jednym języku. Czasem to właściwa odpowiedź. Ale nie zawsze jest to rozmowa, którą chcesz prowadzić.
Co się faktycznie zmieniło
To, co uczyniło ten workflow wykonalnym, to nie jest tłumaczenie AI w abstrakcie. To jest zachowanie formatu w szczególności.
Problem z podawaniem ustrukturyzowanej treści do narzędzia do tłumaczenia ogólnego przeznaczenia nigdy tak naprawdę nie był jakością tłumaczenia. Nowoczesne tłumaczenie maszynowe jest dobre. Problem polegał na tym, że narzędzia nie rozumiały różnicy między treścią a strukturą. Traktowały wszystko jako tekst do przetłumaczenia, w tym części, które powinny pozostać nietknięte.
Plik lokalizacyjny taki jak ten:
{
"nav": {
"home": "Home",
"about": "About us",
"contact": "Get in touch"
}
}
Wracałby z przetłumaczonymi kluczami, zniszczonym zagnieżdżeniem lub całością przekonwertowaną na prozę. Każdy z tych wyników oznacza ręczne czyszczenie przed użyciem pliku, co powoduje utratę oszczędności czasu.
API, które traktuje strukturę jako niedostępną, zmienia ekonomię. Wysyłasz plik, otrzymujesz z powrotem identyczną strukturę z jedynie zmienionymi wartościami tekstowymi. Wrzucasz plik wynikowy bezpośrednio do projektu. Nie jest potrzebne żadne czyszczenie.
Workflow w praktyce
Tak wygląda proces w rzeczywistym projekcie.
Na etapie tworzenia treści wszystko trafia do plików tekstowych lub Markdown zamiast do zakodowanych na stałe ciągów znaków. To dobra praktyka dla utrzymania, ale także oznacza, że treść jest w formacie, który można czysto przetłumaczyć.
Na etapie budowy krótki skrypt odczytuje plik w języku źródłowym, wysyła go do API PolyLingo z listą języków docelowych i zapisuje jeden plik wyjściowy na locale. Dla strony potrzebującej pięciu języków to jedno wywołanie API. Skrypt działa kilka sekund. Pliki wyjściowe trafiają bezpośrednio do struktury projektu.
Na etapie przeglądu klient przegląda przetłumaczoną treść. To krok wart zachowania. Tłumaczenie maszynowe radzi sobie dobrze z większością treści, ale klienci czasem mają preferowaną terminologię, frazy markowe lub konwencje regionalne, które wymagają ludzkiego oka. Przegląd jest szybszy niż tłumaczenie od zera, ponieważ struktura jest już poprawna, a większość treści dokładna. Przeglądasz, a nie tworzysz.
Na etapie przekazania strona jest dostarczana ze wszystkimi plikami locale na miejscu. Przełącznik języka działa od pierwszego dnia. Nie ma nic do uzupełnienia.
Koszty w porównaniu z zatrudnieniem tłumaczy
Liczby zależą od wielkości projektu, ale struktura porównania jest spójna.
Typowa mała strona biznesowa może mieć około 2 000 słów tekstu interfejsu i treści stron. Przetłumaczone na pięć języków to około 10 000 słów wyjściowych. Przy średniej stawce freelancera tłumacza mówimy o kilkuset funtach lub dolarach przed poprawkami.
Z PolyLingo 2 000 słów treści w pięciu językach docelowych mieści się komfortowo w płatnym planie Starter za 9 USD miesięcznie, w tym pojemność na wiele projektów w tym samym okresie rozliczeniowym. Darmowy poziom (50 000 tokenów miesięcznie) pokrywa mniejsze projekty bez żadnych kosztów.
Klient nadal dokonuje przeglądu, co oznacza, że jest zaangażowany w jakość wyniku, a nie tylko otrzymuje rachunek. To zwykle lepiej przyjmowane w rozmowach o projekcie.
Rozmowa o zakresie z klientami
Jedna zmiana, którą umożliwia ten workflow, to zmiana sposobu, w jaki rozmawiasz o zakresie wielojęzyczności z klientami.
Wcześniej „wielojęzyczność” oznaczała „droższe, dłuższy harmonogram, zależność od stron trzecich”. Teraz jest to bliższe decyzji konfiguracyjnej. Określasz zakres, uruchamiasz skrypt, klient przegląda. Trudna część to strategia treści i architektura strony, nie logistyka tłumaczeń.
To zmienia to, co możesz zaoferować. Klient, który planował uruchomienie w jednym języku z niejasnym planem dodania języków później, może zrobić wszystkie pięć przy uruchomieniu bez podwajania kosztów projektu. Klient, który ciągle dodaje strony, może ponownie uruchomić skrypt, gdy zmienia się treść, zamiast wracać do tłumacza z nowym briefem.
To także zmienia rozmowę o tym, co faktycznie oznacza wielojęzyczność. Zadaniem agencji jest zbudowanie strony z odpowiednią architekturą i18n, dobrą kopią w języku źródłowym i procesem przeglądu tłumaczeń. To rozmowa o wyższej wartości niż „załatwimy tłumaczenia, gdy wersja angielska będzie gotowa.”
Gdzie nadal ma sens używanie tłumaczy ludzkich
Warto być w tej kwestii szczerym.
Dla tekstów marketingowych, które muszą nieść prawdziwą emocjonalną wagę w języku docelowym, wykwalifikowany tłumacz ludzki wyprodukuje lepszy wynik. Różnica ma największe znaczenie dla kampanii, oświadczeń o pozycjonowaniu marki i wszystkiego, gdzie samo sformułowanie jest produktem.
Dla treści silnie regulowanych (prawnych, medycznych, finansowych) tłumacz ludzki z wiedzą specjalistyczną jest właściwym wyborem i często wymogiem zgodności.
Dla długich treści redakcyjnych, gdzie głos musi brzmieć naturalnie, a nie być przetłumaczony, przegląd ludzki to coś więcej niż lekka kontrola.
Opisany tutaj workflow najlepiej nadaje się do tekstów interfejsu, treści stron, opisów produktów, dokumentacji i stron marketingowych, gdzie dokładność i integralność strukturalna są ważniejsze niż niuanse stylistyczne. To obejmuje dużą część tego, co mała agencja faktycznie dostarcza.
Jak zacząć
Darmowy poziom PolyLingo obejmuje 50 000 tokenów miesięcznie bez wymogu karty kredytowej. Dla małej agencji pokrywa to znaczną ilość treści, zanim trzeba pomyśleć o płatnym planie.
API akceptuje czysty tekst, Markdown, JSON i HTML. Tłumacz bez kodu w panelu sterowania obsługuje jednorazowe zadania bez dotykania API, co jest przydatne podczas sesji przeglądu klienta, gdy chcesz pokazać przetłumaczony wynik bez wcześniejszego budowania czegokolwiek.