Wikiźródła:Skryptorium/Pulpit techniczny: Różnice pomiędzy wersjami

Z Wikiźródeł, wolnej biblioteki
Usunięta treść Dodana treść
Linia 369: Linia 369:
Czy to jest normalne że w PDF jaki wygenerowałem dla tekstu [[Antoni Sznejder]] cała pierwsza strona jest pusta? [[Wikiskryba:Mahnka|Mahnka]] ([[Dyskusja wikiskryby:Mahnka|dyskusja]]) 14:40, 27 kwi 2021 (CEST)
Czy to jest normalne że w PDF jaki wygenerowałem dla tekstu [[Antoni Sznejder]] cała pierwsza strona jest pusta? [[Wikiskryba:Mahnka|Mahnka]] ([[Dyskusja wikiskryby:Mahnka|dyskusja]]) 14:40, 27 kwi 2021 (CEST)
<br>
<br>
:U mnie na pierwszej stronie mam trzy portrety Sznejdera, tak do 1/3 wysokości strony. Poniżej czarno. [[Wikiskryba:Szandlerowski|Szandlerowski]] ([[Dyskusja wikiskryby:Szandlerowski|dyskusja]]) 15:03, 27 kwi 2021 (CEST)
:U siebie na pierwszej stronie mam trzy portrety Sznejdera, tak do 1/3 wysokości strony. Poniżej czarno. [[Wikiskryba:Szandlerowski|Szandlerowski]] ([[Dyskusja wikiskryby:Szandlerowski|dyskusja]]) 15:03, 27 kwi 2021 (CEST)

Wersja z 14:04, 27 kwi 2021

Skryptorium
Pulpit techniczny

Przy pulpicie technicznym dyskutuje się nad kwestiami technicznymi związanymi z MediaWiki, botami, skryptami i szablonami.

Miłych i owocnych dyskusji!


Chodzi za mną już od dłuższego czasu pomysł, by zunifikować te dwa szablony w jeden, wariantowy. W sumie, informacje, które one zawierają są bardzo podobne, różnią się głównie sposobem ich wyświetlania. Może dałoby się jakoś rozwiązać, by sposób wyświetlania tych informacji był sterowany:

  • przy użyciu js, według wyboru użytkownika, albo jego indywidualnych ustawień,
  • domyślny - sterowany za pomocą dodatkowego opcjonalnego parametru?

Informacje niewyświetlane w {{Nagłówek}} mogłyby być zawarte w kodzie jako ukryte. Przełączanie wyglądu mogłoby się odbywać za pomocą dobrze widocznego przełącznika.

Mam wrażenie, ze większość informacji wyświetlana w {{Dane tekstu}} jest dla przeciętnego czytelnika nieistotna. Część skrybów również preferuje prosty {{Nagłówek}}. I chyba przy małych ekranach, typu mobilnego, pominięcie tych informacji może zwiększyć czytelność tekstów.

Rzucam na razie luźny pomysł, aby rozważyć różne za i przeciw, a przede wszystkim konsekwencje. Już w tej chwili widzę, że może to mieć istotny wpływ na konfigurację eksportera ebuków, spowoduje też pewnie nieznaczne "spuchnięcie" stron o dodatkowy (ale jednorazowy) kod. Coś jeszcze? To pytanie przede wszystkim do naszych najbardziej "technicznych" użytkowników (@Zdzislaw, @Wargo:), ale ciekaw jestem też opinii innych.

Ankry (dyskusja) 13:20, 13 kwi 2020 (CEST)[odpowiedz]

  • @Ankry: jeżeli nagłówek/DT miałby się tworzyć dynamicznie (zmieniać) to czy nie należałoby się zastanowić, czy nie powrócić do źródeł, i nie tworzyć ich automatycznie, tak jak w en i fr, bezpośrednio z danych z Indeksu (które powielamy na każdej stronie w main), z możliwością nadpisywania danych przez wprowadzenie wartości parametrów w wywołaniu <pages...? Zdzislaw (dyskusja) 14:23, 15 kwi 2020 (CEST)[odpowiedz]
    • @Zdzislaw: Być może to też, czemu nie? Ale według mnie nie dla wszystkich tekstów ma to sens (wyekstrahowane, współoprawne, oparte o wiele indeksów itp.). Główny problem z tworzeniem nagłówków przez ProofreadPage polega na tym, że większość użytkowników ma niezmiernie blade pojęcie jak to działa, a ci, co jakieś mają, niekoniecznie są w stanie zaoferować pomoc techniczną innym. Ktoś by musiał to zaimplementować i służyć supportem dla userów (w przeciwnym razie będzie to casus Emeczki, który zaimplementował rodzinę szablonów i zniknął; po czym nikt nie wiedział, jak tego prawidłowo używać).
Obie zmiany łączy tylko to, że wymagają grzebania w kodzie krytycznych szablonów. Pierwsza propozycja wiąże się jedynie z przebudową szablonu i stworzeniem okołoszablonowego js. Druga, oprócz zmian w szablonach, wymaga zmiany sposobu tworzenia stron lub przebudowania istniejących. A to wymaga przeszkolenia użytkowników, zmiany ich przyzwyczajeń, kogoś, kto będzie umiał wyjaśnić jak to działa albo dlaczego nie działa. Bez tego może się okazać pracą daremną (casus Emeczki).
Powrotem do źródeł bym tego nie nazwał; "źródłowy" {{Nagłówek}} jest dużo starszy niż ProofreadPage. Raczej przejściem z epoki brązu do epoki żelaza (skąd do epoki przemysłowej wciąż daleka droga). Ankry (dyskusja) 16:11, 15 kwi 2020 (CEST)[odpowiedz]
  • @Ankry: ok, zapomnijmy na razie o <pages... Pytania... od czego zacząć? Od unifikacji w wariantowy? Czy nagłówek przejmuje DT, czy odwrotnie? Który miałby być przekierowywany, na który? Czy raczej nowy szablon? Czy najpierw spróbować stworzyć gadżet przełączający widok obecnego n->DT i DT-> n? Zdzislaw (dyskusja) 13:42, 19 kwi 2020 (CEST)[odpowiedz]
  • No właśnie do końca nie wiem, stąd ten wątek. Wydaje mi się, że najsensowniej by było utworzyć nowy szablon, a później przekierować na niego istniejące. Lub później przenieść go pod jeden z dotychczasowych (raczej pod DT, bo ma więcej parametrów). Jak uważasz? Myślę też, że proste przekierowanie Nagłówka na DT nie jest możliwe, bo się jednak trochę różnią składnią i raczej byłaby to nakładka.
Zastanawiam się też, na ile taki mechanizm dałoby się wykorzystać w przyszłości do innych zmian sposobu wyświetlania (np. zawężanie jak w fr); rozważyć jakie zmiany byłyby potrzebne do integracji z <pages> też można się zastanowić. Chodzi mi o to, by dobrze przemyśleć zasadę działania oraz jak i do czego mozna go wykorzystać w przyszłości (a do czego nie można / z czym by kolidował), niż o branie się za implementację. Raczej taka wstępna wishlist z analizą wykonalności. Ankry (dyskusja) 14:26, 19 kwi 2020 (CEST)[odpowiedz]
  • @Ankry: w ostatnich dniach przegryzałem się trochę przez dokumentację i zgłębiałem omawiany problem. Analizując możliwości, dochodzę do wniosku, że odpowiednie zaimplementowanie mechanizmu header i jego odpowiednie opisanie w prostym wizualnym samouczku nie dość, że umożliwiło by generowanie DT/nagłówka spiętego z ich zamianą poprzez js lub nawet opcją w ustawieniach użytkownika, to pozwoliłoby na zaimplementowanie mechanizmu zmiany formatu main (tak jak na en i fr... szerokość, styl fontu... zob. tu, link Maquette 1 (2,3...) w menu po lewej), i jednocześnie linki następny/poprzedni byłyby być generowane automatycznie... To wszystko razem spowodowałoby ogromne ułatwienie nie tylko dla starych, lecz także dla nowych skrybów. Oczywiście, znajdziesz przypadki, w których wymagane byłoby wprowadzenie DT/header, lub chociażby pewnych parametrów ręcznie, lecz jedno drugiego nie wyklucza, a dla 95% nowych tekstów (i 95% starych) mechanizm <pages byłby odpowiedni. Jestem także przekonany, że przy odrobinie wysiłku informacyjnego w niedługim czasie (jak na warunki ws:) ) większość Skrybów uznałaby ten mechanizm za łatwiejszy, dający lepszy efekt końcowy i prostszy. Oczywiście obecne mechanizmy (tak jak dla korekta funkcjonowałyby bez zmian). Zdzislaw (dyskusja) 13:21, 1 maj 2020 (CEST)[odpowiedz]
  • Ja jestem w tej materii raczej samoukiem praktykiem i użytkownikiem. Jak mi jest coś potrzebne (a nie ma tego już stworzonego przez kogoś innego) to gdy idea mi w głowie się zarysuje i mam już jakiś pomysł jak to rozwiązać to po prostu siadam i coś na bieżąco płodzę, a potem ewentualnie poprawiam zauważone błędy i braki i dodaję nowe funkcje, których brak mi się nasunął w trakcie testów. Nie jestem więc tak dobrze zorganizowany teoretycznie jak koledzy... Na razie obserwuję ten wątek ale nie mam aż takiej wyobraźni aby coś planować wielowariantowo i ze wszystkimi szczegółami. I obawiam się, że przed zobaczeniem wyników niewiele mogę pomóc w tej materii. Ale jak mi się coś nasunie w trakcie to oczywiście dam znać. Na razie mam taką uwagę, że te dodatkowe opcje (np. szerokość tekstu) powinny być do wyboru przez użytkownika - ja np. preferuję tekst w dostępnej całej szerokości ekranu (używam monobooka, a w proofie używam także gadżetu do chowania sidebaru, aby móc korzystać z całej szerokości), więc nie cieszyłoby mnie wymuszone jego zwężenie, jak się obserwuje na niektórych wiki. Electron  <Odpisz> 11:37, 2 maj 2020 (CEST)[odpowiedz]

Owszem, jak zauważył Ankry również dostrzegam problemy z obecnym szablonem {{Dane tekstu}} aczkolwiek widzę tu dwa aspekty. Wg mnie

  • tworzenie stron w przestrzeni głównej jest problemem dla nowicjuszy i nawet niektóre stare wygi tego unikają.
  • bardzo żmudne (=podatne na błędy) jest zwłaszcza zmienianie struktury np. przy zmianie numeracji, tytułu...
  • inne wymagają więcej uwagi (stary styl, bunch of jpgs, kilka plików w jednym indeksie)

Pierwsza idea, która mi przyszła do głowy to centralna strona z danymi podstron:

Rozdział II✽224✽265✽sekcja_02✽R_02
Rozdział III✽266✽269✽sekcja03✽R_03
itp. itd.

Druga idea to automatyzacja podstron (następna, poprzednia – rozumiem, że uwzględnione w projekcie Zdzisława, bieżąca przydatna do tworzenia kategorii i sekcji) (idee można połączyć):

Rozdział II✽224✽265✽sekcja_{{BieżącyU|2}}✽{{BieżącyU|2}}
Rozdział III✽266✽269✽sekcja_{{BieżącyU|2}}✽R_{{BieżącyU|2}}

Jeśli nie wykorzystać idei I, to pozostaje zastosowanie
<pages index="........" from="11" to="12" fromsection="sekcja_{{Bieżący_U|3}}" tosection="{{Bieżący_U|3"}}/>
i [[Kategoria:....|R_{{BieżącyU}}]]
O ile to pierwsze zastosowanie (sekcje) nie jest często potrzebne (wiele rozdziałów zaczyna się na nowej stronie – choć jeśli sekcje są potrzebne, to warto to móc automatyzować), o tyle tworzenie kategorii można w ten sposób zautomatyzować.

Draco flavus (dyskusja) 14:06, 3 maj 2020 (CEST)[odpowiedz]

Wikibiblioteka: prosty front-end dla Wikiźródeł

Przy okazji, w WMPL wykiełkował taki pomysł. Może warto go przedyskutować w naszym gronie? Ankry (dyskusja) 13:20, 13 kwi 2020 (CEST)[odpowiedz]

Jak najbardziej warto przedyskutować ten pomysł.

  1. czy ten portal miałby zastąpić obecną stronę główną czy być czymś zupełnie oddzielnym?
  2. jaka jest preferowana technologia i wymagania techniczne?

Cafemoloko (dyskusja) 13:42, 13 kwi 2020 (CEST)[odpowiedz]

Na pewno nie może zastąpić SG, bo, jak rozumiem, chodzi o serwis zewnętrzny. Natomiast być może mógłby zastąpić wsexportera albo stać się serwisem pośredniczącym w naszym korzystaniu z niego. Na etapie pomysłu trudno mówić o technologii; wydaje mi się, że jest to kwestia otwarta. Pewne osoby z WMPL zaproponowały przedyskutowanie tego po Świętach. Ankry (dyskusja) 15:13, 13 kwi 2020 (CEST)[odpowiedz]
Tak rzucam tylko do pomyślenia, mamy trzy kategorie tekstów (A. ukończone = zielone, B. skończone=kompletne np. dużo powieści Dumasa i C. takie teksty dziurawe (przeniesione do głównej ale nie przepisane) . Zawężać się do A trochę szkoda..., udostępniać C to antyreklama dla nas, B. bym ew. udostępniał na zewnątrz z jakimś sygnałem, że nieukończone są prace nad tekstem. Draco flavus (dyskusja) 21:48, 13 kwi 2020 (CEST)[odpowiedz]

Hej wszystkim! Dzięki za rozpoczęcie dyskusji, Ankry! Ja podpowiem czego bym potrzebował, żeby ruszyć to dalej:

  • listy rzeczy koniecznych (must have)
  • listy rzeczy mile widzianych (nice to have)
  • listy pomysłów z kosmosu ("A jakby jeszcze robiło kawę…")

Proponuję na tym etapie nie przejmować się technologią ani graficznym kształtem, tylko skupić na dobrym opracowaniu samych potrzeb. Dzięki temu będę mógł to potem zabrać do programistów i designerów i powiedzieć "Zróbcie nam coś co będzie spełniać te wymagania".

Jedna rzecz jest raczej trwała i tego (na razie) nie przeskoczymy, a mianowicie: będzie to odrębny serwis internetowy na oddzielnej domenie (w ten sposób możemy sobie pozwolić na ruszenie z projektem bez oglądania się na WMF). Ale to mam nadzieję rozwiązuję kwestię pytań o stronę główną – nic na Źródłach nie zmieniamy. :)

Jeśli mogę sobie pozwolić na metaforę, mamy skryptorium i drukarnię (Wikiźródła) dla skrybów/skrybek i zecerów/zecerek, a teraz chcemy do tego od frontu dobudować bibliotekę dla czytelników i czytelniczek.

Dla przykładu, na mojej liście rzeczy koniecznych w bibliotece mam:

  • bardzo prosty w użyciu interface i wyszukiwarka – Moja mama chce przeczytać Kordiana i musi go znaleźć i ściągnąć
  • atrakcyjna oprawa graficzna z okładkami książek jako elementem prezentacji
  • dostosowanie do używania serwisu na urządzeniach mobilnych i tabletach
  • możliwość ściągnięcia książki w różnych formatach z prostym objaśnieniem
  • możliwość przejścia z serwisu dla czytelników do serwisu dla skrybów (rekrutacja nowych użytkowników Wikisource)

A na liście rzeczy mile widzianych:

  • możliwość podziękowania skrybom
  • możliwość pokazania użytkownikowi kategorii lub listy książek (np. listy lektur lub książek powiązanych z danym tematem)
  • możliwość pokazywania postępów prac na kolejnymi książkami (takiej list "Wkrótce w naszej bibliotece…")

A na liście rzeczy z kosmosu mam:

  • możliwość osadzania książki w innej stronie internetowej z odniesieniem do strony
  • możliwość dodawania do książki oddzielnych "warstw" (analogicznie do Open Street Maps) tworzonych przez skrybów przypisów i/lub komentarzy do oryginalnego tekstu (np. "warstwa historyczna" z odniesieniami do Wikipedii, "warstwa literaturoznawcza" dla studentów i wykładowców wskazująca zabiegi literackie lub tematykę, "warstwa komparatywna/tłumaczeniowa" z odniesieniem do tekstu oryginału

Także poproszę na tym etapie o listy potrzeb i/lub pomysłów z podziałem na te trzy kategorie. Z tego punktu będzie łatwiej ruszyć dalej. :)

Cieszę się, że przyjmujecie pomysł ciepło – będę z ciekawością czekał na Wasze pomysły.

TOR (dyskusja) 20:16, 14 kwi 2020 (CEST)[odpowiedz]

  • Może zaimplementowanie znanego ostatnio z Commons mechanizmu dodawania tagów - danych strukturalnych, takich jak: rodzaj (literacki), gatunek, tematyka, motywy, tak żeby można było wyszukać łącznie np. "powieść historyczna", "tematyka: XVIII wiek". To by odciążyło kategorie, z którymi jest obecnie mały problem (brak kryteriów: gdzie i jaką kategorię dodać). Matlin (dyskusja) 20:49, 14 kwi 2020 (CEST)[odpowiedz]
    Przyłączam się do prośby o możliwość tagowania (mogą być proste albo w formie klucz wartość typu autor=LD, miejsce=Galicja i uwzględniania tagów jako jednej z opcji wyszukiwania). Bonvol (dyskusja) 19:20, 17 kwi 2020 (CEST)[odpowiedz]
    Wiele sposobów grupowania utworów: po autorze, po roku powstania, po narodowości, tylko słowniki, kolekcje tematyczne itp. Bonvol (dyskusja) 19:20, 17 kwi 2020 (CEST)[odpowiedz]
  • Jeżeli miałby to być nawet prosty front-end, to i tak, jak mi się wydaje, w pierwszym kroku wymagane byłoby zindeksowanie "gotowych" utworów ze Źródeł, wraz z metadanymi. I oczywiście ich okresowa aktualizacja, w miarę pojawiania się kolejnych "gotowych" utworów na Źródłach. Jeżeli tak, to dlaczego nie iść za ciosem i nie powrócić do możliwości połączenia ws z FBC? To co jest do zrobienia opisywałem tu:
    wmpl:Użytkownik:Zdzislaw/Źródłosłów_2018
    Wtedy naszym prostym front-end-em mogłoby się stać FBC :)) Zdzislaw (dyskusja) 14:29, 15 kwi 2020 (CEST)[odpowiedz]
    Cache'owanie gotowych epubów/pdfów też może być opcją i sposobem na odciążenie eksportera. Bonvol (dyskusja) 19:20, 17 kwi 2020 (CEST)[odpowiedz]
Mam pytanie: a ten serwis zewnętrzny gdzie ma być zarejestrowany? Bo jeśli by działał na polskiej domenie to dobrze by było dostawienie tam także forka polskich wikiźródeł, dla prac które są już PD w Polsce a wujek Sam dalej uparcie próbuje je ochraniać nie wiadomo dla kogo, na co i po co... Dotyczy to zwłaszcza polskojęzycznych prac wydanych po wojnie (i nie tylko). Electron  <Odpisz> 23:26, 15 kwi 2020 (CEST) przeniosłem część tej wypowiedzi do następnego wątku; tam ją kontynuujmy Ankry (dyskusja) 21:43, 16 kwi 2020 (CEST)[odpowiedz]

Czasem tak jest, że rzeczy dzieją się szybciej niż przypuszczałeś… :) W ten weekend będę pisał wniosek o dofinansowanie z programu Kultura w Sieci na stworzenie strony internetowej i oprogramowania "łączącego" Wikisource z biblioteką, promocję i pewnie więcej działań jeszcze. Będę Was informował na bieżąco o wynikach. Trzymajcie kciuki. TOR (dyskusja) 11:42, 16 kwi 2020 (CEST)[odpowiedz]

  • @TOR: byłoby przyszłościowo, gdyby w projekcie wziąć pod uwagę koszt narzędzia dającego możliwość wyjścia z danymi o pozycjach w tworzonej bibliotece przez OAI-PMH (daje to możliwość wyjścia do FBC i Europeany). Zdzislaw (dyskusja) 14:57, 16 kwi 2020 (CEST)[odpowiedz]

Wiki dla tekstów PD-PL

