Dyskusja:Zanurkuj w Pythonie

Dyskusja

delimiter - a nie ogranicznik? --Derbeth ^talk 21:57, 21 lis 2005 (UTC)

W tekście angielskim użyto określenia delimiter jako argument metody split. Przykład jego użycia:

>>> str="AAA;BBB;CCC;DDD"
>>> str.split(";")
['AAA', 'BBB', 'CCC', 'DDD']

Wydaje mi się, że tłumaczenie separator bardziej pasuje, ponieważ w tym przypadku średnik oddziela jedną część od drugiej. Natomiast ogranicznik mi średnio podchodzi.

>>> print "".split.__doc__
S.split([sep [,maxsplit]]) -> list of strings

Return a list of the words in the string S, using sep as the
delimiter string.  If maxsplit is given, at most maxsplit
splits are done. If sep is not specified or is None, any
whitespace string is a separator.

Z tego wynikałoby, że delimiter i separator odnosiłyby się do tego samego. Być może się mylę, proszę o ewentualne sprostowanie. Piotr K. 13:38, 22 lis 2005 (UTC)

Ale racja, w niektórych przypadkach ogranicznik będzie bardziej pasował. Piotr K. 14:13, 22 lis 2005 (UTC)

Adresy, które mogą się przydać

http://python.kofeina.net/index.cgi

Forma

Jeszcze jedna dość ważna sprawa. Żeby nie było zbyt dużych rozbieżności w tekście "mówimy" na my czy na ty? ("Zobacz jeszcze ten przykład." czy "Zobaczmy jeszcze ten przykład"). Piotr K. 14:02, 22 lis 2005 (UTC)

Dość sporo się napisałem używając 1 osoby liczby mnogiej. Proponowałbym, żeby tak było w całej książce. --Piotr K. 13:57, 24 lis 2005 (UTC)

Nie sądze, żeby był to istotny problem. Przejrzałem sobie to co dotychczas zostało napisane i ogólnie rzecz biorąc nie ma jakichś rażących rozbieżności. Stosujemy nie tylko 1 os. l. mn., ale także sporo odwołań do 2 os. l. poj. (masz, utworzyłeś). I tak niech zostanie zatem. Warszk ☺ 21:19, 24 lis 2005 (UTC)

No dobra. :) --Piotr K. 06:59, 25 lis 2005 (UTC)

Pozwolicie, że wrócę do tej krótkiej dyskusji. Myślę, że warto postarać się o to, aby treść książki była "neutralna co do płci" czytelnika/czytelniczki. Nie wymaga to zbyt dużo pracy. W języku polskim można to osiągnąć albo używając zwrotów bezosobowych ("Po dokładnemu przyjrzeniu się przykładowi..." zamiast "Jeśli przyjrzałeś się już przykładowi...") albo - co w przypadku tej książki wydaje się bardziej uzasadnione ze względu na jej luźny styl - przy użyciu liczby mnogiej ("Jeśli przyjrzymy się..." lub "Jeśli przyjrzycie się...".). Dlatego skłaniam się ku sugestii Piotra, aby używać liczby mnogiej, w szczególności zaś zwrócić uwagę na to, czy forma zwracania się do czytelnika nie zakłada przypadkiem, że jest nim mężczyzna... --KamilaChyla 12:59, 24 lip 2007 (CEST)

Co do narracji, to się w pełni zgadzam, że liczba mnoga lub forma bezosobowa są najlepsze. Ale co do zwracania się do czytelnika, to już nie jestem pewien. Na przykład taki tekst: "You use Google, right? Have you ever wished you could programmatically access Google search results?" został przetłumaczony tak: "Korzystasz z Google, prawda? Chciałeś kiedyś mieć programowy dostęp do wyników wyszukiwania za pomocą Google?" Nie wiem czy forma "Chcieliście kiedyś..." byłaby tu lepsza. Książek raczej nie czyta się grupowo. :) --Robwolfe 21:36, 26 lip 2007 (CEST)

