Przejdź do zawartości

Wikipedia:Kawiarenka/Kwestie techniczne

Skrót: WP:KT
Z Wikipedii, wolnej encyklopedii
To jest stara wersja tej strony, edytowana przez Nux (dyskusja | edycje) o 01:47, 19 sty 2023. Może się ona znacząco różnić od aktualnej wersji.
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.

Obserwuj stolikArchiwum stolikaWszystkie stoliki • Skróty: WP:KT, WP:BAR:KT, WP:TECH



Zły zapis daty w przypisach

"16 listopada 2022" jest prawidłowym zapisem daty w języku polskim, więc komunikat "zły zapis daty dostępu" jest absurdalny. Eurohunter (dyskusja) 17:17, 16 lis 2022 (CET)[odpowiedz]

Wiele formatów dat jest poprawnych, ale nie wszystkie są przyjazne do maszynowego przetwarzania... A gdzie masz taki komunikat (w jakim polu, w jakim edytorze...)? Nux (dyskusja) 17:25, 16 lis 2022 (CET)[odpowiedz]
@Nux Błąd wyświetla się w przypisach zarówno w podglądzie jak i zapisanej wersji. Komunikat wyświetla się na końcu przypisu i co ciekawe zgłasza tylko "daty dostępu" pomijając parametr daty i daty archiwizacji. "nie wszystkie są przyjazne do maszynowego przetwarzania" - na ENWP z powodzeniem używa się "16 November 2022", więc raczej nie ma tutaj problemu. Eurohunter (dyskusja) 17:43, 16 lis 2022 (CET)[odpowiedz]
A chodzi o artykuł w przestrzeni głównej czy jakiś poza nią? Konkretne przykłady? Screeny? tufor (dyskusja) 17:53, 16 lis 2022 (CET)[odpowiedz]
  • Od początku istnienia2014 w dokumentacji szablonu {{cytuj stronę}} siedzi w nim informacja, że data dostępu ma być podawana w formacie RRRR-MM-DD. I tak w większości przypadków była i jest podawana. Pozostałe wywołania stanowiły około 5% (ale to i tak były grube tysiące) i po dyskusji w barze większość z nich sprzątnąłem botem w imię spójności wyglądu przypisów. To co zostało ląduje w kategorii technicznej Szablon cytowania – zły zapis daty dostępu. Stare szablony nie ingerują w format zapisu tego parametru. To co jest podane jest wyświetlane. Aby zwrócić na to uwagę dodałem sprawdzanie, czy podawana data pasuje do formatu wskazanego w jego dokumentacji. Paweł Ziemian (dyskusja) 17:56, 16 lis 2022 (CET)[odpowiedz]
    • @Paweł Ziemian Kto w ogóle zapisuje daty w formacie RRRR-MM-DD? Amerykanie? 10-10-2010 to powinno być minimum. "To co jest podane jest wyświetlane" - dlaczego nie ma tego w szablonie cytuj stronę? Kto będzie zmieniał całą datę w kilkudziesięciu przypisach podczas tłumaczenia artykułu? Eurohunter (dyskusja) 18:53, 16 lis 2022 (CET)[odpowiedz]
      • Format RRRR-MM-DD jest praktycznie jedynym formatem, który łatwo przekształcić w inny z pomocą funkcji #time. Ponadto jest to zapis zgodny z ISO. Trudno go nie zrozumieć. Zapis odwrotny już nie jest jednoznaczny. Zwłaszcza, że często widywałem angielską notację M/D/Y. Jeśli D w tym zapisie nie przekroczy 12 to nie wiadomo o co chodzi. To znaczy myślimy, że wiemy o co chodzi ale możemy być w błędzie. W dodatku separator / bywa w tym zapisie zamieniony na kropkę, myślnik lub pauzę. Paweł Ziemian (dyskusja) 19:30, 16 lis 2022 (CET)[odpowiedz]
        • @Paweł Ziemian MM-DD-YYYY jest używany w Stanach Zjednoczonych, nie Wielkiej Brytanii i to owszem jest mylące, ale ten problem będzie istniał niezależnie od formatu daty używanego w PLWP. To co jest obecnie na PLWP - oczywiście nie trudno jest to zrozumieć, ale według mnie to jest zapisywanie daty "od tytułu" i zawsze w sytuacji dodawania daty mam myśl, że muszę dodać datę od tyłu... Taki format daty kojarzy mi się raczej z niechlujstwem tak jak pisanie "dnia 15 marca 2022". Na dodatek w podpisach używamy "normalnego" formatu daty DD-MM-YYYY. Eurohunter (dyskusja) 21:34, 16 lis 2022 (CET)[odpowiedz]
          Format y-m-d był przez wiele lat domyślnym formatem w Windows. Jeśli dobrze pamiętam to od Windows 95 aż do Windows 8 (wiem, bo w bibliotekach w Polsce taki format jest normą). Jest to też format ISO (norma międzynarodowa) i polska norma (PN). Nie wiem o co chcesz tu kruszyć kopię. Jeśli wpisujesz datę ręcznie to format ISO jest łatwiejszy do wpisania. Jeśli używasz do przypisów automatu, to on zawsze używa formatu ISO. Nux (dyskusja) 21:57, 16 lis 2022 (CET)[odpowiedz]
          Sprawdziłem. Nawet jeszcze w pierwszych, polskich, wersjach Windows 10 format ISO był domyślnym formatem daty. Tak czy inaczej na pewno miałeś taką datę wpisaną przy zegarku na większości Windowsów/komputerów z których korzystałeś. Minęło ledwie 6 lat odkąd d.m.y stał się domyślny w Windowsach. Nux (dyskusja) 22:21, 16 lis 2022 (CET)[odpowiedz]
          @Nux W bibliotekach czy ogólnie w pismach urzędniczych równie często błędnie jest pisane "dnia 4 marca 2020", więc na to bym się nie powoływał. Co ciekawe są w tym bardzo uparci... Co do Windowsa masz rację, ale jest tam wiele niespójności nawet w Win 11. Może tłumaczący mieli takie same podejście jak w urzędach... Idąc dalej ile razy w mediach słyszysz z ust dziennikarzy i innych osób "tą grę" albo źle wymawianą nazwę roku po 2000 (od 2001)? Eurohunter (dyskusja) 23:02, 16 lis 2022 (CET)[odpowiedz]
          Tak się składa, że robię oprogramowanie dla polskich bibliotek i mamy większość rynku. I wiem jakiego formatu używają biblioteki w swoim oprogramowaniu ;) Nux (dyskusja) 23:08, 16 lis 2022 (CET)[odpowiedz]
  • @Paweł Ziemian, @Eurohunter, @Nux, @Muzyk98, @Beno: A tak przy okazji tej dyskusji, może zmienilibyśmy format wyświetlanej daty dostępu w szablonie {{cytuj}} z [dostęp RRRR-MM-DD] na zwykły polski, np. [dostęp DD.MM.RRRR] lub [dostęp DD MIESIĄCA RRRR]? Nie widzę uzasadnienia do wyświetlania daty w formacie ISO, zamiast w formacie zgodnym z polskimi normami językowymi. Michał Sobkowski dyskusja 22:54, 16 lis 2022 (CET)[odpowiedz]
I jeszcze tu: https://sjp.pwn.pl/poradnia/haslo/zapis-daty;10340.html Michał Sobkowski dyskusja 23:29, 16 lis 2022 (CET)[odpowiedz]
  • Zacznijmy może od szablonu Cytuj, który najpewniej i tak stopniowo wyprze stare szablony specjalistyczne. Z tego co widzę, to szablon Cytuj świetnie sobie radzi z różnymi formatami daty, także z tymi odmiennymi od ISO:
  • data = 2022-11-11 | data dostępu = 2022-11-11: Test [online], 11 listopada 2022 [dostęp 2022-11-11] [zarchiwizowane z adresu 2013-07-17].
  • data = 11.11.2022 | data dostępu = 11.11.2022: Test [online], 11 listopada 2022 [dostęp 2022-11-11] [zarchiwizowane z adresu 2013-07-17].
  • data = 11 listopada 2022 | data dostępu = 11 listopada 2022: Test [online], 11 listopada 2022 [dostęp 2022-11-11] [zarchiwizowane z adresu 2013-07-17].
Chodzi tylko o to, żeby zmienić format wyświetlania daty dostępu (i archiwizacji). Interpretację danych wejściowych szablon już teraz robi (i daje radę!) dla różnych formatów wejściowych. Jeśli po zmianie wynik miałby być nieoczekiwany, to przecież i obecnie jest nieoczekiwany. Nic się pod tym względem by nie zmieniło. Michał Sobkowski dyskusja 23:29, 16 lis 2022 (CET)[odpowiedz]
Przede wszystkim rrrr-mm-dd jest również polskim formatem daty. Jest to nawet podane w linku poradni PWN, który wrzuciłeś ;). Ale format ISO można stosunkowo łatwo skonwertować. Mam wątpliwości czy warto, ale można. Jeśli już to raczej z nawą miesiąca chyba. Nux (dyskusja) 23:40, 16 lis 2022 (CET)[odpowiedz]
Jest polskim formatem daty, ale dla celów "technicznych", nie w tekstach do czytania. Muzyk98 (dyskusja) 23:42, 16 lis 2022 (CET)[odpowiedz]
Przez ponad 20 lat ISO było używane standardowo również do wyświetlania dat w ok. 90% komputerów w Polsce... W każdym razie tak jak wspomniałem i tak jak pisał Paweł można skonwertować tą datę, ale powinna być wprowadzona do danych w formacie ISO. Nawet przeciwnicy tego formatu przyznają przecież, że jest właśnie do zastosowań technicznych ;-). Osobiście nie podzielam opinii, że ISO trudno się czyta. Mi się czyta bardzo dobrze - na początku są najważniejsze informacje. Dla starych przypisów liczy się dla mnie z którego roku były te przypisy, a nie z którego miesiąca czy tym bardziej dnia... No, ale to jest dyskusja typu de gustibus...
Data powinna być zapisana jako ISO (ze względów technicznych). Powinna być wprowadzana przez kalendarz (tego VisualEditor jeszcze niestety nie oferuje, ale to raczej kwestia czasu). Data powinna być ostatecznie wyświetlana zgodnie z ustawieniami danego użytkownika (tego nie mamy, ale jeśli zapis będzie jednolity, to będzie się dało to zrobić). Nux (dyskusja) 00:30, 17 lis 2022 (CET)[odpowiedz]
@Nux Format RRRR-MM-DD powinien być rozpoznawany, ale format DD-MIESIĄCA-YYYY również powinien być rozpoznawany, a oba powinny być wyświetlane jako DD-MIESIĄCA-YYYY, ewentualnie jak ktoś chce inaczej to powinien mieć opcję wyboru w ustawieniach. PLWP powinna rozpoznawać nawet całe przypisy zapisane w języku angielskim i wyświetlać je w języku polskim, czyli tak jak jest w innych wersjach Wikipedii. Nie pamiętam dokładnie, ale chyba na FRWP jak wstawisz przypis z ENWP to FRWP go rozpozna i wyświetli normalnie w języku francuskim (rozpoznaje angielski kod). Eurohunter (dyskusja) 20:19, 17 lis 2022 (CET)[odpowiedz]
@Eurohunter w sumie to {{cytuj}} łyka różne daty, tak jak byś tego oczekiwał, a zestaw jego podstawowych parametrów jest identyczny jak dla {{cytuj stronę}}. Z czego wynika Twój sentyment do starego szablonu? Paweł Ziemian (dyskusja) 22:50, 17 lis 2022 (CET)[odpowiedz]
Nie wiem, być może to dziwne, ale osobiście preferuję te stare szablony, przynajmniej pod względem kosmetycznym. Estetycznie „Cytuj” wydaje się dość przekombinowany, zwłaszcza gdy w grę wchodzą linki do archiwum. Po prostu jest w nim za dużo różnie poformatowanych elementów – być może chodzi o ich kolejność, kursywę użytą w tym, a nie innym miejscu... (w każdy razie coś gryzie w oczy, trudno mi określić co dokładnie). A tak nawiasem mówiąc, w „Cytuj” brakuje parametru „adres rozdziału”, który z kolei jest zawarty w „Cytuj książkę” (i w tym drugim nie potrzeba robić żadnych akrobacji z parametrem rozdział). Na enwiki wszystkie szablony prezentują się schludnie i mają wszystkie potrzebne parametry, a tutaj właśnie czasem czegoś brakuje lub coś subtelnie zgrzyta. No i zdarza się, w jednym haśle występują różne szablony z różnymi formatami (co widać np. w datach) -- czy jest jakiś powód, dla którego nie ujednolicono chociaż wyglądu omawianych szablonów? 2A00:F41:385A:EB5A:F0B8:3320:6B05:34D7 (dyskusja) 00:12, 18 lis 2022 (CET)[odpowiedz]
@Paweł Ziemian Już zapomniałem, że był nowy szablon. Coś w nim było nie tak, ale już nie pamiętam co. W Szablon:Cytuj tylko data jest wyświetlana jako 5 lipca 2019, natomiast data dostępu jest wyświetlana jako "2022-01-24". Eurohunter (dyskusja) 16:50, 18 lis 2022 (CET)[odpowiedz]
Jakże niezwykle merytoryczny komentarz... coś było nie tak, coś zgrzyta, czegoś brakuje, coś gryzie w oczy. Z pewnością te rzeczy zostaną niezwłocznie poprawione. O, już coś zostało poprawione. Wostr (dyskusja) 18:45, 18 lis 2022 (CET)[odpowiedz]
No, w „Cytuj” brakuje parametru „adres rozdziału”. A co do tego, że coś gryzie, to wydaje mi się, że szablon nadużywa formatowania (przykładowo: kursywa zarówno w tytule rozdziału, jak i w tyle książki; kursywa w tytule strony internetowej (który jednocześnie wyświetla się niebiesko, więc jest dostatecznie wyróżniony). Dlatego preferuję „Cytuj książkę” i „Cytuj stronę”, które używam za prostsze, a zarazem bardziej estetyczne. 2A00:F41:3890:B401:2C42:441E:9013:34CD (dyskusja) 18:52, 19 lis 2022 (CET)[odpowiedz]
Zanim powstał nowy szablon były uwagi, że pozostałe za bardzo się od siebie różnią. Nowy powstawał w wyniku długich dyskusji przy założeniu, że będzie podobny do pozostałych. Stąd między innymi takie formatowanie dat w zależności od jej kontekstu. Był też głos, że nowi nie potrafią poprawnie wypełniać szablony cytowania, bo mają za dużo parametrów i nie wiedzą co cytują. Dlatego w nowym nie ma wszystkiego, lecz tylko to co najważniejsze i najczęściej używane. Paweł Ziemian (dyskusja) 18:41, 18 lis 2022 (CET)[odpowiedz]
  • Szablon {{cytuj stronę}} jest znacznie bardziej popularny więc często będzie występował obok {{cytuj}}. Będzie ładniej jeśli różne szablony będą stosowały takie same formaty daty na wyjściu. Opracowuję w brudnopisie odpowiedni kod dla starych szablonów. Paweł Ziemian (dyskusja) 23:37, 16 lis 2022 (CET)[odpowiedz]
    • Przypomniałem sobie jeszcze, że #time ma ograniczenia ilościowe na przetwarzanie danych. Limit to 6000 znaków. Patrząc na daty takie jak 31 października 2022 to możemy tę funkcję wywołać 300 razy. Dla zapisu ISO liczba ta wzrośnie do 600. Istnieją jednak artykuły, w których przypisów jest więcej. To już mi pachnie błędami parsera, które nawet teraz się zdarzają w różnych większych artykułach. W {{cytuj}} rozwiązałem ten problem w ten sposób, że nie korzystam z systemowych funkcji obsługi dat lecz napisałem własne, które są wolne od tych ograniczeń. Paweł Ziemian (dyskusja) 22:50, 17 lis 2022 (CET)[odpowiedz]
      • Na ENWP nie ma takich problemów? Tam bez problemu dodasz 700 przypisów z datami "31 October 2022" w czterech parametrach. Eurohunter (dyskusja) 16:44, 18 lis 2022 (CET)[odpowiedz]
        • Pewnie nie stosują #time w przypisach. Wyświetlają daty tak jak są podawane. Nie zaglądam w kod ich przypisów. U nas też pewnie nie trzeba by z tego korzystać, gdyby do szablonów podawać każdą datę podzieloną na 3 składniki. Jednak wygoda, że data to jedna data kosztuje. Paweł Ziemian (dyskusja) 18:41, 18 lis 2022 (CET)[odpowiedz]
Nie spodziewałem się, że ktoś może chcieć używać innego formatu daty niż ISO (tym bardziej w zastosowaniu czysto technicznym jakim jest kod szablonu) i że może z tego wyniknąć tak duża dyskusja. Moim zdaniem data w szablonach cytowania powinna być zawsze wpisana w formacie ISO (po coś te standardy są), tym bardziej, że w dokumentacji każdego szablonu jest dokładnie opisane jakiego formatu daty ten szablon oczekuje. A to, jak się będzie ta data wyświetlać, może zależeć od ustawień użytkownika.
Zalety formatu RRRR-MM-DD: spójność i brak problemów z interpretacją, w porównaniu ze słownym zapisem miesiąca - brak potrzeby tłumaczenia z/na inne języki i dużo mniejsza podatność na literówki.
Takie pytanie (eksperyment myślowy) do osób uważających zapis RRRR-MM-DD za pisany od końca: Dlaczego zapisujecie godziny od końca, zamiast zacząć od sekund, potem podać minuty, a godzinę na końcu? ;)
Szablon:Cytuj_odcinek - tutaj tylko w jednym miejscu jest podany format daty dostępu inny niż RRRR-MM-DD (zapewne przeoczenie)
Szablon:Cytuj_pismo tutaj data dostępu i data w dokumentacji ma format ISO, ale zakresy dat już podane są z nazwą miesiąca w przykładach: 1-2 grudnia 2018 r. Zakresy dat też właściwie można by zapisywać w ISO np. 2018-12-01 - 2018-12-02 i wyświetlać zgodnie z preferencjami użytkownika, ale to już jest bardziej skomplikowane.
A poza tym gadżet refTools (przycisk Cytuj) sam dodaje dzisiejszą datę dostępu w odpowiednim formacie po wybraniu opcji Strona WWW. Ololuki (dyskusja) 18:39, 19 lis 2022 (CET)[odpowiedz]

Zmiana struktury HTML nagłówków na stronach dyskusji

W najbliższym czasie zamierzam wprowadzić na plwiki zmianę konfiguracji, która spowoduje zmiany w strukturze HTML nagłówków na stronach dyskusji. Obecnie dodatkowe metadane (np. liczba komentarzy – widoczne dla osób, które włączyły funkcję eksperymentalną „Narzędzia dyskusji”, lub które można zobaczyć tutaj: [1]) wstawiane są wewnątrz znacznika nagłówka <h2>, co utrudnia nawigację edytorom korzystającym z czytników ekranowych. Po zmianie nagłówki otoczone zostaną nowym znacznikiem <div>, wewnątrz którego wstawiane będą również metadane.

Nie powinno mieć to żadnego wpływu na działanie stron dyskusji, ale może okazać się, że jakieś gadżety itp. nie będą kompatybilne z tą zmianą, więc ogłaszam ją wcześniej na wszelki wypadek. Zamierzam wprowadzić zmiany w najbliższy wtorek, 29 listopada. Naprawię potem ewentualne problemy z gadżetami, jeśli tylko jakieś zauważę lub jeśli ktoś je zgłosi.

W przyszłości te same zmiany będą wprowadzone również na wszystkich innych projektach. (Powiązany bug na Phabricatorze: T314714.) Matma Rex dyskusja 19:15, 24 lis 2022 (CET)[odpowiedz]

Zrobione. Wstępnie nie widzę żadnych problemów. Matma Rex dyskusja 22:57, 29 lis 2022 (CET)[odpowiedz]
Moje replinki działają bez zmian jak do tej pory, więc chyba wszystko dobrze :). Pozdr. Nux (dyskusja) 23:43, 4 gru 2022 (CET)[odpowiedz]

Szablon cytuj wyświetla tylko ostatnią literę autora gdy autor wpisany jest małą literą

Gdy w szablonie {{cytuj}} wpiszemy w polu autor jakiś tekst małą literą (np. nazwę użytkownika, będącego autorem wpisu na blogu) to wyświetli się tylko ostatnia litera, np (z sonifikacja, autor = schedel):

