Nocna owsianka banoffee

Zacznijmy od przepisu, który zawdzięczam GCN – kolarskiemu kanałowi na YouTube. Ta robiona wieczorem i zostawiana na noc w lodówce owsianka jest idealna, gdy latem planuję bardzo wczesny wyjazd na rower i muszę wstać np. o trzeciej. Nie chcę w takich przypadkach hałasować rodzinie, robiąc sobie śniadanie i kawę, więc wolę po prostu wyciągnąć słoik i za jednym zamachem dostarczyć sobie paliwa i kofeiny.

Składniki

• szklanka płatków owsianych
• espresso
• dojrzały banan
• 200 ml mleka
• 150 g jogurtu
• szczypta soli
• dwie łyżki cukru trzcinowego

Opcjonalnie (zazwyczaj odpuszczam):

• kilka kropli esencji waniliowej
• kostka gorzkiej czekolady

W oryginalnym przepisie mowa o błyskawicznych płatkach owsianych, ale ja wolę górskie. Mleko najczęściej wybieram owsiane, a jogurt wegański kokosowy z Lidla. Zamiast cukru muscovado używam demerara, bo tego pierwszego nie ma nigdzie na moim zadupiu.

Przygotowanie

Wieczorem o dużego słoika (wygodniejszy od pokala użytego w wideo, m.in. przez to, że można go zamknąć) wsypuję płatki owsiane, sól i jedną łyżkę cukru, wlewam espresso (jak wstaję bardzo wcześnie, to podwójne) oraz mleko. Gdy akurat mam ochotę, dodaję też esencję waniliową, czasem zastępując ją cukrem wanilinowym. Wszystko dokładnie mieszam.

Banana kroję na plastry i układam je na płatkach. Jogurt mieszam z drugą łyżką cukru trzcinowego i wlewam na wierzch. Jeżeli chce mi się bawić z późniejszym myciem tareczki (czyli prawie nigdy), to trę na wierzch kostkę gorzkiej czekolady.

Zakręcam słoik i wstawiam lodówki. Do rana płatki zmiękną, a całość stanie się bardziej zwarta i po prostu pyszna.

– –

Pieczona owsianka PB&J

To z kolei owsianka, którą przygotowuję sobie do pracy. Z podanych składników wychodzą mi cztery drugie śniadania, więc jednym pieczeniem załatwiam sobie większość tygodnia.

Przepis, również znaleziony na YT, wyskoczył mi gdzieś w szortach.

Składniki

• 200 g płatków owsianych
• 2 banany
• 60 g białka o smaku słonego karmelu
• 420 ml mleka
• łyżeczka proszku do pieczenia
• garść mrożonych malin
• kilka łyżek masła orzechowego
• kilka łyżek dżemu malinowego

Używam wegańskiej odżywki białkowej z Allnutrition, do kupienia np. w Decathlonie za 50 zł za półkilogramowe opakowanie. Tak jak poprzednio, płatki wybieram górskie, a mleko najczęściej owsiane. Co jakiś czas mrożone maliny zastępuję innymi owocami, w zależności co ciekawego znajdę w dziale mrożonek w sklepie. Dżem malinowy czasami odpuszczam, bez większej straty dla całości.

Przygotowanie

Nagrzewam piekarnik do 180 stopni.

Można wszystkie składniki wymieszać w formie do pieczenia, ale wtedy brzegi zawsze mi się usmarują jak na zdjęciu po lewej. Dlatego częściej przygotowuję całość w misce.

Rozciapuję widelcem banany, dodaję płatki owsiane, białko, proszek do pieczenia i mleko, po czym mieszam wszystko dokładnie. Dodaję maliny i mieszam jeszcze raz, tym razem delikatniej, żeby nie rozwalić owoców. Wylewam całość do formy i wyrównuję. Dodaję na wierzch kleksy z masła orzechowego oraz dżemu malinowego i robię widelcem esy-floresy.

Piekę ok. 40 minut, aż wierzch się trochę zarumieni.

Zamiast formy do pieczenia używam metalowego pojemnika z IKEA, do której dokupiłem pokrywkę, dzięki czemu nie muszę przekładać owsianki do czegoś innego, tylko studzę, zamykam i wsadzam do lodówki. Przez kolejne cztery dni tylko wyciągam sobie po ćwiartce do śniadaniówki i mam drugie śniadanie z głowy. Można jeść na zimno lub np. podgrzać w mikrofalówce.

Zacząłem od niezbyt długiego (65 km) wyjazdu na zbieranie squadratów w okolicy Kcyni (więcej o zabawie w Squadrats napisałem w tej notce). Zdobyłem tylko pięć, ale za to istotnych, bo blokowały mi powiększenie ubersquadratu w przyszłości. Przy okazji trafiłem na zaznaczoną na mapie drogę, która została zaorana i stała się polem, więc żeby nikt inny nie musiał prowadzić roweru przez zboże, usunąłem ją z OpenStreetMap.

– –

Następny wypad wypadł w Wielkanoc, więc tak jak w poprzednich latach zdecydowałem się na wjechanie na Dębową Górę koło Osieka nad Notecią. Przy okazji przeprowadziłem pierwszą tegoroczną „transmisję” na fedi z rowerowania pod hasztagiem #LiveZRoweru.

Dla urozmaicenia postanowiłem wjechać na Dębową inną drogą niż zwykle, co skończyło się zabawą w przenoszenie roweru nad przewróconymi drzewami. Na szczęście reszta leśnych dróg była normalnie przejezdna.

Gdy wyjechałem z lasu w okolicy Krostkowa, silny wmordęwind pomógł mi podjąć decyzję o rezygnacji z dalszej jazdy na zachód jazdy do Chodzieży i skróceniu trasy w Białośliwiu. I tak uzbierało się ponad 97 kilometrów, bo wybrałem trochę dłużą drogę powrotną z odbiciem na leśne szutry za Gromadnem.

– –

Drugi tydzień to trzy krótsze jazdy, z czego dwie to powrót mojego starego Ridleya. Najpierw 26 km po okolicy, by sprawdzić, jak się na nim jeździ z krótszym mostkiem, przełożonym z nowego Canyona (wyraźnie lepiej), ale jeszcze z szutrowymi oponami Continental Terra Speed w rozmiarze 40C. Za drugim razem zmieniłem dodatkowo gumy na węższe i gładkie Continental Gatorskin 32C. Już nie pamiętałem, że takie bujnięcie się po samych asfaltach też potrafi dawać sporo frajdy.

Po tych zmianach Ridley stał się moją maszyną do krótkich, żwawych treningów po szosach, świetnego uzupełnienia bardziej zrelaksowanego kulania po szutrach na Grizlu.

– –

Czwartą jazdą w tym tygodniu był kolejny #LiveZRoweru – wypad do Koronowa, bo dowiedziałem się, że ze względu na konieczny remont osuwiska zostanie zamknięty tamtejszy dawny most kolejki wąskotorowej, obecnie główna (jedyna?) atrakcja trasy rowerowej Bydgoszcz – Koronowo. Postanowiłem przy okazji znaleźć alternatywę dla zamykanej przeprawy, którą okazał się dużo mniej okazały most na Brdzie między Samociążkiem a Gościeradzem.

Zaliczyłem też kilka squadratów, chociaż będę potrzebował jeszcze dużo jeżdżenia, zanim będę mógł włączyć tamte okolice do mojego ubersquadratu.

Pogoda była tak dobra tamtego dnia, że postanowiłem wrócić do domu dłuższą drogą, przez Bydgoszcz, gdzie skusiłem się na kolejną zmianę trasy. Miałem przejechać kawałek wzdłuż Kanału Bydgoskiego i przekroczyć go mostem, który okazał się nieczynny. Dzięki temu wybrałem się na wycieczkę drogą, której coraz bardziej terenowy charakter powodował, że cieszyłem się z zakupu gravela, a nie szosy.