Z tym, że ja nie "chciałem", ja "chciałam". Nie mam zaś nic przeciwko "czytelnikowi zbiorowemu" (choć i tutaj historycznie obowiązuje rodzaj męskoosobowy), szczególnie w książkach o charakterze podręczników. Nie jestem specjalistką od lingwistyki feministycznej, ale uważam, że warto postarać się w "wikibooks" o "neutralność płciową" - w przedstawionym przez Ciebie przykładzie wersja w języku angielskim jest neutralna, natomiast Twoje tłumaczenie już nie: sugeruje ono, że zwracasz się do mężczyzny; można łatwo tego uniknąć, wprowadzając "czytelnika zbiorowego" (którego w przypadku podręczników można utożsamić z grupą osób korzystających z podręcznika, uczących się od mistrza/nauczyciela itp.). --KamilaChyla 14:10, 27 lip 2007 (CEST)

Nie zrozum mnie źle. Nie jestem przeciwnikiem "neutralności płciowej" tylko nie bardzo wiem jak tego dokonać w języku polskim. W angielskim "you" jest neutralne same w sobie, a w polskim trzeba się na coś zdecydować. Zwracanie się w liczbie mnogiej mi się osobiście nie podoba, ale nie będę się upierał. Decyzja i tak należy do Piotra. --Robwolfe 16:18, 27 lip 2007 (CEST)

W przykładzie przedstawionym przez Robwolfa zdanie w liczbie mnogie trochę dziwnie by brzmiało. Zresztą też można by było się zastanawiać, czy ma być "chcieliście", czy może "chciałyście". Na szczęście problem dotyczy tylko czasu przeszłego, ale w czasie teraźniejszym i przyszłym nie powinno być tego typu problemów i tak myślę, że można by było próbować przerobić czasami czas przeszły na teraźniejszy. "Korzystasz z Google, prawda? Może potrzebujesz czasami programowego dostępu do wyników wyszukiwania za pomocą Google?". --Piotr ^@ 17:54, 27 lip 2007 (CEST)

Zdanie "Jeśli kiedykolwiek korzystaliśmy z klas w Javie" brzmi co najmniej śmiesznie. Co on - nie wie czy korzystał czy nie? Naturalnym byłoby "Jeśli kiedykolwiek korzystaliście z klas w Javie", jak już chcemy mieć tą formę mnogą 153.19.50.146 15:45, 26 sty 2009 (CET).

pomysł na zmianę kolejności wbudowanych typów danych

Mam taki pomysł jak przedstawić kilka typów danych które można powiedzieć wywodzą się od jednego typu.

tablice (listy) (indeks liczbowy, pełna wersja)
 --> krotki (indeks liczbowy, pewne ograniczenia)
 --> stringi (indeks liczbowy, pewne ograniczenia, dodatkowe cechy)
 --> tablice asocjacyjne (dictionary) (indeks: klucze w kolejności dodawania, pewne ograniczenia)

No nie wiem, ja bym nie zmieniał. Co najwyżej w podsumowaniu po krótce można by było tak opisać. --Piotr ^@ 14:20, 17 sty 2007 (CET)

W książkach i ogólnie w społeczności są tuple a nie krotki, słowniki a nie tablice asocjacyjne (Python ma też moduł array - tablice)Riklaunim

Ze słownikami się zgodzie, ale z krotką można się spotkać. --Piotr ^@ 07:12, 28 maj 2007 (CEST)

Okienka

Myślę, że w dobie okienkowości przydałyby się rozdziały na temat pisania właśnie takich aplikacji. Moje 2 propozycje to PyGTK oraz PyQt (najlepiej by było dodać po prostu materiał o obu). Co o tym sądzicie? --Migol 01:04, 30 mar 2007 (CEST)

Pomysł ciekawy, ale najpierw trzeba przetłumaczyć to co mamy :) --Piotr ^@ 19:55, 10 kwi 2007 (CEST)

Nie no, z tym to się raczej zgodzę. Ja się niezbyt znam na kwestiach licencjonowania itp. więc czy mógłby ktoś sprawdzić na jakiej licencji jest PyGTK Tutorial (pdf) z [1] i czy nadawałby się on do dodania do naszej książki jako że w pełni omawia używanie PyGTK oraz jest w formie Dive Into.--Migol 11:12, 13 kwi 2007 (CEST)

Będzie można przetłumaczyć ten tutorial, tylko gdzieś trzeba będzie dorzucić dodatkową informację licencyjną. --Piotr ^@ 13:56, 21 kwi 2007 (CEST)

Po głębszym namyśle zastanawiam się czy dodać go tutaj, czy może stworzyć osobny podręcznik. Zwróc uwagę na jego objętość.--Migol 12:24, 24 kwi 2007 (CEST)

