Live manual Debian Live

# Debian Live Manual

# Przewodnik redakcyjny

896

# 17. Przewodnik redakcyjny

897

17.1 Wytyczne dla autorów

898

Ten rozdział zajmuje się pewnymi ogólnymi rozważaniami, które należy wziąć pod uwagę podczas pisania dokumentacji technicznej dla live-instrukcji. Są one podzielone na funkcje językowe oraz zalecane procedury.

899

Uwaga: Autorzy powinni najpierw przeczytać Współtworzenie tego dokumentu

900

17.1.1 Funkcje językowe

901

- Użyj zwykłego angielskiego

902

Należy pamiętać, że wysoki procent czytelników nie są rodzimymi użytkownikami języka angielskiego. Więc jako generalną zasadę spróbuj używać krótkich, sensownych zdań, zakończonych kropką.

903

To nie znaczy, że trzeba korzystać z uproszczonego, naiwnego stylu. Proponuje się unikać, na ile to możliwe, złożonych zdań podrzędnych, które czynią tekst trudny do zrozumienia dla nie rodzimych użytkowników języka angielskiego.

904

- Różnorodność języka angielskiego

905

The most widely spread varieties of English are British and American so it is very likely that most authors will use either one or the other. In a collaborative environment, the ideal variety would be "International English" but it is very difficult, not to say impossible, to decide on which variety among all the existing ones, is the best to use.

906

Spodziewamy się, że różne odmiany języka mogą mieszać się bez tworzenia nieporozumień, ale ogólnie należy starać się być spójnym i przed podjęciem decyzji o użyciu brytyjskiego, amerykańskiego lub innego dialektu języka angielskiego wedle uznania, proszę przyjrzeć się, jak inni ludzie piszą i postarać się ich naśladować.

907

- Bądź zbalansowany

908

Nie być stronniczy. Unikaj w tym odniesienia do ideologii zupełnie niepowiązanych z live-manual. Pismo techniczne powinny być możliwie jak najbardziej neutralne. Jak to jest w naturze piśmiennictwa naukowego.

909

- Bądź poprawny politycznie

910

Staraj się unikać seksistowskiego języka, jak to jest tylko możliwe. Jeśli potrzebujesz, odwołania do trzeciej osoby liczby pojedynczej najlepiej użyć jakiejś formy bezosobowej lub "wy" zamiast "on" , "ona" lub niewygodnych wynalazków, takie jak "mógłbyś/mogłabyś", "byłem/łam" i podobnych.

911

- Bądz zwięzły

912

Go straight to the point and do not wander around aimlessly. Give as much information as necessary but do not give more information than necessary, this is to say, do not explain unnecessary details. Your readers are intelligent. Presume some previous knowledge on their part.

913

- Oszczędź pracy tłumaczącym

914

Należy pamiętać, że cokolwiek napiszesz będzie musiało zostać przetłumaczone na kilka innych języków. Oznacza to, że sporo osób, będzie musiał wykonać dodatkową pracę jeśli dodasz bezużyteczne lub nadmiarowe informacje.

915

- Bądź zgodny

916

As suggested before, it is almost impossible to standardize a collaborative document into a perfectly unified whole. However, every effort on your side to write in a coherent way with the rest of the authors will be appreciated.

917

- Be spójny

918

Use as many text-forming devices as necessary to make your text cohesive and unambiguous. (Text-forming devices are linguistic markers such as connectors).

919

- Bądź opisowy

920

It is preferable to describe the point in one or several paragraphs than merely using a number of sentences in a typical "changelog" style. Describe it! Your readers will appreciate it.

921

- Słownik

922

Look up the meaning of words in a dictionary or encyclopedia if you do not know how to express certain concepts in English. But keep in mind that a dictionary can either be your best friend or can turn into your worst enemy if you do not know how to use it correctly.

923

English has the largest vocabulary that exists (with over one million words). Many of these words are borrowings from other languages. When looking up the meaning of words in a bilingual dictionary the tendency of a non-native speaker of English is to choose the one that sounds more similar in their mother tongue. This often turns into an excessively formal discourse which does not sound quite natural in English.

924

Zgodnie z ogólną zasadą, jeśli koncepcja może być wyrażony za pomocą różnych synonimów to dobrą radą będzie wybieranie pierwszego słowa zaproponowanego przez słownik. W razie wątpliwości, często słusznym jest wybieranie słowa pochodzenia germańskiego (zwykle jednosylabowe słowa). Ostrzegamy, że te dwie techniki, mogą produkować raczej mowę nieformalną, ale przynajmniej wybór słów będzie o szerokim zastosowaniu i ogólnie przyjęty.

925

Korzystanie ze słownika kolokacji jest zalecane. Są one bardzo pomocne, kiedy przychodzi do znajomości słów najczęściej występujących razem.

