Lokalizacja dużego i elastycznego oprogramowania: studium przypadku firmy Kaspersky

Kierowanie pracami lokalizacyjnymi w dużej firmie produkującej oprogramowanie jest samo w sobie wyzwaniem. Co się dzieje, gdy firma ta przechodzi na praktyki Agile? Wyzwania stają się jeszcze większe i trzeba szybko wprowadzić drastyczne zmiany. W niniejszym studium przypadku Ekaterina Galitskaya i Darya Egorushkina z zespołu dokumentacji i lokalizacji firmy Kaspersky opowiadają o swojej drodze do zwiększenia wydajności i efektywności procesów dzięki Smartcat.

Dalsza część tekstu autorstwa Ekateriny i Darii

Nasz zespół jest odpowiedzialny za tworzenie i lokalizację zarówno tekstów interfejsu użytkownika, jak i artykułów centrum pomocy dla aplikacji firmy związanych z bezpieczeństwem urządzeń mobilnych. Poniżej opiszemy, w jaki sposób rozpoczęliśmy lokalizację aplikacji Mobile Security w sposób bardziej niezawodny, elastyczny i zautomatyzowany. Zaczniemy od problemów, które skłoniły nas do wprowadzenia zmian, a następnie przedstawimy wyzwania, przed którymi stanęliśmy, oraz rozwiązania, które opracowaliśmy. Mamy nadzieję, że ten artykuł będzie interesujący dla wszystkich średnich i dużych firm programistycznych, które stoją przed wyzwaniem wdrożenia metodyki Agile nie tylko w procesie rozwoju oprogramowania, ale także we wszystkich powiązanych aspektach.

Podobnie jak wiele innych firm, Kaspersky w pewnym momencie przeszedł na metodykę programowania Agile. Naturalnie doprowadziło to do znacznego skrócenia cyklu wydawniczego. Jeśli wcześniej nowe wersje aplikacji pojawiały się co kilka miesięcy, teraz było to raz na dwa tygodnie. Co prawda w każdej nowej wersji było mniej ciągów znaków, ale to nie pomagało: nadal musieliśmy poddawać te kilka ciągów znaków całemu procesowi lokalizacji i testów językowych, mając do dyspozycji znacznie krótsze terminy.

Istnieje również powszechne błędne przekonanie, że aplikacje mobilne zawierają tylko niewielką ilość tekstu. Chcielibyśmy, żeby tak było! W naszym przypadku, na przykład, mieliśmy średnio około 25 000 słów na aplikację tylko w tekstach interfejsu użytkownika, pomnożonych przez około 10 aplikacji i około 20 języków docelowych dla każdej aplikacji. Do tego dochodziły nowe teksty interfejsu użytkownika i dokumentacji, które pojawiały się co tydzień.

W rezultacie lokalizacja stała się zasadniczo wąskim gardłem w całym procesie wprowadzania produktu na rynek. Jeśli wcześniej menedżerowie produktu nie znali nawet imion członków zespołu lokalizacyjnego — bo po co mieliby je znać, skoro wszystkie tłumaczenia pojawiały się „jak za dotknięciem czarodziejskiej różdżki”? — to teraz byli świadomi wszystkich związanych z tym problemów na znacznie głębszym poziomie, niż kiedykolwiek by tego chcieli.

W firmie Kaspersky proces lokalizacji składa się zazwyczaj z dwóch etapów: tłumaczenia i testów językowych.

Ogólnym problemem na etapie tłumaczenia było to, że wymagało ono zbyt wiele pracy ręcznej, zarówno ze względu na stosowany proces, jak i ograniczenia narzędzia CAT. W szczególności:

• Ponieważ nie obsługiwano wielogałęziowych potoków, musieliśmy ręcznie tworzyć delty do tłumaczenia, a następnie przesyłać je z powrotem do gałęzi.

• Nie można było zapewnić spójności między aplikacjami i językami.

• Nie mogliśmy wykonywać dodatkowych tłumaczeń równolegle, np. jeśli teksty źródłowe uległy zmianie w trakcie procesu. Zamiast tego musieliśmy czekać, aż podstawowy pakiet tłumaczeniowy będzie gotowy, a dopiero potem przystępować do tłumaczenia dodatkowych tekstów.

• Coraz większym problemem stawały się błędy w kompilacji spowodowane „nietłumaczalnymi” elementami, nieeskapowanymi apostrofami i innymi błędami ludzkimi.

Jeśli chodzi o etap testowania językowego, może on trwać nawet dwa tygodnie, w porównaniu z trzema do pięciu dniami, które zajęło samo tłumaczenie. „Czym właściwie jest testowanie językowe?”, zapytacie.