l, Sounds of Science: The Mystique of Sonification [online], Sounding Out!, 9 października 2014 [dostęp 2022-11-29] (ang.).

W tym konkretnym przypadku można poprawić na Margaret Schedel, ale ogólnie chyba jest to błąd w szablonie cytuj. Ololuki (dyskusja) 19:42, 30 lis 2022 (CET)[odpowiedz]

To nie jest błąd, po prostu kod uznaje to za imię, jak jest imię i nazwisko, to szablon wyświetla pełne nazwisko i pierwszą literę z kropką. W takim przypadku należy pisać autor = *schedel lub autor = "schedel". Pozdrawiam Joee (dyskusja) 07:42, 1 gru 2022 (CET).[odpowiedz]
Wyświetlanie wyłącznie ostatniej litery nie wygląda na normalne zachowanie, tylko skutek pójścia parsera w maliny. Myślę, że warto się temu przyjrzeć i poprawić albo udokumentować, tym bardziej, że szablony {{cytuj stronę}} i {{cytuj książkę}} nie mają problemów z autorem pisanym małymi literami i wyświetlają całość poprawnie.
@Julo [2] W dokumentacji szablonu {{cytuj}} stoi: "gwiazdka - odradzane [...] może powodować problemy jeśli w nazwie są przecinki, stąd łatwiej zwykle używać cudzysłów". (Informacyjnie - w tym wypadku nie ma to znaczenia.) Ololuki (dyskusja) 00:24, 2 gru 2022 (CET)[odpowiedz]
  • Tak samo, jeśli autorem jest organizacja (np. Jad Waszem), to też pierwszy człon nazwy jest uznawany za imię i pojawia się inicjał. Żyrafał (Dyskusja) 23:27, 3 gru 2022 (CET)[odpowiedz]
    A jak niby szablon/moduł ma rozpoznać czy to organizacja, czy imię i nazwisko?
    Wprawdzie można pewnie zrobić jakąś listę/bazę najpopularniejszych organizacji, ale czy warto, jak wystarczy to przebotować wstawiając gwiazdkę (jeśli uzbiera się duża liczba takich autorów)? MarMi wiki (dyskusja) 23:42, 3 gru 2022 (CET)[odpowiedz]
    Szablon nie jest w stanie tego rozpoznać, ale źle to wygląda. To już lepiej używać zwykłego cytuj stronę itd., bo tam tego problemu nie ma. Ewentualnie zrobić osobne pola, gdy autorem jest osoba i osobne, gdy jest to organizacja. Żyrafał (Dyskusja) 02:20, 4 gru 2022 (CET)[odpowiedz]
    Po prostu wpisujesz | autor = "Nazwa Organizacji" i tyle. Nie ma sensu dodawać kolejnego parametru, bo to tylko bardziej komplikuje system. Co szablon powinien zrobić jak będzie miał wypełnione pola dla autora osobowego i autora organizacji na raz? ~malarz pl PISZ 13:20, 4 gru 2022 (CET)[odpowiedz]
    Można i tak, ale jest to raczej rzadko stosowane rozwiązanie. Żyrafał (Dyskusja) 02:46, 6 gru 2022 (CET)[odpowiedz]
    W:Malarz pl wyraził to jednoznacznie Nie ma sensu dodawać kolejnego parametru. Żadnych wodotrysków nie montować w tym użytku. Jest więcej przypadków niż powyżej wskazane, gdy europocentryczne przyzwyczajenia do imię= i nazwisko= zawodzą i właśnie parametr autor= obsługuje je wszystkie zadawalająco. Przykładowo osoby świeckie po przyjęciu stanu zakonnego już nie mają nazwiska a struktura azjatyckiego imienia duchowego autora publikacji może być rozmiaru zdania. Indu ( विकिपीडिया ) 03:32, 8 sty 2023 (CET)[odpowiedz]
    Ten cudzysłów był dokładnie po to, żeby obsłużyć autorów instytucjonalnych. Właściwie ma to sens tylko w wypadku oficjalnych dokumentów. Ale przy okazji cudzysłowem można obsłużyć różne nietypowe przypadki. Jakby co jest to też opisane w TD i w sekcji Szablon:Cytuj#Autorzy. Nux (dyskusja) 03:49, 8 sty 2023 (CET)[odpowiedz]

Tłumaczenie nowych stron - jak wyłączyć irytujący komunikat

Jak - kategorycznie i na zawsze - wyłączyć pojawianie się komunikatu "Tworzenie nowych stron poprzez tłumaczenie jest teraz prostsze! Czy chcesz wypróbować narzędzie Tłumaczenie Treści (beta)?"? Temat był już poruszany, ale rozwiązanie nie działa - za każdym razem klikam "Nie, dziękuję" i mimo to przy kolejnym kliknięciu w czerwony link ten komunikat pojawia się ponownie. Ololuki (dyskusja) 22:33, 3 gru 2022 (CET)[odpowiedz]

Możesz to wyłączyć w preferencjach. Wchodzisz na stronę Specjalna:Preferencje#mw-prefsection-betafeatures i odznaczasz "Tłumaczenie treści" masti <dyskusja> 22:35, 3 gru 2022 (CET)[odpowiedz]
Niestety bardziej odznaczyć już się nie da, bo nie jest zaznaczona. Paradoksalnie jak zaznaczę tę opcję to irytujący komunikat przestaje się pojawiać. Problem w tym, że nie chcę mieć tej funkcji załączonej ani jej używać. Ololuki (dyskusja) 23:17, 3 gru 2022 (CET)[odpowiedz]
Napisałem skrypt klikający w anuluj (wystarczy wkleić w odpowiednim pliku .js Pomoc:Personalizacja - porady dla zaawansowanych):
// zamknij irytujący komunikat "Tworzenie nowych stron poprzez tłumaczenie jest teraz prostsze! Czy chcesz wypróbować narzędzie Tłumaczenie Treści (beta)?"
// teoretycznie po kliknięciu anuluj komunikat powinien zniknąć na dłuższy czas, bo tworzone jest ciasteczko cx_campaign_newarticle_hide ważne 300 dni, ale z jakiegoś powodu często się ono traci.
jQuery( document ).ready( function() {
    var cancelPopup = document.getElementsByClassName( 'mw-ui-button mw-ui-quiet cancel' );
    if (cancelPopup.length == 1)
        cancelPopup[0].click();
} );
Ololuki (dyskusja) 22:50, 6 sty 2023 (CET)[odpowiedz]

VE nie wyświetla szablonu wstawionego za tekstowym linkiem

VE nie wyświetla szablonu wstawianego za tekstowym linkiem (link wstawiony jako zwykły tekst bez żadnego formatowania), zamiast tego dodaje na końcu linku %5B%5D.
Przykład:
http://www.ecowaters.org/products.html{{martwy link}} MarMi wiki (dyskusja) 13:55, 4 gru 2022 (CET)[odpowiedz]

Zmiana poziomu nagłówków w Poczekalni

Cześć. Okazuje się, że narzędzia dyskusji działają tylko na drugim poziomie nagłówków. Mi osobiście brakuje głównie subskrypcji w Poczekalni. To znaczy chciałbym mieć powiadomienia z konkretnej dyskusji, a nie z całego stolika. Przez stolik mam na myśli np. to: Wikipedia:Poczekalnia/kwestie techniczne. Najwyższy poziom można by zmienić na poziom 1, a dyskusje byłby na poziomie 2.

Mógłbym się zająć zmianą poziomu nagłówków w stolikach poczekalni, ale pytanie, czy są jakieś obiekcje do tego? Coś by trzeba poprawić poza narzędziem "Zgłoś do usunięcia"? (też mogę poprawić). Jakieś boty by się zepsuły? Nux (dyskusja) 22:06, 4 gru 2022 (CET)[odpowiedz]

  • Poczekalnia działa na osobnych podstronach - można obserwować zatem pojedyncze wątki. Nie używam nowych narzędzie dyskusji więc nie wiem czy to ma podobną funkcjonalność do tego co piszesz. Co do mojego bota, który robi kilka zestawień + archiwizuje poczekalnię to jak będziesz gotowy daj znać na 24h przed zmianą abyśmy mogli je zsynchronizować. ~malarz pl PISZ 09:04, 5 gru 2022 (CET)[odpowiedz]
    • OK. To wstępnie w czwartek ok. 22:00 bym zmieniał, chyba że jakieś veto/wątpliwości się pojawią.
    • Co do tego jak to działa, to różnica jest taka, że w obserwowane trzeba wejść i widać tylko ksywkę ostatnio edytującego. Przy subskrypcji dostaje się zbiorcze powiadomienia (np. "3 osoby wypowiedziały się w wątku Abcd") i dodatkowo po wejściu na wątek podświetlają się wypowiedzi. Można też oznaczać jako przeczytane z poziomu listy powiadomień. Całkiem wygodne, polecam :).
    • Nux (dyskusja) 13:42, 5 gru 2022 (CET)[odpowiedz]
      • Bot archiwizujący działa codziennie ok 3-4 rano, więc jakby się dało wcześniej (1800-2000) to będzie więcej czasu na potestowanie lub na sen :-)
      • Ja widzę wszystkie edycje w obserwowanych a nie tylko ostatnią :-) Można to sobie jakąś opcją włączyć. ~malarz pl PISZ 15:00, 5 gru 2022 (CET)[odpowiedz]
  • Ej, byłem pierwszy z postulatem na ZB! IOIOI2 23:43, 5 gru 2022 (CET)[odpowiedz]
    @IOIOI Wielkie umysły myślą podobnie ;). A serio, to potrzebujesz tam jakiejś pomocy czy coś? Tam chyba łatwiej, bo wystarczy przez regexp zmienić. Jedynie może gadżet z formularzem by trzeba też poprawić. Nux (dyskusja) 02:11, 6 gru 2022 (CET)[odpowiedz]
    W sumie to potrzebuję wiedzieć, czy mogę to zrobić. IOIOI2 07:30, 6 gru 2022 (CET)[odpowiedz]
    Musisz tylko zsynchronizować zmianę na stronie ze skryptami tam działającymi. Tam działa gadżet (do zgłaszania) i mój bot (do usuwania/archiwizowania) i być może coś jeszcze - ale nie kojarzę. Gadżet trzeba zsynchronizować od razu a bota po zmianie a przed archiwizacją (ok 4:00 w nocy). Bota możesz też wyłączyć (usuwając parametr kod z wywołania). ~malarz pl PISZ 09:05, 6 gru 2022 (CET)[odpowiedz]

Szablon czasem występuje obok innych infoboksów. Powoduje to wtedy zaciąganie przez oba tych samych informacji z wikidata. Czy można jakoś dodać tu opcję wyłączania linków do (wybranych) projektów siostrzanych? SpiderMum (dyskusja) 18:14, 8 gru 2022 (CET)[odpowiedz]

  • Może lepiej nie kombinować, tylko wyłączyć całkowicie linki do projektów siostrzanych z tego bonusowego infoboksu, a w zamian stosować dedykowany szablon do tych zadań. Generalnie w artykule powinien być tylko jeden infobox. W przeciwnym razie zaczynamy zabawę w kotka i myszkę. Zresztą takie linki już są przecież dostępne w menu po lewej pod tytułem „W innych projektach”. Można też po prostu pogodzić się z tym i zostawić tak jak jest. Czy one jakoś przeszkadzają? Nie, a nawet uwypuklają, gdzie się zaczyna i kończy infobox. Paweł Ziemian (dyskusja) 18:41, 8 gru 2022 (CET)[odpowiedz]
  • Ja bym w tym konkretnym wyłączył na stałe pobieranie commons z WD. Zresztą dodała to @Wieralee razem z pozostałymi siostrzanymi, które są IMO na tyle rzadkie, że spokojnie można je w razie potrzeby dodawać przez {{wikiźródła}}/{{wikicytaty}}. Commons wprowadziłem do tego szablonu integrując kilka monojęzykowych i dualjęzykowych infoboksów w 2015 (w części z nich był taki parametr). ~malarz pl PISZ 19:15, 8 gru 2022 (CET)[odpowiedz]
  • Co ja mam powiedzieć... 1) dlaczego linki do Wikiźródeł Wam przeszkadzają? 2) dlaczego nie dążycie do unifikacji haseł, tylko do wolnej amerykanki? czy Waszym zdaniem ciągłe szukanie poszczególnych elementów po stronie ułatwia korzystanie z Wikipedii? IMO po to wynaleziono infoboksy, żeby pewne informacje były niejako "pod ręką" bez szukania... choć 3) faktycznie ich mnogość i nie przystawanie do siebie też mi się nie podoba, IMO infoboxy powinny jednak mieć podobne struktury 4) wklejanie kilku infoboxów w jednym artykule jest dziwne... ale może dobrze by było pomyśleć nad szablonem "uzupełnienie infoboxu" który dodawałby pod infoboxem głównym tę jedną informację, której brakowało w tym, akurat użytym infoboxie. Wieralee (dyskusja) 21:15, 8 gru 2022 (CET)[odpowiedz]

Boty a artykuły oczekujące na przejrzenie

Czy boty potrafią wykryć, że artykuł ma nieprzejrzane wersje?

Bo na kosmetyczne poprawki w nieprzejrzanych to wg mnie jest trochę za wcześnie.

Edycja: Przykład (widok przeglądającego). MarMi wiki (dyskusja) 17:09, 10 gru 2022 (CET)[odpowiedz]

  • Mój potrafi. Zwykle przed zapisem sprawdza czy artykuł jest przejrzany. Ale to czysta kurtuazja. Paweł Ziemian (dyskusja) 17:36, 10 gru 2022 (CET)[odpowiedz]
  • A komu przeszkadzają kosmetyczne poprawki w nieprzejrzanych? 2A00:F41:38BB:5F6D:61C4:7A8A:CB87:540D (dyskusja) 18:24, 10 gru 2022 (CET)[odpowiedz]
    Przeglądającemu :)
    Jeśli jest ich niewiele, to nie ma sprawy, ale jak jest ich tyle, że trzeba przez chwilę skrolować żeby dotrzeć do części zmienionej przez użytkownika, to coś jest nie tak...
    Edycja: W pierwszym poście zedytowałem link do widoku przeglądającego. MarMi wiki (dyskusja) 19:21, 10 gru 2022 (CET)[odpowiedz]
    Też o tym myślałem jakiś czas temu. Faktycznie takie edycje o tyle przeszkadzają, że tak efektywnie jest więcej do przejrzenia. Z drugiej strony bot czasem coś poprawia, co trzeba by poprawić ręcznie po edytującym... Tak że to zależy od zadania bota mocno. Nux (dyskusja) 21:36, 10 gru 2022 (CET)[odpowiedz]
    Hmm, chyba trzeba się z tym pogodzić... MarMi wiki (dyskusja) 22:56, 10 gru 2022 (CET)[odpowiedz]
    @MarMi wiki Wiesz, że nie musisz przeglądać i oznaczać wszystkich istniejących nieprzejrzanych wersji naraz? Możesz to robić po jednej wersji wybierając diffa między ostatnią przejrzaną a pierwszą nieprzejrzaną - przykładowy diff. Jeśli na tej stronie klikniesz "oznacz jako przejrzaną" to oznaczona zostanie tylko jedna wersja z 16:14, 29 paź 2022. Kolejne wersje pozostaną nieprzejrzane.
    Tak, boty potrafią wykryć, że artykuł ma nieprzejrzane wersje - dzięki temu bot wprowadzający zmiany w artykule przejrzanym oznacza swoją zmianę automatycznie jako przejrzaną, a gdy artykuł ma wersje nieprzejrzane to bot zostawia swoje zmiany jako nieprzejrzane. Ololuki (dyskusja) 00:15, 20 gru 2022 (CET)[odpowiedz]
    Bot oznacza swoje edycje jako przejrzane tylko jeśli nie ma innych oczekujących nie dlatego, że wykrywa taki stan, ale dlatego że nie ma uprawnień do przeglądania cudzych edycji. W tej kwestii uprawnienia botów są równoważne automatycznie przeglądającym. Msz2001 (dyskusja) 10:01, 20 gru 2022 (CET)[odpowiedz]
    Tylko że to nie jest zbyt praktyczne - skoro i tak wszystko na koniec miałoby być zaakceptowane (albo odrzucone), to po co się rozdrabniać? Czasowo wyjdzie chyba podobnie co przeglądanie całości. Przeglądanie na raty zaciemnia też ogólny obraz.
    Czy wycofywanie na raty czasem nie spowoduje konfliktów, jak przy anulowaniu edycji? Bo część przed botem może być do odrzucenia, a część po (modyfikująca tą pierwszą) do zaakceptowania. Pewnie dość rzadki przypadek, ale przy edycji kilku użytkowników całkiem możliwy. MarMi wiki (dyskusja) 14:48, 20 gru 2022 (CET)[odpowiedz]
    Ja czasami przeglądam artykuły, które zmodyfikował mój bot i mam wrażenie, że częściej jednak można wycofać pojedyncze edycje. Oczywiście nie zawsze tak jest. Dlaczego przeglądanie na raty jest lepsze? - jest łatwiej przeglądać (mniej zmian na raz) a te zmiany wykonane przez bota można czasami zaakceptować bez ich analizy. Są oczywiście sytuacje, w których bot próbuje naprawić ewidentne wandalizmy i jego edycje są wtedy całkowicie zbędne i należy wycofać wszystko bez zastanowienia (np. mój bot usuwający błędne grafiki / próbujący je naprawić). ~malarz pl PISZ 15:12, 20 gru 2022 (CET)[odpowiedz]

Przypisy do Wyborczej

Popatrzmy na takie przykładowe, przeze mnie wybrane przypisy w artykułach:

Zamiast właściwego tytułu strony pojawia nam się krótkie Wyborcza.pl. Nie wiem jak to technicznie działa, ale jest coś takiego, że serwis wyborcza.pl (i serwisy powiązane, jak wyborcza.biz, wysokieobcasy.pl) stosuje jakieś przekierowanie zanim po krótkiej chwili wyświetli czytelnikowi właściwą treść. Z pobieraniem właściwych tytułów nie radzi sobie ani Citoid, ani bot poprawiający linki. Czy pozostaje name ręczne poprawianie? Czy wiemy jaka jest skala zjawiska? --WTM (dyskusja) 01:08, 11 gru 2022 (CET)[odpowiedz]

Kod HTML strony może sugerować, że
<header><h5>Wyborcza.pl</h5></header>

ma pierwszeństwo przed og:title:
<meta property="og:title"
 content="Michał Gieleta: Nie obraziłem się na polski teatr" />

Albo to tylko przypadek. MarMi wiki (dyskusja) 15:28, 11 gru 2022 (CET)[odpowiedz]

Zanim zwołacie konsylium technicznych geniuszy i będziecie rozważać headery, ogtytle, citoidy i sratoidy, to wpiszcie tytuł artykuł do przypisu, to się pokaże. A jak wpiszecie autora, to wiecie co? Pojawi się autor!! MAGIA!! MAGIA!!! Żeby był tytuł, wystarczy go podać! MAGIA!!! Przypisowe pozdrowienia, Alpaka 95.155.87.117 (dyskusja edycje rejestr)Skreślam, bo tu chodzi o automatyczne generowanie przypisu z poziomu bota lub edytora wizualnego. Paweł Ziemian (dyskusja) 16:22, 11 gru 2022 (CET)[odpowiedz]

  • Zapytałem o przykładowy link za pomocą wget i faktycznie ów serwis zapodał <title>Wyborcza.pl</title>, a w <body> jakiś komunikat z prośbą o wyłączenie AdBlocka. Paweł Ziemian (dyskusja) 16:22, 11 gru 2022 (CET)[odpowiedz]
    <title>Francja. Dziennik "Le Figaro": Polska dąży do stworzenia największej armii lądowej w Europie | Biznes na Next.Gazeta.pl</title>
    
    <meta property="og:title" content="Francja. &#034;Le Figaro&#034;: Polska dąży do stworzenia największej armii lądowej w Europie" />
    
    <meta name="twitter:title" content="Francja. &#034;Le Figaro&#034;: Polska dąży do stworzenia największej armii lądowej w Europie" />
    

Przypomnę się. Czy teraz jesteśmy w stanie oszacować jaka jest skala zjawiska? Czyli, czy warto wkładać energię w ręczne poprawianie? Bardziej 500, czy bardziej 1500, czy bardziej 15000? --WTM (dyskusja) 19:58, 27 gru 2022 (CET)[odpowiedz]

