Podręcznik dla chcących współtworzyć Kritę¶

Witaj w przewodniku Krity dla współtwórców!

Jeśli chciałbyś współtworzyć dokumentację Krity, to jesteś we właściwym miejscu.

Krita to (darmowy) program o otwartym kodzie, co w wyniku czyni z nas projekt społecznościowy, z wieloma wolontariuszami współtworzącymi go. To, oczywiście, wymaga od nas, aby dostępne były podręczniki dla nowych wolontariuszy, którzy chcieliby dołączyć i nam pomóc. Różne miejsca, w których to robiliśmy, były raczej rozproszone i często pozostawione bez opieki. Podręcznik współtwórcy jest próbą scalenia wszystkich tych danych. Jest on zatem bardzo techniczny w niektórych miejscach.

Ta dokumentacja będzie zawierała:

Podręcznik dla Krity

Jest to prawdopodobnie to, czego wszyscy oczekują, gdy wpiszą dokumentacja Krity . Suche, podstawowe, dane nt. tego «co ten przycisk robi».

Samouczki nt. ogólnych konceptów.

Przez ostatnie dwa lata odkryliśmy, że dla pewnego rodzaju użytkowników, podręcznik, nawet z przykładami, nie jest wystarczający. Podręcznik powinien zapewniać szybkie i zwięzłe wyjaśnienia rzeczy i pokazywać podstawowy obieg pracy w przygotowywaniu obrazu do użytku w sieci.

Odkryliśmy także, że niektóre koncepty, takie jak zarządzanie barwami i obsługa warstw są w Kricie dużo bardziej rozbudowane niż jest do tego przyzwyczajony artysta. Krita jest darmowa i większość z jej użytkowników nie ma formalnego przeszkolenia w cyfrowej sztuce. Tak więc nie było wcześniej istniejącej wiedzy dostosowanej dla artystów na temat tego jak zarządzać barwami lub warstwami filtrów.

W dodatku są systemy, które są niepowtarzalne dla Krity, np. system pędzli, maski przekształceń, dziedziczenie alfy oraz pomocnicy perspektywy. W końcu, są użytkownicy, którzy nie są zaznajomieniu nawet z podstawowym obiegiem pracy i nie są na tyle elastyczni, aby zrozumieć jak wykorzystać samouczek dla SAI lub Photoshopa w Kritę.

Wykaz znanych samouczków i filmów

Wspaniałą rzeczą w zespole Krity jest to, jak łączymy się z artystami i to, że zdajemy sobie sprawę z tego jak ciekawe rzeczy oni tworzą. To samo tyczy się samouczków, szczególnie pod względem tego, że jest wiele sposobów na używanie Krity, a także wiele sposobów malowania, które są niepowtarzalne i powinniśmy zachęcać ludzi do dzielenia się swoją wiedzą.

Podręcznik dla współtwórców

Co teraz czytasz!

Samouczki krita.org

Na krita.org oraz krita-foundation.tumblr.com znajduje się kilka samouczków, na tym pierwszym nt. tego jak używać niektórych z nowych możliwości, a na tym drugim samouczki na prośby użytkowników.

FAQ

Ten samouczek znajduje się już w sieci i jest scaleniem różnych najczęściej zadawanych pytań. Obecnie jest tłumaczony i mamy nadzieje, że będzie pierwszym miejscem uaktualnień.

Dla tych, dla których jest to pierwszy raz¶

W przeciwieństwie do Mediawiki, Sphinx działa raczej tak jak byśmy pisali kod dla Krity.

First things first, you will want to talk to us! For this you can join us in the chatroom „#krita” via matrix. A introduction about Matrix is given here. Log in to your Matrix client with an account from your instance of choice, and join the #krita:kde.org channel. Or more importantly, make an account at identity.kde.org. The account you make at identity can be used to both access invent.kde.org as well as the phabricator, where we organise Krita development.

