Wikipedia:Kawiarenka/Kwestie techniczne

Dla czytelników

Pierwsze kroki

Portal wikipedystów

Zasady

Współpraca

Społeczność

Szablony

Pomoc

Wikipedyści

Komunikacja

Konflikty

Kawiarenka pod Wesołym Encyklopedystą – kwestie techniczne

Tu rozwiązujemy problemy dotyczące oprogramowania MediaWiki, botów, skryptów, technicznych zmian w szablonach itp. W celu przyspieszenia rozwiązania problemu technicznego zapoznaj się z instrukcją zgłaszania problemów.

• Błędy w oprogramowaniu MediaWiki należy zgłaszać w serwisie Phabricator (użyj formularza).
• Problemy z infoboksami należy zgłaszać na stronę Dyskusja wikiprojektu:Infoboksy.
• Spis aktualnie przeprowadzanych zmian technicznych i osób kontaktowych jest dostępny na stronie Wikimedia Product.

Obserwuj stolik • Archiwum stolika • Wszystkie stoliki • Skróty: WP:KT, WP:BAR:KT, WP:TECH

Nowy wątek

dts

Szablon {{dts}} wyświetla czerwony znacznik cały czas (inaczej niż jest to zdeklarowane w jego opisie). SpiderMum (dyskusja) 22:53, 20 wrz 2023 (CEST)

• SOA: u mnie działa ok. ~malarz pl ^PISZ 23:10, 20 wrz 2023 (CEST)
  • Np. tutaj? Ach, wait. To nie przestrzeń główna... No dobra, przepraszam, w głównej faktycznie nie straszy czerwonym. A musi w innych, że się przy okazji zapytam? :) [edytowane] SpiderMum (dyskusja) 23:26, 20 wrz 2023 (CEST)
• Według mnie dobrze by było mieć dwie podobne klasy css co "problemy" - jedna wyłącznie informacyjna, na żądanie (domyślnie ukrywana na wszystkich przestrzeniach, pokazywania po dodaniu stylu do common.css), a druga służąca typowo do zgłaszania wystąpień błędów. Przynajmniej dla dts.
  Edycja: Chociaż jak tak pomyślę, to można by też domyślnie dodać templatestyle do dts, który by robił podobną rzecz. Z drugiej strony być może takie coś przydało by się globalnie przy innych szablonach. MarMi wiki (dyskusja) 12:54, 21 wrz 2023 (CEST)
• Jeśli chcemy zawsze pokazać jakiś błąd, to nie ma sensu do tego zaprzęgać templatestyles. Wystarczy zwykły komunikat opcjonalnie owinięty w span z wyróżniającym stylem. Dla przykładu zobacz co robi {{cytuj stronę}} jeśli nie podasz url albo tytuł. Nie komplikujmy prostych rzeczy. Paweł Ziemian (dyskusja) 21:24, 21 wrz 2023 (CEST)

  Według mnie problemem (nomen omen) jest to, że błędy nie są rozróżniane od ostrzeżeń i od sugestii. Błędem jest brak url w cytuj stronę, bo strona musi mieć url. Ostrzeżeniem może być jak np. nazwa czasopisma nie jest w zestawie znanych czasopism. Natomiast to, że gdzieś jest dts jest zwykłą sugestią/informacją. Nie bez powodu w JS są trzy poziomy logowania: console.log, warn, error. Podobnie zresztą w innych frameworkach do logowania (np. en:log4j). O ile przerobienie tego pewnie nie będzie bardzo łatwe, to dobrze by było jednak wprowadzić jakieś dodatkowe klasy typu problem-info, problem-warn, problem-error (i przynajmniej kolorować odpowiednio). Nux (dyskusja) 21:32, 22 wrz 2023 (CEST)

  Test ikon/symboli:
  Ikona:
  info, ostrzeżenie, błąd
  small: info, ostrzeżenie, błąd
  Unicode:
  ⓘ info, ⚠ ostrzeżenie, 🚫/⛔/❌ błąd
  small: ⓘ info, ⚠ ostrzeżenie, 🚫/⛔/❌ błąd MarMi wiki (dyskusja) 01:56, 23 wrz 2023 (CEST)

  Tylko to akurat nie jest błąd, tylko pomoc przy określeniu czy w tabelce jakaś data przypadkiem nie została wprowadzona bezpośrednio (taka data nieprawidłowo się wtedy sortuje).
  A problem z czerwonym tekstem jest taki, że nie wiadomo co jest błędem a co informacją - patrz chociażby wątek poniżej Parametr strony = w szablonach Cytuj książkę i Cytuj czasopismo. MarMi wiki (dyskusja) 21:53, 23 wrz 2023 (CEST)

  Myślę, że te ikonki byłby OK. Nie byłoby problemów z kontrastem. I pewnie mniej kłopotliwe by to było też jakby ktoś używał Ciemnego Wektora (czy innej ciemnej edycji skórki). Unicode raczej nie, bo mimo wszystko czasem są problemy z wyświetlaniem ich jeszcze. Np. ostatnio okazało się, że przy jednej z czcionek nie wyświetlały się znaki legendy w: Szablon:Demografia powiatu#Przykład. Ale jak będą klasy w CSS, to można spokojnie użyć nawet SVG, który się będzie ładnie skalować. Nux (dyskusja) 16:32, 24 wrz 2023 (CEST)

  Ikonki czy nie ikonki – gdy nie informują o błędach, to powinny wyświetlać się wyłącznie na życzenie użytkownika (tzn. zgodnie z osobistymi ustawieniami). Tutaj tylko zaśmiecają tabelę. SpiderMum (dyskusja) 20:10, 5 paź 2023 (CEST)

  • Ale w podanym przykładzie to brak „takiej ikonki” jest błędem. Jak chcesz to rozwiązać? Paweł Ziemian (dyskusja) 21:14, 5 paź 2023 (CEST)

    Być może dałoby się odwrócić sytuację przez napisanie weryfikatora dtsów w js, który wyróżniał by tylko błędne pozycje (dtsy miałyby wtedy jakiś niewidoczny dla oka styl/klasę [albo nawet jakiś specjalny atrybut], a js by sprawdzał czy wszystkie pozycje dla danej kolumny też go/ją mają).
    Podobnie można by oznaczać dtsy znajdujące się poza tabelą (chyba że są od tego jakieś wyjątki). MarMi wiki (dyskusja) 21:26, 5 paź 2023 (CEST)

• up! SpiderMum (dyskusja) 19:20, 9 lut 2024 (CET)

Szablon „Cytuj” a numery stron zapisane cyframi rzymskimi

Szablon „Cytuj” nie dodaje w takiej sytuacji skrótu „s.” – należy dopisać go ręcznie. Czy to zamierzone działanie i czy nie dałoby się udoskonalić szablonu w taki sposób, by wykrywał również takie numery stron? Domyślam się, że takie zachowanie wynika z chęci wykrycia przypadków, kiedy w parametrze „s” jest podane coś, co nie jest numerem strony (i uniknięcia bzdur). KXLU221A (dyskusja) 15:02, 10 sty 2024 (CET)

Podanie dowolnej liczby jako wartość parametru s działa prawidłowo, tj. pokazuje nr strony w zapisie np. s. 300, gdy wartością parametru jest 300. XaxeLoled ⸤ AmA ⸣ 17:00, 10 sty 2024 (CET)

Tak to działa, dodaj s. i tyle. Wostr (dyskusja) 19:04, 10 sty 2024 (CET)

Ale czy musi tak być, z perspektywy technicznej? W trakcie edytowania łatwo nie zauważyć, że tego elementu brakuje i że trzeba coś dopisać. KXLU221A (dyskusja) 19:37, 10 sty 2024 (CET)

Czasami zamiast numeru strony podajemy numer rzymski załącznika (wkładki) do książki albo jeszcze coś innego i nie powinno się przed tym dodawać "s.". Szablon jako głupi automat nie rozróżni czy to numer strony czy coś innego. Jest w stanie rozróżnić czy podano cyfry arabskie (dodaje s.) czy coś innego (nie dodaje s.) i tyle. ~malarz pl ^PISZ 19:42, 10 sty 2024 (CET)

Rozumiem. Dziękuję za wyjaśnienie. KXLU221A (dyskusja) 17:56, 12 sty 2024 (CET)

Własny bot

Hej, wpadłem na pomysł żeby stworzyć własnego bota, który by m.in. wstawiał szablon Kontrola autorytatywna do artykułów. I teraz takie pytanie: jak bardzo stworzenie czegoś takiego w C++ przy użyciu czystego CURL jest szalone? Co sądzicie o zaproponowanej funkcjonalności bota? I czy mogę pierwsze, testowe zmiany poczynić za pomocą własnego konta (bez flagi bota), póki oprogramowanie nie jest skończone?

Pozdrawiam, Karol739 (dyskusja) 20:37, 10 sty 2024 (CET)

W C++? Moim zdaniem szalone. Polecałbym prędzej coś pokroju Javy czy Pythona (np. z użyciem biblioteki pywikibot), albo inny język, gdzie nie potkniesz się o wskaźniki i dealokację pamięci. Zresztą szablon KA wstawia już chyba bot @Peter Bowman. Msz2001 (dyskusja) 21:11, 10 sty 2024 (CET)

No cóż, pod tym względem to jestem trochę szalony :)

CURL zarządza dealokacją pamięci, wystarczy zrobić curl_easy_cleanup. Innych memory leaków raczej się nie boję. Ze wskaźnikami zbyt dużo bot nie będzie miał do czynienia.

Masz może jakiś pomysł, co jeszcze trzeba byłoby zrobić, jeśli chodzi o tego bota? Ja myślałem o likwidowaniu takich rzeczy jak "n.p" czy zamianie myślników w definicji na znak "–" i tym podobnych. Można byłoby też pomyśleć nad dodawaniem szablonu Dopracować w przypadku, gdy w artykule nie ma żadnych źródeł ani bibliografii.

Pozdrawiam, Karol739 (dyskusja) 21:43, 10 sty 2024 (CET)