926

Ponownie; dobrą praktyką jest, aby uczyć się z pracy innych. Korzystanie z wyszukiwarki, aby sprawdzić, jak inni autorzy mogą korzystać z niektórych wyrażeń może bardzo pomóc.

927

- Fałszywi przyjaciele, idiomy i inne wyrażenia idiomatyczne

928

Uważaj na fałszywych przyjaciół. Bez względu na to, jak biegły jesteś w obcym języku nie można pomóc wpadając od czasu do czasu w pułapkę tzw. "fałszywych przyjaciół", słowa, które wyglądają podobnie w dwóch językach, ale których znaczenie lub zastosowanie może być zupełnie inne.

929

Staraj się unikać idiomów w jak największym stopniu. "Idiomy" to wyrażenia, które mogą mieć znaczenie zupełnie odmienne od tego, co ich poszczególne słowa wydają się oznaczać. Czasami, idiomy, mogą być trudne do zrozumienia nawet dla rodzimych użytkowników języka angielskiego!

930

- Unikaj slangu, skrótów, mowy potocznej...

931

Nawet jeśli popierasz korzystanie ze zwykłego, codziennego języka angielskiego, pisanie techniczne należy do formalnej formy języka.

932

Staraj się unikać slangu, niepopularnych skrótów, które są trudne do zrozumienia, a przede wszystkim skrótów, które próbują naśladować język mówiony. Nie wspominając o typowych dla kanałów IRC i przyjaznych dla zamkniętych gron wyrażeń.

933

17.1.2 Procedury

934

- Przetestuj przed zapisaniem

935

It is important that authors test their examples before adding them to live-manual to ensure that everything works as described. Testing on a clean chroot or VM can be a good starting point. Besides, it would be ideal if the tests were then carried out on different machines with different hardware to spot possible problems that may arise.

936

- Przykłady

937

W przypadku dostarczania przykładu spróbuj być tak dokładny jak tylko możesz. Przykład jest, mimo wszystko, tylko przykładem.

938

It is often better to use a line that only applies to a specific case than using abstractions that may confuse your readers. In this case you can provide a brief explanation of the effects of the proposed example.

939

There may be some exceptions when the example suggests using some potentially dangerous commands that, if misused, may cause data loss or other similar undesirable effects. In this case you should provide a thorough explanation of the possible side effects.

940

- Linki zewnętrzne

941

Links to external sites should only be used when the information on those sites is crucial when it comes to understanding a special point. Even so, try to use links to external sites as sparsely as possible. Internet links are likely to change from time to time resulting in broken links and leaving your arguments in an incomplete state.

942

Poza tym, ludzie, którzy czytają instrukcję w trybie offline nie będą mogli śledzić tych linków.

943

- Unikaj nadawania marki i rzeczy, które naruszają licencję zgodnie z którą podręcznik ten został opublikowany

944

Try to avoid branding as much as possible. Keep in mind that other downstream projects might make use of the documentation you write. So you are complicating things for them if you add certain specific material.

945

live-manual jest oparty na licencji GNU GPL. Ma to wiele skutków, które odnoszą się do redystrybucji materiału (dowolnego rodzaju, w tym grafiki chronionej prawami autorskimi lub logo), który jest opublikowany wraz nim.

946

- Napisz pierwszy szkic, przeglądnij go, edytuj, popraw i cofnij zmiany jeżeli wymaga tego sytuacja

947

- Burza mózgów!. Najpierw musisz zorganizować swoje pomysły w logicznej kolejności zdarzeń.

948

- Kiedy już w jakiś sposób masz zorganizowane te koncepcje w głowie napisz pierwszy szkic.

949

- Dokonaj przeglądu gramatyki, składni i pisowni. Należy pamiętać, że właściwe nazwy wydań, takich jak trixie lub sid nie powinny być kapitalizowane, gdy odnosi się do nich jako nazw kodowych. Aby sprawdzić pisownię można uruchomić cel "spell". tj. polecenie `make spell`

950

- Udoskonalaj swoje wyrażenia, a jeśli to konieczne cofnij i przerób każdą część.

951

- Rozdziały

952

Use the conventional numbering system for chapters and subtitles. e.g. 1, 1.1, 1.1.1, 1.1.2 ... 1.2, 1.2.1, 1.2.2 ... 2, 2.1 ... and so on. See markup below.

953

If you have to enumerate a series of steps or stages in your description, you can also use ordinal numbers: First, second, third ... or First, Then, After that, Finally ... Alternatively you can use bulleted items.

954

- Znaczniki

955

And last but not least, live-manual uses SiSU to process the text files and produce a multiple format output. It is recommended to take a look at SiSU's manual to get familiar with its markup, or else type:

956

$ sisu --help markup

957

To są przykłady znaczników, które mogą okazać się użyteczne:

958