Sphinx działa poprzez pisanie prostych plików tekstowych zawierających znaczniki reStructuredText, a następnie bierze te pliki tekstowe i zamienia je na podręcznik. Śledzimy zmiany w tym podręczniku, poddając go pod system do zarządzania wersjami zwany Git.

Wprowadzanie zmian¶

Ponieważ używamy Git, to tylko kilka osób może umieszczać rzeczy w systemie zarządzania wersjami, więc jeśli chcesz wprowadzić swoje zmiany, to będziesz musiał poddać je przeglądowi.

Tworzenie próśb o scalenie poprzez tryb edycji¶

Informacja

Sposób ten jest odpowiedni tylko wtedy, gdy nie masz możliwości wysyłania zmian do repozytoriów KDE. W przeciwnym przypadku wdrożył byś woje zmiany bezpośrednio do repozytorium, co jest sprzeczne z bieżącymi wytycznymi.

Zalecane dla użytkowników bez wiedzy technicznej.

Niezalecane, gdy chcesz zmienić więcej niż jeden plik na raz. (Zobacz Tworzenie próśb o scalenie poprzez WebIDE lub Tworzenie próśb o scalenie poprzez wiersz poleceń jeśli chcesz zmienić więcej plików lu po prostu zmienić jeden plik w prośbie o scalenie).

Jeśli masz dużo pracy, którą chciałbyś podesłać, zalecamy wypróbowanie tych instrukcji.

Uzyskaj Tożsamość KDE.
Zaloguj się do KDE_gitlab.
Przejdź do repository i naciśnij fork.
Powinieneś zostać przekierowany do odgałęzienia swojego własnego repozytorium. Zazwyczaj znajduje się ono w invent.kde.org/TWOJA_TOŻSAMOŚĆ_W_KDE/docs-krita-org.
Wróć do oficjalnego repozytorium. Upewnij się, że przeglądasz Strony sieciowe/Dokumentacja Krita.org, a nie swoje własne odgałęzienie. W przeciwnym przypadku ten sposób nie zadziała poprawnie.

Gitlab ma ustawienie do edycji plików bezpośrednio w gitlabie. Aby uzyskać do tego dostęp, przejdź do Repozytorium ‣ Pliki.

Na górze strony widzisz pole do upuszczania z wybraną gałęzią master.

Znajdź plik, który chcesz zmienić, otwórz go i naciśnij na Edycja.

Wprowadź swoje zmiany. (Uwaga: w tym trybie możesz zmieniać tylko jeden plik na raz).

Przejdź do mniejszego pola tekstowego poniżej i stwórz jakiś ładny opis swoich zmian. Gdy ukończysz, naciśnij Wdroż zmiany. Stworzy to dla ciebie prośbę o scalenie, więc wypełnij wszystkie pola tak, jak to wyjaśniono tutaj: Wytyczne dla nowych próśb o scalenie.

Wadą jest to, że w tej chwili nie można stwierdzić, czy popełniłeś jakikolwiek błąd w znacznikach przy użyciu tego sposobu. Sprawdź zmiany w Sieciowym edytorze Sfinksa (po prostu skopiuj i wklej cały plik, który edytujesz).

Uwaga

Edycja oraz WebIDE są dwiema różnymi rzeczami! Upewnij się, że wybrałeś Edit.

Tworzenie próśb o scalenie poprzez WebIDE¶

Zalecane dla użytkowników z pewną wiedzą o Gicie i którzy chcą zmieniać kilka plików na raz.

Niezalecane, gdy nie wiesz, co to jest gałąź (zamiast tego zajrzyj do Tworzenie próśb o scalenie poprzez tryb edycji).