Hm... No do większych zmian pewnie musiałbyś napisać parser do wikikodu z użyciem Bisona pewnie. Tu akurat C++ mógłby być zaletą... W sumie to nawet jest jakiś WikiParser dizzylogicc w C++. Do API byś musiał mieć pewnie coś do parsowania JSON-a, ale pewnie coś znajdziesz.

Co do tego czy można testować na własnym koncie -- można o ile to będą pojedyncze, testowe edycje. Właściwie to wykonanie testowych edycji jest wręcz warunkiem do dostania flagi bota. Nux (dyskusja) 21:55, 10 sty 2024 (CET)

Hm... Po co jest mi potrzebny parser wikikodu do takich prostych zmian? Wprowadzanie zmian mogę oprzeć na prostej pętli sprawdzającej warunki (np. czy nie ma takich "kwiatków" jak "n.p.") za pomocą funkcji nazwaStringu.find i potem wprowadzić zmiany za pomocą nazwaStringu.replace, a następnie CURLem dać odpowiednie dyspozycje dla serwera Wikipedii. Zbyt leniwy na to jestem, może mój kod nie będzie najpiękniejszy, ale założę się, że za pomocą ifów i prostej pętli while czy nawet, broń Boże, switch(case) i tak będzie to dość wydajne, gdyż odpada multum kodu dodawanego przez Bisona.

Aha, jeszcze jedno: dostanę flagę bez spełnienia warunku półrocznego uczestnictwa w projekcie?

Edit 22:38. Trochę się nie zrozumieliśmy, od początku chodziło Tobie o większe zmiany - takie jak zaproponował np. @Sławek Borewicz na mojej stronie dyskusji. I tutaj się zgadzamy :) Karol739 (dyskusja) 22:02, 10 sty 2024 (CET)

• Patrząc na twoją ilość "autopoprawek" w tym wątku oraz fakt, że zapis "n.p." jest często poprawny (np. w częstej frazie "n.p.m.") oraz fakt, że większość wskazanych w tym wątków pomysłów zadań jest wykonywane stale przez inne boty (@Peter Bowman, @masti i mój) to sugeruję abyś najpierw zdobył trochę więcej doświadczenia w projekcie, które przy operowaniu botem uniwersalnym się zdecydowanie przydaje. ~malarz pl ^PISZ 00:13, 11 sty 2024 (CET)

  @Malarz pl ilość autopoprawek w wątku wynika z tego, że szybciej piszę niż myślę, w związku z czym lubię wracać do swych wypowiedzi w perspektywie następnych minut lub godzin oraz poprawiać je. Dziękuję w każdym razie za podpowiedź.

  Odnośnie listy pomysłów, to w tym momencie wygląda ona następująco:

  - uzupełnianie gwiazdek w kodzie w sekcji "Zobacz też"

  - Ewentualne wstawianie szablonu Kontrola autorytatywna (nawet jeśli już taka funkcjonalność istnieje, gdyż jest to szczególnie częsty błąd na Wikipedii)

  - Wstawianie szablonu Dopracować jeśli nie ma ani przypisów, ani bibliografii, ani linków zewnętrznych

  - Poprawka "n.p." czy "n.p" na "np." oraz podobnych błędów

  - Zamiana myślników w definicji na znak "–", pogrubianie tytułu definicji jeśli ta nie jest jeszcze pogrubiona

  - Przenoszenie przypisu przed kropkę, tak żeby naprawić ewentualne błędy powstałe podczas tłumaczenia z angielskiej wersji Wikipedii.

  Nie znam się zbytnio na już istniejącej funkcjonalności botów innych wikipedystów. Rzucam jedynie pomysłami, myśląc o błędach, z którymi najczęściej spotykam się na Wikipedii. Dobrze, że istnieje kawiarenka, zawsze można te luźne idee skonfrontować z rzeczywistością. Rzeczy te po rozgryzieniu podstawowej funkcjonalności bota (logowanie, token edycji, parsing strony) przy przygotowanym szkielecie kodu zajmą może kilkanaście minut przy wprowadzaniu - takie są w każdym razie moje predykcje na ten moment. Pozdrawiam, Karol739 (dyskusja) 00:50, 11 sty 2024 (CET)

  • Poobserwuj WP:ZdB, przejrzyj tabelkę w górnej części tamtej strony. Na tym stoliku kawiarenki (i rzadziej na pozostałych) też bywają dyskutowane potencjalne nowe zadania stałe dla botów. Warto zajrzeć też do kilku podstawowych zasad na Wikipedia:Boty i zajrzeć do WP:SK (przy czym panuje konsensus, że drobnych poprawek (np. typografii) nie wykonujemy tylko z ich powodu. To powinno być zrobione przy okazji poważniejszego zadania. ~malarz pl ^PISZ 00:58, 11 sty 2024 (CET)

    Dziękuję, już widziałem ten stolik. Natomiast nie rozumiem do końca tego konsensusu. Może to dlatego, że jestem z takich, którzy nie lubią zostawiać błędów... ach, ta perfekcjonistyczna dusza...

    Pozdrawiam, Karol739 (dyskusja) 01:03, 11 sty 2024 (CET)

    W zasadzie jeśli coś faktycznie jest błędem ort./int., to możesz poprawiać.... Ale to nie jest takie proste, bo np. nie możesz nic zmieniać w nazwach plików, linkach itp. No i mógłbyś sobie na początek omijać wszystko w nawiasach kwadratowych... Ale obrazki są też np. w infoboksach. Możesz mieć też przykłady kodu i matmę a = b - c;... To jest bardziej skomplikowane niż się wydaje. Dlatego właśnie nawet do drobnych rzeczy coś w rodzaju parsera jest konieczne. Przy przeglądaniu sekwencyjnym musiałbyś mieć stany (stan wejścia w kod, wejścia w szablon itp itd). Nie jest to nie do zrobienia, po prostu trzeba uważać i dużo testować.

    Z tych zadań co napisałeś najbezpieczniejsze na początek wydaje mi się dodawanie {{Dopracować}}. To by mogło być fajne zadanie do osób które takie rzeczy potem poprawiają. Tylko byś musiał uważać ze sprawdzaniem przypisów, bo mamy nie tylko `ref`, ale też parę szablonów (głównie {{r}} i {{odn}}). No, ale to wyjdzie pewnie dosyć szybko w praniu. Jak nie będziesz robił za dużo na raz i w razie czego sprzątał za sobą, to osobiście nie widzę problemu :) Nux (dyskusja) 01:34, 11 sty 2024 (CET)

    Drobnymi poprawkami nie są poprawki błędów ortograficznych. Ale zmiana minusa na dywiz, kropki przy przypisach czy dodanie * w LZ już tak. A to jest połowa z Twoich propozycji. Ale tak jak Nux napisał, nie każdy błąd jest błędem. Nazwy plików, cytaty, zapisy w innych językach, szersze frazy (jak n.p.m.) mogą ta "błędy" zawierać. Zwróć też uwagę, że w zdaniu "Posługiwał się tytułem mgr." nie ma błędu, choć po "mgr" nie stawia się kropki bo jest to błąd. A wracając do przypisów przed kropką to czasami jednak kropka powinna być przed przypisem. Mam nadzieję, że wiesz kiedy. ~malarz pl ^PISZ 09:34, 11 sty 2024 (CET)

• sam pomysł by pisać bota od zera świadczy, że jeszcze jest na to za wcześnie. Jest wiele frameworków, z których mozna skorzystać. Nie, że się nie da. Tylko to pokazuje, że masz jeszcze małe rozeznanie w projekcie i całej otoczce poza pl.wiki. Wiele poprawek, które wydają się proste z punktu widzenia człowieka, okazuje się mocno skomplikowana z punktu widzenia skryptu zwłaszcza w języku polskim z całym jego bogactwem składniowym. A do tego dochodzi zestaw komplikatorów wikiskładni i specyficznie polskich szablonów. Dlatego zgdzam się z @malarz_pl: nabierz najpierw doświadczenia. Poszukaj co możesz wykorzystać w kodzie i zacznij jeść słonia małymi kawałkami. masti <dyskusja> 09:50, 11 sty 2024 (CET)

• @Masti może i mam za mało doświadczenia w projekcie, z tym że pomysł na napisanie bota od zera w C++ wynika z kilku powodów: 1) nie znam żadnego języka webowego (sic!), 2) nie ma zbytnio frameworków do robienia takich rzeczy w języku, który znam. Oprócz tego wraz z botem (jak dostanę flagę), to opublikuję jego kod, wtedy się dopiero przerazicie... jaki tam jest bałagan! Ale to nieważne, najważniejsze jest to, że działa (i nie psuje).
• Póki co rozgryzłem otrzymywanie tokenu do logowania jak i samo logowanie. Za chwilę zrobię ten "editing token" z https://en.wikipedia.org/wiki/Help:Creating_a_bot, a potem pobieranie wikikodu i może jakiś prosty parser do niego oparty na IFach.
• Pozdr., Karol739 (dyskusja) 11:18, 11 sty 2024 (CET)

• Trochę pokombinowałem i ciągle wyskakuje mi błąd, że podczas wysyłania zapytania o logowanie ciągle podaję zły token. Nawet te znaki "+\\" zamieniłem na odpowiedniki "%2b%5c%5c". Sprawdziłem kilkukrotnie, token na serwer idzie dobry, bot nie "zjada" żadnego znaku. Karol739 (dyskusja) 15:24, 11 sty 2024 (CET)

Funkcja eksperymentalna poprawiająca czytelność

Nowe menu w wersji nieprzypiętej, obok nazwy użytkownika

Cześć! zespół Web z Wikimedia Foundation uruchomił funkcję eksperymentalną, której celem jest poprawa czytelności artykułów. Funkcja jest dostępna tylko dla zalogowanych korzystających ze skórki Wektor 2022. Aby ją wypróbować, przejdź do zakładki "Funkcje eksperymentalne" w menu użytkownika i wybierz opcję "Ułatwienia czytania (Wektor 2022)". Można ją również włączyć na wszystkich wiki za pomocą preferencji globalnych. Aby dowiedzieć się więcej o projekcie, sprawdź stronę Dostępność do czytania.