Ostatecznie uzbierało się 114 kilometrów, pierwsza setka w tym roku.

– –

Trzeci tydzień to najpierw kolejny krótki szosowy trening na Ridleyu, a potem dwa wypady na Gryzelku po 30-40 kilometrów. Przy drugim zaliczyłem nową drogę w okolicy Orzelskiego Młyna, która wyprowadziła mnie wprost na pole, na którym dwa kozły sarny walczyły ze sobą, obserwowane przez trzy samice. Jakbym wjechał do filmu przyrodniczego.

Później zrobiło się mniej fajnie, bo złapałem pierwszego kapcia w nowym rowerze. Na oponach Continentalach w starej maszynie robiłem tysiące kilometrów bez problemów, a tu Schwalbe G-One Bite Performance poddały się tak szybko. Przynajmniej mogłem sprawdzić, jak spisują się dętki z zaworem Click oraz nowa pompka Lezyne Click Drive HV. O ile opona mnie zawiodła, to nowe wentyle spisały się świetnie.

– –

W następnym tygodniu wyskoczyłem na rower tylko raz, na kolejne skwadratowanie. Tym razem pojechałem na północ, w okolice Więcborka i zdobyłem 12 kwadratów.

Przy okazji odkryłem, że Więcbork dorobił się nowiutkiej DDR prowadzącej do miasta od strony Nakła, tak świeżej, że kręcąc się po niej, przeszkadzałem ekipie malującej oznaczenia na asfalcie. Niedługo muszę się ponownie wybrać w tamte strony, by sprawdzić, gdzie zaczyna się ta droga, tym razem nie miałem na to czasu i tak uzbierało się prawie 90 kilometrów.

Kawałek dalej znalazłem schowaną w lesie dużą wiatę „edukacyjno–turystyczną”, urokliwie położoną nad jeziorkiem, o której istnieniu nie miałem pojęcia, mimo że niedaleki leśny parking to moje stałe miejsce postojów.

– –

Końcówka kwietnia to jeszcze jeden #LiveZRoweru – długi (kolejna setka) wyjazd na zbieranie skwadratów w okolicy Szubina: 27 nowych kwadratów i ubersquadrat powiększony do 22×22.

Nie obyło się bez niespodzianek, najpierw na drodze stanęła mi brama ogródków działkowych w Żurczynie, a później trafiłem na kolejną znikającą drogę, co skończyło się przedzieraniem przez leśne krzewy i prowadzeniem roweru przez pole (a po powrocie do domu także następną edycją OpenStreetMap).

To nie był jedyny raz tego dnia, gdy szedłem obok Gryzelka, zamiast na nim jechać, bo niedługo później trafiłem na polną gruntówkę, która z powodu suszy zamieniła się w wydmy i koła po prostu grzęzły w piachu. Na szczęście trwało to tylko kilometr.

– –

Miesiąc zakończyłem na wizycie z rowerem w Gdańsku, gdzie na fittingu w VeloLab ostatecznie został pode mnie ustawiony, co ostatecznie zakończyło cały proces kupowania nowej maszyny. Po sesji przejechałem przez pełną turystów starówkę, skąd po cyknięciu Gryzelkowi fotki z Neptunem (żeby nie zazdrościł Ridleyowi) pojechałem w moje ulubione gdańskie miejsce – na Dolne Miasto, gdzie najpierw pokręciłem się po bastionach, a potem zjadłem obiad w Nie/Mięsnym, by zakończyć wizytę w Gdańsku odwiedzinami u rodziny.

Jak zawsze byłem pod wrażeniem gdańskiej infrastruktury rowerowej i chciałbym podobnej wszędzie. Dzień wcześniej byłem na zebraniu wiejskim na konsultacjach społecznych projektu przebudowy drogi powiatowej przechodzącej przez moją wieś, w ramach której mają powstać ciągi pieszo-rowerowe w miejscowościach i drogi dla rowerów poza nimi, więc może w ciągu najbliższych lat będziemy mieli namiastkę Trójmiasta.

– –

W sumie zarejestrowałem 11 wypadów dla frajdy, podczas których uzbierało się 645 kilometrów. Po podaniu wyjazdów na zakupy i kręcenia po Gdańsku wyszło 722,2 km, czyli niewiele mniej niż od stycznia do marca razem.

W porównaniu z zeszłorocznym kwietniem zrobiłem ponad 90 km mniej, ale i tak jestem bardzo zadowolony z wyniku. Oby tak dalej.

– –

Styczeń

Przez cały miesiąc pięć razy wybrałem się rowerem na zakupy, dzięki oponom z kolcami. Do tego tylko dwa razy przejechałem się dla frajdy. Raz skończyło się na 20 kilometrach, bo okazało się po kilku kilometrach, że szosa jest sucha i czysta tylko do granicy gminy, a dalej zaczyna się częściowo zmarznięty szary śnieg. Na szczęście za drugim razem drogi były już wolne od takich niespodzianek i udało się wykręcić ponad 36 kilometrów.

– –

Luty

Przymroziło zdrowo i przez pierwsze dwa tygodnie tylko raz wsiadłem na rower, by pojechać na zakupy. Na szczęście później zrobiło się przyjemniej i mogłem wybrać się na rowerowanie trzy razy: na lokalną pętelkę 36 km, Małą Pętlę Notecką oraz trochę dłuższe kulanie po okolicy (57 km).

– –

Marzec

W marcu zaczęło robić się cieplej i pojeździłem trochę więcej – pięć razy na zakupy i siedem dla frajdy.

W pierwszym tygodniu najpierw zaliczyłem kolejną trasę 50+, a potem machnąłem prawie 80 km w sporej części po leśnych szutrach.

Drugi tydzień to tylko wyjazd na zakupy, nie pamiętam dlaczego, ale podejrzewam, że mogło być tam jakieś załamanie pogody. Za to 17 marca wybrałem się do Gdańska (pociągiem, nie rowerem), na bike sizing w tamtejszym VeloLABie, by mój następny gravel jak najlepiej pasował do mnie.

O całym procesie wyboru i kupowania napiszę osobną notkę, gdy nakulam trochę więcej kilometrów na nowej maszynie. Może po przejechaniu 2k?

Kolejny tydzień to dwie jazdy w okolicy 40 kilometrów, pierwsza jeszcze ze starym komputerkiem GPS od Lezyne, druga już z nowym Coros Dura, kupionym z myślą o kilkudniowych wyjazdach na następcy wysłużonego Ridleya.

W tej chwili mam nakręcone na nim prawie 800 km i jestem bardzo zadowolony, zwłaszcza z czasu pracy na baterii. Dzięki ładowaniu ze słońca nie musiałem go podłączać do ładowarki ani razu od początkowego naładowania do 100%, a nadal ma ponad 43%. Więcej pewnie napiszę w osobnym tekście.

Później zaliczyłem jeszcze wypad na łapanie skwadratów w północno-wschodnim rogu mojego ubersquadratu, dzięki czemu powiększyłem go do rozmiaru 21×21 i w końcu „nadejszła wiekopomna chwila”, czyli przyjechał mój nowy rower, Caynon Grizl 7 w kolorze affogato, czyli kawy z lodami waniliowymi. Jak na złość akurat nie miałem czasu wybrać się na dłuższe kulanie i pierwsza jazda to tylko 36 km.

Dopiero kilka dni później, ostatniego dnia marca, mogłem wyskoczyć na kolejne zbieranie skwadratów, tym razem w północno-zachodnim rogu. 95 kilometrów, w części po lasach i polach, pokazało mi, że dobrze wybrałem, bo jechało się świetnie.

– –

Podsumowanie

W sumie w ciągu pierwszego kwartału 2026 zaliczyłem tylko 11 wypadów na zakupy (łącznie ok. 120 kilometrów) i 12 dla frajdy (610 km). W porównaniu z tym samym okresem 2025 zrobiłem o 44 kilometry więcej, więc mogło być gorzej.

