1. Brak możliwości wyświetlenia danego tłumaczonego segmentu w określonym kontekście. Każdy tłumacz wie, że kontekst to klucz [nasuwa mi się tu mój ulubiony kawał o tłumaczach: Ilu tłumaczy potrzeba do wkręcenia żarówki? To zależy od kontekstu]. W niektórych przypadkach mamy podpowiedzi dotyczące kontekstu, ale _niektórych_. Nie zawsze też te podpowiedzi wystarczą. Powinna być możliwość wyświetlenia segmentu na stronie w miejscu, w którym segment się pojawia, obok innych [przetłumaczonych lub nieprzetłumaczonych] segmentów.

2. Brak pamięci tłumaczeń i wyszukiwania kontekstowego. Załóżmy, że chcemy przetłumaczyć termin “poke” w jakimś kontekście i dopiero zaczynamy pracować z tą aplikacją. Jeśli nie było takiego samego segmentu, nie dostaniemy nawet podpowiedzi, jaki termin został użyty [jeśli terminu nie ma w glosariuszu, a w glosariuszu terminów jest niewiele]. Powoduje to ogromny chaos i stosowanie przez wiele osób różnych terminów oraz różnych standardów tłumaczenia podobnych do siebie segmentów. Rozwiązania używane w aplikacjach CAT wyeliminowałyby ten problem, ale podejrzewam że twórcy aplikacji Translations nawet w życiu nie widzieli Tradosa, WordFasta, OmegaT czy IBM TM/2… Co moim zdaniem źle świadczy o tym, kogo Facebook zatrudnia do pracy nad poszczególnymi elementami swojego serwisu.

Zgadzam się również z Tobą, że brak “centralnego punktu zarządzania” jest w tym wypadku bardzo poważną wadą. Nie ma się do kogo zwrócić o poradę, o rozwiązanie kwestii spornych, a ponieważ nikt nie jest zmuszany do głosowania, poszczególne segmenty będą otrzymywać różną liczbę głosów niezależnie od tego, jakie terminy i standardy będą w nich używane. Doprowadzi to do poważnych niespójności.

Słowem: jeśli tłumaczenie “społecznościowe” zostanie opublikowane “as is” bez zewnętrznej kontroli, to możemy spodziewać się żenującego poziomu. Jeśli zaś ktoś będzie potem całość musiał redagować, to… tak jakby sam tłumaczył to od początku. A właściwie gorzej, bo poprawiać chaotyczne tłumaczenie jest trudniej, niż tłumaczyć od początku.

Dla mnie więc, ze względu na taką a nie inną konstrukcję aplikacji oraz brak zarządzania, rozwiązanie zastosowane przez Facebook jest bardzo złym przykładem, jak należy podchodzić do takich projektów. To zupełnie tak, jakby dowolny produkt open source nie miał osoby zarządzającej [lub osoba ta nie miałaby zielonego pojęcia o programowaniu], nie miałby standardów oraz odpowiednich narzędzi. W takiej sytuacji na przykład w Linuksie dwie aplikacje nie mogłyby współpracować ze sobą, bo nie używałyby ustalonych odgórnie protokołów, a każde okienko wyglądałoby zupełnie inaczej…