Minusem, który długofalowo odciska swoje piętno na jakości jest to, że zleceniodawca (biuro tłumaczeń, a nie klient końcowy) nie dostrzega ogromu poprawek - otrzymuje poprawiony produkt tłumaczeniowy gotowy do dalszej obróbki, a osoba tłumacząca niezależnie od ilości i wagi błędów nie jest ani chwalona, ani eliminowana z zespołu. Brakuje motywacji oraz „przesiewu” wykonawców.
Często podczas składania publikacji mimowolnie włącza mi się mechanizm LQA (http://www.localizers.com/services/linguistic-quality-assurance.html) - oczywiście nie mam skrupułów i informuje mojego zleceniodawce o błędach jeśli są krytyczne (choć wiele firm eliminuje nawet dobrych tłumaczy z powodu poprawek preferencyjnych już na etapie rekrutacji - późniejsza weryfikacja raczej nie występuje do momentu wystąpienia poważnej reklamacji).
Idealnym rozwiązaniem są standardy QA regulowane dedykowanymi normami oraz formularzami (np. LISA - http://www.lisa.org), które niestety przysparzają dodatkowych kosztów, bo poza osobą sprawdzającą potrzebna jest również osoba implementująca poprawki, ale moim zdaniem jest to niemal niezbędne, by chronić jakość finalną produktu (choć o priorytecie i prestiżu klienta końcowego często świadczy tylko to, ile ma zamiar zostawić gotówki w biurze, przynajmniej z punktu widzenia biur, a na pewno takie się znajdą). Dzięki takiemu przepływowi pracy powstaje raport, z którym może zapoznać się pracownik biura i ocenić, czy ten konkretny tłumacz spełnia standardy agencji.
Ponadto zaleca się kontrole spójności (która nie ma sensu w tekstach np. marketingowych, czy literaturze, ale w tekstach technicznych często jest priorytetem - nawet ponad rzetelnością przekładu) via np. Xbench lub QADistiller (http://into-localization.com/dodatkowe-narzedzia/lista), które nomen omen (przynajmniej ten drugi) służą również w dziale DTP (http://into-localization.com/dtp-w-tlumaczeniach/lista) - do np. kontroli wystąpień wariacji interpunkcyjnych (choćby w błędnej postaci) lub spójności w stosowaniu cudzysłowów drukarskich itp.