Błędny komunikat anulowania edycji (ten stolik)

Po kliknięciu w anulowanie 1-2 niedawnych edycji (poniżej najnowszej) z tego stolika (kawiarenki), pokazał mi się komunikat:

"Edycja nie może być cofnięta, ponieważ nie istnieje lub została usunięta."

Podejrzewam, że odmowa wiąże się raczej z tym, że edycja została "nadpisana" nowszą, a nie że "nie istnieje lub została usunięta" (bo w historii widnieje). Czy powinno to być rozpoznane, czy tak ma być? MarMi wiki (dyskusja) 15:55, 11 gru 2022 (CET)[odpowiedz]

Przejrzałem komunikaty interfejsu dot. wycofywania i są one aktualne w stosunku do oryginału, co więcej istnieje też komunikat MediaWiki:Undo-failure (Edycja nie może zostać wycofana z powodu konfliktu z wersjami pośrednimi.). Czemu się w tym wypadku nie pokazał - nie wiem. Oba (Undo-failure i Undo-norev) mają na translatewiki taki sam opis: Message appears if an attempt to revert an edit by clicking the "undo" link on the page history fails. Msz2001 (dyskusja) 16:18, 11 gru 2022 (CET)[odpowiedz]
T325019 Matma Rex dyskusja 12:27, 15 gru 2022 (CET)[odpowiedz]
Teoretycznie już naprawione, ale zdaje się jeszcze nie dotarło to na plwiki (bo komunikat się nie zmienił). MarMi wiki (dyskusja) 23:57, 27 gru 2022 (CET)[odpowiedz]
@MarMi wiki: trwa deweloperska przerwa świąteczna, kolejna wersja oprogramowania (czyli 1.40.0-wmf.17; obecnie mamy wmf.14 z 13 grudnia) nadejdzie w przyszłym tygodniu. Peter Bowman (dyskusja) 00:40, 28 gru 2022 (CET)[odpowiedz]

Szablon Cytuj a ISBN & ISSN

Co zrobić, jeśli określony numer czasopisma ma i ISBN, i ISSN? Gdy się poprzez edytor wizualny poda i to, i to za pomocą szablonu Cytuj to wyskakuje "???" Przykładowe źródło z ISBN i ISSN tutaj Ja bym optował za tym, żeby można dodawać i to, i to. Tudzież żeby to nie generowało komunikatu o błędzie w postaci pytajników. Co sądzicie? Gower (dyskusja) 17:02, 12 gru 2022 (CET)[odpowiedz]

  • False positive i tyle, należy przejść nad tym do porządku dziennego zwłaszcza, że „???” nie wyświetla się dla zdecydowanej większości czytelników, a kategoria, którą dodaje, jest ukryta. Pomijam już fakt, że ISSN obecnie przydatność ma bliską zeru dla większości przypadków, jak i zresztą w tym przypadku, ale to nie jest kwestia techniczna. Wostr (dyskusja) 17:30, 12 gru 2022 (CET)[odpowiedz]
  • Ewentualnie jeśli ktoś chce dodatkowo podać to można w polu "id=ISSN ...". Pozdrawiam Joee (dyskusja) 09:29, 14 gru 2022 (CET)[odpowiedz]

W infoboksie w artykule Most Zygmunta Augusta widnieje mapa z XVIII w. To bez sensu, ale widocznie żadnego wcześniejszego kształtu państwa polskiego nie da się przedstawić w infoboksie. Czy można stworzyć co najmniej jedną dodatkową mapę, dokumentującą stan z 1619 (czyli z czasów największego zasięgu terytorialnego, jak w artykule I Rzeczpospolita)? @Paweł Ziemian. Tar Lócesilion (dyskusja) 15:49, 13 gru 2022 (CET)[odpowiedz]

Na stronie "Pomoc:Przypisy" znajdował się do niedawna infoboks (na samym początku strony, gdzieś u góry), w którym łatwo można było odnaleźć linki do szablonów "cytuj książkę", "cytuj stronę". Było to bardzo wygodne. Nie trzeba było tego szukać u dołu strony. Czy można prosić o przywrócenie takiej formy? Z góry dziękuję. Abraham (dyskusja) 09:34, 22 gru 2022 (CET)[odpowiedz]

@Abraham: Wolałbym nie ruszać zmian wprowadzonych przez innego usera. Ale możesz zapisać sobie tę wersję (np. jako zakładkę w przeglądarce), gdzie linki do tych szablonów masz podane na samym początku strony. W obecnej wersji strony te linki znajdują się w sekcji "Tworzenie i edycja przypisów w kodzie źródłowym". XaxeLoled AmA 15:32, 22 gru 2022 (CET)[odpowiedz]
Być może dlatego je usunięto, że te szablony mogą nie być za bardzo zalecane do masowego użycia (przynajmniej pod VE - do Cytuj jest bezpośredni dostęp, do edycji innych potrzebny jest dodatkowy krok).
Np. Cytuj stronę nie ma parametru Rodzaj dostępu.
Szablon {{Cytuj}} ma infoboks z linkami na górze.
Jeśli dość często zaglądasz na te strony (i masz włączoną historię), możesz w pasku adresu przeglądarki wpisać "cytuj" albo "szablon cytuj".
Edycja: poza tym schemat linków jest ten sam dla każdego z nich... Różnią się tylko końcówką. MarMi wiki (dyskusja) 17:08, 22 gru 2022 (CET)[odpowiedz]

Szablony Congbio i CANbio

Czy nie lepiej by było przerobić szablony {{Congbio}} i {{CANbio}} (i ewentualnie inne) na wywołanie Cytuj, tak jak np. {{Encyklopedia PWN}}? O ile się da ustawić ręcznie niektóre pola, bo automatycznie pobierane dane nie są zbyt pomocne.

Szablon jest używany w przypisach (np. Charlie_Crist) i linkach zewnętrznych, a wizualnie nadawał by się bardziej na bibliografię - tylko nie ma jak do niego zrobić przypisu {{odn}} tak jak przy PWN (chyba że da się zrobić coś podobnego bez {{Cytuj}}, np. dodając bezpośrednio {{odn/id}} z tytułem artykułu jako parametr - ale nie wiem jak to będzie wyglądać). MarMi wiki (dyskusja) 13:06, 24 gru 2022 (CET)[odpowiedz]

  • Lepiej. W przypadku US jest sporo roboty bo trzeba porozdzielać różne linki do oddzielnych szablonów. Chyba, że z nich zrezygnujemy bo nie działają. Jeżeli zaś chodzi o CAN to trzeba się zastanowić czy podajemy dwa linki (ang i fr) czy tylko jeden oraz przerobić wywołania na nowe identyfikatory (z dwóch różnych starych wersji). Warto też zastanowić się nad lepszą nazwą obydwu szablonów. ~malarz pl PISZ 13:53, 24 gru 2022 (CET)[odpowiedz]
    Wersja Congbio na enwiki jest już z cite web, z tym że obsługuje tylko jedno id (jeden link).
    Edycja: Pozostałe dwa niedziałające linki w 2017 przekierowywały na stronę wyszukiwarki: kobiety i czarni amerykanie. MarMi wiki (dyskusja) 14:48, 24 gru 2022 (CET)[odpowiedz]

Problem z infoboksem – symbole |- na początku niektórych artykułów

W niektórych artykułach używających Szablon:Zawodnik zima infobox (przykład: Faustin Moureaux) pojawiła się przed pierwszą linijką treści linia zawierająca jedynie znaki |-. Jest ona związana z wywołaniem infoboksu (jego usunięcie lub ukrycie powoduje zniknięcie tej linii), on sam nie był jednak edytowany od miesięcy, więc wygląda to na efekt jakiejś ogólnowikipedyjnej zmiany. Barcival (dyskusja) 21:08, 26 gru 2022 (CET)[odpowiedz]

Subskrypcja tematów (sekcji) / Brak możliwości odpowiedzi jako IP

Czy mi się zdaje, czy od jakiegoś (dłuższego) czasu subskrypcja tematów/sekcji nie działa na plwiki? Na de i enwiki widzę przy tematach dyskusji subskrybuj, ale nie na plwiki.

Także powiadamianie o odpowiedziach nie działa (z włączonym narzędziem dyskusji w funkcjach eksperymentalnych) na plwiki (nie sprawdzałem tego na innych wersjach językowych).
Nie zdawało mi się, nie działało bo miałem wyłączoną opcję powiadomienia o odpowiedziach w wątkach w ustawieniach globalnych...

Dodatkowo zauważyłem, że jako IP nie da się odpowiedzieć na wątek, który nie ma podpisu - po prostu brak jest przycisku odpowiedź (temat założyłem jako zalogowany użytkownik, jako IP próbowałem odpowiedzieć w trybie prywatnym).
Edycja: Występuje także na enwiki, więc to chyba tak ma być? MarMi wiki (dyskusja) 01:18, 28 gru 2022 (CET)[odpowiedz]

Pytasz o mw:Talk pages project. To, gdzie co jest włączone, jest szczegółowo opisane na mw:Talk pages project/Deployment Status/pl. To, dlaczego przycisk "Odpowiedz" może się nie wyświetlać, jest opisane na stronie mw:Pomoc:Narzędzia dyskusji/Dlaczego nie mogę odpowiedzieć na komentarz?. Najczęstszą przyczyną jest brak podpisu - bez podpisu oprogramowanie po prostu nie wie, czy tekst jest komentarzem i gdzie przycisk "Odpowiedz" miałby być wyświetlony. Tar Lócesilion (dyskusja) 02:27, 28 gru 2022 (CET)[odpowiedz]
Subskrypcja: Przypomniałem sobie, że jakiś czas temu wyłączałem powiadamianie email i desktop, pewnie przeoczyłem że ta opcja miała zaznaczony tylko jeden checkbox.
Odpowiedź IP: Dobrze więc przypuszczałem, że tak ma być. Dawno nie odpowiadałem jako IP. MarMi wiki (dyskusja) 02:57, 28 gru 2022 (CET)[odpowiedz]

infobox Filmowiec/Artysta

