GNOME:ProcesTłumaczeniaProgramu

Z Aviary.pl wiki
Skocz do: nawigacja, szukaj

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:

  1. 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)
    • Najpierw należy wyszukać, czy otwarty raport błędu dotyczący danego programu już istnieje (otwarty, czyli ktoś już nad tłumaczeniem pracuje). Szukamy. Jeśli na liście nie ma szukanego pakietu to musimy sprawdzić jeszcze jedną, istotną rzecz:
    • W przypadku oficjalnych zestawów wydań (np. zestaw GNOME „3.4”, nie gnome-extras) panuje zasada „jeden raport na cykl” dla danego programu. Tłumacz musi koniecznie poszukać, czy istnieje już raport związany z tym pakietem na ten cykl wydawniczy. Trzeba tego dokonać, ponieważ często dochodzi do wyjątków zamrożenia ciągów, a zakładanie nowego raportu za każdym razem, gdy dochodzi do zmian w programie byłoby bez sensu. Szukamy. Jeśli znajdziemy, to ustawiamy jego stan na PONOWNIE OTWORZONY i przypisujemy do siebie.
    • W przypadku całej reszty programów GNOME (gnome-extras) panuje zasada „jeden raport na wersję”, ponieważ tutaj doszłoby do jeszcze większego zamieszania, gdybyśmy zakładali nowe raporty przy każdej drobnej zmianą w programie. Szukamy. Jeśli znajdziemy, to ustawiamy jego stan na PONOWNIE OTWORZONY i przypisujemy do siebie.
    • Nazwy raportów błędów GNOME zostały ujednolicone. Przy zakładaniu nowego raportu należy koniecznie użyć schematu „UiK nazwa_pakietu numer_wersji”. UiK oznacza „Ujednolicenie i Korekta”. W przypadku oficjalnych zestawów wydań należy użyć schematu „UiK nazwa_pakietu na cykl oficjalny_numer_wersji”, a więc nawet jeśli program jest aktualnie w wersji 3.3, to wpisujemy wersję ostateczną, oficjalną (3.4).
  1. Tłumacz tłumaczy i załącza gotową wersję pliku do raportu błędu.
    • 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.
    • Jeśli jest to nowe tłumaczenie (od zera), to tłumacz wprowadza swoje inicjały jedynie przy ciągach dla niego wątpliwych, z komentarzami lub sugestiami.
  2. 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, ale zdecydowanie lepiej najpierw poznać członków zespołu. :)
  3. 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
  4. Plik z korektami ląduje w załączniku, błąd wraca do tłumacza. Korektor ogłasza ukończenie review zwykłym komentarzem w raporcie błędu (np. „Review w załączniku”).
  5. 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.
  6. 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 załącznika, 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 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.
  7. 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ą Piotr Drąg, Tomasz Dominikowski (nieaktywny) i Łukasz Jernaś (niezrzeszony). 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ć.
  8. Piotr wrzuca gotowe tłumaczenie do git GNOME i zamyka raport błędu (ROZWIĄZANY NAPRAWIONY).
    • Jeśli tłumacz odnajdzie później jakieś błędy, to może oczywiście otworzyć raport błędu ponownie (PONOWNIE OTWORZONY), wysłać poprawione tłumaczenie jako załącznik i wyszczególnić poprawki w komentarzu. Piotr sprawdzi poprawki i wyśle 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 ma Piotr.

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 schemat GSettings?
  • 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 nieistnieją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)

Inne