W czasie pisania tego tekstu już wiem, że w kwietniu nie uda mi się zachować tej tendencji, głównie przez pracę, ale mam tak wielką frajdę z jazdy na nowym rowerze, że każda minuta spędzona na Gryzelku liczy się podwójnie.

Spis treści

• Wprowadzenie
• Tłumaczenie przy użyciu webinterfejsów
  • Weblate
  • Crowdin
• Przez ręczną edycję plików
• W polskim zespole GNOME

– –

Wprowadzenie

W końcu przyszła pora na mój ulubiony sposób angażowania się w WiOO, czyli tłumaczenie programów, tak by jak najwięcej osób mogło z nich korzystać.

W tej chwili mam na koncie tłumaczenie na polski m.in.:

• klienta Fediwersum Tuba,
• androidowych klientów fedi Pixelix oraz Pachli,
• edytora Markdown Scratchmark,
• klienta Tidala Tonearm,
• strony Join the Fediverse,
• aplikacji pogody Mousam,
• wtyczki dla WordPressa Embed Consent.

Przy okazji nauczyłem się zupełnie nowych rzeczy. Dzięki Tubie i Pixelix poznałem interfejsy do tłumaczenia Weblate i Crowdin, dla Join the Fediverse dowiedziałem się jak forkować repozytorium i tworzyć merge request ze zmianami, a Mousam zawdzięczam poznanie tworzenia plików tłumaczenia przy użyciu narzędzi gettext. Dla kogoś innego to może być masa roboty, dla mnie zdobywanie nowych umiejętności i doświadczeń jest jedną z zalet angażowania się w WiOO.

Na podstawie powyższej listy mogliście się zorientować, że samo przetłumaczenie komunikatów to nie wszystko, bo trzeba jeszcze nasze tłumaczenie przekazać osobom tworzącym program, aby mogły je do niego włączyć. Można to zrobić na różne sposoby, w zależności od mechanizmów, które oferuje konkretny projekt. Żeby sprawdzić, który jest dostępny w danym przypadku, trzeba zacząć od zajrzenia na stronę programu.

– –

Tłumaczenie przy użyciu webinterfejsów

Spora część aplikacji, które są rozwijane już dłuższy czas, dorobiła się mechanizmów ułatwiających tłumaczenie. Najczęściej są to wyspecjalizowane serwisy, z których najpopularniejsze są Weblate i Crowdin. Jeżeli na stronie projektu znajdziecie wzmiankę o którymś z nich, wasza praca przy tłumaczeniu będzie prosta i wygodna.

Zabawa zaczyna się od założenia konta w używanym przez dany program serwisie, po czym przechodzimy do wybranego projektu. Na liście dostępnych języków szukamy tego, na który chcemy tłumaczyć. Jeżeli już jest, możemy od razu przejść do tłumaczenia, w przeciwnym przypadku, trzeba najpierw go dodać.

W Weblate robi się to kliknięciem mało rzucającego się w oczy plusa, znajdującego się po lewej stronie nad ikonkami ołówka przy liście dostępnych tłumaczeń. Potem wybieramy język, na który chcemy tłumaczyć i klikamy „Rozpocznij nowe tłumaczenie”.

Na Crowdin trzeba kliknąć „Poproś o nowy język” i poza wyborem języka dodać wiadomość dla osób zarządzających projektem. Nie miałem okazji tego robić, ale zakładam, że taka prośba musi być ręcznie zatwierdzona, więc być może trzeba będzie trochę poczekać.

Gdy mamy już konto i wybrany język jest dostępny na liście tłumaczeń, możemy przystąpić do pracy, chyba że trafiliśmy na rzadki wypadek, w którym osoba rozwijająca oprogramowanie wymaga zaakceptowania „Contributor Licence Agreement”. Do tej pory przydarzyło mi się to tylko raz, przy tłumaczeniu Pachli.

Teraz już naprawdę możemy zabrać się za tłumaczenie. W większości małych i średnich programów całość tekstów do przetłumaczenia (nazywanych wiadomościami lub ciągami) jest zebrana w jednym module. Niektóre aplikacje, takie jak Pachli właśnie, rozbijają je na kilka różnych. Takie rozwiązanie ma swoje wady i zalety. Niektórym pewnie łatwiej ogarnąć garść ciągów na raz zamiast długiego zestawu, ja wolę raczej mieć wszystko w jednym miejscu.

No dobrze, mamy konto, wybrany język jest dostępny, zaakceptowaliśmy licencję i wklikaliśmy się w moduł do tłumaczenia. Co dalej? Zostało nam żmudne wypełnianie formularzy.

– –

Weblate

Powyżej znajduje się zrzut interfejsu Weblate z otwartym polskim tłumaczeniem Tuby. Pasek nad boksem „Tłumaczenie” pozwala na nawigację po ciągach i pokazuje aktualną pozycję na tle całości. Pole obok umożliwia wyszukiwanie ciągów spełniających określone wymagania (nieprzetłumaczone, oznaczone do dalszej edycji, z komentarzami itp.), a ostatnie służy do sortowania wiadomości do przetłumaczenia, dzięki czemu możemy np. szybko dotrzeć do ciągów ostatnio dodanych do aplikacji.

Główną część okna zajmuje miejsce na właściwe tłumaczenie. Pierwsze od góry jest pole z opisem ciągu dodawanym przez osoby tworzące aplikacje. Taki opis jest bardzo pomocny, zwłaszcza gdy trudno na podstawie ciągu źródłowego zorientować się, jaki jest kontekst jego wystąpienia, lub gdy w wiadomości występują jakieś zmienne (tutaj to %s oznaczające ilość wpisów).

Szkoda, że stosowanie opisów nie jest powszechniejsze, bo często zdarza się, że trudno zorientować się, jak najlepiej przetłumaczyć komunikat, bo np. w aplikacji oryginalny zwrot występuje w kilku miejscach, a każde wystąpienie po polsku będzie brzmiało inaczej. Tutaj może pomóc znajdująca się w prawej kolumnie informacja „Położenie ciągu źródłowego”, dzięki której możemy jednym kliknięciem otworzyć plik źródłowy i zobaczyć, gdzie znajduje się ten ciąg. Niestety, wymaga to chociaż podstawowej umiejętności czytania kodu.

Prawie zawsze w czasie tłumaczenia poza oknem, w którym pracuję, mam otwartą też aplikację, nad która pracuję, oraz repozytorium z kodem źródłowym, żeby móc odnaleźć kontekst, w którym występuje przekładany akurat tekst.

Pod opisem mamy oryginalną wiadomość. Tu wybrałem dla was rzecz trochę rzadszą, bo mamy do czynienia z rzeczownikiem z liczbą pojedynczą i mnogą. Jak widzicie, w angielskim to są dwa pola, u nas już trzy, ponieważ „posts” będziemy tłumaczyć inaczej w zależności od tego, czy to są „trzy wpisy”, czy „pięć wpisów”. Czerwone magiczne zaklęcie pod polami na tłumaczenie to formuła definiująca, dla jakich liczb występują odmienne formy liczby mnogiej.

Zazwyczaj jednak mamy do czynienia z prostą wersją jeden ciąg źródłowy = jeden ciąg przetłumaczony, ale wolałem wyjaśnić sprawę form liczby mnogiej, żebyście się nie dziwili, o co tu chodzi.

Pod polami na tłumaczenie znajduje się pole „Wymaga edycji”. Można go użyć, gdy np. nie jesteśmy pewni tłumaczenia i będziemy chcieli do niego wrócić.

Dwa z trzech przycisków poniżej są dość oczywiste: „Zapisz i kontynuuj” zapisze nasze tłumaczenie i przejdzie do następnego ciągu, „Zapisz i zostań” również zapisze, ale pozostanie w miejscu. Co robi „Zaproponuj”? Jeżeli chcemy poprawić czyjeś tłumaczenie, ale bez wcinania się w pracę tej osoby, możemy zaproponować swoją wersję. Taką sugestię osoba tłumacząca będzie potem mogła zaakceptować lub odrzucić, czasem też dodając komentarz tłumaczący decyzję.