Myślę, że nadawałoby się to na osobną książkę. --Piotr ^@ 07:10, 28 maj 2007 (CEST)

Każde większe API GUI - czy to PyGTK czy QT lub też ew. wxPython to wielka kobyła do przetłumaczenia, napisania. Dla PyQT4 dwa główne linki to http://www.riverbankcomputing.com/Docs/PyQt4/pyqt4ref.html i http://www.riverbankcomputing.com/Docs/PyQt4/html/classes.html - gdyby robić książkę o PyQT4 to nie w postaci tłumaczenia dokumentacji ale szeregu przykładów uczących PyQT4 i korzystania z dostępnych klas. Tak samo praktycznie powinno wyglądać to dla pyGTK. Riklaunim

WEdycji obowiązkowo?

Myślę, że można by dodać stosowanie szablonu WEdycji obowiązkowo przed każdą sekcją którą się tlumaczy tj. 1 edycja - wstawienie WEdycji, druga to tlumaczenie ze zdjeciem szablonu na koniec. --Migol 12:27, 24 kwi 2007 (CEST)

Moim zdaniem takie podejście za bardzo zwiększa liczbę edycji, a i tak jak na razie nie było problemów z konfliktami edycyjnymi. Jeśli zajdzie taka potrzeba, będzie można wprowadzić takie ograniczenia, ale na razie nie widzę takiej potrzeby. Jeśli ktoś wstawia {{WEdycji}}, to znaczy po prostu, że chce zarezerwować dany moduł dla siebie. --Piotr ^@ 19:43, 24 kwi 2007 (CEST)

Heh, no ja kiedyś tak miałem przy robieniu całej strony i się lekko zdenerwowałem.--Migol 13:54, 25 kwi 2007 (CEST)

Moduły

Proponowałbym rozszerzyć po przetłumaczeniu podręcznik o informacje o najpopularniejszych modułach nie wchodzących w skład Pythona.

Propozycje (dopisujcie własne):

• pysqlite \
• MYSQLdb / np. jako nowy rozdział o bazach danych

Tę sprawę trzeba dobrze przemyśleć i zachować pewną ostrożność. Podręcznik powstaje po to, aby nauczyć czytelnika programować w Pythonie. (Nie ma to być jakaś specyficzna dokumentacja popularnych modułów Pythona w języku polskim itp.) Jeśli chodzi o nowe rozdziały, raczej myślałbym, żeby napisać o możliwościach nowszych wersji Pythona (podręcznik powstawał na bazie wersji 2.2, 2.3). Ale jak na razie wolałbym nie gdybać, bo jeszcze dużo przed nami pracy ;) --Piotr ^@ 20:33, 3 maj 2007 (CEST)

No właśnie. Niestety już w kilku miejscach widać, że ta książka była pisana jakiś czas temu. Może dobrym pomysłem byłoby kiedyś zrobienie adnotacji do miejsc już nieaktualnych i odniesienie tego do najnowszej wersji Pythona. Tyle, że oczywiście dopiero po przetłumaczeniu całości, bo roboty jest jeszcze duuuużo. --Robwolfe 23:51, 4 maj 2007 (CEST)

Może jakiś szablon do oznaczenia działów do aktualizacji?--Migol 21:08, 7 maj 2007 (CEST)

A co masz jakiś pomysł? :) --Piotr ^@ 21:10, 7 maj 2007 (CEST)

Aktualnie niebardzo, nie mam talentu do rysowania. Może Pythonowy wąż z brodą i laską + info że dane tu zawarte nie są pełne w kontekście Pythona 2.5. Ja też powiniennem tak być oznaczony. W 2.5 wprowadzili mojąukochaną odwróconą konstrukcję if a ja o tym nic nie wiedziałem. --Migol 11:52, 8 maj 2007 (CEST)

Podrozdział, a nie sekcja

Czy "section 1.2" należy tłumaczyć (jak w wielu miejscach już widziałam) jako "sekcja 1.2", czy może należałoby użyć polskiego odpowiednika, czyli "podrozdział 1.2"? Proponuję pozbyć się "sekcji" - to przecież niczym nieuzasadniona kalka językowa. Co myślicie? --KamilaChyla 13:05, 24 lip 2007 (CEST)

Zgodzę się, trzeba będzie to poprawić. --Piotr ^@ 10:28, 27 lip 2007 (CEST)

Przegląd tłumaczenia i konieczne poprawki