Co sądzicie o pomyśle dodania parametru wikiźródła w infoboksie dotyczącym filmowców oraz parametru dotyczącego współmałżonka/współmałżonki w infoboksie dotyczącym artystów? Stupa1989 (dyskusja) 16:56, 28 gru 2022 (CET)[odpowiedz]

  • Małżonkowie zazwyczaj nie zaliczają się (IMO) do najważniejszych cech i wymienianie ich w infoboksie daje mało pożytku, a dużo problemów (czy tylko oficjalnie ślubnych, czy konkubinaty poważne też, a może "związana z". Wszystkich, pierwszych, czy ostatnich. A Wikiźródła? Chyba w Wikiźródłach nie ma filmów. Czy wielu filmowców ma jakiś dorobek umieszczony na Wikiźródłach? Ciacho5 (dyskusja) 17:08, 2 sty 2023 (CET)[odpowiedz]

Kontrola autorytatywna

Kiedyś kontrola autorytatywna dotyczyła chyba wyłącznie biogramów, a szablon {{Kontrola autorytatywna}} wstawiany był botem wówczas, gdy dana osoba miała rekord w VIAF lub spełniała inne, ściśle zdefiniowane kryteria (nie wiem, czy była to akcja ad hoc, czy bot robi to regularnie). Obecnie jednak KA uwzględnia mnóstwo deklaracji, z których najistotniejsze są chyba identyfikatory do wielu wartościowych encyklopedii, ale jest też cała masa innych identyfikatorów rozmaitych baz danych. Ponawiam więc moją niechdysiejszą propozycję, aby identyfikatory KA wyświetlały się z automatu we wszystkich artykułach, bez potrzeby wstawiania szablonu KA. Wstawiłem ten szablon niezliczoną liczbę razy, widząc żółty pasek gadżetu kontroli autorytatywnej. A przecież można to chyba zrobić globalnie jedną magiczną zmianą MediaWiki. Będzie wg mnie to z korzyścią zarówno dla czytelników, jak i edytujących. Jeśli ta propozycja weszłaby w życie, to usuwanie szablonu KA można by włączyć do SK. [@Paweł Ziemian, @malarz pl] Michał Sobkowski dyskusja 19:58, 29 gru 2022 (CET)[odpowiedz]

  • Jeżeli chodzi o automatyczne dodawanie to nie mam zdania. Jeżeli chodzi o usuwanie zbędnego to w pierwszym okresie WP:SK jest dobrym pomysłem. Ale na końcówce i tak trzeba będzie boty zaprząc do roboty, bo to potrwa wieki. Ale i tak najpierw do rozstrzygnięcia jest pierwsza kwestia. ~malarz pl PISZ 20:01, 29 gru 2022 (CET)[odpowiedz]
  • Przypuszczam, że bot ciągle wstawia te szablony. Jednak może korzystać z jakiejś starej kopii zbioru cech wzbogaconej o warunki mnogości (z wagami) do podejmowania decyzji o wstawieniu szablonu. Operatorem jest jak dobrze pamiętam @Peter Bowman. Chciałbym również przypomnieć, że na początku istnienia szablonu były głosy sprzeciwu przed masowym wstawianiem. Wiele takich linków do katalogów bibliotecznych ma cechy jedynie słownikowe, czyli jakaś notatka o tym, że pojęcie istnieje i nic ponadto. To pewnie teraz inaczej wygląda po dodaniu do KA linków do encyklopedii lub baz danych. Gdy żółty pasek zobaczy człowiek, to może podjąć rozsądną decyzję o wstawieniu szablonu bazując na ocenie treści do których odsyłają wyświetlone linki. Michale, masz to szczęście, że wybrane do szablonu KA cechy i artykuły, które przeglądasz pozytywnie korelują. Czy tak jest zawsze? Nie wiem. A na pewno nie wie tego żaden bot. Co do technicznego rozwiązania wstawienia automatycznie wszędzie, to zastanawiam się, czy istnieje w MediaWiki jakiś szablon, strona techniczna lub cokolwiek co by nam w tym pomogło bez botowania lub gadżetu. Może @Matma Rex będzie coś wiedział. Paweł Ziemian (dyskusja) 22:19, 29 gru 2022 (CET)[odpowiedz]
    O ile wiem, to nic takiego nie istnieje. Matma Rex dyskusja 22:36, 29 gru 2022 (CET)[odpowiedz]
    Niekiedy można wykorzystać interfejs MW. Przykładowo w Wikisłowniku nadpisujemy komunikat wikt:MediaWiki:Lastmodifiedat, aby w stopce strony generował link do statystyk wyświetleń. Tu można by użyć obecnie domyślnie ukrytego MediaWiki:Retrievedfrom (stopka wersji do druku), o ile z poziomu takiego komunikatu dałoby się uzyskać dostęp do połączonego elementu na WD. Trochę to jednak pachnie paskudnym hackiem. Peter Bowman (dyskusja) 00:48, 30 gru 2022 (CET)[odpowiedz]
  • Mój bot wstawia nowe wywołania szablonu codziennie na podstawie zmian wykonanych w Wikidanych poprzedniego dnia, a dodatkowo jeszcze dwa razy w miesiącu robi przegląd całych WD celem uzupełnienia ewentualnych braków oraz synchronizacji ze zmianami na liście wspieranych identyfikatorów. Mechanizm, w tym kryteria, opisany jest w Moduł:Kontrola autorytatywna. Można nieco złagodzić owe kryteria, jeżeli to ma wyręczyć redaktorów w ręcznym wstawianiu szablonu, lecz mogą się pojawić wtedy problemy, o których pisze wyżej Paweł. Peter Bowman (dyskusja) 00:27, 30 gru 2022 (CET)[odpowiedz]

Szablony cytowania

Jeszcze raz proszę o "przybliżenie" szablonów cytowanie. Jakiś czas temu wystarczyły dwa kliknięcia (pomoc, przypisy) i można było byc przy tych szablonach. Skoro nie można wstawić tej tabeli, która jest teraz na stronie Szablon:Cytuj stronę na stronę Pomoc:Przypisy, jak to było do tej pory, to może przynajmniej dodać wywołanie, np. do Szablon:Cytuj gdzies pomiędzy "Szablony | Infoboksy (kategoria)" na stronie Pomoc:Spis treści. Zmniejszyłoby to liczbę potrzebnych kliknięć. Pozdr. Abraham (dyskusja) 05:46, 30 gru 2022 (CET)[odpowiedz]

Zamiast górnego paska możesz wstawić sobie link do szablonu cytowania w kolumnie po lewej stronie, zaraz pod linkiem do strony pomoc:
jQuery( document ).ready( function() {
  var elBefore = document.getElementById( 'n-helppage-name' );
  var elNew = document.createElement( 'li' );
  elNew.innerHTML = '<a href="//pl.wikipedia.org/wiki/Szablon:Cytuj">Szablon:Cytuj</a>';
  elBefore.parentNode.insertBefore( elNew, elBefore.nextSibling );
} );
Ewentualnie możesz dodać link na swojej stronie użytkownika - wtedy też masz dwa kliknięcia (nazwa użytkownika, szablon cytuj).
Korzystasz ze strony {{cytuj}} tylko w roli dokumentacji, czy ręcznie kopiujesz szablony? W tym drugim przypadku możesz użyć gadżetu refTools (do załączenia w preferencje -> gadżety).
P.S. Nie twórz kilku wątków na ten sam temat. Ololuki (dyskusja) 09:23, 30 gru 2022 (CET)[odpowiedz]
Ololuki, to wygląda fajnie, tylko zarówno na Pomoc:Personalizacja - porady dla zaawansowanych#Dodawanie linków do górnego paska, jak i w Twojej poradzie brakuje informacji, czy należy to wkleić do swojego CSS czy JS. Michał Sobkowski dyskusja 17:46, 31 gru 2022 (CET)[odpowiedz]
Już wiem – chodzi o modyfikację swojego JS. Dopisałem to na stronie pomocy. Michał Sobkowski dyskusja 17:54, 31 gru 2022 (CET)[odpowiedz]
  • Jeśli nie zmieniasz przeglądarki (komputera), to wystarczy zrobić sobie zakładkę albo skorzystać z historii adresów.
    A jeśli nawet zmieniasz, to raczej dość łatwo zapamiętać końcówkę Szablon:Cytuj (jeśli się dosć często z tego korzysta na tyle, że skrolowanie do spisu treści w Pomocy i dodatkowe kliknięcie stanowi problem).
    Możesz także na swojej stronie/brudnopisie wstawić bezpośredni link do listy. Albo wręcz wstawić ten infoboks ze strony Cytuj. MarMi wiki (dyskusja) 13:12, 30 gru 2022 (CET)[odpowiedz]
  • @Abraham Hm... Ciekawe, że używałeś tego tyle lat. Wybacz zepsucie szyków, ale ta strona pomocy była po prostu źle zredagowana. Użytkownicy edytora wizualnego w ogóle nie muszą wiedzieć o tych szablonach, bo się ich nie używa w VE. To było mylące po prostu o tym pisać od razu na górze.
W ramach edytora wizualnego możesz generować automatycznie przypisy (nie potrzebujesz znać szablonów). Dodatkowo w VE używany jest u nas tylko szablon Cytuj, a parametry wybiera się z listy (nie trzeba pamiętać ich nazw). W ramach edytora kodu jest do tego gadżet refTools (wspomniany wyżej). Każda z tych opcji daje możliwość wypełniania tych szablonów bez pamiętania wszystkich parametrów.
Jeśli z jakiś względów potrzebujesz mieć jakieś linki pod ręką, to proponuję dodać je sobie na swojej stronie, albo w brudnopisie: Wikipedysta:Abraham/brudnopis. Linki do obu tych stron powinieneś mieć w górnej belce, więc na pewno najmniej kliknięć. Niezależnie od przeglądarki jakiej używasz. Jedynie w nowym vectorze brudnopis jest w podmenu. Możesz też zrobić sobie dowolną, nową podstronę w swojej przestrzeni (np.: Wikipedysta:Abraham/linki). Potem link do podstrony wrzuć sobie w zakładkach przeglądarki, albo na swojej stronie. Nux (dyskusja) 14:21, 31 gru 2022 (CET)[odpowiedz]
  • Pod VE co najmniej dla kilku adresów (yt, imdb) generowany jest szablon odcinka, więc nie do końca się nie używa.
    Z tym że pod VE w oknie edycji szablonu, na górze, podawany jest bezpośredni link do edytowanego szablonu. MarMi wiki (dyskusja) 15:19, 31 gru 2022 (CET)[odpowiedz]
  • No tak, faktycznie. Chociaż moim zdaniem to błąd akurat (ten szablon odcinka nie bardzo mi pasuje do imdb). Nie wiem skąd taka decyzja mapowania (w sensie merytorycznym).
W każdym razie tak czy inaczej nie wypełnia się szablonu sensu stricte. Wypełnia się po prostu formularz. Nux (dyskusja) 15:25, 31 gru 2022 (CET)[odpowiedz]

Położenie na mapie Grazu

Jak i gdzie zamienić w infoboxie "Położenie na mapie Gracu" na "Położenie na mapie Grazu" ? Braniewiak (dyskusja) 11:40, 2 sty 2023 (CET)[odpowiedz]

@Braniewiak - Moduł:Mapa/dane/Graz (już poprawiłem). Mathieu Mars (dyskusja) 11:53, 2 sty 2023 (CET)[odpowiedz]

Dodawanie wszystkich elementów kategorii do obserwowanych

Było jakieś narzędzie do tych czynności. Używam go raz w roku i już nie pamiętam, co to jest i jak to uruchomić. Gżdacz (dyskusja) 11:25, 3 sty 2023 (CET)[odpowiedz]

@Gżdacz: w Wikisłowniku mamy odpowiedni gadżet; możesz go sobie włączyć tutaj, wstawiając poniższy kod do common.js:
mw.loader.load('//pl.wiktionary.org/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki:Gadget-watchlist-add-categorymembers.js');
Obsługuje dwie strony specjalne:
  • Specjalna:Edytuj obserwowane/raw, czyli tekstowy edytor stron obserwowanych: masowo dodaje artykuły należące do wskazanej kategorii, z opcją rekurencyjnego przeszukiwania podkategorii
  • Specjalna:Edytuj obserwowane, czyli standardowy edytor stron obserwowanych: dodaje przyciski do zaznaczania wszystkich stron, z opcją filtrowania stron usuniętych
Peter Bowman (dyskusja) 13:25, 3 sty 2023 (CET)[odpowiedz]

disFixer a nowy edytor kodu

disFixer nie działa z Nowym trybem wikikodu z funkcji eksperymentalnych (z nowym edytorem kodu).
Przynajmniej na Ski Mask The Slump God.
Jeśli to znany problem, może warto by to dopisać do sekcji Znane problemy. MarMi wiki (dyskusja) 16:09, 4 sty 2023 (CET)[odpowiedz]

Dopisałem. --Wargo (dyskusja) 19:26, 4 sty 2023 (CET)[odpowiedz]
Tak dla bibliotekarskiej dokładności, ten "nowy" edytor w tym roku skończy sześć lat. Tar Lócesilion (dyskusja) 20:42, 4 sty 2023 (CET)[odpowiedz]
Tak szczerze mówiąc, to dotąd używam starego edytora wyłącznie dlatego, że disFixer w nim działa, podczas gdy w nowym nie. Gżdacz (dyskusja) 20:52, 4 sty 2023 (CET)[odpowiedz]
Przy okazji - po wciśnięciu popraw i załadowaniu (nowego) edytora, w konsoli wyskakuje poniższy błąd - jakiś konflikt?
Uncaught TypeError: range is null
getCaretPosition https://pl.wikipedia.org/w/index.php?title=Ski_Mask_The_Slump_God&action=edit line 10 > injectedScript:135 (źródło strony)
textSelection https://pl.wikipedia.org/w/index.php?title=Ski_Mask_The_Slump_God&action=edit line 10 > injectedScript:676 (źródło strony)
wikiEditor https://pl.wikipedia.org/w/load.php?lang=pl&modules=ext.wikiEditor&skin=vector&version=oi73w:21 (var cursorPos=context.$textarea.textSelection('getCaretPosition',{startAndEnd:true});)
init https://pl.wikipedia.org/w/index.php?title=MediaWiki:Gadget-refToolbar2-core.js&action=raw&ctype=text/javascript:128 ($target.wikiEditor('addDialog', dialogobj);)
<anonymous> https://pl.wikipedia.org/w/index.php?title=MediaWiki:RefToolbarConfig.js&action=raw&ctype=text/javascript:195 (CiteTB.init();) MarMi wiki (dyskusja) 15:01, 5 sty 2023 (CET)[odpowiedz]
Gadżet nie działa z tym edytorem. Nie umieją się porozumiewać. Nikt go nie przystosował. Wargo (dyskusja) 17:58, 5 sty 2023 (CET)[odpowiedz]
Udało mi się zmodyfikować skrypt tak, żeby czasami działał (jeśli edycja nie ma zapamiętanej sesji).
Wykryte problemy:
  • czasem wyskoczy ten błąd co wyżej,
  • działa poprawnie praktycznie tylko przy pierwszym wejściu w edycję, jeśli np. cofniemy się do poprzedniej strony, zmienimy cel linku i klikniemy popraw ponownie, zmiany już się nie pokażą. To samo będzie jeśli edycja została wcześniej zapamiętana i przywrócona (wina zapamiętywania sesji?),
  • czasami poprawia linki przez SK, czasami nie - to ostatnie zwłaszcza jeśli sesja została zapamiętana.
Być może należałoby użyć innego sposobu pobierania i ustawiania treści niż #wpTextbox1.
Zmiany wokół wikiEditor.toolbarReady, reszta to debug i poprawki wg wskazówek linta.
Jest jakiś hook odpalany przy gotowości edytora? Bo toolbarReady odpala się za wcześnie i potrzebne jest dodatkowe opóźnienie z setTimeout (obecnie dałem 10 s), żeby poczekać na stworzenie #wpTextbox1. MarMi wiki (dyskusja) 18:01, 5 sty 2023 (CET)[odpowiedz]
Skutek uboczny: po wejściu przez Popraw, pokazuje się ikona SK, która się nie pokazuje przy zwykłej edycji. MarMi wiki (dyskusja) 18:18, 5 sty 2023 (CET)[odpowiedz]
Może wikipage.editform (dokumentacja)? Zalecany sposób pobierania i modyfikowania treści to poprzez $("#wpTextbox1").textSelection(). Peter Bowman (dyskusja) 18:23, 5 sty 2023 (CET) Przepraszam, odnosiłem się do innego edytora. Peter Bowman (dyskusja) 19:06, 5 sty 2023 (CET)[odpowiedz]
wikipage.content odpala się przed wikiEditor.toolbarReady (albo prawie równocześnie), reszta z mw.hook nie odpala się wcale.
Edycja: Późniejsze hooki: ve.activate, ve.activationComplete - przy tym ostatnim input #wpTextbox1 już istnieje. Wygląda na to, że obsługa VE i tego edytora kodu jest taka sama (rozróżnienie: patrz isVEInWikitextMode w linku gadżetu poniżej - przy ve.activate przechodzi z niego tylko pierwszy if). MarMi wiki (dyskusja) 19:37, 5 sty 2023 (CET)[odpowiedz]
Tutaj: MediaWiki:Gadget-ref-klawiatura.js#L-107 jest obsługa edytora 2017, jeśli coś to pomoże. Msz2001 (dyskusja) 18:57, 5 sty 2023 (CET)[odpowiedz]
Panowie, a może zrobić to tak, żeby naciśnięcie przycisku generowanego przez disFIxer powodowało odpalenie starego edytora, bez względu na to, co użytkownik ma w preferencjach? Gżdacz (dyskusja) 19:03, 5 sty 2023 (CET)[odpowiedz]
Pomysł ciekawy, ale musiałbyś jakoś przejść z jednego edytora do drugiego. Problem w tym, że ten edytor kodu, jest tak naprawdę edytorem wizualnym. Tam nie ma zwykłego pola do edycji. Nux (dyskusja) 21:08, 5 sty 2023 (CET)[odpowiedz]
disFixer objawia mi się w czasie zwykłego czytania artykułu, kiedy informuje o linkach do disambigów i wyświetla przycisk do poprawy. W 90% takich sytuacji po prostu wybieram konkretne opcje z list tworzonych przez disFixer - i to nadal dzieje się przed uruchomieniem edytora. Dopiero potem naciskam przycisk Popraw, co uruchamia edytor. Zwykle tylko chcę to zapisać, nie wykonuję żadnych dodatkowych edycji. Chodzi o to, żeby do zapisu uruchomił się stary edytor a nie nowy. Gżdacz (dyskusja) 21:41, 5 sty 2023 (CET)[odpowiedz]
Hm... To by było ciekawe. Również do testów. Trzeba by poszukać takiej opcji, chyba że ktoś zna z głowy? Na pewno jest opcja `dtenable=0` do wyłączenia dodawania odpowiedzi przez nowy mini-edytor. Może jest coś podobnego. Nux (dyskusja) 21:50, 5 sty 2023 (CET)[odpowiedz]
To pewnie jest suboptymalne, ale być może dałoby się edytor całkiem pominąć. disFIxer przygotowuje od razu edycję do wyświetlenia w edytorze, można by to od razu zapisać do bazy. To nie daje szansy obejrzenia podglądu, ale to też nie są akcje wykonywane przez tłumy mało doświadczonych edytorów. Gżdacz (dyskusja) 22:53, 5 sty 2023 (CET)[odpowiedz]
Wersja beta(?) (cały blok else wokół ve.activationComplete). Nie testowałem co się dzieje przy odświeżaniu edytora (F5) czy przy przełączaniu edytora na VE (i z powrotem).
Undo odwraca przywracanie sesji (jakby można było jakoś zablokować przywracanie z poziomu js, to byłoby wspaniale). Użycie Undo może spowodować, że przy intensywnym użyciu na tym samym artykule czas ładowania edytora znacznie się wydłuży (być może należałoby przycinać bufor Undo/Redo) - spotkało mnie to wczoraj, nie wiem czy to wyjątek czy reguła.
Z drugiej strony, to czy Undo/blokowanie przywracania byłoby konieczne? Jeśli używający disFixera dość rzadko zmieniają cel tego samego linku (dwa lub więcej razy w tym samym artykule), to byłoby to zbędne - sesję można usunąć z konsoli, choć zapewne to usuwa sesje globalnie (dla wszystkich artykułów). W razie czego można dodać przycisk/pozycję w menu, która by to robiła na żądanie - czasami taka opcja przydałaby się także poza tym przypadkiem (choć dość rzadko).
Trzeba by też jakoś dodać tagi do opisu zmian - bo zarówno disFixer jak i odblokowywany przez niego SK tego nie obsługują. Skoro opis jest zapamiętywany, to być może da się go zmienić programowo (zdaje się WP:NAC tak robi). MarMi wiki (dyskusja) 13:21, 6 sty 2023 (CET)[odpowiedz]
Jak chcesz to jest prostszy sposób. Można użyć `action=submit` zamiast `action=edit`. To zawsze pokaże standardowy edytor kodu (nawet jak się ma włączony ten eksperymentalny). HotCat używa tego samego. Nux (dyskusja) 16:42, 6 sty 2023 (CET)[odpowiedz]
To będzie chyba najlepsze wyjście.
Wystarczy zrobić zmiany w dwóch miejscach: action: 'edit' (na submit) i do warunku if ( mw.config.get( 'wgAction' ) == 'edit' ) { dodać || mw.config.get( 'wgAction' ) == 'submit' (inaczej nie będzie pokazywać zmian po wejściu w edytor).
Drobna niedogodność - po przełączeniu na VE i z powrotem na kod (zmieni się edytor, ale SK będzie aktywne), przy zapisie wyskoczy błąd "Uwaga: nie wprowadzono opisu zmian." (chyba że ktoś ma to wyłączone), mimo że w opisie zmian będzie widniał tag disFixera. Być może w samym VE będzie podobnie. MarMi wiki (dyskusja) 14:03, 8 sty 2023 (CET)[odpowiedz]

Przetestowałem stan aktualny na artykule 25. ceremonia wręczenia Independent Spirit Awards. Oto obserwacje: (1) Nowy edytor kodu się odpala (2) Edytor się odpala, ale wybrane przez mnie za pomocą disFIxera zmiany nie są w kodzie obecne i muszę je ponownie wprowadzić ręcznie. (3) Jeśli obecny w kodzie link kieruje do strony ujednoznaczniającej ale przez przekierowanie, to disFixer nie oferuje wyboru spośród linków na stronie ujednoznaczniającej, tylko spośród przekierowania i strony docelowej. To zapewne efekt uboczny tego, że disFIxer przy okazji automatycznie usuwa linki do przekierowań z kodu i zastępuje stronami docelowymi. Gżdacz (dyskusja) 18:45, 8 sty 2023 (CET)[odpowiedz]

Dobra, to po tej burzy mózgów trochę pogrzebałem i poprawiłem. Działa na moim testowy przykładzie, ale mało używałem tego gadżetu, więc zobaczcie jak to u Was działa.
Jakby co teraz bezpiecznie można włączyć opcję uruchamiania WP:SK. WP:SK nie będzie się osobno ładować. Trzeba mieć włączone wpsk w gadżetach (albo inaczej załadowaną jakąś kopię). Nux (dyskusja) 21:59, 8 sty 2023 (CET)[odpowiedz]

Ponownie przetestowałem. Wszystko działa, disFixer odpala stary edytor kodu, chociaż w preferencjach mam ustawiony nowy. Jest świetnie! Gżdacz (dyskusja) 12:30, 9 sty 2023 (CET)[odpowiedz]

Inne problemy

  1. disFixer, z racji używania atrybutu title, gryzie się z gadżetem Navigation popups, który usuwa ten atrybut przy najechaniu kursorem na link, choćby tylko na milisekundę (nie przywracając go, aż pokaże i schowa się popup). Zgłosiłem problem z usuwaniem title na stronach dyskusji tego gadżetu (pl/en).
  2. Są dwa warunki z isNaN, jeden z +i, drugi tylko z samym i. Jeśli + robi różnicę, to oba powinny go mieć?

MarMi wiki (dyskusja) 22:47, 9 sty 2023 (CET)[odpowiedz]

Rzucisz linka do linii w kodzie? Chyba nie rozumiem co masz na myśli, bo dissFixer używa przycisku, nie popups linków.
Oraz pytanie czy to co piszesz, to nowe problemy (po ostatnich zmianach), czy stare i niezależne od siebie? Nux (dyskusja) 22:54, 9 sty 2023 (CET)[odpowiedz]
Stare problemy (sprawdzane na wersji sprzed zmian, tylko ze zmienioną akcją na submit). Numery wierszy na samym dole.
1. To raczej błąd Navigation popups, a nie disFixera.
disFixer zbiera linki i wysyła do zapytania (chyba przez api; query) po tytule pobranym z atrybutu "title" linku. Navigation popups czyści ten atrybut już po przejechaniu kursorem po linku, nie przywracając go (chyba że poczeka się na okienko z podglądem linku). Wprawdzie można usuwanie title przez Navigation popups wyłączyć, dodając window.removeTitles=false do np. common.js, ale wtedy tooltip będzie przysłaniał podgląd linku.
disFixer:
Query z pustym tytułem zwraca poniższy obiekt (trafiający do tablicy obiektów pages[])
"-1": Object { title: "", invalidreason: "The requested page title is empty or contains only the name of a namespace.", invalid: "" }
przez co disFixer rzuci błedem "Uncaught TypeError: pages[i].revisions is undefined" (po kliknięciu "Popraw linki (...)"), a po kliknięciu w Popraw nie będzie żadnych zmian. Pętla w wierszu 270 poniżej.
2. isNaN występuje w kodzie tylko w dwóch miejscach, więc znaleźć nietrudno (pętle for..in w 222 i 270). MarMi wiki (dyskusja) 23:35, 9 sty 2023 (CET)[odpowiedz]

Widok Ozetów i Obserwowanych

Mam wrażenie, że coś się zmieniło w interfejsie Specjalna:Ostatnie zmiany i Specjalna:Obserwowane. W celu odtworzenia problemu należy w preferencjach mieć włączone ustawienie „Ukrywaj link [ cofnij ] na stronach: Ostatnie zmiany oraz Obserwowane.”. Faktycznie nie jest widoczny link „cofnij” do rollbacku (rewertu redaktorskiego), ale poszczególne wiersze kończą mi się jakoś dziwnie.

Mianowicie edycje zalogowanych, za które można podziękować, kończą się na ( | podziękuj) [nawias otwierający, pipe, słowo podziękuj, nawias zamykający]. Edycje niezalogowanych i moje własne są zakończone znakami () [nawias otwierający, nawias zamykający], co wygląda dziwnie. O ile polegam na swojej pamięci, wcześniej było to jakoś inaczej rozwiązane. --WTM (dyskusja) 21:15, 6 sty 2023 (CET)[odpowiedz]

Zauważyłam to samo – chyba od wczoraj lub przedwczoraj. Widoczne jest to także na Specjalna:Wkład. Tym pustym nawiasem kończą się tylko edycje oznaczone jako "ostatnia" na danej stronie. Salicyna (dyskusja) 21:36, 6 sty 2023 (CET)[odpowiedz]
Oprócz tego zostały dodane nawiasy z linkiem "inne edycje" przy każdym znaczniku, np. "Znaczniki: Zastąpiono (inne edycje) Ręczne wycofanie zmian (inne edycje)", przez co opisy zmiany zmian są jeszcze dłuższe i jeszcze mniej czytelne. Ololuki (dyskusja) 22:17, 6 sty 2023 (CET)[odpowiedz]
Od czwartku przycisk podziękuj wyświetla się na większej liczbie stron (w tym OZ, Wkład, Obserwowane) - info w przyszłotygodniowym Tech News. Najwyraźniej gadżet ukrywający linki cofnij wymaga aktualizacji. Mogę to zrobić najwcześniej w poniedziałek lub wtorek (wcześniej nie za bardzo mam dostęp do kompa). Chyba że ktoś inny się tym wcześniej zajmie. Msz2001 (dyskusja) 23:14, 6 sty 2023 (CET)[odpowiedz]
Aby ułatwić pracę napiszę, że link "cofnij" jest owinięty znacznikiem span (a konkretnie niepotrzebny jest ten wewnątrz), który psuje magię w CSS, która zarządza oddzielaniem kreską i ukrywaniem nawiasów. Pewnie by trzeba dorobić JS albo naciskac na zmiany w MediaWiki (przeniesienie atrybutu class wyżej i/lub modyfikacja CSS od nawiasów). --Wargo (dyskusja) 14:59, 7 sty 2023 (CET)[odpowiedz]
Z tego, co widzę w konsoli, to za wyświetlanie tych przycisków odpowiada klasa mw-changeslist-links mw-pager-tools dla tego spanu. Przyciski, które się nie pojawiają, są w kodzie wyszarzone, natomiast te, które pojawiają się normalnie, są pokolorowane. XaxeLoled AmA 15:32, 7 sty 2023 (CET)[odpowiedz]
Chodzi o gadżet MediaWiki:Gadget-hide-rollback, który składa się tylko z tego pliku .css: MediaWiki:Gadget-hide-rollback.css. Problem pionowych kresek można rozwiązać dodając do gadżetu następujące linie:
.mw-special-Recentchanges .mw-changeslist-links.mw-pager-tools > span:not(:first-child):before,
.mw-special-Watchlist .mw-changeslist-links.mw-pager-tools > span:not(:first-child):before {
 display:none
}
Niestety nie byłem w stanie w żaden sposób przy użyciu CSS wycelować w pseudoelementy :before i :after, gdy elementy z klasami .mw-changeslist-links.mw-pager-tools mają tylko jedno dziecko – czyli problematyczne puste nawiasy przy włączonym gadżecie. Może istnieje jakiś sposób (chętnie bym zobaczył), ale raczej trzeba będzie to rozwiązać przez js. Jest jeszcze opcja ukrycia obu linków – zarówno rollbacka jak i podziękowań – co byłoby bardzo proste. Nie wiem tylko, czy osoby, które korzystają z tego gadżetu chciałyby takiej zmiany (według Specjalna:Użycie gadżetów 112 osób włączyło sobie ten gadżet). Wszak gadżet został stworzony tylko po to by ukrywać link [cofnij]. tufor (dyskusja) 17:51, 7 sty 2023 (CET)[odpowiedz]
Może selektor :only-child by coś dał, albo coś podobnego ([4], [5]). MarMi wiki (dyskusja) 18:34, 7 sty 2023 (CET)[odpowiedz]
Bawiłem się z tym, bawiłem się z only-of-type, ale gitara grać nie chciała ;) Może mamy tu jakiegoś czarodzieja, który sobie z tym poradzi ;) Z tego co rozumiem to :only-child należałoby połączyć z :has, (coś w stylu .mw-changeslist-links.mw-pager-tools:has(span:only-child):before), ale :has to chyba jedna z nowszych funkcji i nie jest wspierana przez wszystkie przeglądarki (np. Firefox). Pozdrawiam, tufor (dyskusja) 18:49, 7 sty 2023 (CET)[odpowiedz]
Usuwanie pustych nawiasów w css (założenie dla rozwiązania bez :has - są tylko 2 pozycje: cofnij i podziękuj):
/* Rozwiązanie z :has. Usuwa span zawierający samotny span z "cofnij". */
.mw-special-Recentchanges .mw-pager-tools:has(span:only-child .mw-rollback-link) {display:none}

