Wikiźródła:Skryptorium/Pulpit techniczny

Z Wikiźródeł, wolnej biblioteki
Przejdź do nawigacji Przejdź do wyszukiwania
Monobook icon.svg
Skryptorium
Pulpit techniczny

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

Miłych i owocnych dyskusji!


Nowy gadżet Załaduj w tle skany następnej strony[edytuj]

Witam,
w preferencjach w sekcji Gadżety/Edycja stron dodany został nowy gadżet Załaduj w tle skany następnej strony. Gadżet ładuje w tle grafikę ze skanami następnej strony, kiedy tworzysz lub edytujesz stronę w przestrzeni Strona. Dzięki temu, kiedy przejdziesz do edycji kolejnej strony, skany wyświetlą się znacznie szybciej.
Gadżet szczególnie usprawnia pracę z nowymi indeksami, dla których na commons nie wygenerowane zostały jeszcze odpowiednie obrazy jpg dla poszczególnych stron (przy tworzeniu stron w nowym indeksie), co zazwyczaj dodatkowo zwiększa czas oczekiwania. W takim przypadku grafika zostanie także wygenerowana w tle na commons.
Proszę Użytkowników o testy, uwagi donośnie do ewentualnych problemów w funkcjonowaniu gadżetu oraz sugestie zmian. Zdzislaw (dyskusja) 21:27, 26 lip 2018 (CEST)

Wikiźródła:Wikiprojekt Proofread i limity, czyli puchnąca lista indeksów i co dalej[edytuj]

Dodając dzisiaj do listy kilka indeksów zauważyłem, że powoli, ale systematycznie, zbliżamy się do technicznego ograniczenia rozmiaru tej strony (obecnie rozmiar transkluzji 1 923 107/2 097 152 bajty). Oznacza to, że przy obecnej strukturze i technologii mamy miejsce na ok. 150-200 indeksów. Do końca roku pewnie wystarczy, ale co dalej? Generalnie, aby stronę odchudzić, należałoby usunąć z niej jakąś istotną część informacji, które są na niej zamieszczane przy ładowaniu strony (np. autor, tytuł, status indeksu). Informacje te mogłyby być dodawane później jakimś skryptem (@Zdzislaw?) po załadowaniu strony, ale to będzie trwać nawet kilka minut i obciążać przeglądarkę/sieć. Ewentualnie można stronę podzielić na kilka osobnych według jakiegoś ustalonego kryterium (alfabetyczne [np. A-P, Q-Ż], strukturalne [np. nie transkludujemy wydzielonych podstron], status [np. czerwone/żółte na osobną listę], wiek [starsze niż X lat na osobną listę] itp.). Niestety żadnego oczywistego i bezbolesnego kryterium nie widzę. Można też wywalić z listy całą otoczkę i zostawić "gołą" listę indeksów, jak na stronie Wikiźródła:Wikiprojekt Proofread skrócony, ale to tylko odwlekanie decyzji w czasie o kilka lat kosztem wygody (na tej ostatniej stronie jest jeszcze miejsce na ok. 500 indeksów). Alternatywnym rozwiązaniem jest "dyktatura" (@Bonvol), czyli wprowadzenie zasady, że nie dodajemy więcej indeksów do listy, niż z niej usunęliśmy. Zniechęcające dla wielu.

Uwagi? Komentarze? Propozycje?

Ankry (dyskusja) 10:41, 28 sie 2018 (CEST)

  • "dyktaturę" sobie wypraszam, moje podejście jest bliżej "zrównoważonego rozwoju" (sustainable development), zwanego też "wedle stawu grobla". To zapobiega słomianemu zapałowi. Na pewno (@Matlin, @Ankry:) będę się sprzeciwiał modelowi niemieckich Wikiźródeł — jest po prostu zbyt restrykcyjny, ekstremalny i odstraszający. Ale wyjaśnię jeszcze raz publicznie moje stanowisko, dlaczego stoję za jakością, a nie ilością: projekty (u nas: indeksy) są po to, by je kończyć. Szczycimy się tym, że książki od nas są porównywane z oryginałem przez 3 osoby. Nie podcinajmy więc gałęzi na której siedzimy i uczciwie róbmy indeksy zielonymi! (zresztą pod koniec roku były już takie akcje). Ale nie jestem dyktatorem, po prostu będę robił swoje. Bonvol (dyskusja) 19:12, 28 sie 2018 (CEST)