Tłumaczenie zbliża się powoli do końca, myślę, że warto zastanowić się, jakie poprawki są jeszcze potrzebne. Jedną z nich zaproponowałam wyżej; jeśli widzicie jeszcze jakieś potrzebne zmiany, proponuję opisać je poniżej, podyskutować chwilę i zabrać się do ew. poprawek.

• "Podrozdział", a nie "sekcja"
• ujednolicenie sposobu zwracania się do czytelnika (proponuję konsekwentnie liczbę mnogą)
• przegląd pojęć języka Python oraz pojęć z inżynierii oprogramowania (sprawdzenie, czy te same nazwy oraz wyrażenia są spójnie tłumaczone w całym podręczniku)
• przegląd pod kątem ortografii, składu, istnienia linków nawigacyjnych u dołu strony itp.

--KamilaChyla 12:39, 5 sie 2007 (CEST)

Właściwie tłumaczenie już się skończyło :). Ponadto zastanawiam się, czy niedobrze by było uaktualnić kody źródłowe do nowszych wersji Pythona (głównie zamiast ze starych klas, skorzystać z nowych). Poza tym, jak myślicie, czy warto tłumaczyć coś w kodach źródłowych (np. notatki dokumentacyjne), czy lepiej źródła zostawić w spokoju. --Piotr ^@ 13:11, 6 sie 2007 (CEST)

Komentarze, notatki i takie tam według mnie powinny być tłumaczone.Akira ^? 13:16, 6 sie 2007 (CEST)

Są tutaj dwa sensowne rozwiązania:

• nie tłumaczymy przykładów w ogóle (zostaje, jak jest)
• tłumaczymy komentarze w przykładach, jednak ze względu na to, że w źródłach pojawią się znaki "non-Ascii" (polskie literki) informujemy (np. we wstępie "Od tłumacza" lub przypisach) o konieczności umieszczenia odpowiedniej deklaracji kodowania w pliku źródłowym (http://www.python.org/peps/pep-0263.html) - bez niej źródła nie skompilują się (SyntaxError).

To ważna sprawa, jeśli weźmiemy pod uwagę sposób pracy z tego rodzaju podręcznikiem - zwykle czyta się jakiś rozdział i jednocześnie uruchamia przykłady (stosując "metodę Copiego-Paste-a"). [KamilaChyla]

Gratulacje dla wszystkich, którzy pomogli! Proponuję obwieścić dobrą nowinę na pl.comp.lang.python. Co do poprawek, to jestem za zmianą w kodzie na klasy "new-style", bo nowi adepci nauczą się po staremu i będzie problem. Co do tłumaczenia kodu, to przetłumaczyłbym tylko komentarze i notki, a sam kod zostawił w spokoju. No i przydałoby się ujednolicić terminologię, jak proponuje Kamila. --Robwolfe 13:34, 6 sie 2007 (CEST)

Co do sposobu zwracania się do czytelnika, "czytelnik zbiorowy" nie podoba mi się za bardzo. Proponuję używać 2. os. l.poj., ale bez czasu przeszłego (bo z czasem przeszłym są problemy). Jeśli nie jest to możliwe, wówczas trzeba przerobić zdanie na "tryb narracyjny". Na przykład, jeśli nie mamy pomysłu na zdanie typu "Korzystasz z Google, prawda? Chciałeś kiedyś mieć programowy dostęp do wyników wyszukiwania za pomocą Google?", to piszemy na przykład "Pewnie nieraz przydałby się nam programowy dostęp do wyników wyszukiwania za pomocą Google".

Zauważ, że sam użyłeś właśnie liczby mnogiej :) "Czytelnik zbiorowy", czyli użycie liczby mnogiej (czasami 3 os.: "spróbujcie", "zauważcie", a czasami 2 os.: "uruchomiliśmy", "sprawdziliśmy") wydaje mi się tutaj bardzo trafnym wyborem. Autor nie spoufala się z czytelnikami używając 2 os. l. poj. (co jest może przyjęte w literaturze amerykańskiej, ale wciąż wydaje się "nieprofesjonalne" w polskiej), jedynie prowadzi (wspólnie z grupą czytelników - uczniów) dyskusję czy wykład. Kolejna sprawa: czas przeszły może mieć decydujące znaczenie dla rozumienia treści rozdziałów: "zrobiliśmy coś wcześniej [trzeba użyć czasu przeszłego], ale teraz zrobimy to inaczej, lepiej" - to częsta w tym podręczniku metoda "nauczania"; usuwanie na siłę czasu przeszłego może zburzyć logikę takiej metody. [KamilaChyla]