/* Rozwiązanie bez :has. Wada - nawiasy staną się częścią linku "podziękuj". */
.mw-special-Recentchanges .mw-pager-tools:before {display:none}
.mw-special-Recentchanges .mw-pager-tools:after {display:none}
.mw-special-Recentchanges .mw-thanks-thank-link:before {content: '('}
.mw-special-Recentchanges .mw-thanks-thank-link:after {content: ')'}
Przez js jest więcej roboty - trzeba by wykrywać doładowywanie nowych pozycji. MarMi wiki (dyskusja) 00:43, 8 sty 2023 (CET)[odpowiedz]
Hm... :has jest za świeże. Niedawno prosiłem o dodanie wsparcia clamp, które jest już od jakichś 20 wersji we wszystkich przeglądarkach, a i tak Izno marudził, że specyfikacja jeszcze nie jest klepnięta. Z tym bym poczekał aż przynajmniej w FF będzie. O ile w ogóle linter to przepuści. Nux (dyskusja) 01:52, 8 sty 2023 (CET)[odpowiedz]
Linter zgłasza błąd (oczekiwano RPAREN). MarMi wiki (dyskusja) 13:42, 8 sty 2023 (CET)[odpowiedz]
Udało mi się wygospodarować czas już dzisiaj i wprowadziłem zmiany w gadżecie. Ze względu na to, że rozwiązania polegające wyłącznie na CSS mają pewne wady lub są nieobsługiwane powszechnie, ukrywanie pustych list i pierwszego znaku potoku będzie wspomagał JavaScript (sam link cofnij jest nadal ukrywany w CSS, aby nadal działało w sposób podstawowy u osób, które nie korzystają ze skryptów). Msz2001 (dyskusja) 18:28, 8 sty 2023 (CET)[odpowiedz]

Szablon:Cytuj

Jak sporo pewnie edytorów wciąż edytuję często jeszcze w kodzie i używam szablonów cytowania z pasków narzędziowych. Próbuję przymusić się do korzystania tylko z szablonu uniwersalnego i tym co sprawia, że b. niechętnie rezygnuję z szablonu "cytuj stronę" jest to, że domyślnie wypełnia on datę dostępu, czego nie potrafi szablon uniwersalny. Podpowiadam tylko, że być może bardzo wzrosłaby popularność szablonu uniwersalnego, gdyby wejście do edycji parametru "data dostępu" skutkowało wczytaniem domyślnie daty bieżącej (tylko do zatwierdzenia). Kenraiz (dyskusja) 12:45, 7 sty 2023 (CET)[odpowiedz]

Też mi chodziło po głowie dodanie automatycznej daty dostępu w szablonie uniwersalnym, problem jednak w tym, że jest on uniwersalny i data dostępu nie zawsze jest potrzebna - np. przy cytowaniu książki lub czasopisma papierowego. W takim przypadku użytkownik musiałby pamiętać o usuwaniu tej daty. Ewentualnie można spróbować dodać dynamiczne uzupełnianie daty dostępu dopiero po wypełnieniu pola url. Ololuki (dyskusja) 14:11, 7 sty 2023 (CET)[odpowiedz]
No właśnie to drugie rozwiązanie byłoby optymalne – gdyby można było zrobić tak, że wejście w pole edycji powoduje podświetlenie sugerowanej (bieżącej) daty – do zatwierdzenia tylko, ew. modyfikacji (w razie potrzeby) lub usunięcia (w przypadku pomyłkowego wejścia w zbędny parametr). Kenraiz (dyskusja) 14:23, 7 sty 2023 (CET)[odpowiedz]
Mamy dwa gadżety refToolbar, ale zakładam, że chodzi o pierwszą wersję. Czy nie wystarczyłoby w linii 381 dodać coś takiego co jest już w linii 188? Oczywiście pamiętając by wcześniej odpowiednio zadeklarować w tej funkcji zmienną newtime (albo bezpośrednio w miejscu docelowym wywołać funkcję refsTB.getTime(); ;)? Kłaniam się, tufor (dyskusja) 18:04, 7 sty 2023 (CET)[odpowiedz]
Tak, to chyba o to chodzi. Zmieniłem.
Niestety TemplateData póki co nie ogarnia tworzenia dat, a subst: nie działa w tagach ref. Czyli w formularzu VE i tym ogólnym do szablonów tego się nie da zrobić (a przynajmniej nie przez TD). Nux (dyskusja) 18:14, 7 sty 2023 (CET)[odpowiedz]
@Nux Problemem w podejściu @Tufora jest to, że teraz data dostępu dodawana jest zawsze dla szablonu uniwersalnego (gdzie przynajmniej widać ją od razu) i dla książki, gdzie jest schowana w formularzu pod przyciskiem "Dodatkowe pola", co może spowodować wysyp cytowań papierowych książek z datą dostępu ;) Moja propozycja jest taka: dodałem przycisk umożliwiający szybkie dodanie daty dostępu w szablonie cytuj i cytuj książkę. P.S. zapomniałeś podbić numeru wersji. Ololuki (dyskusja) 23:01, 7 sty 2023 (CET)[odpowiedz]
Hm... Słusznie, ale uprościłem sprawę. Data dostępu dotyczy url, więc po prostu usuwam jak url jest pusty. To powinno też załatwić sprawę jak ktoś sam niepotrzebnie podaję datę. Dodałem też przy okazji podstawową walidację. W sumie jak ktoś chce, to może też dodawać cytowanie przez przycisk do szablonów -- tam jest formularz wypełniany przez TemplateData. Nux (dyskusja) 03:04, 8 sty 2023 (CET)[odpowiedz]
Dziękuję bardzo. Działa pięknie. Kenraiz (dyskusja) 17:31, 8 sty 2023 (CET)[odpowiedz]

Niewidoczny szablon Aktualizuj po (VE)

{{Aktualizuj po}} z datą dzisiejszą (i zapewne przyszłą) jest niewidoczny pod VE (nie da się go zedytować) i na stronach (ale to ostatnie być może jest zamierzone). Może pod VE podawać datę przez {{#invoke:Sprawdź}} (czy jak on się tam nazywa?) dla wywołań z przyszłą datą? Co do widoczności na stronie: wydaje mi się, że dla daty teraźniejszej szablon też powinien się wyświetlać. Chyba że są jakieś zastosowania, w których to wymuszenie „po” jest potrzebne.
Edycja:
Dodatkowo może domyślnie jako rok wstawać obecny (lub obecny-1), bo przyszłych dat jest niewiele (z 202[2-9] - 14, z 202[3-9] - 4...) MarMi wiki (dyskusja) 16:00, 7 sty 2023 (CET)[odpowiedz]

Automatyzacja pracy przewodnika

Czy jest opcja automatycznego wysyłania wiadomości swoim popieczmy jako przewodnik? User został mi przydzielony, więc automatycznie dostaję od mnie wiadomość. SkrzydlatyMuflon Pisz tutaj 18:09, 7 sty 2023 (CET)[odpowiedz]

Teoretycznie można by do tego zaprząc automatyczną witajkę i słowo kluczowe {{#mentor:}}, które pozwala na określenie, kto jest przewodnikiem danego użytkownika. (W ten sposób można by też umieścić w witajce podpis przewodnika, a nie losowej osoby). Msz2001 (dyskusja) 18:14, 7 sty 2023 (CET)[odpowiedz]
Jeśli krótka wiadomość, to w Specjalna:Panel_przewodników możesz ustawić. Te osoby, które masz przypisane z programu Growth widzą to na swojej stronie domowej (mają swój nick w belce podlinkowany do tej strony). Widzą to info na chwilę przed napisaniem do Ciebie. Jeśli chcesz ich przekierować chwilowo na kogoś innego, to możesz właśnie tam napisać. Nux (dyskusja) 03:10, 8 sty 2023 (CET)[odpowiedz]
@SkrzydlatyMuflon, propozycje technicznych możliwości tego typu możesz przedstawiać (po polsku i w dowolnym innym języku) na stronie mw:Talk:Growth. Tam się dowiesz, czy zespół rozważał coś podobnego, ew. kiedy można się tego spodziewać albo dlaczego tego nie zrobią, czy jest możliwe zbudowanie gadżetu, który by to robił itp. Tar Lócesilion (dyskusja) 17:44, 8 sty 2023 (CET)[odpowiedz]

Gadget - przenoszenie do brudnopisu jako wynik dyskusji DNU

Czy przy kończeniu dyskusji i przenoszeniu do brudnopisu za pomocą gadgetu dałoby się umieścić gdzieś informacje o samej dyskusji w Poczekalni? Bo z tego mogą wyniknąć problemy, gdy autorzy zaczną przywracać po cichu zbrudnopisowane hasła bez zmiany treści. Na przykład hasło Imperium Morza Północnego poszło automatycznie do brudnopisu, dyskusja DNU do zostawionych - ale szablonu brak, a opis przy przenoszeniu do brudnopisu nie mówi nic o DNU. Za kilka miesięcy autor (nie mówię, że ten konkretnie) po prostu przeniesie brudnopis bez wprowadzania zmian i ktoś zacznie kolejną dyskusję DNU nie wiedząc o poprzedniej. Konkretnie pytanie jest takie - Czy gadget mógłby w opisie zmian przy przenoszeniu do brudnopisu wstawiać "Przeniesione do dopracowania decyzją DNU + link" zamiast standardowego "Artykuł należy dopracować"? Taka informacja jest do łatwego znalezienia przy każdej próbie odtworzenia hasła pod tą samą nazwą. Przy okazji gadget mógłby też wstawiać szablon do dyskusji hasła w brudnopisie. Jest to łatwiejsze do obejścia, ale pewnie też łatwiejsze w implementacji. Radagast13 (dyskusja) 18:25, 9 sty 2023 (CET)[odpowiedz]

Najpierw chyba powinniśmy odpowiedzieć na pytanie: który gadżet powinien to robić? Ten do zamykania dyskusji w DNU czy „Przenieś do brudnopisu”? IMO ten pierwszy do tego powinien służyć, chociaż byłoby to w dużej mierze powielenie funkcjonalności drugiego. tufor (dyskusja) 18:36, 9 sty 2023 (CET)[odpowiedz]
Oczywiście ten pierwszy. Już teraz wstawia przy kasowaniu komunikat "Usunięto po dyskusji: Wikipedia:Poczekalnia/artykuły/2022:12:31:Caramba", mógłby wstawiać przy przenoszeniu do brudnopisu "Przeniesiono do brudnopisu po dyskusji: Wikipedia:Poczekalnia/artykuły/2022:12:31:Caramba". O ile jest to oczywiście możliwe i wykonalne, z góry też dziękuję. Radagast13 (dyskusja) 18:55, 9 sty 2023 (CET)[odpowiedz]
A, ok, zauważyłem, że gadżet (MediaWiki:Gadget-DelReqHandler.js) został już zintegrowany z gadżetem przenoszenia do brudnopisu (MediaWiki:Gadget-move-to-sandbox.js); ja kojarzyłem go ze starszej wersji. tufor (dyskusja) 19:39, 9 sty 2023 (CET)[odpowiedz]
W zasadzie można zostawiać przekierowanie do brudnopisu (nie kasować). To by załatwiało sprawę jeśli chcesz utrudnić nieco odtworzenie.
Jeśli chodzi o samą informację o przebiegu, to w logu jest info. Nie wystarczy?
Pozdrawiam, Nux (dyskusja) 20:04, 9 sty 2023 (CET)[odpowiedz]
  • Jeśli to możliwe to prosiłbym jednak o taki opis przy przenoszeniu jak podałem powyżej, "Przeniesiono do brudnopisu po dyskusji: Wikipedia:Poczekalnia/artykuły/2022:12:31:Caramba". Jest różnica pomiędzy przeniesieniem do brudnopisu po dyskusji (czasem długiej), a przeniesieniem uznaniowo podczas sprawdzania OZ. Może nie jest to różnica formalna, ale link do DNU by się przydał. Potem hasło jest wstawiane po cichu i czasem nikt nie podejrzewa, że wszystko zostało już omówione - a zamiast tego startuje kolejne DNU o tym samym. Nie widzę jak mogłoby to zaszkodzić, więc jeśli tylko jest to w miarę łatwe do wprowadzenia to byłbym wdzięczny. Jak zbyt kłopotliwe to trudno, nie jest to sprawa kluczowa. Radagast13 (dyskusja) 20:35, 9 sty 2023 (CET)[odpowiedz]
  • Popieram. Takie coś byłoby znacznie bardziej informatywne niż obecny opis:
Pozdrawiam, Michał Sobkowski dyskusja 09:45, 10 sty 2023 (CET)[odpowiedz]
Również popieram. AramilFeraxa (Napisz do mnie!) 10:10, 10 sty 2023 (CET)[odpowiedz]
Zaktualizowałem gadżety, tak aby można było ustawić inny domyślny powód przenosin niż „Artykuł należy dopracować” (diff move-to-sandbox, diff delReqHandler). Prosiłbym kogoś z administratorów o sprawdzenie przy okazji, czy wszystko działa tak jak powinno. Msz2001 (dyskusja) 10:45, 10 sty 2023 (CET)[odpowiedz]
Teraz tak to działa i wygląda diff wraz z diffem (po mojej kompilacji oczywiście) Jckowal piszże 19:20, 10 sty 2023 (CET)[odpowiedz]
Uwaga: nie ma wyboru jak pisze Msz2001 Zaktualizowałem gadżety, tak aby można było ustawić inny domyślny powód przenosin niż „Artykuł należy dopracować”, jest tylko w okienku Przeniesiono do brudnopisu po dyskusji: ... itd. To dla ścisłości. Jckowal piszże 19:28, 10 sty 2023 (CET)[odpowiedz]
Racja, niefortunnie się wysłowiłem. Chodziło mi o to, że skrypt, który wywołuje okienko może sobie ustawić, co użytkownik ma zobaczyć w polu z uzasadnieniem. Msz2001 (dyskusja) 19:37, 10 sty 2023 (CET)[odpowiedz]
Dziękuję bardzo. Radagast13 (dyskusja) 18:17, 10 sty 2023 (CET)[odpowiedz]

Hm, użycie szablonu Cytuj uniemożliwia podgląd tworzonego artykułu?

Od 2-3 dni wstawienie szablonu cytuj z paska narzędziowego powoduje (u mnie), że przestają działać funkcje 'pokaż podgląd' i 'podgląd zmian'. Skopiowanie kodu i wklejenie w nowym oknie (razem z szablonem już wpisanym do artykułu) przywraca funkcjonalność ww. funkcji. Przed chwilą przetestowałem to w nowym oknie edycji – dopóki pisałem, formatowałem tekst bez używania ww. szablonu – przyciski działały. Gdy wkleiłem szablon – przestały działać. Nie sprawdzałem czy działa funkcja 'zapisz stronę' ponieważ nie używam jej bez uprzedniego podglądu zmian... Kenraiz (dyskusja) 00:10, 11 sty 2023 (CET)[odpowiedz]

Oraz który edytor i pasek narzędziowy. MarMi wiki (dyskusja) 01:35, 11 sty 2023 (CET)[odpowiedz]
  • Powyższe przytrafiło mi się kilkukrotnie podczas edycji i raz podczas próby znalezienia źródła problemu w brudnopisie, teraz powtarzając eksperyment w brudnopisie, było już ok... Używałem przy tym Win 10, FF i Brave, skórka: stary wektor, refTools – pasek skrótów do szablonów cytowania nad oknem edycji kodu. Kenraiz (dyskusja) 08:04, 11 sty 2023 (CET)[odpowiedz]
    Jednak wciąż mam problem. Jeśli to tylko u mnie, to spróbuje odinstalować Brave – kłopoty zaczęły się po instalacji tej przeglądarki... Kenraiz (dyskusja) 10:32, 11 sty 2023 (CET)[odpowiedz]
    Jeśli masz włączone podświetlanie, to je wyłącz i zobacz czy to coś zmienia.
    A sprawdzałeś, czy w konsoli (F12) nie ma czasem jakiegoś błędu? MarMi wiki (dyskusja) 14:33, 11 sty 2023 (CET)[odpowiedz]
  • Też coś takiego mi się dzisiaj przytrafiło, ale nie umiem powiedzieć, czy było to związane ze wstawieniem Cytuj. Nie wydaje mi się, bo wstawiam go często i nigdy takiego problemu nie było. Otworzyłem nowe okno edycji, wkleiłem cały zmodyfikowany kod i podgląd działał już prawidłowo (w nowym oknie edycji, starego nie sprawdzałem). FF 108.0.2, Win10, Monobook, włączony pasek narzędzi edycyjnych w trybie kodu źródłowego, wczoraj włączyłem sobie standardowy refToolbar zamiast Wikipedysta:Paweł Ziemian/Gadget-refToolbars.js. Michał Sobkowski dyskusja 15:58, 11 sty 2023 (CET)[odpowiedz]
  • Potwierdzam problem w przypadku wstawienia szablonu bez wypełnionego jednego z pól wymaganych. @Nux: wydaje mi się, że winna może być walidacja, którą dorzuciłeś ostatnio. Nie sprawia ona, że nie generuje się źle wypełniony szablon cytowania (a zakładam taka była intencja), lecz wyżej wymienione przyciski pod edytorem nie działają. Jak wywołać błąd: edytuj artykuł > narzędzie cytuj > dowolny przycisk generujący szablon > nic nie wypełniając kliknij "Dodaj przypis". Usunięcie pustego szablonu z kodu artykułu nic nie zmienia. Kłaniam się, tufor (dyskusja) 17:28, 11 sty 2023 (CET)[odpowiedz]
  • A, możliwe, teraz przypominam sobie, że przy generowaniu któregoś przypisu coś źle wypełniłem w formularzu refToolbara. Michał Sobkowski dyskusja 18:22, 11 sty 2023 (CET)[odpowiedz]
    Heh. No ciekawe. Trzeba wypełniać wymagane pola i wtedy działa ;)... Ale serio, to ja używam podglądu AJAX (Pref → Edycja → „bez przeładowania strony”). Wtedy problem nie występuje. Ciekawe, że MW to sprawdza w podglądzie czasami. Pomyślę jak to ominąć. Nux (dyskusja) 21:12, 11 sty 2023 (CET)[odpowiedz]
    Pewnie chodzi o atrybut "required". To jest obsługiwane przez przeglądarki. Może po zakończeniu edytowania a przed zapisem należałoby te pola tekstowe jakoś usuwać? Wargo (dyskusja) 21:41, 11 sty 2023 (CET)[odpowiedz]
    Pole edycyjne jest opakowane w jeden wielki <form>, gadżet generuje tylko <fieldset>, co jest uznawane za część dużego <form>. required działa dla znacznika form i blokuje inputy typu submit tego formularza (całego pola edycji). Taka jest moja teoria, nie wiem czy poprawna ;) tufor (dyskusja) 21:55, 11 sty 2023 (CET)[odpowiedz]
    Aaa no tak, bo podgląd ma typ submit. No to tak niechcący im/nam wyszło to sprawdzanie (myślałem, że explicite w MW wywołują). –Nux (dyskusja) 23:03, 11 sty 2023 (CET)[odpowiedz]
@Kenraiz zmieniłem nieco sposób działania. Jak ukryjesz formularz cytowania, to podgląd będzie działał normalnie. Kliknięcie w „Anuluj” też powinno działać.
Aczkolwiek i tak zachęcam do włączenia dynamicznego podglądu (Pref → Edycja → „bez przeładowania strony”). Mocno przyśpiesza działanie. Nux (dyskusja) 23:48, 11 sty 2023 (CET)[odpowiedz]
Dzięki za poprawki, zmianę w preferencjach przetestuję. W razie czego będę znów wołał o pomoc... Kenraiz (dyskusja) 00:11, 12 sty 2023 (CET)[odpowiedz]
Działa, ale tylko wtedy, jak ukryjesz całkowicie przyciski gadżetu; jak nie odklikniesz to nadal nie wyświetlisz sobie podglądu. Jest to nieintuicyjne, zwłaszcza, że przyciski typu submit nie zmieniają koloru. Teraz my to wiemy i będziemy pamiętać, jednak jestem niemal pewien, że inni wikipedyści też napotkają na ten problem i będą się zastanawiać co się dzieje. Moim zdaniem tą walidację przez required należy usunąć. Szczerze to nie widzę sensu walidacji „sposobem htmlowym” formularza tworzonego i obsługiwanego przez js; szablon cytowania bez wypełnionych pól wymaganych jest mimo wszystko tworzony. IMO obecna wersja < brak walidacji < walidacja przez JS. Kłaniam się, tufor (dyskusja) 00:41, 12 sty 2023 (CET)[odpowiedz]
Jak nie schowasz, to przeglądarka powinna podświetlić pole, więc jak dla mnie trudno przegapić. Aczkolwiek powiedziałbym, że zażalenia piętro wyżej – phab: zaprasza ;). Moim zdaniem to błąd w MW, że raz sprawdzają, a raz nie formularz przy podglądzie ;). Mógłbym im wyłączyć to sprawdzenie, ale wtedy musiałbym zaingerować w nieswój przycisk. Nux (dyskusja) 00:57, 12 sty 2023 (CET)[odpowiedz]
Edytuję stronę > klikam przycisk Cytuj > Klikam "Strona WWW" > klikam "Pokaż podgląd" > przeglądarka faktycznie mnie cofa do niewypełnionego parametru URL, nie wyświetla podglądu > nic nie wypełniając klikam "Dodaj przycisk" > chowa się okienko z polami do wypełnienia i wstawiony jest kod <ref>{{Cytuj stronę}}</ref> > przycisk "Pokaż podgląd" nie działa. To jest ten problem, o którym mówię. Teraz, jeśli jeszcze raz kliknę "Cytuj" to schowają się przyciski gadżetu ("Strona www", "Książka" itd.) i dopiero wtedy przycisk "Pokaż podgląd" ponownie działa. I to jest ta nieintuicyjna kwestia. I to nie kwestia MW; przed dodaniem required wszystko działało bez zarzutu. Nie analizowałem dokładnie kodu, ale wydaje mi się, że za chowanie formularza po kliknięciu "Dodaj przypis" odpowiada linia 113. Ustawia ona display: none i inspector to potwierdza. Czyli pozostaje nam niewidoczny input z niewypełnionym parametrem required i nic dziwnego, że formularz nie może zostać wysłany. Dlatego też ponowne kliknięcie w ikonkę gadżetu, powodujące usunięcie formularza gadżetu z DOMu przywraca funkcjonalność przyciskom. Po sprawdzeniu w konsoli, to chyba jednak zostaje w DOM, chyba jakaś inna magia się tam dzieje ;) tufor (dyskusja) 01:41, 12 sty 2023 (CET)[odpowiedz]
Być może zamiast ustawiania display:none, albo dodatkowo, zmienić typ na hidden?
Edycja: Ukrycie paska cytowania (Anuluj lub ponowne kliknięcie w ikonę) wyłącza input (dodawany jest disabled="disabled"), więc też to można wziąć pod uwagę. MarMi wiki (dyskusja) 12:25, 12 sty 2023 (CET)[odpowiedz]
Hm... Z jakiegoś względu chowanie formularza po wypełnieniu działa jakoś inaczej. Chyba kiedyś można było wypełnić parę szablonów jednocześnie. Teraz chyba się nie da tak standardowo, ale są pozostałości po tym. W sumie to trochę lipa jest, że wypełniony szablon jest kasowany przy przełączaniu, ale tak raczej działa od dłuższego czasu... W każdym razie puste wypełnienie poprawiłem [6]. Mógłbym blokować wstawienie pustego (nieprawidłowego) cytuja, ale nie chciałem psuć zgodności wstecznej (pewnie ktoś mógł tego używać do czegoś). @Tufor możesz szukać kolejnych przypadków testowych :) Nux (dyskusja) 17:03, 14 sty 2023 (CET)[odpowiedz]
Ukrycie formularza cytowania pozwala zapisać artykuł, ale to raczej nie powinno tak działać... Przy wypełnianiu formularzy cytowania starałem się wypełnić wszystkie pola, jakie mogłyby być uznane za "wymaganie". Kenraiz (dyskusja) 12:01, 12 sty 2023 (CET)[odpowiedz]