Dobrze by było dostawienie forka polskich wikiźródeł, dla prac które są już PD w Polsce a wujek Sam dalej uparcie próbuje je ochraniać nie wiadomo dla kogo, na co i po co... Dotyczy to zwłaszcza polskojęzycznych prac wydanych po wojnie (i nie tylko). Electron  <Odpisz> 23:26, 15 kwi 2020 (CEST)[odpowiedz]

  • Może ja odpowiem: ten temat już wypłynął i będzie dyskutowany; jednak w tym przypadku sprawa jest trochę bardziej złożona: choćby dlatego, że systemem z aktywnymi użytkownikami trzeba aktywnie zarządzać i go jakoś nadzorować. Ankry (dyskusja) 08:54, 16 kwi 2020 (CEST)[odpowiedz]
    Nawet system "samoobsługowy" wymaga opieki jakiegoś admina, który dba o to aby pracował on poprawnie, nie zawieszał się i dokonywał jego aktualizacji. Tak więc dodanie jeszcze jednego serwisu nie powinno go zbytnio dodatkowo obciążyć. A adminami dbającymi bezpośrednio o treść mogliby być wszyscy dotychczasowi admini Wikiźródeł wyrażający takie zainteresowanie - raczej nie powinno być z tym problemu... Upiekło by się dwie pieczenie przy jednym ogniu.
    Aby nie zajmował on zbyt wiele miejsca można ustanowić zasadę, że można by było tam umieszczać tylko teksty i pliki, które nie nadają się do "właściwych" Wikiźródeł ze względów prawnych. I ograniczyć wielkość maksymalną ładowanych plików do rozsądnych rozmiarów (pliki pdf i djvu można zwykle dokompresować do właściwych rozmiarów). Electron  <Odpisz> 11:20, 16 kwi 2020 (CEST)[odpowiedz]
    Potraktowałbym to jako odrębny projekt. Możemy zacząć osobny wątek na ten temat? Bo to ważna kwestia (pozdrowienia dla prawników Myszki Mikki), ale nie powinno nas blokować przy tworzeniu naszej "biblioteki". Chętnie bym się dowiedział czy inne kraje w jakiś sposób rozwiązały już tę kwestie, czy też jako ruch Wikimedia jesteśmy cały czas w kropce globalnie? TOR (dyskusja) 11:42, 16 kwi 2020 (CEST)[odpowiedz]
    @TOR: Wedle życzenia. Wydawało mi się wprawdzie, że pewne założenia organizacyjno prawne tego projektu warto by przedyskutować najpierw poza wiki, ale jeśli nie masz nic przeciwko temu, to możemy i tutaj. Ankry (dyskusja) 21:43, 16 kwi 2020 (CEST)[odpowiedz]
  • @Electron: Mając doświadczenia z Wikilivres, na pewno jesteś świadomy tego, że nie jesteśmy w stanie po prostu "przenieść" kont z Wikiźródeł, w każdym razie zachowując WMF-owe zasady dotyczące anonimowości. Więc nie można po prostu powiedzieć że admini stąd będą adminami tam. Ponadto, admini (techniczni) tego systemu będą mieli dostęp do informacji o IP użytkowników, co w przypadku jakiegokolwiek powiązania kont może być problematyczne. Z drugiej strony chyba nie bez powodu samodzielne zakładanie kont w Wikilivres było wyłączone, prawda? I chyba tutaj też nie zechcemy pozwolić na zakładanie kont wszystkim spamerom?
Inną kwestią jest odpowiedzialność WMPL za zamieszczone tu treści. I dotyczy to nie tylko tekstów, ale także stron dyskusji. Odpowiedzialność ta w Europie jest dużo większa niż w USA i może rodzić dodatkowe koszty/ryzyko, które WMPL może zdecydować się ponieść albo nie. Prawdopodobnie dotychczasowe doświadczenia z użytkownikami Wikiźródeł i ich podejście do kwestii prawnych, zwłaszcza prawnoautorskich, dają tu pewien poziom bezpieczeństwa. Ale czy można przewidzieć jak będzie w przyszłości?
Jest kwestia, jakie teksty miałyby tu być wrzucane: wszystko na hurra, czy może jakieś wstępne zatwierdzanie każdej nowej pozycji? Wtedy jak i przez kogo? Co będzie jeśli ktoś zdecyduje się wrzucić tłumaczenie Mein kampf na CC-BY-SA 3.0? Albo przekłady białoruskich autorów zmarłych w latach 1950-tych? Czy choćby teksty PD, ale antysemickie? Lub przekłady francuskich autorów, które są PD w Polsce, ale we Francji już nie? Możemy tę listę rozwijać. Na pewno ktoś z WMPL musi mieć prawo weta i wywalenia bez dyskusji czegokolwiek, co do takiego systemu trafi. Bez pyatń i bez dyskusji. Natomiast wydaje się, że WMPL nie byłoby zainteresowane tym, by ktoś od nich weryfikował każdy nowo wrzucony tekst.
Kolejną sprawą będzie opozycja wewnętrzna. Są już głosy, że uruchomienie takiego projektu będzie ze szkodą dla Wikiźródeł, bo każdy user, który pójdzie edytować tam, nie będzie edytował tu. I to fakt.
Ankry (dyskusja) 22:23, 16 kwi 2020 (CEST)[odpowiedz]
Moim zdaniem jeśli to byłby projekt w polskiej domenie i na polskich serwerach to tylko polskie prawo autorskie się liczy. Bo przecież o to chodzi aby "uwolnić" te utwory, które według polskiego PA są już PD, ale w USA (lub gdziekolwiek indziej) są dalej chronione. Prawo zwykle działa tylko na danym terytorium, a my w większości mieszkamy w Polsce więc powinniśmy mieć możliwość w pełni z niego skorzystać. Oczywiście należy brać także ratyfikowane przez Polskę zobowiązania międzynarodowe w tej dziedzinie (bo są one traktowane na poziomie ustaw), ale nic ponadto.
Co do jakiejś formy cenzury: prawdę powiedziawszy jestem przeciw cenzurze. W wikilivres mieliśmy zaczęty "Mein kampf" w oryginale (w proofread). Co ciekawe pdf był zaciągany z commons. To dzieło historyczne i powinno być dostępne, jak każde inne. Nie żebym był jego fanem, i namiętnie się w nim zaczytywał (prawdę powiedziawszy jakoś do tej pory nie chciało mi się w nie zagłębiać, chociaż jak ktoś chce to i tak w sieci może znaleźć jego przekład), ale jak zaczniemy coś cenzurować, to różne grupy zaczną dodawać nowe pozycje, bo dlaczego by i nie? Zawsze można znaleźć jakieś powody. Powiedział bym tak: od przeczytania tego "dzieła" od razu nikt nie robi się hitlerowcem i chce wywołać III wojnę. Druga w zupełności większości wystarczy... A osoby o skrajnych poglądach zawsze były i będą. Nie należy ich tylko dopuszczać do władzy. Oczywiście właściciel serwisu może zawsze narzucić jakieś własne dodatkowe reguły, ale to zwykle tak jest, że kto wykłada pieniądze ten ma zawsze więcej do powiedzenia...
Co do identyfikacji nowych/starych kont użytkowników: to nie ma problemu. Już to przecież było przerabiane: po prostu zakładający nowe konto o tym samym brzemieniu jak w starym serwisie deklaruje, że jest tym kim jest, a dodatkowo proszony jest aby w starym serwisie (po zalogowaniu się) to potwierdził. I to w zupełności wystarczy. Gdy natomiast ktoś obcy zakłada konto o takiej samej nazwie jak w starym serwisie miał ktoś znany, z dużą ilością edycji, to się go prosi o zmianę jego nazwy, a gdy to nie poskutkuje to się ją zmienia bez jego zgody z uwagi na takie przyjęte zasady. Podobnie było w projektach wikimedii, gdy unifikowano konta. A Electronów było chyba z kilkunastu w innych projektach (całe szczęście, że z małą ilością edycji i głównie nieużywanych). Trochę trwało zanim to wyprostowałem... W wikilivres/bibliowiki blokada samodzielnego zakładania konta trwała tylko czasowo, zanim nie zainstalowaliśmy systemu moderacji edycji dla nowych użytkowników (z uwagi na spam-boty). Ale w wikiźródłach spam-boty są temperowane skutecznie w inny sposób...
Co do opozycji wewnętrznej - to nie zróbmy z niej opozycji zewnętrznej. Bo może sobie równie dobrze pójść lub założyć nowy serwis który nie będzie miał takich ograniczeń. A to już może być konkurencja. Chociaż konkurencja jest zwykle sytuacją zdrową, to przy niewielkich serwisach rozbicie sił i środków zwykle nikomu nie wychodzi na dobre. Po za tym nie widzę tego, aby np. polska sekcja w old wikisource odciągała jakąś poważną część dotychczasowych użytkowników wikiźródeł - jest tylko ich uzupełnieniem, gdzie publikuje się prace, które są PD w USA a w Polsce nie są. Tak będzie moim zdaniem i z "polskimi Wikiźródłami", tylko że będą tam publikowane prace, które są PD w Polsce a w USA nie są... W Wikilivres zwykle działali użytkownicy aktywni także w wikisource. Electron  <Odpisz> 11:38, 17 kwi 2020 (CEST)[odpowiedz]
@Electron: Mówisz: "polskie serwery, polskie prawo", inni myśleli: "amerykańskie serwery, amerykańskie prawo", a niemiecki sąd miał inne zdanie. Jesteśmy w Unii, trzeba różne warianty brać pod uwagę.
Co do Mein Kampf: ty możesz chcieć wrzucić, natomiast prezes WMPL może nie chcieć w tej sprawie spotykać się z prokuratorem. Trzeba to jakoś wyważyć. To samo dotyczy swobodnego zakładania kont: jeśli każdy je będzie mógł założyć, to jest ryzyko, że ktoś wrzuci coś, czego nie powinien. I jeśli z jakiegoś powodu nie zostanie to dostatecznie szybko usunięte, to WMPL może mieć problem. Jestem pewien, że WMPL nie chce tu zatrudniać moderatora, a czy na wolontariuszach można polegać? Tu jest właśnie różnica pomiędzy umieszczeniem serwisu w Europie, a np. w Ameryce: u nas odpowiedzialność (i obowiązki) hostującego jest większa. Według mnie serwis ze swobodnym zakładaniem kont przez użytkowników jako serwis prowadzony przez WMPL w ogóle nie wchodzi w grę Ankry (dyskusja) 21:31, 17 kwi 2020 (CEST)[odpowiedz]
Toteż mówię, że to jest moje zdanie, a właściciel serwera ma zwykle zdanie ostanie. Co do niemieckiego sądu: tak czy owak, jego decyzje mają skutek tylko na terytorium Niemiec. Po za tym pisałem przecież, że umowy międzynarodowe ratyfikowane przez Polskę są wg polskiego prawa jego częścią (w mocy polskich ustaw) więc należy je oczywiście brać pod uwagę... Co do zakładania kont: sprawa jest do dyskusji, ale przecież to, że to ktoś inny założy konto dla danego użytkownika nie daje jeszcze 100%-owej gwarancji, że on czegoś takiego nie wrzuci. Po to są admini aby to wyłapywali a w sytuacjach wątpliwych przeprowadza się dyskusje nad danym przypadkiem. Po za tym: to nie jest tak, że w serwisie nie można popełnić błędu - chodzi o to żeby błąd był wyłapany i naprawiony w rozsądnym czasie. Np. jakiś czas temu jeden wandal namieszał mi w OP i miedzy innymi podmienił na stronie tytułowej jedną z ilustracji na "zwis męski prosty". Ja to potem oczywiście odkręciłem, a jego zablokowałem na amen. To znany stały wandal i był już definitywnie zablokowany ale skorzystał z tego, że zmienił IP po zakupieniu karty jednego z operatorów mobilnych. Czy ja jestem winny temu, że serwis prezentował przez jakiś czas pornografię na stronie głównej? Nie. Zrobiłem co było można i w tak krótkim czasie jak się tylko dało. Takich sytuacji nie można nigdy wykluczyć całkowicie, zwłaszcza w serwisach o dostępie otwartym. A za dane czyny odpowiada przede wszystkim ten, kto je dokonał. Electron  <Odpisz> 21:57, 17 kwi 2020 (CEST)[odpowiedz]

