GNOME:ProcesTłumaczeniaProgramu
Z Aviary.pl Wiki
Peer review
Żaden plik nie ma lądować w git.gnome.org zanim przejrzą go co najmniej 2 osoby (tzn. tłumacz + korektor). Żeby nie wprowadzać zbędnego zamieszania i ograniczyć ew. wąskie gardła review może zrobić każdy z tłumaczy (byle tylko nie dla siebie).
Proces wygląda tak:
- Tłumacz pobiera sobie aktualną wersję pliku .po z l10n.gnome.org, zgłasza błąd dot. tego tłumaczenia na bugs.aviary.pl (produkt GNOME) i przypisuje go do siebie (ma to na celu poinformowanie wszystkich, że dana osoba zajmuje się/ma zamiar zająć się danym programem)
- Oczywiście najpierw należy wyszukać, czy raport błędu dotyczący danego programu już istnieje (a jest to bardzo prawdopodobne). Szukamy wybierając "All" w obu polach wyboru. Jeśli znajdziemy uprzedni raport, to ustawiamy jego status na REOPEN i przejmujemy go. Wprowadzamy także wszelkie wymagane zmiany parametrów (np. zmieniamy GNOME-2-26 na GNOME-2-28 w polu "Version").
- Nazwy raportów błędów GNOME zostały ujednolicone. Przy zakładaniu nowego raportu proszę użyć schematu "UiK nazwa_pakietu". UiK oznacza "Ujednolicenie i Korekta".
- Tłumacz umieszcza plik bez zmian w repozytorium svn.aviary.pl (żeby była baza do późniejszych porównań).
- W sprawie dostępu do repozytorium prosimy o kontakt z wdziedzic(maupa)aviary(kropka)pl
- Tłumacz tłumaczy i wrzuca gotową wersję pliku do svn.aviary.pl.
- Jeśli jest to aktualizacja już istniejącego tłumaczenia, to przy nowo przetłumaczonych ciągach obowiązkowo wstawiamy komentarze z własnymi inicjałami (np. "wd" - Wadim Dziedzic).
- Ciągi, których nie jesteśmy pewni lub nie mamy pojęcia jak przetłumaczyć, oznaczamy jako wątpliwe ("fuzzy"). W komentarzach do tych ciągów umieszczamy swoje wątpliwości i ewentualne sugestie.
- Tłumacz prosi o review wprowadzając adres e-mail żądanego korektora w polu GNOME_Review i wybierając "?" z listy wyboru.
- Jeśli jesteśmy nowi i nikogo nie znamy, to możemy po prostu zostawić komentarz z prośbą o review.
- Korektor akceptuje GNOME_Review wybierając "+" z listy wyboru, przejmuje błąd, przeprowadza review i wpisuje swoje uwagi do komentarzy w pliku .po oraz ewentualnie w zgłoszeniu na b.a.p
- Korektor nie może w żadnym wypadku modyfikować treści tłumaczenia, tylko wstawia uwagi w polu komentarza danego ciągu
- Uwagi koniecznie należy poprzedzić znakami "REV" tak, żeby odróżniały się od zwykłych komentarzy
- Fakt korekty dobrze jest także odnotować w komentarzu na początku pliku (zob. GNOME:ElementyStałe)
- Plik z korektami ląduje w svn.aviary.pl, błąd wraca do tłumacza. Korektor ogłasza ukończenie review zwykłym komentarzem w raporcie błędu (np. "Review w SVN").
- Tłumacz wprowadza poprawki, co do których nie ma wątpliwości, wg. uwag załączonych w komentarzach.
- Podczas wprowadzania poprawek obowiązkiem tłumacza jest na bieżąco całkowite usuwanie komentarzy zarówno własnych jak i korektora, ale wyłącznie z poprawionych ciągów. W ciągach znajdować się mogą starsze komentarze (niepoprzedzone inicjałami lub REV), zawierające przydatne informacje dotyczące np. kontekstu czy wyjaśniające celowość danego tłumaczenia. Należy je zostawić, jeśli nadal są aktualne. Tłumacz może podczas tłumaczenia zostawiać takie komentarze, aby ułatwić życie innym.
- Tłumacz i korektor mogą omawiać ewentualne uwagi, jeśli pozostały jakiekolwiek wątpliwości. Nie wolno usuwać jakichkolwiek komentarzy z ciągów, które nie zostały poprawione.
- Wymianę zdań można prowadzić prywatnie (e-mail, Jabber, itp.), ale jeśli wątpliwości jest sporo, to lepiej poprzez komentarze w raporcie błędu.
- W niektórych przypadkach można wykonać drugą iterację korekty, jeśli tłumacz i korektor nie dochodzą do porozumienia w sprawie kontrowersji (są to sytuacje nadzwyczaj rzadkie). Tłumacz, po poprawieniu bezdyskusyjnych błędów i wrzuceniu pliku w takim stanie do SVN Aviary, może za porozumieniem stron poprosić o review inną osobę, która dołącza komentarze "REV2" do komentarzy "REV", jeśli się z nimi nie zgadza. Po drugiej iteracji review tłumacz poprawia błędy wg sugestii REV (jeśli drugi korektor nie miał uwag do korekty danego ciągu) lub REV2 (jeśli miał uwagi). Jeśli na tym etapie nadal będą istniały jakieś kontrowersje, to sprawę należy przedyskutować na cotygodniowym stand-upie, w gronie całego Aviary.pl.
- Nie do przyjęcia jest tłumaczenie wg wytycznych sprzecznych z GNOME/Aviary.pl oraz sprzecznych ze słownikiem GNOME/Aviary.pl. Spójność tłumaczeń jest ważniejsza od własnego punktu widzenia. Jakiekolwiek zmiany wytycznych i słownika można przedyskutować na forum Aviary.pl. Należy jednak wziąć pod uwagę ograniczone zasoby, nawet miesiąc przed wydaniem jest i tak za późno na wprowadzanie nawet drobnych zmian słownikowych. To duży projekt.
- Jakiekolwiek wycieczki osobiste są nie do przyjęcia.
- Tłumacz, po wprowadzeniu wszystkich poprawek, usunięciu wszystkich swoich komentarzy jak i REV/REV2 daje znać, że plik można umieścić w git.gnome.org. Wystarczy komentarz do błędu typu "Poprawione, gotowe do wysłania".
- Konta w git GNOME posiadają Wadim Dziedzic oraz Tomasz Dominikowski. Nie trzeba ich przypisywać do błędów, jeśli chcemy, aby nasze poprawione tłumaczenie zostało wysłane do git GNOME, bo i tak otrzymują wszystkie wiadomości e-mail związane z GNOME, ale można to zrobić.
- Wadim lub Tomasz wrzucają gotowe tłumaczenie do git GNOME i zamykają raport błędu (RESOLVED FIXED).
- Jeśli tłumacz odnajdzie później jakieś błędy, to może oczywiście otworzyć raport błędu ponownie (REOPEN), wysłać poprawione tłumaczenie do SVN Aviary i wyszczególnić poprawki w komentarzu. Wadim lub Tomasz sprawdzą poprawki i wyślą do git GNOME, jeśli nie ma z nimi żadnych problemów.
- Nie ma stale określonej granicy, kiedy wymagany jest review, a kiedy poprawki są "drobne" (dotyczy to także aktualizacji tłumaczenia między wydaniami). Zależy to od oceny tłumacza, ale ostateczne słowo w tej sprawie mają Wadim i/lub Tomasz.
Testy na żywo
Testy na żywo to nic innego jak przetestowanie nowego lub poprawionego tłumaczenia w praniu. Warto to robić jak najczęściej, ponieważ:
- Język polski jest językiem wysoce kontekstowym, a automatyczne komentarze programistów nie zawsze są pomocne w zlokalizowaniu danego ciągu w interfejsie. Czasami nie ma wyjścia i trzeba sprawdzić w jakim kontekście dany ciąg został użyty. Czy jest to podpowiedź w pasku stanu, czy jest to ciąg obok kratki do zaznaczania, ciąg na przycisku, opis parametru w wierszu poleceń, a może schematu GConf?
- Kolizje skrótów klawiszowych są nieuniknione. Należy koniecznie przetestować je co najmniej raz na wydanie i poprawić, wywołując wszelkie możliwe opcje.
Przed przystąpieniem do testów należy sprawdzić czy zgadzają się wersje pliku tłumaczenia i testowanego programu (w przeciwnym wypadku mogą występować nieprzetłumaczone fragmenty, ew. teksty nie istniejące w rzeczywistym programie). Starajmy się przejść wszystkie możliwe ścieżki i opcje programu - należy także sprowokować najczęstsze sytuacje błędów (test komunikatów).
Krótkie wprowadzenie do podmieniania tłumaczeń programów można znaleźć w artykule Novell:Testowanie#Lcn (fragment Lcn)
