If you don’t know anything about Logoport – it’s a server based TM system, in which multiple translators can work concurrently on the same project, using light client-side applications: a MS Word add-on, XLIFF editor (a good one) and QA tool (also decent), which can be used for LIOX jobs only. Now the idea is to release somewhat improved and more powerful Logoport-based system – GeoWorkz – to all. It can be used by LPs and freelancers alike. The main benefits would be the ability to easily share all kinds of assets – mainly TMs and glossaries. GeoWorkz could be a perfect tool for the small to medium LPs or occasional collaboration of networked freelancers working together on some bigger job – all thanks to eliminating all the hassle with updating glossaries and TMs, plus the ability to use online review tool. The software includes a comprehensive and flexible asset rights management, assures security and confidentiality, etc.

However, as usually, the devil is in the details. First of all, it is based on Logoport. Let’s be honest – I don’t know a single translator who worked with the system and really liked it. It’s decent, when working properly, but no frills. One can get over the word counting algorithm with internal matches – sooner or later this will become a standard. One can get used to, and get around, the unreliable glossary matches display. The main problem is a speed (or lack of it). Logoport never was a speed demon, especially when working on large tagged files, but for the last several months the speed decreased drastically – at least for the European vendors. LIOX will have to significantly increase servers throughput, or the venture will be doomed from the start. Fortunately, I’ve been told this will be so.

While, regardless of other factors, I won’t move my business “to the cloud” (security and privacy concerns plus the ability to work off-line), I might consider using the system from time to time for sharing some bigger jobs, with the ability to easily control and coordinate them.

However, the more pressing problem is the “pay as you go” payment model – in fact based on a monthly subscription plans, with fee value tied to the monthly number of words. The lowest fee would be 10 Euro (14 USD) with the limit of 5,000 words, and to get the reasonable monthly limit of 80,000 words one would have to pay 50 Euro (70 USD) . Of course providing that all the freelancer’s jobs would be done via GeoWorkz. And they say 3-year TCO is lower than any other TM system. Well, I don’t know what kind of math they’re using but do I know that I can get other top CAT tools for a 6-8 month’s fee equivalent. With no additional costs in the future. Still, a bargain if you want to use some networking features and job sharing – you just pay for one month to get the job done.

It gets even better if you get a job via GeoWorkz from some client (agency) working with system. The job assigned through system does not count to the word limit of recipient, but to the word limit of the ordering party. So, if you were to use the system only for jobs from LIOX, it would be enough to have no “private” word limit. The problem – there’s no such thing.

In effect, a freelancer will have to pay at least the lowest monthly fee just to get jobs from LIOX, since they won’t be using any other tool, and you can’t get a job without the system account. In simple terms, this means that freelancer will have to pay to get a job. Brilliant, isn’t it?

Somehow, I predict a drastic drop of LIOX freelance vendors numbers in June, when the payment system will kick in. Unless they think it over and offer their vendors free accounts (even without the ability for “private” jobs).

If you want to learn more about GeoWorks, visit their website, there’s plenty of info there.

Na wypadek, gdyby czytelnik nie znał Logoporta, kilka słów wprowadzenia. System opiera się na dość rozsądnym założeniu – centralny serwer pamięci tłumaczeniowej (TM) umożliwia równoczesną pracę wielu osobom nad tym samym projektem i dzielenie się glosariuszami. Tłumacze mogą sprawdzić, jak dany termin został przetłumaczony przez kogoś pracującego równolegle, co ułatwia zachowanie spójności i przyspiesza pracę. Przynajmniej w teorii, bo różnie z tym sprawdzaniem bywa. Firmie łatwiej też jest zarządzać pamięciami tłumaczeń. Od strony klienta (tłumacza) program oferuje nakładkę na edytor Word (podobną do starszych wersji Tradosa lub WordFasta), edytor XLIFF (naprawdę niezły), oraz całkiem przyzwoite narzędzie do kontroli jakości. Z punktu widzenia tłumacza największym minusem jest konieczność pracy w trybie online, ze stałym dostępem do internetu. Nie ma łącza – nie ma pracy. Zastrzeżenia można mieć też do jakości algorytmów wyszukiwania terminów w glosariuszach – działają w sposób dość nieprzewidywalny.