Przeczytaj wytyczne powyżej, aby zalogować się do KDE_gitlab i utworzyć swoją gałąź.
Przejdź do swojego odgałęzienia (upewnij się, że adres url zawiera twoją nazwę użytkownika).
Upewnij się, że jesteś na gałęzi master.
Naciśnij WebIDE. To powinno przenieść cię na stronę, która ma listę plików po lewej stronie i dużą pustą przestrzeń na treści plików po prawej stronie.
Otwórz plik, które chcesz zmienić i zacznij wprowadzać w nich zmiany.
Naciśnij Wdroż…. Dwukrotnie naciśnij na wszystkich plikach w kategorii Niedobrane zmiany, aby przenieść je do Dobrane zmiany.
Naciśnij Wdroż… ponownie - rozwinie się pole tekstowe z opisem wdrożenia. Wpisz opis wdrożenia, który wyjaśnia jakie zmiany wprowadziłeś i dlaczego.
Upewnij się, że ustawienia są poprawne: musisz wybrać Utwórz nową gałąź (nazwa gałęzi powinna być: [nazwaużytkownika]/[bardzo krótki opis twoich zmian]). Jeśli ukończyłeś swoje zmiany, to upewnij się, że zaznaczyłeś Rozpocznij nową prośbę o scalenie. W przeciwnym przypadku, będziesz musiał później ręcznie poprosić o scalenie.
Naciśnij Dobierz & Wdroż.
Wypełnij wszystkie poprawnie: zajrzyj na Wytyczne dla nowych próśb o scalenie.
Aby ręcznie utworzyć nową prośbę o scalenie, przejdź do oficjalnego repozytorium Podręcznika Krity (upewnij się, że adres url jeszcze nie zawiera twojej nazwy użytkownika) i naciśnij Utwórz nową prośbę o scalenie (jasny zielony przycisk po lewej). Wybierz swoje odgałęzienie i gałąź, którą utworzyłeś w WebIDE.

Informacja

Jeśli nie masz dostępu do zapisu w oficjalnym repozytorium, to gitlab nie pozwoli ci zapisać twoich zmian, gdy wprowadzałeś je w oficjalnym repozytorium przez pomyłkę (a Stwórz prośbę o scalenie nie pomoże ci z tym: nadal musisz wdrożyć zmiany w swojej gałęzi, lecz jeśli nie masz uprawień do zapisu, to nie możesz tego zrobić). Pojawi się po prostu wiadomość: Wystąpił błąd podczas próby wdrożenia twoich zmian. Spróbuj ponownie.

W tym przypadku, po prostu skopiuj zawartość wszystkich plików, które zmieniłeś, przejdź do swojego odgałęzienia i wklej je do odgałęzienia WebIDE.

Tworzenie próśb o scalenie poprzez wiersz poleceń¶

Zalecane dla użytkowników, którzy wiedzą jak działa Git i jak używa się wiersza poleceń.

Niezalecane, gdy nie wiesz, co to jest gałąź (zamiast tego zajrzyj do Tworzenie próśb o scalenie poprzez tryb edycji).

Przeczytaj wytyczne powyżej, aby zalogować się do KDE_gitlab i utworzyć swoją gałąź.
Pobierz repozytorium lokalnie przy użyciu git clone. Strona repozytorium zawiera adresy urls, z których możesz pobierać przez git, a następnie wysyłać do swojego odgałęzienia. Zaletą tego jest to, że możesz użyć wszystkich narzędzi na swoim komputerze do wprowadzenia zmian w tych plikach tekstowych, a także zbudować podręcznik lokalnie, aby sprawdzić czy zawiera on błędy. (Wystarczy, że wykonasz ten krok tylko raz).
# dostęp przez ssh git clone git@invent.kde.org:<username>/docs-krita-org.git git remote add upstream git@invent.kde.org:documentation/docs-krita-org.git # dostęp przez https git clone https://invent.kde.org/<username>/krita.git git remote add upstream https://invent.kde.org/kde/krita.git
Pamiętaj, aby zawsze zaciągać zmiany z oficjalnego repozytorium, przed dokonywaniem jakichkolwiek zmian:
git pull upstream master
Upewnij się, że stworzyłeś nową gałąź dla swoich zmian, od września 2019, wszystkie zmiany powinny być odgałęzieniem master.
git checkout master # a następnie: git checkout -b "<nazwa użytkownika>/<opis nowej funkcji>"