Problem z szablonem {{Układ wielokolumnowy}}

Mam problem z szablonem {{Układ wielokolumnowy}}. Wstawiam {{Układ wielokolumnowy|liczba=4| i jest dwukolumna zamiast cztero. Poniżej wyskakuje info Brakujące pola: szerokość. Przestarzałe pola: "liczba". Tak jest na moim profilu [7] oraz było w innych projektach co spowodowało, że nie wstawiam szablonu np. {{Układ wielokolumnowy}}. Proszę o poprawę mojego profilu i pomoc w naprawieniu tegoz szablonu, abym mógł go wstawić w projektach. Keres 40 (dyskusja) 10:11, 12 sty 2023 (CET)[odpowiedz]

  • Wpisałem się w tej samej sprawie w dyskusję Pawła Ziemiana, który wczoraj wieczorem edytował szablon. Kenraiz (dyskusja) 10:47, 12 sty 2023 (CET)[odpowiedz]
    Przydałoby się przynajmniej doraźnie przywrócić wersję sprzed ostatnich zmian, bo szablon jest często używany, a teraz się posypał. Ja zupełnie nie jestem "techniczny", więc proszę o pomoc.
    Trafiłem też na takie coś: Dyskusja wikipedysty:Archivald./Mikrowarsztat poprawy układów wielokolumnowych – czemu takie tematy nie są omawiane w Kawiarence technicznej, tylko gdzieś w przestrzeni prywatnej? Używam szablonu w kilkuset artykułach o taksonach o randze wyższej od gatunku. Byłoby fajnie wiedzieć, co się z nim dzieje i co planuje się w nim zmienić. Kenraiz (dyskusja) 11:07, 12 sty 2023 (CET)[odpowiedz]
    W podglądzie edycji użycie szablonu generuje błędy. Póki co zapisuję edytowane artykuły w plikach txt. Kenraiz (dyskusja) 11:13, 12 sty 2023 (CET)[odpowiedz]
  • [konflikt] Chodzi o to aby podawać minimalną szerokość kolumny a nie liczbę kolumn. Bo ta wygląda całkowicie inaczej na monitorze 24" a inaczej na komórce. Szablon dobiera liczbę kolumn do zadanej minimalnej szerokości kolumny. Ale o szczegóły pytajcie Pawła. ~malarz pl PISZ 11:09, 12 sty 2023 (CET)[odpowiedz]
    Parametr "szerokość" dotąd służył właśnie do ustalania minimalnej szerokości (wyrażanej w px, teraz zmieniono na "szerokość kolumny wyrażaną wierszami tekstu" – nie wiadomo, o co chodzi). Kenraiz (dyskusja) 11:13, 12 sty 2023 (CET)[odpowiedz]
    • Dalej możesz używać z px, choć z em jest generalnie lepiej (przy powiększaniu czcionki zobaczysz różnicę). Jest błąd w wyświetlaniu czy tylko komunikat o błędzie wywołania widoczny w podglądzie edycji? ~malarz pl PISZ 11:43, 12 sty 2023 (CET)[odpowiedz]
    Użycie px wyświetla na podglądzie komunikat "Nieprawidłowe/puste pola: szerokość" oraz na oknem edycji "Błąd skryptu". Ogarnąłem, że em to liczba znaków w kolumnie (w dokumentacji szablonu "liczba wierszy tekstu" to chyba błąd?). Ok, ta zmiana wygląda na uzasadnioną (szkoda tylko, że wprowadzona bez konsultacji/uprzedzenia edytorów). Kenraiz (dyskusja) 11:57, 12 sty 2023 (CET)[odpowiedz]
    Dodałem px przy sprawdzaniu parametrów ([ep][mx]).
    Przydało by się też rozszerzyć zakres z dwóch cyfr na 3 (dla ok. 4,5 tys. art. z px). (Edycja: z czego część to mogą być inne szablony) MarMi wiki (dyskusja) 13:22, 12 sty 2023 (CET)[odpowiedz]
    A może w ogóle zrezygnować z px? Dokładność co do piksela nie jest chyba potrzebna (chyba że przy kolumnach z grafikami, jeśli takie są). MarMi wiki (dyskusja) 13:52, 12 sty 2023 (CET)[odpowiedz]
    W sytuacji z grafikami odpowiedniejsza wydaje mi się galeria wstawiana tagiem <gallery>. Jeśli dobrze pamiętam ma nawet pewne wsparcie od strony JS, żeby przeskalować obrazki i dopasować dynamicznie do szerokości strony, utrzymując ich równe wysokości. Msz2001 (dyskusja) 14:02, 12 sty 2023 (CET)[odpowiedz]
    Szablon ma ułatwiać organizację treści zapisanych relatywnie wąskim tekstem na większej płaszczyźnie. Zaraz doimplementuję oddzielną obsługę px i innych niezalecanych jednostek aby nie generowały być może czerwonych komunikatów. Paweł Ziemian (dyskusja) 18:46, 12 sty 2023 (CET)[odpowiedz]
  • Uwaga do żółtawej szachownicy (lewy górny róg): zapewne miało to być tło dla obrazka Wikipedii? Bo u mnie jest przypięta do rogu przeglądarki, a nie do rogu strony (tzn. przy skrolowaniu nie pozostaje przypięta do obrazku). MarMi wiki (dyskusja) 12:56, 12 sty 2023 (CET)[odpowiedz]
  • Poprosiłem o pomoc i ponownie zapytuję, bo nie jestem w tych technikaliach za mocny: jaki mam konkretny wstawić szablon na moim profilu, by była kolumna 4 rzędowa (jest dwu). A może ktoś wstawi za mnie szablon w moim profilu [8], byłbym bardzo wdzięczny, z góry dzięki. Keres 40 (dyskusja) 13:22, 12 sty 2023 (CET)[odpowiedz]
    Jeśli chcesz, by wszyscy oglądający (z różnymi rozdzielczościami) mieli po 4 kolumny, to się chyba nie da (przy użyciu Układ wielokolumnowy). Dla siebie (swojej rozdzielczości) możesz dopasować szerokość emami tak, by wyświetlało 4 kolumny.
    Alternatywnie możesz pogrupować ręcznie na 4 kolumny używając {{Kolumny-start}}. MarMi wiki (dyskusja) 13:31, 12 sty 2023 (CET)[odpowiedz]
    @Keres 40, wstawiłem parametr szerokość do układów wielokolumnowych na Twojej stronie. Dzięki temu może się pojawić więcej kolumn. Jeśli na twoim ekranie wyświetlają się np. trzy, to zawsze możesz wartość tego parametru zmniejszyć. (diff). W ogólności natomiast (np. w artykułach) szerokość powinna być dostosowywana do zawartości spisu, a nie do osiągnięcia konkretnej liczby kolumn (bo 4 kolumny na telefonie są czymś innym niż 4 na ekranie 24"). Msz2001 (dyskusja) 13:42, 12 sty 2023 (CET)[odpowiedz]
Mam mieszane uczucia co do jednostek stosowanych w szablonie. Z perspektywy dostępnościowej fajnie by było, aby używać jednostek względnych do wielkości tekstu (jak te em, które jednak mieszają koncepcje wysokości i szerokości). Z kolei dla osoby nietechnicznej, najłatwiejsze do zrozumienia są według mnie piksele (które psują się przy indywidualnej zmianie wielkości czcionki). W CSSie z jednostek względnych, definiowanych od szerokości tekstu, jest dostępne ch (szerokość cyfry 0). Średnia szerokość znaku w typowych czcionkach to ok. 0.8ch ([9]), ale można z tego zbudować mechanizm, gdzie użytkownik podaje orientacyjną liczbę znaków w kolumnie, a szablon generuje odpowiednią szerkość. Będzie to jednocześnie proste w użyciu dla nietechnicznego edytora i dostępne dla osób korzystających z dużych czcionek. Msz2001 (dyskusja) 14:00, 12 sty 2023 (CET)[odpowiedz]
Obie wartości są orientacyjne ze względu na różną szerokość liter.
No, może ch jest trochę bardziej dokładne?
ch wprowadzono w CSS3, jeśli to (obecnie) ma jakieś znaczenie.
Poza tym jak ktoś używa innej czcionki/wielkości liter w przeglądarce to i tak mu się to rozjedzie...
Edycja: Link o em i ch na w3.org css3-values/#font-relative-lengths. MarMi wiki (dyskusja) 14:17, 12 sty 2023 (CET)[odpowiedz]
Według caniuse ch jest wspierane przez 10-letnie przeglądarki, więc nie powinno być problemu z obsługą. Zgodzę się, że wszystkie te wartości są orientacyjne, tylko według mnie ch pozwala na możliwie intuicyjną interpretację podawanej w szablonie liczby (jako przybliżona liczba znaków w kolumnie), będąc też możliwie niezależną od czcionek (niektóre są węższe, a inne szersze – wtedy obliczenia szerokości bazujące na em dawałyby gorszą dokładność). Msz2001 (dyskusja) 14:27, 12 sty 2023 (CET)[odpowiedz]
W brudnopisie mam przykładowy tekst, napisany różnymi krojami czcionki w ramce o szerokości ustalonej według wzoru 0.8ch * liczba znaków. Na czcionkach, które sprawdzałem wygląda to całkiem spoko. Msz2001 (dyskusja) 14:44, 12 sty 2023 (CET)[odpowiedz]
Dla porównania dodałem ramkę o szerokości 16em (wartość dobrana eksperymentalnie).
U mnie 4 przykłady mają taką samą szerokość, 3 się różnią (em jest dłuższe od ch).
Część może wynikać z tego, że być może nie ma u mnie niektórych fontów. MarMi wiki (dyskusja) 15:09, 12 sty 2023 (CET)[odpowiedz]
Ramka 16em ma za każdym razem dokładnie tę samą szerokość (bo w każdym przykładzie czcionka jest tej samej wysokości). Jest to jak najbardziej responsywne i dostosuje się do ustawień użytkownika. Jednak związek szerokości ramki z liczbą znaków jest wtedy słabszy (co powodowałoby rozbieżności między szerokością kolumny w znakach wpisaną przez użytkownika a rzeczywistością – o ile coś takiego zostałoby zaimplementowane).
Domyślnie na Windowsie nie ma trzech ostatnich czcionek, więc tam może się wyświetlać coś innego (albo, zależnie od systemu, inne mogą być niewyświetlane).
Dla jasności – nie jestem przeciwny em, tylko uważam, że można zrobić coś bardziej intuicyjnego, korzystając z ch (co jednocześnie nie będzie aż tak zależne od czcionki, której używa edytor). Msz2001 (dyskusja) 15:55, 12 sty 2023 (CET)[odpowiedz]
Tutaj grafika ze wszystkimi przykładowymi czcionkami, które użyłem w brudnopisie: [10]. Msz2001 (dyskusja) 16:59, 12 sty 2023 (CET)[odpowiedz]
  • Widzę, że sporo zostało już wyjaśnione. Ja nie mam mieszanych uczuć co do technicznego parametru szerokość. Jeśli natomiast chcemy ułatwić jego używanie osobom nietechnicznym to możemy równie dobrze podawać jeden parametr styl przyjmujący jakiś zbiór wartości od wąsko do szeroko dla szerokości przez liczbę kolumn od mało do dużo lub po staremu wartości szerokości CSS dla zaawansowanych. Paweł Ziemian (dyskusja) 18:46, 12 sty 2023 (CET)[odpowiedz]
  • Zmieniłem implementacje sprawdzania parametrów w szablonie tak aby zmniejszyć globalną liczbę czerwonych komunikatów błędów. Jak widać redaktorzy (i boty) ich praktycznie nie potrzebują. Chociaż przez chwilę zobaczyliśmy skalę zjawiska. Paweł Ziemian (dyskusja) 20:15, 12 sty 2023 (CET)[odpowiedz]
IMO jakaś forma ostrzeżenia przed użyciem przestarzałej formy "liczba" albo chociaż przed brakiem parametru "szerokość" powinna się pojawiać; to da szansę redaktorom, którzy od x lat stawiają dany szablon, zreflektować się, że zalecenia się zmieniły na bardziej nowoczesne (nawet kosztem ew. nowych tematów na WP:BAR że szablon się "zepsuł"). Ale ostatecznie i te zmiany, które są obecnie (1.nowa dokumentacja szablonu, 2.kategoria techniczna błędnych wywołań 3.automatyczna szerokość minimalna) to IMO krok w dobrym kierunku w stosunku do tego, co było wcześniej. Nie pomyślałem o tym, żeby początkową dyskusję z mojej przestrzeni użytkownika przenieść do kawiarenki, co spowodowało nieco zamieszania i za co @Keres 40 i @Kenraiz przepraszam Archivald. (dyskusja) 03:33, 13 sty 2023 (CET)[odpowiedz]
Teoretycznie z niczego nie wynika, by parametr "liczba" miał być przestarzały, jest natomiast używany przez wielu edytorów i w co najmniej paru tysiącach artykułów obecny. Służył do wskazania maksymalnej liczby kolumn, co miało swoją zaletę przy redakcji artykułów (np. w przypadku niewielkiej liczby elementów pozwalało uniknąć rozstrzelenia ich w jednym/dwóch wierszach albo pozwalało dobrać liczbę ilustracji do najkrótszej wersji wyświetlanej wersji). Też mam szerokie monitory (27') otaczające biurko, ale nie lubię gdy zestawienia/wykazy układają się w większej liczbie kolumn, bo stają się one wówczas mniej czytelne. Ustalenie limitu wyświetlania 3-4 kolumn było IMO użyteczne. W zestawieniach składających się z kilkuset alfabetycznie ułożonych pozycji (liczne artykuły z wykazami gatunków) umieszczenie ich w więcej niż 2-3 kolumnach bardzo utrudnia znalezienie określonego gatunku (trudno zapamiętać która kolumna od jakiej litery się zaczyna). W każdym razie zniknięcie ("przestarzenie") parametru bez dyskusji nie powinno być prawomocne. Kenraiz (dyskusja) 10:22, 13 sty 2023 (CET)[odpowiedz]
Dodanie do diva width: fit-content; może w tym pomóc - nie zwiększa liczby kolumn poza podaną maksymalną liczbę i nie rozciąga kilku kolumn na całą szerokość ekranu:
Szablon:Układ_wielokolumnowy/brudnopis/test
szerokość=auto - stała liczba kolumn
liczba i szerokość - max. liczba kolumn
liczba=auto - tylko 1 kolumna
Z tym że trzeba by wtedy też coś zrobić z elementami obok z wyrównaniem do prawej... MarMi wiki (dyskusja) 13:04, 13 sty 2023 (CET)[odpowiedz]
To wygląda bardzo interesująco. Działa całkiem nieźle jeśli podane są oba niepuste parametry szerokość i liczba kolumn. Myślę, że warto ten przypadek w ten sposób zaimplementować. Z elementami po prawej trzeba się pogodzić, a w dokumentacji zaznaczyć aby takich sytuacji unikać. Paweł Ziemian (dyskusja) 22:15, 13 sty 2023 (CET)[odpowiedz]
Warto by też ograniczyć zmianę liczby kolumn w dół do minimum 2, jeśli się da - bo zamiana w jedną listę nie ma sensu, a wręcz to utrudnienie (chyba że to akurat zawartość sekcji Zobacz też lub coś podobnego).
Link do sekcji o kolumnach podręcznika z developer.mozilla.org, może się komuś przyda. MarMi wiki (dyskusja) 22:40, 13 sty 2023 (CET)[odpowiedz]
Możliwość wyświetlania jako jedna kolumna musi być - to często jedyna opcja żeby tę listę w sposób czytelny wyświetlić na telefonie. Msz2001 (dyskusja) 22:44, 13 sty 2023 (CET)[odpowiedz]
@Kenraiz sam w sobie parametr liczba w zasadzie nie powinien być przestarzały moi zdaniem, ale jego użycie jest problematyczne. Używanie liczby kolumn bez szerokości jest problemem, bo wtedy smartfony mają wyświetlane np. 4 kolumny na bardzo wąskim ekranie i to wygląda fatalnie. Archivald chciał właśnie to poprawić i to by nie zmieniało wyglądu na desktopie.
Wybacz @Paweł Ziemian, ale to dopiero po Twoich zmianach została złamana zgodność wsteczna. Zgadzam się, że fajnie by było mieć coś co jest bardziej zrozumiałego dla przeciętnego użytkownika. Może jakieś nazwane zestawy parametrów byłby fajne... Ale też wiem, że raczej ciężko będzie na szybko wymyślić i obsłużyć wszystkie przypadki. Skłaniam się do wycofania zmian do czasu opracowania lepszej metody. Podtrzymuję, że użycie parametru liczba + szerokość w starej formie jest prawidłowe. Parametr liczba powinien działać na PC w dużej mierze tak jak działał. Nux (dyskusja) 17:53, 14 sty 2023 (CET)[odpowiedz]
@Nux Zgadzam się, że parametr 'liczba' nie powinien wymuszać podziału na określoną liczbę kolumn, a jedynie pozwalać na tworzenie nie większej liczby kolumn od wskazanej, przy zadanej szerokości kolumn. Przy nieustalonej szerokości nie powinien działać (wymuszać podziału na określoną ich liczbę), ew. można by przyjąć jakąś domyślną szerokość kolumny (dla przypadków gdy parametr 'szerokość' nie został ustalony). Kenraiz (dyskusja) 18:00, 14 sty 2023 (CET)[odpowiedz]
  • Po pierwsze Kategoria:Układ wielokolumnowy do sprawdzenia się już wyczyściła z grafik i można zobaczyć co jest nie tak w pozostałych wywołaniach. Po drugie w brudnopisie szablonu jest wersja, która traktuje parametr liczba jako maksymalną liczbę kolumn jeśli jest również podany niepusty parametr szerokość. Link do strony testowej został już wyżej podany. Wydaje mi się, że można to przenieść do szablonu głównego. Po trzecie miejmy z tyłu głowy świadomość, że wcześniej lub później wyłączą nam szerokoekranowy widok zastępując go pionową kolumną o maksymalnym rozmiarze 60em (frwiki, mediawiki itp itd). W takim interfejsie 3 lub max 4 kolumny pewnie wyjdą w sposób naturalny. Więc każde rozwiązanie ograniczające liczbę kolumn uznaję za tymczasowe. Najwyżej trzeba będzie dopasować ustalone obecnie wartości szerokości na podstawie liczby kolumn. Paweł Ziemian (dyskusja) 20:40, 14 sty 2023 (CET)[odpowiedz]
    OK, jestem za przeniesieniem wersji brudnopisowej do szablonu – odpowiada ona chyba wszystkim żywotnym interesom wyrażonym powyżej (i przywróci wcześniejszy wygląd wielu artykułom). Proszę też o zachowanie px jako jednostki szerokości; rozumiejąc funkcjonalność em, dotychczas w ogromnej liczbie artykułów szerokość była ustalona za pomocą px... Warto natomiast dodać w opisie szablonu przy em, że jest jednostką zalecaną (ew. z krótkim wyjaśnieniem, że pozwala elastyczniej dostosować szerokość kolumn do różnych ekranów i krojów czcionek). Kenraiz (dyskusja) 21:26, 14 sty 2023 (CET)[odpowiedz]
    Moim zdaniem ta wersja Tufora była lepsza. Nie jestem pewien jak miało to działać, ale w praktyce fit-content się nie sprawdza. Może coś przy przeliczeniach nie działało, bo widzę inne wartości w kodzie niże w nagłówkach sekcji. W nowym układzie dla "liczba=3, szerokość=" mam 1 kolumnę, Dla "liczba=3, szerokość=16em" mam też 1 kolumnę. Dla "liczba=, szerokość=16em" mam 2 kolumny. Coś tam chyba nie bryknęło ;).
    Nawiasem mówiąc w tym nowym widoku (V'22) będzie powiększenie na pełny ekran (na prawie pełną szerokość). Pierwotnie nie było tego rzeczywiście, więc pewnie widziałeś starą wersję. W między czasie testujący z różnych stron wpłynęli na zmianę. Nux (dyskusja) 21:30, 14 sty 2023 (CET)[odpowiedz]
    A, dobra jest OK :-). Źle było wpisane w teście. Jakby co z można sprawdzić zachowanie z v'22. Nux (dyskusja) 21:41, 14 sty 2023 (CET)[odpowiedz]
    Aha. Tylko nie wiem skąd tak wielka szerokość dla liczba=3? Tam jest "column-width:25em" czyli 25*16px, czyli 400px. To jest o wiele, wiele więcej niż w wersji proponowanej przez @Tufor. Nawet w skrajnych propozycjach nie proponowaliśmy tak wielkiego minimum. Komórki mają szerokość 360px (nawet te nowe). Nux (dyskusja) 21:47, 14 sty 2023 (CET)[odpowiedz]
    @Paweł Ziemian prosiłbym o rozpisanie jakie wartości są według Ciebie oczekiwane. W komentarzu widzę, że dla liczba=3 miało być 9em. Coś tam chyba nie wyszło. Myślę, że łatwiej byłoby zostawić te obliczenia dla CSS. Ta wersja tufora z max-width: min(...) wydawała się działać dobrze. Nie wiem z jaki problem chciałeś rozwiązać tamtym drugim switch w szablonie. Dlatego jakbyś napisał co chciałeś zrobić, to może dojdziemy jak być powinno ;) Nux (dyskusja) 21:54, 14 sty 2023 (CET)[odpowiedz]
    Wywaliłem wszystkie obliczenia do kosza. Założyłem, że ekran ma 60em na treść artykułu. Stąd 2 kolumny to 30em, 3 kolumny to 20em, 4 kolumny to 15em itd. Jednak między kolumnami jest jakiś margines, stąd szablon ma na sztywno ma zapisane (inne) sztywne wartości ||0|1|2=30em|3=25em|4=20em|5=15em|#default=12em. Im więcej kolumn tym są węższe. Ekrany smartfonów są bardzo wąskie i tam bym oczekiwał tylko jednej kolumny zawsze. Paweł Ziemian (dyskusja) 22:03, 14 sty 2023 (CET)[odpowiedz]
    Aha. No to błędne założenia po prostu. Ekran nie ma 60em. Ekran (a właściwie okno przeglądarki) ma tyle ile ma i ma tą szerokość w px. W nowym Vectorze 2022, jak sam napisałeś, ta szerokość jest jeszcze inna, bo liczy się kolumna przeznaczona na treść. Ta kolumna jest jednak też zwężana wraz z oknem przeglądarki, więc nie możesz odgórnie założyć, że ekran ma 60em. Co więcej teraz to jest jeszcze 14px, ale docelowo ma być 16px [11]. Nux (dyskusja) 22:51, 14 sty 2023 (CET)[odpowiedz]
    Ale to nie ma żadnego znaczenia. Artykuł ma być czytelny. A ścieśnianie do 3 kolumn na sztywno niezależnie od rozdzielczości obrazu nie ma sensu. Zgodzę się, że to 60em jest z sufitu. Jednak postaw się w roli redaktora gazety. Inaczej podzielisz Trybunę Ludu, a inaczej Wprost. One mają różny format, więc wymagają innej liczby kolumn. Na przeglądarkę, a więc format tekstu nie masz wpływu. Aby zachować wygodę czytania musisz zapewnić minimalną rozsądną szerokość, a tę może ocenić jedynie osoba wstawiająca szablon. 150px to nie jest wygodna kolumna do czytania długich tekstów. Praktycznie wszystko się tam łamie. W zestawie z min zależnym od szerokości wyświetlacza smartfona próbujesz wciskać teksty, które w 2 kolumnach wyglądają dobrze tylko na desktopie 22". Paweł Ziemian (dyskusja) 23:12, 14 sty 2023 (CET)[odpowiedz]
    Znaczy wiesz, tak się składa, że od kliku tygodni poprawiam wszystkie strony główne siostrzanych projektów, które teraz zaczynają wyglądać. Responsywność znam od dawna, więc trochę mnie obrażasz jak sugerujesz, że testuję na desktopie z ekranem 22" ;-). O 2 kolumnach napisałem poniżej. W skrócie: To zależy. Nux (dyskusja) 23:37, 14 sty 2023 (CET)[odpowiedz]
    Raczej chodziło mi o to, że szablon był wstawiany przez osobę korzystającą z wyświetlacza 22" lub większego. Nikt kiedyś nie myślał o responsywności. Działało to zgodnie z zasadą SOA#1. Nie możemy więc zakładać, że 2 zadeklarowane kolumny musimy na siłę wcisnąć na telefon. Podział na kolumny w takim przypadku można robić jedynie w oparciu o jedyny sensowy parametr szerokość. Oczywiście za cenę wyłączenia wszelkich kolumn w artykułach zebranych w specjalnej kategorii „bez szerokości”. Paweł Ziemian (dyskusja) 23:55, 14 sty 2023 (CET)[odpowiedz]
  • Wrzuciłem zmiany z brudnopisu do szablonu. Uaktualniłem także dokumentację. Paweł Ziemian (dyskusja) 22:37, 14 sty 2023 (CET)[odpowiedz]
    • Niestety @Nux wywalił wszystkie zmiany i przywrócił wcześniejszą wersję, która również powstała na podstawie prywatnej dyskusji. Przy okazji wycinając cały niezależny kod sprawdzający parametry i dodający kategorie techniczne. Paweł Ziemian (dyskusja) 22:51, 14 sty 2023 (CET)[odpowiedz]
      No wybacz, ale to Ty przyszedłeś ze swoimi pomysłami, które zamiast ewolucji robiły rewolucję. I bez żadnej dyskusji uznałeś je za słuszne. Tak jak to widzę. Przywróciłem wersję, która ma kategorię, którą wymyślił twórca warsztatu. Warsztatu zgodnego z opisem szablonu. Nasza dyskusja była tylko o tym, czy zrobić słabszą czy mocniejszą rekomendację dla em. Nie chcieliśmy nic wymuszać. Ja przynajmniej nie chciałem. Pomysły miałeś ciekawe, bo faktycznie szablon jest średnio intuicyjny, ale opis naprowadzał na słuszną drogę. Tak, żeby i na PC i na tablecie i na komórce wyglądało dobrze. Nux (dyskusja) 22:57, 14 sty 2023 (CET)[odpowiedz]
      Ale te 177 artykułów z ewidentnymi problemami zaraz zniknie i jak je chcesz odnaleźć? A są tam takie proste błędy jak puste pola z liczbą lub szerokością, które praktycznie nie miały żadnego wpływu na efekt działania szablonu. Jednak widziałem też szerokości bez jednostek. A to już powodowało na przykład wyłączenie dzielenia na kolumny. No i ja tej nowej kategorii przecież nie usuwałem, tylko dodałem dwie nowe. Paweł Ziemian (dyskusja) 23:08, 14 sty 2023 (CET)[odpowiedz]
      Ja tam nie upieram się przy początkowych założeniach, jakkolwiek jako laikowi zdaje mi się, że rozwiązanie Tuforowo-Nuxowe jest mniej inwazyjne; z kolei na pewno kattechy Pawła nie kłócą się z niczym i powinny zostać, bo są pomocne Archivald. (dyskusja) 23:11, 14 sty 2023 (CET)[odpowiedz]
      Przywróciłem zaimplementowane wcześniej kategorie techniczne. Paweł Ziemian (dyskusja) 23:30, 14 sty 2023 (CET)[odpowiedz]
      Kategorii nie analizowałem. Po prostu przywróciłem wersję, którą sprawdzałem i testowałem, i powinna być OK. Jeśli kategorie mają sprawdzać tylko jednostki, to jak dla mnie spoko. Nie powinno być też komunikatu na czerwono jeśli parametry są zgodne z dokumentacją. A, poprawcie jeśli się mylę, ale tam było to sprawdzane chyba? Czy to we wcześniejszej wersji? To znaczy w szczególności sama liczba=2 dla zwykłego tekstu jest OK (nawet na komórce dwie szpalty są OK). Dla listy z flagami i długimi nazwiskami może źle wyglądać, ale co tam jest w treści, to jest jednak za bardzo gdybanie jak dla mnie. Bez konkretnej treści i kontekstu ja bym powiedział, że liczba=2 jest prawidłowe... a w każdym razie nie jest błędem ;). Nux (dyskusja) 23:31, 14 sty 2023 (CET)[odpowiedz]
      IMO jeśli nie podano parametru szerokość i jednocześnie liczba > 2, powinien wyskoczyć jakiś komunikat Archivald. (dyskusja) 23:35, 14 sty 2023 (CET)[odpowiedz]
      To pełna zgoda. Jeśli liczba > 2 i szerokość pusta, to może być ostrzeżenie. Nux (dyskusja) 23:39, 14 sty 2023 (CET)[odpowiedz]
      Wstawiłem w brudnopisie. Paweł Ziemian (dyskusja) 23:48, 14 sty 2023 (CET)[odpowiedz]
      @Paweł Ziemian Hm... Nie pamiętam czy moduł Sprawdź obsługuje inne niż domyślne komunikaty? Teraz przy wpisaniu liczba=3 jest Nieprawidłowe/puste pola: "liczba". A to w sumie nie do końca prawda. Znaczy trzeba dodać np. "szerokość=10em", a nie zmienić parametr z liczbą. Jeśli nie, to może ogólnie zamiast podawać nazwę szablonu mógłbyś dorzuć link do opisu szablonu? Np.:
      Nieprawidłowe/puste pola: „liczba” (zobacz opis szablonu).
      Długość takiego tekstu powinna być podobna, więc chyba nic się nie rozleci. Ew. może samo zobacz opis. Co myślisz? Nie zepsuje nic w innych miejscach? Nux (dyskusja) 00:07, 15 sty 2023 (CET)[odpowiedz]
      Już dawno miałem z nazwy szablonu zrobić link. Paweł Ziemian (dyskusja) 10:56, 15 sty 2023 (CET)[odpowiedz]
      @Paweł Ziemian Jak dla mnie OK :) Nux (dyskusja) 17:10, 15 sty 2023 (CET)[odpowiedz]
      Wstrzymałbym się na razie z dodawaniem tego warunku do szablonu. Wolałbym go dodać dopiero po wyczyszczeniu obecnej kategorii z innych błędów. No i moim zdaniem podawanie tylko liczby kolumn zawsze powinno być błędem, a te wywołania zbiera pierwsza dodana techniczna kategoria. Paweł Ziemian (dyskusja) 11:12, 15 sty 2023 (CET)[odpowiedz]
    A może by odstąpić w ogóle od podawania wartości liczbowych do szablonu? Parametr szerokość określa jedynie minimalną szerokość kolumny i tak naprawdę trudno zauważyć, jaki ma wpływ na wygląd listy, jeśli się nie zrobi dużych zmian wartości. W większości przypadków nie ma różnicy między np. 200 a 240 pikseli albo 21 a 28 em. Dlatego wartość podana w polu szerokość to nie precyzyjnie dobrana liczba ale raczej coś, co wygląda dobrze u edytora.
    W takim razie, proponowałbym zamiast podawania konkretnej liczby, wybór jednej z czterech możliwości szerokości (punktem odniesienia dla szerokości kolumn będą urządzenie mobilne o szerokości ok. 400px oraz desktop z Wektorem 2022 i pełnej szerokości treści 60em, czyli najpowszechniejsze według mnie ustawienia po przełączeniu domyślnej skórki):
    • szeroko – dwie kolumny na desktopie i jedna na mobilnych (np. 25em)
    • średnio – trzy kolumny na desktopie i jedna na mobilnych (np. 18em)
    • wąsko – cztery kolumny na desktopie i jedna na mobilnych (np. 14em)
    • bardzo wąsko – pięć/sześć kolumn na desktopie i dwie na mobilnych (np. 9em)
    Takie podejście z jednej strony pozwoli uprościć wikipedyście podejmowanie decyzji, jaką szerokość wybrać, a z drugiej strony ujednolici wygląd artykułów i zapewni ich dostępność na różnych ekranach. Msz2001 (dyskusja) 12:25, 15 sty 2023 (CET)[odpowiedz]
    Z jednej strony tak, nazwy mogłyby być lepsze, ale to nie jest tylko szerokość. Masz tu dwa aspekty i oba są istotne -- minimalna szerokość kolumny i maksymalna liczba kolumn, czyli liczba kolumn przy zachowaniu minimalnej szerokości. Aspekt tego powiązania jest chyba najmniej intuicyjny (dlaczego wpisujesz 3 i nie ma 3). Z drugiej ta maksymalna liczba kolumn też jest istotna. Zwracałem na to uwagę już po zmianach Pawła, pisał o tym też m.in. Kenraiz tutaj w aspekcie praktyczny. Tak że i tak nie widzę możliwości rezygnacji z liczby kolumn.
    Tu tak nawiasem mówiąc muszę dodać dla mniej technicznych, że responsywność jest trudna do policzenia, ale tego właściwie nie powinno się liczyć. Trzeba wcisnąć CTRL+SHIFT+M (FF) i znaleźć tzw. punkty przełamania dla danej zawartości, albo przynajmniej danego rodzaju zawartości. Sprawdzić czy ładnie się zawija wszystko. I pamiętać, że nie można patrzeć na szerokość okna. Należy patrzeć jak zachowuje się zawartość (treść, obrazki), a nie jaka jest chwilowo szerokość kolumny, okna itp. sorry musiałem mały wykład zrobić ;)
    Teraz wracając do rozmiarów kolumn. O ile różnicą 1-2px bym się nie przejmował, to 2em to już nie jest tak mało. 2em to jest ok. 30px, to jest rozmiar sporej ikony. Na wiki to 2em to więcej niż rozmiar flagi (22px). Czyli lista z flagami np. będzie wyglądać ok np. na 12em, a bez flag na 10em. Raczej bym to policzył procentowo, co w efekcie da największą różnicę przy największych wartościach.
    Nie jestem pewien czy polskie, długie nazwy to dobry pomysł. Zbyt łatwo o literówki, skomplikowane do wpisania, a poza tym możesz to odmieniać różnie (średnio, czy średnia?). Tailwind poszedł w jakieś dziwaczne skróty dwuliterowe. Ja bym raczej skłaniał się do standardowych nazw rozmiarów ubrań. Łatwiej jest więcej rozmiarów obsłużyć przez xxxxl nawet ;)
    No i teraz główny problem -- jak raz to ustalimy to już nigdy nie będzie można tego zmienić. Ludzie będą tego używać tak jak to widzą i wybiorą pewnie rozmiar według tego co wygląda ładnie dla wpisanej treści. I jakakolwiek zmiana będzie potem zasadniczo nierealna.
    Czyli pytanie jaka powinna być szerokość M? Moim zdaniem to powinna być szerokość, która jest OK dla większości rodzajów zawartości. A jaka jest szerokość jest zazwyczaj OK?... No i tu należy wrócić do Mikrowarsztat poprawy układów wielokolumnowych (są tam zrzuty ekranu). Dla 10em zmieszczą się długie polskie wyrazy, klika krótkich, 2 średnie wyrazy. Dla 12em nieźle wygląda lista nazwisk z flagami. Dodatkowe 1-2em na listę wypunktowaną. Tak że wychodzi mi, że ok. 14em, może 15em to jest średnia. Nux (dyskusja) 16:46, 15 sty 2023 (CET)[odpowiedz]
    Z rozmiarami ubrań też trzeba uważać - ostatnio była afera z metką rozmiaru ss... MarMi wiki (dyskusja) 17:36, 15 sty 2023 (CET)[odpowiedz]
    Zgodzę się, że tę responsywność trudno jest wyliczyć/określić. W mojej opinii, dlatego właśnie tak popularna była sztywna liczba kolumn. Bo to jest parametr dyskretny, którego wartości są dobrze oddzielone i mają intuicyjną interpretację (każdy wie, ile to są np. trzy kolumny). Nie da się tego powiedzieć o szerokości, która dziedzinę ma bardzo szeroką, ale coś się dzieje tylko po przekroczeniu pewnych progów (zależnych od urządzenia). Stąd właśnie pomysł na zdyskretyzowanie wszystkich typowych zachowań i potrzeb. Tak naprawdę do każdej kategorii można wrzucić i minimalną szerokość kolumny i maksymalną liczbę kolumn. De facto dawałoby to możliwość majstrowania przy tych parametrach nawet z poziomu CSS i zapytań mediów (żeby np. zezwolić na gęsty układ dwukolumnowy na mobilkach, ale rozepchnąć go trochę na większych urządzeniach).
    Co do samych nazw, chyba najlepszym wyborem byłby schemat rozmiarów ubrań, bo szybki do wpisania i nie ma multum form fleksyjnych :D.
    Jeśliby przyjąć średnią za te ok. 14-15 em, to nie ma problemu by zaproponowaną przeze mnie skalę „przesunąć” i zrobić S-XL Msz2001 (dyskusja) 20:10, 15 sty 2023 (CET)[odpowiedz]
    W sumie to można to chyba prościej i bardziej ewolucyjnie załatwić. Dodałem wartości sugerowane, które na pewno są obsługiwane przez VE jako menu, z którego można wybrać wartości. Z tego jakie są sugerowane wartości powinno jakby samo wynikać, które z nich są duże, a które są małe. Na ten moment to jest jako Combobx w VE, czyli oprócz sugerowanych można i tak wpisać własną wartość. To chyba załatwia sprawę?
    Dodałem też automatyczną wartość jako 14em, czyli jak ktoś nie będzie chciał w tym grzebać, to wpisze mu się 14em. Szablon:Układ wielokolumnowy#Parametry szablonu (strukturyzacja VE).
    Aha, nie wiem jak to działa w narzędziu do wstawiania szablonów w kodzie (w tym pop-up z formularzem). Nie miałem okazji przetestować, ale można sprawdzić jak się cache wyczyści. Mam nadzieję, że nie będzie negatywnych niespodzianek w postaci jakiejś dziwnej implementacji ;) Nux (dyskusja) 20:28, 15 sty 2023 (CET)[odpowiedz]
    Mnie satysfakcjonuje takie rozwiązanie. Msz2001 (dyskusja) 20:33, 15 sty 2023 (CET)[odpowiedz]
    Eeee, ten, tego. Minimalna wartość szerokości w sprawdzarce to 10em. 9em nie łapie się na wyrażenie regularne [1-9][0-9]. Poza tym zwężanie na siłę aby wyszły 2 kolumny na komórce to trochę przesada. Moim zdaniem 12em to już bardzo wąsko i tyle pierwotnie ustawiłem domyślnie minimalnie w swojej wersji szablonu. Przy czcionce 14px daje to 168px. Natomiast ekran telefonu jest nie dość, że wąski, to też krótki, więc i tak trzeba go w kółko przewijać. Nie widzę tam zysku z drugiej kolumny. Paweł Ziemian (dyskusja) 22:13, 15 sty 2023 (CET)[odpowiedz]
    Zysk z 2 kolumn jest taki, że ktoś nie zainteresowany listą ma znacznie mniej do przewinięcia przy dwóch kolumnach niż przy jednej.
    Zakładam, że żeby zobaczyć drugą kolumny wystarczy przesunąć stronę w poziomie (zakładając, że widać że coś tam dalej jest) - ale nie używam komórki (do przeglądania list), więc w praktyce może być inaczej. MarMi wiki (dyskusja) 22:20, 15 sty 2023 (CET)[odpowiedz]
    Ale druga kolumna się nie pojawi jeśli się nie zmieści. To działa tak samo jak na desktopie. Jak zaczniesz zwężać przeglądarkę to zadeklarowana maksymalna liczba kolumn spada aż do jednej. Paweł Ziemian (dyskusja) 22:37, 15 sty 2023 (CET)[odpowiedz]
    Możesz zobaczyć WŹ na telefonie. Nie wszystko jest tam jeszcze idealnie, ale kolekcje się spokojnie mieszczą w dwóch kolumnach. Indeksom też niewiele brakowało by się mieściły oba w dwóch kolumnach... Choć zależnie jak na to spojrzeć, to same litery indeksu są w 9 kolumnach (grid, ale wizualnie kolumny)... Tak jak mówiłem -- nie możesz z góry założyć, że jakaś szerokość będzie na pewno zła. Musiałbyś znać zawartość, a tą zna tylko osoba wstawiająca/edytująca szablon. W każdym razie 9em może być jak najbardziej OK, a może nawet i 5em czy 2em w jakiś dziwnych przypadkach. Nux (dyskusja) 22:50, 15 sty 2023 (CET)[odpowiedz]