Odnośnie terminologii, proponuję tłumaczenia wszystkich technicznych zwrotów zamieścić w słowniku wraz z proponowanymi tłumaczeniami.

W oryginale występuje wiele dodatków typu "Further Reading" (w naszym tłumaczeniu niektóre rozdziały to mają, a niektóre nie...) pod koniec każdego podrozdziału. Może byśmy także z tego skorzystali i dodali dodatkowo/zamienili polskie linki. --Piotr ^@ 15:34, 6 sie 2007 (CEST)

Dobry pomysł. I jeszcze związana z tym sprawa: w oryginale, przy niemal każdym przykładzie znajduje się informacja o możliwości ściągnięcia źródeł z netu. W tłumaczeniu kilka razy umieściłam tę informację, ale później przygotowane do tłumaczenia rozdziały już tej informacji nie zawierały. Czy celowo? [KamilaChyla]

Linki do dodatkowych materiałów na pewno warto dodać. Jednak co do polskich linków, to poza tą książką niestety nie ma zbyt wiele materiałów. --Robwolfe 19:02, 7 sie 2007 (CEST)

Informację o możliwości pobrania przykładów nie zostały celowo usunięte (przynajmniej, jeśli ja je usunąłem). Polskich materiałów rzeczywiście niewiele jest, ale czasami można coś znaleźć. --Piotr ^@ 19:18, 7 sie 2007 (CEST)

Przekopiowałem przykłady źródeł, które trzeba poprawić na Wikibooks. Lista znajduje się w Python/Zalecenia dla autorów. --Piotr ^@ 19:54, 7 sie 2007 (CEST)

Może byśmy książkę tę zatytułowali "Zanurkuj w Pythonie"? --Piotr ^@ 22:01, 7 sie 2007 (CEST)

Dobry pomysł. Ustalmy też jak powinien wyglądać nagłówek, który jest chyba we wszystkich źródłach: "This program is part of "Dive Into Python", a free Python book for experienced programmers. Visit http://diveintopython.org/ for the latest version." Czy zostawiamy tytuł "Dive into..." i adres "http://diveintopython.org", czy coś zmieniamy? --Robwolfe 14:16, 8 sie 2007 (CEST)

Moja propozycja to:

"""Ten program jest częścią książki "Zanurkuj w Pythonie", podręcznika
o Pythonie dla doświadczonych programistów. Najnowszą wersję można
znaleźć tu: http://pl.wikibooks.org/wiki/Python.

Program ten został oparty na przykładach zawartych w książce
"Dive Into Python", a dostępnej stąd: http://www.diveintopython.org.
"""

--Piotr ^@ 17:57, 8 sie 2007 (CEST)

Notki dokumentacyjne w Unikodzie

Ponieważ tłumaczymy notki dokumentacyjne na język polski, zastanawiam się nad tym, czy na samym początku nie wprowadzić unikodu i czy nie lepiej by było pisać notki dokumentacyjne w unikodzie. Uniknie się w ten sposób problemów związanych z różnym kodowaniem wyjścia. Co o tym myślicie? --Piotr ^@ 16:21, 16 sie 2007 (CEST)

Jednak rezygnuje z tego pomysłu. Wszelki tekst będziemy tworzyć w UTF-8. --Piotr ^@ 22:15, 20 sie 2007 (CEST)

Zmiana nazwy podręcznika

Gdzieś za tydzień czasu nazwa podręcznika zostanie zmieniona na "Zanurkuj w Pythonie". --Piotr ^@ 19:17, 20 sie 2007 (CEST)

Znacznie trafniejsze wydaje mi się tłumaczenie w tytule "dive" jako "zanurzyć się" a nie "nurkować". Od biedy może być "zagłębić" albo "pogrążyć". Można się zanurzyć/zagłębić w ciszy, ciemności, aromatycznej kąpieli, zapachu, zieloności etc. W razie awarii kanalizacji pracownicy wodociągów bywają zmuszeni do nurkowania w szambie -- osoba nurkująca jest na ogół dobrze zabezpieczona przed działaniem (odizolowana od) tego wewnątrz czego nurkuje.