Po wprowadzeniu swoich zmian, wdroż je i prześlij do swojego odgałęzienia. Po szczegółowy opis na temat tego jak używać Git w terminalu zajrzyj na Forking on Gitlab.

# wgraj pakiet python3-sphinx na swój system. Na przykład dla Ubuntu:
sudo apt install python3-sphinx
# zbuduj podręcznik (zgłasza potencjalne błędy i umożliwia przeglądnięcie zmian w przeglądarce)
make html
git status
git diff
# dodaj wszystkie pliki
git add .
# wdroż swoje zmiany
git commit
# podeślij swoje zmiany do swojego odgałęzienia
git push

W końcu, przejdź do strony sieciowej pierwotnego repozytorium, a następnie do próśb o scalenie. Wybierz swoje odgałęzienie i odpowiednią gałąź oraz stwórz nową prośbę o scalenia. Aby dowiedzieć się czym wypełnić pola, przeczytaj Wytyczne dla nowych próśb o scalenie.

Wytyczne dla nowych próśb o scalenie¶

Twoje opisy wdrożenia powinny być zgodne z wytycznymi zapisanym tutaj: Jak pisać opisy wdrożenia
Tytuł oraz Opis powinien wyjaśniać zmiany, których dokonałeś i to dlaczego ich dokonałeś, tak jak opis wdrożenia, więc przeczytaj także wytyczne z odnośnika powyżej.
Cel powinien wskazywać na master.
Jeśli jesteś pewny, że prośba o scalenie będzie wymagać w przyszłości jakichś zmian, to poprzedź jej nazwę [WIP].
Upewnij się, że zaznaczyłeś Zezwól na wdrożenia od użytkowników, którzy mogą scalać do gałęzi docelowej. – często jest to potrzebne ze względów technicznych, gdy prośba o scalenie jest nakładana na gałąź master, co technicznie zmienia prośbę o scalenie, lecz nie zmienia jej właściwej treści. Nakładanie na gałąź może być wykonane przez ciebie lub osobę dokonującą przeglądu twojej prośby – jeśli nie chcesz, aby cię później zbyt dużo pytano, to lepiej zaznacz to pole, tak aby osoba przeglądająca mogła to zrobić sama w kilku kliknięciach.
Możesz bezpiecznie zaznaczyć Usuń gałąź źródłową, po przyjęciu prośby o scalenie w większości przypadków.
Zaznacz Połącz wdrożenia, gdy prośba o scalenie zostanie przyjęta. Pierwszy wiersz opisu wdrożenia będzie pochodził od Tytułu twojej prośby o scalenie, a reszta od Opisu prośby o scalenie.
Gdy ukończysz tworzenie swojej prośby o scalenie, to przejdź na IRC (zobacz Internet Relay Chat) i zapytaj kogoś z uprawnieniami do zapisu, aby dodał etykietę Potrzebuje przeglądu do twojej prośby o scalenie.
Możesz otrzymać informację zwrotną na swoją prośbę scalenia, jeśli zawiera błędy. Po prostu popraw błędy w swojej gałęzi w jeden z następujących sposobów.
- Jeśli chcesz użyć trybu Edycji, to przejdź do działu Zmiany w prośbie o scalenie i naciśnij na ikonie ołówka (ze wskazówką, która mówi Edycja), aby ponownie użyć trybu edycji.
- Jeśli chcesz użyć trybu WebIDE, to przejdź do swojego odgałęzienia, wybierz gałąź, na której znajdują się twoje zmiany i przejdź do WebIDE.
- Jeśli zmieniasz pliki na swoim komputerze i pracujesz w terminalu, to upewnij się, że jesteś na właściwej gałęzi i prześlij swoje zmiany - gitlab sam uaktualni twoją prośbę o scalenie.
Po wprowadzeniu zmian, upewnij się, że zapytasz kogoś o zmianę etykiety ponownie na Wymaga przeglądu.

Zajrzyj do działu technicznego na Forking on Gitlab po szczegóły.