Nieźle się nagimnastykowałem z tym, ale dalej mam problem. Jeden z wierszy kończy się słowem choćby, następny zaczyna słowem najmniejszą, ale w zamyśle chciałbym, żeby nie było złamania do nowego wiersza. Niestety nie umiem tego złamania usunąć. W jaki sposób ten problem usunąć? Superjurek (Dyskusja) 00:48, 25 maj 2020 (CEST)[odpowiedz]

@Superjurek: Trzeba tak wykombinować, by to umieścić w jednym tagu <pages ... > Spróbuję coś wyrzeźbić. Ankry (dyskusja) 09:33, 21 cze 2020 (CEST)[odpowiedz]
Zobacz teraz. Sekcja na stronie nie musi być ciągła. Ankry (dyskusja) 07:07, 26 cze 2020 (CEST)[odpowiedz]

Wersje przejrzane

W związku z tym, że rozszerzenie FlaggedRevs jest od dłuższego czasu nierozwijane, nie ma wsparcia, ta sytuacja coraz częściej powoduje różne problemy (np. wczorajsze "zamulanie" przy ładowaniu stron) i istnieje ryzyko, że zniknie zupełnie, sugeruję, by się zastanowić, czy jest ono dla nas niezbędne i czy dałoby sie je ewentualnie czymś zastąpić.

Rozszerzenie to posiada dwie funkcje wykorzystywane obecnie na wiki

  1. możliwość "zatwierdzania" edycji stron dokonywanych przez niedoświadczonych użytkowników,
  2. ukrywanie takich edycji przed niezalogowanymi użytkownikami.

Moim zdaniem ta druga funkcja jest w przypadku Wikiźródeł (w odróżnieniu od Wikipedii) nieistotna, gdyż treści, które moglibyśmy chcić w ten sposób ukrywać (wandalizmy, nieporadne edycje początkujących) rzadko trafiają do przestrzeni głównej, gdzie ich ukrywanie ma sens (raz, że wandalizmy są u nas generalnie rzadkie, a dwa, że są trudne technicznie poprzez mechanizm transkluzji używany przez ProofreadPage). Z kolei edycje początkujących mają zwykle miejsce w przestrzeni Strona i do przestrzeni głównej w takiej formie nie są transkludowane.

Dlatego skoncentruję się na tym, co by można zrobić w pierwszej kwestii.

Według mnie można by tę rolę rozszerzenia zastąpić dwoma nowymi funkcjami:

  1. skrypt w js, który by sprawdzał, kto ostatnio edytował daną stronę, jakie ma uprawnienia i jeśli nie był do redaktor dawał edytującemu stronę redaktorowi wyraźny komunikat (dla edytujących nieredaktorów nic by nie robił)
  2. generowana co jakiś czas (np. przez bota) lista stron wymagających "przejrzenia", czyli takich, które ostatnio edytowali "nieredaktorzy"

Minusy tego rozwiązania w porównaniu z obecnym

  • nieco wolniejsze ładowanie formularza edycji strony (bo skrypt musi sięgnąć do jej historii; a może nie?)
  • wymagałoby to większej uwagi od redaktorów, gdyż w tym wariancie każda ich edycja "niezatwierdzonej" strony oznaczałaby jej "zatwierdzenie" (ale w końcu na tym ma chyba polegać rola nas, redaktorów?)
  • "zatwierdzenie" wersji strony wymagałoby jakiejś realnej edycji (np. dodanie/usunięcie spacji, podbicie statusu; itp.); można w tym celu utworzyć pusty szablon {{zatwierdzone}}.
  • "zatwierdzone" strony znikałyby z listy stron "do przejrzenia" nie od razu, lecz po następnym przebiegu bota.
  • starsze edycje świeżo upieczonych redaktorów stawałyby się automatycznie zatwierdzone w chwili nadania uprawnień; można by co prawda kombinować ze sprawdzaniem przez skrypt w jakiś sposób daty nadania uprawnień (ale to by chyba nadmiernie go skomplikowało)
  • inaczej by działało "odbieranie" uprawnień ("nieprzejrzane" by się stawały wszystkie strony których najnowszej edycji dokonał ten user); ale to może być akurat plus, nie minus.

No i główny problem, że ktoś to musi zaimplementowac...

Proszę szanownych redaktorów o opinie. Ankry (dyskusja) 15:26, 7 wrz 2020 (CEST)[odpowiedz]

Również uważam, że "funkcja ukrywanie" nie bardzo jest u nas przydatna, i jej brak raczej nie będzie zauważalny. A jeżeli chodzi o minusy nowego rozwiązania nie wyglądają na problemowe (zwłaszcza, że niektóre mogą się okazać plusami). Jestem za wprowadzeniem nowego rozwiązania. O ile oczywiście znajdzie się ktoś kto to zrobi, bo na technicznej stronie to ja się niestety za bardzo nie znam. Joanna Le (dyskusja) 10:55, 8 wrz 2020 (CEST)[odpowiedz]
 Za, bo chyba to dłuższe ładowanie nie będzie wynosiło więcej niż kilka sekund. A może jakieś podobne rozwiązania mają inne wersje językowe? Matlin (dyskusja) 12:45, 8 wrz 2020 (CEST)[odpowiedz]
Chyba nie. Temat "co zrobić z nierozwijanym i niewspieranym FlaggedRevisions" nie jest wprawdzie nowy (phab:T185664), jednak większość, zwłaszcza wikipedyści, liczy pewnie że WMF się weźmie i coś zrobi. Powyższy wariant dotyczy sytuacji "a jeśli nie?" Ankry (dyskusja) 15:02, 8 wrz 2020 (CEST)[odpowiedz]
Proponowane rozwiązanie przypomina napisanie tego rozszerzenia od nowa. Jeżeli chodziłoby tylko o wyłączenie ukrywania to da się zrobić, reszta pożądanych funkcji by została. W MediaWiki jest też wbudowany mechanizm do oznaczania jako "sprawdzona" strona i edycja. Można by go udostępnić szerszej grupie niż administratorzy. Wargo (dyskusja) 12:50, 10 wrz 2020 (CEST)[odpowiedz]
I to de facto jest napisanie od nowa tej części, która jest dla nas przydatna. Ale może ktoś ma lepszy pomysł? Ankry (dyskusja) 20:00, 10 wrz 2020 (CEST)[odpowiedz]
A co z wbudowanym mechanizmem patrolowania? Sprawdź czy widząc nowo utworzoną stronę przez osobę nie-automatycznie zatwierdzoną widzisz w prawym dolnym rogu link do oznaczenia jako sprawdzoną. Albo w porównaniach zmian pod informacjami o prawej wersji. To inny mechanizm i jest bardzo uproszczony - daje tylko znacznik sprawdzona/niesprawdzona. Uprawnienie autopatrola też działa. Wargo (dyskusja) 23:44, 10 wrz 2020 (CEST)[odpowiedz]
Tu nie chodzi wyłącznie o nowo utworzone strony. Równie istotne są edycje już istniejących. A także o, rzadko stosowaną, możliwość odebrania uprawnień (automatycznie zatwierdzonych, o ile wiem, się nie da). Ankry (dyskusja) 13:45, 11 wrz 2020 (CEST)[odpowiedz]
Funkcja obejmuje również oznaczanie edycji. Zobacz na Wikidanych. Grupy użytkowników można konfigurować i nadać im uprawnienie "autopatrol". Można też stworzyć grupę odbierającą uprawnienia jeżeli usuwanie z grupy stanowiłoby problem. Wargo (dyskusja) 15:06, 11 wrz 2020 (CEST)[odpowiedz]
  • Może zastosować to co już jest opracowane i dalej jest rozwijane: mw:Extension:Moderation. Mieliśmy to kiedyś w Wikilivres. W skrócie: wszystkie nowe edycje użytkowników nie będących w grupie automoderatorów są zapisywane w rejestrze do moderacji i do momentu ich aprobaty nie są widoczne dla ogółu. W sumie już po pierwszej edycji widać czy jest to dzieło wandala, czy też nie - więc od razu można zdecydować, czy usera można dodać do listy automoderatorów, a jego dotychczasowe edycje zatwierdzić. Dość radykalne (w stosunku do dotychczasowej praktyki, ale bardzo skuteczne). Electron  <Odpisz> 14:24, 11 wrz 2020 (CEST)[odpowiedz]
      1. Tego chyba nie ma na serwerach Wikimedia.
      2. W przestrzeni Strona, owszem wandalizmy widać. Ale chodzi nie tylko o wandalizmy, ale także o przejrzenie edycji początkujących użytkowników pod kątem ich poprawności. Natomiast w przestrzeni main, wandalizm może polegać na zamieszczeniu tekstu innego niż w podawanym źródle. A to, czy tak jest, czy nie, nie zawsze widać.
    • @Wargo: Jeśli patrolowanie, spełniałoby nasze wymogi, to rzeczywiście nie warto wyważać otwartych drzwi. Ankry (dyskusja) 00:36, 12 wrz 2020 (CEST)[odpowiedz]

tag <hr>

Zauważyłem dziś problemy z tagiem <hr>. "Nabył" on z jakiegoś powodu zerowy rozmiar, przez co generowana przezeń linia "zniknęła" podczas renderowania przez przeglądarkę. W szablonach {{---}} i {{===}} poprawiłem to, ale ten tag jest używany w wielu innych miejscach i nie wiem co z tym zrobić:

  • przywrócić "starą" wartość w globalnym CSS (która nie mam pojęcia dlaczego została zmieniona)
  • dodać dodatkowy atrybut wszystkim hr-om... (botem?)

Sugestie co do sposobu naprawienia są cenne. @Zdzislaw: masz jakieś pojęcie o przyczynach zmiany? Ankry (dyskusja) 17:55, 10 wrz 2020 (CEST)[odpowiedz]

phab:T262507. Czekamy. Ankry (dyskusja) 21:47, 10 wrz 2020 (CEST)[odpowiedz]
@Ankry: widziałem to w [1], ale znaleźć/połączyć z [2] nie zdążyłem :) Zdzislaw (dyskusja) 22:52, 10 wrz 2020 (CEST)[odpowiedz]

