|
|
|
|
|
|
|
|
|
This manual serves as a single access point to all documentation related to the Live Systems Project and in particular applies to the software produced by the project for the Debian 9.0 "stretch" release. An up-to-date version can always be found at ‹http://debian-live.alioth.debian.org/›
Podczas, gdy podręcznik live-manual skupia się przede wszystkim na pomocy w budowaniu systemu live, a nie na tematach użytkownika końcowego. To użytkownik końcowy również może znaleźć przydatne informacje w następujących sekcjach: Podstawy obejmuje pobieranie skompilowanych obrazów i przygotowanie obrazów tak aby były uruchamiany z nośnika przenośnego lub z sieci, równocześnie używanie web builder lub uruchamianie live-build bezpośrednio w systemie. Dostosowywanie zachowania w czasie działania systemu opisuje kilka opcji, które mogą zostać określone podczas startu, na przykład wybieranie układu klawiatury i ustawienia regionalne, używając opcji persistence.
Niektóre z poleceń zawartych w tekście muszą być wykonywane z uprawnieniami superużytkownika, które mogą być uzyskane przez stanie się użytkownikiem root poprzez su lub używając sudo. Aby odróżnić te polecenia, które mogą być wykonywane przez nieuprzywilejowanego użytkownika i te wymagające praw administratora, polecenia zostały poprzedzone przez odpowiednio by $ or # . Symbol ten nie jest częścią polecenia.
Wierzymy, że wszystko w tym podręczniku jest ważne, przynajmniej dla niektórych z naszych użytkowników. Zdajemy sobie sprawę również, że zawiera on dużo materiału do sprostania. I że może chciałbyś doświadczyć szybkich postępów w używaniu oprogramowania przed zagłębianiem się w szczegóły. Dlatego sugerujemy czytanie w następującej kolejności.
Najpierw przeczytaj rozdział, O tym podręczniku, od początku, kończąc na sekcji Warunki. Następnie przejdź do trzech ćwiczeń na początku sekcji Przykłady mającej na celu nauczyć Cię podstaw budowania obrazu i dostosowywania. Najpierw przeczytaj Używanie przykładów, następnie Tutorial 1: Domyślny obraz, Tutorial 2: Narzędzie przeglądarka i wreszcie Tutorial 3: Spersonalizowany obraz. Pod koniec tych tutoriali, będziesz mieć ogólny zarys tego, co można zrobić z systemami live.
Zachęcamy do powrotu i bardziej dogłębnej analizy podręcznika, być może następnym razem czytanie Podstaw, przejrzenie lub pominięcie Budowanie obrazu netboot, a skończywszy czytając Omówienie dostosowywania i rozdziałów, które po nim następują. W tym momencie, mamy nadzieję, że są zostałeś zainteresowany tym, co można zrobić z systemami live i zmotywowany, aby przeczytać resztę tego podręcznika, od deski do deski.
Lista Autorów (w kolejności alfabetycznej):
Intencją niniejszy podręcznik jest dziłanie jako projekt społeczny, a więc wszelkie propozycje usprawnień i zmian są bardzo mile widziane. Proszę przejrzyj sekcję Przyczynianie się do projektu w celu uzyskania szczegółowych informacje na temat sposobu pobrania klucza do wysyłania zmian i jak wnosić dobre zmiany.
W celu dokonania zmian w podręczniku angielskim musisz edytować odpowiednie pliki w manual/en/, ale przed złożeniem swojego wkładu, należy przejrzeć swoją pracę. Aby wyświetlić podgląd live-manual, upewnij się, że pakiety potrzebne do budowy to są zainstalowane przez wykonanie:
# apt-get install make po4a ruby ruby-nokogiri sisu-complete
Możesz zbudować live-manual z głównego katalogu swojego zapytania GIT przez wykonanie:
$ make build
Ponieważ zbudowanie podręcznika we wszystkich obsługiwanych językach zajmuje trochę czasu, autorzy mogą zdecydować, że wygodniej będzie skorzystać z jednego z szybko korygujących skrótów podczas zamieszczania nowej dokumentacji, którą dodali do podręcznika angielskiego. Używanie PROOF=1 tworzy live-manual w formacie HTML, ale bez posegmentowanych plików HTML, a przy użyciu PROOF=2 tworzy się live-manual w formacie PDF, ale tylko sformatowane jako A4 i listowy pionowy. Dlatego korzystając z jednej z możliwości opcji PROOF= można zaoszczędzić sporo czasu, np.:
$ make build PROOF=1
Gdy zatwierdzasz jedno z tłumaczeń możliwe jest zbudowanie tylko dla jednego języka, przez wykonanie, np.:
$ make build LANGUAGES=pl
Jest też możliwe, aby zbudować po typie dokumentu, np:
$ make build FORMATS=pdf
Lub kombinacja obu, np:
$ make build LANGUAGES=pl FORMATS=html
Po rewizji swojej pracy i upewnieniu się, że wszystko jest w porządku, nie należy używać make commit chyba aktualizujesz już istniejące tłumaczenia, i w tym przypadku, nie należy mieszać zmian do instrukcji angielskiej i tłumaczeń w tej samej wysłanej zmianie, ale należy użyć osobnych zgłoszeń zmian dla każdego tłumaczenia. Zobacz sekcję Tłumaczenie, aby uzyskać więcej szczegółów.
Note: For the translation of the man pages see Translation of man pages
W celu przetłumaczenia live-manual, wykonaj następujące kroki, w zależności od tego, czy rozpoczynasz tłumaczenie od zera czy też kontynuujesz pracę na już istniejącym tłumaczeniu:
Po uruchomieniu make commit zobaczysz jakiś przewijający się tekst. Są to przede wszystkim informacyjne komunikaty o statusie przetwarzania, a także niektóre wskazówki na temat tego, co mogłoby być zrobione, aby poprawić live-manual. Chyba, że widzisz błąd krytyczny, zazwyczaj w takim wypadku możesz kontynuować i wysłać swój wkład w tłumaczenie.
live-manual składa się z dwóch narzędzi, które mogą w znacznym stopniu pomóc tłumaczom znaleźć nieprzetłumaczone i zmienione ciągi znaków. Pierwszy z nich jest "make translate". Uruchamia skrypt, który mówi dokładnie ile nie przetłumaczonych ciągów jest w każdym pliku .po. Drugi, "make fixfuzzy", działa tylko na zmienionych ciągach znaków, ale to pomaga znaleźć je i edytować jeden po drugim.
Należy pamiętać, że nawet jeśli te narzędzia mogą być bardzo pomocne do pracy z tłumaczeniami w linii poleceń, to korzystanie z wyspecjalizowanego narzędzia jak poedit jest zalecanym sposobem, aby wykonać zadanie. Jest to również dobry pomysł, aby zapoznać się z dokumentacjami Debian o lokalizacjach (l10n) i tymi specyficznymi dla live-manual: Poradnik dla tłumaczy.
Uwaga: Możesz użyć make clean aby oczyścić swoje drzewo git przed zamieszczeniem. Ten krok nie jest obowiązkowy, dzięki plikowi .gitignore, ale dobrą praktyką jest uniknać zatwierdzania plików odruchowo.
|
|
|