Informacja

W czasie pisania tego przewodnika, nadawanie etykiet na prośby o scalenie jest możliwe tylko dla współtwórców z uprawnieniami do zapisu do oficjalnego repozytorium. (Jeśli nie wiesz, co to oznacza, to prawdopodobnie nie jesteś jednym z nich). Z tego względu, jeśli tworzysz lub zmieniasz swoją prośbę o scalenie, to musisz wejść na IRC (see Społeczność Krity) i zapytać, czy ktoś nie umieści na nim dla ciebie etykiety.

Budowanie podręcznika z wiersza poleceń¶

Dla tych, którzy najpierw chcą wypróbować swoje zmiany (i już wiedzą jak używa się gita w wierszu polecenie), przed prośbą o scalenie, jest to opisane jako część kroku 5. w Tworzenie próśb o scalenie poprzez wiersz poleceń.

Ogólna filozofia¶

Jest to do określenia właściwego sposobu pisania. Sposób pisania, zależnie od tego czy rozważamy go od strony wartości praktycznych, czy estetycznych, jest zazwyczaj podszyty jakimś celem lub ogólną filozofią. Co chcemy osiągnąć przez podręcznik i do kogo będzie on przeznaczony?

Demografia i grupa docelowa¶

Nie możemy rozmawiać nt demografii w takim sensie, że wiemy, że wszyscy użytkownicy, to 55 letni mężczyźni. Kirta jest używana przez wielu różnych ludzi i jesteśmy dumni z tego, że mamy tak zróżnicowanych użytkowników.

Mimo tego, wiemy kilka rzeczy o naszych użytkownikach:

Są artystami. Jest to dokładnie ten rodzaj użytkowników, w który celujemy.
- Stąd wiemy, że wolą ładne zdjęcia.
- Są wzrokowcami.
- Próbują osiągnąć ładne zdjęcia.

Dlatego, domniemanym celem każdej strony jest uzyskanie funkcji używanej do ładnych zdjęć.

Poza tym, zauważyliśmy następujące grupy:

Uczniowie szkół średnich i studenci próbujący programów do rysowania. Ci mają zazwyczaj wcześniejsze doświadczenia z programami do rysowania, takimi jak Paint Tool SAI lub Photoshop, lecz potrzebują wprowadzenia do możliwości jakie daje Krita. Siłą tej grupy jest to, że dzielą się wieloma informacjami ze sobą, takimi jak wskazówki i samouczki.
Zawodowcy, ludzie, którzy zarabiają pieniądze przy użyciu oprogramowania do cyfrowego rysowania. Siłą tej grupy jest to, że mają duże know-how i są chętni, aby ulepszać program. Występują oni w dwóch rodzajach:
- Nietechniczni zawodowcy. Są to ludzie, którzy nie rozumieją bardziej matematycznej części programu, lecz rozwinęli niezawodny obieg pracy w czasie lat pracy z oprogramowaniem na podstawie instynktów. Są to ilustratorzy, malarze i ludzie, którzy pracują z wydrukami.
- Techniczni zawodowcy. To są ludzie, którzy używają Krity jako części swojej pracy i zależy im na precyzyjnej matematyce, a także na wypychaniu pikseli. Zazwyczaj są to ludzie pracujący w grach oraz przemyśle VFX, lecz czasami także naukowcy.
Dorośli i starsi hobbyści. Ta grupa nie wie zbyt dużo o komputerach i zawsze gdzieś utkną na tym jednym małym kroku, którego brakuje w samouczku. Ich siłą, jako grupa, jest to że dostosowują niecodzienne obiegi pracy z życia rzeczywistego, o których student się nie dowie, a na które zawodowiec nie ma czasu, przez co tworzą ciekawe rzeczy. Mają także dobry wpływ na pierwszą grupę w większej społeczności.

Z tych czterech grup…

