UX writing i proces lokalizacji ~ Wojciech Aleksander

UX writing i proces lokalizacji ~ Wojciech Aleksander

Osoby projektujące doświadczenia, a zwłaszcza projektujące treści, są odpowiedzialne też za to, jak produkt brzmi we wszystkich językach, w których go udostępniamy. Oczywiście nikt nie wymaga, byśmy nagle uczyli się kilkudziesięciu nowych języków. Natomiast na etapie ideacji, testowania i wdrożenia można dostosować interfejs do doświadczenia  ludzi z różnych kultur. Co zatem robić, aby skutecznie wspierać osoby dopasowujące język produktu przeznaczonego na różne rynki? Jest na to kilka sposobów.

 

Z tego artykułu dowiesz się:

  • Co sprawia, że odpowiedzialność za tłumaczenia spoczywa na barkach osób zajmujących się UX writingiem
  • Dlaczego lokalizacja angażuje wiele osób
  • Jakie rzeczy można i trzeba zrobić podczas projektowania, aby rozwijane usługi były tak samo udane na różnych rynkach

Wprowadzenie


Lokalizacja (L10n, czyt. lajon) to ten element rozwoju produktu, gdzie – mimo że zakończyła się większość prac nad rozwiązaniem problemu projektowego, makietami i dizajnem – UX writing nadal trwa. Kwestia jest złożona, dużo bardziej skomplikowana niż przekazanie tekstu do przetłumaczenia. Decyzja o udostępnianiu produktu w wielu językach, na wielu rynkach jest brzemienna w skutki dla całej organizacji i wszystkich zespołów product development. Wpływa na decyzje architektów systemowych, projektantów i w końcu na strategię treści. Wymaga od nas ponownego przemyślenia procesów, współpracy i nierzadko zmiany fundamentów kodu produktu.

Na potrzeby niniejszego tekstu zakładam, że zatroszczyliśmy się o fundamenty. A zatem internacjonalizacja i eksternalizacja tekstu są już po stronie developmentu załatwione. Nie ma zatem problemu z tym, żeby system dał nam możliwość przełączania języków i pracował w różnych trybach formatowania dat, walut, liczb itp. No i oczywiście, teksty nie są już częścią kodu. Możemy na nich pracować bez interwencji zespołu technicznego. Po stronie biznesu strategia treści i lokalizacji zostały opracowane i wzajemnie się uzupełniają. Wiemy zatem, po co funkcjonujemy na danym rynku i jakie wyzwania kulturowe stoją przed osobami tworzącymi treści.

Dlaczego lokalizacja, a nie tłumaczenie?


W skrócie lokalizacja to proces dostosowania produktu lub usługi do specyfiki konkretnego rynku – to działania zakrojone na szeroką skalę, znacznie wykraczające poza wąskie ramy tłumaczenia tekstu. Aby nam się to udało, musimy wziąć pod uwagę nie tylko język, ale również kulturę, obyczaje i prawo obowiązujące w danym kawałku świata. 
Przykłady świadomej obecności marek na skalę globalną pokazują, że pewne działania, takie jak dodanie postaci do gry w wybranym regionie, wymiana ilustracji w zależności od dominującej w nim kultury czy nawet zmiana nazwy produktu, mają wielki sens.

Po pierwsze, to skomplikowane

W świecie rozwoju oprogramowania nie ma spoczynku. Jedyną pewną rzeczą jest zmiana. Musimy nie tylko zwinnie reagować na potrzeby świata, trzeba również nieustannie optymalizować i weryfikować swoje metody pracy. Lokalizacja to droga. Nie uda nam się bowiem wypracować idealnego rozwiązania, które będzie działać bez potrzeby przebudowy lub poprawek. Lokalizacja to zbiór procesów. To amalgamat technologii, trybów działania (projektowanie, development, QA, wdrożenie, operations itp.), a także ludzi.

Aby udawało się wciąż dostarczać wysoką biznesową wartość, jaką niewątpliwie jest produkt dopasowany do różnych rynków i kultur, trzeba nieustannie o niego dbać. 

Podstawowe zasady udanej współpracy między zespołami produktowymi a zespołem L10n 

  • Ściśle współpracuj z działem lokalizacji lub osobami odpowiedzialnymi za tłumaczenia.
  • Analizuj na bieżąco, dlaczego coś nie działa idealnie (lub tak jak zamierzono).
  • Reaguj natychmiast – wynajduj rozwiązania i od razu je wdrażaj.
  • Nie obawiaj się działania na dużą skalę (oddziaływania na całą organizację).

Pisz od razu z myślą o lokalizacji