Firma chwali się, że Logoport ma 90 tysięcy zarejestrowanych użytkowników, a codziennie pracuje na nim około 2000 osób – i to niestety czuć.

Teraz Lionbridge robi krok dalej, uruchamiając na bazie Logoporta nowy produkt, Translation Workspace. Główna różnica polega na tym, że po zarejestrowaniu się w systemie użytkownik będzie mógł korzystać z serwera do pracy nie tylko na zlecenie firmy Lionbridge, ale też użyć go do innych zleceń. Każdy posiadacz konta może w dowolny sposób korzystać z dostępnych narzędzi, pełniąc rolę zarówno zleceniobiorcy, jak i zleceniodawcy. Możemy np. przyjąć od dowolnego klienta zlecenie na 50 tys. słów i podzielić się nim z dwoma osobami, zapewniając im dostęp do TM na ustalonych przez nas warunkach, dysponując bieżącą kontrolą nad postępami i możliwością redakcji przetłumaczonych segmentów. Teoretycznie całkiem niezły pomysł – w końcu absolutnym hitem są obecnie wszelkiego typu aplikacje „w chmurze” (cloud), traktowanie programów jako usług (application as service) itd. Nie trzeba instalować wielkiego, skomplikowanego oprogramowania (wystarczy małe i skomplikowane), nie musimy się martwić o backupy TM, nie trzeba replikować naszych zasobów (assets) między różnymi komputerami – wszystko dostępne jest centralnie, na serwerze. Oprócz narzędzi podobnych do obecnych, logoportowych, czyli nakładki na Worda i edytora Xliff, dostępne będzie narzędzie do kontroli jakości oraz program do redakcji w trybie on-line, na serwerze. Obsługiwanych ma być większość powszechnych formatów – przez Office i systemy markupowe do programów do składu. I przyznaję, że pomysł może być atrakcyjny, zwłaszcza w przypadku współpracy niewielkich grup tłumaczy, ale…

Po pierwsze – wydajność logoporta. Jeśli firma drastycznie nie zwiększy liczby dostępnych serwerów, projekt skazany będzie na niepowodzenie. Obecnie współpraca z serwerem może być bardzo uciążliwa – nie ze względu na czas potrzebny na połączenia z serwerem, a z powodu czasu reakcji serwera, który ewidentnie nie wyrabia. Zdarzają się sytuacje, kiedy na samą analizę plików trzeba czekać w kolejce kilkadziesiąt minut, a zrealizowanie zapytania o concordance potrafi trwać kilkadziesiąt sekund.

Po drugie – model płatności, dumnie określany „pay as you go”, a w praktyce – miesięczne opłaty subskrypcyjne, których wysokość zależy od liczby słów do przetłumaczenia. Według zaprezentowanych planów najtańszy abonament miesięczny będzie kosztował 10 euro i pozwalał na przetłumaczenie 5 tysięcy słów – a to oznacza koszt około 8 groszy za słowo – znam agencje, które płacą mniej swoim tłumaczom (nie jest tak źle, pomyliłem się o jedno zero – nie 8 groszy, a 0,8 grosza). Oczywiście przelicznik ceny za słowo poprawia się wraz z rosnącym limitem, spadając do 0,00025 grosza/słowo przy rozsądnym dla freelancera limicie 80 tysięcy słów miesięcznie… ale i tak oznacza to wydawanie 50 euro miesięcznie. Za 200 można kupić kilka bardzo dobrych, komercyjnych programów, a te z całkiem górnej półki kosztują 600-800 euro.

Na plus należy zaliczyć systemowi sposób rozliczania otrzymywanych zleceń – jeśli dostanę zlecenie od innego użytkownika systemu (np. korzystającej z niego agencji), tłumaczone słowa nie liczą się do mojego limitu miesięcznego, a do limitu zleceniodawcy.

Na koniec wybitnie kontrowersyjny pomysł właściciela systemu – od chwili pełnego wdrożenia systemu GeoWorkz do wszystkich tłumaczeń w firmie Lionbridge, tłumacze pracujący dla firmy będą musieli posiadać płatne konta w serwisie, by otrzymać pracę. Czyli trzeba będzie zapłacić, by móc pracować. Trudno mi uwierzyć, by tłumacze chętnie się na to decydowali.