istnieje tylko jedna, która jest techniczna. Z tego powodu potrzebujemy stron koncepcji, tak abyśmy mogli stworzyć solidną podstawę, na podstawie których będziemy mogli pisać nasz podręcznik.
trzy z nich prawdopodobnie mają wcześniejsze doświadczenie z oprogramowaniem i mogą potrzebować jakiegoś rodzaju wsparcia przy przesiadce.
dwie z nich potrzebują wiedzieć jak Krita może współgrać z innym oprogramowaniem.
dwie z nich nie mają pojęcia, co robią i mogą potrzebować wsparcia w najbardziej podstawowych kroki.

Stąd możemy ściągnąć następujące zasady:

Ogólne pisanie¶

Używaj angielskiego-amerykańskiego, jeśli możliwe.: Używany angielskiego-amerykańskiego w podręczniku w zgodzie z tym, że interfejs Krity domyślnie jest w tym języku.
Bądź uprzejmy, lecz nie używaj języka akademickiego.: Jako społeczność, chcemy być przyjaźni dla użytkowników, więc staramy się unikać języka, który nie jest przyjazny. Nie ma przyzwolenia na przeklinanie. Z drugiej strony, styl akademicki, w którym nie jest uwzględniony zarówno piszący jak i czytający może sprawić wrażenie, że tekst jest dużo bardziej złożony niż jest to potrzebne, a przez to może odstraszyć użytkowników.
Unikaj używania plików GIF (otwórz dla debaty): Powodem tego jest to, że na ludzi z epilepsją wpływają szybko poruszające się obrazy. Podobnie, obrazy GIF mogą czasami przyjmować na siebie zbyt dużą część wyjaśnienia. Jeśli nie możesz poradzić sobie bez obrazów GIF, to przynajmniej powiadom czytelnika o tym na stronie wprowadzenia.
Zachowaj zgodność w tłumaczeniu: Składa się to z używania SVG do infografiki oraz używania poprawnych znaczników dla danego tekstu.

Odnośnie zdjęć i malowideł¶

Odradzam zdjęć i tradycyjnych obrazów w podręczniku, jeśli nie przedstawiają one konceptu. Jest to trochę śmieszne i nieszczere pokazywać prace Rembrandta w Kricie, gdy mamy wiele współczesnych prac, które wykonano w Kricie.Cała oprawa Pepper&Carrot została wykonana w Kricie, a pierwotne pliki są dostępne, wiec gdy nie masz żadnego obrazu pod ręką, to zacznij tam. Zdjęć należy unikać, bo Krita to program do malowania. Zbyt wiele zdjęć może dać wrażenie, że Krita próbuje być rozwiązaniem na retusz zdjęć, co naprawdę nie jest jej celem.
Oczywiście, nadal chcemy przedstawiać pewne koncepty w ruchu na zdjęciach i głównych obrazach, takie jak połysk lub niebezpośrednie światło. W tym przypadku, dodaj podpis, który mówi o nazwie obrazu lub malarzu lub wspomina jego fotografa.
Zdjęć nadal można używać do photobashingu i podobnych, lecz tylko wtedy, gdy jest to widocznie używane w kontekście photobashingu.

Odnośnie obrazów w ogólności¶

Unikaj tekstu w obrazach. Zamiast tego używaj podpisów. Rób tak poprzez dyrektywę figure.
Jeśli potrzebujesz użyć tekstu, to stwórz albo SVG, tak aby łatwo można było zmieniać tekst wewnątrz lub spróbuj ograniczyć ilość tekstu.
Spróbuj, aby twoje obrazy miały wysoką jakość/były ładne. Daj ludziom poczucie, że używają programu do rysowania!
Pamiętaj, że podręcznik jest na licencji GDPL 1.3, tak więc podesłane przez ciebie obrazy także będą podlegać tej licencji. W przypadku CC-By-Sa/CC-By upewnij się, że plik ma poprawnie przypisane autorstwo przez podpis pod nim. Nie wysyłaj obrazów, których nie można będzie wydać pod żadną z tych licencji.

Protokół¶

Tutaj wymieniamy wszystkie nudne obiegi pracy.