Pod tłumaczeniem znajduje się pięć kart z przydatnymi narzędziami. Pierwsze z nich to „Ciągi sąsiadujące”, pozwalające czasem na umieszczenie wiadomości w kontekście lub przypomnienie sobie tłumaczenia zbliżonych tekstów. „Komentarze” to po prostu miejsce na skomentowanie tłumaczenia, z możliwością oznaczania zarówno innych tłumaczy, jak i osób tworzących aplikację. „Automatyczne sugestie” to tłumaczenia pochodzące z serwisu LibreTranslate oraz podsuwane na podstawie pamięci tłumaczeń, w której wyszukiwane są tłumaczenia podobnych ciągów. W „Innych językach” możemy sprawdzić, jak ten ciąg był przełożony w innych wersjach językowych, co jest przydatne raczej tylko dla osób posługujących się wieloma językami, a karta „Historia” pozwala na prześledzenie zmian w tłumaczeniu: kto, jak i kiedy przełożył ciąg.

W kolumnie po prawej, poza wspomnianym już odnośnikiem do pliku źródłowego, znajdują się informacje dotyczące ciągu, w tym data powstania i ostatniej aktualizacji. Powyżej znajduje się funkcja, której jeszcze nigdy nie użyłem, czyli „Słownik”, który pozwala na zapisanie własnych terminów, co pewnie jest bardzo przydatne zwłaszcza przy tłumaczeniu aplikacji używającej jakiejś zaawansowanej terminologii, gdy musimy pamiętać specjalistyczne słownictwo.

– –

Crowdin

Muszę przyznać, że nie jestem fanem Crowdin i jego interfejs uważam za mniej wygodny niż Weblate. Jak widać na zrzucie powyżej, bardzo różni się od tego drugiego serwisu, ale po przyjrzeniu się rozpoznacie podobne elementy. Lewa strona to przeglądarka ciągów (można przełączyć ją na przeglądanie plików) z opcjami ich filtrowania i sortowania.

Część środkowa to ciąg źródłowy z kontekstem (i możliwością zapytania o niego) oraz miejsce na tłumaczenie. Poniżej znajdują się informacje o tłumaczeniu oraz sugestie z pamięci tłumaczeń oraz tłumaczenia maszynowego Crowdin Translate. Jest też możliwość podejrzenia wersji w innych językach.

Prawa strona to miejsce na komentarze tłumaczy, w tym przypadku proszących o zmianę, gdyż forma, w jakiej ciąg występuje w aplikacji, nie działa w ich językach.

Zamiast komentarzy można włączyć panel przeszukiwania pamięci tłumaczeń, słownika i kontekstu, oraz asystenta AI (ha, tfu!).

– –

Tłumaczenie poprzez edycję plików

Tu już mamy do czynienia z trochę bardziej zaawansowanym tematem, bo takie tłumaczenie wymaga znajomości podstaw obsługi repozytoriów git i gotowości do posługiwania się trybem tekstowym. Konieczność sięgnięcia po ten tryb tłumaczenia pojawia się zwłaszcza w przypadku młodych projektów, które nie dorobiły się jeszcze integracji z np. Weblate.

Zanim zabierzemy się za jakiekolwiek dłubanie, warto sprawdzić, czy aplikacja w ogóle jest przetłumaczalna, czyli osoby ją tworzące napisały ją w sposób pozwalający na wyświetlanie różnych wersji językowych. Najprościej to zrobić rozglądając się w repozytorium kodu programu za katalogiem z plikami tłumaczeń.

Jeżeli aplikacja korzysta z gettext, czyli najpopularniejszego systemu tworzenia wielojęzycznego oprogramowania, to katalog ten najczęściej nazywa się po prostu po, ale spotkałem też np. i18n oraz l10n.

Te dwa ostanie ciągi znaków to sprytne skróty oznaczające internationalization oraz localization, a cyferki w nich to po prostu liczba znaków między pierwszą a ostatnią literą.

Jeżeli nie znajdziecie żadnego śladu po wersjach językowych w kodzie aplikacji, to jedyne, co możecie zrobić, to skontaktowanie się z osobami ją rozwijającymi i zasugerowanie dodania obsługi wielu języków. Najprościej to zrobić przez dodanie Issue na stronie projektu, najlepiej z tagiem Enhancement.

Jeśli jednak aplikacja okaże się przekładalna, możemy brać się za tłumaczenie. Żeby to zrobić, trzeba zacząć od stworzenia własnej kopii repozytorium, czyli zrobienia forka, do czego będziemy potrzebować konta w serwisie, w którym jest rozwijany dany program (np. Codebergu, GitHubie lub GitLabie).

W tej części będę sporo posługiwać się systemem kontroli wersji o nazwie Git. Pozwala on na zapanowanie nad zmianami w kodzie i np. cofanie ich, jeżeli były błędne, a także tworzenie gałęzi, w których trwa rozwój różnych funkcjonalności i późniejsze ich scalanie. Większość rzeczy będzie można załatwić przez interfejsy WWW, ale jeżeli spróbujecie obsługi z linii poleceń, możecie uznać, że jest dużo wygodniejsza i szybsza. W poznaniu obsługi git mogą pomóc gry w rodzaju Oh My Git!, Learn Git Branching czy GitMastery.

– –

Jak wygląda przebieg tłumaczenia pokażę na przykładzie Blood Pressure, aplikacji, którą znalazłem niedawno na Flathub.org, po tym, jak lekarz kazał mi przez tydzień mierzyć ciśnienie i zapisywać wyniki.

Po zalogowaniu na gitlab.com i przejściu do strony projektu klikam na przycisk Fork w prawym górnym rogu, po czym wypełniam krótki formularz. Zazwyczaj po prostu dodaję litery PL do nazwy repozytorium i informację w rodzaju „Polish translation” do opisu, tym razem się rozpisałem trochę bardziej

W tym momencie mam już swoje repozytorium i mogę zabierać się od razu za tłumaczenie. Mógłbym to zrobić przez edycję plików przy użyciu interfejsu GitLaba, ale wygodniej mi będzie pracować na plikach na dysku.

Jeżeli chcecie uniknąć pracy w terminalu, gdzie się tylko da, to po kliknięciu zielonego przycisku Code wybieracie opcję Download ZIP, to jednak oznacza, że stworzone i zmodyfikowane pliki będziecie trzeba wgrywać przez przeglądarkę.

Jeśli wybierzecie tryb tekstowy, to repozytorium klonuje się poleceniem git clone, po którym można podać albo adres sieciowy repozytorium w rodzaju

git clone https://gitlab.com/LukaszH77/cisnienie-krwi.git

albo SSH

git clone git@gitlab.com:LukaszH77/cisnienie-krwi.git

Ta druga opcja jest na dłuższą metę wygodniejsza, ale wymaga konfiguracji kluczy SSH w systemie oraz w serwisie z repozytorium. Ten wpis i tak będzie bardzo długi, więc nie podejmę się w nim jeszcze tłumaczenia działania i tworzenia kluczy SSH. Zarówno GitLab, jak i GitHub oraz Codeberg mają tę procedurę opisaną krok po kroku.

W końcu mamy pliki na dysku i można się przyjrzeć, z czym będziemy pracować.

Tłumaczenia przy użyciu systemu gettext opierają się na kilku rodzajach plików. POTFILES (lub POTFILES.in) zawiera listę plików źródłowych, w których znajdują się przetłumaczalne ciągi, a LINGUAS to lista języków, na które przetłumaczono aplikację. Plik z rozszerzeniem .pot (zazwyczaj nazwa_programu.pot) to wygenerowany przez gettext szablon tłumaczenia i na jego podstawie powstają pliki .po z konkretnymi wersjami językowymi (np. pl.po dla polskiego, pt_BR.po dla brazylijskiej wersji portugalskiego itd.).