Więcej informacji na temat systemu można znaleźć na stronie GeoWorkz – dostępne są materiały reklamowe i techniczne dla freelancerów, biur tłumaczeń i zleceniodawców.

W październiku ubiegłego roku sąd wydał wyrok, zgodnie z którym tłumacze w Niemczech będą nie tylko otrzymywać stałe wynagrodzenie za każdą stronę przetłumaczonego tekstu, ale również — jeśli książka zostanie sprzedana w nakładzie powyżej 5000 egzemplarzy — tłumaczowi przysługiwać będzie 0,8% ceny sprzedaży w przypadku książek w twardej oprawie oraz 0,4% w przypadku książek w oprawie miękkiej. Jako ciekawostkę dodam, że tłumaczka, która pozwała wydawcę dostała zgodnie z umową 15 Euro za stronę tłumaczenia z angielskiego na niemiecki. Cóż, pozazdrościć.

Przy okazji jednak rodzi się pytanie, jak wygląda wynagrodzenie tłumaczy literackich w Polsce na tle zarobków w innych krajach. I tu z pomocą przychodzi raport z wyników badania przeprowadzonego w latach 2007/2008 przez Europejską Radę Zrzeszeń Tłumaczy Literackich (Conseil Européen des Associations de Traducteurs Littéraires, CEATL). Niestety, badanie nie obejmowało naszego kraju. Czego można się dowiedzieć z raportu?

Po pierwsze – na jakich zasadach wynagradzani są tłumacze. W zasadzie nie ma tu niespodzianek, bo i sposobów rozliczania wynagrodzenia nie ma wiele: stała opłata od objętości tekstu (liczonego w znakach, słowach lub stronach), procent od ceny zbytu książki, lub ustalona zaliczka (zazwyczaj zależna od objętości dzieła) oraz procent od ceny zbytu. Co ciekawe, zazwyczaj w danym kraju stosowany jest tylko jeden rodzaj rozliczania – w Belgii, Katalonii, Francji i Hiszpanii stosuje się niemal wyłącznie opłaty od ceny zbytu, ew. z zaliczką na ich poczet. Z ankietowanych krajów tylko w Wielkiej Brytanii równie powszechne są wszystkie trzy opcje – tak jak w Polsce. W większości krajów Europejskich powszechną praktyką jest płacenie tłumaczom stałej stawki od jednostki rozliczeniowej.

Po drugie – ile zarabiają tłumacze. Dane dla standardowej strony rozliczeniowej (1800 znaków) prezentuje tabela poniżej. Kwoty podane są w Euro. Pierwsza wartość to stawka minimalna, następnie stawka średnia i stawka maksymalna.

Stawki za tłumaczenia literackie.
Kwoty w Euro za 1800 znaków.

Jak na tym tle wyglądają stawki „obowiązujące” w Polsce? Niestety o kwotach z Belgii czy Szwecji możemy tylko pomarzyć — plasujemy się na poziomie Czech i Słowacji.

Ba, jak wynika z raportu, jesteśmy jednym z nielicznych krajów Europejskich, w których tłumacze nie czerpią żadnych zysków z wypożyczania owoców ich pracy z bibliotek – w większości krajów poza Polską, Belgią, Chorwacją, Irlandią i Portugalią istnieją organizacje (analogiczne jak nasz ZAiKS dla twórców muzycznych), zajmujące się pobieraniem i dystrubucją opłat za publiczne korzystanie z dzieł literackich.

Cały raport zawiera znacznie więcej informacji dotyczących tłumaczy literackich – np. ich liczbę w różnych krajach (od 50 w Szwajcarii do 2000 w Niemczech), dane dotyczące liczby przekładów i udziału tłumaczeń w całkowitej liczbie wydawanych dzieł literackich, oraz wiele innych. Zachęcam do lektury. Raport dostępny jest pod tym adresem (PDF).