Znaczniki i Gałęzie¶

Dodawanie i usuwanie tekstu nastąpi w gałęzi draft.

Sprawdzanie wyników starych stron jest traktowane jako poprawki błędów i przez to będzie trafiać do gałęzi master i zostanie scalone z gałęzią draft, gdy będzie to potrzebne.

Przed tym jak gałąź draft zostanie scalona z danym wydaniem:

Gałąź master zostanie oznaczona starą wersją.
Gałąź draf jest dwukrotnie sprawdzana, czy zawiera uaktualniony numer wersji oraz uaktualnioną okładkę epub.

Gałąź draft nie zostanie scalona do dnia przed wydaniem, aby zachować strony w nienaruszonym stanie przez tak długi czas, jak to możliwe.

Każde wydanie będzie miało wersję epub wysłaną jako część procesu wydawania. Skąd bierzemy pliki POT? Nawet przetłumaczone wersje?

Usuwanie stron¶

Jeśli jakaś możliwość została usunięta w pewnej wersji, to następujące strony:

Zostanie najpierw oznaczone jako przestarzałe.

Można to zrobić tak:

.. deprecated:: numer wersji

    Tekst wskazujący, że użytkownicy powinni pracować bez tej funkcji.

Zostanie dowiązane do strony o nazwie «deprecated»
Gdy pojawi się nowa wersja, to wszystkie strony dowiązane w dziale przestarzałych zostaną usunięte.

Dodawanie stron¶

Upewnij się, że znajduje się to we właściwym miejscu.
Przestrzegaj Zasady oznaczania tekstu dla Podręcznika Krity, aby strona była sformatowana poprawnie.
Dodaj stronę do spisu treści.

Jeśli dodajesz nową możliwość, to dodaj versionadded:

.. versionadded:: numer wersji

    coś opcjonalnego lub innego.

Tak jak w przypadku obrazów, nie dodawaj tekstu, do którego nie masz uprawnień. Oznacza to, że jest to tekst napisany przez ciebie albo masz zezwolenie na przeniesienie go od autora pierwowzoru. Podręcznik jest na licencji GDPL 1.3+ więc tekst też będzie na tej licencji.

Zmienianie stron¶

Jeśli w całości przepisałeś stronę, w przeciwieństwie do wyszukiwania w niej błędów, to cała strona powinna przejść przez ponowną ocenę.

Jeśli zmienisz stronę, bo zmieniła się funkcja i masz uprawnienia do zapisu, to zmianę można zapisać bez przeglądu (chyba, że bezpieczniej czujesz się z przeglądem), lecz wtedy powinieneś dodać:

.. versionchanged:: numer wersji

    To i tamto uległo zmianie.

W każdym przypadku, zastanów się czy nie chcesz dodać się do pola autorów w dziale metadanych na górze.

Używanie deprecated, versionadded oraz versionchanged wraz z numerem wersji umożliwia nam szybkie przeszukiwanie podręcznika po tych wyrażeniach przy użyciu narzędzia grep:

grep -d recurse versionadded * --exclude-dir={_build,locale}

Błędne strony¶

Jeśli ta strona prześlizguje się przez pęknięcia, to albo …

Utwórz prośbę o scalenie w dziale Wprowadzanie zmian.
Utwórz zadanie na Tablicy ręcznej pracy nad projektem.
Zgłoś błąd w bugzilla pod projektem Krita w dziale «dokumentacja».

Sprawdzanie¶

Są dwa rodzaje sprawdzeń, które należy wykonać.

Najważniejszą z nich jest przeglądanie zmian, które ludzie robią. Na KDE_gitlab możesz to zrobić na dwa sposoby:

Przegląd próśb o scalenie

Możesz pomóc w przeglądzie próśb o scalenie. Przegląd prośby jest zazwyczaj robiony przez programistów nawzajem, aby znaleźć błędy w kodzie. Ponieważ programowanie jest oparte na tekście, to możemy użyć tego także do szukania literówek.