Przykład złego wyglądu na komórce z liczba=3 (bez podania minimalnej szerokości) Nux (dyskusja)
  • Zapraszam do sprzątania Kategoria:Układ wielokolumnowy do sprawdzenia. Idzie jak burza. Dużo jest do usunięcia szablonów z liczba=1. Nawet pusty szablon znalazłem. Generalnie uważam, że wartość domyślna 14em jest bardzo dobra jako minimalna. Często daję więcej po podglądzie (trzeba sobie dodatkowo przeglądarkę zwęzić/rozszerzyć do testów). To są zazwyczaj listy wypunktowane i lepiej wyglądają jeśli treść każdego punktu nie musi się zawijać ze względu na wąską kolumnę. Paweł Ziemian (dyskusja) 22:59, 15 sty 2023 (CET)[odpowiedz]
    Zerknę. PMG (dyskusja) 14:54, 17 sty 2023 (CET)[odpowiedz]
  • Przy dwóch lub 3 kolumnach nie widzę istotnej różnicy między podawaniem liczby kolumn lub ich szerokości. Obydwa sposoby mają wady i zalety. Edytowanie zaś artów tylko w tym celu, by zamienić liczba kolumn=2 na szerokość 12 em uważam za zwykłe zabawianie się artami. Właśnie zauważyłem, że niektórzy to robią. Wygląda to tak, jak gdyby ktoś na siłę chciał sobie znaleźć jakąś robotę; nudne to strasznie, ale za to dużo edycji, żaden wysiłek, intelektualny, no chyba, że płacą za liczbę edycji, albo komuś zależy na miejscu w rankingu edycji ... Selso (dyskusja) 19:16, 18 sty 2023 (CET)[odpowiedz]
    @Selso zapewniam Cię, że to nie jest sztuka dla sztuki. Stety/niestety większość naszych czytelników korzysta z telefonów komórkowych (a w każdym razie większość Polaków) [12]. Trochę rozmawialiśmy o tym na Discordzie wcześniej (tam łatwiej screeny wrzucić) i również w warsztacie Archiwalda są screeny: Wikipedysta:Archiwald/Mikrowarsztat poprawy układów wielokolumnowych. Moim zdaniem bardzo zacna inicjatywa i mocno kibicuję poprawiaczkom i poprawiaczom :). Nux (dyskusja) 19:37, 18 sty 2023 (CET)[odpowiedz]
    @Selso tu kilka screenów jak to wyglądało przed 9 stycznia: 1 2 3. Choć zgodzę się z Tobą że w tej chwili poprawki twardego wywołania 2 kolumn są mniej naglące ponieważ szablon automatycznie wychwytuje problem i ustawia wyświetlanie jednej na wąskim ekranie. Niemniej jest to wynikiem właśnie tej wieloekranowej dyskusji a wcześniej (tj od. 2012 roku) szablon na telefonach wyświetlał się błędnie nawet przy dwóch kolumnach. Te zmiany są raczej naturalnym pójściem w kierunku większej dostępności artykułów w momencie kiedy zdaje się ok. 65% ruchu na wikipedii jest z urządzeń mobilnych. Pzdr Archiwald (dyskusja) 19:48, 18 sty 2023 (CET)[odpowiedz]
    @Nux@Archiwald. Screny nie bardzo rozumiem. Przed chwilą oglądnąłem na komórce art. Czacha (szer=2 kolumny) i art Dupa Słonia (3 kolumny poprawione na em). Ten pierwszy art. nie wygląda źle, w drugim arcie kolumny zniknęły. No teraz widzę, że układ z ilością kolumn wygląda na komórce dobrze, gdy jest ich nie więcej niż dwie i nie są bardzo szerokie. Ale takie warunki spełnia co najmniej 90% układów dwukolumnowych. Selso (dyskusja) 20:07, 18 sty 2023 (CET)[odpowiedz]
    nie, nie zniknęły, zamieniły się tylko w układ jednokolumnowy... Selso (dyskusja) 20:19, 18 sty 2023 (CET)[odpowiedz]
    Jest tak jak mówisz. W tej chwili jednak Doopa Słonia wygląda w mojej opinii znacznie czytelniej niż Czacha. Jeszcze gdyby poprawić wywołanie pogrubienia średnikami na zwykłe pogrubienie byłoby perfekcyjnie. Generalnie te poprawki w układzie kolumnowym są wartością dodaną ale faktycznie mogą budzić pewien opór (natłok w obserwowanych itp.) Myślę sobie że moze nie byloby złym pomyslem gdyby robić je z flagą bota. Inną opcją moglaby być rezygnacja z poprawiania wywołań jeśli korekta ma znaczenie estetyczne - czyli poza przypadkami kiedy wywołanie jest nieczytelne Archiwald (dyskusja) 20:42, 18 sty 2023 (CET)[odpowiedz]
    Tak, dwie szerokie kolumny mogą się nie mieścić na komórce i wtedy robi się jedna kolumna. To może być nie intuicyjne w pierwszej chwili, ale jest normalne. @Selso zajrzyj na {{Układ wielokolumnowy}} dodaliśmy z Michałem parę przykładów, które mogą pomóc zrozumieć jak to działa. Zwłaszcza Przykład 4 vs Przykład 5.
    Co do zmian tego typu, to moim zdaniem poprawa układu - nawet jako samodzielna zmiana - jest OK. O ile wiem poprawianie disambów czy dodawanie kategorii jest uznawane za OK, a w sumie to zmiana linka w zasadzie jest niewidoczna w treści. Zmiana układu to jest zmiana, która poprawia czytelność głównych treści artykułu na komórce/tablecie. Nux (dyskusja) 21:25, 18 sty 2023 (CET)[odpowiedz]
    Z Google na komórce korzystam rzadko. Faktycznie na komórkach układy jednokolumnowe są lepsze. Ale urządzenia multimedialne to nie tylko komórki; to są także laptopy, tablety i inne jak ich tam zwią. Czy obecne komórki długo się utrzymają? Zdaje się, że ich czas mija, coraz częściej słychać o ekranach rozwijanych do wielkości monitorów i innych wynalazkach. Może nie warto sprowadzać całej wikipedii tylko do rozmiarów komórki? Selso (dyskusja) 22:14, 18 sty 2023 (CET)[odpowiedz]
  • Poprawiając wywołania szablonu uważam, że 2 kolumny to jest praktycznie najsensowniejsza wartość na ograniczanie liczby kolumn. Patrząc przez ekran komórki, może to być chyba jedyna prawidłowa wartość. Liczba kolumn 3 lub 4 to wartości pasujące na normalny monitor lecz moim zdaniem już nawet one są dyskusyjne. Wyższe wartości powinny być zdyskwalifikowane. Nie ma sensu dzielenie tekstu na 5 kolumn. Jeśli szerokość stanie się polem obowiązkowym i wszędzie podanym, to lista podzieli się na tyle kolumn ile będzie mogła automatycznie. Jak już gdzieś wcześniej wspominałem, gdy nadejdzie domyślna „wąska” skórka, to przy domyślnej szerokości 14em uzyskamy co najwyżej 4 kolumny. Chciałbym zauważyć, że podział na kolumny jest motywowany właśnie tym, że mamy długą listę relatywnie krótkich tekstów, które na monitorach komputerowych dają wielką białą plamę po prawej stronie. Naturalne jest aby to lepiej zagospodarować. W efekcie każdy redaktor dzieli na tyle ile mu pasuje na jego ekranie. Stąd zakładam, że im jest większa liczba kolumn w szablonie tym węższe kolumny potrzebuje, a więc mniejsza szerokość do przypisania. Jestem za przebotowaniem wywołań zawierających 3 lub więcej kolumn o uzupełnienie wywołań o brakującą szerokość według jakiegoś sztywnego wzoru. Najlepiej takiego, który próbowałem zaimplementować w szablonie, co mi @Nux wycofał gdyż wrzuciłem to bez dyskusji. Chociaż teraz mnie naszło, że można tak dobrać nastawy, aby to co ma zadane 5 lub 6 kolumn dawało 2 kolumny na komórce. Paweł Ziemian (dyskusja) 22:47, 18 sty 2023 (CET)[odpowiedz]
    Cieszę się, że przekonałeś do widoku dwóch kolumn ;). Szkoda męczyć bota i serwery jak można to samo CSS-em załatwić. Po zmianie tufora, która wprowadził minimalną szerokość kolumny tak właśnie powinno być. Jeśli masz przykład, w którym tak nie jest, a powinno, to podeślij. Powinno dać się poprawić. Nux (dyskusja) 00:45, 19 sty 2023 (CET)[odpowiedz]