Dyktatura nie, ale koordynacja? (Anagram16 (dyskusja) 00:11, 29 sie 2018 (CEST))
  • Indeksy są uwierzytelniane, co prawda nie w tempie geometrycznym (wykres). Trzeba brać pod uwagę, że nie można kierować wikiskrybami jako zwartym i podporządkowanym (chociażby prawnie) zespołem. W związku z tym każdy, chociaż upowszechnia wyniki swojej pracy dla całej ludzkości, to pracuje na własny rachunek (w rozumieniu: przepisuje lub koryguje tyle, ile chce (ile mu na to pozwala zapał, zasób czasu i umiejętności), sam dla siebie wyznacza prakseologii. --Matlin (dyskusja) 20:05, 28 sie 2018 (CEST)
  • Wydaje mi się, że naprostszym i najmniej "bolesnym" rozwiązaniem byłoby nie transkludowanie wydzielonych podstron, czyli tam gdzie jest osobna podstrona np. Wikiźródła:Wikiprojekt Proofread/Orzeszkowa dawanie tylko linku do niej. Salicyna (dyskusja) 11:13, 28 sie 2018 (CEST)
    • I mój głowny pomysł, też się na tym opiera. Idzie może nieco dalej: może by się dało zrobić skrypt, który te "podlinkowane strony" dociągnie i doklei do strony wyswietlanej po stronie użytkownika, tab by efekt końcowy był zbliżony do tego co mamy obecnie. Niestety, sam nie podejmę się tego zaimplementować a i takie rozwiązanie ma swój koszt. @Zdzislaw: co o tym myślisz? Ankry (dyskusja) 19:01, 28 sie 2018 (CEST)
  • @Ankry:, oczywiście do zrobienia, jednak należałoby rozważyć najpierw aspekty związane z tym, że rozwiązanie pobierania w tle wielu stron i wklejania ich w stronę po stronie przeglądarki użytkownika, z zastosowaniem js, poza nieelegancją i postawieniem na głowie procesu generowania strony, ma, w mojej ocenie, jedną podstawową wadę, a mianowicie bezpieczeństwa takiego rozwiązania (ja wiem, że na pierwszy rzut oka wydaje się to przesadne). Wymagane byłyby rozwiązania to bezpieczeństwo zapewniające, oraz stałe monitorowanie pod kątem bezpieczeństwa. Doraźnie mógłbym zaproponować usunięcie z generowanych wierszy tabelki linku do stron dyskusji indeksów w kolumnie uwagi, które wg mnie niczego nie dają - zmniejszy to ciężar strony o 20%. Zdzislaw (dyskusja) 22:08, 28 sie 2018 (CEST)
  • hmmmm u mnie pokazuje Rozmiar dołączonych elementów po ekspansji 1 923 107/2 097 152 bajty. @Ankry: czy aby na pewno dobrze zerknąłeś? Zdzislaw (dyskusja) 14:37, 28 sie 2018 (CEST)
    • rzeczywiście, przekleiłem liczby nie z tej strony. Ale pozostałe szacunki są dobre: nowy indeks daje na plus ok. 1kB; zwykle trochę mniej. Ankry (dyskusja) 19:01, 28 sie 2018 (CEST)
      • Minęło 40 dni i mamy 1 957 726/2 097 152. Wychodzi ETA na luty. Myślę, że warto omówić temat na zlocie. Ankry (dyskusja) 14:43, 7 paź 2018 (CEST)
  • Łamiąc zasady, ale muszę: w niemieckich Wikiźródłach bardzo rygorystycznie podchodzi się do dodawania nowych indeksów. I one muszą mieć zadeklarowanych wikiskrybów (tutaj są zasady, także po angielsku). Ale nie wiem, czy dobrym pomysłem jest ograniczona swoboda dodawania. Oczywiście trzeba znać umiar i nie ma sensu dodawania projektów, które i tak będą puste, albo będą "wydmuszkami". Niemniej rygoryzm (nie licząc strony technicznej) to jest przywiązywanie dużej wagi do statystyki (% ukończonych indeksów) i pewne wymuszanie pracy nad rzeczami, która nas nie interesuje. Jeżeli mam interesujące skany na oku, ale aby je dodać, muszę "zazielenić" jakiś projekt, który niekoniecznie mnie interesuje, stawia mnie to w dyspozycji (nawet podświadomego) pośpiechu, a on z kolei może rodzić bylejakość. Reasumując chciałem stwierdzić, że moim zdaniem te ograniczenia powinny zostać wprowadzone tylko przy konieczności natury technicznej. --Matlin (dyskusja) 16:15, 28 sie 2018 (CEST) Dopisek Można np. zrobić szablon Szablon:Tabelka indeksu, który 'wyrywa' ze strony indeksu tytuł, autora i datę utworzenia strony Indeks:...; i na stronie Proofread wprowadzać tylko {{Tabelka indeksu... To by także uproszczało dodawanie indeksów. To, co napisałem, to luźna myśl, nawet nie jestem pewien, czy tak da się zrobić... --Matlin (dyskusja) 16:29, 28 sie 2018 (CEST)
    • Niemcy mają ograniczenie dodawania dużych indeksów (>100 stron). Małe rzeczywiście zwykle szybko schodzą. Z drugiej jednak strony taki przykład: gdy zaczynałem swoje działania z Kraszewskiem, nikt poza mną nie był nim zainteresowany (pomimo kilku deklaracji). Po pewnym czasie mi się znudził; jednak gdybym go wtedy nie dodał i nie przepisał, czy mielibyśmy kiedykolwiek tyle ukończonych jego tekstów? Chętni do korygowania znaleźli się po latach. Podobnie z Kościelną: nie ja ją wrzucałem, ale gdyby nie zrobił tego kto inny, na pewno nie przepisałbym ani jednego tomu. A tak, mam szansę ją przepisać do emerytury. Przykłady można mnożyć. Wg mnie zasada niemiecka jest dobra dla projektów rozmiaru Wikipedii, gdzie jest wielu użytkowników i zainteresowany losowo wybranym tematem zwykle się znajdzie. W małych projektech, gdzie zainteresowani tematem użytkownicy często mijają się znacznie w czasie (nawet o lata), taka zasada zabija projekt. Ankry (dyskusja) 19:01, 28 sie 2018 (CEST)
  • ja proponuję najprostsze rozwiązanie, podzielić projekt sektory od [A do ...] ... [... do Z], przeszukiwanie czegoś dla siebie dalej będzie łatwe i ograniczy ilość klikania do minimum. Co do dyktatury nawet w jej minimalnej wersji to Wikiźródła są wolnym projektem i zawsze będę przeciwny jakimkolwiek ograniczeniom ilościowo/jakościowym, ostatnio patrzyłem na Polonę i planuję pobranie kilkunastu indeksów, chociaż postaram się ograniczyć ze względów o których rozmawiamy ;) @Ankry: jeżeli masz jakieś dojścia do Polony to porozmawiaj odnośnie Zbrodni i Kary dodali dwie części, druga jest dostępna a pierwsza zablokowana, chyba tylko ze względu na przedmowę, może da się udostępnić tylko tekst przetłumaczony bez przedmowy Nawider (dyskusja) 22:35, 28 sie 2018 (CEST)
Tak na marginesie, czy moglibyśmy się jakoś zorganizować w kwestii nowych indeksów Szekspira tak, żebyśmy sobie pomagali, a nie wchodzili sobie w paradę. Bo one na długo zagoszczą na liście. (Anagram16 (dyskusja) 01:03, 29 sie 2018 (CEST))
@Anagram16: Co do Szekspira, to ja raczej przepisywać będę tylko prozę, czyli przedmowy, życiorys poety - resztę będę tylko korygować. Salicyna (dyskusja) 10:16, 29 sie 2018 (CEST)
@Salicyna:, skoro wzięłaś na siebie tę trudniejszą, bardziej odpowiedzialną i niewdzięczną rolę, to przez grzeczność nie będę oponował. Sadzę, że razem z Wolanem dostarczymy Ci bardzo wiele stron do skorygowania. (Anagram16 (dyskusja) 10:22, 29 sie 2018 (CEST))
  • Jeżeli strona Wikiźródła:Wikiprojekt Proofread miałaby zostać podzielona, to może w oparciu o ten podział, który już na niej jest. Tzn. na jednej stronie zostawić "Różne indeksy (nieposortowane)", "Indeksy w grupach tematycznych", "Indeksy wielojęzyczne i w wielu projektach" i "Indeksy niekompletne lub z problemami", czyli punkty 1, 2, 4 i 5 obecnego spisu treści, a na drugą wydzielić punkt 3 - "Indeksy według autorów". Himiltruda (dyskusja) 19:14, 29 sie 2018 (CEST)
  • Właśnie pisałam coś podobnego co @Himiltruda: (Może na osobną stronę przenieść np. pkt. "Indeksy w grupach tematycznych", "Indeksy wielojęzyczne", czy "indeksy niekompletne i z problemami", zawsze dało by to troszkę więcej miejsca,przynajmniej tymczasowo:) Joanna Le (dyskusja) 19:27, 29 sie 2018 (CEST)
  • Ja bym "odchudziła". Nie widzę potrzeby linkowania ze stroną autora ani ze stronami dyskusji, a jedynie z indeksem. Nie martwiłabym się na zapas... Myślę, że fajną alternatywą dla tej strony mogłaby być kategoria, w której by były wszystkie nie ukończone indeksy. Ale jeśli dzielić... intuicyjnie nie "łapię" podziału na grupy tematyczne... lepiej chyba alfabetycznie wg autorów. Wieralee (dyskusja) 20:49, 7 paź 2018 (CEST)

Words hyphenated across pages in Wikisource are now joined[edytuj]

Hi, this is a message by Can da Lua as discussed here for wikisource communities

The ProofreadPage extension can now join together a word that is split between a page and the next.

In the past, when a page was ending with "concat-" and the next page was beginning with "enation", the resulting transclusion would have been "concat- enation", and a special template like d:Q15630535 had to be used to obtain the word "concatenation".

Now the default behavior has changed: the hyphen at the end of a page is suppressed and in this case no space is inserted, so the result of the transclusion will be: "concatenation", without the need of a template. The "joiner" character is defined by default as "-" (the regular hyphen), but it is possible to change this. A template may still be needed to deal with particular cases when the hyphen needs to be preserved.

Please share this information with your community.

MediaWiki message delivery (dyskusja) 12:28, 30 wrz 2018 (CEST)

  • Większość sytuacji typu "północo-" + "zachodni" już poprawiłem; Encyklopedia Kościelna nie wymaga uwagi: to jest wyłącznie czysty OCR. Na pozostałe przypadki dobrze, by ktoś zerknął drugą parą oczu. Odnośnie wierszy z pojedynczym minusem dodawanych kiedyś w okolicach znacznika <poem> przez Ashaio i Vearthy'ego czekam na wyjaśnienie, bo nie rozumiem co autorzy mieli na myśli; ale może ktoś z pozostałych skrybów wie? Ankry (dyskusja) 14:12, 30 wrz 2018 (CEST)
    @Ankry: Mógłbyś podać przykład jakiejś strony z tym pojedynczym minusem, bo nie kojarzę o co chodzi? Salicyna (dyskusja) 17:48, 30 wrz 2018 (CEST)
  • @Salicyna: Ankry na pewno napisze więcej... lecz w dwóch słowach - strony kończące się przeniesieniem słowa, od teraz nie będą wymagać stosowania szablonów {{pp}} i {{pk}}. Po prostu zostawiamy urwany wyraz z minusem na końcu strony a parser połączy go w main automatycznie, co mnie niezmiernie cieszy. W związku z tym trzeba było się przyjrzeć występującym wyjątkom oraz nietypowym użyciem łącznika na końcu strony, takich jak tu i poprawić je aby parser nie potraktował ich jak przenoszenia wyrazów. Zdzislaw (dyskusja) 18:03, 30 wrz 2018 (CEST)
  • Nie przypominam sobie, żebym specjalnie wstawiała myślnik na końcu strony w wierszach, chyba że przez pomyłkę (może to jakaś pozostałość OCRu?). Pamiętam, że kończyłam stronę sekwencją <br><poem> lub <poem><br> i to pomagało zachować równomierne odstępy między wierszami przy łączeniu stron. Ashaio (dyskusja) 08:03, 3 paź 2018 (CEST)
Do sprawdzenia (i ewentualnego poprawienia) jest kilkadziesiąt stron (lista). Ankry (dyskusja) 11:27, 3 paź 2018 (CEST)
@Ankry: Sprawdziłam strony z listy, poprawiłam te które tego wymagały. Natomiast te co pozostały do poprawy to strony w których szablon "pp" nie został zastosowany, ale na kolejnej stronie szablon "pk" już jest. Postaram się je również poprawić. Joanna Le (dyskusja) 17:50, 3 paź 2018 (CEST)

{{pp}}/{{pk}} i takie tam[edytuj]

W związku z pojawiającymi się na IRC-u pytaniami odnośnie mechanizmu łączenia stron wprowadzonego w poprzednim wątku vs. mechanizm dotychczasowy, chciałem przedstawić kilka uwag oraz propozycję.

  • Po pierwsze, korzystanie z {{pp}}/{{pk}} ma jedną przewagę w stosunku do niekorzystania (pozostawienia niepołączonych fragmentów i łącznika): pozwala wyszukiwarkom znaleźć całe (połączone) słowo na obu stronach. Przynajmniej teoretycznie.
  • Po drugie, podczas korekty stron zawierających fragmenty przenoszonego słowa oraz ww. szablony (lub bez szablonów) należy zawsze sprawdzić co jest na poprzedniej/następnej stronie (tu @Zdzislaw: może warto pomyśleć o jakimś narzędziu, które ułatwi w takim przypadku podgląd poprzedniej/następnej strony i/lub pokaże użycie szablonu {{pp}}/{{pk}} na stronie bez wchodzenia w tryb edycji? - np. w "dymku"). Dotyczy to także sytuacji, gdy nie dokonujemy korekty tej poprzedniej/następnej strony (ale zgodność użytego na nich mechanizmu przenoszenia wyrazów trzeba sprawdzić; @Anagram16:).
  • Po trzecie, w przypadku objęcia szablonu {{pp}} ''kursywą'' lub '''pogrubieniem''' należy do treści objętej formatowaniem wiki dodać spację ('' {{pp|coś|-tam}}''). Wprawdzie użycie typu {{pp|''coś|-tam''}} czy {{pp|''coś|-tam}} też działa (ze względu na automatyczne domykanie znaczników wiki przez MediaWiki), ale użycie znaczników wiki w parametrach szablonu (zwłaszcza w tym drugim) jest problematyczne, gdyż parametry te są używane wewnątrz kodu HTML (ten drugi tylko tam), który nie rozumie znaczników wiki (i w efekcie powstaje HTML-owy koszmarek).

Wg moich testów na testowej wiki z ProofraedPage omawiany w poprzednim wątku nowy mechanizm łączenia wyrazów nie "psuje" elementów wikikodu takich, jak |- czy ---- jeśli występują na końcu strony. Natomiast co do łączenia tabelek: gdy nowa strona zaczyna się od nowej komórki: | cośtam zamiast nowego wiersza: |- to parser MediaWiki w interakcji z szablonami ProofreadPage numerującymi strony "psuje" efekt połączenia stron dodając atrybut "hidden" do całego pierwszego wiersza strony. Obejściem tego problemu jest dodanie przd znacznikiem nowej komórki tabeli (| tekst lub parametry) znacznika nowego wiersza (|-) lub użycie sekcji do łączenia tabelki (ale tu też są niuanse). Jest to efekt znany już od paru lat, który próbuję sukcesywnie poprawiać, gdy nań natrafię, niezwiązany z obecną zmianą. Być może "rozwiązaniem" problemu byłoby domyślne wyświetlanie numerów stron; ale nie wiem, czy tego chcemy.
Zwracam jednocześnie uwagę, że znaczniki wikitabelek {|, |-, |, |} nie powinny występować w pierwszym fizycznie wierszy strony (także: nagłówka/stopki), gdyż w wyniku interakcji ze znacznikami <noinclude> dodawanymi przez ProofreadPage powodują nieprawidłowe wyświetlanie zawartości (należy w takich sytuacjach po prostu dodawać przed nimi pusty wiersz).

  • W związku z powyższymi uwagami proponuję, by dopuścić używanie obu mechanizmów łączenia wyrazów. Natomiast w sytuacjach spornych preferować {{pp}}/{{pk}} jako mechanizm o wyższej funkcjonalności. Zwracam także uwagę, że przy przenoszeniu wyrazów, gdzie wymagane jest zachowanie łącznika (np. "polsko-" / "francuski") i tak musimy nadal stosować pp/pk ({{pp|polsko|-francuski}} / {{pk|polsko-|francuski}}).

Ankry (dyskusja) 09:32, 8 paź 2018 (CEST)

Indeksy i informacje na stronach indeksów zamieszczone[edytuj]

Jak zapewne niektórzy z was zauważyli, zacząłem rozbudowywać strukturę indeksu o dodatkowe informacje. Mam nadzieję, że nie są to zmiany kontrowersyjne; a gdyby nawet były jestem otwarty na wszelkie sugestie i uwagi w szczególności odnośnie tego co już dodałem, co można by jeszcze dodać lub zmienić czy też kwestie nazewnictwa.

Zmiany, które zacząłem mają na celu: 1. umożliwienie generowania na podstawie indeksu danych o książce (jako {{Dane tekstu}}, informacje do ebuków czy też Dublin Core 2. kategoryzację indeksów ze względu na stopień zaawansowania (tu będą potrzebne jeszcze dodatkowe zmiany)

Na razie dodałem dodatkowe pola: Redaktor, Druk, Miejsce wydania, Status dodatkowy oraz rozbudowałem nieco drzewko kategorii indeksów.

Myślę, ze warto, by te i inne planowane zmiany w indeksach omówić na Źródłosłowie. Ankry (dyskusja) 02:48, 19 paź 2018 (CEST)

  • Fajne by było (chociaż oszczędza to raczej sekundy, aniżeli minuty) generowanie tego opisu na podstawie samego pliku w Commons, a mianowicie szablonu Template:Book --Matlin (dyskusja) 10:38, 19 paź 2018 (CEST)

Łączenie tekstów z elementami Wikidanych[edytuj]

Zastanawiam się jak łączyć poprawnie teksty na naszych Wikiźródłach z odpowiednimi elementami Wikidanych, tak aby przede wszystkim aktualizowały się na bieżąco inne wersje językowe (chyba że robi to jakiś bot, ale nie wiem, na podstawie jakich informacji miałby to robić). Teraz już intuicyjnie pojmuję, że czym innym jest element np. Wikidata:Q846870, który mówi o oryginalnym wydaniu, a czym innym Wikidata:Q56155531, który jest danym wydaniem książki. Nie wiem tylko czemu moje edycje, dodające link do polskiego Wikisource są revertowane, natomiast nadal są w danym elemencie linki do innych wersji językowych Wikisource. Np. tutaj. Patrząc potem na efekt, widzę, że obcych wersji językowych nie ma. Można je dodać ręcznie, jak to zrobił w jednej edycji Ankry, lecz nie jestem pewien, czy to rozwiązuje problem zwarty w pierwszym zdaniu tego wpisu. Widzę też, że bardzo dużo tekstów jest teraz rozłączanych od elementów (przy takim filtrze ostatnich zmian należy spojrzeć na zmiany użytkownika Emaus). Wiem, że nie jest to typowo temat związany z Wikiźródłami, jednak po aktywności wikiskrybów także w Wikidanych mam nadzieję, że ktoś będzie wiedział, jak poprawnie to czynić. --Matlin (dyskusja) 15:59, 28 paź 2018 (CET)

Przede wszystkim trzeba utworzyć odpowiednie, dwustopniowe struktury w Wikidanych dla naszych tekstów, zgodnie z Wikiprojektem Books w wikidanych, który jest obowiązującym standardem dla tekstów na wszystkich Wikiźródłach. Proste dodawanie interwiki nie działa i jest bez sensu ze względu na wielość przekładów i wydań. Niestety, obawiam się, że przeniesienie wszystkich informacji ręcznie przez naszą społeczność przekracza nasze możliwości (pewnie musielibyśmy przez pół roku lub rok nic innego nie robić), dlatego nawiązując do wczorajszego wykładu PMG na Źródłosłowie, poprosiłem go o rozważenie wsparcia technicznego ze strony WMPL w tej sprawie. Na szybko, interwiki można robić po staremu, za pomocą odpowiednich wikilinków. Ankry (dyskusja) 16:18, 28 paź 2018 (CET)
Moi drodzy. Z racji tego że moja wiedza techniczna na temat połączenia Wikidanych z Wikiźródłami nie jest wystarczająca, przedstawiam was @Powerek38:. Powerek ma szeroką wiedzę z zakresu projektów, więc uważam że będzie mógł wam pomóc. Mam nadzieję że pomożecie mu swoją wiedzą. PMG (dyskusja) 11:20, 5 lis 2018 (CET)
  • (@Matlin:, @Ankry:) Kłaniam się wszystkim. Faktycznie @PMG: w imieniu Zarządu WMPL poprosił mnie o pomoc Waszej społeczności we współpracy z Wikidanymi. Cieszę się z tego zadania bardzo, zwłaszcza że po zakończeniu mojej własnej kadencji w Zarządzie, Wikidane stały się zdecydowanie moim głównym polem aktywności w Wikimediach. Z drugiej strony, sam nie jestem wikiskrybą ani żadnym ekspertem od bibliotekoznawstwa, więc bardzo liczę na Waszą wiedzę merytoryczną. A przechodząc do konkretów, kilka moich uwag / pomysłów / wyjaśnień na dobry początek:
  1. Na pewno zachęcam Was bardzo do dyskusji wewnątrz społeczności projektu na temat szablonu Kontrola autorytatywna. Widzę, że dotychczas jest tutaj zdecydowanie skromniejszy technicznie i rzadziej stosowany niż np. w polskojęzycznej Wikipedii. Osobiście uważam, że KA jest niezwykle przydatnym i ważnym narzędziem przy porządkowaniu i wpisywaniu w szerszy obieg bibliotekoznawczy zbiorów takich jak Wasze. Na Wikidanych mamy już ogromnie dużo oznaczeń KA, a ponadto mamy też mechanizmy pozwalające łatwo importować kolejne oznaczenia z baz zewnętrznych, zwłaszcza z VIAF. Krótko mówiąc: zachęcam do rozmowy, a chętnie przedstawię w niej konkretne propozycje.
  2. Jeśli chodzi o przenoszenie Waszego dorobku do Wikidanych, to na pewno możemy zeskanować specjalnym narzędziem wszystkie Wasze szablony, a zwłaszcza infoboksy. Tą metodą moglibyśmy włączyć do Wikidanych np. daty czy miejsca urodzenia i śmierci autorów, które tu zebraliście. To zadanie mogę dość szybko wykonać ja, mam w tym sporą wprawę, choć niezbędne będzie do tego prawidłowe powiązanie stron Wikiźródeł z elementami WD.
  3. Co do masowego tworzenia / wiązania elementów WD, najpopularniejszą metodą robienia tego jest na dzisiaj narzędzie, które nazywa się QuickStatements. Działa ono w ten sposób, że tworzy się plik w arkuszu kalkulacyjnym, tak naprawdę zwykłą tabelkę danych, a następnie, po eksporcie do pliku CSV, narzędzie masowo ładuje te dane do bazy WD. Mógłbym oczywiście pomóc ogarnąć to technicznie, natomiast pozostaje kwestia stworzenia jakiegoś zespołu, który np. na jakimś dysku sieciowym przygotuje dane w tabelce.
  4. Napisałem o naszej współpracy na grupie najaktywniejszych edytorów WD na FB i już podrzucono mi kilka inspirujących linków: 1, 2, 3. Polecam Waszej uwadze.

Tyle mojego "expose", oczywiście jestem bardzo ciekawy Waszych poglądów, potrzeb, pomysłów itd. Postaram się zaglądać na tę stronę regularnie, a gdybyście życzyli sobie mojej obecności w innym miejscu, pingujcie szablonem. Powerek38 (dyskusja) 15:17, 5 lis 2018 (CET)

@Powerek38: Z kontrolą autorytatywną jest u nas tak, że samo wyświetlenie danych o autorze z Wikidata to nie problem. Natomiast inicjalny pomysł zakładał, że szablon kontroli autorytatywnej powinien również wyświetlać link do listy książek danego autora w bibliotekach cyfrowych, a przynajmniej w CBN Polona. Co, według mnie nie jest trywialne i dlatego zarzuciłem temat. Nikt inny go na razie nie podjął.
Dane o autorach w wikidanych w większości już są i ich uzupełnienie, o ile ważne, nie jest dla na s dużym problemem.
Problemem jest zamieszczenie danych o tekstach i ich organizacji oraz powiązanie tych danych z już dostępnymi danymi pochodzącymi z innych wikisource (w przypadku przekładów). Chodzi o to, że zgodnie z obowiązującym dla tekstów standardem (którym jest d:Wikidata:WikiProject Books) transfer tych informacji nie jest prosty dla przeciętnego redaktora Wikiźródeł (trzeba stworzyć dwa rekordy w wikidanych, odpowiednio je powiązać, i odpowiednio porozdzielać informacje pomiędzy nie, nie wspominając już o znalezieniu z czym je powiązać - np. rekordy wydawnictw, autorów, tłumaczy, języków itp.). Mój pomysł polega na tym, żeby ten proces jakoś (a) zautomatyzować w przypadku istniejących kilkudziesięciu tysięcy tekstów i/lub (b) stworzyć skrypt, który pobierze z odpowiednich stron Wikiźródeł (strona tekstu, spisu treści, indeksu) odpowiednie dane i po zatwierdzeniu przez użytkownika zapisze je w Wikidanych. Jedno i drugie jest niestety nietrywialne i nie ma u nas nikogo, kto mógłby chociaż spróbować coś takiego stworzyć. A jest nas po prostu za mało, by to wszystko wyklikać w Wikidanych ręcznie.
Większość potrzebnych danych już gdzieś na Wikiźródłach jest. Trzeba je tylko wyekstrahować. Być może możemy coś zrobić, aby ten proces ułatwić, ale nie wiedząc jak miałby przebiegać transfer, nie wiemy jak.
Inną sprawą jest, że niektóre kwestie w ramach tego Wikiprojektu są nadal dla mnie niejasne; np. nie mam pojęcia gdzie i w jakiej formie zapisać informację, że dany utwór jest wierszem, poematem, tomikiem poezji, antologią, powieścią lub nowelą. Albo jak należy powiązać utwory (współwydane: powieść i opowiadanie, wiersz zamieszczony w artykule naukowym, opowiadanie ze zbioru czy wiersz z tomiku lub antologii). Gdzie zamieścić informację identyfikującą wydanie, jeśli nie jest numeryczna (np. "szósty tysiąc" albo wydanie "nowe"). Ewentualnie gdzie w wikidanych szukać odpowiedzi na te pytania. Książki poza tym, że mogą zawierać wiele utworów (lub być ich częścią - tomy powieści - a czasem jedno i drugie na raz) mogą mieć kilku wydawców, kilku autorów itp. Dlatego zdaje sobie sprawę, że docelowo zadanie jest nietrywialne, ale od czegoś trzeba zacząć.
Wydaje mi się, że dobrze by było pogadać na ten temat online. IRC? Ankry (dyskusja) 16:12, 5 lis 2018 (CET)
@Ankry: Szczerze mówiąc nie jestem wielkim fanem dyskusji tego typu na IRC, bo ich log mało przejrzysty i stosunkowo trudno dostępny, a jednak mówimy o rzeczach ważnych chyba dla całej społeczności, więc proces powinien być transparentny. Można za to stworzyć tutaj coś w rodzaju dedykowanego wikiprojektu i dyskutować tam. A co do meritum Twojej wypowiedzi:
  • Myślę, że to, o czym piszesz a propos automatycznego tworzenia elementów, wymagałoby dość skomplikowanego technicznie bota, na pewno znacznie powyżej moich umiejętności informatycznych. Pozwolę sobie przywołać tu @Yarl:a i @Masti:ego jako najbardziej "technicznych" członków Zarządu WMPL. Być może chłopaki będą miały pomysł, jak to ogarnąć, albo przynajmniej jak poszukać rozwiązania, być może korzystając ze środków finansowych WMPL.
  • Niewątpliwie najlepszym miejscem na szczegółowe pytania co do edytowania na dany temat jest dyskusja wikiprojektu na Wikidanych. Proponowałbym tam zadać te pytania po angielsku. Na marginesie powiem, że jeśli użyje się na WD szablonów {p|XXXX} lub {q|XXXX}, gdzie XXXX jest numerem właściwości (P) lub elementu (Q), to każdemu wyświetli się jego etykieta we własnym języku, więc nie trzeba się martwić o terminologię.
  • Co do Polony, można zaproponować stworzenie dedykowanej właściwości - identyfikatora w tej bazie. Podobnie dla innych bibliotek cyfrowych, nie jest to przesadnie trudne, tyle że wymaga akceptacji społeczności WD w trwającym tydzień głosowaniu. Oczywiście mogę w tym pomóc. Gdy takie właściwości zaistnieją, każdy projekt będzie mógł składać sobie z nich, jak z klocków, własne szablony itd. Powerek38 (dyskusja) 16:32, 5 lis 2018 (CET)
@Powerek38: Zacznę od końca: w przypadku polony chodzi obecnie o to, że nie widzę u nich możliwości wyszukiwania po autorze; może jest, tylko ja jestem ślepy? A może trzeba o tym doczytać w jakiejś dokumentacji jakiegoś API, do którego nie dotarłem. Kiedyś umiałem to zrobić; po ostatniej (ze 2 lata temu) zmianie softu w polonie nie umiem.
Co do transferu do wikidata: myślałem kiedyś, żeby zrobić to botem. I gdyby to było możliwe, to bym się pewnie tego podjął. Ale po przemyśleniach stwierdziłem, że ze względu na to, że w wikidanych sporo informacji już jest, często błędnych, robienie tego automatem, bez weryfikacji i zatwierdzenia jest ryzykowne. Dlatego, jeżeli robić to botem, musiałbym ten projekt z kimś znającym temat na bieżąco konsultować, żeby zminimalizować ryzyko błędów. Niestety nie mam z kim. I uważam, że nie da się tego robić on-wiki.
Dlatego uważam, że lepsze byłoby narzędzie interakcyjne, które pokaże co wpisuje/zmienia i pozwoli zatwierdzić. Lub nie zatwierdzić.
Jeśli masz inny pomysł jak to zrobić, wal śmiało.
Natomiast o wyklikaniu tego w obecnym GUI wikidanych zapomnij. Mamy ok. 30.000 niezależnych tekstów. Dla każdego trzeba utworzyć po dwa elementy (utwór "work" i wydanie "edition"). Żeby zrobić to dajmy na to w rok trzeba by tworzyć dzień w dzień po ok. 200 dziennie. Można przy tym zwariować. A 10 lat pracy nikt na to nie poświęci. Przyjmij, że ilość userów na wikiźródłach gotowych cokolwiek robić w wikidata oscyluje w granicach 1-5. Na ok. 20-25 aktywnych. Reszta może kliknie, jeśli dostaną guzik pt. "przenieś wszystkie informacje do wikidata".
Najprostszy przykład: masz 50 wierszy z jednego tomiku. Musisz utworzyć 2x50 elementów wzajemnie powiązanych odpowiednimi właściwościami, przy czym poszczególne pary będą się różnić tylko jedną z ok. 10 właściwości: tytułem. Jak to zrobić ergonomicznie. żeby pozostałych dziewięciu nie wpisywać po 50 razy? (a będą to różne: link do autora, może tłumacza, rok wydania, język, link do wydawcy, nazwa drukarni itp.).
Co do pytań: najtrudniej je zadać, gdy właśnie nie wiemy jakiej właściwości albo elementu użyć dla danego pojęcia lub kontekstu. A może po prostu właściwego nie ma? Ankry (dyskusja) 21:27, 5 lis 2018 (CET)
  • @Ankry: Według strony pomocy Polony można wyszukiwać poszczególnych autorów. Na wskazanej przeze mnie stronie, u samej jej góry, wystarczy kliknąć w trójkącik skierowany w dół, znajdujący się pomiędzy okienkiem wyszukiwania a niebieską ikonką lupy. I tam się mieści wyszukiwanie zaawansowane. Ale może nie o to chodzi… Maitake (dyskusja) 21:37, 5 lis 2018 (CET)
    • Żeby pokazać Wam pewien kontekst w sprawie Polony lub innych bibliotek: ja jestem autorem (tzn. byłem pomysłodawcą i stworzyłem wniosek, zatwierdzony w głosowaniu) właściwości P5058, czyli identyfikatora osoby w bazie e-teatr.pl. Żeby stworzyć tego typu właściwość, potrzebujemy od architektury danej bazy tylko jednej rzeczy: aby dało się stworzyć wzór linku, w którym będziemy zaledwie podmieniać jakąś zmienną (czyli identyfikator) i w ten sposób będą powstawać linki do każdego rekordu. W przypadku wspomnianej właściwości wygląda on tak http://www.e-teatr.pl/pl/osoby/$1.html, gdzie $1 jest zmiennym identyfikatorem. Jeśli dostanę od Was coś takiego, reszta jest dość prosta technicznie, choć oczywiście musi zostać zatwierdzona przez społeczność WD. Jeśli w przypadku Polony jest to niemożliwe, to oczywiście wina leży już zupełnie poza Wikimediami. Powerek38 (dyskusja) 22:14, 5 lis 2018 (CET)
      • @Maitake: A udało ci się za pomocą tego mechanizmu utworzyć link do listy tekstów autorstwa Henryka Sienkiewicza (wyłącznie) z pominięciem tekstów innych autorów, zwłaszcza tekstów o Sienkiewiczu? Mi się nie udało. Ankry (dyskusja) 22:37, 5 lis 2018 (CET)
        • @Ankry: Musiałem kliknąć na menu, potem zbiory, potem z lewej strony w pozycji autor zaznaczyć checkbox przy Sienkiewiczu. Nie widzę, żeby wypluło coś innego, niż jego autorstwa. link --Matlin (dyskusja) 22:50, 5 lis 2018 (CET)
To, co ja zalinkowałem, daje ten sam rezultat, jeśli mierzyć go po liczbie zasobów, tylko pomija ten, który nie jest dostępny online (a więc o kilkadziesiąt wyników mniej) --Matlin (dyskusja) 23:04, 5 lis 2018 (CET)
@Powerek38: To jeden problem mamy jakby rozwiązany :) A co z danymi o tekstach zawartymi w {{Dane tekstu}} i indeksie? Jak je można przenieść do Wikidata? Ankry (dyskusja) 23:21, 5 lis 2018 (CET)
To teraz pytanie (do tego, kto wie): co daje przypisanie numeru Q do identyfikatora na e-teatr.pl albo na Polskim Słowniku Biograficznym poprzez narzędzie Mix'n'match? --Matlin (dyskusja) 12:27, 6 lis 2018 (CET)
Na Wikiźródłach jakiekolwiek powiązanie z serwisem e-teatr nie da dokładnie nic, jeśli o to chodziło. Raczej nie publikujemy informacji o aktorach; a jeśli nawet jakiś aktor był także pisarzem, to żadnych przydatnych dla Wikiźródeł informacji o nim w serwisie e-teatr nie znajdziemy. Linkować do e-teatru też raczej nie będziemy. Ankry (dyskusja) 14:04, 6 lis 2018 (CET)
@Ankry:: Podałem przykład e-teatru, żebyście zobaczyli (ci z Was, którzy dotąd nie wiedzieli) jak na WD tworzy się identyfikatory zewnętrzne. Liczyłem, że dzięki temu łatwiej będzie stworzyć identyfikator np. dla Polony. Muszę popracować chwilę nad tym, co padło wyżej, ale być może mamy już dobry trop. Postaram się wkrótce przygotować zgłoszenie takiej nowej właściwości i poddać je obowiązkowej procedurze zatwierdzenia przez społeczność WD. @Matlin:: Mix'n'Match jest narzędziem wspomagającym wprowadzanie do WD identyfikatorów zewnętrznych. Co to daje? Dla odbiorcy wiedzy - możliwość błyskawicznego przechodzenia, traktując WD jako swego rodzaju indeks czy bramkę, między różnymi bazami opisującymi tę samą osobę, co przydaje się, gdy szukamy o niej wiedzy. Dodatkowo wikimedianom daje to możliwość w dużej mierze zautomatyzowanego wyświetlania tych identyfikatorów na stronach projektów (Wikipedii, Wikiźródeł itd.) na zasadzie kontroli autorytatywnej lub linków zewnętrznych. Wystarczy wtedy do tego relatywnie prosty szablon. Powerek38 (dyskusja) 14:27, 6 lis 2018 (CET)

Natomiast, wracając do meritum wątku: mam wrażenie, że ciągle jesteśmy w punkcie wyjścia. Nadal nie wiemy, jak przenieść istniejące w Wikiźródłach w szablonie {{Dane tekstu}} i indeksie stron informacje do Wikidanych nie przepisując ich i nie klikając kilkadziesiąt razy per strona (najlepiej, gdyby to był pełny automat lub mechanizm jedno- lub dwukliknięciowy). @Powerek38, @PMG: jakieś pomysły, sugestie? Czy zostawiamy zagadnienie przyszłym pokoleniom? O ile ja, Matlin czy Zdzislaw sobie z ręcznym przenoszeniem danych poradzimy, o tyle dla większości bez precyzyjnej instrukcji typu: klinknij tu, sprawdź czy nie ma bzdur i jeśli nie ma to zatwierdź, a jeśli są, poproś kogoś o pomoc będzie to problem, z którym sobie nie poradzą. A i to dotyczyłoby tylko bieżących informacji o nowych tekstach. Armii klonów do przeniesienia informacji o wcześniej wprowadzonych tekstach, często przez skrybów, których u nas już nie ma, nigdzie nie widzę. Ankry (dyskusja) 14:04, 6 lis 2018 (CET)

Nie ma potrzeby przenoszenia tych danych ręcznie, jest do tego narzędzie. Istota problemu jest inna. Jak padło już wyżej, doszło do zupełnego pomieszania dzieł literackich z ich konkretnymi wydaniami, przynajmniej jeśli chodzi o powiązanie elementów WD ze stronami Wikiźródeł. Tu jest największy problem i myślę, że to wymaga roboty w jakimś stopniu ręcznej, co najwyżej wspomaganej narzędziami typu QuickStatements. Musimy doprowadzić do sytuacji, gdy te powiązania będą prawidłowe i moim zdaniem od tego cały proces musi się zacząć. Bo gdybym dzisiaj puścił narzędzie skanujące np. {{Dane tekstu}}, to ono by sobie w dużej mierze poradziło z szablonem tutaj, ale po stronie WD wpisałoby te dane do błędnych elementów. Zamierzam w miarę możliwości zabrać się za to sprzątanie, poprosiłem już Yarla o pewne wsparcie techniczne, żeby szło to nieco szybciej. Jeśli ktoś ma chęć pracować dla Wikiźródeł, ale w obrębie Wikidanych, zachęcam np. do tego, żeby po kolei lecieć po tej liście i sprawdzać prawidłowość powiązania elementu oraz tworzyć elementy konkretnych wydań. Powerek38 (dyskusja) 14:20, 6 lis 2018 (CET)
Akurat to są szczegóły techniczne, z którymi można sobie poradzić.
  1. większość elementów wikidanych przypisanych do Wikiźródeł jest po prostu pusta, zrobiona przez jakiegoś bota.
  2. przypadki, gdy mamy powiązania z innymi Wikisource bym w ogóle na razie zostawił; raczej do obróbki ręcznej.
  3. przypadki gdy mamy powiązania z Wikipedią i/lub np. cytatatmi są albo:
    1. totalnie błędne - jeśli artykuł w Wikipedii nie dotyczy dzieła literackiego – trzeba odlinkować i utworzyć parę nowych elementów Wikidanych
    2. elementy typu "work" - jeśli artykuł w Wikipedii dotyczy dzieła literackiego – też trzeba odlinkować i utworzyć nowy element dla wydania.
... itd. Ale mam wątpliwości, czy projektowanie takiego algorytmu na wiki to dobre podejście.
Kolejna sprawa, to że najlepiej zacząć od tekstów autorów polskich (na stronie autora szablon Autorinfo nie będzie miał parametru "kod" lub będzie on pusty. Szanse, że będą jakiekolwiek powiązania interwiki będą małe.
Ankry (dyskusja) 14:59, 6 lis 2018 (CET)
Wygenerowałem (uwaga, może ładować się nawet 2-3 minuty) listę stron polskich Wikiźródeł, na których jest {{Dane tekstu}}, ale zarazem nie mają one w ogóle wartości P31 (czyli "jest to...") w Wikidanych lub jest to wartość inna niż Q3331189 (czyli wydanie). Mogę to wyciągnąć również w postaci tabelki CSV. Jeżeli mamy mówić o konkretach: trzeba się zastanowić, ale to jest pytanie wybitnie do skrybów, czy faktycznie wszystkie te strony dotyczą wydań. Jeśli tak, można w zautomatyzowany sposób (w oparciu o pliki CSV i narzędzie QuickStatements) dokonać w WD masowych zmian. Jeśli nie, trzeba podzielić to na mniejsze grupy, wg kryterium wartości, jaką ma dla tych elementów przyjąć właściwość P31. Mam nadzieję, że nie piszę zbyt technicznie. Dla mnie to jest etap 1 sprzątania powiązań Wikidane / Wikiźródła. Powerek38 (dyskusja) 15:53, 6 lis 2018 (CET)
  • I tu powraca pytanie, które powinno zostać postawione na wstępie tej dyskusji... Jak definiujemy samodzielne dzieło (wydanie)?? Czy na poziomie indeksu (pozycji książkowej), czy rozdziału??, czy pojedynczego wiersza?..., czy Wybór dramatów/Wstęp. Rys biograficzny powinno mieć rekord w WD? Zdzislaw (dyskusja) 17:40, 6 lis 2018 (CET)
@Powerek38: Dzięki za listę. @Zdzislaw: powinno być postawione i powinniśmy sobie na nie odpowiedzieć, ale uważam, że niekoniecznie dyskusja musi wstrzymywać dalsze działania. Możemy znaleźć niekontrowersyjny podzbiór, na którym przećwiczymy technologię transferu danych. A później tę technologię zastosujemy do innych tekstów. Albo nie zastosujemy: w zależności od wyniku dyskusji.
Sądzę, że na początek powinniśmy odrzucić wszystkie hasła słownikowe, typu "SJP:<coś tam>", artykuły Encyklopedii Muzycznej ("Encyklopedia Muzyczna PWM/*") oraz rozdziały powieści (te można rozpoznać po tym, że w {{Dane tekstu}} nie posiadają wypełnionego pola pochodzenie). Można by też na początek wyeliminować wszystkie podstrony (jeśli tak będzie prościej; ale tu uwaga: nie tylko podstrony, bo wspomniane hasła SJP podstronami nie są). Inna sprawa, że wiele podstron (wiersze Asnyka, fraszki Kochanowskiego jest podstronami przez pewną zaszłość i prędzej czy później powinny one został przeniesione na główny poziom nazewnictwa wg schematu "Fraszka X (Kochanowski, rok)").
Wracając do pytania Zdzislawa: uważam, że w Wikidanych powinno być jak najwięcej informacji o strukturze zawartości naszego projektu. Dlatego, jeśli mamy wiersz X autora Y w wersjach (a) z gazety, (b) z autorskiego tomiku, (c) z antologii to powinniśmy utworzyć dla wszystkich trzech tekstów elementy Q3331189 (wydanie) i powiązać je (1) z utworzonym elementem utworu-wiersza oraz z (2) odpowiednimi elementami Q3331189 (wydanie) dla tomiku poezji i antologii (być może też dla numeru gazety, acz tu niekoniecznie gdyż wiele wydań tego samego numeru gazety jest mało prawdopodobne). Tak przynajmniej rozumiem rolę elementu Q3331189 i liczę, że Powerek38 mnie skoryguje, jeśli rozumiem ją opacznie. Natomiast wracając jeszcze raz do prawdopodobnej przyczyny pytania Zdzislawa: wcale nie uważam, że wszystko co się znajdzie w WD musi trafić do jakiegoś katalogu i z nim do BC. Jest to wg mnie temat na zupełnie odrębną dyskusję.
@Powerek38: czy mógłbyś sporządzić również listę różnych wartości jakie przyjmuje P31 dla tekstów z twojej listy? Myślę, że przyjrzenie się jej pozwoliłoby wyłapać ewentualne "bzdurne" rekordy (jak np. podlinkowany kiedyś przez jakiś automat Bagno (Ostrowska, 1902) (wtedy po prostu jako Bagno) do w:Bagno). Ankry (dyskusja) 19:46, 6 lis 2018 (CET)
@Ankry:: Na moją prośbę Yarl przygotował bardzo ciekawe zestawienie, pokazujące, jakie wartości P31 i w jakiej ilości można spotkać w polskich Wikiźródłach. Ze swojej strony dodatkowo służę listą wszystkich stron Wikiźródeł posiadających właściwość P31 wraz ze wskazaniem jej wartości. Mam nadzieję, że to pomoże. W kwestii technicznej - w obu przypadkach trzeba nacisnąć ikonkę "play" po lewej stronie i poczekać na wyniki. Powerek38 (dyskusja) 20:57, 6 lis 2018 (CET)
@Powerek38: Bardzo przydatne zestawienie, dzięki @Yarl. Pousuwałem powiązania naszych tekstów z różnymi miastami, wioskami, rzekami czy obiektami leżącymi z sferze zainteresowania paleologii. Zostało jeszcze parę wymagających wyjaśnienia, ale o tym gdzie indziej. W chwili obecnej, po dyskusji na IRC-u, sugerowalibyśmy by się zająć stronami:
  • z pominięciem podstron ("/" w nazwie) oraz z pominięciem stron z ":" w nazwie
  • z pominięciem stron posiadających linki do innych projektów Wikisource (obrabianie ich automatyczne uważam za ryzykowne; lepiej zająć się nimi ręcznie)

Chciałem zwrócić też uwagę na jeszcze jedną kwestię. Zgodnie z założeniami wikiprojektu Books: Works should be instances of utwór pisany (Q47461344) or one of its subclasses i Editions should be instances of wydanie (Q3331189) or one of its subclasses. Natomiast w zasadzie strony dotyczące różnego rodzaju aktów prawnych (ustawy, umowy międzynarodowe), jak też sztuk teatralnych wydają mi się nie być przypisanymi do żadnej z podklas wskazanych wyżej klas. Możesz zweryfikować? Jakieś sugestie? Ankry (dyskusja) 01:05, 7 lis 2018 (CET)

    • Widocznie to nie jest objęte tym wikiprojektem. Mówi on tylko o książkach. --Wargo (dyskusja) 20:45, 7 lis 2018 (CET)
      • @Wargo: jest objęte. On mówi o utworach ("works"). Poza tym dokumenty o charakterze prawnym też bywają wydawane w postaci książek (przykład, drugi). Jaką wartość P31 byś sugerował dla abstrakcyjnych elementów Wikidata ("works"), odnoszących się do tych tekstów i ich przekładów na różne języki, a wywodzącego się z Q47461344? Na wikiźródłach czy Commons pod pojęciem "książki" mieści się dowolny (wielostronicowy) dokument piśmienniczy, dla którego można określić dane bibliograficzne. Ankry (dyskusja) 21:59, 7 lis 2018 (CET)

@Wargo, @Ankry: A nie może być np. Q47461344? Opis tego elementu: dowolny utwór w formie pisemnej, taki jak: inskrypcja, rękopis, dokument lub mapa. Czyli np. Konstytucja RP (jako works) jest to utwór pisany? Z zastrzeżeniem, że dobrze rozumiem na czym polega trudność. Jeżeli źle zrozumiałem to zignorować. --Matlin (dyskusja) 22:37, 7 lis 2018 (CET)

  • @Matlin: Q47461344 zawsze można dopisać. Natomiast jeśli byłoby to jedyną wartością, to prędzej czy później ktoś zdecyduje się "uszczegółowić". Po to są bardziej szczegółowe podklasy, żeby tych najbardziej ogólnych nie używać bezpośrednio. Dodanie tego elementu jako P31 jest trochę podobne do dodania do elementu jakiegoś autora informacji oprócz tego, że jest to "człowiek", że jest to także "forma białkowa" lub "organizm wielokomórkowy". Trochę absurdalne. Ankry (dyskusja) 22:52, 7 lis 2018 (CET)
  • @Ankry: To prawda. W reasonator widzę, że w powiązanych elementach m. in. Książka jest podklasą dla 'Utwór pisany' - jeśli dobrze rozumiem fragment of its subclasses. Pozostałe powiązane elementy, np. dzieło literackie, inskrypcja raczej nie pasuje. --Matlin (dyskusja) 19:40, 8 lis 2018 (CET)
  • @Matlin: obawiam się, że to narzędzie nie podaje pełnego drzewa hierarchii podklas. Np. nie mogę z niego wyklikać: utwór pisany (Q47461344) -> dzieło literackie (Q7725634) -> fikcja literacka (Q38072107) -> powieść (Q8261). Niestety nie wiem, jak w przystępny sposób uzyskać i przejrzeć pełne drzewo podklas wybranej klasy. Może @Powerek38: coś doradzi? Ankry (dyskusja) 20:58, 8 lis 2018 (CET)
  • Obawiam się, że to co jest wynikiem tej dyskusji, tzn. usuwanie bezpośrednich powiązań w WD pomiędzy tekstami z innymi wersjami językowymi ws i zamiana na wydanie, a w zamian wstawianie ręcznych iw na naszych źródłach, to wylewanie dziecka z kąpielą i w mojej ocenie szkodliwe działanie dla projektu. Dlaczego? Otóż, w ten sposób tracimy link iw po drugiej stronie, tzn na stronie danego tekstu w enws czy rfws, i pośrednio osłabiamy widoczności naszego tekstu dla wyszukiwarek, a w konsekwencji w wynikach wyszukiwania. Takie zmiany miałyby sens, po przygotowaniu podłoża, gdyby realizowane były także przez inne wersje językowe, wraz ze zmianą mechanizmu wyświetlania linków iw dla ws. I nie da tutaj nic generator w formie nakładki js (tak jak robi to jeden z projektów), ponieważ roboty i tak tego nie widzą. Zdzislaw (dyskusja) 20:22, 9 lis 2018 (CET)
    • @Zdzislaw: Ależ właśnie inne wersje językowe to robią. Wprawdzie ręcznie, ale robią. I "niszczą" w ten sposób istniejące interwiki. Uważam, że w takich sytuacjach należałoby odtworzyć interwiki starego typu. Miałem nawet swego czasu starcie w tej sprawie na Wikidata. Ze względu na to, że nie wierzę, by automat zrobił to dobrze, sugerowałem wyżej (patrz pkt. 2), by przynajmniej na początku pominąć strony z interwiki do innych Wikisource. Być może w n-tym podejściu uda się stworzyć automat, który sobie z tym poradzi, a być może trzeba będzie to zrobić ręcznie. Ankry (dyskusja) 21:29, 9 lis 2018 (CET)
      • @Zdzislaw:, @Ankry:: Przede wszystkim musicie mieć świadomość, że nie zawrócicie kijem Wisły. To nie jest tak, że społeczność polskojęzycznych Wikiźródeł może odmówić współpracy z Wikidanymi i to zatrzyma zmiany. Tym bardziej, że te wszystkie edycje i zmiany dzieją się tam, a nie tutaj. Podczas Waszego spotkania z @PMG: na Źródłosłowie niejako zaprosiliście WMPL (jak rozumiem), by postarało się wesprzeć ten proces, ale nawet bez tego zaproszenia to i tak by się zdarzyło, to była tylko kwestia czasu, bo WD są projektem niezwykle ważnym dla Fundacji Wikimedia, Wikimedia Deutschland (największego na świecie lokalnego partnera WMF) i dla kilku dużych instytucjonalnych sponsorów Fundacji. Wikidane będą w coraz większym stopniu swego rodzaju kręgosłupem Wikimediów i tego się nie zatrzyma, można co najwyżej angażować się na WD lub na Meta w różne dyskusje i współkształtować kierunek, w jakim to idzie. A mówię to dlatego, że dopóki na WD są w tej sprawie zasady takie, jakie są, to próby powrotu do starego systemu mają duże szanse na rewerty. Zresztą moim skromnym zdaniem nawet czysto merytorycznie prawdą jest, że publikowane tutaj teksty są często jakimiś wersjami swoich oryginałów, zwłaszcza w przypadku prac obcojęzycznych. Sami zresztą pewnie wiecie to lepiej niż ja. Posprzątałem dotychczas elementy kilkudziesięciu tekstów i np. zajęło mi dobrych kilka minut ustalenie, które to dzieło Verne'a kryje się pod polską adaptacją figurującą tutaj jako Anioł kopalni węgla. Krótko mówiąc sądzę, że rzetelność i merytoryczna poprawność powinny być w Wikimediach ważniejsze od pozycjonowania. Powerek38 (dyskusja) 18:51, 13 lis 2018 (CET)
        • @Powerek38: Ależ my wcale nie zamierzamy niczego zawracać. Chcemy wykorzystać możliwości, które ten projekt mógłby dać. Ale trzeba wziąć pod uwagę dwie rzeczy: (1) żeby skrybowie zaczęli wrzucać dane z Wikiźródeł do WD muszą naocznie się przekonać, że Wikiźródła na tym jakoś skorzystają (a co tak naprawdę w odniesieniu do tekstów mogło być do WŹ z WD pobierane, a czego jeszcze w WŹ nie ma, poza interwiki? Głos Zdzislawa odbieram właśnie jako taki sceptycyzm odnośnie potencjalnych korzyści dla projektu); oraz (2) większość społeczności WŹ jest słabo zaawansowana technicznie, wielu nawet nie radzi sobie z tworzeniem stron w main czy wypełnianiem szablonu {{Dane tekstu}} (a prawdę mówiąc, nawet ja miałbym problem z określeniem wydawcy na podstawie treści typu: "Nakładem autora; druk W. L. Anczyca i Spółki pod zarządem Iksińskiego; Kraków: Skład główny w Księgarni Gebethnera; Warszawa: Gebethner i Wolff". Dlatego 50% skrybów nic do Wikidanych nie przeniesie, jeśli nie będą mogli tego zrobić (przynajmniej w podstawowym zakresie) jednym kliknięciem. Z drugiej strony, niektórzy pamiętają, że wprowadzenie Wikidanych wiązało się ze stopniową destrukcję interwiki Wikiźródeł: po pierwsze, przed ich wprowadzeniem działały statyczne "stare" interwiki wielokrotne, podobne do widocznych na tej stronie (m.in. 12 en, 3 pl i 4 cs); po drugie, po uruchomieniu WD, wiele botów (ale też użytkowników z innych wiki) zaczęło przerzucać linki interwiki do WD, ignorując zwracane uwagi, że jest to bez sensu; po czym inni użytkownicy "porządkujący" informacje w WD, rozdzielili elementy i interwiki zniknęły całkiem.
Osobiście widzę pewien potencjał, jaki mogą stanowić WikiDane dla Wikiźródeł (jako baza dla interwiki i jako źródło dla katalogu tekstów). Natomiast, aby się dało go wykorzystać, trzeba przekroczyć pewna "masę krytyczną" informacji. Zniechęcająca jest też konieczność klikania na każdym polu: przydałby się mechanizm zautomatyzowania pewnych czynności, np. wyboru podstawowych właściwości, które należy wypełnić dla tekstu czy choćby wypełnienia pól jakimiś podpowiedziami w oparciu o to, co jest już na WŹ. Także tworzenie relacji wzajemnych ("work"<->"edition" czy część<->całość) mogłoby być prostsze i oparte na pojedynczej edycji, a nie na błądzeniu po dwóch elementach. Myślę, że można by też stworzyć pewne katalogi, np. katalog wydawców, które mogłyby ułatwić pewne wybory. Tyle, że nie znając narzędzi, które mogłyby pomóc zautomatyzować pewne procesy, nie wiem jak się za to zabrać i błądzę po omacku rzucając propozycje, o których nie mam pojęcia czy są realizowalne.
Myślę, że należałoby się zastanowić nad zagadnieniami typu: "jak utworzyć od zera możliwie wypełniony element WD dla nowego tekstu wykonując nie więcej niż, dajmy na to, 10 operacji (typu klikniecie myszą, naciśnięcie klawisza, czy zaznaczenie tekstu)". Bardziej skomplikowane algorytmy możemy tworzyć dla botów i ich operatorów, ale nie dla przeciętnego skryby. Krótko mówiąc: link w menu bocznym WŹ pt. "utwórz nowy element WD" kierujący do formularza z wybranymi, predefiniowanymi polami, wypełnionymi w oparciu o dostępne dane z (a) Danych tekstu (b) strony indeksu, na której dany tekst bazuje, ew. jakież listy wyboru umożliwiające poprawienie tych danych w oparciu o informacje zawarte w WD lub predefiniowane listy oraz przycisk "Zatwierdź". Tyle, że ja nie wiem, jak się technicznie za coś takiego zabrać :( Ankry (dyskusja) 00:16, 14 lis 2018 (CET)

Jak to kiedyś napisała Magda Gessler: moni (sic!) mili, tu trochę trzeba na chwilę odejść od głównego wątku: myślę, że jeżeli wszystkie strony pomocy zostaną uaktualnione, jeżeli wszystkie niepisane zasady i zasady tworzone ad-hoc nie zostaną przedyskutowane, ustalone i zapisane, to tych wikiskrybów, dysponujących umiejętnościami technicznymi nie przybędzie, bo osoba, która nawet chce się czegoś nauczyć: z czego ma czerpać wiedzę?

  1. Musi naśladować działania tych doświadczonych wikiskrybów (na przykład zobaczyć, jak inna osoba zastosowała szablon) - ma to tę wadę, że mechanizm wiki jest do bólu elastyczny i nie zawsze da się zastosować daną metodę bez żadnych ubytków.
  2. Musi przekopywać się przez dyskusje i inne strony: czytaj to w ten sposób: musi być obyty ze skryptorium, musi przeglądać strony książek i patrzeć, jak tam dane zagadnienie zrealizowano.
  3. Musi w końcu czasem zrobić coś na oślep, bo nie do końca rozumie dany mechanizm (jakie powoduje skutki, dlaczego trzeba zastosować to albo tamto): ale wtedy jest ryzyko, że dostanie l*nie po d*pie, a ono bardzo boli od niektórych osób.
  4. Oczywiście część zagadnień jest spisana w pomocy, czasem dostatecznie (i po prostu popełniane są błędy z lenistwa czy pójścia na łatwiznę), a czasem zbyt ogólnie lub bez odniesienia do obecnych mechanizmów.

Dlatego uważam tak, jak w pierwszych zdaniach (prakseologicznych) tej wypowiedzi, dodając, że spisanie jasnych zasad postępowania (nie unikając czasem kazuistyki) spowodowałoby, że mniej osób obawiałoby się działań tzw. technicznych :-) --Matlin (dyskusja) 10:21, 14 lis 2018 (CET)

Właściwość WD dla Polony[edytuj]

Drodzy Skrybowie, po tej ogólnej dyskusji przystępuję powoli (powoli, bo niestety mam do połowy grudnia wyjątkowo dużo obowiązków zawodowych, o czym uczciwie uprzedziłem Zarząd WMPL, podejmując się współpracy z Wami) do konkretnych działań. Jako pierwsze z nich chciałbym zrealizować złożenie wniosku do społeczności Wikidanych o utworzenie nowej właściwości, o której dyskutowaliśmy wyżej - identyfikatora autora w bazie Polony. Bardzo byście mi ułatwili zadanie, gdybyście mogli podać mi następujące informacje:

  • wzór linku do bazy dla przykładowego rekordu, z zaznaczeniem części stałej i zmiennego identyfikatora w linku (już o tym gadaliśmy powyżej, ale proszę o dokładne sprawdzenie, czy to działa);
  • przypuszczalną liczbę encyklopedycznych rekordów w tej bazie;
  • wyrażenie regularne (np. ^[1-9]\d{0,2}$) opisujące zakres, w jakim będą się mieściły zmienne identyfikatory.

Z góry dziękuję. Powerek38 (dyskusja) 13:33, 8 lis 2018 (CET)

Tutaj może być problem (a może się mylę), linki do polony wyglądałyby następująco https://polona.pl/items/?filters=creator:%22Sienkiewicz,_Henryk_(1846--1916)%22, lecz z identyfikatorem może być problem, może on przyjmować postać "Imię,_Nazwisko_(rok*--rok†)", jak również, wiele innych odmian, np. w przypadku, gdy rok śmierci lub urodzenia jest nieznany "Imię,_Nazwisko_(rok*--_)",... aż do przypadków gdy żadna z dat jest nieznana, np. "Imię1,_Imię2_Nazwisko" (https://polona.pl/items/?filters=creator:%22Wr%C3%B3blewski,_Jan_Tadeusz%22)... zmienna liczba członów, raz z przecinkiem, raz bez. Nie ma także gwarancji, że dany identyfikator nie zmieni się z czasem, np. gdy zostanie ujawniona data śmierci. Tak więc regexp dla zmiennej części identyfikatora, to /^.+$/ :))), Zdzislaw (dyskusja) 20:16, 8 lis 2018 (CET)
Dodam, że w nawiasie może być co innego niż daty, np https://polona.pl/items/?filters=creator:%22Go%C5%82%C4%99biowski,_S%C5%82awomir_(teologia)%22. Chyba jedyne co jest w miarę pewne, to że identyfikator zaczyna się od wielkiej litery alfabetu łacińskiego (ale może być ze znakami diakrytycznymi).

Ręczne sprzątanie powiązań[edytuj]

@PMG: poprosił mnie parę dni temu o wrzucenie gdzieś instrukcji czy też opisu, co właściwie robię, gdy ręcznie sprzątam powiązania Wikiźródeł i Wikidanych (a w wolnych chwilach ostatnio trochę się tym zajmuję). Gdyby ktoś jeszcze chciał się z tym zapoznać, zostawiam tutaj. Oczywiście prace te można by też wykonywać półautomatycznie, ale póki nie powstaną stosowne narzędzia, można bawić się też tak. Powerek38 (dyskusja) 17:38, 12 lis 2018 (CET)

>>Duplikuj<<, przełomowa funkcja na Źródłach[edytuj]

Dobry, na stronach naszych indeksów zaimplementowałem zapowiadaną podczas Źródłosłowu nową opcję pozwalającą (jednym kliknięciem) na rozpoczęcie tworzenia nowej strony automatycznie wypełnionej treścią ze źródłowej. Nie udało się jej zaimplementować (choć powstawała w kuluarach) podczas samego zlotu, z prozaicznego powodu - poprzednie punkty programu i żarliwa dyskusja wypełniła cały dostępny czas naszych sesji. Lecz, co się odwlecze... i jest :) Na razie można z niej korzystać podczas tworzenia nowych indeksów w przestrzeni Indeks:, na podstawie danych pobieranych z już istniejących. Proszę tutaj o uwagi i opinie. Pozdrawiam, Zdzislaw (dyskusja) 21:40, 28 paź 2018 (CET)

Wyłączyłem w CSS widoczność tej funkcji dla nie-redaktorów. Niezalogowanych czytelników raczej rozprasza, niż stanowi dla nich pożyteczny element, a początkującym tez raczej się nie przyda. Ankry (dyskusja) 18:18, 27 gru 2018 (CET)

Generator linków[edytuj]

Zmodyfikowałem troszkę gadżet Generator linków, rozszerzając nieco jego możliwości (generowanie nazw stron bez zer w numerach, czy uwzględnienie przesunięcia fizycznej numeracji w książce względem numeracji stron w pliku. Gadżet rzadko używany, niemniej proszę o ewentualne uwagi. Ankry (dyskusja) 10:19, 30 paź 2018 (CET)

rezerwacja[edytuj]

@Zdzislaw, @Wieralee, @Rosewood, @Anwar2:@PMG, @Masti: Podobno na Źródłosłowie była omawiana kwestia wprowadzenia/implementacji rezerwacji indeksów. Czy ktoś mógłby podsumować tamtejszą dyskusję? (sugerujemy wprowadzenie w taki sposób..., nie implementujemy bo..., pojawiły się następujące opinie i wątpliwości..., itp...) Ankry (dyskusja) 19:18, 30 paź 2018 (CET)

Mnie przy tym nie było, widocznie byłem w innej sali. PMG (dyskusja) 19:29, 30 paź 2018 (CET)
Omawiana, to za dużo powiedziane, poruszyliśmy jedynie tę kwestię już poza samą sesją, jedynie w kontekściem możliwych problemów z osobami, które nagminnie odrezerwowałyby indeksy w toku, jako iż opcja rezerwacji stanowić ma jedynie funkcję informacyjną, nie restrykcyjną, i jako taka, może być przez każdego dowolnie wyłączana. Pytanie to oczywiście jest ciągle otwarte, jednakże ja wyraziłem pogląd, że w takich razach (częstych odrezerwowaniach) powinien z wyczuciem reagować administrator. W przeciwnym wypadku wymagane byłoby stworzenie swoistego zbioru zasad. Zdzislaw (dyskusja) 20:32, 30 paź 2018 (CET)
Odrezerwowywanie to wg mnie małe piwo: można ustalić, że jeśli indeks jest zarezerwowany nie dawniej niż N dni temu, to obowiązkiem odrezerwującego jest zapytanie się rezerwującego o zgodę na odrezerwowanie i poczekanie określony czas na odpowiedź. Niedotrzymanie tych zasad, dawałoby zatrudnienie administratorom.
Natomiast większym problemem może być zarezerwowanie sobie indeksu, który ktoś niedawno edytował, ale go nie zarezerwował. Bo tego, że edytował, nie da się łatwo sprawdzić. Ankry (dyskusja) 20:45, 30 paź 2018 (CET)
@Zdzislaw, @Ankry: a nie dałoby się zrobić na stronie indeksu jakiegoś małego podglądu który by pokazywał kto i kiedy robił ostatnią edycję na stronach indeksu? Np. "Wikiskryba... edytował stronę nr... data..." Joanna Le (dyskusja) 12:36, 31 paź 2018 (CET)
Technicznie by się dało. Ale skrypt, który by to robił musiałby pobrać i przeanalizować strony historii wszystkich stron w indeksie (statystycznie kilkuset). Czaso- i zasobochłonne. Jeśli używasz gadżetu Oznaczaj skorygowane przeze mnie strony, to mniej-więcej tak by to działało. Ankry (dyskusja) 14:02, 31 paź 2018 (CET)
A jakby była możliwość uruchamiania takiego skryptu tylko kiedy się potrzebuje sprawdzić ostatnią edycję, jakimś przyciskiem, a nie jak gadzet Oznaczaj skorygowane przeze mnie strony, który się uruchamia przy każdym wejściu na stronę indeksu? Czyli wchodzę na stronę indeksu który chcę zarezerwować klikam "sprawdź" i wyświetla mi się kto edytował ostatnio. Wtedy byłoby to czaso- i zasobochłonne, ale tylko kiedy byłoby konieczne. Joanna Le (dyskusja) 14:22, 31 paź 2018 (CET)
@Joanna Le:Obawiam się, że w przypadku dużych i uczęszczanych indeksów ilość danych byłaby istotnie pokaźna, nawet dla bota. Czy nie wystarczyłoby na górze strony indeksu małe (może potrójne?) okienko, gdzie użytkownik ręcznie by się podpisywał. A wchodzący na stronę widziałby informacje: ten indeks przepisuje/przepisują np. Ankry, korygują/korygują np. Anagram16 i uwierzytelnia/uwierzytelniają np. Zdzislaw. Po kilku dniach weszło nam w nawyk oglądanie tej informacji i rzadziej by się zdarzało, że ja wejdę komuś w paradę, a ktoś mnie. Gdyby ktoś się wpisał, ale by nie edytował przez miesiąc i się nie wypisał, wtedy każdy mógłby usunąć jego podpis i ewentualnie wstawić swój. (Anagram16 (dyskusja) 15:33, 31 paź 2018 (CET))
@Anagram16: Umieszczenie informacji o rezerwacji w indeksie to żaden problem. Tu chodziło o sposób przekazania tej informacji edytującemu stronę. Nie jestem pewien, czy wszyscy edytujący strony wchodzą na nie z indeksu. PMG raczej nie. Ankry (dyskusja) 17:30, 31 paź 2018 (CET)
@Anagram16: o takiej rezerwacji myślałes? Ankry (dyskusja) 18:56, 31 paź 2018 (CET)
Mniej więcej. A PMG, o ile pamiętam, nie zostawia po sobie błędów, chociaż pracuje jak japoński pociąg. (Anagram16 (dyskusja) 20:12, 31 paź 2018 (CET))
Rezerwacja nie ma nic do błędów lub ich braku. Chodzi o konflikty edycji. Na japoński pociąg też się można naciąć, choć trudniej. Ankry (dyskusja) 21:31, 31 paź 2018 (CET)
Wycofałem zmianę w strukturze indeksu, bo jak rozumiem nie ma zainteresowania tematem. Ankry (dyskusja) 22:35, 7 lis 2018 (CET)

Pytania do inicjatorów tego pomysłu:

  1. Czy celem wprowadzenia tej funkcji ma być a) ograniczenie konfliktów edycji, czy b) przekazywanie ogólnej informacji o tym, że ja już pracuję nad danym indeksem i znajdź se inny (bo np. robię strony offline, a potem je wszystkie jednocześnie wprowadzam)?
  2. Jak często spotkaliście się w swojej pracy edytorskiej z konfliktem edycji? Osobiście - choć edytuję o wiele mniej i mam wielomiesięczne przerwy w edytowaniu - tylko raz, jak łapczywie rzuciłem się w 2015 roku na Maksymy i rozważania moralne.--Matlin (dyskusja) 11:35, 4 lis 2018 (CET)
Oba względy (a i b) są uzasadnione. Konflikty edycji się zdarzają, a niektórzy z nas opracowują całe indeksy poza przestrzenią główną a nawet tutejszym brudnopisem i potem wklejają kilkadziesiąt stron z szybkością jednej na minutę. (87.207.9.162 (dyskusja) 13:03, 4 lis 2018 (CET))
@Matlin: Chyba kilkanaście razy. Ale ostatnio były to w zasadzie konflikty tylko z jednym skrybą. Każdy taki konflikt działa na mnie na tyle zniechęcająco, że odechciewa mi się edytowania w danym projekcie (trochę tak, jakby w trakcie czytania książki ktoś mi ją zabrał i wyrwał z niej nieprzeczytaną jeszcze kartkę). Dlatego jestem skłonny podjąć pewne działania wyprzedzające, które pozwolą mi upewnić się, że na kilkuset stronach, które zamierzam edytować z nikim się konfliktował nie będę. A jeśli się nie da, wolę sobie pójść na inną wiki, gdzie tego problemu nie ma lub zająć się czymś innym. Po prostu. Przez lata wypracowaliśmy sobie niepisaną zasadę, że nie wchodzimy sobie w drogę, jeśli edytujemy w tym samym indeksie, w którym edytuje ktoś inny, to albo zachowujemy pewien dystans, postępując za użytkownikiem, albo jeśli robimy to przed, to po to, żeby ten indeks szybciej ukończyć. A nie po to, żeby "obrobić" jedną stronę i po konflikcie się wycofać rakiem.
Konflikty edycji zdarzają się też w dyskusjach, ale te tak nie drażnią.
Co do celu: chodziło chyba przede wszystkim o a), ale to b) nie wyklucza. Masz jakieś inne propozycje w tej materii? Ankry (dyskusja) 23:09, 5 lis 2018 (CET)
  • Nie miałem pomysłu i motywacji ostatnimi czasy, lecz okazało się, że Sitenotice/Editnotice parsuje szablony po transkluzji, więc i urodził się pomysł implementacji, z minimalnym użyciem js. Tak czy siak, po niespełna roku Rezerwacja doczekała się implementacji i od dzisiaj testowo działa na naszych ws. Obsługa zgodnie z opisem w Pomocy. Funkcja ta działa z większością nowych indeksów wykorzystujących funkcję pages rozszerzenia Proofread (tymi, których nazwy/adresy stron są takie same jak nazwa indeksu). Chętnych proszę o testy i uwagi. Zdzislaw (dyskusja) 22:19, 31 paź 2019 (CET)
  • Czy będzie możliwość w zakładce rezerwacja zrobić tak, żeby do rezerwacji były przypisane 2 konta (np. gdy robię to zespołowo z kolegą z harcerstwa)? Superjurek (Dyskusja) 20:51, 25 cze 2020 (CEST)
  • @Superjurek: na pierwszy rzut oka wydaje się, że byłoby to możliwe. Muszę jednak znaleźć dłuższą chwilę aby toto dokładnie przetestować. Dam znać. Zdzislaw (dyskusja) 23:41, 25 cze 2020 (CEST)
  • Mam pytanie w temacie tej funkcji. Jak ona się ma do tego, że każdy może edytować? Jak blokada edycji ma się do tego, że jest to projekt wiki? Rozumiem zamysł choć ciężko mi uwierzyć w nagminne konflikty edycji zwłaszcza na nielicznym gronie edytujących. Zauważyliście, że redaktorzy dawno wypracowali metodę nie wchodzenia sobie w drogę. Teraz czytam obowiązkiem odrezerwującego jest zapytanie się rezerwującego o zgodę na odrezerwowanie i poczekanie określony czas na odpowiedź. Niedotrzymanie tych zasad, dawałoby zatrudnienie administratorom.. Obowiązek pytania o możliwość edycji???? Reakcja administratorów???? Jeśli jakiś user wejdzie w listę stron do weryfikacji i zacznie weryfikować losowo, po pierwsze spotka się z blokadą edycji, po drugie gdy ją ominie, może doczekać się reakcji adminów? Jakoś tak mi to wychodzi z tej dyskusji i jakoś mocno kłóci się z ideą wiki. Tommy J. (pisz) 00:45, 26 cze 2020 (CEST)
  • @Tommy Jantarek: Cytujesz wycinki propozycji z dyskusji, które nie zostały przyjęte jako jakakolwiek zasada. Implementacja funkcji została wykonana w taki sposób, że odrezerwowanie nie wymaga ani żadnych uprawnień, ani pytania kogokolwiek o zgodę. Całość znajdziesz w Pomoc:Proofread/Rezerwacja. Zdzislaw (dyskusja) 00:57, 26 cze 2020 (CEST)
  • @Zdzislaw: wiem co cytuję. Skoro się to pojawia w dyskusji, to jest brane pod uwagę. Na projekcie wiki. Wydaje mi się że to ogromnie zgrzyta. Wg mnie, nawet gdy w przepisywany przez jednego usera projekt wejdzie inny user pozostający z pierwszym w jawnym i nieskrywanym antagoniźmie, to ma prawo edytować co chce, kiedy chce i nikt nie może mu tego utrudniać czy blokować, jeśli edytuje bez wandalizmów. Wg mnie również, taka rezerwacja może (przynajmniej na projekcie wiki gdzie każdy może edytować) jedynie rolę informacyjną. Wg mnie nawet automatyczne zblokowanie edycji już jest nadużyciem. Sam nie lubię konfliktów edycji czy gdy w ulubionym projekcie pojawia się Obcy, ale to jednak wiki.... Tommy J. (pisz) 01:09, 26 cze 2020 (CEST)
  • Jeszcze jedno pytanie. Rozumiem że rezerwacja uniemożliwia pracę innych skrybów. Czyli gdy jeden przepisuje, drugi nie może korygować a trzeci weryfikować? Najpierw indeks musi zostać odrezerwowany? Tommy J. (pisz) 02:13, 26 cze 2020 (CEST)
  • Dokładnie. Rezerwacja jest informacją dla kogoś kto chciałby edytować strony indeksu, że w tym samym indeksie grzebie lub grzebał ktoś inny i że ta osoba prosi by jej w tym nie przeszkadzać. To, czy ta druga osoba zastosuje się do prośby, czy nie jest w kwestii dobrych obyczajów raczej niż zasad. Jednak taka semi-blokada pozwala uniknąć przypadkowych konfliktów edycji. Jeśli ktoś chciałby edytować strony indeksu pomimo rezerwacji, to byłoby wskazane przynajmniej poinformować o tym użytkownika, który rezerwację utworzył (chociaż ten i tak powinien się w tej materii zorientować przy pierwszej swojej edycji strony tego indeksu). Chyba, że jest to stara, zapomniana rezerwacja. Zdarzają się czasem użytkownicy edytujący przypadkowe strony w przypadkowych indeksach, i to do nich głównie jest skierowana taka informacja. Dodam, ze niektórzy użytkownicy praktykują pracę offline (kiedy pomiędzy pobraniem wersji strony a zapisaniem nowej może upłynąć nawet kilka dni) i w takich sytuacjach konflikty edycji mogą być dokuczliwe. Ankry (dyskusja) 06:56, 26 cze 2020 (CEST)
  • @Tommy Jantarek: nie nazwałbym tego nieuniemożliwianiem pracy - rezerwacja jedynie wymusza jednorazowe dodatkowe trzy (cztery kliknięcia) w celu odrezerwowania, po ich wykonaniu (do czego nie trzeba mieć żadnych dodatkowych uprawnień) rezerwacja całego indeksu znika. Nie trzeba odrezerwowywać przy każdej stronie. Zdzislaw (dyskusja) 16:30, 26 cze 2020 (CEST)
  • @Zdzislaw: w pewnych przypadkach (w tej chwili mam dwa) może być. Jeśli user będzie korygować z poziomu kategorii bo przyjdzie mu do głowy że akurat dziś nie ma co robić, nie ma na celu i ochoty na żaden konkretny projekt i postanowi sobie zmniejszyć cyfrę nieskorygowanych. Drugi przypadek to uczenie się. Rzucane nowego skryby na konkretny projekt niewiele go nauczy. Taki user może skakać po projektach i korygować losowo strony podglądając różne rozwiązania i składnie. Sam tak się uczyłem. Wreszcie też chodzi mi o samą ideę. Ja rozumiem niechęć, gdy ktoś Ci wchodzi z ciężkimi butami w projekt. Sam tego nie lubię. To zrozumiałe. Ale jednak to wiki, zaden projekt nie jest niczyją własnością. I choćbym nawet z pełnym poświęceniem na nim pracował, "prawnie" nie mogę komukolwiek zabronić czy utrudnić pracy na tym projekcie, choćby ten ktoś postanowił sobie korygować np. co jedenastą stronę. Wg mnie rezerwacja może pełnić jedynie rolę informacyjną, pozostawiając edytorowi wolną wolę i wybór, zechce zrezygnować z edycji czy nie. Wg mnie zniknięcie przycisku edycji i spowodowanie kolejnych kliknięć by to umożliwić już jest nadużyciem na projekcie wiki. Taka jest moja opinia acz zaznaczam, całkowicie rozumiem z czego wynika pomysł rezerwacji w tej postaci. Tommy J. (pisz) 18:06, 26 cze 2020 (CEST)
  • @Tommy Jantarek: Osobiście z rezerwacji nigdy nie korzystałem. Wykonałem ją testowo ze względu na zapotrzebowanie społeczności. Nikt od 10.2019 nie zgłaszał żadnych zastrzeżeń, nikt nie sygnalizował, że ogranicza to jego prawa. W takim razie wyjścia są dwa - całkowity rewert lub pozostawienie jedynie komunikatów. @Ankry, @Anagram16, @Matlin, @Joanna Le: jakieś opinie? Zdzislaw (dyskusja) 18:29, 26 cze 2020 (CEST)
  • Rezerwacja jest stosowana, według mojej obserwacji Ostatnich zmian, bardzo rzadko. Wynika to oczywiście z tego, że stosunkowo trudno o konflikt edycji, a jeśli pojawiały się jakieś widoczne w dyskusjach problemy, to nie w tym, że dwóch użytkowników chciało przepisywać ten sam indeks, tylko rezerwacja była założona przez nowego, niedoświadczonego użytkownika, którego edycje chciał sprawdzić drugi wikiskryba, aby udzielić mu pomocy i wskazówek. Nie oznacza to, że jest to rozwiązanie nieużyteczne, tylko lepiej sprawdziłoby się przy większej liczbie wikiskrybów. Poza tym przekonałem się, że to nie jest tak daleko idąca ingerencja w swobodę edycji, bowiem zawsze można rezerwację usunąć, chociażby na chwilę. Jedyną zalecaną przeze mnie modyfikacją jest to, aby rezerwację mogli zapisywać tylko wikiskrybowie o randze redaktora, tak aby nowicjusze mieli możliwość otrzymania szybkiej pomocy. Może i pozostawienie tylko samego komunikatu, bez znikania zawartości strony? Nie jestem chyba sam w tym, że czasami przeglądam ostatnie zmiany i oglądam cudze edycje, bez żadnego klucza wyboru. W ten sposób mogę przy okazji wyłapać np. jakieś literówki, które są widoczne gołym okiem po wejściu w taką edycję. --Matlin (dyskusja) 18:50, 26 cze 2020 (CEST)
  • Moim zdaniem najzupełniej "legalna" jest rezerwacja w formie komunikatu nawet obszerniejszego, jednak z możliwością edycji. Jeśli obstajecie przy zniknięciu edycji, to może łatwiejszy i szybszy sposób na odblokowanie/jednoedycyjne odblokowanie edycji, niż klikanie po dyskusjach indeksów i kasowanie a potem przywracanie rezerwacji. I prośba, zapomnijcie o jakichkolwiek "reakcjach admińskich". Nawet jeśli user nagminnie czy złośliwie będzie kasował rezerwacje, a jego edycje będą poprawne, to niestety ma do tego prawo a reakcja na to byłaby już przekroczeniem granicy. Tommy J. (pisz) 19:31, 26 cze 2020 (CEST)
  • Zgadzam się, że z rezerwowaniem indeksów przez nie-redaktorów jest tylko kłopot. Ale pewnie wystarczy ukryć przed nimi informację o tym, jak rezerwować. Możliwe, że warto informację o tym jak rezerwować, schować głębiej w dokumentacji (może pokazywać nowym userom informację o tym mechanizmie dopiero przy konflikcie edycji? - nie wiem czy się tak da). Przyznam, że mi w przypadkach konfliktów edycji najbardziej brakowało ostrzeżenia przed próbą zapisu, że taki konflikt może wystąpić. Ewentualne zniknięcie informacji o rezerwacji lub (szczyt marzeń) informacja o jej zdjęciu na stronie dyskusji byłyby dla mnie zadowalające. Ja często edytuję strony offline, seriami (zwykle do 50 kolejnych stron) i nerwowe oczekiwanie, czy nie będę miał co kilkanaście stron konfliktu edycji przy seryjnym, półautomatycznym zapisie, jest nieco zniechęcające. Inna rzecz, ze od chwili utworzenia tego mechanizmu, nie miałem potrzeby z niego korzystać, bo "skaczący" po indeksach użytkownicy jakby zniknęli ostatnio z projektu. Nie mam nic przeciwko "jednoguzikowemu" likwidowaniu rezerwacji. Mógłby to być gadżet, który wyczyści stronę rezerwacji (a może jeszcze zostawi na stronie dyskusji rezerwującego wiadomość: "Słuchaj koleżanko/kolego, usunąłem/usunęłam twoją rezerwację z indeksu XXXX bo mi przeszkadzała w edycji <4 tyldy>". W moim rozumieniu, celem mechanizmu rezerwacji jest zniechęcanie innych użytkowników (nie: uniemożliwianie) do edytowania danego indeksu. Ankry (dyskusja) 20:20, 26 cze 2020 (CEST)
  • Niestety, ze względu na specyfikę rozszerzenia proofread, nie powiodła się implementacja opcji jednoguzikowego likwidowania rezerwacji. Nie twierdzę, że tego się nie da wykonać, lecz ja nie widzę prostego mechanizmu. Zostawiłem na chwile obecną cały dotychczasowy mechanizm, lecz okrojony jedynie do komunikatów. Pytanie: Zostawić mechanizm z komunikatami, czy robimy całkowity rewert? Zdzislaw (dyskusja) 23:52, 30 cze 2020 (CEST)
  • Wyłączyłem w indeksie widoczność tego mechanizmu dla nieredaktorów. Wydaje mi się, że jest konsensus co do tego, że używanie go przez nieredaktorów (których edycje wymagają przeglądania) jest niezalecane. Ankry (dyskusja) 23:26, 27 cze 2020 (CEST)

wikEd[edytuj]

Okazuje się, ze nie tylko ja mam problemy z gadżetem wikEd. Gryzie się on z wieloma mechanizmami wiki (w przestrzeni Strona potrafi likwidować okno edycji i inne elementy strony, przy edycji js z kolei okno edycji powiela, nieszczególnie współpracuje z tzw. "rozszerzonym" paskiem edycji itp.). Sugerowałbym usunięcie go z listy dostępnych gadżetów. Ale ponieważ kilkudziesięciu użytkowników ma go włączony (w tym 2 aktywnych), sugeruję by się odezwali tutaj, jeśli się z tym nie zgadzają, a spróbujemy wypracować jakiś kompromis.

Zwracam uwagę, że nawet jeśli gadżet zostanie usunięty z listy gadżetów, można go będzie ładować z common.js użytkownika. Ankry (dyskusja) 20:56, 3 lis 2018 (CET)

  • Dodać notę, że gadżet działa niestabilnie i nie jest zalecane jego włączanie. --Matlin (dyskusja) 11:24, 4 lis 2018 (CET)
    • I wywalić go na koniec do osobnej sekcji "niewspierane gadżety"? Tu, gdzie jest, po prostu "utrudnia" dostęp do pozostałych gadżetów, a zwiększenie ilości tekstu w opisie tego użytkownikom nie ułatwi (będą musieli poświęcić więcej czasu na przeczytanie i zrozumienie, zanim dotrą do tego, czego szukają). IMO, jeśli go potrzebujesz, to po prostu skopiuj zawartość MediaWiki:Gadget-wikEd.js do swojego common.js. Ankry (dyskusja) 16:20, 5 lis 2018 (CET)
      • Ale ja tego dziadostwa nie używam :-) Chciałem raczej, żeby korzystający użytkownicy nie byli zaskoczeni, chociaż jest ich tak mało, że milczenie należy przyjąć za zgodę. Solidny wikiskryba powinien czytać skryptorium. --Matlin (dyskusja) 11:52, 6 lis 2018 (CET)