Głównym celem testów językowych jest sprawdzenie całego tłumaczenia w kontekście. Dysponujemy solidnym zespołem tłumaczy, którzy dobrze znają naszą terminologię. Jednak tłumaczenie tekstu bez uwzględnienia kontekstu, a nawet bez wiedzy, czy jest to przycisk, czy nagłówek, może szybko doprowadzić do niepożądanych rezultatów.

Testowanie językowe polega więc na ręcznym sprawdzaniu wszystkich ekranów aplikacji, zazwyczaj za pomocą zrzutów ekranu. Pomaga to zidentyfikować takie problemy, jak

• Tekst jest zbyt długi dla rozmiaru elementu ekranowego. Czasami może to mieć konsekwencje prawne, jeśli pominięty tekst zawiera zastrzeżenia lub informacje finansowe.

• Tekst pozostawiony bez tłumaczenia, albo z powodu błędu tłumacza, albo dlatego, że został zakodowany na stałe, zamiast zostać wyeksportowany jako string,

• Tekst przetłumaczony w niewłaściwym kontekście, np. gdy tekst na przycisku — np. „Pobierz” — jest gramatycznie imperatywem zamiast bezokolicznikiem.

Samo wykonywanie zrzutów ekranu zajmowało ogromną ilość czasu. Na przykład, jeśli nowa funkcja obejmowała 40 ekranów interfejsu użytkownika, a było 20 języków docelowych, mogło to zająć nawet 70 godzin ręcznej, mechanicznej, żmudnej pracy.

Ogólnie rzecz biorąc, można było się z tym pogodzić, gdy nowe wersje pojawiały się co trzy miesiące. Jednak przy wydawaniu nowych wersji co dwa tygodnie zaczęło to mieć negatywny wpływ na zespół lokalizacyjny. Trzeba było to naprawić i to szybko.

1. Zatrudnić pracowników z niewielkim doświadczeniem i zmniejszyć ilość pracy związanej z lokalizacją — co naturalnie prowadzi do spadku jakości, LUB
2. Zautomatyzować proces.

Zdecydowaliśmy się na to drugie rozwiązanie.

Przy wyborze rozwiązania CAT/TMS nasze główne priorytety były następujące:

1. Mniejsza liczba wewnętrznych zatwierdzeń — zatwierdzanie budżetów, generowanie kluczy seryjnych i tym podobne czynności,

2. Gotowe do użycia podstawowe funkcje — abyśmy mogli zacząć z niego korzystać od razu, bez czekania na opracowanie dodatkowych funkcji,

3. Niewielkie wymagania sprzętowe serwera — ponownie, aby uniknąć długotrwałych procesów zatwierdzania,

4. Niedrogi, najlepiej bezpłatny dostęp do usługi.

5. Odpowiednie wsparcie ze strony serwisu, aby nie trzeba było zatrudniać wewnętrznego programisty,

6. Wymagania bezpieczeństwa — to my łączymy się z serwisem, a nie odwrotnie,

7. Obsługa wielu gałęzi — aby tłumaczyć kilka funkcji jednocześnie,

8. Dodatkowe tłumaczenia możliwe równolegle z oryginalną partią.

Kiedy stworzyliśmy krótką listę opcji, pozostały nam tylko dwie nazwy: Smartcat i Zing, serwer ciągłej lokalizacji od twórców Evernote.

Zing spodobał nam się ze względu na możliwość dostosowania do indywidualnych potrzeb, bezpłatny pakiet instalacyjny i prywatny dostęp — mogliśmy go hostować w ramach naszej własnej organizacji. Minusem było to, że proces instalacji nie był łatwy, więc wdrożenie wszystkich naszych tłumaczy i pracowników spowodowałoby zbyt wysokie koszty czasowe związane z obsługą usługi.

Wybór padł więc na Smartcat. Ponieważ nie możemy podłączać narzędzi CAT bezpośrednio do naszego wewnętrznego systemu kontroli wersji (VCS), zdecydowaliśmy się skorzystać z pakietu Smartcat–Serge. (Serge to oprogramowanie typu open source, które synchronizuje ciągi znaków między systemami kontroli wersji a systemami zarządzania tłumaczeniami. Identyfikuje ciągi znaków w plikach różnych formatów i konwertuje je do standardowego formatu PO, a następnie przekazuje do Smartcat. Możemy zainstalować je bezpośrednio na naszych serwerach, dzięki czemu żadne z naszych poufnych informacji nie trafiają na zewnątrz).

Oto, co najbardziej nam się podobało w powstałym rozwiązaniu:

• Spełnia wszystkie nasze wymagania: wielogałęziowe potoki, dodatkowe tłumaczenia, bezpieczeństwo itp.

• Otrzymujemy aktualizacje na bieżąco, bez konieczności pobierania lub instalowania czegokolwiek,