W przypadku Blood Pressure nie było tego pierwszego pliku, więc postanowiłem przy okazji uzupełnić ten brak. Po jego przygotowaniu mogłem wygenerować szablon tłumaczenia poleceniem

xgettext --from-code=UTF-8 --keyword=_ --keyword=C_:1c,2 --output=po/blood-pressure.pot -f po/POTFILES

Parametry użyte w tym poleceniu wskazują jak jest kodowany plik, jak oznaczane w kodzie są przetłumaczalne ciągi, jak ma nazywać się tworzony plik .pot oraz z jakiej listy ma skorzystać.

Na podstawie szablonu plik z tłumaczeniem tworzy się komendą

msginit --locale=pl --input=blood-pressure.pot

wydanym w podkatalogu po.

--locale=pl oznacza oczywiście, że generujemy plik dla języka polskiego, a --input=blood-pressure.pot wskazuje na plik szablonu tłumaczeń.

Po jej uruchomieniu zostaniemy zapytanie o adres e-mail, który ma być podany w pliku jako adres tłumacza. Po wpisaniu adresu i zatwierdzeniu powinien powstać plik pl.po, w którym będziemy wpisywali polskie tłumaczenie. Zanim się za to zabierzecie, warto najpierw otworzyć plik LINGUAS i dopisać pl w osobnym wierszu tak, żeby zachować alfabetyczną kolejność wpisów.

Tłumaczenie można załatwić w jakimkolwiek edytorze tekstu, ponieważ pliki .po są plikami tekstowymi o określonej, dość prostej strukturze. Wiersze zaczynające się od msgid zawierają oryginalny tekst, a w liniach poprzedzonych msgstr wpisujemy tłumaczenie. Każda taka para jest poprzedzona komentarzem zawierającym ścieżkę do pliku i numer linii, w której występuje ciąg, co przydaje się, gdy chcemy sprawdzić kontekst, w jakim się pojawia.

Są jednak wygodniejsze sposoby na tłumaczenie plików .po, moim ulubionym jest program Gtranslator, który powstał na potrzeby tłumaczenia GNOME (o czym więcej napiszę w dalszej części). Można go zainstalować z Flathuba.

Interfejs Gtranslatora jest dość prosty. Główna część okna to lista ciągów i ich tłumaczeń, które wpisuje się w polu na dole. To, co nas interesuje w tej chwili w panelu po prawej, to pola „Wydobyte komentarze” gdzie trafiają informacje dołączone przez osoby tworzące program oraz „Ścieżki” zawierające dane o tym, w jakim pliku i wierszu występuje wybrany komunikat.

Polecam zapoznanie się ze skrótami klawiszowymi (np. Alt + -> to następny komunikat, a Alt + Page Down przechodzi do następnej nieprzetłumaczonej wiadomości), dzięki którym poruszanie się po pliku jest szybkie i wygodne.

Po przygotowaniu tłumaczenia trzeba je wrzucić do naszego repo. Jako że sklonowałem repozytorium przy użyciu git clone, to teraz mogę załatwić to wygodnie w terminalu. Najpierw przy pomocy git add dodaję po kolei pliki (całość zmian można od razu dodać komendą git add .), które utworzyłem lub zmodyfikowałem, a potem poleceniem git commit -m "Opis zmian" tworzę zatwierdzenie. Na koniec zostaje użycie git push do wypchnięcia zmian do zdalnego repozytorium na GitLabie.

Jeżeli zamiast klonować repozytorium pobraliście tylko archiwum zip i pracowaliście na wypakowanych plikach, wszystkie te, które stworzyliście i zmieniliście, musicie teraz przez interfejs WWW wgrać do odpowiednich katalogów, co w przypadku GitLaba załatwia się nawigując po drzewie plików, a po wybraniu właściwego miejsca klikając na ikonkę plusa i wybierając pozycję „Upload file”. Oczywiście także w tym wypadku trzeba będzie podać opis zmiany.

Ostatni krok to wysłanie zmian do oryginalnego repozytorium programu. Na stronie mojego forka klikam „Create merge request” i w formularzu, który się wyświetli mogę opisać na czym polegają zmiany.

Zazwyczaj załatwiam to wcześniej, już w wiadomości dołączonej do zatwierdzenia zmienianych plików i na tej podstawie wypełniany automatycznie jest tytuł merge request, więc muszę tylko zatwierdzić wysłanie oraz zaczekać aż osoby rozwijające aplikację przejrzą moje zmiany i je zatwierdzą.

– –

Praca w polskim zespole GNOME

Właśnie zobaczyłem, że wpis przekroczył już 2,5k słów, więc postaram się tę ostatnią część ograniczyć do minimum.

Jak już nabierzecie trochę doświadczenia przy tłumaczeniu różnych aplikacji, to zapraszam do ekipy tłumaczącej na język polski środowisko GNOME z przylegającymi aplikacjami. Praca tutaj trochę się różni od tej, którą pokazywałem powyżej. Trzeba zacząć od założenia konta w serwisie Damned Lies, zwanego w skrócie DL. Niestety nie można zrobić tego bezpośrednio, tylko trzeba do tego użyć SSO z np. GitLaba lub GitHuba.

Następnym krokiem jest dołączenie do polskiego zespołu. Zespół jest w trakcie reorganizacji, która nałożyła się na natłok pracy przy wydaniu GNOME 50, ale nowa koordynatorka to osoba bardzo dynamiczna i sprawy idą w dobrą stronę. Dorobiliśmy się już forum na oficjalnym Discourse GNOME oraz kanału Matrix, który jest najlepszym sposobem na komunikację z resztą zespołu i zadawanie pytań związanych z tłumaczeniem.

Jeżeli mamy wybrany moduł, który chcemy przetłumaczyć, pracę nad nim trzeba zacząć od zarezerwowania go do tłumaczenia poprzez formularz na stronie modułu. Możemy przy okazji dopisać komentarz, chociaż nie jest to konieczne. Potem pobieramy plik PO i zabieramy się za tłumaczenie.

Do tłumaczenia najlepiej wykorzystać Gtranslatora, którego polecałem wyżej. Można go połączyć ze swoim kontem na Damned Lies (po wpisaniu w danych profilu naszego tokenu z DL), co teoretycznie pozwoli na pobieranie i wgrywanie plików (chociaż ja wolę załatwiać to przez strony modułów, bo mogę od razu np. wyklikać rezerwację). Bardziej ciekawą możliwością jest pamięć tłumaczeń, którą można sobie zbudować na podstawie innych tłumaczeń zespołu.

Dzięki skryptowi udostępnionemu przez brazylijską ekipę przygotowałem zbiorczy plik .po z całości tłumaczeń przygotowanych dla GNOME50 i udostępniam go na swoim koncie na Codebergu. Po ściągnięciu pliku trzeba jego położenie wskazać Gtranslatorowi (Menu główne -> Zbuduj pamięć tłumaczeń). Od tej chwili w panelu po prawej będziecie mieli podpowiedzi tłumaczeń podobnych ciągów.

Po skończeniu tłumaczenia i zapisaniu pliku otwieramy znowu stronę modułu i w formularzu wybieramy opcję „Wyślij nowe tłumaczenie” i wgrywamy plik. Takie tłumaczenie musi zostać przejrzane przez osobę z uprawnieniami do recenzowania i jeżeli będzie poprawne, to zostanie zatwierdzone i wypchnięte do repozytorium.