Gtk-ok.svg Załatwione usunąłem go z gadżetów wobec braku zadeklarowanych użytkowników. Ankry (dyskusja) 21:06, 25 cze 2020 (CEST)

Indeks[edytuj]

Może część z was zauważyła, że od pewnego czasu rozwijam szablon {{Index}} służący do wyświetlania informacji w Indeksie, głównie poprzez dodawanie do niego nowych pól. Jeżeli macie w tej materii jakieś uwagi (np. uważacie, że jakiś pola są potrzebne lub zbędne, albo że coś można by rozwiązać inaczej, proszę o sygnał, najlepiej w tym wątku).

Jakiś czas temu zauważyłem, że dość powszechnie przyjętym standardem rozgraniczania wartości wielokrotnych (wielu autorów, tłumaczy, wydawców, miejsc wydania) jest używanie w tym celu średników. I proponuję, by ten de facto standard stosować, przynajmniej w indeksie. Powinno to ułatwić w przyszłości ewentualny transfer informacji do wikidanych (o którym mowa w jednym z wątków wyżej; chociaż na razie widzę tam więcej czarnych chmur niż jaskółek).

Ankry (dyskusja) 08:34, 6 lis 2018 (CET)

Błędy składni[edytuj]

Hej

Czy macie świadomość istnienia takiej strony i czy ktoś pracuje nad poprawkami pokazywanych tam błędów? PMG (dyskusja) 13:35, 14 lis 2018 (CET)