• Możemy tworzyć własne schematy parsowania ciągów znaków dzięki pakietowi Smartcat–Serge,

• Możemy rozmawiać z tłumaczami pracującymi nad naszymi dokumentami bez opuszczania platformy,

• Możemy znaleźć freelancerów bezpośrednio na platformie, jeśli kiedykolwiek zajdzie potrzeba zwiększenia produkcji,

• Możemy płacić za wszystkie języki i projekty za pomocą jednej faktury,

• Bardzo podoba nam się wsparcie, jakie otrzymujemy — zespół Smartcat pomógł nam uruchomić proces pracy i nadał priorytet niektórym funkcjom, które były dla nas kluczowe,

• Usługa jest praktycznie bezpłatna — ostatecznie zdecydowaliśmy się na subskrypcję ze względu na funkcję wyszukiwania tekstu w całym projekcie, ale było to opcjonalne.

Niektóre z wyzwań, przed którymi stanęliśmy, to:

• Początkowo nie mogliśmy wyszukiwać tekstu we wszystkich dokumentach projektu — nie jest to już problemem, ponieważ Smartcat wdrożył tę funkcję,

• Freelancerzy czasami pomijają lub ignorują powiadomienia o aktualizacji dokumentu projektu, więc musimy ręcznie wysyłać im przypomnienia za pośrednictwem wbudowanego czatu,

• Kierownik projektu musi ręcznie wysyłać zaproszenia do tłumaczy — ale słyszeliśmy, że wkrótce ten krok zostanie zautomatyzowany.

Biorąc pod uwagę nasze dotychczasowe doświadczenia z Smartcat, mamy nadzieję, że ich zespół już pracuje nad rozwiązaniem tych problemów.

Aby spojrzeć na sprawę z odpowiedniej perspektywy, poniżej przedstawiamy porównanie tego, co mieliśmy, z tym, co mamy obecnie, zarówno pod względem procesów, jak i liczb.

Przed

Przed wprowadzeniem zmian musieliśmy wykonać blisko 30 czynności na etapie tłumaczenia i testowania językowego:

Tłumaczenie:

1. Pobierz teksty z różnych gałęzi repozytorium — ręcznie,

2. Utwórz plik delta do tłumaczenia — ręcznie,

3. Utwórz pakiety do tłumaczenia,

4. prześlij je na serwer FTP,

5. napisz mnóstwo e-maili do agencji, freelancerów lub lokalnych biur,

6. pobierz tłumaczenie z serwera FTP, gdy będzie gotowe,

7. załaduj je do narzędzia CAT i upewnij się, że wszystko wygląda dobrze,

8. ręcznie przesłać przetłumaczone ciągi znaków do repozytorium, starając się nie pomieszać gałęzi,

9. uruchomić kompilację, naprawić błędy, zakończyć kompilację,

10. poprosić o dodatkowe tłumaczenia — zasadniczo powtarzając ten sam proces.

Testowanie językowe:

1. Rozpocznij kompilację i poczekaj na jej zakończenie,

2. Uruchom ponownie kompilację, jeśli zakończyła się niepowodzeniem z powodu błędów lokalizacji,

3. Skonfiguruj specjalne środowisko testowe, jeśli nie ma menu debugowania,

4. Zrób wszystkie odpowiednie zrzuty ekranu dla ponad 20 języków,

5. Wraz z zespołem kontroli jakości ustal, jak uzyskać brakujące zrzuty ekranu,

6. Utwórz i nazwij pakiety zrzutów ekranu,

7. Prześlij je na serwer FTP,

8. Przydziel zadania agencjom tłumaczeniowym w celu sprawdzenia tłumaczeń,

9. Odpowiadaj na pytania agencji,

10. Akceptuj zadania i wprowadzaj zmiany,

11. Wykonaj kompilację — co czasami zajmuje dużo czasu,

12. Powtórz kompilację, jeśli wystąpiły błędy,

13. Zrób zrzuty ekranu do testów regresyjnych,

14. Ponownie przesłać zrzuty ekranu i zlecić zadania agencjom tłumaczeniowym,

15. Ponownie omówić wszystko z agencjami,

16. Ponownie przeprowadzić kolejną rundę testów regresyjnych, jeśli wprowadzono zmiany w tłumaczeniu.

Po

Obecnie mamy tylko dziewięć etapów we wszystkich fazach:

1. Copywriter zatwierdza nowe ciągi znaków w Git. Serge automatycznie przekazuje ciągi znaków do Smartcat,

2. Kierownik projektu lokalizacji przydziela tłumaczy,

3. Tłumacze tłumaczą w kontekście — mając pod ręką zrzuty ekranu i komentarze,

4. Kierownik projektu lokalizacji sprawdza i zatwierdza tłumaczenie, które następnie automatycznie wraca do Git,