Pojawił się nowy wodotrysk w ProofraedPage, który nawet nie wiem jak po polsku nazwać (kontrolka listy stron?), a który wstępnie skonfigurowałem. Można go sobie aktywować podczas edycji indeksu. Służy do numerowania / nazywania stron w indeksach używających <pagelist>. Krótko mówiąc jego przydatność jest dla nas ograniczona. Jednakże, gwoli formalności, jeśli ktoś chce ich używać lub ma sugestie/uwagi odnośnie nazywania wybranych stron to proszę je kierować do mnie, lub do kogoś z pozostałych administratorów interfejsu, którzy mogą edytować tę stronę. Ankry (dyskusja) 14:11, 11 wrz 2020 (CEST)[odpowiedz]

Przykładowy efekt użycia tego wodotrysku jest tutaj. Ankry (dyskusja) 14:19, 11 wrz 2020 (CEST)[odpowiedz]

Zlynchujemy Strona:Karol May - Czarny Mustang.djvu/98

czy można poprawić czy zostawić -- niepodpisany komentarz użytkownika Anwar2 (dyskusja | wkład) 10:33, 23 wrz 2020‎

Ale tu nie ma co poprawiać: słowo ma angielki pierwowzór "lynch", więc pewnie tak się wtedy pisało... Electron  <Odpisz> 10:44, 24 wrz 2020 (CEST)[odpowiedz]

Pomysł na autoprzypisy

Może ktoś ma pomysł jak skonstruować taki szablon przypisów, które by się same pojawiały w tekście w razie potrzeby, a nie ujawniały swojej obecności gdy w tekście nie ma refów. Oczywiście tak działa tag <references/>, ale mi chodzi o to, aby w razie potrzeby oprócz przypisów tak samo znikał lub pojawiał się napis "Przypisy". Uprościłoby to automatyzację tworzenia stron, bo można by zawsze wstawiać tam taki szablon, a przypisy by się pojawiały w tylko w razie potrzeby. Electron  <Odpisz> 00:38, 1 paź 2020 (CEST)[odpowiedz]