Tytuł w najbliższym czasie już nie zostanie zmieniony (już raz został z "Python" na "Zanurkuj w Pythonie"). Tytuł wskazuje na luźny charakter tego podręcznika, a nazwa się już dosyć dobrze przyjęła, poza tym zmiana nazwy jest zajęciem dosyć niewygodnym i czasochłonnym (jak na obecne możliwości oprogramowanie MediaWiki), . --Piotr ^@ 16:08, 9 paź 2007 (CEST)

Dwa podręczniki o Pythonie na Wikibooks

Nie podoba mi się, szczerze mówiąc, sposób, w jaki "Zanurkuj w Pythonie" uczy programować - macie coś przeciwko utworzeniu alternatywnego podręcznika? --vatzec 17:25, 19 lip 2008 (CEST)

Piękno rzecz względna. Wielu ludzi chwaliło sobie ten podręcznik, choć sprawa może być podobna do Keringhama i jego książek w tematyce programowania - jedni zachwalają, inni ganią. Jeśli masz świeższy pomysł na Pythona, a do tego dużo przykładów - nie ma chyba przeszkód aby utworzyć drugą pozycję, pod warunkiem że nie będzie za bardzo zbieżna do Zanurkuj... Od siebie dodam, że można byłoby w nowej pozycji zwrócić większą uwagę na użytkowość Pythona jako języka makr w OpenOffice.org. MonteChristof DMC 03:46, 20 lip 2008 (CEST)

e-mail do autora oryginału Dive Into Python

Wysłałem e-maila do Marka Pilgrima z informację o polskim w-większości-tłumaczeniu jego podręcznika, zgodnie z tym, co sam na stronie owej książki pisze:

Dive Into Python in your language

Translations are freely permitted as long as they are released under the GNU Free Documentation License. Dive Into Python has already been fully or partially translated into several languages. If you translate it into another language and would like to be listed here, just let me know.

Jest więc możliwe, że link do tego modułu pojawi się tamże, o ile autor jeszcze edytuje czasem tę stronę i czyta maile ;). --// Silmethule^@dyskusja 21:46, 9 sie 2008 (CEST)

Python/C, itp.

Można by napisać o wykorzystaniu Pythona, np.jako języka skryptowego wykorzystywanego w grach. Sam chcę się o tym dowiedzieć, a oryginalna dokumentacja jest strasznie zagmatwana.

Nie wydaje mi się, ponieważ Zanurkuj w Pythonie to tłumaczenie. Do tego trzebaby utworzyć oddzielny podręcznik (vide moja propozycja). --vatzec 02:36, 26 sie 2008 (CEST)

Nowe wersje Pythona

Uczę się właśnie Pythona z tej książki i zauważyłem, że opisuje ona starą wersję języka. Teraz na przykład trzeba pisać nawiasy po princie. Czy nie przydałoby się tego poprawić? Lampak 14:07, 24 gru 2008 (CET)

Python czy python?

Nazwa python nie pochodzi od węża, tylko od Monty Pythona, dlatego nie na miejscu jest np wstawianie głowy węża do czołówki pdf'a...

W dystrybucjach Linuksa i w instalacji Pythona dla Windows ikoną skojarzoną ze skryptami Pythona jest głowa węża albo zielony wąż. Na okładkach książek o Pythonie znanego każdemu informatykowi wydawnictwa O'Reilly występuje m.in. pyton. Myślę, że twórcom języka frajdę sprawiają zabawy językowe i wieloznaczność i nie mieliby nic przeciwko naszej okładce. --Derbeth ^talk 22:46, 25 lut 2009 (CET)

Zanurkuj w Pythonie 3

Rozpocząłem pracę nad tłumaczeniem http://www.diveintopython3.org/. Proszę o pomoc: Zanurkuj w Pythonie 3

Wygenerowany PDF

Czytam sobie podręcznik ściągnięty w wersji PDF z tego gotowca na stronie głównej. Z tego co widzę PDF może mieć błędy spowodowany generacją plików PDF w MediaWiki. Przykład:

- na wikibooks: print ("\n".join(["%s %s" %

(rozdział Potęga Introspekcji)

- w pdf: print "\textbackslash{}n".join(["%s %s" %

Mi się udało domyślić, że coś jest nie tak i poszperać, ale komuś może to sprawić problem, zwłaszcza, że konwencja książki to 'kod a potem tłumaczenie'. Póki co jest w 1/5 książki, jakbym jeszcze coś znalazł dam znać.