W nowym menu (Motyw, po angielsku Theme jak na ilustracji obok) dostępne są trzy ustawienia tekstu: mały, normalny i duży. Mały jest bieżącym ustawieniem domyślnym. Duży jest przeznaczony dla użytkowników, którzy potrzebują dodatkowego powiększenia. Normalne ustawienie może później stać się domyślnym. Takie zalecenie wynika zarówno z przeglądu literatury, jak i badań społeczności.

Do menu Motyw dodaliśmy również ustawienie szerokości strony. Wcześniej było ono dostępne w dolnym rogu ekranu, a teraz jest łatwiejsze do znalezienia. Menu można przypiąć w podobny sposób jak menu Narzędzia i Główne, oba umieszczone w bocznych kolumnach interfejsu. Gdy nie jest przypięte, wyświetlane jest obok nazwy użytkownika.

Zachęcamy do włączenia tej funkcji eksperymentalnej i bardzo prosimy o opinie. Jak się wam czyta z różnymi ustawieniami? Czy jest coś, co trzeba zmienić, zanim menu Motyw będzie dostępne dla wszystkich? SGrabarczuk (WMF) (dyskusja) 16:34, 11 sty 2024 (CET)

Dostosowywanie Wikipedii do potrzeb osób niedowidzących jest słuszną inicjatywą, w tym punkcie nie mam większych uwag. Przy edytowaniu korzystam obecnie z dwóch laptopów, na mniejszym rozdzielczość to 1366 × 768 (rozmiar tekstu 100%), na większym 1920 × 1080 (rozmiar tekstu 125%). W tematyce, którą edytuję – skokach narciarskich – często wykorzystywane są tabele. W tak zwanym "normalnym" ustawieniu tekstu wyglądają one źle na większym laptopie, a katastrofalnie na mniejszym. I mówię tu o szerokim ustawieniu obszaru tekstowego (określanym przez funkcję uroczo jako szeroka szerokość), przy "normalnym" czytelność jest zła już przy małej czcionce. Od miesięcy szukam sposobów na zmniejszenie szerokości tabel w związku z wprowadzeniem nowego Wektora tak, aby przynajmniej przy szerokim obszarze tekstowym wyświetlały się poprawnie dla jak największego grona czytelników. W wikiprojekcie mamy całą dużą dyskusję o ich modyfikacji. Da się je jednak zwęzić tylko do pewnego stopnia. Wymuszone zwiększenie czcionki dla niezalogowanych przekreśli te starania i oznaczać będzie w praktyce, że tabele, na których przygotowywaniu paru z nas spędziło lata, będą dla znakomitej większości korzystających z Wikipedii nieczytelne. To smutne. Barcival (dyskusja) 11:47, 12 sty 2024 (CET)

Dzięki za komentarz, @Barcival. Poprawię tłumaczenie tej szerokości, bo rzeczywiście wygląda niezgrabnie.

Co masz na myśli przez złe/katastrofalne/poprawne wyświetlanie? Czy chodzi o to, że chcecie, żeby treść mieściła się w jednej linijce, czy jeszcze coś? SGrabarczuk (WMF) (dyskusja) 17:29, 7 lut 2024 (CET)

@SGrabarczuk (WMF) Kod, który przez lata dawał dobre wizualnie efekty przestał takie dawać i jak się dowiaduję ma być jeszcze gorzej. Dzielenie tekstu mieszczącego się wcześniej w jednej linii na wiele jest rzeczywiście głównym symptomem. Do tej pory kolejne wiersze tabel, zawierające informacje tego samego typu, miały stałą wysokość. Teraz zajmują na zmianę jedną, dwie lub trzy linijki, co czyni szybkie odczytanie z nich informacji niemożliwym. Oprogramowanie Wiki źle sobie radzi z dzieleniem tekstu w tabeli na kilka linii: na przykład zostawia puste miejsca w jednych kolumnach, równocześnie dzieląc sąsiednie, albo wyświetla tabelę podzieloną na maksymalną możliwą liczbę linii nawet gdy nadal nie mieści się ona na jednym ekranie. Barcival (dyskusja) 13:46, 9 lut 2024 (CET)

Narzędzia, które mamy do edycji tabel są bardzo ograniczone. Powinny istnieć proste sposoby na oznaczenie "tej kolumny nie dziel na linie", zamiast tego musimy używać szablonów albo spacji niełamliwych. Barcival (dyskusja) 14:26, 9 lut 2024 (CET)

• Mający problem z widzeniem standardowo zapewne korzystają przy przeglądaniu stron z "CTRL" + "+/-" do powiększania i zmniejszania obrazu na ekranie, dlatego że to funkcja uniwersalna – działająca na wszystkich stronach, a przy tym zachowująca proporcje obiektów na stronie (np. wyżej opisanych tabel, infoboksów itp.), w tym powiększająca też ilustracje. Przydałoby się badanie, na ile funkcja powiększania czcionek jest w istocie potrzebna, bo w stosunku do powiększania całego obrazu zdaje się być wtórna i mniej funkcjonalna, a istotne wady wyżej opisane ma.

Z kolei powiększenie motywu na całą szerokość ekranu powoduje u mnie stan euforyczny – dlatego na stanowisku komputerowym obstawiony jestem wielkimi monitorami, by nie musieć skupiać wzroku lunetowo na treściach i obrazach wąsko sformatowanych pod smartfony. Niestety jako bardziej twórca, a nie użytkownik, staram się formatować obraz nie w sposób wygodny, lecz zbliżony do typowego dla odbiorcy... Czuję się jednak jak koń zmuszony do chodzenia z klapkami na oczach. Kenraiz .ꓘ (dyskusja) 09:17, 13 sty 2024 (CET)

Własny bot - v2

Hej, nawiązując do wątku Wikipedia:Kawiarenka/Kwestie techniczne#Własny_bot chciałbym powiedzieć, że po wielu godzinach nieudanych testów z CURL'em postanowiłem odświeżyć swego zakurzonego Pythona (jeszcze z czasów podstawówki) i przeportować bota właśnie tam. Jako że niedługo zabierać się będę za implementację funkcji automatycznego wstawiania szablonu Dopracować do artykułów, które tego wymagają, chciałbym zapytać o radę: bot będzie sprawdzał cały artykuł w poszukiwaniu kilku elementów (stringów). Gdy ich nie będzie, wtedy wstawiane będzie Dopracować. Czy to wystarczy?