Prośba o scalenie, jest ilością zmian wprowadzonych w dokumencie (dodania/usunięcia wierszy) umieszczone w pliku możliwym do odczytania przez komputer. Gdy ktoś podsyła prośbę o przejrzenie łatki (w systemie takim jak gitlab lub github to jest to scalenie lub prośba o wciągnięcie), to ludzie, którzy opiekują się tymi plikami przejrzą je i mogą wstawiać uwagi w miejscach, które wymagają zmiany. To umożliwia im robienie uwag do literówek, zbyt skomplikowanego pisania, lecz także do rzeczy, które są całkowicie niepoprawne. Gdy łatka zostanie przyjęta, to można będzie ją wypchnąć do systemu zarządzania wersjami.
Robienie uwag do zmian w podręczniku.

Uwagi do zmian następują po fakcie. Możesz dodać uwagę do zmiany, przechodząc do opisu wdrożenia (ze strony repozytorium, przejdź do historii i naciśnij na wpisie), gdzie będziesz mógł dodać uwagi do wprowadzonych zmian.

W obu przypadkach, interfejsy składają się z pokazywanych różnic, gdzie po lewej znajduje się stara wersja, a po prawej nowa wersja. Linie, które zostały dodane będą oznaczone na zielono, podczas gdy linie, które zostały usunięte, będą oznaczone na czerwono. Możesz nacisnąć na ikonę bąbelka rozmowy, aby dodać uwagę w wierszu.

Drugą ważną rzeczą jest sprawdzenie podręcznika w całości. Wiele ze stron zostało sprawdzonych tylko na poprawność, lecz nie na styl lub gramatykę.

Aby to zrobić będziesz musiał przeczytać rozdział Wprowadzanie zmian, tak abyś miał pełny dostęp do stron i mógł je edytować.

Tłumaczenie¶

Tłumaczenie podręcznika jet robione przez Społeczność tłumaczy KDE. Aby pomóc w tłumaczeniu, przejdź do strony tłumaczeń, wybierz listę zespołów tłumaczy, wybierz język, na który chcesz przetłumaczyć i podążaj za wytycznymi na stronie zespołu, aby nawiązać kontakt z innymi tłumaczami.

Aby dowiedzieć się więcej o tym jak zacząć tłumaczyć KDE zajrzyj do https://community.kde.org/Get_Involved/translation.

Zespół tłumaczy ma dostęp do plików PO do tego podręcznika, który jest rodzajem pliku używanym przez programy do tłumaczeń takie jak POEdit oraz Lokalize. Zespół tłumaczy ma możliwość wspólnej pracy nad tłumaczeniami tych plików, a następnie przesłania tych tłumaczeń do SVN. Osobny skrypt pobierze tłumaczenia z SVN i umieści je w rozdziale podręcznika codziennie.

Obrazy można przetłumaczyć, jeśli zespół tłumaczy chce dostarczyć swoje własne. Wszystkie obrazy w katalogu obrazów domyślnie są dla wersji «en». Gdy chcesz przetłumaczyć dany obraz, to przejdź do tego katalogu i dodaj kolejny katalog z kodem swojego języka, a następnie dodaj przetłumaczone wersje obrazów. Tak więc Sphinx będzie szukał wersji holenderskiej pliku /images/Pixels-brushstroke.png w /images/nl/Pixels-brushstroke.png oraz dla /images/dockers/Krita-tutorial2-I.1-2.png w /images/dockers/nl/Krita-tutorial2-I.1-2.png.

Ukończone tłumaczenia muszą także zostać dodane do skryptu budowania, aby mogły pokazać się w sieci. Zespoły tłumaczy, które są pewne swojego tłumaczenia powinny porozumieć się z głównym zespołem Krity poprzez kimageshop mailinglist(kimageshop@kde.org), lub foundation@krita.org, aby tego dokonać.

Inne¶

Aby dowiedzieć się o zasadach tekstu „restructured”, przeczytaj Zasady oznaczania tekstu dla Podręcznika Krity.