Jeżeli Twój produkt dostępny jest w więcej niż jednym języku, fakt ten odciśnie piętno na sposobie, w jakim myślisz o tekście w UI (microcopy). Musi zmienić się też postrzeganie układu graficznych elementów w interfejsie, włącznie z tym, co przedstawiają ilustracje. 

O tym warto pamiętać

Przetłumaczony tekst będzie mieć inną długość niż w języku bazowym. Zwykle staje się dłuższy, zwłaszcza jeśli oryginalne teksty zostały napisane po angielsku.

Tekst CTA po angielsku (Buy now), polsku (Kup teraz), hiszpańsku (Compra ahora) i francusku (Acheter maintenant). Napisy po hiszpańsku i francusku wychodzą poza pole buttonu CTA.
Rys. 1. Ten sam komunikat w każdym języku ma inną długość. Elementy UI niereagujące na takie zmiany będą zawsze zepsute. Aut. Wojciech Aleksander


Tekst w niektórych językach ma zupełnie inny szyk zdania i czasami nietypową (z europejskiego punktu widzenia) interpunkcję. Wartości liczbowe mogą np. pojawiać się jako ostatnie w zdaniu lub po słowie wprowadzającym. Dlatego niektóre wzorce bazujące na szyku zdania nie będą przenośne.

Schemat układu poszczególnych części zdania w dwóch różnych językach
Rys. 2. Składnia języka docelowego może się diametralnie różnić od tej stosowanej w języku bazowym. Źródło: UX writing hub [za:] Chris Jaekl.


Możesz jeszcze bardziej zaprzyjaźnić się z prostym językiem. Jeśli w interfejsie nie ma w ogóle miejsca na sprytne wyrażenia, rymy i słowną ekwilibrystykę, to w interfejsie lokalizowanym jest tego jeszcze mniej1. Prosty język zwiększa również prawdopodobieństwo uzyskania dobrej jakości tłumaczenia maszynowego.

Rozwiązania uniwersalne będą bardziej przyjazne dla wielokulturowych odbiorców, a także łatwiejsze do zarządzania i aktualizacji. Hermetyczne odniesienia, kulturowe żarty, metafory i przysłowia funkcjonujące w jednym kraju z reguły nie są przetłumaczalne i praca nad nimi kosztuje więcej.

Pracuj na zakończonych iteracjach

Materiały, które wysyłasz do tłumaczenia, powinny być jakąś całością – kompletnym krokiem wizarda, całym ekranem, a nawet całym flow. Jeśli tworzysz onboarding, najlepiej lokalizować cały, zamiast posyłać kawałki do przekładu. Jeśli to formularz rejestracji osadzony na stronie, najlepiej tłumaczyć opisy formularza i pozostałe części strony jako całość – tak jak będą na to patrzeć użytkownicy.

To samo tyczy się wdrażania tłumaczeń. Wypuszczaj w świat i testuj zlokalizowane funkcje, używając tego samego sposobu postępowania, jak uprzednio, przy wysyłaniu treści. Dzięki temu znacznie szybciej wychwycisz niespójności lub powtarzające się błędy. Wówczas łatwiej będzie też znaleźć rozwiązanie i zdecydować, czy potrzebna jest parafraza w języku docelowym, powtórne tłumaczenie, zmiana układu strony w zlokalizowanym wariancie produktu czy jednorazowa ingerencja front-end developera.

Wspieraj tłumaczenie najlepiej, jak potrafisz

Dbaj o jasne i bogate informacje o kontekście

Czasy, gdy tłumacze dostawali tabelkę z listą „stringów” do przetłumaczenia, ciągle nie chcą przeminąć. Translatorzy zatem niejednokrotnie trudzą się przy przekładzie, próbując zrozumieć to, czego nie widzą. „Kup teraz, zapłać później” to tekst na przycisk czy nagłówek? Słowa „delete” i „remove” są synonimami czy oznaczają różne czynności? Bez informacji o kontekście danego tekstu tłumaczenie nieraz przypomina dobieranie części garderoby po omacku.

Czasem osobom odpowiedzialnym za prowadzenie projektów wydaje się, że jakość tłumaczenia jest kwestią drugorzędną. Niestety, aby używanie aplikacji miało dla naszych klientów sens, musi ona „gadać” jednakowo dobrze niezależnie od wybranego języka. Internet pełen jest zrzutów ekranu z nietrafionymi tłumaczeniami. Niestety twórcom takich rozwiązań użytkownicy wprost mówią, że produkt jest zepsuty. Klientom nawet przez myśl nie przychodzi to, że to „tylko” tłumaczenie. Myślę, że niejedna osoba pracująca nad aplikacją dostępną w wielu językach zetknęła się z tym, że klienci z jakiegoś kraju ignorują wersję w swoim narodowym języku. Wynika to w dużej mierze z niedostatecznego skupienia na wsparciu osób tłumaczących i braku kontroli jakości tłumaczeń.