• {{r|
• {{odn|
• <ref>
• </ref>

Dodatkowo chciałbym zainspirować się pracą projektu WP:SK, zamieniając czysty szablon <references > (bez żadnych dodatków, żeby niczego nie zepsuć) na {{Przypisy}}.

Pozdrawiam, Karol739 (dyskusja) 18:52, 14 sty 2024 (CET)

Edit: A zresztą, co ja tak abstrakcyjnie będę gadać... i tak mam zamiar udostępnić kod źródłowy, więc wstawienie przykładu nie zaszkodzi:

def parse_downloaded_page():
    # Założenia wstępne
    f = open("page_temp.php", 'r')
    file = f.read()

    # Dodano: 14.01.2024. Ostatnia zmiana: 14.01.2024
    # Funkcja: dodawanie szablonu "Dopracować" w każdym artykule, w którym nie ma przypisów.
    # Algorytm szuka "śladów" przypisów, szukając następujących ciągów wyrazów: "<ref>", "</ref>", "<ref name=" "{{odn", "{{odn|", "{{odn |", "{{r|", "{{r |"
    # Szablon "Dopracować" nie będzie wstawiany, jak istnieje już jakaś bibliografia
    # Wątek z Kawiarenki: https://pl.wikipedia.org/w/index.php?title=Wikipedia:Kawiarenka/Kwestie_techniczne&veaction=edit&section=26
    if "<ref>" not in file:
        if "</ref>" not in file:
            if "{{odn" not in file:
                if "{{odn|" not in file:
                    if "{{odn |" not in file:
                        if "{{r|" not in file:
                            if "{{r |" not in file:
                                if "<ref name=" not in file:

                                    # Sprawdzanie, czy w artykule już jest szablon {{Dopracować}}
                                    if "{{dopracować|przypisy" not in file:
                                        if "{{dopracować" not in file:
                                            if "{{Dopracować|przypisy" not in file:
                                                if "{{Dopracować" not in file:

                                                    # Sprawdzanie, czy w artykule nie ma dodanej bibliografii
                                                    if "== Bibliografia ==" not in file:

                                                        # Teraz bez żalu można dodać szablon
                                                        foo()

– Karol739 (dyskusja) 20:22:30, 14 sty 2024 (CET)

Nie uwzględniłeś:

{{ Odn|Kowalski|2024}}
<ref name = 

i wielu innych wariantów. ~malarz pl ^PISZ 19:36, 14 sty 2024 (CET)

• Na pewno warto dodać datę, to chyba jest np. Dopracować|więcej przypisów=2024-01. Poza tym z tego co rozumiem z kodu (a niewiele rozumiem) to służy do identyfikacji czy w ogóle nie ma tych znaczników, a nie do sytuacji, gdy są, ale niewystarczające, rozumiem, że to pierwszy krok. Ponadto ten kod będzie zbierał artykuły z wadliwymi szablonami przypisów i przypisami np. ref otwarcie bez ref zamknięcie, dublując CheckWikipedia. PS Może zamiast szalonego if...if...if... połącz to alternatywami :D (popraw mnie jak gadam bzdury). InternetowyGołąb (dyskusja) 19:37, 14 sty 2024 (CET)
  • Dzięki za radę, zobaczę jak to zrobić. W C++ sprawa jest prosta: if((!warunek)&&(!warunek) etc, natomiast jeśli chodzi o Pythona, to będę musiał poszukać. Sam kod wymyślałem sam, nie był od znikąd kopiowany (przynajmniej ten fragment, w innych oczywiście podlinkuję przykład z MediaWiki) Karol739 (dyskusja) 20:02, 14 sty 2024 (CET)
• Moim zdaniem szukanie przez bota znacznika </ref> jest zbędne, bo już szuka <ref>, a raczej nikt nie wstawia znacznika zamykającego bez otwierającego podczas wstawiania przypisu ;-). XaxeLoled ⸤ AmA ⸣ 19:48, 14 sty 2024 (CET)
  • Jak ktoś nieumiejętnie kopiuje kod, albo coś usuwa... ląduje na check wiki. Jakby szukał tylko otwarcia, zacząłby zbierać artykuły z takimi wadami. Powinien właśnie rozumieć że ref ... /ref to przypis, a bez jednego z nich przypis wadliwy i tego nie brać do dopracować. Nowicjusze robią dziwne rzeczy z refami czasem. InternetowyGołąb (dyskusja) 19:53, 14 sty 2024 (CET)
  • Warianty do instrukcji warunkowej na ten moment: "<ref>", "<ref name=" "{{odn", "{{odn|", "{{odn |", "{{r|", "{{r |", "{{ Odn|", if "{{Odn|", " Odn |" Czy coś jeszcze przychodzi Wam do głowy? Na absurdalnie wielkiej ilości stron brakuje przypisów, więc załeżałoby mi, żeby kod ten niczego (w miarę możliwości) nie zepsuł. Karol739 (dyskusja) 20:07, 14 sty 2024 (CET)
• Hm... Normalnie nie lubię zniechęcać ludzi... Ale patrząc na ten kod... jednak będę zniechęcał do pisania własnego bota. Przynajmniej bota-bota (do wprowadzania masowych zmian). Przychylam się tym samym do wcześniejszego stanowiska mastiego i malarza. Myślę, że nie będziesz umiał prawidłowo zidentyfikować różnych przypadków. Szczerze powiedziawszy jak by mi jakiś kolega z pracy wrzucił kod do code review z tak zagnieżdżonymi ifami, to bym uznał, że mnie troluje i uznałbym to za żart. Nux (dyskusja) 20:08, 14 sty 2024 (CET)
  • @Nux zgadzam się z Tobą, że ten kod nie jest najpiękniejszy. Z tym że uwzględnić trzeba w tym momencie to, że w Pythonie programowałem ostatnio całe wieki temu (większe doświadczenie mam w C++), więc teraz przypominam sobie (i uczę się) całej masy nowych rzeczy. W każdym razie w przypadkach takich jak ten bot ręczy się własną głową, więc mam zamiar przeprowadzić wiele testów przed tym, jak bot finalnie będzie mógł cokolwiek czynić w przestrzeni głównej. Karol739 (dyskusja) 20:13, 14 sty 2024 (CET)
• Analiza struktury tekstu (XML, wikikod) na podstawie prostego wyszukiwania ciągów znaków to proszenie się o problem. Należy korzystać z dobrze przetestowanego parsera, a i tak brak jednolitego standardu wymusza wprowadzanie wyjątków; dla przykładu parser HTML, z którego korzystam, wykłada się na <ref name=a/> tylko dlatego, że zabrakło cudzysłowów wokół wartości oraz spacji przed ukośnikiem. Twój kod musi być przygotowany, aby obsłużyć < ref >, <rEf>, {{ r |..., ponadto te elementy mogą znajdować się w zakomentowanym bloku HTML, więc zostałyby wykryte przez warunki w powyższym kodzie, a nie powinny. @Karol739: radzę zajrzeć do WP:ZdB i dla treningu wykonać zadania, które nie niosą ze sobą konieczności wykonywania zmian w artykułach. Dużo zgłoszeń to generowanie list, możesz przy nich poznać strukturę stron, przygotować kod do odpowiedniego parsowania elementów, przygotować się do obsługi sytuacji wyjątkowych i ogólnie potrenować pisanie kodu dla wiki. Skok na głębszą wodę na takim etapie nie skończy się dobrze. PS: zgadzam się z Nuksem. Peter Bowman (dyskusja) 20:10, 14 sty 2024 (CET)
  • Dziękuję serdecznie za porady. Na początku mam zamiar napisać bota w ten sposób, żeby ręcznie sprawdzać każdy przypadek wykonanej przez niego pracy - tak na wszelki wypadek. Dopiero po wykonaniu kilku tysięcy zmian i uwzględnieniu praktycznie wszystkich możliwych przypadków będę mógł być pewny, że nic nie zepsuję. Karol739 (dyskusja) 20:16, 14 sty 2024 (CET)
    • Właśnie odnosząc się do przedmówców, może @Karol739 spróbuj porobić takie listy, a gdy przyjmą one sensowną postać (bez fałszywek), zamiast stawiać całego bota, można to przekazać do wikiprojektów, a potem uzupełnić to AWB, pod ludzką kontrolą. Zresztą może ktoś od razu będzie chciał poprawić. InternetowyGołąb (dyskusja) 20:19, 14 sty 2024 (CET)
      • Szczerze mówiąc, robienie list nie jest dla mnie. Lepiej chyba będzie testować bota w kontrolowanych warunkach, zatwierdzając ręcznie każdą dokonywaną przez niego edycję. Po co najmniej kilkudniowych testach mam zamiar założyć botowi osobne konto, starając się o flagę bota (ze względu na regulamin). Z racji na brak zaufania społeczności i brak doświadczenia nie łudzę się, że ją dostanę (przynajmniej teraz), ale niech regulaminom i zaleceniom stanie się zadość. W końcu na zaufanie zapracowuje się nie pięknym kodem, ale solidną (nieawaryjną) pracą. Jeszcze raz dziękuję wszystkim za cenne rady, wiele z nich będę miał przyjemność wprowadzić w życie już niedługo. Pozdrawiam, Karol739 (dyskusja) 21:02, 14 sty 2024 (CET)
      • Edit: żeby nie było wątpliwości - szablon {{Dopracować|źródła=2024-01}} wstawiany będzie, gdy spełnione zostaną wszystkie warunki naraz. -- niepodpisany komentarz użytkownika Karol739 (dyskusja)
• Mam wrażenie, że kiedyś odbyła się dyskusja przy którymś stoliku kawiarenki i automatyczne wstawienie komunikatu informującego o braku źródeł zostało uznane za zły pomysł. Nie pamiętam detali, terminu i nie potrafię podać linku do dyskusji. Jeśli się nie mylę, akceptowany był pomysł wstawienia botem komunikatu na stronę dyskusji, natomiast nie akceptowano masowego wstawienia krzykliwego szablonu w niczym nie poprawiającego artykułu, a raczej jakby przeciwnie. Szablon warto wstawiać do artykułów świeżo utworzonych lub istotnie zmienionych, gdy jest szansa, że aktywny autor zrozumie przekaz. Generalnie poza rozwiązaniem problemów technicznych, dla tego typu masowej akcji warto byłoby uzyskać akceptację w kawiarence, najlepiej nie przy technicznym stoliku, obserwowanym przez chyba najmniejszą grupę edytorów. Kenraiz .ꓘ (dyskusja) 21:56, 14 sty 2024 (CET)
  • PS. Ponieważ lata mijają nie wykluczam, że być może nadszedł czas na przebotowanie pod tym kątem artykułów. Tak czy siak sugerowałbym szersze konsultacje. Kenraiz .ꓘ (dyskusja) 21:58, 14 sty 2024 (CET)
    • Wydaje mi się, że dyskusja nie powinna iść w kierunku wstawiania tego szablonu, ale jego widoczności. Kiedyś poruszano wątek, że miał on za zadanie zwracać uwagę na braki w artykule, lecz teraz dla osób nieobeznanych z edytowaniem pełni tylko jedną funkcję - irytuje. Dlatego właśnie byłbym za domyślnym wyłączeniem jego widoczności dla osób niezalogowanych poza trybem edycji bądź też za przeniesieniem go na koniec artykułu. Dyskusja o tym zdecydowanie jest potrzebna. Pozdrawiam, Karol739 (dyskusja) 22:02, 14 sty 2024 (CET)
  • @Kenraiz, ktoś powiedział mi kiedyś, że wstawienie {dopracować} do 50k artykułów sprawi jedynie, że w kategorii Kategoria:Artykuły wymagające uzupełnienia źródeł zamiast 39 124 artykułów będzie ich po prostu 89 124. @Karol739, zgadzam się z PB, Malarzem i Mastim oraz innymi mówcami w tej i poprzedniej dyskusji. Samo botowanie dla botowania nie ma sensu, nawet niektóre zmiany, które powyżej poruszasz są w najniższej kategorii WP:Check Wikipedia, których nie zaleca się wprowadzać bez żadnych innych "większych zmian". Na Twoim miejscu zostałbym na razie przy AWB i semi-automatycznych zmianach, lub wykorzystał prostszą wersję narzędzie JavaScript Wiki Browser. Dodatkowo, jeżeli koniecznie chcesz napisać bota, to przetestuj go proszę najpierw na test.wiki, gdzie jest miejsce do takich testów. Nadzik (dyskusja) 23:10, 14 sty 2024 (CET)

Mapa lokalizacyjna w infoboxie

Mam pytanie: jak przejść do pliku mapy lokalizacyjnej będąc na stronie artykułu z inoboxem w którym jest ta mapa widoczna? Pozdrawiam Joee (dyskusja) 07:10, 19 sty 2024 (CET).

@Joee, wszystkie mapy powinny być na podstronach modułu Moduł:Mapa, dokładniej Moduł:Mapa/dane/ Aby znaleźć konkretną mapę, klikasz w edytuj w danym artykule, aby zobaczyć listę użytych szablonów i modułów (pod polem edycji trzeba kliknąć i rozwinąć Szablony użyte w tym artykule:). Wyszukujesz (lista jest alfabetyczna) frazę Moduł:Mapa/dane/... Na przykład na stronie Nowa Wieś (powiat pruszkowski) pod polem edycji masz Moduł:Mapa/dane/Michałowice (gmina w województwie mazowieckim), Moduł:Mapa/dane/Polska, Moduł:Mapa/dane/mazowieckie i Moduł:Mapa/dane/powiat pruszkowski. Wybierasz ten, który cię interesuje, a tam już masz mapę (po lewej), którą można kliknąć i przejść do Commons, np. do pliku File:Michałowice (gmina w województwie mazowieckim) location map.png. Huh, chyba nie zagmatwałem :) Hedger z Castleton (dyskusja) 09:50, 19 sty 2024 (CET)

Załatwione Nie jest to łatwe ale dzięki przykładowi udało się przejść. Nie korzystam z Edytuj tylko z Edytuj kod źródłowy więc tego nie znałem. Wielkie dzięki i pozdrawiam. Joee (dyskusja) 11:20, 19 sty 2024 (CET)

Optymalizacje szablonu i modułu Cytuj

W związku z problemami na stronie 2023 i podobnych, zastanawiam się jakie można by zrobić optymalizacje w tym module. Optymalizacje zwykle są kosztem wygody programistów, ale myślę, że to jest na tyle popularny szablon, że po prostu trzeba coś z niego wycisnąć.

Pomyślałem, że w miarę łatwo możemy załatwić przypadek, w którym w szablonie jest podany jeden, popularny język. Na pewno j. polski oraz j. ang. jako poniekąd język internetu (tak, wiem teoretycznie powinien być chiński, ale w praktyce takich przypisów nie używamy u nas). Zrobiłem mocno uproszczone oszacowania występowań języków z wyszukiwania. Jakby ktoś chciał zrobić dokładniejsze statystyki języków wg dumpa, to byłoby świetnie. W każdym razie na początek widziałbym coś w tym rodzaju (oczywiście to nie jest prawdziwy kod ;)):

• if (lang.len < 4)
  • lang="pl" or lang.startsWith("pl-") ⇒ pol. -- oszacowanie: insource:"język = pl": 95 484
  • lang="en" or lang.startsWith("en-") ⇒ ang. -- oszacowanie: insource:"język = en": 124 956
• inne oszacowania (insource z hastemplate:Cytuj):
  • de: 15 457
  • ru: 10 575
  • fr: 8 551
  • zh: 334

Jakieś inne pomysły na optymalizacje popularnych przypadków (niekoniecznie języka tylko)? CC: @Malarz pl, @Paweł Ziemian, Nux (dyskusja) 14:50, 20 sty 2024 (CET)

• Upraszczając, {{Cytuj}} korzysta z {{lang}}, tak jak pozostałe szablony cytowania i tego bym nie ruszał. Zresztą według komentarza w kodzie wygenerowanej strony obecny czas działania Lua nie osiąga 5 sekund, przy ograniczeniu do 10 sekund. To, że jakiś szablon się nie rozwinął wynika z innych ograniczeń. I najpierw trzeba by to zrozumieć i ustalić, aby wiedzieć gdzie móc ewentualnie poprawić. Z innej strony ten 2023 jest za duży. Wzorem 2021 i 2021 w sporcie przeniósłbym cały sport do 2023 w sporcie. To odchudzi artykuł o około 800 przypisów. A te nigdy dobrze się nie zachowywały, gdy ich liczba zbliżała się do tysiąca. Paweł Ziemian (dyskusja) 16:56, 20 sty 2024 (CET)

  @Paweł Ziemian Nie wiem czy patrzyłeś na diffa. Artykuł 2023 działa, bo malarz wyciął wszystkie użycia parametru "język". Nie wiem co tam aż tak zamula w tym module, ale wygląda na to, że zrobienie prostego if przed ładowaniem modułu mogłoby pomóc. Jak rozumiem to jest tutaj [1]. Może nawet samo ładowanie modułu (który ładuje kolejne moduły) jest zamulające. Nux (dyskusja) 18:46, 20 sty 2024 (CET)

  Zgodnie z Twoją sugestią wydzieliłem sport nie-światowy w 2023 i od razu też w 2024. W sumie to powinno załatwić sprawę w dużej mierze. Może niepotrzebnie kombinowałem z optymalizacją szablonów zamiast przyciąć artykuł. W sumie i tak był za długi. Nux (dyskusja) 22:02, 24 sty 2024 (CET)

• Po pierwsze sprostuję: wyciąłem nie wszystkie języki z parametrów szablonów cytowania a jedynie język polski (czyli większość). W tym artykule przekroczony był "Rozmiar dołączonych elementów po ekspansji", obecnie jest ok 50k zapasu. To jest rozmiar kodu wygenerowanego przez szablony. Sposobem na rozwiązanie problemu było zatem zmniejszenie treści wygenerowanych przez szablony, a w przypadku szablonów cytowania jedynym rozwiązaniem jest ograniczenie informacji przez nie generowanych, co jest do uzyskania przez skrócenie parametrów (tytułów, autorów) lub ich pozbycie się. Ja wyrzuciłem wszystkie www z parametrów opublikowano (czyli np. zamiast www.xxx.pl zostało xxx.pl) oraz wyrzucenie języka polskiego (bo IMO nie jest to konieczne na polskojęzycznej Wikipedii - traktujemy ten język jako domyślny). Ew. optymalizacją mogłoby być zrobienie wersji "light" szablonów, tj. takich, które nie podają na wyjściu informacji domyślnie niewyświetlanych (css: display:none;), ale nie wydaje mi się aby to był dobry pomysł. Ew. gdyby szablon wykrywał, że ma do czynienia z artykułem, który ma powyżej 500 przypisów to ..., ale wtedy zaraz możemy dojść do innych ograniczeń MediaWiki (czas działania lua, itp.). W artykułach szczególnych lepiej to zrobić po prostu rezygnując z szablonów - cytując źródło "ręcznie". ~malarz pl ^PISZ 22:31, 20 sty 2024 (CET)

  A, czyli same bajty per szablon. Ciekawe. No to faktycznie mój pomysł by w takim razie tego nie oszczędził. Co do języka pl. to jednak jest przyjęte, że go zostawiamy (była jakaś dyskusja, bo w pewnym momencie usuwałem w WP:SK). O ile pamiętam argumentacja była taka, że dzięki temu wiadomo, czy ktoś zapomniał podać język, czy faktycznie jest po polsku. Nux (dyskusja) 00:22, 21 sty 2024 (CET)

  Ja natomiast pamiętam, że dyskusje nigdy nie przynosiły żadnego konsensusu, a brak zmian w WP:SK wynikał właśnie z tego – braku zdecydowanego poparcia w jedną lub w drugą stronę (ja osobiście nie stosuję i usuwam – to jest jeden z elementów mających poprawiać dostępność stron i informować, że treść nie jest w języku domyślnym dla strony wyjściowej). Wostr (dyskusja) 13:09, 21 sty 2024 (CET)

  @Wostr tak dla ścisłości, to akurat używane tutaj <abbr> jest niezbyt dostępne [2]. Zasadniczo działa tylko dla użytkowników komputerów z myszkami, a tych jest coraz mniej. Przyjmuje się, że skróty powinny występować gdzieś na stronie w formie rozwiniętej w tekście. Co więcej nie używamy tego oznaczenia języka do dodawania atrybutu lang w odpowiednich miejscach przypisów (pewnie tytuł i autor). Nux (dyskusja) 16:57, 21 sty 2024 (CET)

  Jeśli chodzi o mobilki, to polecam {{tooltip}}, gdzie implementowałem swego czasu wsparcie dla dotyku. Nie jest perfekcyjnie, ale przynajmniej tooltip jest. Msz2001 (dyskusja) 17:23, 21 sty 2024 (CET)

  Nie chodziło mi o sam sposób prezentacji nazwy języka w zakresie dostępności, co przekazanie informacji o zmianie domyślnego języka przy przejściu na inną stronę. Informacja o przejściu z polskiego na polski to informacja żadna zwłaszcza, że to zazwyczaj każdy czytelnik określi z samego opisu bibliograficznego. Kwestia stosowania tego czy innego rozwiązania w samym szablonie {{lang}} to jest druga sprawa. Wostr (dyskusja) 23:23, 21 sty 2024 (CET)

  @Wostr obawiam się, że informacji o języku nie ma również w samym linku. Pomijając ew. domenę jeśli ktoś ma włączone czytanie URL. W gruncie rzeczy to jest teraz głównie ozdobnik i ew. info dla czegoś co by analizowało przypisy. Nux (dyskusja) 23:35, 21 sty 2024 (CET)

  Natomiast jeśli chodzi o ten język w szablonie cytowania i jego „nieużywanie” do oznaczania autora lub tytułu, to bardzo dobrze, bo on wskazuje w jakim języku jest treść cytowanego źródła. Ponadto kodów można podać więcej niż jeden jeśli źródło powiela treść w wielu językach. Treści podawane do wyświetlenia w szablonie można w tym celu owijać w {{J}}. @Nux jakbyś chciał zacytować „Quo vadis”? A takich przypadków może być znacznie więcej, zwłaszcza jeśli cytowana jest strona internetowa z [wymyślonym tytułem]. Paweł Ziemian (dyskusja) 18:01, 21 sty 2024 (CET)

  @Paweł Ziemian no tak, słusznie. Mogłyby być z tym problemy w sekcji Bibliografia. Jednak dla przypisów pewnie śmiało można by przyjąć, że nikt nie używa tam więcej niż jednego języka. Tak że dodanie w obecnych warunkach lang mogłoby być problematyczne bez jakiegoś oznaczenia szablonów poza przypisami.

  Nawiasem mówiąc „Quo vadis”, to akurat zły przykład, bo np. NVDA umie trochę w łacinę (nawet dla lang=pl). Ale wiem o co Ci chodzi :) Nux (dyskusja) 18:29, 21 sty 2024 (CET)

  Jw. Nie da się automatycznie przełożyć naszego parametru język na znaczniki określające język tytułu (a tym bardziej autorów). Nawet nie ma co próbować moim zdaniem, jest to niewykonalne. Wostr (dyskusja) 23:26, 21 sty 2024 (CET)

• Moim zdaniem to wycięcie języka skróciło tekst generowany przez szablon. Każdy język generuje <abbr>, który ma wizualnie treść krótką, jednak w środku siedzi „dymek” z długą podpowiedzią. Jedno wywołanie {{lang|pl}} to «(pol.)» czyli prawie 100 bajtów. Usunięcie tego z 220 szablonów to prawie ponad 20kB. Dodatkowo poskracał zbędne www.. Dzięki temu zabiegowi zmniejszył post-expand include size z 2097147 na 2044215, to jest o 52932 bajty, podczas gdy limit to 2097152 bajtów. O zbyt dużej liczbie szablonów można również poczytać w en:Help:Template limits. Moim zdaniem, optymalizacja mogłaby iść w kierunku całkowitego wycięcia tych statycznych dymków z kodu. To mógłby robić jakiś wbudowany gadżet wspomagający {{lang}}. Ich normalnie i tak nie widać. Przy czym prawdopodobnie oznaczałoby to również migrację kodu z Moduł:Lang/data do formatu JSON. Paweł Ziemian (dyskusja) 22:20, 20 sty 2024 (CET)

  Przy czym warto zaznaczyć, że usunięcie www. z opublikowany oznacza jedno: w tym parametrze są rzeczy, których tam być nie powinno. Z nieznanych przyczyn w pl.wiki rozpleniła się ta maniera, która jest nieobecna w jakichkolwiek systemach tworzenia opisów bibliograficznych, aby podawać nazwę domeny internetowej... (a obok i tak jest pełny URL, który w wersji drukowanej powinien być podawany jawnie, a nie jako link). Jest to już niestety nie do wyplenienia z pl.wiki, ale jest to zwyczajny błąd, tyle że przez wielu akceptowany jako prawidłowe wypełnienie szablonu. Wostr (dyskusja) 23:32, 21 sty 2024 (CET)

  Obok jest pełny URL, ale tylko w kodzie. W wersji mobilnej, ani w aplikacji nie widzisz linka przed tapnięciem. Drukowanie obawiam się wyszło z mody znacznie przed dominacją internetu przez urządzenia mobilne. Nux (dyskusja) 23:38, 21 sty 2024 (CET)

• Wpadł mi do głowy taki pomysł na ewentualne przyszłe życzenie społeczności do zaimplementowania w MediaWiki. Skoro przypisy są ważne, to szablony rozwijane w tagach <ref>...</ref> mogły by mieć swój oddzielny i niezależny post-expand limit. Najlepiej większy niż dla zwykłej treści. Nie mam zielonego pojęcia czy to w ogóle jest technicznie możliwe. Teoretycznie wydaje się proste. Toć to tylko alternatywny niezależny licznik. Jednak nie wiem jak to działa w rzeczywistości. Paweł Ziemian (dyskusja) 21:29, 24 sty 2024 (CET)

Sprzątanie kodu

O ile pamiętam, kiedyś SK zamieniało linki do redirów na poprawne. A dzisiaj tego nie zrobiło :(

Coś powinienem kliknąć, zaznaczyć albo odznaczyć gdzieś? Ciacho5 (dyskusja) 23:00, 22 sty 2024 (CET)

A nie chodzi czasem o gadżet disFixer? Msz2001 (dyskusja) 23:06, 22 sty 2024 (CET)

@Ciacho5 musisz mieć włączony podgląd strony przy edycji. Wtedy sk znajduje przekierowania w nim i może je podmienić. Nux (dyskusja) 00:38, 23 sty 2024 (CET)

Nowa funkcja do podglądu przypisów na waszej wiki

Cześć! Zgodnie z zapowiedzią sprzed kilku tygodni^[1][2], zespół Życzeń Technicznych Wikimedia Deutschland wdrożył Podgląd przypisów (Reference Previews) na wiele wiki, w tym tę. Funkcja ta pokazuje dymki z treścią przypisów w czasie czytania artykułu.

Funkcja ta jest co prawda dostępna na waszej wiki, ale większość osób jej nie widzi, ponieważ włączony domyślnie jest gadżet replikujący to zachowanie. Zalecamy, by gadżet ten przestał być domyślnym. Będzie to oznaczało, że:

• Domyślnym źródłem dymków po najechaniu na przypis będzie wbudowany w oprogramowanie Podgląd przypisów.
• Jednak, gdyby któryś z użytkowników chciał nadal korzystać z gadżetu, może go sobie włączyć w Preferencjach, w sekcji Gadżety (opis: Podgląd przypisów (Reference Tooltips): wyświetla tekst przypisu w dymku po najechaniu myszką na odnośnik, dzięki czemu nie trzeba się odrywać od treści artykułu.).

Zaletą korzystania z Podglądu przypisów jest spójność doświadczenia użytkowników pomiędzy poszczególnymi wiki oraz z Podglądem stron. Ponadto, ułatwi to utrzymanie i konserwację oprogramowania.

Jeśli wasza wiki chce dokonać wspomnianej zmiany, możecie to zrobić samodzielnie lub poprosić nasz zespół o pomoc, najlepiej do 12 lutego. Pozdrowienia, Johanna Strodt (WMDE), 10:40, 23 sty 2024 (CET) (tłumaczenie: Msz2001 (dyskusja) 21:04, 29 sty 2024 (CET); oryginalny komentarz)

Zgodnie z powyższą sugestią, zmieniłem opcje gadżetu Reference Tooltips, który realizował do tej pory podgląd przypisów, tak by nie był już domyślnie włączony. Nie ma potrzeby ładować u użytkowników (w tym czytelników) dwukrotnie kodu do obsługi tego samego. Jeśli ktoś nie zmieniał opcji pokazywania podglądu, najprawdopodobniej nie zobaczy różnicy. Gdyby zaś ktoś chciał włączyć sobie ten gadżet z powrotem, może to zrobić w Preferencjach, w sekcji Gadżety. Msz2001 (dyskusja) 21:04, 29 sty 2024 (CET)

Logo z WD do infoboksów

Niedawno gładko przeszło tu Wikipedia:Kawiarenka/Kwestie_techniczne#Grafiki_z_WD_do_infoboksów. Proponuję dodać również pole "logo" do {{Instytucja infobox}}. @Nux --Chrumps ► 00:32, 27 sty 2024 (CET)

"czy też" a sprzątanie kodu

Któreś z narzędzi do sprzątania kodu nagminnie wstawia przecinek przed "czy też" (nawet kiedy to sformułowanie pełni funkcję spójnika). Wskazana naprawa. 2A00:F41:34A1:88A6:C06D:5E43:7A3D:7346 (dyskusja) 21:42, 29 sty 2024 (CET)

• Bez jakiegokolwiek linku do takiej zmiany (najlepiej diffa) trudno jest wróżyć o co chodzi. ~malarz pl ^PISZ 21:50, 29 sty 2024 (CET)
  • Okej, oto winowajca: Wikipedysta:Beno/wp_sk.js. 37.47.163.212 (dyskusja) 00:01, 30 sty 2024 (CET)
    • Tego skryptu należy używać z uwagą, zawsze sprawdzać podgląd. InternetowyGołąb (dyskusja) 10:51, 30 sty 2024 (CET)
      • Dobrze jest. "Czy też" należy interpretować jako wtrącenie, w rozumieniu np. "jak również". W rzadkich przypadkach, raczej tylko w beletrystyce, ma funkcję zwykłego spójnika charakterystycznego w tym momencie dla mowy potocznej. Takie (spójnikowe) użycie nie powinno mieć miejsca w wydawnictwie leksykalnym z powodu braku zwięzłości, jednoznaczności i zwykłej lakoniczności wypowiedzi. Jeżeli więc komuś nie podoba się przecinek przed "czy też", to po pierwsze powinien się zastanowić, dlaczego przecinek tam jest i w nielicznych sytuacjach zmienić "czy też" na zwykłe "czy" albo "i". Dodam, że zwykłe "czy" jest nadużywane, bo powinno odnosić się do wyliczeń nieenumeratywnych (wymienianie kilku rzeczy z ich większej liczby). Statystycznie w przeważającej większości przypadków mój skrypt wstawia te przecinek dobrze. W nielicznych przypadkach cała fraza powinna być przeredagowana. Beno (dyskusja) 11:20, 30 sty 2024 (CET)

Nowa wersja Wikiploy 2.0

Cześć. Wydałem nową wersję Wikiploy oraz nowy, przykładowy gadżet z Wikiploy. Nowa wersja pozwala szybciej przygotować nowy gadżet i ogólnie jest lżejsza, a jednocześnie ma nadal to samo programistyczne API (więc dla tych co używają Wikiploy wystarczy zmienić numerek w swoim package.json). Pozdrawiam i udanych eksperymentów :) Nux (dyskusja) 22:33, 10 lut 2024 (CET)

Template Data

Zacząłem dorabiać opisy TD do niektórych zaawansowanych szablonów. Pierwszy na warsztat poszedł {{reprezentacja}}. Nie znalazłem możliwości dodania opisów do sugerowanych wartości. Istnieje mechanizm ukrywania nazw parametrów i przydałby by się podobny mechanizm ukrywania rzeczywistych wartości parametru dyscyplina. Wybór z listy pomiędzy bbk, fauk czy fb nie jest prosty :-(.

Jeżeli nie ma takiego mechanizmu, to może warto spróbować namówić na niego osoby decydujące nad rozwojem MW. Tu by się przydała sugestia gdzie uderzać. ~malarz pl ^PISZ 00:22, 14 lut 2024 (CET)

• To jest ciekawy przypadek również dla ogólnych szablonów cytowania. Występuje w nim ewidentnie słownikowy parametr język. Jednak z tą różnicą, że można w nim podawać więcej niż jedną wartość, jeśli języków jest więcej niż jeden. Mamy też wiele szablonów LZ, które podobnie skracają linki do identyfikatorów. Paweł Ziemian (dyskusja) 20:47, 14 lut 2024 (CET)

Kłopot z lokalizacją w szablonie Fb map

Cześć, pojawił się kłopot z mapką Fb map, która dotyczy lokalizacji klubów w danej lidze. Chciałbym stworzyć nowy sezon z nowymi uczestnikami. Kopiuję więc z starego hasła:

Kopiuję mapę z już istniejącego hasła:

Fb map|nt=10|map=POL|label=Lokalizacja klubów grających w Ekstralidze 2020/2021 |1=Górnik Łęczna Kobiet |2=Medyk Konin |3=Czarni Sosnowiec |pos3=top |4=AZS UJ Kraków |5=UKS SMS Łódź |6=GKS Katowice Kobiet |7=Olimpia Szczecin |8=Śląsk Wrocław Kobiet |pos6=bottom |9=KP Bydgoszcz |10=Rolnik Biedrzychowice |pos10=top |11=APLG Gdańsk |12=TS ROW Rybnik |pos12=left}}

2) Chcę zmienić punkt 7, więc nowa wersja w nowym haśle:

Fb map|nt=10|map=POL|label=Lokalizacja klubów grających w Ekstralidze 2023/2024 |1=Górnik Łęczna Kobiet |2=Medyk Konin |3=Czarni Sosnowiec |pos3=top |4=AZS UJ Kraków |5=UKS SMS Łódź |6=GKS Katowice Kobiet |7=Pogoń Szczecin Kobiet |8=Śląsk Wrocław Kobiet |pos6=bottom |9=KP Bydgoszcz |10=Rolnik Biedrzychowice |pos10=top |11=APLG Gdańsk |12=TS ROW Rybnik |pos12=left}}