Może się zdarzyć, że zamiast tego dostaniemy recenzję z informacjami, które ciągi mają błędy i jak je należy poprawić tak, by spełniały standardy zespołu. Aby ograniczyć prawdopodobieństwo poprawek, warto pamiętać m.in. o tym, że po każdym jednoliterowym spójniku (a, i, o, u, w, z) powinna znaleźć się niełamliwa spacja (wstawiana za pomocą Prawy alt + Spacja), dzięki czemu przy dzieleniu tekstu na wiersze, na ich końcu nie będą wisieć pojedyncze litery.

Zespół planuje przygotowanie wytycznych dotyczących tłumaczenia (np. preferowanych form gramatycznych dla różnych elementów interfejsu oraz używania form neutralnych płciowo) i gdy będą gotowe, to je tutaj podczepię, ale na razie warto przyjrzeć się temu, jak wyglądają dotychczasowe tłumaczenia, a w razie wątpliwości zapytać w naszym pokoju Matrix.

– –

Myślę, że to najwyższy czas, żeby zakończyć ten wpis i cały cykl. Mam nadzieję, że pokazując tyle różnych sposobów na zaangażowanie się w FOSS uda mi się namówić do tego chociaż jedną osobę.

Jeżeli macie jakieś pytania dotyczące poruszonych w tych wpisach zagadnień, lub uważacie, że podane przeze mnie informacje wymagają uzupełnienia, a być może są błędne, to proszę dajcie znać w komentarzach. Z chęcią poznam wasze zdanie i uzupełnię swoje braki w wiedzy.

Spis treści

• Testowanie wersji rozwojowych aplikacji
  • Wydania nightly
  • Przy użyciu GNOME Buildera
  • Z ręcznym budowaniem pakietów flatpak
  • Kod spoza głównej gałęzi repozytorium
  • Jak testować?
• Pomaganie innym osobom używającym WiOO i advocacy
• Wsparcie finansowe osób rozwijających FOSS

– –

Testowanie wersji rozwojowych aplikacji

O wyłapywaniu błędów w czasie używania programów i ich zgłaszaniu pisałem w pierwszej części, tym razem opowiem o używaniu niewydanych jeszcze wersji, samodzielnym budowaniu i instalowaniu oprogramowania prosto z repozytorium, po to, by przetestować nowe funkcje i wychwycić błędy jeszcze zanim program zostanie udostępniony zwykłym użytkownikom.

To zagadnienie bardziej zaawansowane, wymagające umiejętności korzystania z trybu tekstowego i instalowania potrzebnych programów i bibliotek. Jeżeli jeszcze nie masz tych umiejętności w swoim repertuarze, to może być właśnie dobra okazja na uzupełnienie braków.

O ile stosunkowo często zdarza mi się zgłaszanie błędów w różnych programach, to za testowanie wersji rozwojowych biorę się tylko w przypadku programów, które naprawdę lubię i rozwijają się na tyle szybko między wydaniami, żeby było warto sprawdzać, co ciekawego się w nich dzieje.

Robiłem tak np. z Tubą (klientem fediwersum), Scratchmarkiem (edytorem Markdown, w którym piszę wszystkie teksty na bloga), a ostatnio z Tonearm, natywnym klientem Tidala.

Wymaga to trochę więcej pracy niż zwykłe używanie i ewentualne zgłaszanie zauważonych błędów, ale jest też bardzo satysfakcjonujące, zwłaszcza jeżeli jest się osobą, którą cieszy zdobywanie nowych umiejętności i lubi dłubać w terminalu.

Wiadomości, którymi się poniżej podzielę, pewnie będą banalne dla bardziej zaawansowanych, ale sam nieraz musiałem się naszukać i nadłubać, zanim załapałem co i jak. Przyznaję, że mimo zebranego doświadczenia i tak zdarza się, że w niektórych przypadkach działam trochę po omacku, co zresztą jest dla mnie sporą częścią frajdy, jaką mam z tej całej zabawy.

– –

Korzystanie z wydań niestabilnych

Zanim zabierzecie się za samodzielne budowanie niewydanych jeszcze wersji programów, sprawdźcie czy czasem osoby tworzące aplikację nie udostępniają wydań niestabilnych, często budowanych codziennie. Jeżeli się nie mylę, to Firefox wprowadził nazwę nightly na takie wydania i od tego czasu widuję ją używaną w innych projektach.

Czasem nie są dostępne w jakimś rzucającym się w oczy miejscu na stronie projektu, tylko trzeba się do nich doklikać. W przypadku Tonearm osoby rozwijające program włączyły automatyczne budowanie pakietów, do których można się dostać po wybraniu interesującej nas zmiany w repozytorium w sekcji Actions.

Takie rozwiązanie bardzo ułatwia życie osób chcących testować aplikacje w czasie ich rozwoju. Niestety, zazwyczaj nie jest dostępne i trzeba radzić sobie samodzielnie.

– –

Budowanie przy pomocy GNOME Builder

W wielu przypadkach, zwłaszcza gdy mowa o aplikacjach tworzonych dla ekosystemu GNOME, najłatwiej będzie do ich budowania i instalacji wykorzystać program GNOME Builder. To zintegrowane środowisko programistyczne (IDE) najprościej zainstalować z Flathuba.

Po odpaleniu Buildera otwiera się okno powitalne, w którym można stworzyć nowy projekt albo otworzyć znajdujący się już na dysku, ale nas interesuje pobranie źródeł programu z jego repozytorium, które umożliwia znajdujący się na dole okna przycisk „Sklonuj repozytorium…”.

Dostępny w tej chwili Builder jest spolszczony w 36%, ale dopiero co skończyłem jego pełne tłumaczenie, które w tej chwili musi zostać przejrzane przez koordynatorkę zespołu przekładającego GNOME na język polski i po poprawkach będzie mogło zostać włączone do następnego wydania.

W następnym oknie wklejacie adres repozytorium i wybieracie, do jakiego folderu mają trafić źródła. Możecie tam też podać swoje dane, na wypadek, gdybyście chcieli zmieniać kod i wysyłać poprawki.

Adres URL repozytorium ma formę https://serwis/autor/projekt.git. Na GitHubie schowany jest pod zielonym przyciskiem „Code”, a na GitLabie pod niebieskim. Po jego kliknięciu zobaczycie adres HTTPS, a obok ikonkę kopiowania go do schowka. Na Codebergu nie trzeba nic rozwijać, można od razu klikać przycisk kopiowania znajdujący się obok pola z adresem.

Po zatwierdzeniu klonowania Builder pobierze źródła z głównej gałęzi programu i otworzy projekt. Dla osób niezaznajomionych z edytorami dla programistów interfejs Buildera może wydawać się nieprzyjazny i skomplikowany. Najważniejsze dla nas rzeczy kryją się na górze w centrum ekranu. Znajdziecie tam ikonkę młotka, która uruchamia budowanie projektu. Na prawo od niej jest strzałka w dół rozwijająca listę działań. Warto rozpocząć od kliknięcia „Update Dependencies…”, co zainstaluje pakiety potrzebne do zbudowania programu.

Gdy ten proces zakończy się sukcesem, można kliknąć młotek lub wybrać „Zbuduj” z menu. W dolnej części ekranu zaczną wyświetlać się proces budowania, który powinien przelecieć bez problemów, o ile w systemie macie wszystkie potrzebne narzędzia. Czasem wywali się z informacją o nieznalezionym poleceniu czy bibliotece, wtedy będzie trzeba użyć narzędzia zarządzania oprogramowaniem waszej dystrybucji i doinstalować potrzebne rzeczy.

Jeżeli wszystko się powiedzie, to na pasku na lewo od młotka wyświetli się napis „Pomyślnie zbudowano”. W tym momencie możecie kliknąć ikonkę trójkąta po prawej, by uruchomić program, co zazwyczaj wystarcza do testowania. Można też stworzyć pakiet flatpak, wybierając „Export” z menu.

– –

Ręczne budowanie

Niektóre programy nie dawały mi się zbudować w powyższy sposób, całkiem możliwe, że przez mój brak umiejętności i wiedzy do tego potrzebnej. W takich wypadkach załatwiam to ręcznie.