Niezbędne minimum działań, dzięki którym znacznie poprawi się komfort pracy osób tłumaczących, a także jakość ich tekstów, można zamknąć w poniższych punktach.

  • Przygotuj dla osób tłumaczących lub działu lokalizacji oprowadzanie po produkcie. Zrób demo nowej funkcji, pokaż, o co w niej chodzi, gdzie ludzie będą klikać, co oglądać. Przedstaw również działanie komunikatów o błędach i to, co mówią.
  • Wysyłaj zrzuty ekranu razem z tekstami do translacji. W przypadku, gdy tłumacze nie mają dostępu do wersji testowej produktu (lub produktu w ogóle) – a to zdarza się dość często – będą mogli zobaczyć, gdzie na ekranie pojawiają się poszczególne frazy, zdania i słowa.
  • Przygotuj i wyślij spis decyzji na temat języka. Wyjaśnij, dlaczego autorzy tekstów wybrali takie, a nie inne słowa i wyrażenia. W przypadku adaptacji interfejsu na inny rynek da to tłumaczom swobodę w działaniu podczas translacji. Albo odwrotnie, narzuci pewien rygor również w tłumaczeniu i będą wiedzieć, dlaczego należy się go trzymać.
  • Zapewne pracujesz nad tym, by język Twojego produktu nie tworzył wykluczeń. Warto również w tej materii wesprzeć osoby tłumaczące. Pomocne będą informacje na temat taktyk pisarskich pomagających uniknąć stosowania końcówek osobowych lub informacje o niepożądanych metaforach i sformułowaniach (np. o niestosowaniu słów kojarzących się z zabijaniem typu terminate lub execute). To są szczególne decyzje w zakresie języka i warto poświęcić im odrębne miejsce w komunikacji z innymi.  
  • Jeśli masz style guide dla języka podstawowego, podziel się nim z tłumaczami. Zrozumieją zasady i założenia strategii treści. Będzie im łatwiej myśleć w sposób podobny do Twojego o tym, co, jak i dlaczego dostarczają.
  • Przygotuj listę rzeczy, których nie należy tłumaczyć. Zawiera ona zwykle takie tematy jak znaki towarowe, nazwy własne produktów i marek. Mogą to być też zapożyczenia z innych języków specjalnie użyte w microcopy.
  • Czasem warto przygotować uproszczoną wersję tekstu w języku źródłowym, pozbawioną kwiecistych metafor, nawiązań kulturowych lub idiomów. Taka opcja light posłuży dobrze w tłumaczeniu na dowolny język i zaoszczędzi czasu na próbach przekładu tam, gdzie można by „zawiesić się” na nieprzetłumaczalnych sformułowaniach.
  • Przygotuj instrukcje, jak łamać zasady. Czasem trzeba. 🙂 Lepiej zrobić to w kontrolowany sposób i wypracować nowe wzorce, niż pozostawić tłumaczących na lodzie, by podejmowali decyzje niezgodne z fundamentem naszej strategii.

Spraw, aby technikalia nie stały nikomu na przeszkodzie

Ważne jest również to, aby kod nie wpływał negatywnie na elastyczność osób piszących i tłumaczących. To, co możemy zrobić w kluczach translacyjnych (fragmentach tekstu wyekstrahowanego z kodu), znacząco wpływa na komfort pracy zarówno podczas tworzenia komunikatów, jak i w trakcie tłumaczenia.

Smartfon z komunikatami:
Rys. 3. Czasem osoby odpowiedzialne za kod kusi, by rozdrobnić coś, co dla nas stanowi jeden komunikat. W tym przypadku każdy element listy mógłby być osobnym kluczem translacyjnym. Z punktu widzenia logiki narracji nie ma to sensu, a osoby tłumaczące, nie widząc interfejsu, mogą pomyśleć, że każda fraza jest osobnym elementem. Może to prowadzić do niespójności stylistycznej lub terminologicznej. Aut. Wojciech Aleksander
  • Zabroń „hardcodowania” czegokolwiek, co jest komunikatem lub tekstem w interfejsie. Wszystko, co opisano w style guide, wartości, teksty, nazwy itp., musi być albo poza kodem, albo przedstawione jako wartości dynamiczne. Pozostawienie treści w kodzie na sztywno wcześniej czy później obróci się przeciwko nam.
  • Namawiaj i ewangelizuj, aby nie dzielić pojedynczych komunikatów na kilka kawałków kodu. Należy zabiegać o to, by nie tworzono kilku kluczy na potrzeby wyświetlenia w interfejsie jednego zdania. Tak będzie prościej nie tylko dla tłumaczących, ale i dla Ciebie.
  • Przekonuj do używania w treści kluczy translacyjnych formatowania inline, a nawet blokowego. Formatowanie typu kursywa, pogrubienie lub listy są zwykle powodem tego, że klucze translacyjne poszatkowane są jak trawa w trakcie sianokosów. Jeśli takie fragmenty komunikatów trafią do tłumaczeń, możemy otrzymać w rezultacie nieoczekiwane formy gramatyczne, a nawet nieadekwatne frazy. Strzępy wyglądają jak bezokoliczniki zdań, tytuły lub zwięzłe etykiety. Połączone w jeden komunikat stają się tak straszne, jak pierwsze drgnięcie monstrum na stole doktora Frankensteina.
  • Perswaduj, żeby w wartościach kluczy translacyjnych można było używać zmiennych (ang. variables). To najlepszy sposób przygotowania na zmiany szyku zdania w różnych językach i jednocześnie zapewnienie sobie integralności komunikatów.