I właśnie przez ten punkt 7 wczytuje się mapka z błędem o koordynatach. Klub posiada już hasło w kategorii szablonu.

1923 (dyskusja) 22:11, 15 lut 2024 (CET)

@Malarz pl, czy to się nie ma trochę z Twoją propozycją co do tej rodziny szablonów? Jeżeli osobny temat, to wybacz proszę niepotrzebny ping. Nadzik (dyskusja) 22:43, 15 lut 2024 (CET)

Z ciekawości. Jaka to propozycja? Jest gdzieś streszczenie? 1923 (dyskusja) 23:02, 15 lut 2024 (CET)

• Wiąże się o tyle, że dotyczy częściowo wspólnych szablonów. Natomiast w obecnej chwili chciałbym jedynie usunąć 3 szablony, które są moim zdaniem zbędne i więcej przeszkadzają bo są nadużywane. Docelowo najlepiej by było wszystkie je usunąć bo są m.in. skuteczną zaporą dla nowych/młodych (z krótkim stażem) edytorów jak 1923. Tutaj problem dotyczył szablonu {{Fb team Pogoń Szczecin Kobiet}}, który poprawiłem (technicznie). Nie wiem czy w nim nie ma innych błędów bo jest on praktycznie niewykorzystywany. A Nadzik wspominał o dyskusji przy innym stoliku kawiarenki: Szablony {{Fb}}, {{Vb}} i {{Hb}}. W tej dyskusji rzeczywiście padła propozycja skasowania szablonu {{fb map}}, ale nie z mojej klawiatury. ~malarz pl ^PISZ 23:20, 15 lut 2024 (CET)

  Zadziałało! :) Możesz zdradzić co tak naprawdę poprawiłeś? Ten sam problem pojawia przy innych klubach, a z tego co widzę po historii zmiany w tym konkretnym szablonie, to... nie dodałeś żadnego nowego znaku/bajta? 1923 (dyskusja) 23:51, 15 lut 2024 (CET)

  • Poprzestawiałem kilka znaków, które były podane w złej kolejności. Czy są prawidłowe - tego nie wiem, ale kolejność była ewidentnie zła. ~malarz pl ^PISZ 23:54, 15 lut 2024 (CET)

    Przetestowałem kluby, z którymi miałem problem, najprostszą możliwą metodą. Skopiowałem szablon Pogoni z twoimi poprawkami, zmieniłem tylko nazwy i dane lokalizacyjne. Wstępnie: wchodzą elegancko bez błędu, z którym tutaj przyszedłem. Dziękuję!

    Podsumowując: problem pojawił się najwidoczniej przez złą kolejność znaków, którą ustawiali pierwotni twórcy szablonu z klubem. Z racji, że nie był one wykorzystywane, błąd nie został wcześniej zauważony. 1923 (dyskusja) 00:07, 16 lut 2024 (CET)