Jeżeli nie macie kopii repozytorium utworzonej w Builderze, można to zrobić bez niego. Otwieramy terminal w katalogu, w którym ma znaleźć się kod źródłowy i używamy polecenia git clone. Na przykład w przypadku Tonearm to

git clone https://codeberg.org/dergs/Tonearm.git

Następny krok to sprawdzenie na stronie projektu, czy są tam zamieszczone instrukcje budowania/instalacji. Niekiedy znajdziecie tam dokładne polecenie i wystarczy je skopiować do terminala, by zbudować program, oczywiście, jeżeli macie zainstalowane wszystkie zależności.

Niektóre programy mają skrypty zajmujące się budowaniem i instalowaniem. Na przykład w katalogu build-aux źródeł Scratchmark znajduje się skrypt generate_flatpak.sh, którego wywołanie buduje pakiet Scratchmark.flatpak, który można potem zainstalować poleceniem

flatpak install Scratchmark.flatpak --user

Opcja --user powoduje zainstalowanie pakietu wyłącznie dla aktywnego użytkownika. Dzięki temu jeżeli dzielimy komputer z innymi osobami, nie będą widziały w swoim menu potencjalnie niestabilnej wersji aplikacji.

Czasem jednak instrukcji nie ma i trzeba sobie radzić bez nich. Tak było właśnie w przypadku Tonearm, gdy zaczynałem kręcić się przy tej aplikacji. Na szczęście po wcześniejszych doświadczeniach wiedziałem, co zrobić. Rozejrzałem się za zawierającym manifest budowania plikiem .json lub .yaml, który znalazłem w build/flatpak, a potem wydałem polecenie

flatpak-builder --force-clean --install-deps-from=flathub --user --install build dev.dergs.Tonearm.yaml

Dodanie --install-deps-from=flathub spowoduje, że brakujące zależności zostaną dociągnięte z repozytorium flathuba, a --force-clean usunie pliki wygenerowane w czasie poprzedniego budowania.

Jeżeli proces budowania i instalowania przebiegnie bez błędów, można się zabrać za testowanie.

– –

Kod spoza głównej gałęzi repozytorium

Zazwyczaj opisane powyżej sposoby instalacji programów ze źródeł pobranych z repozytorium wystarczają do testowania wersji rozwojowej. Czasem jednak rozwój nowych funkcjonalności odbywa się poza główną gałęzią repo (najczęściej nazywającą się main lub master) i kod ją zawierający trafia do niej dopiero po doszlifowaniu.

Niektóre projekty mają stałą gałąź w rodzaju dev lub devel, w większości przypadków gałęzie powstają na potrzeby konkretnych zmian i mają zazwyczaj dość oczywiste nazwy, np. feat/nowy-edytor albo fix/wycieki-pamieci. Żeby przetestować taką wersję programu, trzeba przełączyć źródła na wybraną gałąź.

W Builderze po lewej stronie pola, w którym były wyświetlane komunikaty budowania aplikacji, znajduje się kolumna ikonek. Druga od góry przełącza na terminal, w którym wpisujemy polecenie git switch. Po naciśnięciu klawisza TAB pokaże się lista dostępnych gałęzi, na której odszukujemy tą, która nas interesuje i dopisujemy do polecenia

git switch feat/nowy-edytor

Przy ręcznym budowaniu po prostu używamy tego samego polecenia w terminalu, po wejściu do katalogu ze źródłami.

Po przełączeniu na wybraną gałąź dalsze budowanie jest takie samo, jak opisałem powyżej.

Jeżeli od sklonowania repozytorium do chwili budowania programu minęło trochę czasu, można je zaktualizować, pobierając zmienione pliki poleceniem git pull wydanym w główny katalogu repo, a ponowne przestawienie repozytorium z bocznej gałęzi na główną załatwiamy oczywiście poleceniem git switch main.

– –

Jak testować?

Niezależnie od tego, w jaki sposób zainstalowaliście testową wersje programu, testowanie wygląda tak samo. Najprostsza opcją jest po prostu używanie programu jak zazwyczaj, z jednoczesnym zwracaniem uwagi na zamykanie się aplikacji, skoki zajęcia pamięci, zamulenie, niedziałające elementy. Po natrafieniu na takie problemy zgłaszamy je w sekcji Issues strony programu, co opisałem już w poprzedniej części. Pamiętajcie o wcześniejszym upewnieniu się, że problem jeszcze nie został zgłoszony.

Bardziej zaawansowaną opcją jest sprawdzenie, co się zmieniło od ostatniego wydania i testowanie rzeczy z tej listy. Żeby to zrobić trzeba wejść na zakładkę Wydania (Relases) na stronie projektu i wybrać najnowsze, a po jego otwarciu poszukać odnośnika w rodzaju „15 commits to master since this release”, który otworzy stronę zawierające listę wszystkich zmian, które zaszły w repozytorium od tego czasu.

Lista, którą zobaczycie, może w pierwszej chwili może wydawać się nieczytelna i przytłaczająca, zwłaszcza jeżeli w repozytorium sporo się wydarzyło od czasu ostatniego wydania. Na szczęście da się to dość łatwo ogarnąć, o ile osoby rozwijające program dbają o sensowne opisywanie zmian.

Zazwyczaj można zignorować aktualizacje tłumaczeń oraz zmiany oznaczane jako chore, które z reguły dotyczą np. aktualizacji zależności i podobnych zabiegów związanych z utrzymaniem kodu. Te, które nas interesują, często są mają oznaczenia fix dla zmian łatających błędy oraz feat dla dodających nowe funkcjonalności lub zmieniających działanie dotychczasowych.

Testowanie pierwszych jest bardziej oczywiste, zwłaszcza jeżeli dotyczy błędów, które zgłaszaliśmy. Odtwarzamy okoliczności, w których błąd występował i sprawdzamy, czy nadal tak się dzieje. Jeżeli jest już naprawiony, warto w komentarzu pod konkretną zmianą napisać, że poprawka zadziałała. Jeżeli błąd pojawia się nadal, tym bardziej warto dać o tym znać.

Te drugie pewnie są najbardziej atrakcyjne – ja sam mam wielką frajdę, gdy mogę używać rzeczy, które są jeszcze niedostępne dla osób korzystających tylko ze stabilnych wydań i często robię to jako pierwsza osoba po bezpośrednio zaangażowanych w rozwój programu. Poza sprawdzeniem, czy dodany/zmieniony element aplikacji działa tak, jak powinna, warto spojrzeć na to, jak łączy się z jej resztą i czy np. nie psuje używalności, albo jeżeli się sprawdza, czy nie pasowałby też w innych miejscach.

Przykład 1: Niedawno do Scratchmark doszła możliwość zmiany rozmiaru tekstu w edytorze za pomocą skrótów Ctrl+ i Ctrl-. Osoba rozwijająca Scratchmarka uznała, że skoro można ustawić rozmiar czcionki w ten sposób, to może usunąć ustawianie rozmiaru w preferencjach. Zgłosiłem w pokoju Matrix aplikacji, że IMHO to nie jest najlepszy pomysł, bo skoro możemy tam zmienić krój czcionki, to dziwne będzie, jeżeli nie będziemy mogli zmienić tam również jej rozmiaru. Za to jak najbardziej powinna się tam znaleźć informacja, że wielkość tekstu można zmienić też w czasie pisania za pomocą skrótów klawiszowych.

Przykład 2: Zaproponowałem dodanie do Tonearm podglądu okładek albumów, co dość szybko zostało zrealizowane. Gdy przetestowałem wersję z tą zmianą odkryłem, że działa to wyłącznie po kliknięciu z okładkę obecnie odtwarzanego utworu, która i tak jest dość powiększona w panelu odtwarzacza, za to nie działa z okładkami na stronach albumów, jeżeli ich nie odtwarzamy, a tam przydałoby się bardziej, bo okładki są dużo mniejsze, więc słabiej widoczne. W tym przypadku również zasugerowałem zmianę na Matriksie.