Hej @PMG:, świadomość mamy, chociaż dobrze jak czasami ktoś przypomni. Ale do zrobienia jest tyle różnych rzeczy, że nie wiadomo czasem za co się brać. A większość z nas najchętniej (bo w sumie po to tu jesteśmy) czyta książki, przepisując bądź korygując jednocześnie. Joanna Le (dyskusja) 18:43, 14 lis 2018 (CET)
@PMG: jak wynika ze statystyk postępu za jakieś 14 lat powinniśmy wyjść na prostą. Chyba, że znowu coś pozmieniają w HTML-u do tego czasu ;P Ankry (dyskusja) 22:51, 14 lis 2018 (CET)
W3C działa wolno - ale myślę że HTML6 powstanie szybciej niż za 14 lat. Pewnie augmented reality będzie już powszechne jak ostatnie znaczniki big będą usuwane z Wikiźródeł :) PMG (dyskusja) 23:27, 14 lis 2018 (CET)

Interwiki[edytuj]

Zaimportowałem od Szwedów ich skrypty do tworzenia interwiki na podstawie informacji z Wikidata. Strony wykorzystujące ten mechanizm można znaleźć w tej kategorii (nowe będą się sukcesywnie pojawiać po odświeżeniu). Proszę o sygnały o nieprawidłowym działaniu i ew. inne uwagi. Ankry (dyskusja) 01:30, 21 lis 2018 (CET)

  • Super. Teraz wystarczy tylko utworzyć odpowiedni element wikidanych i teksty same linkują do siebie. Dzięki Nawider (dyskusja) 21:38, 24 lis 2018 (CET)
  • @Ankry: Hej, jeżeli P629 zostanie wprowadzone z wartością nieznana wartość, (patrz [1]), skrypt generuje błędy na naszych stronach. Nie znam się na data, lecz wydaje mi się, że to raczej błędnie wprowadzone P629, lecz sam moduł chyba także należałoby uodpornić na takie rzeczy? Zdzislaw (dyskusja) 17:29, 30 lis 2018 (CET)
  • Ano. Dzięki za sygnał. Choć chyba lepiej by było jakoś takie sytuacje wykrywać, bo w tym przypadku w Wikidata są ewidentnie bzdurne informacje. Ankry (dyskusja) 20:45, 30 lis 2018 (CET)