5. Zespół lokalizacyjny uruchamia bota do tworzenia zrzutów ekranu dla zlokalizowanych tekstów,

6. Zespół ds. lokalizacji umieszcza zlokalizowane zrzuty ekranu na serwerze FTP i wysyła je do lingwistów,

7. Lingwiści sprawdzają i w razie potrzeby poprawiają tłumaczenia, przeglądając zlokalizowane zrzuty ekranu,

8. Zmiany automatycznie trafiają do Git,

9. Zespół ds. lokalizacji zamyka pull request.

To wszystko — dzięki trzykrotnemu zmniejszeniu złożoności naprawdę odczuwamy różnicę w porównaniu z tym, co mieliśmy wcześniej!

Wszystkie liczby dotyczą jednego wydania — co dwa tygodnie — i jednej aplikacji.

Dodatkowe korzyści — niektóre z nich były dla nas zaskoczeniem — obejmują:

• Bardziej niezawodne kompilacje: Dzięki placeholderów nie musimy już martwić się o tłumaczenie tekstów, których nie da się przetłumaczyć, lub o brak escapowania apostrofów itp.

• Smartcat zidentyfikował kilka starszych błędów dzięki ustawieniom krytycznych błędów.

• Nie marnujemy czasu i zasobów innych osób: nie musimy zabierać urządzeń testowych zespołowi ds. kontroli jakości ani zajmować czasu zespołu programistów, prosząc ich o robienie zrzutów ekranu.

• Zrzuty ekranu dostępne dla tłumaczy, które mogą oni łatwo otworzyć i wyświetlić bezpośrednio w edytorze, znacznie poprawiły jakość tłumaczeń.

Możemy kontynuować nasze działania i jesteśmy pewni, że z czasem znajdziemy inne sposoby na poprawę zarówno wydajności, jak i jakości naszych procesów lokalizacyjnych. Co najważniejsze, lokalizacja nie stanowi już wąskiego gardła w cyklu wydawniczym. Uważamy, że osiągnięcie tych wyników w tak krótkim czasie było wielkim osiągnięciem zarówno dla naszego zespołu, jak i platformy Smartcat.

Oto kilka konkretnych kroków, które podjęliśmy po wdrożeniu Smartcat. Zamieszczamy je tutaj jako „ściągawkę” dla innych firm i zespołów, które chcą pójść w nasze ślady. Nie wszystkie z nich są łatwe do wykonania, ale większość z nich pomoże usprawnić proces lokalizacji i zmniejszyć liczbę błędów.

Integracja:

• Przetestuj integrację Git–Serge–Smartcat, aby upewnić się, że wszystkie ciągi znaków trafiają do projektów Smartcat i z powrotem. Nie chcesz przecież spotkać się z niespodziankami na etapie produkcji.

• Uzgodnij nazewnictwo gałęzi z inżynierami oprogramowania. W ten sposób będziesz mógł skonfigurować bota, który będzie wyszukiwał konkretne gałęzie wymagające lokalizacji — oszczędzając zarówno Tobie, jak i programistom wiele godzin komunikacji.

• W razie potrzeby dostosuj domyślne parsery Serge. Na przykład sprawiliśmy, że identyfikatory ciągów znaków, komentarze i linki do referencyjnych zrzutów ekranu są widoczne dla tłumaczy.

• Utwórz zadanie cron, aby znaleźć gałęzie lokalizacji zgodnie z uzgodnioną powyżej maską nazwy.

• Rozważ testowanie interfejsu użytkownika i robienie zrzutów ekranu funkcji przy użyciu frameworka Kaspresso. Na przykład nasi programiści umieszczają link do zrzutu ekranu dla każdego używanego ciągu znaków. Kiedy plik trafia do Smartcat, link do zrzutu ekranu automatycznie pojawia się w zakładce Komentarze. Więcej informacji na temat Kaspresso i powodów, dla których warto z niego korzystać, można znaleźć pod adresem tutaj.

Lokalizacja i testy językowe:

• Jeśli dysponujesz słownikami, prześlij je do Smartcat, aby zapewnić spójność wszystkich lokalizacji.

• Dodaj swoich wewnętrznych lingwistów, aby mogli zapoznać się z platformą i nauczyć się jej obsługi, zanim otrzymają od Ciebie rzeczywiste zadania.

• Znajdź i wybierz freelancerów, a następnie włącz ich do procesów swojej firmy, upewniając się, że wiedzą, jak korzystać ze zrzutów ekranu, komentarzy, glosariuszy itp.

• W razie potrzeby znajdź agencje tłumaczeniowe, które zaspokoją dodatkowe potrzeby w zakresie lokalizacji lub testowania.

Mamy nadzieję, że te wskazówki okazały się pomocne — dajcie nam znać, jeśli macie własne!