Wiadomości techniczne: 2024-08

Najnowsze wiadomości ze środowiska technicznego Wikimedia. Poinformuj innych użytkowników o tych zmianach. Nie wszystkie zmiany będą dotyczyć ciebie lub twojej wiki. Dostępne są tłumaczenia na inne języki.

Ostatnie zmiany

• U osób z zaznaczoną opcją „Wyślij do mnie e‐mail, gdy strona lub plik z mojej listy obserwowanych zostaną zmodyfikowane”, edycje botów nie będą już powodowały wysyłki e-maili. Wcześniej powiadomienia nie wywoływały jedynie edycje oznaczone jako drobne. [3]
• Zaszły zmiany w sposobie ładowania skryptów użytkownika i całej strony w Wektorze 2022 na niektórych wiki. Dotknęło to następujące wiki: wszystkie projekty ze starym Wektorem jako domyślną skórką oraz Wikipodróże i Wikibooks. Inne projekty zostaną dotknięte w ciągu najbliższych trzech miesięcy. Nie ulega zmianie sposób wczytywania gadżetów. Jeśli zostaliście dotknięci aktualizacją albo chcecie zmniejszyć jej wpływ na swój projekt, zajrzyjcie do zadania na Phabricatorze. Zachęcamy do podjęcia działań z wyprzedzeniem.
• Nowe automatycznie tworzone konta lokalne (tzn. kiedy odwiedzasz daną wiki po raz pierwszy) będą miały takie same ustawienia powiadomień, jak konta zakładane na danej wiki. Dotyczy to czterech rodzajów powiadomień, wskazanych w opisie zadania na Phabricatorze.
• Maksymalny rozmiar pliku, przy przesyłaniu Kreatorem przesyłania plików, wynosi teraz 5 GiB. [4]