Status proofread a anonimowi użytkownicy[edytuj]

Jakiś czas temu zauważyłem, że na niemieckich Wikiźródłach anonimowi użytkownicy mają możliwość zmiany statusu korekty. Następnie nastąpiła ta dyskusja, w wyniku której doszedłem do wniosku, że może to niegłupi pomysł, by dać niezalogowanym przynajmniej ograniczone możliwości w tej materii.

A w szczegółach pomysł wygląda tak:

  • wnioskujemy w phabricatorze, by nadać anonimowym użytkownikom prawo zmieniania statusu strony
  • usuwamy "żółty" guziczek w przypadku nowych stron (OK, to właśnie zrobiłem; a dla "hackerów" mamy jeszcze blokadę na abusefiltrze)
  • usuwamy dla anonimowych wszystkie guziczki statusu, jeśli edytują istniejącą stronę
  • blokujemy na abusefiltrze możliwość zmiany przez nich statusu w przypadku już istniejących stron

Raz ustawionego statusu nie będą mogli zmienić; ale będą mogli ustawić status strony na dzień dobry i zobaczą, że jest coś takiego jak ustawianie statusu przez użytkownika.

@Joanna Le, @Nawider, @Salicyna, @Bonvol, @Wieralee:@Alenutka, @Matlin, @Wrzodek, @JKW, @Zdzislaw:@Wolan, @Anwar2, @Anagram16, @Kejt, @Draco flavus:@Sempai5, @Zetzecik, @Kanioska: Co o tym pomyśle myślicie? Ankry (dyskusja) 23:23, 13 gru 2018 (CET)

Krótko mówiąc, obecnie jest tak, że niezalogowany użytkownik, tworząc nową stronę, może ją pozostawić jedynie w domyślnej pozycji czerwonej, nawet jeżeli strona powinna być szara (bez treści) lub niebieska (problemy). Zmiany proponowane przez Ankrego spowodują, że niezalogowany może utworzyć nową stronę także nadając jej status szary lub niebieski. Osobiście jestem Symbol support vote.svg Za Salicyna (dyskusja) 23:29, 13 gru 2018 (CET)
Zmiana na szary lub niebieski jak najbardziej, ale na żółty lub zielony, jak rozumiem, nie. (Anagram16 (dyskusja) 01:02, 14 gru 2018 (CET))
Moim zdaniem to dobry pomysł. Oznaczanie na czerwono, niebiesko i szaro powinno być dostępne dla każdego, jestem Symbol support vote.svg Za Joanna Le (dyskusja) 11:13, 14 gru 2018 (CET)
A czy niezalogowani dostają przy oknie edycji jakieś info, że pełna funkcjonalność będzie dostępna po zalogowaniu? --Matlin (dyskusja) 11:21, 14 gru 2018 (CET)
@Matlin: Pojawiają się komunikaty:
"Dokonane przez Ciebie zmiany zostaną pokazane natychmiast po przejrzeniu przez uprawnionego użytkownika. (pomoc)"
"Osoby zaczynające pracę na Wikiźródłach zachęcamy do zapoznania się ze stroną Pomoc:Proofread."
"Uwaga: Nie jesteś zalogowany. Jeśli wykonasz jakąkolwiek zmianę, Twój adres IP będzie widoczny publicznie. Jeśli zalogujesz się lub utworzysz konto, Twoje zmiany zostaną przypisane do konta, wraz z innymi korzyściami." Joanna Le (dyskusja) 11:37, 14 gru 2018 (CET)
...nie mam nic naprzeciwko, Zdzislaw (dyskusja) 14:46, 14 gru 2018 (CET)
wstępnie za, ale rozumiem, że w dalszym ciągu ktoś będzie musiał to przejrzeć i zatwierdzić zmiany Nawider (dyskusja) 19:17, 14 gru 2018 (CET)
...i to ktoś posiadający konto. Uprawnień redaktora anonimowi też nie dostają. Ankry (dyskusja) 20:27, 14 gru 2018 (CET)
w sumie dlaczego nie, w takim ograniczonym zakresie. Kejt (dyskusja) 19:55, 14 gru 2018 (CET) Symbol support vote.svg Za
właściwie, czemu nie, też jestem Symbol support vote.svg Za Sempai5 (dyskusja) 21:20, 14 gru 2018 (CET)
Zgłoszone na phabricatorze: phab:T212478. Ankry (dyskusja) 08:30, 21 gru 2018 (CET)
Funkcja została dziś włączona (działa).
Czyli Gtk-ok.svg Załatwione Ankry (dyskusja) 17:24, 8 sty 2019 (CET)

Przycisk do szybkiego wstawiania sekcji[edytuj]

Przycisk do szybkiego wstawiania sekcji nie działa. Ktoś, coś? Nawider (dyskusja) 20:04, 15 gru 2018 (CET)

Ja mogę jedynie powiedzieć, że u mnie też nie działa. Joanna Le (dyskusja) 21:07, 15 gru 2018 (CET)
Powinien już działać. Jeśli nie, sugeruję na chwilę wyłączyć ten gadżet, a potem włączyć go ponownie. Niestety, popsuto go przy usuwaniu starego toolbara, a jakoś nikt dotąd nie zwrócił uwagi, że nie działa. Ankry (dyskusja) 21:50, 15 gru 2018 (CET)
Dziękuję, już działa Nawider (dyskusja) 22:26, 15 gru 2018 (CET)

Znaczniki formatowania[edytuj]

Chciałam zwrócić uwagę na sposób oznaczania pogrubionego i pochylonego tekstu. Na liście Błędy składniowe: Źle zagnieżdżone znaczniki jest całkiem sporo pozycji które w dużej części tego dotyczą. Jak widzę po edycjach, nie zwracamy na to zbytnio uwagi (ja z pewnością nie zdawałam sobie z tego sprawy, i sądzę że jest tak ze sporą częścią redaktorów).

Oznaczając tekst, aby był pochylony czy pogrubiony, wszystkie znaczniki muszą znajdować się wewnątrz szablonów {{c}} i {{f}} i nie mogą znajdować się wewnątrz szablonu {{rozstrzelony}}. Np. zapis {{c|{{roz|''COŚ TAM}}''|w=130%}} jest nieprawidłowy, powinno być {{c|''{{roz|COŚ TAM}}''|w=130%}}.