Temat był już rozważany: po stronie serwera się nie da: przypisy są dodawane przez rozszerzenie do kodu strony po jej przetworzeniu przez parser (więc taka możliwość musiałaby i mogłaby istnieć jedynie wewnątrz tagu <references/> (ale nie zlokalizowałem żadnej funkcji rozszerzenia, którą by można tu wykorzystać). Można by się oczywiście bawić z widocznością/usuwaniem sekcji na poziomie przeglądarki, ale to z kolei popsułoby e-booki (bo generator nie odpala żadnych skryptów - nie potrafi tego). Ankry (dyskusja) 07:26, 1 paź 2020 (CEST)[odpowiedz]
Z tego co znalazłem tutaj ->Help:Cite#Adding an automatic heading before the references list wynika, że istnieją na to 2 sposoby, ale oba dość inwazyjne; tzn. mamy zawsze dodawany autonagłówek (o sztywnie zdefiniowanych parametrach) przed <references/> gdy tylko pojawią się przypisy. Czasami jednak to może być niezbyt wygodne: gdy już jest generowany nagłówek przez jakiś inny szablon przypisów. Można by było oczywiście z tą sztywną właściwością się pogodzić, a z dotychczasowych szablonów przypisów usunąć nagłówki... tym niemniej nie zawsze to może być wygodne. Electron  <Odpisz> 12:43, 1 paź 2020 (CEST)[odpowiedz]
Tak jak wyżej, skrypty tylko wpłyną na wyświetlanie w przeglądarce. Ale dałoby się dodać do niego sprawdzanie, czy jest już jakiś nagłówek. Może lepszym pomysłem byłoby wstawianie automatyczne do okna edytowania, gdy wykryje określony ciąg znaków... Czy automatyzacja o której piszesz jest tak często konieczna? Wargo (dyskusja) 09:49, 2 paź 2020 (CEST)[odpowiedz]
Przydatna by była taka funkcjonalność często (moim zdaniem przede wszystkim na podstronach w przestrzeni głównej = rozdziały książek). Pomysł jest taki, by przy tekstach "standardowych" W pustyni i w puszczy/Rozdział 3, W pustyni i w puszczy/Rozdział 4 różnic w kodzie strony było jak najmniej. Problematyczne jest to, że w części rozdziałów powinny się znaleźć przypisy, w innych są zbędne (i wyglądałyby bezsensownie = pusta sekcja). Oczywiście nie jest to jakaś kluczowa funkcjonalność natomiast zaburza koncepcję automatyzacji tworzenia podstron. Draco flavus (dyskusja) 10:07, 2 paź 2020 (CEST)[odpowiedz]
  1. Na stronach będących w przestrzeni Strona: (Page:) wstawianie nagłówków mogło by zaburzać potem wyświetlanie przypisów na stronach zbiorczych, więc nie ma to tam raczej sensu.
  2. Myślałem już o wstawianiu autonagłówków poprzez sprawdzenie czy w tekście strony występują tagi <ref> (dało to by się zrobić za pomocą funkcji String). O ile działałoby to pewnie dla zwykłych stron, to już dla treści inkludowanych (a takie mamy przede wszystkim na stronach rozdziałów) to nie zadziała bo nie widzę sposobu zajrzenia za pomocą tej funkcji do stron, które mają być inkludowane (nie mówiąc już o tym, że przy dużej ilości inkluzji mogło by znacząco spowalniać proces ich wyświetlania).
  3. Najgłupsze jest to, że (jak wynika z cytowanego helpu) do wersji MediaWiki 1.29 autoheading był funkcją wbudowaną. I komuś (nie wiadomo dlaczego) to przeszkadzało i został usunięty... Electron  <Odpisz> 11:54, 2 paź 2020 (CEST)[odpowiedz]
Wstawiłem dzisiaj {{pw}} na stronę Strona:M. Arcta Słownik Staropolski.djvu/1011 i się ździebko zdziwiłem, że na stronie M. Arcta Słownik Staropolski/Zwoźny pojawiła się "automagicznie" sekcja {{przypisy}} generowana przez szablon {{Staropolski}} a konkretnie współpracujący z nim Moduł:Staropolski spłodzony swego czasu przez @Zdzislaw:. A więc jednak można? Electron  <Odpisz> 13:31, 2 lis 2020 (CET)[odpowiedz]
@Electron: można, gdy cała treść strony generowana jest przez moduł przed odpaleniem parsera. To jest wykonalne dla maleńkich stron słownika, lecz dla normalnych tekstów już nie, ponieważ przy ~70% z nich (trzeba modułem zajrzeć do każdej inkludowanej strony) przepełniałoby ograniczenia serwera i wywalało błędy parsera. Zdzislaw (dyskusja) 17:17, 15 lis 2020 (CET)[odpowiedz]
Tak coś przypuszczałem, że obejście tego byłoby dość mocożerne; czyli na razie klapa. Chyba, że przywrócą autoheading... Electron  <Odpisz> 11:45, 16 lis 2020 (CET)[odpowiedz]
Ja niestety również nie znalazłem sposobu uniwersalnego ukrywania/tworzenia przypisów. Owszem, można sprawdzać modułem, czy w danym zakresie stron występują charakterystyczne ciągi znaków <[Rr][Ee][Ff]>, {{[Pp]w| , {{[Bb]wd| ale:
  1. prawie cały zysk z uniwersalności narzędzia bierze w łeb, bo musimy dwa razy wpisywać to samo raz w tagu <pages...> drugi raz w omawianym wywołaniu modułu
  2. sprawę bardzo komplikują ewentualne sekcje (czytaj początek/koniec rozdziału w środku strony).
  3. naprawdę nie wiem, jak by w rozsądny sposób należało odwzorować exclude, step itp.
  4. w przypadku więcej niż jednego zakresu stron sprawa się jeszcze bardziej komplikuje
Słowem pomysł jest moim zdaniem warty śledzenia, ale obecnie skórka nie warta wyprawki. W przypadku, przenoszenia do przestrzeni głównej książki (zakresu stron) przepisanej trzeba po prostu zobaczyć, czy na końcu generują się przypisy i ew. uzupełnić szablon {{Przypisy}}.
Brakuje faktycznie takiego narzędzia najbardziej, gdy tworzymy strony w przestrzeni głównej, gdy jeszcze dany zakres jest nieprzepisany oraz gdy tworzymy to dla kogoś początkującego a przepisującego daną książkę.
Wydaje mi się jednak, że tworzenie dodatkowego szablonu/modułu z licznymi ograniczeniami i niedoskonałościami jest raczej bez sensu. Draco flavus (dyskusja) 22:39, 20 lis 2020 (CET)[odpowiedz]

Dane Tekstu

@Electron: mógłbyś wyjaśnić (pokazać) jaki problem występował z rozjeżdżaniem, który był przyczyną do tej edycji +Sekcja "Dane tekstu" w Arial Narrow, bo się rozjeżdża już przy lekkim powiększeniu? Wbijanie w bolda Arial narrow, zamiast natywnego fontu, wygląda lekko mówiąc paskudnie w niektórych rozdzielczościach (litery interpolowane w różnej grubości):

Zdzislaw (dyskusja) 17:09, 15 lis 2020 (CET)[odpowiedz]

U mnie to tak "rzadko" nie wygląda (Napis "Dane tekstu" ledwo mieści się w swojej kratce) i przy normalnym powiększeniu (z którego standardowo korzystam) te 3 strzałki po prawej obowiązkowo przeskakiwały linijkę niżej (i były widoczne po lewej), co wyglądało nie tyle paskudnie ile po prostu głupio. Obecnie nie mam już tego problemu. Oczywiście można zamiast 3 strzałek dać dwie lub jedną albo skrócić napis, ale nie sądzę aby to razem wyglądało lepiej. Electron  <Odpisz> 11:39, 16 lis 2020 (CET)[odpowiedz]
@Electron: DT od roku 2010, tj. od 11 lat, został zdefiniowany jako tabela o stałej szerokości 265px. Niezależnie zatem od rozdzielczości ekranu, samo DT powinno mieć szerokość pozwalającą bez problemu pomieścić treść. Jeżeli zatem u Ciebie napis "Dane tekstu" ledwo mieści się w swojej kratce, to jest to najprawdopodobniej problem lokalnego nadpisania styli lub lokalnego nadpisania defaultowych czcionek i rozwiązania powinieneś szukać w swoich ustawieniach. Arbitralna zmiana czcionki, choć być może polepsza wygląd u Ciebie lokalnie, to pogarsza go u wszystkich innych, korzystających ze standardowych ustawień. Nie tędy droga. Zdzislaw (dyskusja) 16:50, 16 lis 2020 (CET)[odpowiedz]
No i zawsze to u mnie źle działało, aż przebrała się miarka... Moim zdaniem nie wygląda to aż tak źle. A u mnie wygląda o wiele lepiej niż było. A po za tym powinno prawidłowo działać na monitorach większości użytkowników, nawet u takich, którzy mają problemy ze wzrokiem i sobie muszą tekst powiększyć, a jak widać nie działało bo napis był za długi. I nikt do tej pory po mojej korekcji nie zgłaszał jednak problemu, że ta drobna zmiana mu jakoś szczególnie przeszkadza. Electron  <Odpisz> 17:05, 16 lis 2020 (CET)[odpowiedz]
Nikt przez 10 lat nie zgłaszał żadnych uwag, że napis jest za długi. To 1. "jak widać nie działało bo napis był za długi" jest nieuprawione ponieważ pomimo mojej prośby w pierwszej wypowiedzi (mógłbyś wyjaśnić (pokazać)), zamiast pokazać, jak ten nagły problem się objawił, stwierdziłeś, że ledwo się mieścił. To 2. Powiększenie poprzedniej wersji nie powinna powodować problemu, ponieważ powiększałaby się całość, łącznie z tabelką. To 3.
To nie jest drobna zmiana (!) - co innego po prostu zmniejszyć czcionkę, a co innego wbijać bolda w arbitralny narrow, co powoduje, że przy zmianie skórki czy ustawień wiki, napis nie przystosuje się do nowej skórki, tylko zawsze będzie wymuszał Arial Narrow. A to już problem, że w najczęściej używanym szablonie pozbawiłeś wszystkich użytkowników skórki timeless zgodności wyświetlania treści szablonu z całością wybranej skórki (Segoe UI). Wygląda to po prostu nieładnie i razi, gdy jeden napis w tabeli jest inny. Innych styli to także dotyczy. To 4. Uważam, że to nie jest ok i nie jest to dobra praktyka. Wspólne szablony powinny korzystać z ustawień skórki, powinny być responsywne, a nie wymuszać parametrów takich jak krój czcionki, bez powiązania z całością. Zdzislaw (dyskusja) 17:34, 16 lis 2020 (CET)[odpowiedz]
Być może nie powinna a jednak powodowała (myślisz, że w innym przypadku zawracał bym sobie tym głowę?). Jak masz lepszy pomysł na skrócenie nagłówka to działaj śmiało... Bierz jednak pod uwagę, że krótkowzroczni i niedowidzący też mają prawo do prawidłowego jego działania przy różnych monitorach i różnych ustawieniach ich parametrów. Btw. Ktoś korzysta z owej egzotycznej skórki? Robiłeś jakieś badania? Btw2. Masz nieprzyjemną tendencję do narzucania innym tylko twojego punktu widzenia. A tu potrzebny jest szeroki kompromis. Electron  <Odpisz> 18:25, 16 lis 2020 (CET)[odpowiedz]
Cóż, wręcz przeciwnie. Po to prosiłem w pierwszej wypowiedzi o pokazanie problemu, ponieważ chciałem poznać jego genezę i zastanowić się, czy nie da się wprowadzić dodatkowej responsywności tego elementu. Lecz (jak zwykle) przypisałeś mi złą wolę i insynuujesz tendencję do narzucania. Starałem się odtworzyć samodzielnie problem, lecz pomimo ustawienia w przeglądarce (Chrome) rozmiaru czcionki na "bardzo duży" (nie powiększenia, bo te powiększa wszystkie elementy) nie udało mi sie odtworzyć problemu:

Ty zaś, zarzucając mi złą wolę (standard), w komentarzu sugerujesz, że nie biorę pod uwagę krótkowzrocznych, niedowidzących... Idąc tym tokiem powinniśmy w całym serwisie wbić "Narrow", bo zawsze znajdzie się nietypowy stopień powiększenia, przy którym np. opisy w menu bocznym będą uciekać... Otóż responsywaność polega na tym, aby zawartość dostosowywała się do ustawień przeglądarki (tak dopasowywany jest natywny css skórek i nowy Wektor od 12.2019 (można go uruchomić testowo w Preferencjach)). I jeżeli tu (w DT) wymagana byłaby zmiana jego zachowania (swoją drogą oczywiście stała szerokość tabel to zwyczaj bardzo niedobry z punktu widzenia dzisiejszych standardów, lecz tutaj akurat paradoksalnie chroni ona przed przeskakiwaniem), gdybym poznał przyczynę, możnaby... lecz wolisz podejście bo tak. W takim wypadku najlepszym rozwiązaniem, zamiast arbitralnego wbijania fontu Narrow, byłoby po prostu dodanie klasy do opisu i wtedy każdy, komu nagle przeszkadza standard, prostą edycją jednej linii w swoim CSS-ie może sobie ustawić dowolną niestandardową czcionkę, rozmiar, szerokość.... tyle. Zdzislaw (dyskusja) 20:58, 16 lis 2020 (CET)[odpowiedz]
No jakoś to tak wynika z mojego (pewnie jednostkowego) doświadczenia: zwykle nikt (z których większość to zwykle częstszy bywalce) nie zgłasza żadnych uwag, po czym zjawiasz się (zwykle po dłuższej nieobecności) ty i od razu z jakimiś pretensjami...
No dobra, jak ci się to do czegoś nada: od jakichś kilkunastu lat korzystam z monobooka, WinXP, FF ESR 52.9.0 (ostatni mohikanin zdolny do pracy z XP i nie blokowany przez wikimedię), ekran 21,5" FullHD (1920x1080), rozmiar czcionki: normalny, DPI: 150% normalny (przy mniejszym powiększeniu czcionek na tym ekranie ledwo co je widać). I na razie nie zamierzam tego zmieniać, bo jest to ustawienie dobrane po licznej ilości prób i dla mnie najbardziej optymalne. Zresztą wszystkie inne szablony pracują w większości wiki poprawnie. Ten tylko się rozłazi, a konkretnie prawe strzałki w nagłówku. Electron  <Odpisz> 12:53, 17 lis 2020 (CET)[odpowiedz]
@Electron: Czy zaoferujesz jakiś screenshot w ramach przykładu? No i żeby Zdzisław wobec Twoich zarzutów nie stał sam, to stwierdzam, że i u mnie Twoja zmiana sprawiła, że szablon prezentuje się bardzo źle. Vearthy (dyskusja) 13:32, 17 lis 2020 (CET)[odpowiedz]
Nie wiem czy to coś pomoże, ale ok, przesłałem obrazek, w pełnej krasie. To oczywiście kwestia gustu, ale nie należy przesadzać - moim zdaniem jest nieźle, a po za tym znosi on obecnie mężnie nawet bardzo duże powiększenia, czego nie można było powiedzieć o wersji poprzedniej. Electron  <Odpisz> 14:05, 17 lis 2020 (CET)[odpowiedz]
Btw. Dla jednolitości można by było całą tabelkę dać Narrowem: dodatkową zaletą byłoby to, że zmieściło by się więcej treści w krótszej tabelce, bo obecnie przy wielopoziomowych długich tytułach zwykle strasznie się ona wydłuża... Electron  <Odpisz> 14:29, 17 lis 2020 (CET)[odpowiedz]
@Electron: Na wstępie, prosiłbymm o zaprzestanie osobistych wycieczek w stylu:
"zwykle nikt (z których większość to zwykle częstszy bywalce) nie zgłasza żadnych uwag, po czym zjawiasz się (zwkle po dłuższej nieobecności) ty i od razu z jakimiś pretensjami".
Sugestie, że moja osoba zwylke kojarzy się z dłuższymi nieobecnościami jaki ma cel? (pretensje pominę). Czy sugerujesz, że "częstszy bywalec" jest kimś lepszym, a więc ja gorszym?? Gorszym od kogo? A może niegodnym, aby zwrócić uwagę na coś, co od razu po zwykłej mojej dłuższej nieobecności rzuca się w oczy i kłuje zaburzając natywny styl i repsponsywność skalowania? Jaki jest cel zwracania uwagi użytkowników czytających ten wątek na moje częste i długie (z czym się nie zgadzam) nieobecności, a nie na podniesiony problem merytoryczny. Czy chodzi o odwrócenie uwagi od problemu i skierowaniu uwagi na mnie jako Usera, który ma pretencje, poza tym często jest nieobecny, w przeciwieństwie od częstszy bywalce? Pisałem o tym przy Twoim PUA i w odpowiedzi czytałem, że takie wycieczki nie są ok. W dalszym ciągu uważam, że wrzucanie mimochodem wstawek osobistych nie jest ok w dyskusjach na wiki. Takie wbijanie szpileczki, i powtarzające się przypisywania złej woli tej drugiej stronie jest, w mojej ocenie, szkodliwe dla projektu opartego na współpracy społeczności. Nie czuję się z tym dobrze.
Wracając do meritum. Cóż, monobook, który z natury skaluje w dół, plus 21,5" przy FullHD, to rzeczywiście połączenie wymagające niestandardowego skalowania dla czytelności. Na to nie wpadłem. Oczywiście, można sobie wyobrazić bardziej daleko idące dostosowanie ekranu, pomagające osobom ze szczególnymi wymaganiami. I jako, że uważam, że każdy powinien mieć możliwość wprowadzenia przy istotnych elementach interfejsu niestandardowego ustawienia styli, tak jak dla większości elementów skórki, co nie było uwzględnione pierwotnie w szablonie, poprawiłem DT dodając klasę dttable, dzięki której każdy może dowolnie dostosować np. czcionkę w DT. Wystarczy na swojej stronie common.css dopisać kilka linii stylu i poczkać kilka minut, np. (dla Arial Narrow):
/* Style dla DT */
.dttable  {
	font-family: "Arial Narrow";
}
Zdzislaw (dyskusja) 01:06, 20 lis 2020 (CET)[odpowiedz]
Dla tych co nie lubią wycieczek: uważam, że łatanie zasadniczego problemu (czyli napisu zrobionego zbyt szeroką czcionką) za pomocą css-u to jest po prostu porażka. Należałoby zająć się wreszcie tym problemem a nie go obchodzić (z lewa lub z prawa), bo to nie wygląda zbyt profesjonalnie, gdy krytyczny, często używany szablon sobie po prostu nie radzi... Większość osób, u których ten problem występuje i tak nie będzie go łatała css-em ale po prostu uzna, że tak po prostu jest i większości to widocznie nie przeszkadza... I oczywiście może coś sobie pomyśleć o profesjonalizmie jego twórców... Electron  <Odpisz> 15:23, 23 lis 2020 (CET)[odpowiedz]
Stwierdzenie, że DT sobie nie radzi jest nadmiarowe. DT, zgodnie ze sztuką, przejmuje krój czcionki z elementów wyższego poziomu, a więc dostosowuje się (tak jak każdy inny element interfejsu użytkownika wiki) do całości interfejsu, a samo skalowanie rozmiaru fontu także nie jest wymuszane (np. w px), lecz skaluje (do 120%) ten przyjęty przez Twórcę skórki, przeglądarki lub ustawień użytkownika. Jak użytkownik ustawi sobie ulubioną skórkę to treść w DT przejmuje jej krój, styl, wielkość..., jeżeli ktoś wymusi czcionkę w ustawieniach przeglądarki, DT się dostosuje... To właśnie próba narzucenia kroju czcionki w css powoduje nieradzenie sobie szablonu. Twórcy DT zarezerwowali 250px dla zaledwie 17 znaków - myślę, że to duży zapas, i dla 99,9% przypadków nie powinien powodować problemów. Czy obecne 120% to za dużo? Jeżeli to nagłówek tabeli, to powinien się wyróżniać nieznaczenie. Jeżeli nie mieści się w swojej kratce, to raczej w przypadku nietypowych ustawień. Można by usunąć to 120%, lecz czy to byłoby dobre posuniecie, aby zmniejszyć liczbę użytkowników, którym napis w DT się ne mieści o ~0,01%?? Można by oczywiście także zacząć wymuszać automatyczne powiększanie szerokości DT, lecz byłoby to być trudne i powodować inne problemy. Zdzislaw (dyskusja) 20:11, 24 lis 2020 (CET)[odpowiedz]
Zdania nie zmieniam: uważam, że często używany krytyczny szablon powinien być tak skonstruowany ("sam w sobie") aby się nie rozjeżdżał przy byle powiększeniu, nawet w trochę niestandardowych warunkach... Bo to jest po prostu obciachowe dla serwisu. Być może powinien być default ciutek szerszy lub te strzałki powinny być "sklejone" z napisem nagłówka jakimiś spacjami niełamliwymi, które by wymuszały jego większą szerokość... Zauważyłem na przykład, że gdy szablon wypełniają długie tytuły/nad i podtytuły, to się on lekko poszerza i wtedy już nie jest taki wrażliwy na przeskakiwanie strzałek (to jest chyba kwestia 1-2 znaków). Tak czy owak stan obecny jest niezadowalający. Electron  <Odpisz> 13:26, 25 lis 2020 (CET)[odpowiedz]
tak, gdyby usztywnić w jakiś sposób łańcuch w nagłówku, tabela powinna się, ja to ująłeś lekko poszerzyć zamiast powodować przeskakiwanie. Uważam, że to dobry pomysł. Nie wiem jeszcze, jaki sposób tego uszytwnienia byłby najlepszy, lecz przyjrzę się temu w najbliższym czasie. Zdzislaw (dyskusja) 16:45, 25 lis 2020 (CET)[odpowiedz]

Update to ICU Unicode library

Trizek (WMF) 15:53, 16 lis 2020 (CET)[odpowiedz]

Indeks do usunięcia

Mamy w Proofread dwie książki z opowiadaniami Oscara Wilde'a: Duch z Kenterwilu i Duch w zamku. Oba zawierają praktycznie tę samą treść - te same opowiadania i to samo ich tłumaczenie. Jedyną różnicą jest tytuł jednego (a co za tym idzie - także tytuł całego zbioru), no i oczywiście wydawnictwa. Nie zauważyłam też różnic w pisowni. Oczywiście nie porównywałam absolutnie całych tekstów, niemniej wyrywkowe sprawdzanie oryginałów z Polony ([3] i [4]) dawało identyczne wyniki.

Proponuję więc usunąć ten drugi indeks (Duch w zamku), bo pierwszy jest już częściowo przepisany (oraz jest to wydanie wcześniejsze o 2 lata) - nie ma sensu dublować pracy. --Czupirek (dyskusja) 16:07, 27 lis 2020 (CET)[odpowiedz]

 Za jeśli nie będzie osoby, która by chciała przepisać. Matlin (dyskusja) 20:21, 27 lis 2020 (CET)[odpowiedz]

Problem z zamieszczeniem w indeksie stron

Zgłaszam problem. Próbowałem zamieścić w Indeks:PL Wstęp do nauki prawa cywilnego H. Capitant pozostałe strony, ale nie serwer nie chce ich zapisać. Serwer pozwolił mi tylko wstawić pierwszą stronę. Próbowałem zarówno z laptopa, jak i ze smartfona. Kod źródłowy ze stronami udało mi się zamieścić na stronie dyskusji indeksu. Superjurek (Dyskusja) 23:49, 12 lut 2021 (CET)[odpowiedz]

Techniczny problem nie jest trudny do rozwiązania. Natomiast moim zdaniem musimy ustalić daty śmierci obu panów (autor, tłumacz) i datę wydania oryginału. Draco flavus (dyskusja) 09:50, 13 lut 2021 (CET)[odpowiedz]
Lepiej jest scalić pliki. Matlin (dyskusja) 14:33, 15 lut 2021 (CET)[odpowiedz]

Technical maintenance planed‬

Scalenie tabelek ze spisem treści

Cześć, potrzebuję pomocy ze scaleniem tabelek. Jak wykonać łamanie tabeli na kilku stronach? Chodzi o spis treści który wyświetla się na stronie tytułowej mojej pracy magisterskiej. Chciałbym żeby justowanie było jednolite dla wszystkich trzech stron, przez które się przewija spis treści, to jest strony 4, strony 5 i strony 6. Z góry dzięki :) Superjurek (Dyskusja) 14:17, 18 mar 2021 (CET)[odpowiedz]

@Superjurek: Chyba wystarczyłoby użyć samego szablonu {{SpisPozycja}} bez tabelki. Joanna Le (dyskusja) 15:55, 18 mar 2021 (CET)[odpowiedz]
@Joanna Le: Faktycznie, dziękuję za słuszną wskazówkę. Superjurek (Dyskusja) 10:40, 19 mar 2021 (CET)[odpowiedz]

Niepotrzebne wcięcie w nagłówku nr 3.10

Mam problem, w tym rodziale powstaje mi wcięcie przed nagłówkiem 3.10, choć nie wynika ono nijak z kodu źródłowego stron.Superjurek (Dyskusja) 18:52, 20 mar 2021 (CET)[odpowiedz]

Może to dlatego że w 3.10 nie użyto znacznika section tak jak w innych. --Wargo (dyskusja) 22:51, 5 kwi 2021 (CEST)[odpowiedz]
@Superjurek: parser nie widział zakończenia wypunktowania. Zdzislaw (dyskusja) 00:51, 6 kwi 2021 (CEST)[odpowiedz]

Futrue of FlaggedRevs (Pending Changes) extension

Pomóż przetłumaczyć na Twój język

Hello, I’m posting this here because this wiki has FlaggedRevs (Pending Changes) enabled.

This extension is one of the oldest extensions we have in production and currently does not have a maintainer. FlaggedRevs has been the cause of several incidents and visible regressions, especially because software decays and our technology constantly changes.

Another problem with this extension is its scope. While most of its functionalities are not enabled at Wikimedia, or are enabled on a very small set of wikis only (e.g. "multiple dimensions" was enabled only on Hebrew Wikisource, and they agreed to disable it). This has made maintaining the extension a tall order (more of a nightmare). In other words, this extension does too many things, and none well.

To move forward, barely used functionalities of this extension will be removed. Such as: support for multiple dimensions (like “style” and “tone”), multiple tiers (“quality” and “pristine”), several one of its special pages (ProblemChanges, ReviewedPages, ReviewedVersions, QualityOversight), and more. This will make it less of a burden to start maintaining and improving the main functionalities. The user interface will have only one mode in the future (currently it has four).

You can check this Phabricator ticket for more information about functionalities being removed: phab:T277883

These removals would simplify its logic drastically, and enable us to rework its old interface, fix several deprecated dependencies that this extension is the last to block their removal of (like the "action=ajax" API), and reduce the number of issues/incidents/regressions that can be caused by this extension.

Most users of wikis that have this extension enabled (including English Wikipedia and German Wikipedia) won't see any difference. Wikis will still be able to use multiple "levels" (but not multiple "tiers") and will still be able to enable pending changes for whole namespaces, or on a group of pages only (otherwise known as “protect mode”). Those features will not be removed.

To follow the discussion around this, take a look at T185664.

Thank you for understanding and sorry for any inconvenience. Ladsgroup (talk) 18:17, 23 mar 2021 (CET)[odpowiedz]

Wczoraj utworzyłem ten szablon na potrzeby przypisów harwardzkich w mojej pracy magisterskiej. Mam nadzieję, że przyda się też przy innych przyszłych pracach dyplomowych, które ktoś zechce udostępnić na wolnej licencji. Na komputerze działa ok, bo wyświetla dymek przy kursorze. Mam jednak pytanie, czy da się go tak ulepszyć, żeby dymek wyświetlał się również na urządzeniach mobilnych? Superjurek (Dyskusja) 09:51, 4 kwi 2021 (CEST)[odpowiedz]

Rozmiar i typ pliku źródłowego a jakość edycji

Dzień dobry! Chciałbym poruszyć dwie problematyczne kwestie:
1) Proszę otworzyć sobie edycję 2. strony tej noweli. Obrazek ze skanu już przy lekkim powiększeniu wygląda słabo. Gdy zerkniemy na grafikę widzimy, że ma ona szerokość tylko 770px. Jak to możliwe, skoro źródłowa strona podaje rozmiar 2043 × 1128 pikseli? Okazuje się, że oprogramowanie, na którym tu pracujemy, dostosowuje szerokość obrazków wszystkich stron skanu do szerokości jego pierwszej strony. Czyli w większości przypadków tego problemu nawet nie zauważymy, bo w książce skany stron mają bardzo zbliżone do siebie wymiary. Natomiast w przypadku takich „wycinanek“ gazetowych to rozwiązanie techniczne się nie sprawdza i nawet z najlepszej jakości pliku wyjść może kupa. Wiem, że „wycinanki“ gazetowe są małym procentem na WŹ i tylko garstka ludzi będzie musiała tę niewygodę zmęczyć, ale mimo wszystko pytam, czy można to zmienić? Dałoby radę zrobić tak, żeby kolejne strony zachowywały swoją rozdzielczość (przynajmniej w przypadku takich dużych różnic)?
2) Jakość obrazka w oknie edycyjnym w przypadków PDF-ów mocno rozczarowuje. Zainteresowanych zachęcam do porównania np. którejś ze stron powieści Syzyf z plikiem oryginalnym. Pytanie moje brzmi: czy jest szansa polepszyć jakość tego? Czy może po prostu omijać PDF-y szerszym łukiem?

Seboloidus (dyskusja) 20:14, 10 kwi 2021 (CEST)[odpowiedz]
ad 1. niestety tak właśnie jest, są trzy możliwości rozwiązania: a. "podwatowanie" pierwszego obrazka do rozmiaru innych (jeśli tylko on jest taki karłowaty) b. zamieszczenie całego indeksu w formie osobnych obrazków c. zamieszczenie pierwszego obrazka (zakładając że jest to tylko "strona tytułowa" i jest powtórzona na następnym obrazku) jako osobnego obrazka ("okładki") -- znowu z zastrzeżeniem jak w punkcie a. Do wycinanek rozwiązanie b jest najlepsze, ponieważ pozwala bezboleśnie podmieniać skan (lub wstawiać dwa zamiast jednego), można też podawać dokładniej źródło każdego wycinka, można potem połączyć ze skanem całej gazety itp. Jest to jednak dość pracochłonne.
ad 2. z pdf-ami bywały rzadko bo rzadko ale problemy techniczne, ja osobiście wstawiam tylko djvu, ew. jpg/png (wycinanki). Chyba że oryginalny pdf jest tak niskiej jakości, że jakakolwiek konwersja spowoduje nieczytelność pliku wynikowego.
Draco flavus (dyskusja) 20:40, 10 kwi 2021 (CEST)[odpowiedz]
@Draco flavus: Dzięki za informacje, rzeczowo to podsumowałeś. Osobiście bardziej mi odpowiada, aby cały utwór był w jednym pliku (nie wiem ile w tym wygody, a ile przyzwyczajenia), więc w tej problematycznej kwestii skłaniać się będę do opcji a.
Co do pkt. 2 — ja wrzuciłem chyba tylko dwie książki w pdf-ach, skuszony niewielkimi rozmiarami plików, których nie osiągnąłbym po przekonwertowaniu na djvu, chcąc zachować dobrą jakość. I to rozumowanie okazało się błędne. Seboloidus (dyskusja) 23:13, 10 kwi 2021 (CEST)[odpowiedz]
@Draco flavus: Rozwiązanie z powiększeniem pierwszego obrazka do rozmiaru pozostałych sprawdza się bardziej w teorii niż w praktyce. Na przykładzie tego opowiadania widać, że grafika ma 3219px, ale cóż z tego, skoro obrazek w okienku ma wielkość 1024px(!) Zaś samo okienko przy większym powiększeniu strony zaczyna przypominać wizjer z tankietki... Domyślnie nie da się tego okienka powiększyć (co uważam za kolejny minus), lecz można to zmienić w indywidualnym common.css (gdyby kogoś interesowało: .prp-page-image { resize: vertical; }). Seboloidus (dyskusja) 13:35, 14 kwi 2021 (CEST)[odpowiedz]
W rozwiązaniu b. (zamieszczenie całego indeksu w formie osobnych obrazków) jest to samo. Dla przykładu w Bajce o Gacku 3-szpaltowe grafiki mające szerokość ponad 3700px są wyświetlane w oknie edycyjnym w rozmiarze 1024px... 😐 Seboloidus (dyskusja) 01:28, 17 kwi 2021 (CEST)[odpowiedz]
Założenie proofreadpage było takie, że skan powinien się mieścić w prawej połówce okna; raczej mało kto ma ekran o szerokości 7400px. Z drugiej strony, obraz nie powinien być zbyt duży, by nie generować niepotrzebnego ruchu sieciowego (niektórzy wciąż płacą za przetransferowane bajty). Myślę, że gdy standardem będą ekrany o szerokości większej niż 2048px, to można będzie zgłosić programistom sugestię powiększenia domyślnej wartości dla maksymalnego rozmiaru skanu. Wieralee swego czasu optowała za dzieleniem wieloszpaltowych tekstów na osobne szpalty. Wg mnie, o ile w przypadku książek takie podejście może być dyskusyjne, w przypadku wycinków jest bardzo sensowne. Ankry (dyskusja) 14:29, 25 kwi 2021 (CEST)[odpowiedz]
@Ankry: Zgadzam się z założeniem, że skan winien się mieścić w połówce okna. I tak się dzieje, bo jest on na początku wczytany z odpowiednio wyskalowaną width. Problemem jest ta domyślna wartość dla maksymalnego rozmiaru skanu (1024px tutaj), z której on startuje, i która go ogranicza. Gdyby obrazek z Gacka miał 3700px szerokości, to w okienku przy powiększeniu do jednej szpalty osiągnąłby pożądaną jakość, a to — w połączeniu w możliwością wydłużenia tego okna, o czym wyżej napisałem — byłoby umożliwiające komfortową pracę. (Edytowanie z wyświetlonym w całości 3-szpaltowym skanem na super szerokim ekranie moim zdaniem byłoby niepraktyczne, bo przy edycji wzrok niepotrzebnie błądziłby w nadmiarze tekstu.) Rozwiązanie widziałbym w dodatkowej, włączanej w preferencjach opcji, która pozwalałaby wczytywać każdą stronę skanu ze swoją nominalną szerokością (albo przynajmniej wykorzystywać szerokość pierwszej z parametru data-file-width), za cenę niewygody, czyli zapewne dłuższego wczytywania stron. Biorąc jednak pod uwagę marginalność problemu, a właściwie ilość osób, którym to przeszkadza, to pewnie taka opcja „dla koneserów“ nie powstanie prędko, bądź wcale. Nauczony zatem doświadczeniem... ✂ kroję... Pozdrawiam. Seboloidus (dyskusja) 18:11, 25 kwi 2021 (CEST)[odpowiedz]
@Seboloidus: Myślę, że nie rozumiesz gdzie leży problem. Chodzi o to, że często skany są w dużo większej rozdzielczości niż potrzebna. A generowanie skanów o szerokości 2048px dla bajeczek dla dzieci, drukowanych dużą czcionką to jest marnotrawstwo zasobów: potrzeba na to więcej zasobów serwera, więcej bajtów przesłać siecią i wymagać więcej zasobów od przeglądarki (2x większa rozdzielczość to 4x większy plik). I dotyczyłoby to wszystkich skanów, gdzie uzyskanie takiej rozdzielczości jest technicznie możliwe. Dotyczyłoby to przy tym wszystkich użytkowników na całym świecie (a niektórzy mający słabe komputery/łącza mogliby nie być z tego zadowoleni). Dlatego zmiana domyślnej wartości raczej nie wchodzi w grę. Ale proofread wspiera od dawna możliwość ustawiania tej rozdzielczości indywidualnie, per indeks (zobacz np. na mul: parametr Width of scans). U nas nie zostało to zaimplementowane, bo nikt tego dotąd nie potrzebował. Można to zrobić, tyle że jest to dość głęboka ingerencja w system, zmieniająca strukturę indeksu i wymagająca poprawienia szeregu plików konfiguracyjnych oraz, być może, zmodyfikowania botem wszystkich indeksów. Krótko mówiąc: potrzeba konsensusu i kogoś, kto to zrobi (będzie umiał i znajdzie na to czas). Przy ostatnich grzebaniach w strukturze indeksu parę lat temu konsensusu na to nie było (kilka osób podczas wstępnej dyskusji uznało, że to niepotrzebne). Natomiast nie mam 100% pewności, czy da się ustawić indywidualnie większą rozdzielczość niż domyślna maksymalna. Trzeba by to sprawdzić (albo w kodzie proofreadpage, albo przetestować, np. na mul:). Ankry (dyskusja) 20:31, 25 kwi 2021 (CEST)[odpowiedz]
Cóż, nie wszystko jestem w stanie pojąć, ale tutaj zrozumiałem chyba wystarczająco dużo. @Ankry: Dziękuję za wypowiedź. Seboloidus (dyskusja) 21:45, 25 kwi 2021 (CEST)[odpowiedz]
ad 1... d. można zaimplementować w indeksie funkcję ręcznego ustawiania szerokości skanów; wtedy wszystkie strony będą najpierw skalowane do tej szerokości (być może część skalowana w górę), a dopiero potem dostosowywane do aktualnych potrzeb (rzeczywistego powiększenia ekranu). Niektóre wiki mają to zaimplementowane. U nas dotychczas nie było ku temu motywacji. Jednak wątpię, by w przypadku wycinków był to dobry pomysł: generalne założenie jest takie, że dla jednaj "książki" rozmiar stron powinien być ustalony. Ankry (dyskusja) 14:29, 25 kwi 2021 (CEST)[odpowiedz]

Jak powiększyć przyciski pod polem edycji?

Dzień dobry,
W mojej pracy z Wikiźródłami całkowicie nie korzystam z fizycznej klawiatury i myszki, a moim głównym narzędziem pracy są przyciski pod polem edycji. Problem w tym, że niektóre z nich są na tyle małe, że mam problem z ich wybraniem. Czy jest jakiś sposób na powiększenie (nawet 200-300%) tych przycisków bez powiększania całej strony. Rozmiar pozostałego tekstu na stronie mam odpowiedni. Mahnka (dyskusja) 17:33, 24 kwi 2021 (CEST)[odpowiedz]

  • @Mahnka: Dobry wieczór! Nie jestem specem w tym zakresie, ale ja bym rozwiązał to w taki sposób: na swojej stronie common.css proszę wpisać:
/* Wielkość przycisków pod polem edycji */
.plainlinks {
  font-size:200% !important;
}
Wielkość procentowa wedle potrzeb (domyślnie jest 95%). Seboloidus (dyskusja) 22:35, 24 kwi 2021 (CEST)[odpowiedz]

Problemy z szablonem Odnośnik

Ad. Problemy z szablonem Odnośnik
Wracam się z prośbą o pomoc z tym szablonem. Więcej opisałem w dyskusji szablonu.
Superjurek (Dyskusja) 21:33, 25 kwi 2021 (CEST)[odpowiedz]

Abstrahując od technikaliów, nie bardzo rozumiem cel tego szablonu: jeśli informacji w "dymku" nie ma w oryginalnym tekście, to może raczej powinien to być {{Przypiswiki}}? Ankry (dyskusja) 12:39, 27 kwi 2021 (CEST)[odpowiedz]

Pusta strona w wygenerowanym PDF

Dzień dobry,
Czy to jest normalne że w PDF jaki wygenerowałem dla tekstu Antoni Sznejder cała pierwsza strona jest pusta? Mahnka (dyskusja) 14:40, 27 kwi 2021 (CEST)[odpowiedz]

U siebie na pierwszej stronie mam trzy portrety Sznejdera, tak do 1/3 wysokości strony. Poniżej czarno. Szandlerowski (dyskusja) 15:03, 27 kwi 2021 (CEST)[odpowiedz]