Wiele można by mówić o pomysłach lokalizacyjnych tłumaczy Microsoftu, czasami błędnych (jak szpalta, która na wieki zostanie już kolumną), często niekonsekwentnych, jak zakładka, która całkiem niedawno zmieniła się w kartę. Nie zmienia to jednak faktu, że nad lokalizacją oprogramowania Microsoftu pracuje naprawdę spory sztab ludzi, zwracając dużą uwagę na poprawność językową i uspójnienie terminologii. Oczywiście nie zawsze to wychodzi, wszyscy zapewne możemy przytoczyć przykłady jakichś tłumaczeń „od czapy” pochodzących z programów MS, ale… kto wie, jak wygląda tłumaczenie tzw. „stringów” w lokalizacji oprogramowania najwyżej westchnie i pokiwa głową, rezygnując z rzucania kamieniem.

Przez rozpowszechnienie systemów operacyjnych i oprogramowania biurowego, terminologia stosowana w lokalizacji tych produktów stała się de facto standardem lokalizacji oprogramowania. Zwłaszcza w przypadku programów działających w systemie operacyjnym Microsoftu – firmy takie jak Sun czy IBM mogą sobie pozwolić na stosowanie własnej terminologii w produktach pracujących pod kontrolą ich systemów operacyjnych, jednak jeśli ktoś chce zlokalizować program czy instrukcję do programu działającego w systemie operacyjnym MS Windows, wypadałoby się trzymać terminologii systemu operacyjnego, dzięki czemu nasze tłumaczenie będzie zrozumiałe dla użytkowników.

Microsoft wyszedł naprzeciw tej potrzebie. Kiedyś możliwe było pobranie ze stron Microsoftu glosariuszy w formie plików .cvs. Podstawową zaletą była możliwość zapisania ich na dysku i korzystania w dowolnej chwili. Wadą – konieczność ściągnięcia sporej ilości danych oraz zastosowanie jakiegoś programu, który umożliwiałby wyszukanie w masie danych interesującej nas informacji (na przykład programu XBench), co mogło być problemem dla mniej zaawansowanych użytkowników. Teraz sytuacja się zmieniła. Firma Microsoft udostępniła dla wszystkich swój portal językowy.

Microsoft Language Portal umożliwia dostęp online do tłumaczeń wszystkich stringów oprogramowania wypuszczonego na rynek, i to w kilkudziesięciu językach. Oczywiście wraz z językiem polskim. Wystarczy wpisać interesujący nas termin, a zostanie wyświetlona lista tłumaczeń. W przypadku terminów z bazy terminologii, dostępne są również definicje. Dostępne jest również wyszukiwanie zaawansowane, z określenie produktu (programu), w którym ma być wyszukany dany termin. Przy okazji łatwo się przekonać, że zmiana terminologii, nawet jeśli dobrze umotywowana, nie musi być dobrym pomysłem – „tab” co prawda przeważnie jest już tłumaczone jako „karta”, ale tu i ówdzie trafiają się jeszcze „zakładki”.

Wygląd strony z wynikami wyszukiwania terminu. Lista rozwijana „Product” umożliwia wybór programu, w którym ma być wyszukiwany termin.

Dla zwolenników pracy w trybie offline wciąż możliwe jest ściągnięcie glosariuszy w plikach CVS – niestety, wymagane jest wykupienie subskrypcji MSDN lub TechNet.

Warto też zwrócić uwagę na dostępny z głównej strony serwisu odnośnik do wytycznych stylistycznych (tzw. „styleguide”). Dokument ten zawiera wytyczne stylistyczne dotyczące tłumaczenia tekstu, bezcenne zwłaszcza dla początkujących tłumaczy.

CafeTran napisano w języku Java. Oznacza to, że może działać pod dowolnym systemem operacyjnym – nie tylko Windows, ale i w systemach MacOS oraz Linuks. To bardzo dobra wiadomość dla tłumaczy, którzy chcieliby pracować w środowisku innym niż MS Windows – oferta programów dla nich wciąż jest niewielka. Instalacja CafeTran jest też niewiarygodnie mała – zajmuje na dysku niecałe 4 megabajty. Nie znaczy to jednak wcale, że program niewiele może. Wręcz przeciwnie. Możliwości silnika CafeTrana są bardzo duże. Zacznijmy może od tego, co program potrafi:

- Tłumaczenie plików .docx (natywny format MS Word 2007) i .odt (format plików OpenOffice). Tłumaczenie plików .doc (starszy format MS Word) możliwe jest albo przez zapisanie ich w formacie .docx w MS Word 2007, albo jako .odt w darmowym Writerze z OpenOffice. Ponadto obsługiwane są pozostałe formaty pakietów MS Office 2007 (Excel i PowerPoint) oraz ich odpowiedniki w OpenOffice.

- pliki w formatach HTML i XML

- pliki .ttx programu TagEditor z pakietu Trados

- pliki programów iWork, AbiWord i KWord

- pliki tekstowe.

Ponadto CafeTran potrafi współpracować z systemowym schowkiem, dzięki czemu możliwe jest tłumaczenie tekstów z programów niechętnych do współpracy, bądź plików w nieobsługiwanych wprost formatach. Rozwiązanie to jest bardzo podobne do zasady działania programu T-window for Clipboard z pakietu Trados, które już kilka razy niezwykle ułatwiało mi życie, na przykład przy tłumaczeniu bardzo złożonych plików Excela, w których tłumaczone miały być tylko niektóre komórki. CafeTran też to potrafi, co jest dużym plusem.

Miły jest również fakt, że CafeTran radzi sobie z dwujęzycznymi plikami .docx przygotowanymi w Tradosie. Oznacza to, że można w nim tłumaczyć dla zleceniodawców (np. biur tłumaczeń) korzystających z Tradosa – wystarczy poprosić o przysłanie przesegmentowanych plików i pamięci w formacie TMX, a nie będzie problemu z odesłaniem gotowego tłumaczenia w odpowiedniej postaci.

Podobnie jak najnowszy Trados, program potrafi pracować równocześnie z wieloma pamięciami TM, choć może przydałaby się opcja ich gradacji, albo kolejności wyświetlania wyników dopasowań. Miłym bonusem jest możliwość „złożenia” dowolnej liczby pamięci w jedną.

Wygląd najnowszej (w chwili pisania tekstu) wersji programu CafeTran.

Skoro mowa o pamięci, dochodzimy do największego atutu CafeTrana – potężnego (w sensie możliwości) mechanizmu przeszukiwania pamięci oraz dopasowywania nie tylko całych segmentów, ale również ich części. Technika tzw. „subsegment matching” jest ostatnio bardzo popularnym tematem wśród programów CAT i wprowadzają ją wszystkie większe firmy. O ile mi wiadomo pionierem był Atril z programem DejaVu. Subsegment matching rewelacyjnie działa w MemoQ i chwalił się nim Trados w Studio 2009, choć realnie niczym takim nie dysponuje. Ale wróćmy do CafeTrana. W trakcie pracy z pamięcią TM (albo wieloma pamięciami) po otwarciu nowego segmentu wyświetlane jest podstawienie z TM (jeśli jest) oraz „tłumaczenie automatyczne”, będące rekonstrukcją segmentu na podstawie tłumaczeń fragmentów znalezionych w TM. Rozwiązanie to sprawdza się całkiem nieźle w przypadku stosowania średniej wielkości (kilka-kilkanaście tysięcy TU), ściśle tematycznych pamięci. Wyświetlane są też dopasowania rozmyte z fragmentami, z których złożono sugerowane tłumaczenie automatyczne. W przypadku występowania w TM większych subsegmentów, wystarczy je zaznaczyć w oknie trafień, a tekst zostanie automatycznie skopiowany do okna edycji. Może to bardzo przyspieszyć pracę. Z drugiej strony, przy dużych pamięciach (rzędu kilkuset tysięcy TU) lista trafień z pojedynczymi słowami jest tak długa, że trudno odszukać na niej te dłuższe subsegmenty. Do kopiowania fragmentów trzeba też użyć myszy, co wiąże się z oderwaniem rąk od klawiatury (użycie skrótu klawiaturowego powoduje skopiowanie całego segmentu z fragmentem dopasowania).

Samo tłumaczenie w programie przebiega sprawnie i wygodnie. Bardzo dobrze i wygodnie działa system kopiowania znaczników z segmentu źródłowego. Z drugiej strony ich obsługa pozostawia trochę do życzenia – po pierwsze segmenty dzielone są na znacznikach (i to nawet w przypadku segmentów już zapisanych w TM), po drugie – znaczniki nie są zapisywane w pamięci, zastępuje je spacja. Zapewne w codziennym użytkowaniu nie jest to bardzo uciążliwe, ale stanowiło nieustanne źródło frustracji w moich testach, w których wielokrotnie „tłumaczyłem” ten sam, specjalnie spreparowany plik. Powiększanie przedwcześnie podzielonego segmentu jest bardzo proste, gorzej z dzieleniem nadmiernie rozbudowanego tekstu, co nie zawsze działa.

