Ponadto każdy programista jest również testerem, który musi po rekompilacji przeprowadzić pomyślną walidację produktu i wyeliminować błędy powstałe w procesie lokalizacji (zdania są podzielone jeśli chodzi o tzw. błędy źródła, czyli błędy w materiale dostarczonym przez zleceniodawce).
Na szczęście z pomocą przychodzą CATy lokalizacyjne, czyli bardziej skomplikowane (z pewnością mniej przejrzyste dla „klasycznego” – w sensie „regular” – tłumacza) i o większych możliwościach aplikacje wspomagające nie tylko proces tłumaczenia, ale również pośredniczące w dekompilacji plików (RS, EXE, DLL, PHP, PEARL, JAVA, ASP, .NET, SOAP, XML, Flash etc.), sprawdzające, a nawet kolorujące składnię (czyli umożliwiają wyświetlanie więcej szczegółów, a nie tylko tzw. Tagi) segmentów docelowych (Target TUs), a nawet posiadające wbudowane moduły do walidacji konkretnych języków programowania, aż do kompilacji i wysyłki gotowego produktu do kolejnego etapu, czyli korekty.
W procesie lokalizacji poza weryfikacją tłumaczenia (QA/LQA, FQC, FCI) mamy do czynienia w dodatkowych etapem mającym na celu testowanie aplikacji. Jest to etap, który jest praktykowany przez większość wykonawców. Szczególnie w przypadku projektów większych niż klasyczna „strona główna i trzy podstrony”. Etap testowania najczęściej znajduje się tuż przed „oględzinami” klienta (CR – Clients Review) lub jest przedostatni. Jest to bardzo ważny etap i przesunięto go prawie na sam koniec odcinka produkcyjnego ponieważ bardzo często zdarza się, że kolejne dłonie w kolejnych etapach wskutek nieprawidłowego (niedelikatnego) obchodzenia się z materiałem w sposób nieumyślny generują problemy. Osobiście jestem zwolennikiem skracania pranu ramowego prdukcji do minimum. Dlatego tak ważne jest aby osoba odpowiedzialna za formę oglądała/weryfikowała efekt pracy zespołu tuż przed klientem. Lokalizacja składa się z wielu skomplikowanych zadań, które aplikacje CAT uprościły do minimum.
Z pozoru błachą, lecz praktycznie bardzo istotną różnicą między lokalizacją, a tłumaczeniem jest waga projektowania odpowiedniego przepływu pracy (workflow) już na etapie PM (Project Management – zarządzania projektami). W tłumaczeniu dodanie, a wręcz wepchnięcie dodatkowego etapu do planu projektu, lub dodatkowa korekta tłumaczenia itp. Nie przysparza tyle problemów co w przypadku lokalizacji, gdzie niezbędne jest uproszczenie procesów lokalizacyjnych, ich bezbłędne zaplanowanie i dobór odpowiednich wykonawców oraz sprawne zarządzanie projektem.
Skuteczne zarządzanie projektami lokalizacyjnymi może być przeprowadzone sprawnie tylko przez Project Managera posiadającego dużą wiedzę na temat lokalizacji oraz zagadnień technicznych związanych ściśle z tym procesem.
Najczęściej używane narzędzia do lokalizacji oprogramowania to:
Interface Builder (dawniej Project Builder)
WW. aplikacje często umożliwiają rozpoczęcie projektu za pomocą wbudowanego kreatora importu, czy innego, podobnego, który pozwala na dodanie plików oraz określenie preferencji twórcy. Np. Catalyst zaraz po uruchomieniu pyta użytkownika, czy przypadkiem nie ma ochoty na rozpoczęcie nowego projektu (oczywiście nie mówię o wersji bezpłatnej tzw. Lite dla tłumaczy). W kolejnym oknie określamy miejsce zapisu, nazwę projektu i pary językowe, potem przeciągamy cały katalog z plikami aplikacji do okna „Navigator” i przy odrobinie szczęścia (jeśli nie pokażą się błędy lub pytania o dodatkowe dodefiniowanie pewnych elementów itp.) pozostanie wybrać ulubiony widok (ja preferuję „Flat view” lub „.NET Inheritance view”) i rozpocząć tłumaczenie.
Wspomagacze CAT w wydaniu pro-localization są również tworami mniej hermetycznymi niż standardowe CATy, czyli często współpracują między sobą w sposób o wiele przyjemniejszy niż jest nam znany ze współpracy np. Transita z SDLXem. Pozostając przy Catalyst; ten program bez problemu (i co ważniejsze bez żadnych konwersji) akceptuje wiele rodzajów baz tłumaczeniowych jednocześnie. Istnieje możliwość podłączenia bazy zdalnej oraz lokalnej. Pierwsza akceptuje bazy serwra Catalyst oraz zdalne bazy programu Trados (np. dzięki TM Anywhere). Ta druga może być w formacie TTK (format programu Catalyst), PPF (plik z projektem programu Publisher), TXT rozdzielonego tabulatorami, TMX, czyli standardu obecnego w wielu programach lub TMW, czyli formacie „natywnym” dla programu Trados Workbench.
Oczywiście lokalizacyjne CATy również służą do tego co standardowe CATy, czyli nadadzą się do przetłumaczenia poczciwego pliku DOC, choć akurat Catalyst na to nie pozwala. Ale analogicznie, wyjątkiem w drugą stronę jest Trados, który radzi sobie z z plikami wykonywalnymi i innymi zasobami dzięki małym aplikacjom schowanym w katalogu z aplikacją (np. dla wersji 2007 standardowo: "C:\Program Files\SDL International\T2007\TT"). Są to: TRADOS T-Window for Executables (TWX.exe) oraz SDL TRADOS T-Window for Resources (TWR.exe). Ten drugi doczekał się nawet kreatora projktu: TRADOS T-Window for Resources Project Wizard (TWRProjectWizard.exe).
Na pewno warto zapoznać się z tymi narzędziami i programami, szczególnie, że część z nich tłumaczom udostępniana jest za darmo w wersji umożliwiającej tłumaczenie (plików przygotowanych do tłumaczenia najczęściej w tej samej aplikacji kupionej przez zleceniodawce lub jego klienta).
Więcej informacji na stronie: http://www.into-localization.com