Zmiany w tym tygodniu

• Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 20 lutego, na stronach innych niż Wikipedia i niektórych Wikipediach od 21 lutego, a następnie na wszystkich wiki od 22 lutego (harmonogram). [5][6]

• Wybrane narzędzia, działające na silniku Grid, zostały zatrzymane w ramach przygotowań do wyłączenia tego silnika 14 marca br. Ich kod i dane nie uległy usunięciu. Jeśli utrzymujesz jedno z tych narzędzi i chcesz je uruchomić ponownie, odezwij się do zespołu. Wyłącznie te narzędzia, których właściciele poprosili o wydłużenie czasu mogą nadal działać.
• Właściwość CSS filter może być teraz używana w atrybutach HTML style w wikikodzie. [7]

Wiadomości techniczne przygotowane przez redaktorów Tech News i wysłane przez bota • Dołącz do zespołu • Przetłumacz na swój język • Uzyskaj pomoc • Wyraź swoją opinię • Subskrybuj lub zrezygnuj z subskrypcji.

MediaWiki message delivery 16:34, 19 lut 2024 (CET)

Załatwione, ~Cybularny^{Napisz coś ✉} 16:36, 19 lut 2024 (CET)

Błąd w przypisach

Równina Niemodlińska. To chyba jakiś ogólniejszy błąd, bo w artykule nie widzę błędu. Stok (dyskusja) 15:27, 21 lut 2024 (CET)

• {{odn}} sam już wstawia znaczniki ref. Jak był w dodatkowych to ... Zrobione. ~malarz pl ^PISZ 15:57, 21 lut 2024 (CET)

Data publikacji/aktualizacji w przypisie

Jeżeli źródło internetowe ma podaną datę publikacji i obok datę aktualizacju – to którą z nich wpisujemy wparametrze "data" szablonu Cytuj stronę? Widzę, że w dyskusju szablonu @Jojnee bezskutecznie o to pytał w 2015. BasileusAutokratorPL (dyskusja) 14:19, 22 lut 2024 (CET)

Ja wstawiam datę aktualizacji - bo wersje mogły się różnić merytorycznie, więc trzeba by je porównać, a nie zawsze będzie dostępne archiwum pierwszej wersji.
Poza przypadkami, gdy z jakiegoś powodu pierwsza data/wersja publikacji jest istotna (ale wtedy zapewne była by o tym mowa w tekście do którego jest przypis). MarMi wiki (dyskusja) 17:20, 22 lut 2024 (CET)

Skoro zgodnie z opisem szablonu, parametr data odpowiada za datę publikacji, to moim zdaniem wpisujemy tam tąże. AramilFeraxa (Napisz do mnie!) 17:30, 22 lut 2024 (CET)

Nawet jeśli to, co potwierdza przypis, zostało dodane dopiero w aktualizacji - np. jakieś sprostowanie, czy poprawa błędu merytorycznego (np.: literóka w dacie - 16 zamiast 26, czy podanie błędnego nazwiska - Kowalski zamiast Nowak)? MarMi wiki (dyskusja) 17:42, 22 lut 2024 (CET)

Masz wtedy 3 daty: utworzenia (np. 22 lutego 2024), aktualizacji (np. 20 marca 2024) i datę dostępu (np. 1 stycznia 2025). Data dostępu w szablonie Cytuj stronę mówi Ci o tym, jaka dnia 1 stycznia 2025 była treść przedstawiona w artykule utworzonym dnia 22 lutego 2024 (czyli aktualizacja z 20 marca 2024 jakby automatycznie się w tym zawiera i nie trzeba jej powielać w szablonie). Tak przynajmniej ja przez całe lata to rozumiałem. :D Gabriel3 (dyskusja) 17:53, 22 lut 2024 (CET)

Przykład: Britannica podaje na stronie hasła datę ostatniej aktualizacji, czy to znaczy że trzeba wchodzić w historię edycji i zamiast niej podawać datę opublikowania danego hasła?
Ja przez datę opublikowania rozumiem datę, w której dana informacja się pojawiła, a nie tylko i wyłącznie pojawienie się danego nagłówka prasowego / hasła w encyklopedii, do którego później została dopisana (choć data publikacji nagłówka potrafi być przydatna przy ewentualnym szukaniu linku w archiwum). Dla uproszczenia podaję więc datę aktualizacji, żeby nie trzeba było ustalać za każdym razem daty dodania.
Dodane w późniejszej edycji: To trochę tak, jakby podawać datę pierwszego wydania książki, chociaż treść mogła zostać dodana dopiero w późniejszych edycjach. MarMi wiki (dyskusja) 18:27, 22 lut 2024 (CET)