Unikalną funkcją programu jest możliwość pracy z plikami graficznymi. Możliwe jest tłumaczenie w programie tekstu na skanach, które wyświetlane są w jednym z okien. Przyznam, że nie bardzo przekonuje mnie przydatność tej funkcji, bo z braku tekstu źródłowego w formie elektronicznej nie sposób korzystać z TM, choć można szybko przeszukiwać dostępne zasoby słownikowe, wcześniejsze TM, czy glosariusze. Wydaje mi się, że prościej byłoby po prostu przeprowadzić OCR zeskanowanego tekstu. Bardziej przydatna (moim zdaniem) jest możliwość wykorzystania plików graficznych jako materiału referencyjnego, np. w przypadku zeskanowanych słowników.

Jak większość pakietów CAT, CafeTran umożliwia wykonanie procedury tzw. „align”, czyli utworzenia pamięci tłumaczeń z istniejących plików z tekstem oryginalnym i przetłumaczonym, dzięki czemu można w przyszłości w prosty sposób korzystać z efektów wcześniej wykonanych tłumaczeń.

Dodatkowo CafeTran oferuje możliwość współpracy z serwisem Google Translate, oferując jako jedną z opcji podstawienia maszynowe tłumaczenie segmentu. Niestety, w przypadku tekstów technicznych takie tłumaczenie nadal przeważnie generuje wyniki mogące co najwyżej rozbawić czytelnika, dlatego poza jedną próbą, w ogóle się tą funkcją nie zajmowałem.

Domyślny wygląd jednej z wcześniejszych wersji programu, z widocznym oknem automatycznego tłumaczenia (drugie okno od góry).

Osobną kwestią jest interfejs programu i sposób pracy z nim. Nie będę ukrywał, że program wymaga przyzwyczajenia się, a rozpoczęcie pracy w pierwszej wersji programu, z którą się zapoznałem, było mało intuicyjne. Od tamtej pory autor, Igor Kmitowski, wprowadził wiele zmian do programu (zmiany wprowadzane są często, widać, że program nieustannie się rozwija), między innymi zmieniając część ikon, co ułatwia użytkownikowi rozpoczęcie pracy. W ostatniej wersji zmienił się też nieco wygląd programu, i choć autor dalej eksponuje zamiłowanie do kratki, teraz łatwiej ją wyłączyć. Przy okazji warto stwierdzić, że program oferuje dość duże możliwości modyfikacji aranżacji układu okien oraz wyglądu poszczególnych elementów, takich jak tło i czcionka poszczególnych okien, kolor znaczników itp., choć trzeba się przy tym sporo naklikać.

Oczywiście żaden program nie jest idealny, tu też można dopatrzyć się paru wad. Po pierwsze, irytuje brak zapisu znaczników w TM oraz fakt, że program wymusza podział na segmenty przy znacznikach (choć jest nadzieja – autor obiecał uwzględnić możliwość wykluczenia znaczników z segmentacji). Z segmentów źródłowych w TM giną ukośniki („/”). Brakuje funkcji analizy tekstu względem TM. Wyświetlane po uruchomieniu programu okno „Open project” oferuje raczej otwarcie pliku. Co prawda można go użyć do otwarcia projektu, ale znacznie wygodniej zrobić to z menu (inne foldery domyślne okienka przeglądania) i przydatność okna wydaje mi się problematyczna (choć może inni uznają je za przydatne). CafeTran ostrzega, jeśli w segmencie docelowym brak znaczników występujących w źródle, ale sprawdza tylko ich liczbę (choć dobre i to).