Przykład 1. Użycie zmiennej w microcopy w wersji polskiej i angielskiej.

Wypełnij formularz {{customForm}}, by zakończyć obliczenia 
To finish calculations, fill the {{customForm}} form 

{{customForm}} to nazwa zmiennej. Dzięki jej zastosowaniu osoby korzystające z aplikacji zawsze zobaczą tam tytuł formularza. W trakcie tłumaczenia natomiast będzie można sprawić, by nazwa formularza mogła zmienić swoje miejsce i pasowała do składni docelowego języka.

  • Wypracujcie razem sposób na kodowanie linków. Ważne, aby ustalić, w jaki sposób aplikacja będzie tworzyć URL-e dla wersji zlokalizowanych i jednocześnie wyświetlać tekst linku w odpowiednim języku. Tekst linku to taki sam kawałek tekstu jak każdy inny i nie może powodować, by ktoś w trakcie tłumaczenia stawał na rzęsach. I to wyłącznie z powodu nieelastyczności technologii.
  • Stanowczo domagaj się umożliwienia stosowania liczby mnogiej i pojedynczej. Unikniesz konieczności tworzenia potworków językowych typu „Znaleziono 2 problem(y)”.

 

Przykład 2. Obsługa liczby mnogiej w kodzie.

ONE "W koszyku masz %d bilet."      
FEW "W koszyku masz %d bilety."   
MANY "W koszyku masz %d biletów." 
OTHER "W koszyku masz %d biletów."
ZERO "Koszyk jest pusty."          
  • Wymęcz osoby odpowiedzialne za projekty graficzne, by stosowały bardziej elastyczne zasady w interfejsie. Niech spacing, marginesy czy wielkość obiektów pozwolą interfejsowi pozostać pięknym, nawet gdy długość etykiet, podpisów i instrukcji znacząco zmieni się po tłumaczeniu.

Stwórz roadmapę i procesy

Jak to mawiają w Polsce, nie od razu Kraków zbudowano. Wymieniłem szereg działań na różnych etapach naszych procesów. Być może wszystkie te listy zebrane razem wyglądają przerażająco. Spróbuj po trochu, asynchronicznie. Zaplanuj kolejne kroki. Pomyśl, co ma szansę wydarzyć się w konkretnym czasie. Ten proces się nie kończy i tak czy owak będziesz go usprawniać. Uczymy się wzajemnie od siebie, wzbogacamy arsenał narzędzi, usprawniamy procesy. Obserwuj, jaki wpływ na ludzi lub organizację wywiera to, co udało Ci się wprowadzić. Optymalizuj i nie zapomnij, by zmieniać też siebie. Krok po kroku będziesz bliżej kontroli nad jakością produktu w jego wszystkich odsłonach.

1 Jeśli lubisz teksty z charakterem i budujące silny styl marki, może to brzmieć bardzo restrykcyjnie. Zwróć uwagę, że chodzi o naprawdę wymyślne operacje na słowie.

Inspiracje

Książka 

  • A. Hofmann-Delbor, M. Bartnicka, Programiści i tłumacze. Wprowadzenie do lokalizacji oprogramowania, Gliwice 2017

Autor

Wojciech Aleksander zdjęcie

Wojciech Aleksander

Pracuje jako content strategist i content designer. Wierzy, że słowa tworzą doświadczenie. W świecie cyfrowym działa od ponad 20 lat, a wciąż cieszy go projektowanie treści. Promuje prosty język oraz klarowną komunikację. Ustala procesy wytwarzania treści. Kreuje i opisuje wzorce dla design systemów. Prowadzi warsztaty i szkolenia z UX writingu w całym kraju. Uwielbia kuchnię koreańską, sprzątanie i szum morskich fal.
https://www.waleksander.design
https://www.linkedin.com/in/waleksander/