No ale jeśli napiszesz artykuł między opublikowaniem strony internetowej ze źródłem a jej aktualizacją? Czyli - pozwól, że posłużę się moim przykładem - między 22 lutego a 20 marca 2024? Wtedy jeśli po utworzeniu artykułu nie wracasz już do niego (a są osoby, które tak robią, ubolewam nad tym), to maleją szanse na zauważenie aktualizacji w źródle tak czy siak. Źródło będzie wtedy aktualne z dnia daty dostępu. :( Dlatego czasem nawet w niektórych książkach, jeśli w bibliografii są podane strony internetowe, to dodaje się datę dostępu. Gabriel3 (dyskusja) 19:02, 22 lut 2024 (CET)

Nie bardzo rozumiem czemu odnosisz się do daty dostępu (która raczej nie budzi wątpliwości). Jeśli w czasie wstawiania przypisu nie ma daty aktualizacji, to oczywiste jest że wstawia się datę opublikowania (wraz z datą dostępu)?
No chyba że w rzeczywistości (albo w 2015) szablon Cytuj stronę przyjmuje tylko jedną z tych dat (opieram się na dokumentacji ze strony szablonu, z której wynikałoby że można wstawiać obie daty). MarMi wiki (dyskusja) 14:14, 24 lut 2024 (CET)

Myślę, że to trochę dwie różne rzeczy, a z drugiej strony podobne. Z jednej strony w wypadku książek podaje się datę wydawania i to jest data konkuretnej aktualizacji. A z drugiej strony mamy artykuły, które powstały w określonym momencie i opisują wydarzenia z punktu widzenia danego momentu... Może zatem to zależy czy aktualizacja podaje nowy stan faktyczny, czy tylko poprawia literówki. W wypadku Britannica pewnie to jest nowy stan faktyczny (a przynajmniej próba podania stanu faktycznego na dzień aktualizacji). Nux (dyskusja) 20:21, 24 lut 2024 (CET)

Zdecydowanie data publikacji (i oczywiście dostępu) jest najważniejsza. Źródła i strony internetowe bywają aktualizowane, a aktualizacje mogą nawet nie zostać zauważone. Gabriel3 (dyskusja) 17:34, 22 lut 2024 (CET)

Zgadzam się z Gabrielem. Data aktualizacji wcale nie musi być podana w artykule, więc to czy się jej użyje jest w pewnym stopniu bez znaczenia. Od tego jest właśnie data dostępu, żeby np. potem szukać wg daty dostępu w WebArchvie itp. Innymi słowy to data dostępu mówi o tym w jakim stanie widzieliśmy daną stronę. Nux (dyskusja) 19:27, 22 lut 2024 (CET)

Swoją drogą jakby jakiś bot chciał uzupełnić daty dostępu wg daty wstawienia danego ref, to byłoby super 😉 (ułatwiłoby to ratowanie starych ref) Nux (dyskusja) 19:29, 22 lut 2024 (CET)

Fajny pomysł, ale mało realny do realizacji. Pewnie dałoby radę zrobić w {{cytuj}}, ale niestety sporo linków jest gdzieś wstawionych bezpośrednio. Mój może szukać diffa do wstawienia, ale musisz jakoś określić dla których linków ma to robić i jak wskazywać wynik swojej pracy. Już do robi dodając datę do {{fakt}} i {{dopracować}}. Podobnie szuka w historii usuniętych przypisów i je przywraca. ~malarz pl ^PISZ 19:38, 22 lut 2024 (CET)

podstrona archiwum

Kawiarenka techniczna ma dwie podstrony:

• ogólną stronę archiwum (link)
• i archiwum z grudnia 2023 (link)

Z tą stroną grudniową są jakieś problemy - ma dziwny wygląd. W dwóch miejscach pojawia się szara ramka (i zmieniony wygląd czcionki):

• miejsce 1 - pomiędzy sekcją 7 (Autoportret z paletą (obraz Anny Bilińskiej-Bohdanowiczowej)) oraz Podział Czy-wiesza na podstrony
• miejsce 2 - od parser szablonów do końca strony

Być może jakąś wskazówką będzie jeden z linków z ogólnej strony archiwum - ten z tytułem:

• 7 (Autoportret z paletą (obraz Anny Bilińskiej-Bohdanowiczowej))

Po kliknięciu na niego:

• po pierwsze pojawia się informacja że: Nie znaleziono tego wątku, pomimo że taki fragment na stronie już jest,
• a po drugie widać, że ten fragment jest częścią innej, wspomnianej już sekcji: Podział Czy-wiesza na podstrony

91.198.177.99 (dyskusja) 18:01, 22 lut 2024 (CET)

Dokonałem jakichś tam poprawek wespół z @Malarz pl. Winny był znacznik <pre>, który nie był do końca prawidłowo powstawiany. XaxeLoled ⸤ AmA ⸣ 18:11, 22 lut 2024 (CET)

Załatwione, ~malarz pl ^PISZ 18:13, 22 lut 2024 (CET)

tabele w artykułach

W wybranych artykułach są na górze po prawej różne tabele (szablony) - np:

• Stany Zjednoczone (link)
• A.F. Modrzewski (link)
• litera A (link)

W tabelach tych, odległość między kolejnymi wierszami (na wysokość) jest jakaś większa, niż była jeszcze nie tak dawno temu (luty 2024, a przynajmniej styczeń 2024). Było to sprawdzane na różnych i aktualnych przeglądarkach.

Czy jest to jakiś błąd, czy jest to jakaś techniczna zmiana? Jeśli to drugie, to:

• kto to zmienił i gdzie?
• czy są gdzieś o tym podane jakieś informacje?
• jest to zmiana czasowa (testowa), czy trwała?

91.198.177.99 (dyskusja) 18:34, 22 lut 2024 (CET)

Załatwione Zmieniły się style ogóle w MediaWiki (<p> dostały padding na dole) i skutkiem ubocznym było rozepchnięcie infoboksów. Naprawiłem to, usuwając padding dla akapitów w infoboksach. Msz2001 (dyskusja) 18:44, 22 lut 2024 (CET)

Chyba działa. A z ciekawości - wiesz może, gdzie dokładniej było to zmienione? 91.198.177.99 (dyskusja) 18:59, 22 lut 2024 (CET)

Gdzie to zostało zmienione, to nie wiem, ale dałoby się znaleźć w spisie commitów. Natomiast naprawiłem tutaj: Specjalna:Diff/72947658. Msz2001 (dyskusja) 21:17, 22 lut 2024 (CET)

Pytanie

Czy mógłby ktoś zweryfikować, czy ta strona: https://pl.wikipedia.org/wiki/Dyskusja_wikipedysty:ZwierzK została wcześniej usunięta? Dziwne jest lekko, że nie istnieje (i że nie znajduje się na niej choćby witajka). Dziękuję i pozdrawiam, Karol739 (dyskusja) 21:06, 22 lut 2024 (CET)

Nie została usunięta, co widać w rejestrze: [8]. Możliwe że 10 lat temu bot od witajki był skonfigurowany inaczej (ja w dyskusji też nie miałem witajki). Załatwione Msz2001 (dyskusja) 21:13, 22 lut 2024 (CET)

Wait a sec... Rzeczywiście data utworzenia konta to 2015. Dzięki bardzo, nawet nie wiedziałem o takim błędzie :) Karol739 (dyskusja) 21:15, 22 lut 2024 (CET)

To nie błąd. Po prostu automat działa od 2016 roku. Wcześniej działał Wikipedia:Komitet powitalny, który nie wszystkie konta wyłapywał. ~malarz pl ^PISZ 21:24, 22 lut 2024 (CET)

Wszystko jasne. Dziękuję za wyjaśnienie i pozdrawiam, Karol739 (dyskusja) 21:26, 22 lut 2024 (CET)

Błędne wyświetlanie SVG w infoboxie

W artykule Rozkład F Snedecora plik .svg z dystrybuantą w infoboxie wyświetla się niepoprawnie – tekst jest przesunięty i nakłada się na pozostałe elementy. Mam nadzieję, że da się to replikować, bo u mnie problem występuje na kilku urządzeniach i przeglądarkach. Po otwarciu ilustracji wszystko wraca do normy. Czy to może jakiś błąd na poziomie szablonu? Epsilon598 (dyskusja) 13:10, 25 lut 2024 (CET)

Hmm... widzę, że złowiłem ciekawy problem. Dziękuję za obejście, na pewno jest lepiej, choć dwa zielone nie są idealne. Epsilon598 (dyskusja) 20:19, 25 lut 2024 (CET)

To jest błąd po stronie Commons i tego, jak renderuje pliki SVG. Jeśli się zażąda tego obrazka w niektórych rozmiarach (zapewne tych, dla których nie ma żadnej wersji w pamięci podręcznej), to niestety tekst się ustawia tak dziwnie. Zgłosiłem to na Phabricatorze, my lokalnie nic na to nie poradzimy. Msz2001 (dyskusja) 13:38, 25 lut 2024 (CET)

Nie żebym nie wierzył w szybkie poprawki na phabie ;), ale akurat z tekstem w SVG to pamiętam różne problemy przez lata. W każdym razie zrobiłem obejście. Nux (dyskusja) 18:20, 25 lut 2024 (CET)

Związki chemiczne według pierwiastków/Wykaz/Błędy

Czy to na pewno powinno być w przestrzeni głównej? Raczej nie. Wzywam nieaktywnego ostatnio: @Miner? Może @Malarz pl, bo dużo edycji Twojego bota? :) A sam wykaz rzeczywiście jest ency? Kryterium jest istnienie w Wikipedii. Lista jest jakoś tam przydatna, jednak czy tak to powinno wyglądać? Emptywords (dyskusja) 22:35, 25 lut 2024 (CET)

@Saper ^ PMG (dyskusja) 22:59, 25 lut 2024 (CET)

• 1. IMO to nie jest artykuł. 2. Edycje mojego bota były częścią długotrwałej wojny botów ;-). ~malarz pl ^PISZ 00:09, 26 lut 2024 (CET)