speedwayu21 prowadzi na stronę NSFW

Link *.speedwayu21.com (39 sztuk) prowadzi na stronę z reklamami NSFW, przydało by się podmienić je botem na archiwa (część linków jest np. w bibliografii). MarMi wiki (dyskusja) 12:46, 15 sty 2023 (CET)[odpowiedz]

Gdy już sprawa z tymi linkami będzie załatwiona, to się go dopisze do czarnej listy. XaxeLoled AmA 12:59, 15 sty 2023 (CET)[odpowiedz]

Skrypt DNU

Skrypt do półautomatycznego zgłaszania do poczekalni generuje kod:
=== [[:nazwa artykułu]] ===
: {{lnDNU|nazwa artykułu}}
z nagłówkiem III, a nie II rzędu, jak to obecnie Poczekalnia lubi. Trzeba usuwać ręcznie (zob. poprawka Adamta ); można prosić o poprawkę, żeby od razu było dobrze? Felis domestica (dyskusja) 17:01, 15 sty 2023 (CET)[odpowiedz]

Zaktualizowałem stronę z opisem: diff. Załatwione Msz2001 (dyskusja) 22:03, 15 sty 2023 (CET)[odpowiedz]

orderowe pxpx

Coś gdzieś nie zasiadło dobrze i linter zgłosił całe zatrzęsienie błędów w plikach na przykład tutaj cała strona. Gdzieś pewnie w szablonie order, ale coś się skopało. PMG (dyskusja) 23:09, 15 sty 2023 (CET)[odpowiedz]

Co mogłem, to usunąłem z tych błędów. Nie wiem tylko, jaki błąd oznaczają puste bloki kodu (w konsoli jako <code></code>). XaxeLoled AmA 16:52, 16 sty 2023 (CET)[odpowiedz]
To chyba [[Plik:przykład.jpg|thumb||Opis zdjęcia]] i podobne. [16], [17], [18] ~malarz pl PISZ 17:23, 16 sty 2023 (CET)[odpowiedz]
Hmm... nawet nie pomyślałem, że to może być przez to :-). XaxeLoled AmA 18:40, 16 sty 2023 (CET)[odpowiedz]

Szablon:Infobox

Brak w PLWP szablonu Infobox Wikidata:Q5626735, który jest obecny w 250 wersjach. Eurohunter (dyskusja) 20:41, 16 sty 2023 (CET)[odpowiedz]

Wiadomości techniczne: 2023-03

MediaWiki message delivery 02:09, 17 sty 2023 (CET)[odpowiedz]

Załatwione ~CybularnyNapisz coś ✉ 08:09, 17 sty 2023 (CET)[odpowiedz]

Działanie narzędzia "Odpowiedz" w skórce mobilnej

Dzisiaj użyłem tego narzędzia w tej edycji. Sprawdziłem co wysyłam (pisałem w trybie edycji kodu, ale przełączyłęm się na wizualny). Dwóch pierwszych linijek zapisanego w edycji tekstu w edytorze nie było. Faktycznie edytor trochę "świrował" i po drodze sam mi kasował jakieś kawałki tekstu. Jak widać, on je tylko ukrył, ale potem zapisał do bazy.

Xiaomi Redmi Note 11 Pro 64 GB, wersja Androida 12 SP1A.210812.016, przeglądarka Firefox wersja 108.2.0 Gżdacz (dyskusja) 08:21, 17 sty 2023 (CET)[odpowiedz]

Globalny(?) MediaWiki internal error

Co to było? Najpierw enwiki, potem plwiki.
Original exception: [ebc22ad0-c1a6-483d-a39d-710b7c87c1ad] 2023-01-17 18:41:40: Fatal exception of type "ConfigException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. MarMi wiki (dyskusja) 19:46, 17 sty 2023 (CET)[odpowiedz]

Wszystkie (albo większość) wiki padło. Patrz T327196. AramilFeraxa (Napisz do mnie!) 19:47, 17 sty 2023 (CET)[odpowiedz]
I jeszcze miałem przy wejściu na common.js: [4dc2de94-4bf2-4177-ab58-544b75a2a24c] 2023-01-18 00:54:28: Krytyczny wyjątek typu „Shellbox\ShellboxError”. MarMi wiki (dyskusja) 02:14, 18 sty 2023 (CET)[odpowiedz]

W wersji mobilnej wyświetla się data dostępu do źródła. W wersji komputerowej nie ma nic takiego. W tym przypadku szablon powinien (chyba) zupełnie zignorować zbędny parametr. 2A00:F41:38E7:AF1A:BD39:8FEF:AC99:F7C7 (dyskusja) 11:25, 18 sty 2023 (CET)[odpowiedz]

Tu akurat bardziej chodzi ze w wersji mobilnej pokazuje date dostepu a w normalnej nie pokazuje (a czy on jest zbedny to chyna nie)--Ignasiak (dyskusja) 22:43, 18 sty 2023 (CET)[odpowiedz]

Pionowe szablony nawigacyjne

Chciałbym podnieść tu problem szablonów nawigacyjnych o pionowym układzie. Obecnie popularnie stosuje się szablony poziome umieszczane na końcu artykułu. Pozostała jednak wielka ilość stosowanych dawniej szablonów pionowych wrzucanych na początek artykułu. Szablony te są destrukcyjne dla formatowania, często zajmują ogromną nieproporcjonalną do "funkcjonalności" część przestrzeni ograniczając lub utrudniając np. sensowne zilustrowanie artykułu. Często też (poprzez zawieranie w sobie ilustracji) wprowadzają w błąd bo pierwsze co widzi czytelnik to ilustracja z szablonu (często zupełnie niezwiązana z artykułem). Problem podnoszony kiedyś w związku z relikwiami - wtedy przerobiłem szablon na poziomy i jako że artykułów nie było dużo, to jakoś to przeklikałem w każdym z nich... szablonów takich jest jednak więcej a liczba artykułów które je wykorzystują uniemożliwia przepracowanie tego ręcznie. Czy dałoby się zatem przelecieć to botem? - poprzez zmianę szablonów na poziome i przerzucenie ich na koniec w artykułach które je wykorzystują? Jak to wygląda pokażę na pierwszym z brzegu przykładzie: artykuł jarmułka - 90% przestrzeni zajmuje rozciągnięty szablon "Judaizm" Sumek101 () 11:44, 18 sty 2023 (CET)[odpowiedz]

  • Dałoby się, ale:
    • przeniosłem chyba już kilkadziesiąt podobnych szablonów, przy niektórych zmiany były cofane (również w wywołaniach), więc lepiej to do końca przedyskutować
    • czasami są dwa szablony (poziomy i pionowy) - wtedy trzeba je scalić, ale bot tego nie wymyśli
    • czasami w szablonie są nietypowe rzeczy (ilustracje, specjalne formatowania) - które trzeba raczej sprawdzić/poprawić ręcznie
    Z dwóch ostatnich powodów lepiej jest przerobić szablon ręcznie (co nie jest kłopotliwe po ujednoliceniu kodu szablonów) i botem przeniesienie ich na koniec artykułu. Tych szablonów nie jest też za wiele: Kategoria:Szablony nawigacyjne – pionowe. Znacznie gorsze są różnego rodzaju szablony pseudonawigacjne (zrobione bez {{szablon nawigacyjny}}). Ale tych tym bardziej botem się nie przerobi. ~malarz pl PISZ 12:36, 18 sty 2023 (CET)[odpowiedz]
    szablony pionowe powinny zniknąć. Być moze spełniały kiedyś swoje funkcje - teraz już nie.--Kerim44 (dyskusja) 19:09, 18 sty 2023 (CET)[odpowiedz]