Osobną kwestią jest język interfejsu – w programie wykorzystano język angielski, co jest zrozumiałe w przypadku programu kierowanego do potencjalnych klientów z całego świata. Przydała by się jednak wersja spolszczona, bo wielu tłumaczy języków innych niż angielski narzeka na brak zlokalizowanych programów do lokalizacji. Co prawda dostępna jest instrukcja programu w języku polskim, ale miejscami bywa nieco niejasna (przydałaby się jej redakcja) i uaktualnienie by nadążyć za najnowszymi zmianami w programie.

Generalnie – zdecydowanie polecam przynajmniej wypróbowanie możliwości programu (wersja demonstracyjna ogranicza TM projektu do 50 jednostek), ponieważ oferuje on znakomity stosunek możliwości do ceny. W razie problemów autor udziela wyczerpującej pomocy. Stanowczo uważam, że CafeTran zasługuje na określenie „dobre, bo polskie”.

W zakresie nowych funkcji:

• Tados Studio 2009 (TS) SP1 umożliwia łączenie z serwerami TM 2009 i MultiTerma 2009 (To wcześniej nie obsługiwał? Żenua).
• TS 2009 SP1 można instalować na Windows 7 oraz wersjach 64-bit Wisty i Win 7.
• TS2009 SP1 zawiera program SDL Passolo Essential 2009. W tej wersji Passolo może współpracować z pamięciami tłumaczeń Trados Studio oraz bazami terminologii Multiterm 2009.
• Rozbudowano funkcję filtra wyświetlania (Display Filter): możliwość wyszukiwania wyrażeń regularnych z rozróżnianiem wielkości znaków oraz wprowadzono filtr „New Translated Content”, do wyświetlania tylko nowych segmentów (może być przydatne).
• Dodano opcję definiowania maksymalnej wielkości pliku do importu do pliku .sdlxliff – pliki powyżej zadanej wielkości będą linkowane, nie importowane, co ma pozwolić na uniknięcie problemów z zajętością pamięci.
• Zmieniono ustawienia domyślne kontroli jakości tak, by domyślnie sprawdzane były zatwierdzone segmenty.
• W wersji Freelance TS 2009 domyślna sekwencja przetwarzania wsadowego dla tworzenia projektów obejmuje krok „Przygotowanie bez TM projektu”.
• W TS 2009 SP1 można otwierać pakiety przygotowane w SDL TMS.
• W edytorze można przełączać między trybem edycji wstawiania i nadpisywania.

Do tego dochodzi  całkiem spora lista poprawek usuwających błędy, na której czele znajdują się ten z komunikatem „Cannot create window handle” i podobnymi oraz problem z zaprzestaniem działania funkcji kopiuj/wklej po dłuższej pracy programu. Co prawda na liście nie ma mojego „ulubionego” błędu z „null object reference”, prowadzącego do zawieszania się programu w trakcie wpisywania tekstu do segmentu w edytorze, ale mam nadzieję, że może i to zostało poprawione. Zobaczymy.

W celu ściągnięcia poprawionej wersji należy się zalogować na swoje konto w SDL i ściągnąć cały poprawiony pakiet. Instalator automatycznie odinstaluje wcześniejszą wersję i zainstaluje nową. Muszę przyznać, że sama instalacja przebiegła szybko i bez żadnych problemów, poza jednym drobiazgiem – na etapie wyboru języków, które można tłumaczyć w pakiecie (jak zwykle w wersji Freelance, jest ich pięć) nie można wybrać mniej niż 5, co jest dość absurdalne. Cóż, może jeszcze kiedyś nauczę się paru dodatkowych języków…

Przeinstalowanie pakietu nie doprowadziło do żadnych problemów z danymi – wszystkie projekty dalej znajdują się na liście, choć musiałem na nowo otworzyć pliki w celu wyświetlenia statystyk – inaczej zamiast wykresu słupkowego z liczbami słów w plikach wyświetlany był komunikat błędu. Niestety, program nadal nie potrafi zapamiętać położenia pasków narzędzi i za każdym razem wyświetla je w ustawieniach domyślnych. Irytujące.

Co do samej stabilności, trzeba będzie sprawdzić. Niestety w moim przypadku będzie to musiało poczekac przynajmniej tydzień, ale będziecie mieć jakieś swoje obserwacje, zostawcie komentarz.