Pozdrawiam Joanna Le (dyskusja) 08:35, 4 sty 2019 (CET)

  • @Joanna Le:, {{c|{{roz|''COŚ TAM}}''|w=130%}} jest nieprawidłowy, ponieważ "początek" italica '' znajduje się w {{roz}}, natomiast "koniec" już w {{c}}. Nie widzę przeszkód aby znacznik znajdował się wewnątrz {{rozstrzelony}}, tak jak tu: {{c|{{roz|''COŚ TAM''}}|w=130%}}. Zdzislaw (dyskusja) 18:29, 5 sty 2019 (CET)
  • @Zdzislaw: wydaje mi się, że na liści błędów były strony w których znaczniki były wewnątrz szablonu , jak np. tutaj, ale możliwe że jest tam coś innego nie tak, czego ja nie widzę.
  • tak, tam problem wywołuje(ywał) ''' w {{Roz*}}. {{Roz*}} generuje kod dynamicznie, aby omijać znaki interpunkcyjne, i nie jest w stanie "parsować" znaczników wikikodu. Tutaj trzeba unikać zagnieżdżania - dodam informację w opisie szablonu. Zdzislaw (dyskusja) 19:25, 5 sty 2019 (CET)
I zauważyłam właśnie, że jako błąd oznaczane jest też, że znacznik jest poza <poem> [2], czyli powinniśmy oznaczać każdy wers osobno? Joanna Le (dyskusja) 18:50, 5 sty 2019 (CET)
@Joanna Le:, Aby być w zgodzie ze standardem, to każdy osobno, lub tak, Zdzislaw (dyskusja) 19:03, 5 sty 2019 (CET)

Kwestia formatowania[edytuj]

Zastanawiam się jak możliwie jak najwierniej (ale bez generowania trudności technicznych, uniemożliwiających przeglądanie utworu) odwzorować komentarze na marginesie objaśnień (zob. np. str. 38). Raczej nie może do tego służyć Szablon:wiersz. Być może wystarczyło by coś takiego jak Szablon:right sidenote na angielskiej Wikisource (np. tu). Jeżeli ktoś mógłby opracować znaczniki formatowania html/css na potrzeby tego, to byłbym wdzięczny podwójnie; bo tego typu komentarze występują chyba też w innych dialogach tłumaczonych przez Witwickiego, które zamierzam opracować. --Matlin (dyskusja) 21:10, 7 sty 2019 (CET)

Na razie można uznać za Gtk-ok.svg Załatwione. Dzięki, Ankry. --Matlin (dyskusja) 21:15, 20 sty 2019 (CET)

Zepsute renderowanie PDF-ów[edytuj]

Uwaga

Wygląda na to, że nam developerzy zaserwowali popsute renderowanie PDF-ów. O ile wcześniej wygenerowane obrazki stron wyświetlają się prawidłowo, o tyle nowo wygenerowane (gdy starych nie było lub się przeterminowały) dla wielu plików pokazują goły OCR lub pustą stronę zamiast jej obrazu.

Dlatego zalecam szczególną ostrożność przy wprowadzaniu / korygowaniu stron opartych o pliki PDF. Z DjVu problemu nie ma.

Problem zgłoszony na phabricatorze. Ale znając życie, nie liczyłbym na szybie usunięcie usterki ;P Ankry (dyskusja) 21:10, 20 sty 2019 (CET)

Wygląda na to, że już poprawione. Ankry (dyskusja) 23:46, 17 lut 2019 (CET)

Jak to poprawić[edytuj]

"ludu polskiego na {{Kor|Slązku|Ślązku]] i wszędzie i ciągle głoszą" w https://pl.wikisource.org/wiki/Baczno%C5%9B%C4%87!_Chleb_dro%C5%BCeje! na pewno mnie jest porządane. Jak to poprawić? Mateusz Konieczny (dyskusja) 12:52, 26 sty 2019 (CET)

Podmiana plików DjVu itp.[edytuj]

Wygląda na to, że w MediaWiki mocno kuleje obsługa plików z bardzo dużą liczbą powiązanych z nimi miniaturek (thumbnails) (patrz też phab:T214759). W związku z tym sugerowałbym osobom podmieniającym takie pliki (@Draco flavus:), zwłaszcza z dużą ilością stron, by przed ich załadowaniem na Commons sprawdziły, czy operacja wyczyszczenia cache (purge) nie zwróci błędu (jeśli zwróci to mamy prawie pewność, że pozostaną nam miniaturki stron ze starego pliku - przynajmniej tych, które były w ostatnim czasie - miesiąc wstecz? - przez kogoś oglądane). Można spróbować kilka razy. Jeśli operacja się nie powiedzie, sugerowałbym zamieszczenie pliku lokalnie korzystając z Special:Upload zamiast/oprócz zamieszczania pliku na Commons. Tyle, że warto przed zamieszczeniem sprawdzić, czy nowy plik jest na pewno tym o który chodzi, bo taki "numer" obejścia problemów z czyszczeniem cache uda się zrobić dla danego pliku prawdopodobnie tylko raz. Ankry (dyskusja) 15:13, 28 sty 2019 (CET)

Niewidoczne separatory[edytuj]

Szablony: {{Separator linia}}; {{Separator}}; Szablon:-=- (tego ostatniego nie da się go wstawić w {{s}}) nie wyświetlają się w mojej przeglądarce Firefox, są widoczne za to w Google Chrome. Poprosiłbym, abyście sprawdzili u siebie i ewentualnie, jeśli też nie będą widoczne, napisali tutaj. A ogólne pytanie brzmi: czy nie da się "poprawić" tych szablonów, aby były kompatybilne, albo czy da się, aby w takich sytuacjach wyświetlały alternatywnie zwykły separator, np. z {{---}}? --Matlin (dyskusja) 14:50, 8 kwi 2019 (CEST)

Z bratniej niwy: link między stronami i ebook[edytuj]

Nie mogę sobie poradzić z linkiem między stronami w spisie treści Z bratniej niwy i ebookiem, który generuje się pusty. Uprzejmie proszę o pomoc. Pozdrawiam, Wolan (dyskusja) 06:59, 9 kwi 2019 (CEST)

@Wolan: Nie wiem, czy nadal występuje u Ciebie problem z ebookiem, ale gdy pobieram go ze strony głównej (Z bratniej niwy) to zawiera wszystkie utwory; więc chyba Gtk-ok.svg Załatwione? --Matlin (dyskusja) 12:37, 12 maj 2019 (CEST)

Czy możliwe jest płynne połączenie tekstu pochodzącego z 2 (lub więcej) indeksów?[edytuj]

Pytanie jak w tytule. Dla przykładu, popatrz np. -> Old Surehand/Tom III. Tekst jest łączony z 2 oddzielnych indeksów, przy czym na ich "styku" powstaje przerwa, co nie wygląda zbyt elegancko. Chodzi mi o przerwę w zdaniu:

Nieraz dwaj lub trzej zuchwalcy napadają na pociąg i zmuszają podróżnych do poddania się rewizyi

a

na okrzyk: hands up!

Może jednak ktoś ma na to jakiś patent? Electron Smiley kabelsalat.gif <Odpisz> 11:43, 12 maj 2019 (CEST)

  • @Electron: Masz chyba na myśli sytuację, występującą ściślej na tej stronie i związaną z tym, że przerwę tworzą trzy puste strony (007 itd.) z nowego pliku (które należą do tego samego indeksu). Rozwiązaniem mogłoby być pominięcie tych stron przy wstawianiu znacznika pages index, ale widzę, że to też powoduje wystąpienie przerwy. --Matlin (dyskusja) 12:47, 12 maj 2019 (CEST)
  • @Electron: Z dwóch różnych indeksów nie jest możliwe ze względu na specyfikę formatowania MediaWiki. Ale tutaj widzę jeden indeks. Można użyć sekcji. Zobacz, jak to jest zrobione w niektórych rozdziałach Winnetou. Ankry (dyskusja) 13:10, 12 maj 2019 (CEST)
    • OK. Dzięki za radę. Ciekawe rozwiązanie i widzę, że działa. Problem w tym, że sekcję trzeba by było wkleić na każdej stronie... A dużo tego jest (podobna sytuacja występuje także w innych rozdziałach i stronach całości). Najlepiej by było zatrudnić bota. Więc na razie sobie chyba odpuszczę... Po za tym jeszcze kupa stron została do przepisania. Electron Smiley kabelsalat.gif <Odpisz> 11:09, 13 maj 2019 (CEST)
    • Btw. Próbowałem też zastosować parametry "exclude" bądź "include", które pozwalają wyświetlać tylko konkretne strony ale bez rezultatu (tzn. nie ma na nie żadnej reakcji oprogramowania). Ale może źle je stosuję, bo tak na dobrą sprawę to nigdzie nie jest szerzej opisane jak je zapisywać, gdy stron do wykluczenia/załączenia jest więcej i nie są one tylko prostymi numerami, a indeks jest bardziej złożony. Być może wtedy nie działają. Electron Smiley kabelsalat.gif <Odpisz> 12:19, 13 maj 2019 (CEST)
      • Niestety, parametr exclude działa tylko dla nowego formatu indeksów, opartych na pojedynczym pliku pdf/djvu. I chyba nie byłoby łatwo to zmienić. Ankry (dyskusja) 12:51, 13 maj 2019 (CEST)
        • Szkoda, bo to by elegancko rozwiązało sprawę. W takim razie pozostaje rozwiązanie z zastosowaniem sekcji. Ale zajmę się nim jak już uporam się z tekstem. A jeszcze trochę tego zostało. May nie należał do pisarzy oszczędnych w słowa ;) Electron Smiley kabelsalat.gif <Odpisz> 13:06, 13 maj 2019 (CEST)

Problem z wprowadzaniem niektórych znaków specjalnych[edytuj]

Od przedwczoraj mam problem z wprowadzaniem niektórych znaków specjalnych z klawiatury takich np. jak

"dwukropek" -> ː

"plus" -> ̟

"gwiazdka" -> ̈

nawiasy kwadratowe (jak je wprowadzam podwójnie) -> ʽʼ

nawiasy klamrowe (jak je wprowadzam podwójnie) ->̻ ˌ

i inne (to co mi się wprowadza jest pokazane po znaku "->") Litery wchodzą OK.

Jak widać wprowadzają się jakieś inne dziwne znaczki. Na innych projektach wiki (mediawiki) jest wszystko OK. Nie bardzo wiem o co biega... Czy to coś z moim kompem lub konfiguracją oprogramowania (Win XP ̟ FF ESR 52.9.0)? Wygląda jednak, że to coś zostało przestawione w tej wiki.

Przedtem wszystko było w porządku. Nic w międzyczasie nie przestawiałem ani nie instalowałem na kompie. Zmiana nastąpiła "w biegu" podczas pracy i od tego czasu jest źle (choć czasami jakby na krótko odpuszcza i niektóre znaki specjalne wchodzą prawidłowo ale to z rzadka). Oczywiście nie muszę chyba dodawać jak to utrudnia formatowanie, gdy niektóre znaki można tylko wstawiać metodą "skopiuj i wklej"...

Co to może być? Czy ktoś ma ten sam problem? --Electron Smiley kabelsalat.gif <Odpisz> 12:06, 20 maj 2019 (CEST)

Nie wiem jakiego edytora używasz, ale ja w edytorze z 2010 nie mam tego problemu: ":.*" Ankry (dyskusja) 13:08, 20 maj 2019 (CEST)
Edytora? Czy chodzi ci o przeglądarkę? To Fire Fox ESR 52.9.0 - nic nowszego na Windows XP nie pójdzie, a Wikimedia od jakiegoś czasu blokują inne starsze przeglądarki. Oczywiście dla mojego dobra ;) --Electron Smiley kabelsalat.gif <Odpisz> 13:27, 20 maj 2019 (CEST)
W starszym (po wyłączeniu "paska edycji") też nie mam żadnego problemu: ":.*"
A nowszych cudeniek nie używam, więc się nie wypowiem. Może coś nie tak z klawiaturą na twojej maszynie, albo z jakąś wybraną niestandardową klawiaturą w samym MediaWiki?
Chodzi mi o edytor mediawiki: [3] Ankry (dyskusja) 13:36, 20 maj 2019 (CEST)
Aha. Też nie używam żadnych nowych wynalazków. Edytuję w wikikodzie, po staremu. W preferencjach mam zaznaczone Włącz pasek narzędzi edycyjnych Inna nazwa to 'edytor wikikodu 2010' Co do skrótówː Java skrypt wydaje się chodzić prawidłowo ale być może zaczął się nagle z czymś gryźć? Zresztą zerżnąłem go dawno temu od Ciebie ː) Być może trzeb by zaktualizować? --Electron Smiley kabelsalat.gif <Odpisz> 13:52, 20 maj 2019 (CEST)
Najwyraźniej edytując na Wikiźródłach niechcący przestawiłeś w oknie edycji rodzaj klawiatury. Wejdź w jakiekolwiek okno edycji, najedź na trójkącik w prawym dolnym rogu (pod paskiem przewijania), po kliknięciu powinna wyświetlić ci się ikonka klawiatury, a po kliknięciu w nią lista wyboru - przełącz na "Użyj swojej klawiatury". Salicyna (dyskusja) 14:09, 20 maj 2019 (CEST) Może niekoniecznie na sam trójkącik, ale w jego okolicach, w prawym dolnym rogu okna edycji. Pingam jeszcze raz, bo w pierwszej edycji zrobiłam to z błędem i pewnie nie zadziałało. @Electron: Salicyna (dyskusja) 14:28, 20 maj 2019 (CEST)
Odkryłem o co chodzi. Jak wprowadzałem te problemowe znaki to pojawiało mi się na ekranie jakieś małe okienko z nazwą "International Phonetic Alphabet". Na początku tego nie zauważyłem, bo jakoś tak tylko niezbyt wyraźnie majaczyło. A oczy już nie te... Można toto wyłączyć - po kliknięciu na to okienko jest taka opcja. I po sprawie. Na co to to komu do tej pory nie wiem... Pewnie dla ułatwienia czegoś tam, a mnie mało co szlag nie trafiał... Dziękuję wszystkim pięknie za pomoc i pomysły :) Electron Smiley kabelsalat.gif <Odpisz> 14:33, 20 maj 2019 (CEST)
@Electron: No, to jest właśnie to, o czym mówiłam powyżej - musiałeś niechcący podczas edycji kliknąć na wybór rodzaju klawiatury i przełączyć na fonetyczną. Salicyna (dyskusja) 14:37, 20 maj 2019 (CEST)
OK. Dzięki za wyjaśnienie. Wprowadzają te nowe funkcje za funkcją a człowiek coś niechcący włączy i siwieje potem ze zgryzoty, że coś mu się nagle popsuło... Ech... Ja już nie nadążam. Electron Smiley kabelsalat.gif <Odpisz> 14:43, 20 maj 2019 (CEST)

Maszynopis a typografia[edytuj]

Od czasu do czasu zdarzają się nam do przepisania maszynopisy. Przykład Ethos społeczny literatury polskiej. Wydaje mi się, że trzymanie się ogólnych zasad stosowanych na wikiźródłach nie ma sensu. Rozumiem, że zasady są takie: cudzysłowy zostawiamy, jak w oryginale, myślnik/łącznik typograficzny (zgodnie z funkcją), nawias jak w oryginale, trzy kropki w wielokropek (zresztą dzieje się to na wiki automatycznie).
Mielibyśmy tu taką sytuację (zmyślony przykład): "Flaga czerwono-biała /czyli/ odwrócona..." — rzekł nauczyciel.
Wydaje mi się, że naturalniejsze byłoby w tym wypadku (maszynopis) zdecydowanie się na konsekwentne stosowanie polskich typograficznych cudzysłowów „”, normalnych nawiasów ()i rozróżniania łączników od myślników(czyli naturalna transformacja tradycyjnego maszynopisu w tradycyjny tekst złożony przez zecera.
Maszynopis był pisany wg przysłowia „Tak krawiec kraje, jak mu materiału staje.” — jeśli nie było na maszynie nawiasów — zastępowano je ukośnikiem, cudzysłów był jeden (łączył funkcję ze znakiem cali), kreska również była jedna (minus-myślnik-łącznik), trzy kropki były od siebie oddalone, jak w każdym nieproporcjonalnym kroju, nienaturalnie daleko.
Draco flavus (dyskusja) 16:30, 26 cze 2019 (CEST)


  • @Draco flavus: Ta dyskusja jest skazana na niepowodzenie - jest przyjęty tak zwany konsensus dotyczący tego, że teksty należy wprowadzać tak wiernie, jak to jest możliwie. I myślę, że w sporej części słusznie, bo przyjęcie polityki redakcyjnej (nawet tylko w części źródeł) utrudniłoby pracę - dlatego są takie serwisy, jak Wolne Lektury. Dyskusje o tej kwestii toczą się często. Myślę, że, skoro temat powraca, warto stworzyć jakąś wiki, której funkcją byłaby jakaś obróbka redakcyjna i krytyczna tekstu - oczywiście poza ruchem Wikimedia. Coś jak np. Ogród Petenery, który istnieje na bezpłatnej (bodaj) platformie Wikia (Fandom). --Matlin (dyskusja) 17:40, 26 cze 2019 (CEST)
    • Ad vocem - dla jasności, nie mam do tematu, żadnego stosunku emocjonalnego, indeks był już opracowywany przez kilka osób, podchodziły do tego różnie. Raczej oczekuję porady, czy w przypadku maszynopisu uwzględniać ich naturalne ograniczenia i robić dziwną mieszaninę "skansenu" (cale, ukośniki) i postępowych zasad (wielokropki, myślniki) czy w tym wypadku zrobić jakiś kompromis. I nie chcę tu naprawdę odgrzewać starych tematów, na poziomie ogólnym zgadzam się, z ideę zachowywania oryginału.Draco flavus (dyskusja) 17:53, 26 cze 2019 (CEST)
No nie, nie stwierdziłem, że masz jakikolwiek stosunek do tematu, jest on zresztą nieistotny, jednakowoż on się sprowadza do tych [tematów], które wymieniłem, a w jaki sposób? To działania ocenne, które wykraczają poza potrzebę; tę potrzebę wyznacza następujące kryterium: należy dokonywać ocen (czy dany zapis/pisownia, czy dany sposób zapisu w znaczeniu typograficznym jest merytorycznie i teleologicznie dobrym/poprawnym/spójnym) tylko wtedy, gdy mamy wątpliwości, czy jest w ogóle możliwe odwzorowanie (w kodzie strony) tego, co poddajemy ocenie. A więc także przykładowo w sytuacji, gdzie mamy na skanie subtelność w zapisie tak wielką, że prawie niedostrzegalną (konkretnie: wahamy się, czy rozmiar czcionki jakiegoś nagłówka jest, w odniesieniu do tekstu zasadniczego, większy lub mniejszy o kilka procent). Przy czym taka subtelność nie może dawać zbyt dużego luzu interpretacyjnego i sprawiać wrażenia, że odwzorowanie (w kodzie strony) jest przekłamane. Chcąc podsumować i odpowiedzieć na zadaną Twoją kwestię, muszę stwierdzić, że przyjęty tak zwany konsensus oznacza, że znaki interpunkcyjne należy odwzorować, o ile mają swój odpowiednik na bitowej tablicy znaków, jeżeli nie mają, to należy sięgnąć po najbardziej podobny (wizualnie) znak i konsekwentnie stosować go w obrębie tekstu. --Matlin (dyskusja) 20:42, 26 cze 2019 (CEST)
  • Btw. Przypominam, że istnieje Kategoria:Transkrypcje. Fakt, że kurzem porosła... ale można by było ten tekst poprawić w ramach transkrypcji. Jakby komuś się chciało. Były też pojedyncze próby uwspółcześniania zamierzchłej ortografii. Ale już nie pamiętam, których to konkretnie tekstów dotyczyło. Electron Smiley kabelsalat.gif <Odpisz> 00:29, 27 cze 2019 (CEST)

Możliwości są następujące (+ jeszcze kilka pośrednich)

  • 1. "Flaga czerwono-biała /czyli/ odwrócona..." - rzekł nauczyciel. (najbliższa oryginałowi)
  • 2. "Flaga czerwono-biała /czyli/ odwrócona..." - rzekł nauczyciel.
  • 3. "Flaga czerwono-biała /czyli/ odwrócona..." - rzekł nauczyciel.
  • 4. "Flaga czerwono-biała /czyli/ odwrócona..." — rzekł nauczyciel. (najbliższa moim zdaniem ogólnym zasadom stosowanym na Wź )
  • 5. „Flaga czerwono-biała /czyli/ odwrócona...” — rzekł nauczyciel.
  • 6. „Flaga czerwono-biała (czyli) odwrócona...” — rzekł nauczyciel. (najbliższa idei autora zapewne)

Za jaką wersją byście byli (ja za 6)? W jakieś transkrypcje dla "głupiego" maszynopisu z lat 80-tych bym się nie bawił. Draco flavus (dyskusja) 09:11, 27 cze 2019 (CEST)

  • Kwestia gustu, jak to w transkrypcjach, przekładach, itp.... Zawsze to jest jednak jakiś arbitralny wybór. Electron Smiley kabelsalat.gif <Odpisz> 12:14, 27 cze 2019 (CEST)
  • Przyjęło się stosować u nas wersję czwartą i do tej bym się skłaniał (nawiasy traktowałbym tutaj jak cudzysłowia — staraliśmy się zawsze pozostawić oryginalne, a że tekst nam się trafił w maszynopisie... — unikałbym takich jeśli mamy dostępną inną wersję na otwartej licencji). Przy okazji: mamy jeszcze nieopracowany indeks a ciekawie się zapowiadający (czytałem Anda) o nietypowej typografii: patrz przykład np. tu Bonvol (dyskusja) 21:03, 27 cze 2019 (CEST)
Dodam jeszcze, że możemy spotkać jeszcze inne problemy w innym maszynopisach:
  • Druga wojna światowa wybuchła w I939 roku.
  • Druga wojna światowa wybuchła w l193 roku.
Praktyka zamieniania 1 na wielkie i lub małe ℓ była powszechna i zalecana... Draco flavus (dyskusja) 20:37, 29 cze 2019 (CEST)
Wszystko fajnie, ale wg mnie należałoby zacząć od zastanowienia się, czy jesteśmy w stanie sformułować jasne i jednoznaczne zasady "transkrypcji" takich maszynopisów. Celem wspierania naszych tekstów przez skany jest ich weryfikacja ze źródłem. Weryfikacja, która zakłada, że jest możliwe jednoznaczne stwierdzenie czy dany tekst jest zgodny ze źródłem, czy nie. Jeśli takiej możliwości nie będzie, to zamiast wprowadzać nowe teksty, zaczniemy się zajmować dyskusjami nt. właściwej interpretacji poszczególnych fragmentów, a na to raczej nie mamy zasobów. Podam przykład: załóżmy, że mamy dokument oznaczony sygnaturą: "I94o/II/A": jak stwierdzić, czy jest to rzymska II, czy 11? Osobiście nie mam nic przeciwko takim transkrypcjom, ale pod warunkiem, że ktoś będzie w stanie zdefiniować jednoznaczne reguły postępowania (co zamieniamy, na co i w jakim kontekście). Ankry (dyskusja) 08:58, 30 cze 2019 (CEST)
Za całkowitym zachowaniem liternictwa tekstu pierwotnego. — Paelius (dyskusja) 23:44, 8 lip 2019 (CEST)

PetScan a wikiźródła[edytuj]

Taki problem: zawsze używałem jednego zapytania Petscana do wyciągania małych stron do oznaczania. Ale ostatnio strony oznaczone przestały mi znikać z listy. Takie zapytanie w PetScanie pokazuje mi na pierwszych 10 pozycjach 9 stron Skorygowanych (pierwszego nie oznaczę bo nie znam rosyjskiego). Jakiekolwiek idee dlaczego? PMG (dyskusja) 10:05, 12 wrz 2019 (CEST)

Zgłosiłem na to defekt. PMG (dyskusja) 10:18, 12 wrz 2019 (CEST)
Teraz jest chyba dobrze. --Wargo (dyskusja) 22:37, 16 wrz 2019 (CEST)
Tak, jeszcze na to zerknę trochę. Poza tym widzę że ktoś to oznacza bo poznikało trochę z listy rzeczy, których ja nie oznaczyłem :P PMG (dyskusja) 10:19, 17 wrz 2019 (CEST)

Czytniki epub[edytuj]

Witam, Bardzo podobają mi się pozycje w wikiźródłach, ale mam pytanie. Dla kogo tworzycie pliki w formacie epub? Dla ludzi korzystających z czytników? Nie wydaje mi się. Czytniki są tak prostymi urządzeniami, przynajmniej na razie, że dla nich odpowiedniejszym formatem jest epub 2. Czytniki nie są w stanie wykorzystywać wszystkich znaczników stylów z css. Nie są w stanie prawidłowo obsługiwać tabel. Wariują gdy gdy w css znajduje się błąd. Czemu w kodzie html formatowanie z css zastąpione zostaje przez formatowanie wewnątrz tekstu ( np. <div style="">). Po co odnośniki do skanów źródłowych; zresztą ukryte. Wydaje mi się, że forma przerosła treść, a twórcy zapomnieli o naczelnej zasadzie programistów BUZI (bez udziwnień zapisu idioto). Rozumiem, że chcecie zrobić super plik multimedialny, ale większość ludzi czyta epuby na czytnikach, a nie na komputerach lub tabletach. Dlatego na epub należy patrzeć jak na książkę papierową, a nie plik multimedialny. -- niepodpisany komentarz użytkownika 91.222.140.70 (dyskusja | wkład)

Po pierwsze, epub jest formatem bazowym używanym do generowania wszystkich innych (mobi, pdf, txt) przez używane narzędzie. Dlatego nawet jeżeli jest on mało przydatny, i tak jest niezbędny a jego obecność niewiele kosztuje. Z tabelami rzeczywiście jest problem, ale na to chyba niewiele obecnie można poradzić poza sukcesywnym rezygnowaniem z nich przy opracowywaniu tekstów. Ale nie wszędzie się da.
Po drugie, nie rezygnujemy z css, bo w odróżnieniu od styli inline nigdy go u nas na szeroką skalę nie było. Problem z css jest taki, że przerobienie wszystkich możliwych styli występujących w tekstach na uniwersalne klasy w taki sposób, by niczego nie popsuć (zwłaszcza, że mamy nadal mnóstwo kodu opartego jeszcze na HTML4) to jest multum roboty dla wielu osób. A nas jest garstka wolontariuszy, którzy niekoniecznie znają się na css.
Po trzecie, jeśli chcesz pomóc, zapraszamy do współpracy. Ankry (dyskusja) 11:14, 6 paź 2019 (CEST)
  • Wtrącę w temacie swoje 3 grosze, jako w pewnym sensie odpowiedzialny za taki stan rzeczy. Przybyłem na Wikiźródła właśnie w poszukiwaniu utworów, które zazwyczaj czytam na Kindlu - właściwie o Źródłach dowiedziałem się na Świecie Czytników, i kiedy się tutaj pojawiłem (chyba w 2014) pobranie jakiegokolwiek tekstu, szczególnie w zjadliwym dla czytnika formacie było baaardzo utrudnione. Jednak możliwość pobierania tekstów w formatach zewnętrznych była ważną sprawą dla międzynarodowej społeczności źródeł. Aby ułatwić życie czytelnikom (m.in. nam, czytnikowcom), międzynarodowa społeczność wolontariuszy stworzyła narzędzie pozwalające w locie eksportować teksty ze źródeł (Wsexport). A jest to o tyle karkołomne zadanie, że teksty na źródłach wciąż żyją (są przeglądane, poprawiane i uwierzytelniane przez kolejnych użytkowników, dopisywane są kolejne rozdziały, teksty powstają czasami latami, tworzone przez kilku wolontariuszy, mających różne przyzwyczajenia, ....), tak więc (także z powodu tego, że wolontariuszy jest zdecydowanie za mało, aby tworzyć dedykowane epuby dla poszczególnych pozycji) jedynym rozwiązaniem było automatyczne tworzenie plików (w tym epub) na żądanie. Zaimplementowaliśmy je także u nas, co spowodowało, że praktycznie 90-cioma% pozycji możemy się cieszyć pobierając je i czytając także na czytnikach. Teraz kwestie, które poruszyłeś - możesz pobrać każdą pozycję w epub2 wybierając odpowiedni format bezpośrednio w Wsexport wpisaując tytuł strony ze Źródeł; eksporter z definicji nie zastępuje css przez formatowanie wewnątrz tekstu, lecz aby zachować uniwersalność ze wszystkimi wersjami językowymi wprowadza jedynie pewne uproszczenia [4]; tabele to osobny problem, tutaj chyba nigdy nie będzie złotego środka, lecz nie mamy ich zbyt dużo, a Kindelki jakoś sobie radzą; odnośniki do skanów źródłowych; zresztą ukryte są, ponieważ istnieją także ukryte w naszych tekstach, a są one ważne ze względu na możliwe do implementacji automatyczne odnośniki w plikach do konkretnej strony w źródle. Istniałaby możliwość ich usunięcia dla naszej wiki lokalnie, lecz musiałby istnieć ważny powód (mi nie przeszkadzają w czytaniu (bo ich nie widać :) ), poza tym to jedynie kilka bajtów, raczej nie stanowiących problem wagi pliku dla czytnika). Zaręczam, że twórcy narzędzia nie zapomnieli o naczelnej zasadzie programistów, wręcz przeciwnie, narzędzie jest najprostsze jak to możliwe (a wielce efektywne, dość wspomnieć, że generuje powyżej 100 000 plików miesięcznie); zaręczam także, że nie było naszą intencją zrobienie pliku multimedialnego. Chodziło o sprawne i efektywne obsłużenie tysięcy żądań przez serwer, i co bardzo ważne, udostępnienie naszych tekstów dla wszystkich w najpopularniejszych formatach bez angażowania wolontariuszy, których po prostu jest za mało, a wolą skupiać się nad powiększaniem księgozbioru, niż na myśleniu o technikaliach.
Życzę więc wielu radości w konsumpcji naszych utworów, i proszę o przymykanie oczu na pewnie niedoskonałości składu :))) Zapraszamy oczywiście do współpracy. Zdzislaw (dyskusja) 15:29, 6 paź 2019 (CEST)
  • No niestety, co książka, to inne formatowanie - brak jest jednolitych stylów formatowania i redakcji książek, jakie mają na przykład Wolne Lektury. Na moim e-czytniku na przykład nie działają książki z Wikiźródeł, urządzenie nie jest w stanie otworzyć poprawnie plików epub z Wikiźródeł (z wyjątkami). Pomaga jedynie usunięcie z pliku strony tytułowej czy spisu treści (nie mylić z toc.xml wewnątrz pliku, czy jakoś tak) poprzez edytor ebooków w Calibre. Matlin (dyskusja) 15:07, 9 paź 2019 (CEST)
  • @Matlin: gdybyś mógł podać jaki to czytnik, przykład pozycji, która nie działa, przykład takiej która działa, przykład tego co musisz usuną i z jakiego pliku usuwasz... być może udałoby się znaleźć przyczynę blokowania działania na Twoim czytniku i coś ulepszyć w generatorze, Zdzislaw (dyskusja) 21:32, 10 paź 2019 (CEST)

Błąd w niekorygowaniu[edytuj]

Nie mogę skorygować strony Strona:PL Waleria Marrené-Mąż Leonory 042.jpeg - przy próbie zmiany statusu na skorygowaną wyświetla się komunikat "Błąd: Ta akcja została automatycznie zidentyfikowana jako szkodliwa, w związku z tym została odrzucona. Jeśli uważasz, że ta edycja była zasadna, skontaktuj się z administratorem i poinformuj go o zaistniałej sytuacji. Krótki opis reguły nadużycia, do której Twoja akcja została dopasowana: zmiana statusu czerwony -> żółty przez tego samego użytkownika". Tymczasem w historii edycji tej strony nie widzę, bym kiedykolwiek zmieniała jej status... Salicyna (dyskusja) 21:00, 13 paź 2019 (CEST)

@Salicyna: system widzi twoją zmianę, z 2016 jako "Przepisanie" i dlatego nie daje ci skorygować, z jakiegoś powodu w niektórych przypadkach tak się robi. Najłatwiej chyba w tym przypadku żebyś anulowała swoją poprzednią edycję i wprowadzone wtedy zmiany wprowadziła na nowo przy zmianie statusu na "Skorygowana". Joanna Le (dyskusja) 21:14, 13 paź 2019 (CEST)
Kiedy próbuję wycofać moją poprzednią zmianę, z kolei wyświetla mi się "Błąd: Ta akcja została automatycznie zidentyfikowana jako szkodliwa, w związku z tym została odrzucona. Jeśli uważasz, że ta edycja była zasadna, skontaktuj się z administratorem i poinformuj go o zaistniałej sytuacji. Krótki opis reguły nadużycia, do której Twoja akcja została dopasowana: wykrywanie pomyłek pp/pk" i znowu nie mogę zapisać... ;) Salicyna (dyskusja) 21:22, 13 paź 2019 (CEST)
@Salicyna: zdaje się, że jako administrator na czas takiej edycji możesz wyłączyć filtr 6, który uniemożliwia zmianę statusu czerwony -> żółty przez tego samego użytkownika, ale jak to dokładnie działa to niestety nie pomogę. Joanna Le (dyskusja) 22:15, 13 paź 2019 (CEST)
@Salicyna: problem wynika z przeszłych zmian w rozszerzeniu proofreadpage: pierwotnie nie odnotowywało ono w nagłówku nazwy użytkownika, który ustawiał status czerwony. Od pewnego czasu robi to i w efekcie, jako użytkownik ustanawiający status czerwony, odnotowywany jest ten, kto pierwszy edytował daną stronę przy tym statusie, bez jego zmiany (jeśli takie edycje miały miejsce). Z drugiej strony, abusefilter ma dostęp tylko do ostatniej edycji i nie może analizować całej historii strony. Efekt jest jak widziałaś. Jeśli uważasz, że filtr sprawia więcej kłopotów niż z niego pożytku, nie krępuj się i wyłącz go. "Poprawić" go się nie da. Przypisać czerwonych edycji właściwym użytkownikom też nie za bardzo (zmienić użytkownika przypisanego do danej zmiany statusem można chyba tylko zmianiając status strony (chyba, że pole to jest puste). Ankry (dyskusja) 08:15, 14 paź 2019 (CEST)
Nie wiem, czy filtr sprawia więcej kłopotów niż z niego pożytku, osobiście pierwszy raz miałam przez niego problem z edytowaniem. Po prostu miałam pecha, że jednocześnie blokował mnie filtr korygowania i filtr pp/pk przy próbie anulowania... Salicyna (dyskusja) 09:02, 14 paź 2019 (CEST)

Problem z plikami EPUB na czytnikach[edytuj]

W ostatnich paru tygodniach widziałem doniesienia użytkowników czytników, że są problemy z działaniem plików EPUB z Wikiźródeł. Tu przykładowa konwersacja na grupie eCzytelnicy na FB. Grupa jest publiczna, można czytać bez logowania.

Postanowiłem to sprawdzić i wgrałem dwie książki na PocketBook Touch HD 3, jeden z lepszych dostępnych czytników, obsługujący w dużym stopniu format EPUB 3:

  • Podróże Guliwera - otwiera się, zmieniam kilkanaście stron, program zamyka książkę automatycznie. Tak samo przy próbach nawigacji.
  • Żywot Jezusa - otwiera się na pierwszej stronie, nie jestem w stanie przejść dalej.

Edit: na Kobo jest tak samo, czytnik restartuje się po kilkunastu stronach, niezależnie czy to EPUB2 czy EPUB3.

Sprawdziłem oba pliki w walidatorze Flight Crew, używanym też w programie Sigil (to popularny edytor epubów). Dla obu plików program wywala setki błędów, w rodzaju pominięte i niewłaściwe atrybuty HTML. Tu przykładowe screeny: [5] oraz [6].

Podobnie z walidatorem w3c.

Dla porównania sprawdziłem kilka książek zakupionych w księgarniach - zwykle błędów nie ma, albo jest ich kilka.

Nie znam się na robieniu epubów, wiele z tych błędów wydaje się nieistotnych (przeglądarka powinna zignorować np. nieistniejącą właściwość taga), ale być może ich nagromadzenie powoduje problemy. Trudno mi też określić, czy jest to problem obecnego narzędzia do generowania e-booków, a nie samego źródła HTML, które jest wykorzystywane. W tym drugim przypadku generator powinien filtrować odpowiednio HTML, tak aby pozbywać się elementów niezgodnych z walidatorem. Ktoś ma pomysł, co z tym możemy zrobić? rdrozd (dysk.) 00:53, 20 paź 2019 (CEST)

Dzięki @Rdrozd:, godzina późna, ale od rana będziemy mieli wyjątkową koncentrację właściwych osób we właściwym miejscu (na razie poszli do hotelu). A i zasugeruję obserwowanie tej grupy, na której zgłoszenie się pojawiło - rozsądni ludzie. Bonvol (dyskusja) 01:01, 20 paź 2019 (CEST)
Mi się jutro mam nadzieję uda wpaść na Źródłosłów, więc pokażę na żywo, co nie działa :) a jak widzę jeden z dyskutantów z grupy odzywał się powyżej jako IP... rdrozd (dysk.) 01:19, 20 paź 2019 (CEST)
  • @Rdrozd: Dziękujemy za informacje - w miarę wolnych mocy przerobowych będę starał się zidentyfikować przyczyny problemów. Sprawdzałem przykładowe pozycje przy pomocy Flight Crew i rzeczywiście dla oby pozycji zgłasza setki ostrzeżeń - jednakże wynika to raczej z epub-3, którego mogą słabo trawić, szczególnie starsze czytniki. Wydaje mi się, iż dobrym rozwiązaniem byłoby generowania i pobieranie epubów w wersji 2, lista błędów wskazywanych przez walidator spada bardzo drastycznie, ograniczając się jedynie do dwóch pominiętych deklaracji dla każdego z obrazków, tutaj do pobrania w formacie 2.0:
Żywot Jezusa (epub2)
Podróże Gulliwera (epub2)
za które oczywiście zabierzemy się w ramach wolnego czasu. Gdybyś Rdrozd zobaczył jak zachowują się na czytniku. Prosiłbym o zgłaszanie tutaj kolejnych uwag i błędów, w miarę możliwości będziemy starali się poprawić (przynajmniej lokalnie), pamiętając, że narzędzie generowania epubów obsługuje wszystkie wersje językowe. Zdzislaw (dyskusja) 10:13, 20 paź 2019 (CEST)
  • @Rdrozd: Jeszcze raz dziękuję za pomoc w identyfikacji problemów z dostępnością naszych utworów, odkrycie, iż użycie br-ów do wydzielenia akapitów powoduje poważne problemy jest ogromnie cenne, lecz zanim podejmiemy decyzje o zmianach w formatowaniu (przełomowych dla ws) istnieje potrzeba potwierdzenia ich wpływu. Potraktować chciałbym Podróże Guliwera i Żywot Jezusa jako indeksy ćwiczebne, dla których zmieniona zostanie źródłowe formatowanie, po czym będę Cię prosił o testy. @Ankry:, potrzebowałbym w pierwszej kolejności Twojej pomocy, aby przebotować wszystkie strony powyższych dwóch indeksów z dokonaniem zmian typu \<br ?\/?\>\n\{\{tab na \n\n\{\{tab. Czy mam wpisać zadanie dla bota? :)Zdzislaw (dyskusja) 21:58, 20 paź 2019 (CEST)
    • @Zdzislaw: Właśnie miałem poruszyć ten sam temat. Zadanie można stworzyć, na razie pod dyskusję. Jednak istotniejsze według mnie jest to, że "naprawienie" usterki będzie się wiązało ze zmianą naszych przyzwyczajeń, opracowaniem nowych standardów, a wtedy można myśleć o (prawdopodobnie półautomatycznej) konwersji tekstów, które mamy. Decyzja jest na tyle ważna, że powinniśmy ją podjąć w szerszym gronie i wyjaśnić konsekwencje całej społeczności. Ankry (dyskusja) 22:12, 20 paź 2019 (CEST)
      • @Ankry:, ależ oczywiście, lecz zanim rozpoczniemy dyskusję nad zmianą standardów, wolałbym najpierw potwierdzić przypuszczenie i przetestować to dokładnie. Dlatego w tych celach chciałbym przebotować jedynie te dwa indeksy. Zmiana ta nie wpłynie na ich wygląd, a pozwoli na dogłębne testy. Zdzislaw (dyskusja) 22:17, 20 paź 2019 (CEST)
        • OK. Ankry (dyskusja) 22:19, 20 paź 2019 (CEST)
        • @Zdzislaw, @Rdrozd: Przerobiłem na akapity również Potop Sienkiewicza. To tak dla sprawdzenia, czy rozmiar ma dla tych czytników znaczenie... Ankry (dyskusja) 16:25, 21 paź 2019 (CEST)
    • Ja jeszcze w tygodniu spróbuję przerobić i przetestować tak inne epuby (np. tę "Wojnę i pokój" zgłaszaną na FB) i sprawdzę czy to załatwia problem. rdrozd (dysk.) 22:34, 20 paź 2019 (CEST)

@Zdzislaw, @Ankry: No i nie wiem, o co chodzi. :-( Ściągnąłem te dwie książki w wersji z akapitami + Potop i... tak samo nie działa. "Żywot Jezusa" wywala się na pierwszej stronie (choć to może kwestia tabelki ze spisem treści o której wspominałem na spotkaniu). "Potop" na pierwszej stronie w ogóle zawiesza czytnik. A "Podróże" działają różnie: na jednym czytniku wywala się po 1/3 książki, na innym działa, ale ma problemy ze zmianą stron - skacze np. między 17 i 24 i z powrotem. W źródle EPUB na pewno są akapity zamiast przełamań.

Otworzyłem jeszcze raz "Podróże" w mojej wersji, którą na szybko zrobiłem podczas Źródłosłowu (mechaniczna zamiana <br /> na <p> plik tutaj: [7]) i działa... Nie mam pojęcia dlaczego. Porównałem źródła HTML pierwszego rozdziału - różnice oczywiście są w liczbie i układzie akapitów, czasami jakieś dodatkowe divy, ale czy to jest decydujące? Nie mam pojęcia. W każdym razie obecna metoda nadal nie działa. rdrozd (dysk.) 19:33, 21 paź 2019 (CEST)

@Rdrozd: Strzelam: może się czytnikom nie podoba coś co MediaWiki umieszcza pomiędzy akapitami? Spróbuj może z tego "niedziałającego" ePuba usunąć wszystkie </p>.
@Rdrozd: wywaliłem tabelkę ze strony tytułowej i spisu treści w Żywot Jezusa, ściągnij ponownie i przetestuj w wolnej chwili, Zdzislaw (dyskusja) 22:27, 21 paź 2019 (CEST)
@Zdzislaw: Z "Podróży" usunąłem wszystkie </p>, wywala się teraz na obu czytnikach solidarnie w okolicy nagłówka "ARTYKUŁY OSKARŻENIA" - tam jest dużo obrazków, może o to chodzi.
Co do "Żywota" - bez zmian, wysypuje się na okładce. Jedno co pozytywne, że po usunięciu tabelki na Kindle w wersji MOBI działa spis treści. rdrozd (dysk.) 19:20, 23 paź 2019 (CEST)

MediaWiki:Abusefilter-pagestatusrestrictions[edytuj]

Nie masz uprawnień do zmiany statusu proofread tej strony. Uprawnienia zmiany statusu stron maję tylko zalogowani użytkownicy.Nie masz uprawnień do zmiany statusu proofread tej strony. Uprawnienia zmiany statusu stron mają tylko zalogowani użytkownicy. 83.31.86.73 (dyskusja) 00:11, 22 paź 2019 (CEST)

Dziękujemy za zauważenie błędu, już poprawione. Pozdrawiam, Salicyna (dyskusja) 00:13, 22 paź 2019 (CEST)

przypis w przypisie[edytuj]

Czy mamy metodę wstawienia przypisu w przypis? Taka sytuacja pojawia się m.in. tutaj z odnośnym dwupoziomowym przypisem stąd. Pamiętam, że kiedyś to było niemożliwe; czy się to obecnie zmieniło? Czy jest jakiś szablon na wzór wikipedyjnego {{w:Szablon:Refn}}? Vearthy (dyskusja) 23:10, 23 paź 2019 (CEST)

Można przez #tag, szablonu na wzór wikipedii nie mamy. Ankry (dyskusja) 02:12, 24 paź 2019 (CEST)
Super! Jest tylko jedno ale, w obecnym kształcie uwaga do przypisu pojawia się nieco nieintuicyjnie przed właściwym przypisem, w którym do tej uwagi jest odnośnik. Da się to jakoś obejść czy wymaga to zbyt dużo roboty? Vearthy (dyskusja) 02:23, 24 paź 2019 (CEST)

Linki w pdf[edytuj]

W Język międzynarodowy linki spisu treści w pdf prowadzą do strony internetowej a nie do stron pdf. Jak to naprawić? Marek Mazurkiewicz (dyskusja) 08:28, 26 paź 2019 (CEST)

Dodać do epuba strony do których linki kierują na wiki (stron do których linki nie działają nie ma w epubie). Tylko, nie wiem, czy wtedy będzie lepiej, bo będzie dublowana treść: teraz mamy cały rozdział, dojdą jeszcze jego podrozdziały, każdy na osobnej stronie i z własnym szablonem licencji. Można zostawić tylko te podrozdziały, ale do czego ma wtedy linkować link do strony głównej rozdziału?
Chyba, że masz pomysł, jak zrobić w MediaWiki różne linki w zależności od narzędzia, które pobiera stronę w HTML? Ankry (dyskusja) 14:09, 26 paź 2019 (CEST)
Czy przeniesienie podstron pod Język_międzynarodowy/nazwa_rozdziału by nie pomogło? Język międzynarodowy/tył działa w epubie poprawnie, a ma w spisie treści podaną ścieżkę względną. --Wierzbowski (dyskusja) 21:00, 26 paź 2019 (CEST)
@Wierzbowski: Przeniesienie niczego nie zmieni, tylko nazwy. Weźmy taki przykład: w tej chwili "Przedmowa" linkuje do strony Przedmowa do Języka międzynarodowego (i jest e ebooku), a "Do czytelnika" linkuje do strony Przedmowa do Języka międzynarodowego/Do czytelnika (która nie wchodzi w skład ebooka, bo jej treść stanowi początek poprzedniej strony). Jeślibyśmy dołączyli tę ostatnią do ebooka, to co z pierwszą? Zostawiamy i dublujemy treść? Zastępujemy czymś innym - czym? Ebook to są po prostu scalone różne strony wiki. O ile wiem, nie ma obecnie możliwości tworzenia w ebooku linków do sekcji na stronach, jedynie do osobnych stron.
Być może jakimś rozwiązaniem byłoby zastąpienie strony z całą przedmową, stroną z fragmentem spisu treści (rozdziały przedmowy). Tylko czy takie rozczłonkowanie przedmowy na osobne strony + licencje ma w ebooku sens? Nie twiardzę, że nie ma problemu; tylko nie widzę dobrego sposoby na jego rozwiązanie. Być może linki do wiki to mniejsze zło.
A może @Zdzislaw: ma jakiś pomysł? Ankry (dyskusja) 21:34, 26 paź 2019 (CEST)

Google Code-In will soon take place again! Mentor tasks to help new contributors![edytuj]

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributor about two or three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have any Lua, template, gadget/script or similar task that would benefit your wiki? Or maybe some of your tools need better documentation? If so, and you can imagine enjoying mentoring such a task to help a new contributor, please check out mw:Google Code-in/2019 and become a mentor. If you have any questions, feel free to ask at our talk page. Many thanks in advance! --Martin Urbanec 08:28, 5 lis 2019 (CET)

Blokowanie adresów IP[edytuj]

Chciałbym zwrócić uwagę naszym administratorom, że w dużych sieciach (Orange, Plus, Cyfrowy Polsat itp.) adresy IP są zazwyczaj przydzielane użytkownikom dynamicznie. Oznacza to, że użytkownik łącząc się z siecią dostaje losowo jeden z adresów z pewnego zakresu, który to adres po pewnym czasie może zostać przydzielony innemu użytkownikowi, a dany użytkownik może po chwili otrzymać zupełnie inny adres. Oznacza to, że:

  1. długoterminowe blokowanie takich adresów nie ma sensu
  2. blokowanie użytkowników zalogowanych z takich adresów również zazwyczaj nie ma sensu
  3. trudno skutecznie zablokować jednego użytkownika (można wprawdzie zablokować całą sieć, ale to eliminuje możliwość edycji przez wszystkich potencjalnych niezalogowanych użytkowników danej sieci i jednocześnie uniemożliwia im założenie kont)

Jak sprawdzić z jakiej sieci dany użytkownik korzysta? Służy do tego baza WHOIS, którą można odpytać korzystając z różnych stron internetowych, jak np. ta (wybrałem pierwszą z brzegu; jest ich wiele). W bazie znajdują się informacje o operatorze sieci, kraju oraz, co ważne, o pełnym zakresie adresów IP danego operatora, do którego dany adres należy (operator może mieć wiele takich zakresów, ale to sprawa drugorzędna).

Od pewnego czasu MediaWiki pozwala zarówno na blokowanie całych zakresów IP, jak tez sprawdzanie wkładu użytkowników z wybranego zakresu, co pozwala administratorom podejmować decyzje o ewentualnej blokadzie. Kilka przykładów:

IP=‎37.248.155.254
Operator: Cyfrowy Polsat S.a
Zakres IP: 37.248.152.0/21 (tzn. od 37.248.152.0 do 37.248.183.255)
Edycje z tego zakresu: Specjalna:Wkład/37.248.152.0/21

Albo:

IP=2A00:F41:4894:D68C:ECE1:157E:56DB:BDE4
Operator: Orange Polska Spolka Akcyjna
Zakres IP: 2a00:f40::/29 (tzn. od 2a00:f40:: do 2a00:f47:ffff:ffff:ffff:ffff:ffff:ffff)

(niestety ten zakres jest zbyt szeroki, by odpytać o edycje z całego zakresu lub go zablokować, ale możemy po prostu wziąć fragment, do którego należy "nasz" podejrzany adres, kopiując jego początkowy fragment - dwie 16-bitowe sekcje)

Edycje z zakresu 2A00:F41::/32 : Specjalna:Wkład/2A00:F41::/32

itd.

Zdaję sobie sprawę, że większość administratorów Wikiźródeł nie jest "specjalistami od sieci", stąd powyższe wyjaśnienie. @Cafemoloko, @Bonvol, @Fallaner, @Himiltruda, @Joanna Le:@Nawider, @Salicyna, @Wieralee, @Zdzislaw: Czy uważacie, że warto zrobić w tym celu specjalizowaną instrukcję? (A może już taka gdzieś jest; na Wikipedii?).

Według mnie wandalizmy w IP nie są jeszcze u nas na tyle dokuczliwe, by blokować całe zakresy IP (utrudniając tym samym założenie kont użytkownikom z zablokowanych sieci). Ale może warto rozważyć zablokowanie edycji mobilnych przez niezalogowanych użytkowników (poprzez AbuseFilter z komunikatem typu "aby edytować załóż konto i zaloguj się"): [8] AbuseFilter bardziej obciąża serwery (choć dla ruchu z/do Wikiźródeł to nie powinien być problem), ale jest bardziej selektywny (można np. nie blokować możliwości założenia konta czy edycji na stronach dyskusji)

Uwagi, komentarze? Ankry (dyskusja) 13:21, 5 lis 2019 (CET)

Dzięki Ankry za zajęcie się sprawą. Opcja włączenia AbuseFilter dla IP-ków ze wskazaniem: zarejestruj/zaloguj się najpierw jest daleko idąca, ale na ile sięgam ostatnio pamięcią, to proporcja przyjętych edycji z IP-ków do wygłupów jest niewielka; więc ignorowanie wkładu IPków może u nas mieć rację bytu. Niemniej: czy uważasz, że liczba wandalizmów jest już u nas na tyle problemem, by szukać systemowych rozwiązań? Włączyłem też sobie gadżet "Dynamiczne adresy IP" (w Preferencjach). Bonvol (dyskusja) 14:24, 5 lis 2019 (CET)
Nie wiem. Dlatego poddaję temat pod dyskusję. Administratorów mamy w sumie sporo... Ankry (dyskusja) 16:13, 5 lis 2019 (CET)
Sądzę że na Wikiźródłach mamy do czynienia z takimi wandalizmami na tyle rzadko, że nie wiem czy nie szkoda czasu i pracy na tworzenie jakichś specjalnych narzędzi. Może wystarczy ustalenie zasady co do blokowania IP-ków, tzn. jak długa powinna być ta blokada. Ja do tej pory nr IP blokowałam jedynie na 1 dzień, ale może wystarczy na 1h? Ale w sumie to na sieci się nie znam :) Joanna Le (dyskusja) 19:00, 5 lis 2019 (CET)
Podzielam zdanie Joanna Le, że wystarczy określić mniej więcej na jaki czas zablokować dany adres, faktycznie 1 dzień wydaje się być optymalny. Do czasu kiedy ingerencje w tekst nie będą naprawdę wyzwaniem tj. bardzo bardzo mała liczba wikiskrybów lub bardzo duża liczba ingerencji to można sobie odpuścić. Bardziej mnie zastanawia @Ankry: skąd wiesz czy nowo utworzone konto np. Michał 453, Basia454 powstało w celach destrukcyjnych, można to jakoś próbować sprawdzić? Nawider (dyskusja) 21:57, 5 lis 2019 (CET)
Te które blokuję, próbowały spamować, ale zostały zablokowane przez abusefilter (patrz Abuselog). Zdaje się, że w planach jest danie abusefiltrowi możliwości blokowania takich użytkowników automatycznie. Ankry (dyskusja) 22:03, 5 lis 2019 (CET)
Trzeba ustawić $wgAbuseFilterActions['block'] aby włączyć możliwość blokowania --Wargo (dyskusja) 15:42, 6 lis 2019 (CET)
Z mojego doświadczenia: spam-boty tworzą zwykle konta o nazwach typu zlepek: NameSurname (pisane bez spacji zwykle in English, losowo wybrane ze swojej bazy danych imion i nazwisk) więc na tego typu konta trzeba zwracać przede wszystkim uwagę. Przy czym nie zawsze od razu wklejają spam, czasami mogą odczekać kilka dni... Electron Smiley kabelsalat.gif <Odpisz> 06:39, 6 lis 2019 (CET)

Nowa grupa uprawnień do celów technicznych[edytuj]

Dzisiaj, próbując odtworzyć materiały, które przeszły do domeny publicznej natrafiliśmy z Himiltrudą na problem na stronach [[9]] i następnych. Okazuje się, że aktualna wersja oprogramowania ProofreadPage uniemożliwia odtworzenie skasowanej wcześniej wersji uwierzytelnionej strony użytkownikom nie posiadającym uprawnienia "pagequality-admin", którego posiadanie pozwala użytkownikowi ignorować ograniczenia ProofreadPage dotyczące zmiany statusu strony.

Problem został zgłoszony na phabricatorze: phab:T241691. Trudno w tej chwili powiedzieć, czy zostanie to uznane za bug czy za ficzer, ani kiedy problem zostanie rozwiązany, jeśli to bug. Jak wiemy, proces poprawiania błędów w oprogramowaniu trwa zwykle miesiące.

W chwili obecnej, uprawnienia "pagequality-admin" nie zawiera żadna istniejąca grupa użytkowników, więc nie można go nikomu nadać. Z drugiej strony, jak jest wyjaśnione w phab:T167491, kiedy parę lat temu zostało ono przyznane adminom, żaden użytkownik nie powinien dysponować tym uprawnieniem "na stałe" (gdyż mógłby w niekontrolowany sposób zmieniać stan korekty stron).

W związku z powyższym, proponuję utworzenie nowej grupy uprawnień użytkowników (nazwanej roboczo "proofread-admin" lub "proofreadpage-admin" - "Administrator statusu korekty"?), która zawierałaby wyłącznie to uprawnienie i mogła być nadawana i odbierana (a) dowolnemu użytkownikowi przez biurokratę w razie uzasadnionej potrzeby, lub (b) administratorzy mogliby ją nadawać i odbierać samym sobie w razie takiej potrzeby. Uważam, ze administratorzy są odpowiedzialnymi użytkownikami i nie będą nadużywać tego uprawnienia, dlatego jest mi obojętne, który wariant zostałby wybrany. Z drugiej strony, uprawnienie to powinno być potrzebne niezmiernie rzadko. Wygląda na to, że od dwóch lat żadne Wikisource tego dotąd nie potrzebowały; jesteśmy pierwsi.

Innym możliwym rozwiązaniem jest odtworzenie stron w wersji "Skorygowana" i uwierzytelnienie ich ponownie. Jednak jestem przeciwny takiemu rozwiązaniu, gdyż uważam, że byłoby ono nie fair w stosunku do użytkowniczki, która je już wcześniej uwierzytelniła (Lilibalu).

@Ajsmen91, @Cafemoloko, @Bonvol, @Fallaner, @Joanna Le:@Nawider, @Salicyna, @Wieralee, @Zdzislaw: proszę was o opinię, co robimy w tej sytuacji: czekamy na rozwiązanie problemu (mam nadzieję) w nowej wersji oprogramowania, czy występujemy o utworzenie nowej grupy uprawnień dla obejścia problemu i, w tym wypadku, który wariant przyznawania uprawnień preferujecie: (a) czy (b). Oczywiście opinie innych użytkowników, nie-administratorów, też są mile widziane Ankry (dyskusja) 11:53, 2 sty 2020 (CET)

No i nie pingnąłem wszystkich, więc się poprawiam: @Ajsmen91, @Cafemoloko, @Bonvol, @Fallaner, @Joanna Le: @Silvanka, @Electron, @Zetzecik, @Anwar2, @Draco flavus: Ankry (dyskusja) 11:56, 2 sty 2020 (CET)
I jeszcze @Wierzbowski, @Wydarty, @Maire, @Alenutka, @Wolan: to chyba już wszyscu z OZ; przepraszam, jeśli kogoś pominąłem. Ankry (dyskusja) 11:59, 2 sty 2020 (CET)
  • Kiedyś też natknąłem się na podobny problem na innej wiki, że nie mogłem w pełni odtworzyć strony, którą przed chwilą skasowałem, bo Mediawiki nie pozwalała odtworzyć wersji sprawdzonej przez kogoś innego. W sumie to wszystko jedno jak to będzie rozwiązane byleby ktoś miał takie uprawnienia. Electron Smiley kabelsalat.gif <Odpisz> 12:12, 2 sty 2020 (CET)
  • Problem w praktyce ma miejsce jedynie na początku roku, gdy utwory trafiają do domeny publicznej. Mnie wielokrotnie samo Mediawiki przypominało, że nie mogę podbić statusu strony, bo rok temu akurat coś na niej poprawiałem i wtedy przy okazji np. skorygowałem. Obie opcje (a) i (b) są dla mnie OK - przy czym kluczowe jest, by w wariancie (b) od razu na kalendarzu nakleić kartkę "odebrać sobie uprawnienia za 2 dni". Bonvol (dyskusja) 12:21, 2 sty 2020 (CET)
    • Ja bym powiedział nawet, że za 10 min., zaraz po wykonaniu niezbędnej operacji. Jednak z drugiej strony, jeśli stronę korygowałeś, nawet rok temu, to nie powinieneś jej uwierzytelniać. Byłoby to wbrew zasadom, których chyba nie chcemy zmieniać? Ankry (dyskusja) 13:00, 2 sty 2020 (CET)
      • Oczywiście. Dałem przykład, że oprogramowanie, przez swoje walidacje dotyczące statusu, nie zmusza mnie do sprawdzania na każdej stronie "czy już ją kiedyś obrabiałem". Bonvol (dyskusja) 13:13, 2 sty 2020 (CET)
  • Symbol support vote.svg Za a i b (prędzej jeśli tylko jedno to raczej a)- Mnie osobiście to nie interesuje, ale wyobrażam sobie scenariusz taki, że któryś z nie-administratorów z żyłką porządkową i po prostu mający ochotę się tematem zająć, na początku roku dostaje takie uprawnienia i tyle. Draco flavus (dyskusja) 12:29, 2 sty 2020 (CET)
    • Nie-administratorzy nie maja prawa do usuwania/odtwarzania stron; więc w przypadku tego konkretnego problemu uprawnienie byłoby dla nich bezużyteczne (chyba, że jednocześnie otrzymaliby uprawnienia administratora) Ankry (dyskusja) 12:36, 2 sty 2020 (CET)
  • Obie wersje są wg mnie w porządku. Może dałoby się wprowadzić i a i b jednocześnie - byłoby większe pole manewru w razie potrzeby. Maire (dyskusja) 12:35, 2 sty 2020 (CET)
  • Symbol support vote.svg Za a i b (jeśli tylko jedno to raczej b), przekonuje mnie argumentacja Maire Wieralee (dyskusja) 18:43, 2 sty 2020 (CET)
  • nie jestem zwolennikiem mnożenia grup użytkowników (tu tworzenia grupy dla jednego uprawnienia), byłem zresztą przeciwny usunięciu go z grupy adminów, szkoda słów... jeżeli już to Symbol support vote.svg Za b, Zdzislaw (dyskusja) 19:46, 2 sty 2020 (CET)
    • Tu się z tobą nie zgodzę; wg mnie utrzymywanie tego uprawnienia włączonego dla jakiegokolwiek aktywnego użytkownika byłoby strasznie błędogenne i powinniśmy taką praktykę wykluczyć w naszych zasadach. Ankry (dyskusja) 22:54, 2 sty 2020 (CET)
      • cóż, przez wiele lat mieliśmy (mamy teraz ograniczone js-em) możliwość tworzenia żółtych, co jest niezgodne z naszymi zasadami, i jakoś nie zauważyłem, rezultatu starsznie błędogennego wśród edycji adminów. Zdzislaw (dyskusja) 23:55, 2 sty 2020 (CET)
        • Przy tworzeniu strony nie ma problemu sprawdzania czy się ją wcześniej edytowało. A wiem po sobie, ile razy mi się zdarzyło, że byłem przekonany, że strony nie korygowałem, tymczasem jednak... Ankry (dyskusja) 08:01, 3 sty 2020 (CET)
      • samo b też nie jest takie złe... okrężną drogą, ale można uzyskać te uprawnienia także przy pomocy biurokraty, jeśli się wykaże że projekt umarł i nie ma komu głosować w PUA. Wieralee (dyskusja) 11:08, 3 sty 2020 (CET)
  • Symbol support vote.svg Za b Nawider (dyskusja) 21:31, 2 sty 2020 (CET)
  • Symbol support vote.svg Za b Cafemoloko (dyskusja) 08:45, 3 sty 2020 (CET)
  • Symbol support vote.svg Za b Joanna Le (dyskusja) 12:23, 3 sty 2020 (CET)

Wobec wyraźnego konsensusu, zgłosiłem wniosek phab:T241824. Ankry (dyskusja) 11:45, 3 sty 2020 (CET)

Sprawa na razie upadła... i może lepiej. Po co tworzyć grupy o niejasnym przeznaczeniu? Pliki odtworzył sysadmin skryptem po stronie serwera (pewnie checkuser by się zdziwił, z jakiego to ja adresu operowałem...). Możliwość odtwarzania "zielonych" stron trzeba raczej rozwiązać systemowo, poprawiając proofreadpage, a nie łatając dziury dziwnymi uprawnianiami. Dziękuję wszystkim za udział w dyskusji i... do następnej potrzeby odtwarzania uwierzytelnionych stron. I na koniec prośba do administratorów: ostrożnie z kasowaniem zielonych. Ankry (dyskusja) 15:35, 3 sty 2020 (CET)

Brakujące znaki unicode w przyborniku[edytuj]

Przepisując Sādhanę, zauważyłam, że w części Inne litery brakuje znaków m.in. dla litery m z listy Unicode/Alfabet łaciński/Łaciński rozszerzony dodatkowy: od znaku 7742 do 7747. Brakuje też: b, k, p, v, w i innych.
Można je dodać czy obowiązuje jakieś ograniczenie?
Cafemoloko (dyskusja) 10:20, 12 sty 2020 (CET)

Litery Ḿ ḿ ḿ Ṁ ṁ Ṃ ṃ to zupełna egzotyka. Jeden-dwa teksty może na całych wź. Warto kruszyć kopie? Ja bym sobie na przykład skopiował potrzebne literki do jakiegoś dokumentu tekstowego i Ctrl-C, Ctrl-V. Bardziej fachowo by pewnie było dopisać do common.js Draco flavus (dyskusja) 10:48, 12 sty 2020 (CET)
Myślę, że kilka dodatkowych znaków w przyborniku nikomu nie zaszkodzi, a że rzadko się będą przydawać – taka już ich natura, większość ze znaków w przyborniku rzadko się przydaje. Salicyna (dyskusja) 11:15, 12 sty 2020 (CET)
Można dodać, jeśli uważasz, że warto. Z tym, że od razu dodam kilka uwag:
  1. Te znaki są dostępne dla używających tzw. nowego paska edycji (inna nazwa: edytor wikikodu 2010) z menu ("Znaki specjalne" -> "Łacińskie (rozszerzony)"
  2. Ja często takie (i inne egzotyczne) znaki dodawałem poprzez C&P ze stron Unicode, które niedawno zostrały zgłoszone do usunięcia.
BTW: diakrytyków greckich też tam nie ma, choć dużo częściej są potrzebne. Ankry (dyskusja) 11:22, 12 sty 2020 (CET)
Tutaj (greka) klawiatura Matlina jest nieoceniona Draco flavus (dyskusja) 11:28, 12 sty 2020 (CET)
Ja korzystam z brudnopisu Salicyny. Ankry (dyskusja) 11:31, 12 sty 2020 (CET)
Aha, jeśli ktoś z adminów ma ochotę jakieś znaki dodawać, to tutaj. Ankry (dyskusja) 11:33, 12 sty 2020 (CET)
To może link do Unicode/Alfabet łaciński/Łaciński rozszerzony dodatkowy w przyborniku z opisem inne znaki? Dla mnie to byłaby wygodniejsze w użyciu, a pewnie też nie każdy korzysta z z edytora wikikodu 2010. Cafemoloko (dyskusja) 11:36, 12 sty 2020 (CET)
Tak, to jest dobry pomysł. Electron Smiley kabelsalat.gif <Odpisz> 11:54, 12 sty 2020 (CET)
@Cafemoloko: Ale jaki to ma sens wobec twojej opinii w Wikiźródła:Strony do usunięcia#Unicode/Lista znaków i podstrony? Ankry (dyskusja) 12:09, 12 sty 2020 (CET)
@Ankry: Jestem za usunięciem Indeks:Unicode (HD Table) a nie Unicode/Alfabet łaciński/Łaciński rozszerzony dodatkowy. Cafemoloko (dyskusja) 12:13, 12 sty 2020 (CET)
@Cafemoloko: Mam jednak wrażenie, że zgłaszający mia inne intencje. Proponuję doprecyzowac to w dyskusji PUA. Ankry (dyskusja) 12:19, 12 sty 2020 (CET)
@Cafemoloko, @Ankry: Po usunięciu indeksu przy pozostawieniu podstron strony jak ta: Unicode/Rozszerzony łaciński A zostaną nieuźródłowione. W kategorii Unikod jest też druga grupa — takich spisów jak ten: Unicode/Alfabet łaciński/Łaciński rozszerzony A. Już współistnienie dwóch grup w tej samej kategorii wywołuje spore zamieszanie. Kolega z Wikibooks jest gotów przenieść wszystko — czyli całość kategorii — w obu formach — na Wikibooks, a więc treść będzie nadal dostępna, tylko nie tu. Bonvol (dyskusja) 19:42, 13 sty 2020 (CET)
@Bonvol: ok, to tak zróbcie. Cafemoloko (dyskusja) 20:09, 13 sty 2020 (CET)

Można też chyba skorzystać z możliwości oferowanych przez własny komputer, np. ze wstawiania znaków. Można wykorzystać edytor tekstów, gdzie powinna być opcja: „Wstaw symbol” (bądź coś podobnego) i stamtąd skopiować. Windows 10 ma też coś takiego jak „Tablica znaków”, umożliwiająca skopiowanie stamtąd znaku do dowolnego programu, w tym i do przeglądarki internetowej. Dostęp do tego jest następujący:

  • Przycisk startowy ⊞ (po lewej u dołu) > Wszystkie aplikacje > Akcesoria systemu > Tablica znaków

Po przypięciu tej Tablicy do paska ikon u dołu lub do obszaru startowego (tak się chyba te elementy nazywają) dostęp do niej jest bardzo szybki. Nie wiem, czy w innych systemach coś podobnego istnieje, ale pewnie tak, choć raczej nie w starszych wersjach. No i na tabletach / telefonach też pewnie tego nie ma. Maitake (dyskusja) 17:02, 12 sty 2020 (CET)

Kolekcja:100 książek na stulecie niepodległości i Baczyński[edytuj]

W tej kolekcji pozycja z Baczyńskim daje możliwość pobrania "ebooków", zawierających tylko stronę w przestrzeni Autor. Da się to jakoś wyłączyć czy trzeba Baczyńskiego z tej kolekcji wykreślić? --Matlin (dyskusja) 17:10, 23 sty 2020 (CET)

  • Generator ebooków pobiera metadane z szablonu {{Dane tekstu}} zamieszczonego na wskazanej stronie i dołącza do ebooka zawartość tych podstron tej strony, które są na niej podlinkowane (oraz odpowiednich podstron tychże podstron - bez głębszej rekursji) lub stron, linki do których znajdują się wewnątrz szablonu {{Summary}} (wtedy bez podstron, natomiast ze stronami objętymi tym samym szablonem na wskazanych stronach).
Zatem należy po prostu wskazać odpowiednią stronę, zawierającą te metadane. Ankry (dyskusja) 17:45, 23 sty 2020 (CET)

Indeks:PL Doyle - Tajemnica oblubienicy i inne nowele.pdf[edytuj]

Od kilku dni mam problem z załadowaniem poprawionego pliku (w oryginale: skany 223 i 224 (strony 210 i 209) są zamienione miejscami) na Commons. Być może to wina mojego wolnego łącza. Byłbym wdzięczny, gdyby ktoś z szybkim łączem wgrał ten poprawiony plik (wystarczy po prostu przestawić kolejność wymienionych stron). W razie trudności z naprawą, mogę też przesłać już poprawiony plik jako załącznik mailem (z uwagi na wielkość pliku w kilku częściach) na podany adres osoby, która by go wgrała potem na Commons. Z góry dzięki za pomoc. Electron Smiley kabelsalat.gif <Odpisz> 15:29, 5 lut 2020 (CET)

Spróbuj wrzucić poprawiony plik pod inną nazwę wizardem i podaj pod jaką, a ja je scalę. Ankry (dyskusja) 17:06, 5 lut 2020 (CET)

::To nic nie pomaga. Tak czy owak, po wgraniu ok. 60 MB przerywa upload, a że każda próba przy moim łączu zajmuje ok. 15 min. to to się staje mało zabawne :( Electron Smiley kabelsalat.gif <Odpisz> 22:50, 5 lut 2020 (CET)

@Ankry: OK. W końcu jakoś wgrałem jako nowy plik: File:PL Doyle - Tajemnica oblubienicy i inne nowele (fixed).pdf. Trzeba go połączyć ze starym: File:PL Doyle - Tajemnica oblubienicy i inne nowele.pdf. Electron Smiley kabelsalat.gif <Odpisz> 01:19, 6 lut 2020 (CET)
Gtk-ok.svg Załatwione @Electron: Ankry (dyskusja) 07:58, 6 lut 2020 (CET)
@Ankry: OK. Dzięki. Btw. Wydaje się, że ten Wizard korzysta z jakiegoś trochę innego protokołu przesyłu z informacją zwrotną i jest przez to stabilniejszy. A to ma znaczenie przy dużych plikach. Electron Smiley kabelsalat.gif <Odpisz> 12:12, 6 lut 2020 (CET)
@Electron: Korzysta z "Chunked upload" i c:Special:UploadStash. Są inne skrypty korzystające z tego mechanizmu, ale wymagają trochę zachodu by ich użyć. Możesz zerknąć do mojego common.js. Ankry (dyskusja) 13:06, 6 lut 2020 (CET)
@Electron: Dobrze wiedzieć. Dzięki za info. W wolnej chwili się tym pobawię :) Electron Smiley kabelsalat.gif <Odpisz> 13:19, 6 lut 2020 (CET)

@Electron: Napisz do mnie w takich sytuacjach, pomogę konwertować/modyfikować plik. Matlin (dyskusja) 13:32, 27 lut 2020 (CET)

@Matlin: OK. Dzięki za chęć pomocy. Będę pamiętał na przyszłość. Na razie sobie poradziłem - "Chunked upload" rzeczywiście może zdziałać cuda, nawet na takich wolnych łączach jak moje :) Electron Smiley kabelsalat.gif <Odpisz> 13:43, 27 lut 2020 (CET)

Nowy szablon do umieszczania spisów na stronach całości tekstów[edytuj]

Podaje dla informacji, że sporządziłem taki szablonik, który pomaga w tworzeniu spisów uniwersalnych, które prawidłowo działają umieszczone na stronie tytułowej i na stronie całości tekstów. Do tej pory był z tym problem, bo zwykle spis umieszczony na stronie całości prowadził linki poza tę stronę. Więcej informacji i przykład zastosowania umieszczony jest na stronie opisu {{Szablon:id sekcji}}. Electron Smiley kabelsalat.gif <Odpisz> 17:24, 25 lut 2020 (CET)

{{Dane tekstu}} a {{Nagłówek}}[edytuj]

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)

  • @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)
    • @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)
  • @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)
  • 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)
  • @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)
    • No to super! Patrząc na tę duskusję wydaje mi się, że @Electron, @Draco flavus: mogą również być zainteresowani tym tematem (żeby nie dublować rozwiązań automatyzujących pewne rzeczy). Ankry (dyskusja) 13:42, 1 maj 2020 (CEST)
  • 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 Smiley kabelsalat.gif <Odpisz> 11:37, 2 maj 2020 (CEST)
  • Jeśli chcecie wiedzieć, jak to działa, to przyjrzyjcie się jak są tworzone strony w main w fr:. Ankry (dyskusja) 09:51, 3 maj 2020 (CEST)
  • Jestem za unifikacją. Najchętniej zastąpiłabym szablon Nagłówek szablonem Dane tekstu, ale rozwiązania techniczne pozostawiam wykonującemu ;) Wieralee (dyskusja) 00:05, 20 kwi 2020 (CEST)

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)

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

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

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)

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)
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)

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)

  • 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)
    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)
    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)
  • 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)
    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)
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 Smiley kabelsalat.gif <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)

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)

  • @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)

Wiki dla tekstów PD-PL[edytuj]

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 Smiley kabelsalat.gif <Odpisz> 23:26, 15 kwi 2020 (CEST)

  • 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)
    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 Smiley kabelsalat.gif <Odpisz> 11:20, 16 kwi 2020 (CEST)
    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)
    @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)
  • @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)
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 Smiley kabelsalat.gif <Odpisz> 11:38, 17 kwi 2020 (CEST)
@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)
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 Smiley kabelsalat.gif <Odpisz> 21:57, 17 kwi 2020 (CEST)

Odezwa Wojewódzkiego Komitetu Zlotu Jubileuszowego Związku Harcerstwa Polskiego[edytuj]

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)

@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)
Zobacz teraz. Sekcja na stronie nie musi być ciągła. Ankry (dyskusja) 07:07, 26 cze 2020 (CEST)

Wersje przejrzane[edytuj]

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)

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)
Symbol support vote.svg 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)
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)
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)
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)
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)
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)
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)
  • 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 Smiley kabelsalat.gif <Odpisz> 14:24, 11 wrz 2020 (CEST)
      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)

tag <hr>[edytuj]

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)

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

Pagelist widget[edytuj]

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)

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

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

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 Smiley kabelsalat.gif <Odpisz> 10:44, 24 wrz 2020 (CEST)

Pomysł na autoprzypisy[edytuj]

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 Smiley kabelsalat.gif <Odpisz> 00:38, 1 paź 2020 (CEST)

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)
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 Smiley kabelsalat.gif <Odpisz> 12:43, 1 paź 2020 (CEST)
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)
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)
  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 Smiley kabelsalat.gif <Odpisz> 11:54, 2 paź 2020 (CEST)
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 Smiley kabelsalat.gif <Odpisz> 13:31, 2 lis 2020 (CET)
@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)
Tak coś przypuszczałem, że obejście tego byłoby dość mocożerne; czyli na razie klapa. Chyba, że przywrócą autoheading... Electron Smiley kabelsalat.gif <Odpisz> 11:45, 16 lis 2020 (CET)
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)

Dane Tekstu[edytuj]

@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):
Narrow w DT.jpg
Zdzislaw (dyskusja) 17:09, 15 lis 2020 (CET)

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 Smiley kabelsalat.gif <Odpisz> 11:39, 16 lis 2020 (CET)
@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)
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 Smiley kabelsalat.gif <Odpisz> 17:05, 16 lis 2020 (CET)
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)
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 Smiley kabelsalat.gif <Odpisz> 18:25, 16 lis 2020 (CET)
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:
Narrow w DT 1.jpg
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)
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 Smiley kabelsalat.gif <Odpisz> 12:53, 17 lis 2020 (CET)
@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)
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 Smiley kabelsalat.gif <Odpisz> 14:05, 17 lis 2020 (CET)
Dane tekstu XP.png
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 Smiley kabelsalat.gif <Odpisz> 14:29, 17 lis 2020 (CET)
@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)
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 Smiley kabelsalat.gif <Odpisz> 15:23, 23 lis 2020 (CET)
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)
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 Smiley kabelsalat.gif <Odpisz> 13:26, 25 lis 2020 (CET)
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)

Update to ICU Unicode library[edytuj]

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

Indeks do usunięcia[edytuj]

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 ([12] i [13]) 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)

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