- Dla pogrubienia użyj:

959

*{foo}* lub !{foo}!

960

powoduje: foo lub foo. Użyj tego by wyszczególnić określone słowa kluczowe.

961

- Dla kursywy użyj:

962

/{foo}/

963

powoduje: foo. Użyj tego dla np. nazw paczek Debiana.

964

- Dla czcionki o stałej szerokości użyj:

965

#{foo}#

966

powoduje: `foo`. Użyj tego np. dla nazw poleceń. A także aby uwidocznić poszczególne słowa kluczowe jak ścieżki dostępowe.

967

- Dla bloków z kodem użyj:

968

code{
$ foo
# bar
}code

969

powoduje:

970

$ foo
# bar

971

Użyj `code{` do otwarcia i #{}code# do zamknięcia tagu. Ważne jest, aby pamiętać, by zostawić miejsce na początku każdej linii kodu.

972

17.2 Wytyczne dla tłumaczy

973

Ta sekcja zajmuje się pewnymi ogólnymi rozważaniami, które należy wziąć pod uwagę przy tłumaczeniu zawartości live-manual.

974

Jako ogólne zalecenie, tłumacze powinni przeczytać i zrozumieć zasady tłumaczenia, które mają zastosowanie do ich specyficznych języków. Zazwyczaj, grupy i listy dyskusyjne tłumaczeń dostarczają informacji o tym, jak tworzyć przetłumaczone pracę zgodne z normami jakości Debiana.

975

Uwaga: Tłumacze powinni również przeczytać Współtworzenie tego dokumentu. W szczególności rozdział Tłumaczenie

976

17.2.1 Wskazówki tłumaczenia

977

- Komentarze

978

The role of the translator is to convey as faithfully as possible the meaning of words, sentences, paragraphs and texts as written by the original authors into their target language.

979

So they should refrain from adding personal comments or extra bits of information of their own. If they want to add a comment for other translators working on the same documents, they can leave it in the space reserved for that. That is, the header of the strings in the po files preceded by a number sign #. Most graphical translation programs can automatically handle those types of comments.

980

- UT, Uwagi Tłumacza

981

It is perfectly acceptable however, to include a word or an expression in brackets in the translated text if, and only if, that makes the meaning of a difficult word or expression clearer to the reader. Inside the brackets the translator should make evident that the addition was theirs using the abbreviation "TN" or "Translator's Note".

982

- Wyrażenia w trybie bezosobowym

983

Documents written in English make an extensive use of the impersonal form "you". In some other languages that do not share this characteristic, this might give the false impression that the original texts are directly addressing the reader when they are actually not doing so. Translators must be aware of that fact and reflect it in their language as accurately as possible.

984

- Fałszywi przyjaciele

985

Pułapka "fałszywych przyjaciół" wyjaśnionych wcześniej szczególnie dotyczy tłumaczy. Dwukrotnie sprawdzić znaczenie podejrzanych fałszywych przyjaciół w razie wątpliwości.

986

- Znaczniki

987

Tłumacze pracujący początkowo nad plikami pot, a później z plikami *{po} * znajdą wiele znaczników w ciągach. Mogą oni przetłumaczyć tekst tak, jak to jest tylko możliwe do tłumaczenia, ale niezwykle ważnym jest, aby używali oni dokładnie takich samych znaczników jak w oryginalnej wersji angielskiej.

988

- Bloki kodowe

989

Mimo, że bloki z kodem są zazwyczaj nieprzetłumaczalne, zawarcie ich w tłumaczeniach jest jedynym sposobem, aby zdobyć 100% kompletne tłumaczenie. I mimo, że oznacza to więcej pracy na początku, bo to może wymagać interwencji od tłumaczy jeśli kod się zmieni, to jest to najlepszy sposób, w dłuższej perspektywie czasu na określenie, co już zostało przetłumaczone, a co nie podczas sprawdzania integralności plików .po.

990

- Nowe linijki

991

Przetłumaczone teksty muszą mieć te same znaki nowej linii jak teksty oryginalne. Należy uważać, aby nacisnąć klawisz "Enter" lub wpisać \n jeśli pojawią się one w oryginalnych plików. Znaki te często pojawiają się, na przykład, w blokach z kodem.

992

Nie popełniaj błedów, to nie znaczy, że przetłumaczony tekst musi mieć taką samą długość jak w wersji angielskiej. Jest to prawie niemożliwe.

993

- Nieprzetłumaczalne ciągi znaków

994

Tłumacze nigdy nie powinni tłumaczyć:

995

- Nazw kodowych wydań (które powinny być pisane małymi literami)

996

- Nazw programów

997

- Komend podanych jako przykład

998

- Metadanych (zazwyczaj pomiędzy dwukropkami :metadata:)

999

- Linków

1000

- Ścieżek dostępnowych