Matrix jest sposobem komunikacji popularnym w świecie FOSS. To taki Discord dla geeków – otwarty i niezależny od korporacji. Mniej wybajerzony, ale IMHO bardziej wygodny. Gorąco zachęcam do korzystania z niego, bo jest dobrym sposobem na bezpośrednią komunikację z osobami rozwijającymi WiOO, mniej formalną niż wypełnianie issues na stronach projektów. Jeżeli zdecydujecie się spróbować, to polecam polski serwer noevil, na którym mam swoje konto oraz klienta o nazwie Fractal.

– –

Pomaganie innym osobom używającym WiOO i advocacy

Jeżeli propozycje, które przedstawiłem w poprzedniej części i powyżej to dla was za dużo zachodu, to teraz pokażę działalność, która w przeciwieństwie do powyższych nie wymaga dłubania, a jedynie chwili wolnego czasu.

Sporą częścią całego środowiska WiOO jest wzajemne pomaganie. Kiedyś było to dużo łatwiejsze, po prostu siedzieliśmy na usenetowej grupie (alt.pc.comp.os.linux.newbie na zawsze w moim sercu, jeżeli ktoś z a.p.c.o.l.n. to czyta, to pozdrawiam serdecznie) i w miarę możliwości odpowiadaliśmy na pytania, które się na niej pojawiały. Polecaliśmy programy, kompatybilny sprzęt, podpowiadaliśmy sposoby rozwiązywania problemów, dzieliliśmy się sztuczkami, skryptami, pisaliśmy FAQ itd.

Usenet niestety odszedł w niepamięć, ustępując pola forom dyskusyjnym, które z kolei prawie wyginęły po nastaniu czasu mediów społecznościowych i discordów, przetrwały chyba głównie w formie poświęconej konkretnym dystrybucjom, np. Arch, Debian, Fedora, Mint, openSUSE, Ubuntu. To bardzo dobre miejsca, aby pomóc osobom zaczynającym przygodę z Linuksem i szukających rozwiązania jakiegoś problemu. Jeżeli tylko macie wiedzę, którą możecie się podzielić, to z pewnością znajdziecie tam osoby, którym się ona przyda.

Jeżeli nie macie ochoty zaglądać na fora, to zostają jeszcze media społecznościowe. Co prawda na takim Facebooku czy Twitterze raczej nie będzie okazji do zaangażowania się w taką działalność (no chyba, że są jakieś grupy okołoFOSSowe na fb), ale w fediwersum to dość popularny temat, więc na pewno trafi się okazja polecić jakiś program, podpowiedzieć rozwiązanie problemu, a może nawet zagadać bezpośrednio do osób rozwijających WiOO. Fedi zresztą jest świetne jako sposób do trzymania palca na pulsie świata FOSS, sam śledzę w ten sposób np. dystrybucje Linuksa, klienty Mastodona i innych platform oraz garść innych programów WiOO.

Poza pomaganiem przy rozwiązywaniu problemów, można w takich miejscach zająć się głoszeniem dobrej nowiny o FOSS, czyli tak zwanym advocacy. Można np. pokazywać zalety używania Linuksa zamiast zamkniętych systemów operacyjnych czy polecać ciekawe aplikacje WiOO, na które natrafiliście. Warto to robić nienachalnie i bez pogardy dla innych systemów. Na a.p.c.o.l.n. mieliśmy zasadę, że skoro nie chcemy, żeby ktoś pisał o „Linuchu”, to my nie mówimy o „Winshicie” itd. (obecnie zrobiłbym wyjątek od tej zasady dla „Microslopu”, jego użycie jest jak najbardziej uzasadnione, podobnie jak deadname’owanie Twittera).

Pamiętajcie przy tym, że odwieczna tradycja flejmów (flame wars) o wyższość jednej dystrybucji nad drugą, jak bardzo rozrywkowa by nie była, raczej nie przysłuży się celowi. Lepiej zamiast tego pokazać np. jak można wykorzystać Linuksa do grania (dzięki Steamowi i Protonowi) czy przedłużenia życia starszego sprzętu, niewspieranego już przez Windows.

Masa aplikacji FOSS jest pisana także na inne systemy, więc można polecać je bez namawiania do przesiadki na Linuksa.

– –

Wsparcie finansowe osób tworzących WiOO

Sporym problemem wśród osób rozwijających WiOO jest zmęczenie, a nawet wypalenie. Więcej o tym możecie przeczytać np. w artykule w serwisie „It’s FOSS”, opartym na badaniu Mirandy Heath z The University of Edinburgh, tu pozwolę sobie nawiązać tylko do jednego fragmentu.

Raport zawiera sześć czynników, które powodują stan wypalenia u osób rozwijających FOSS i ich odchodzenie od rozwijanych projektów. W skrócie to stres związany z przytłaczającym obciążeniem, poczuciem odpowiedzialności i potrzebą udowadniania własnej wartości. Osoby utrzymujące popularne oprogramowanie są zasypywane zgłoszeniami, a że często pracują solo, nie są w stanie sobie z tym poradzić. Jednocześnie czują zobowiązanie do dalszej pracy, bo porzucenie projektu byłoby jak zdrada.

Do tego dochodzi często toksyczne zachowanie społeczności: bezrefleksyjne wymaganie nowych funkcjonalności, bez zastanowienia się, czy osoba tworząca projekt ma czas i możliwości na ich realizację oraz bezwzględne krytykowanie wszelkich wpadek, podczas gdy dobra praca jest niedoceniania.

Kolejną kwestią jest fakt, że utrzymywanie istniejącego projektu jest mniej wynagradzające od tworzenia: programowanie nowej aplikacji czy biblioteki jest źródłem frajdy, ale utrzymywanie ich, naprawa błędów, aktualizacja zależności itp. to po prostu uciążliwa, powtarzalna praca.

Ostatnim czynnikiem są kwestie finansowe. Według raportu 60% osób utrzymujących przy życiu WiOO nie otrzymuje za to żadnego wynagrodzenia. Muszą najpierw wykonywać swoją pracę zarobkową, a po niej często odrabiają kolejny etat pracując przy jakimś projekcie FOSS, poświęcając swój czas przeznaczony na życie prywatne, rodzinę i przyjaciół.

Wszyscy lubimy fajne programy WiOO, chcemy by były dobrze zaprojektowane i działające, regularnie aktualizowane i naprawiane. Ale tak przywykliśmy do tego, że są dostępne za darmo, że rzadko myślimy, że ktoś płaci za ich rozwój swoim czasem. Nie jestem w stanie załatwić tym osobom etatów polegających na pracy nad FOSS, dlatego staram się co jakiś czas, w miarę możliwości, wesprzeć jakiś projekt, np. z okazji kolejnego wydania. To samo z osobami lub organizacjami utrzymującymi ważną infrastrukturę np. serwer Matriksa. Moje parę złotych dużo nie zmienia, ale jeżeli takich wpłat zbierze się więcej, mogą naprawdę pomóc. Jeżeli tylko możecie, to gorąco zachęcam, nawet jeżeli będzie to tylko równoważność jednej kawy czy innego napoju.

Jeżeli się na to zdecydujecie, to najlepszym sposobem będzie poszukanie na stronie ulubionego oprogramowania odnośników do serwisów w rodzaju Ko-Fi czy Liberapay, często wykorzystywanych jako metody na przekazywanie finansowego wsparcia.

– –

To koniec drugiej części, trzecia powinna pojawić się wkrótce. Tymczasem zapraszam do rozmowy – jeżeli macie jakieś pytania dotyczące poruszonych zagadnień lub uważacie, że podane przeze mnie informacje wymagają uzupełnienia, a może nawet są błędne, to proszę dajcie znać w komentarzach. Z chęcią poznam wasze zdanie.