U progu swojej „kariery” tłumacza technicznego pracowałem w systemie Linuks, używając wyłącznie darmowych narzędzi. Nie powinno więc dziwić, że moim pierwszym programem CAT była OmegaT – całkiem darmowy program napisany w Javie. Użyłem go mn. do przetłumaczenia kilku dość dużych instrukcji obsługi, w czym bardzo mi pomógł dzięki sporej powtarzalności tekstu. Niestety, w tamtych czasach w programie OmegaT dostępna była jedynie segmentacja akapitowa, a właśnie zgłosił się do mnie klient z tłumaczeniem nowszej wersji jednej z tamtych instrukcji. Wydawało mi się, że nie ma na to pytanie prostej odpowiedzi. Kilka miesięcy wcześniej w analogicznej sytuacji wygenerowałem TM z segmentacją zdaniową robiąc align dokumentu źródłowego i tłumaczenia (tych z poprzedniej wersji). Niestety, było to dość pracochłonne. Tym razem postanowiłem uważniej przyjrzeć się programom z pakietu Okapi.

Co to takiego? Cytując opis ze strony projektu: „jest to zestaw specyfikacji interfejsów, modeli obiektów, elementów i aplikacji zapewniających środowisko do tworzenia uniwersalnych narzędzi służących do lokalizacji i tłumaczenia dokumentacji i oprogramowania.” Brzmi strasznie, na szczęście w rzeczywistości nie jest tak źle. Okapi to zestaw narzędzi i filtrów służących do pracy z pamięciami tłumaczeń oraz konwersją i przygotowaniem do tłumaczenia różnego rodzaju plików. Funkcja, która mnie tym razem najbardziej zainteresowała to właśnie możliwość przesegmentowania pamięci tłumaczeń.

Niestety, jak to czasami bywa w projektach Open Source, pakiet został stosunkowo niedawno przepisany na inny język programowania i w sieci dostępne są jego dwie wersje. W procedurze wymagany jest jeden program w starej wersji i jeden w nowej.

Opis procedury zaczerpnąłem stąd.

1. Pobrać i zainstalować program Olifant. Służy on do edycji i tworzenia plików TM. W naszym wypadku jest konieczny tylko, jeśli segmenty pamięci do przeróbki nie mają atrybutów “tuid”, czyli unikalnych identyfikatorów segmentów.
2. Wczytać pamięć w formacie TMX do programu Olifant i wybrać z menu „Entries” polecenie „Generate IDs”. Zapisać plik.
3. Pobrać i rozpakować do stworzonego folderu program program Rainbow w wersji 6.0 lub wyższej (dostępny tutaj, na stronie z Olifantem dostępna jest wersja 5).
4. Uruchomić program  (nie jest tworzona ikona na pulpicie ani w menu Start). Korzystając z Eksploratora (lub innego managera plików) przeciągnąć na kartę Input List 1 plik TM do konwersji. Ten sam plik przeciągnąć na kartę Input List 2. W karcieLanguages and Encodings ustawić właściwe parametry (w razie wątpliwości sprawdzić nagłówek pliku TMX).
   UWAGA: W ścieżce do pliku nie mogą się znajdować foldery ze spacjami w nazwie.
5. Z menu „Utilities” wybrać polecenie „ID-based alignment”. Zaznaczyć opcję „Segment the extracted text using the following SRX rules:” (Segmentuj ekstrahowany tekst używając następujących reguł). Wybrać plik .srx z regułami segmentacji. Jeden dostępny jest w podfolderze Config folderu Okapi. Ja użyłem pliku domyślnych reguł segmentacji programu SDLX z pakietu Trados 2007.
6. Na karcie Output wybrać wpisać nazwę pliku wyjściowego i kliknąć OK. Jeśli nie popełniliśmy jakiegoś błędu, program rozpocznie pracę (patrz ilustracja wyżej).

I to wszystko. W moim wypadku zamiast całego dnia uzyskałem przesegmentowaną TM w niecałe trzy godziny (włącznie z wyjaśnieniem problemu spacji w nazwie).

52. miejsce może nie robić wrażenia, ale uważam je za duży sukces zwłaszcza uwzględniając fakt, że blog zacząłem prowadzić zaledwie kilka miesięcy temu. Pełen ranking dostępny jest tutaj.

A przy okazji informuję, że nastąpi przerwa w publikacjach – jutro jadę na wakacje.