Wikipedia:Kawiarenka/Kwestie techniczne

Dla czytelników

Pierwsze kroki

Portal wikipedystów

Zasady

Współpraca

Społeczność

Szablony

Pomoc

Wikipedyści

Komunikacja

Konflikty

Kawiarenka pod Wesołym Encyklopedystą – kwestie techniczne

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

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

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

Nowy wątek

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)

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)

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

A chodzi o artykuł w przestrzeni głównej czy jakiś poza nią? Konkretne przykłady? Screeny? tufor (dyskusja) 17:53, 16 lis 2022 (CET)

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

        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)

        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)

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

        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)

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

I jeszcze tu: https://sjp.pwn.pl/poradnia/haslo/zapis-daty;10340.html Michał Sobkowski _dyskusja 23:29, 16 lis 2022 (CET)

• Nie widzę problemu jeśli na wejściu szablonu będziemy podawać ISO. W przeciwnym razie w wyniki mogą być nieoczekiwane. Myślałem o takim przełączeniu po wyczyszczeniu technicznej kategorii. Ale na to szybko się nie zanosi. Ponadto można ów wynik owijać w <time datetime="RRRR-MM-DD">...</time>. Paweł Ziemian (dyskusja) 23:00, 16 lis 2022 (CET)
• Zapomniałem dodać, że należy to zrobić we wszystkich szablonach cytowania. Paweł Ziemian (dyskusja) 23:03, 16 lis 2022 (CET)

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

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)

Jest polskim formatem daty, ale dla celów "technicznych", nie w tekstach do czytania. Muzyk98 (dyskusja) 23:42, 16 lis 2022 (CET)

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)

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

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

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)

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

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)

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)

• Parametr „adres rozdziału” jest zbędny, bo mozna wpisać | rozdział = [https... Tytuł rozdziału]. Michał Sobkowski _dyskusja 18:30, 10 gru 2022 (CET)

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)

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

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)

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)

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

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 [1] 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)

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

  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)

  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)

  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)

  Można i tak, ale jest to raczej rzadko stosowane rozwiązanie. Żyrafał (Dyskusja) 02:46, 6 gru 2022 (CET)

  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)

  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)

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)

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)

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)

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)

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)

• Mój potrafi. Zwykle przed zapisem sprawdza czy artykuł jest przejrzany. Ale to czysta kurtuazja. Paweł Ziemian (dyskusja) 17:36, 10 gru 2022 (CET)
• A komu przeszkadzają kosmetyczne poprawki w nieprzejrzanych? 2A00:F41:38BB:5F6D:61C4:7A8A:CB87:540D (dyskusja) 18:24, 10 gru 2022 (CET)

  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)

  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)

  Hmm, chyba trzeba się z tym pogodzić... MarMi wiki (dyskusja) 22:56, 10 gru 2022 (CET)

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

  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)

  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)

  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)

Przypisy do Wyborczej

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

• Blokada Kanału Sueskiego w 2021 (przypisy 35, 43, 49)
• Katastrofa śmigłowca Mi-2 w Sporniaku (przypis 4)
• Polowania na Cyganów (przypis 7)
• Kazimierz Lubiński (przypisy 2, 4)
• Michał Gieleta (przypisy 1, 6)
• Przemysław Kupidura (przypis 11)
• Przyprawy bulionowe (przypis 2)
• Krzesło składane (przypis 1)
• SPATiF Sopot (przypis 4)
• Dina Boluarte (przypis 3)

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)

• Na wszelki wypadek: @masti. ~malarz pl ^PISZ 12:48, 11 gru 2022 (CET)

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)

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)

• 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)
  • i to jest problem, że najpierw jest zwracana strona przekierowania. masti <dyskusja> 20:48, 11 gru 2022 (CET)
  • Swoją drogą to w stronach jest kilka różnych opcji do wyboru, np. dla artykułu [2]:

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

• Raczej 2000. ~malarz pl ^PISZ 20:02, 27 gru 2022 (CET)
  • 2000 artykułów oczywiście. Samych przypisów więcej - jak sam zauważyłeś. ~malarz pl ^PISZ 20:04, 27 gru 2022 (CET)

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)

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)

T325019 Matma Rex dyskusja 12:27, 15 gru 2022 (CET)

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)

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

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)

• 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)
• Ewentualnie jeśli ktoś chce dodatkowo podać to można w polu "id=ISSN ...". Pozdrawiam Joee (dyskusja) 09:29, 14 gru 2022 (CET)

Moduł:Mapa/dane/Polska

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)

• Tak, możesz stworzyć taką mapę :-) Na razie w artykule podmieniłem mapę na obecną mapę Warszawy. Trochę na niej widać, że ten most był na pn od obecnego śląsko-dąbrowskiego. ~malarz pl ^PISZ 16:17, 13 gru 2022 (CET)
• @Poznaniak Czy może dałbyś radę określić współrzędne dla mapy z pliku: Plik:Podział administracyjny I RP.svg? ~malarz pl ^PISZ 16:35, 13 gru 2022 (CET)

Pomoc:Przypisy

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)

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

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)

Załatwione ~malarz pl ^PISZ 09:26, 19 sty 2023 (CET)

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)

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

  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)

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)

• To pewnie moja wina. Szczegóły w tej dyskusji. Paweł Ziemian (dyskusja) 21:10, 26 gru 2022 (CET)
  • Wycofałem swoje zmiany. To jednak trudniejszy temat. Paweł Ziemian (dyskusja) 21:21, 26 gru 2022 (CET)

Załatwione ~malarz pl ^PISZ 09:26, 19 sty 2023 (CET)

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)

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)

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)

Załatwione ~malarz pl ^PISZ 09:25, 19 sty 2023 (CET)

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)

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

Załatwione ~malarz pl ^PISZ 09:25, 19 sty 2023 (CET)

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)

• Zobacz: Pomoc:Personalizacja - porady dla zaawansowanych#Dodawanie linków do górnego paska

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)

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)

Już wiem – chodzi o modyfikację swojego JS. Dopisałem to na stronie pomocy. Michał Sobkowski _dyskusja 17:54, 31 gru 2022 (CET)

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

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

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

Załatwione ~malarz pl ^PISZ 09:25, 19 sty 2023 (CET)

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)

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

Załatwione ~malarz pl ^PISZ 09:25, 19 sty 2023 (CET)

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)

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

• Wikipedysta:Tufor/WatchCatElems.js, przycisk 👁 tam gdzie link do historii. Wargo (dyskusja) 19:52, 3 sty 2023 (CET)

  Już wiem, co się stało. Te skrypty nie działają poprawnie z nową skórką Wektor 2022, której używam. Jak się przełączyłem na starego Wektora, to pokazały się wszystkie potrzebne przyciski. Gżdacz (dyskusja) 17:42, 4 sty 2023 (CET)

  Naprawiłem. --Wargo (dyskusja) 19:26, 4 sty 2023 (CET)

Załatwione ~malarz pl ^PISZ 09:24, 19 sty 2023 (CET)

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)

Dopisałem. --Wargo (dyskusja) 19:26, 4 sty 2023 (CET)

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)

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)

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)

Gadżet nie działa z tym edytorem. Nie umieją się porozumiewać. Nikt go nie przystosował. Wargo (dyskusja) 17:58, 5 sty 2023 (CET)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Kolejny zapewne stary problem - disFixer wykrył link generowany przez Plik, ale po zmianie celu linku nic w nim nie zmienił. Podejrzewam że Plik raczej nie jest obsługiwany?
Tutaj ręcznie poprawiłem (odznaczenia), co ciekawe po tej edycji disFixer już się więcej nie pokazał przy oglądaniu poprzedniej edycji/wersji.
Edycja: A, i na liście disFixer miał tylko "Wielki Mistrz Orderu Wierności (Albania)". MarMi wiki (dyskusja) 00:40, 23 sty 2023 (CET)

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)

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)

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)

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)

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)

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)

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)

Może selektor :only-child by coś dał, albo coś podobnego ([3], [4]). MarMi wiki (dyskusja) 18:34, 7 sty 2023 (CET)

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)

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)

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)

Linter zgłasza błąd (oczekiwano RPAREN). MarMi wiki (dyskusja) 13:42, 8 sty 2023 (CET)

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)

Załatwione ~malarz pl ^PISZ 09:24, 19 sty 2023 (CET)

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)

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)

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)

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)

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)

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

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)

Dziękuję bardzo. Działa pięknie. Kenraiz (dyskusja) 17:31, 8 sty 2023 (CET)

• Nux, potwierdzam, działa znakomicie! Przerzuciłem się więc z Wikipedysta:Paweł Ziemian/Gadget-refToolbars.js na standardowy refToolbar z Preferencji, bo w wersji Pawła data nie jest wstawiana. No ale teraz zniknęła mi opcja niewstawiania znaczników cytowania, jeżeli jako nazwę przypisu wpisze się „*”. Jest to bardzo wygodne, gdy szablon chce się wstawić do Bibliografii lub LZ. Czy można by dodać tę funkcję do standardowego refToolbara? Ewentualnie może Paweł Ziemian dodałby datę do swojego refToolbara? Michał Sobkowski _dyskusja 16:13, 11 sty 2023 (CET)
  • @Michał Sobkowski Zobacz teraz. Skopiowałem najnowszą wersję i naniosłem stare poprawki dla gwiazdki. Jeśli będzie ok to wrzucę to do globalnego gadżetu, żeby już nie uciekło. Nie wiem czemu tego nie zrobiłem wcześniej. Paweł Ziemian (dyskusja) 21:42, 11 sty 2023 (CET)
    • Paweł Ziemian, dziękuję, działa! Michał Sobkowski _dyskusja 13:53, 12 sty 2023 (CET)
      • DW @Nux, @Michał Sobkowski Przeniosłem swoje zmiany do globalnego gadżetu. Paweł Ziemian (dyskusja) 18:55, 12 sty 2023 (CET)

Załatwione ~malarz pl ^PISZ 09:24, 19 sty 2023 (CET)

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)

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)

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)

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)

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

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)

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)

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)

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)

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?

• (pokaż/usuń) 11:50, 9 sty 2023 AramilFeraxa dyskusja edycje zablokuj przeniósł stronę Imperium Morza Północnego na Wikipedysta:Test1243234325/Imperium Morza Północnego w miejsce przekierowania i bez pozostawienia przekierowania pod starym tytułem (Artykuł należy dopracować) Znacznik: przeniesienie do brudnopisu (inne edycje) (podziękuj)"

Pozdrawiam, Nux (dyskusja) 20:04, 9 sty 2023 (CET)

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

• Popieram. Takie coś byłoby znacznie bardziej informatywne niż obecny opis:

Pozdrawiam, Michał Sobkowski _dyskusja 09:45, 10 sty 2023 (CET)

Również popieram. AramilFeraxa (Napisz do mnie!) 10:10, 10 sty 2023 (CET)

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)

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)

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)

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)

Dziękuję bardzo. Radagast13 (dyskusja) 18:17, 10 sty 2023 (CET)

Załatwione ~malarz pl ^PISZ 09:23, 19 sty 2023 (CET)

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)

• SOA#1. Obawiam się, że więcej technicznych info (system, skórka, gadżety) jest potrzebne --Felis domestica (dyskusja) 01:30, 11 sty 2023 (CET)

Oraz który edytor i pasek narzędziowy. MarMi wiki (dyskusja) 01:35, 11 sty 2023 (CET)

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

  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)

  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)

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

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

  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)

  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)

  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)

  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)

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

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)

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)

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)

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)

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)

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 [5]. 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)

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)

Załatwione ~malarz pl ^PISZ 09:23, 19 sty 2023 (CET)

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 [6] 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)

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

  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)

  • @Kenraiz Też tam trafiłem przypadkiem. I też mnie zdziwiło, że takie zmiany zostały omówione na prywatnej stronie wikipedysty. No ale się do niej dołączyłem. Chociaż teraz cieszę się, że w końcu trafiło to na publiczny stolik. Paweł Ziemian (dyskusja) 18:46, 12 sty 2023 (CET)

  • "Z tym "szablon się posypał" bym nie przesadzał. IMO nie ma powodu do uznania, że coś jest porozwalane. ~malarz pl ^PISZ 11:11, 12 sty 2023 (CET)

  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)

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

  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)

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

  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)

  • Przeredagowałem i uzupełniłem opis. Informacja, że szerokość 12em jest równa wysokości 12 wierszy tekstu była dość zagmatwana. Podałem, że „em” to w przybliżeniu szerokość litery „M”. Może jest to mniej precyzyjne, ale chyba łatwiejsze do zrozumienia dla laika. Michał Sobkowski _dyskusja 16:56, 12 sty 2023 (CET)
    • Tak jest 1em to rozmiar używanej czcionki, czyli $\pi \times {\mbox{oko}}$ wysokość wiersza. Paweł Ziemian (dyskusja) 18:46, 12 sty 2023 (CET)

  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)

  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)

  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)

  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)

• 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)
• 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 [7], byłbym bardzo wdzięczny, z góry dzięki. Keres 40 (dyskusja) 13:22, 12 sty 2023 (CET)

  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)

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

  • @Keres 40 ja mam monitor ultra wide 34" z rozdzielczością 4K i widzę, że na tej Twojej stronie akapity zawierają nawet po 13 kolumn. Paweł Ziemian (dyskusja) 18:46, 12 sty 2023 (CET)

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 ([8]), 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)

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)

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)

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)

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)

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)

Tutaj grafika ze wszystkimi przykładowymi czcionkami, które użyłem w brudnopisie: [9]. Msz2001 (dyskusja) 16:59, 12 sty 2023 (CET)

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

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)

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)

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)

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)

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)

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)

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

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

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

  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)

  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)

  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)

  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)

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

  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)

  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 [10]. Nux (dyskusja) 22:51, 14 sty 2023 (CET)

  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)

  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)

  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)

• Wrzuciłem zmiany z brudnopisu do szablonu. Uaktualniłem także dokumentację. Paweł Ziemian (dyskusja) 22:37, 14 sty 2023 (CET)
  • 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)

    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)

    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)

    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)

    Przywróciłem zaimplementowane wcześniej kategorie techniczne. Paweł Ziemian (dyskusja) 23:30, 14 sty 2023 (CET)

    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)

    IMO jeśli nie podano parametru szerokość i jednocześnie liczba > 2, powinien wyskoczyć jakiś komunikat Archivald. (dyskusja) 23:35, 14 sty 2023 (CET)

    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)

    Wstawiłem w brudnopisie. Paweł Ziemian (dyskusja) 23:48, 14 sty 2023 (CET)

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

    Już dawno miałem z nazwy szablonu zrobić link. Paweł Ziemian (dyskusja) 10:56, 15 sty 2023 (CET)

    @Paweł Ziemian Jak dla mnie OK :) Nux (dyskusja) 17:10, 15 sty 2023 (CET)

    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)

  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)

  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)

  Z rozmiarami ubrań też trzeba uważać - ostatnio była afera z metką rozmiaru ss... MarMi wiki (dyskusja) 17:36, 15 sty 2023 (CET)

  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)

  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)

  Mnie satysfakcjonuje takie rozwiązanie. Msz2001 (dyskusja) 20:33, 15 sty 2023 (CET)

  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)

  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)

  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)

  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)

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)

  Zerknę. PMG (dyskusja) 14:54, 17 sty 2023 (CET)

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

  @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) [11]. 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)

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

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

  nie, nie zniknęły, zamieniły się tylko w układ jednokolumnowy... Selso (dyskusja) 20:19, 18 sty 2023 (CET)

  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)

  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)

  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)

  @Selso intrygująca teza. Ale nie sądzę. Foldy póki co są za drogie i jeszcze trochę za duże (za ciężkie). Z dostosowaniem do komórek i tak jesteśmy spóźnieni już o kilka lat, a liczba czytelników wiki spada (na pewno nie tylko dlatego, ale za pewne również dlatego, że źle się ją czyta w biegu). Poza tym dzięki responsywnym układom można wyglądać dobrze i na komórce i na PC i na telewizorze. Nux (dyskusja) 10:25, 19 sty 2023 (CET)

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

  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)

  Przychylam się do opinii Ziemianina. Selso (dyskusja) 09:15, 19 sty 2023 (CET)

  Przypominam tylko, że takich zmian nie można robić masowo bez głębokiego zrozumienia czym jest Responsive web design. Ew. zmiany należałoby podzielić według kategorii artykułów tak by wiedzieć jakiego rodzaju treści się zmienia. Czy tam w treści są flagi, czy tekst, czy lista, lista zagnieżdżona, czy większe obrazki itp. Bez tego przemyślenia problem zostanie tylko zamaskowany i dobry pomysł na warsztat artykułów zostanie zniweczony. Nux (dyskusja) 10:31, 19 sty 2023 (CET)

  Tu nie potrzeba wielkiego rozumienia. Mi chodzi też o to, że nie należy ze wszystkiego robić 2 kolumny. One są dobre na dużym ekranie. Zobacz jak wyglądają informacje tygodnia na WD. Piękne 2 kolumny, a tylko jedna na smartfonie. Zgodzę się, że należy sprawdzić zawartość przed podjęciem najlepszej decyzji na temat szerokości i liczby kolumn. Jednak obecne rozwiązanie wszystko co nie ma podanej szerokości domyślnie ściśnie do 2 kolumn. Zawsze to lepiej niż 3 lub 4. Jednak ja bym oczekiwał, że 2, 3 a nawet 4 kolumny z dużego ekranu prezentować w komórkach w jednej kolumnie. Byłoby to znacznie czytelniejsze. Zrobiłem w ostatnich dniach kilka dodatkowych technicznych kategorii statystycznych. Można w nich znaleźć różne przykłady i potrenować poprawianie szablonów. Tylko, że ręcznie tego problemu nigdy nie rozwiążemy. Mamy za dużo wywołań. To można zrobić hurtowo albo botem, albo rezygnując ze sztywnej nastawy domyślnej szerokości w szablonie i wstawić tam funkcję zależną od liczby kolumn. Paweł Ziemian (dyskusja) 20:31, 19 sty 2023 (CET)

dyskusja nad zmianą w obsłudze domyślnej szerokości kolumn

• Proponuję następującą zmianę w szablonie:

Jest	Chcę aby było
{{#if: {{{szerokość|}}} | column-width: {{{szerokość}}}; | column-width: min(150px, 48vw)}}	column-width:{{#if:{{{szerokość|}}}|{{{szerokość}}}|{{#switch:{{{liczba|}}}||0|1|2=28em|3=18em|4=13em|#default=9em}}}};

Paweł Ziemian (dyskusja) 20:43, 19 sty 2023 (CET)

Nie, no już przecież rozmawialiśmy o tym. Nie możesz zrobić punktów przełamania na sztywno. Nux (dyskusja) 20:59, 19 sty 2023 (CET)

Nie rozumiem. Jakie „sztywno”? Podaj przykład gdzie to działa źle. Paweł Ziemian (dyskusja) 21:03, 19 sty 2023 (CET)

No założyłeś, że 2 kolumny się zmieszczą na ekranie, czyli zakładasz, że ekran (pole do wyświetlania) ma szerokość 28em x 2. I nie ma to nic wspólnego z zawartością ani z prawdziwą szerokością dostępną w danej skórce/urządzeniu itp. Nie widzę żadnego problemu, który by to rozwiązywało, a na pewno tworzy nowe. Nux (dyskusja) 21:09, 19 sty 2023 (CET)

Dokładnie tak założyłem, ponieważ przypuszczam, że edycja została wykonywana na komputerze z normalnym monitorem. Osoba, która wstawiała układ wielokolumnowy sugerowała się swoim gustem i subiektywnie uznała, że treść wygląda lepiej wykorzystując 2 połówki ekranu. A one mają i tak znacznie więcej niż moje proponowane 28em, więc gdzie tu jest problem? Gdyby treść była wciąż zbyt wąska, a lista długa, to pewnie prywatny gust zasugerowałby więcej kolumn. Skoro wystarczyło 2, to treść jest na tyle szeroka, lub ma więcej niż jeden poziom, że jej zwężanie grozi utratą czytelności. Paweł Ziemian (dyskusja) 21:16, 19 sty 2023 (CET)

Przepraszam, ale dokładnie te założenia po raz kolejny mi mówią, że nie wiesz o co chodzi w RWD. Nie wiem może to jakiś inny zbiór doświadczeń czy coś... Ale no nie możesz po prostu mieć takich sztywnych założeń. To jest zaprzeczenie RWD. Nie istnieje coś takiego jak standardowy monitor. W ogóle założenie, że okno przeglądarki jest zmaksymalizowane jest błędne (teraz to już nawet na telefonie niekoniecznie jest prawda). Pisałem już o tym wyżej zresztą. Np. jak nacisnę [Windows] + [→], to ile kolumn zobaczę? Jedną. Dlaczego? Spokojnie mi się 4 zmieszczą za pewne, o dwóch nie wspominając...

Myślę, czy mogę polecić jakiś dobre materiały o RWD... Taki nieco bardziej zaawansowany na pewno mogę polecić: Layout Land. Layout Land jest głównie o nowych narzędziach w CSS o gridzie i flexboksie, ale też trochę o podstawach mówi. W filmiku Flexibility & The Fold, jest w sumie o nieco innym początku, ale na początku mówi trochę o viewport (potem jest o kontrolowaniu wysokości, więc to coś co tutaj się nie przyda). Z dłuższych rzeczy na pewno mogę polecić: “Everything You Know About Web Design Just Changed” by Jen Simmons—An Event Apart video. Trochę w ciemno, bo dawno temu to oglądałem, ale Jen Simons polecam w zasadzie wszystko z CSS (Jen jest autorką paru specek, dawniej pracowała nad Firefox w Mozilli, teraz w Apple i Safari). Nux (dyskusja) 23:08, 19 sty 2023 (CET)

"Np. jak nacisnę [Windows] + [→], to ile kolumn zobaczę? Jedną. Dlaczego? Spokojnie mi się 4 zmieszczą za pewne, o dwóch nie wspominając..."
Mowa o Szablon:Układ_wielokolumnowy/brudnopis/test? Gdyby nie ten obrazek po prawej, to u mnie zmieściły by się dwie kolumny (a być może kawałek trzeciej, zakładając że dłuższe nazwy by się zawijały).
Co potwierdza wersja mobilna strony (z pl.m. w adresie).
Szerokość kolumn moim zdaniem powinna być dynamiczna w pewnym zakresie. Powinna mieć wartość minimalną - taką, przy której połowa/większość elementów jeszcze się mieści bez zawijania (np. tandem flaga + nazwa), dłuższe nazwy mogą się zawijać - po przekroczeniu której dopiero następuje degradacja liczby kolumn. Choć nie wiem czy to jest dość łatwo zrobić. Gorzej by było tylko z ustaleniem maksimum tego zakresu - zawsze może się przydarzyć jakiś jeden wyjątkowo długi wiersz, albo ktoś z ekranem o szerokości hiper ultra super wide...
Czy gridy (i fr) z Flexibility & The Fold nadają się do kolumn? MarMi wiki (dyskusja) 02:08, 20 sty 2023 (CET)

• Nie chodzi mi o konkretny przykład. Po prostu nie można się fiksować na jakiejś wielkości ekranu. Nie przelicza się tego statycznie, tylko zatrudnia się do tego przeglądarkę, która robi obliczenia sama :).
• Ale jak chcesz liczyć konkretnie, to mój laptop ma 1280px / 2 = 640px. Załóżmy optymistycznie, że czcionka ma 14px (teraz tak ma, ale ma mieć 16px). 640px / 14px = 45em. Czyli, żeby mieć dwie kolumny na pół ekranu, to one by miały ok. 22.5em. Tu pomijam margines i scrollbar i inne komplikacje (np. pasek z aplikacjami z boku). Skoro kolumny miały mieć minimum 28em, to 22.5em jest za mało. Czyli dostaję jedną kolumnę...
• Ale tak jak mówiłem przeglądarka sama to liczy ;). Ustawienia które wybierzemy w szablonie nie muszą być też perfekcyjne. Po prostu powinny zależeć od zawartości, w jakiejś minimalnej szerokości zawartość ładnie się zawija. W większości wypadków zawartością kolumn jest jakaś lista z wypunktowaniem (z marginesem), nierzadko są w niej flagi. Na większość tego typu rzeczy można dać np. liczba=5 | szerokość=14em i to powinno być OK w większości wypadków.

PS: Co do gridów i podziału na kolumny, to zależy od rodzaju zawartości (grid nie bardzo nadaje się do lanego tekstu). Tak czy inaczej to by raczej jakiś osobny szablon musiał być. Problem układu wielokolumnowego jest taki, że kolumny przełamują się w dosyć losowych miejscach, co niekoniecznie wygląda dobrze (np. dla list z nazwiskami). Gridy można by użyć do ładniejszego formatowania list, ale trzeba by dobrze przemyśleć jakie opcje powinny być w takim szablonie. Nux (dyskusja) 03:26, 20 sty 2023 (CET)

• Nie rozumiem sensu wyrażenia min(150px,48vw). To znaczy niby wiem co to znaczy. Jednak minimalna szerokość mojej przeglądarki to 437px, co w przeliczeniu dalej efektywnie min(150px,209px) czyli w stałą o wartości 150px. To oznacza, że minimalna szerokość kolumny w układzie wielokolumnowym jest stała niezależnie od przeglądarki, monitora, czcionki, czy liczby kolumn. Czy to chcieliście uzyskać? Bo ja chciałbym uzyskać coś takiego, że 2 kolumny zmieszczą na przykład około 30 liter tekstu w jednej linii bez zawijania, 3 kolumny to 20 liter, 4 to na przykład 15 liter, a więcej kolumn mniej więcej 10 liter w jednej linii. Już nawet nie interesują mnie jednostki w jakich ten rozmiar podamy. Chodzi mi tylko o ideę, że jeśli ktoś ogranicza liczbę kolumn, to podświadomie sugeruje, że ma szersze teksty w krótkich liniach. Paweł Ziemian (dyskusja) 21:19, 20 sty 2023 (CET)

  Nie wiem czemu akurat 30 liter. Natomiast 30 liter, to jest około 14-15em i około 25-27ch. Do listy z flagą pewnie może być. Kolumnom jednak nic do tego. Nie wiem dlaczego dla większej liczby kolumn chciałbyś mieć mniej tekstu. Kolumny decydują o wysokości, a nie szerokości. Nux (dyskusja) 21:45, 20 sty 2023 (CET)

  Bo nie chcę czytać na wąskim ekranie listy dwukolumnowej, której elementy zawijają się przez 4 linie. Na przykład filmografia, która często ma 2 kolumny może mieć długie tytuły. Podobnie wykaz gatunków. W wyszukiwarce jej szerokość waha się w granicach 200-400px, średnio 300px. Lista 3 kolumnowa to często imię i nazwisko, raptem 2 wyrazy. W wyszukiwarce od 150-400px, bardzo często 200px. Natomiast lista 4 kolumnowa to wykaz miejscowości jednowyrazowych, która może być wąziutka. Czy to trudno zrozumieć? Paweł Ziemian (dyskusja) 22:15, 20 sty 2023 (CET)

  Korelujesz ze sobą przypadkowe powiązania. Liczba kolumn nie decyduje o zawartości. Nux (dyskusja) 22:20, 20 sty 2023 (CET)

  A mogę prosić o wyjaśnienie odnośnie min(150px,48vw)? Czy spotkałeś się z przeglądarką o szerokości ekranu mniejszej niż 300px? Paweł Ziemian (dyskusja) 22:23, 20 sty 2023 (CET)

  Ech, normalnie jakbym Cię nie znał, to bym uznał, że trolujesz. Tak jak pisałem 11 dni temu – nie jestem przekonany do tego minimum. Wpisał je tufor jako pomysł na rozwiązanie problemu. Moim zdaniem raczej 11em byłoby bardziej przyszłościowe. Ale jednocześnie jest to tylko domyślne minimum, które powinno najmniej psuć. Gdybyś chciał podyskutować normalnie i przeczytał to 11 dni temu, to może cała ta dyskusja byłaby niepotrzebna. Po to jest warsztat i kategoria/e, żeby właśnie wpisać inne minimum. Nie na siłę, botem, tylko patrząc na konkretną treść. Nux (dyskusja) 22:40, 20 sty 2023 (CET)

  Ja wiem, że wszystko trzeba ręcznie sprawdzić. Kapitan Jastrząb zawiera listę numerowaną. Pozycja 104 zaczyna się słowem nieprawdopodobna. Musiałem wstawić szerokość 11em aby je zmieścić w kolumnie. Minimalna szerokość kolumny powinna być taka aby dać przynajmniej 2 kolumny na komórce. Jednak nie musimy każdej listy dzielić na kolumny. Te które mają zadeklarowane 2 kolumny są ok na monitorze ale moim zdaniem lepiej wyglądają jako 1 kolumna na komórce. Moim zdaniem istnieje korelacja między liczbą kolumn a treścią. Paweł Ziemian (dyskusja) 23:27, 20 sty 2023 (CET)

  A u mnie poniżej 16em szerokość się nie zmienia (są 3 kolumny), przy 16em liczba kolumn spada do 2. Czyli wiersz z nieprawdopodobna (bez końcówki) ma u mnie szerokość 15em. MarMi wiki (dyskusja) 00:07, 21 sty 2023 (CET)

  Zmieniłem minimum na 11em. Efektywnie na PC będzie póki co tak samo. Na komórce trochę będzie szerzej niż przed zmianą, ale w sumie tak samo jak na PC. Nadal zachęcam do działania zgodnie z pierwotnymi planami warsztatu. Zmiany powinny być dosyć proste. Z czasem na pewno nabierze się wyczucia co wygląda dobrze. Nux (dyskusja) 00:03, 23 sty 2023 (CET)

  Będąc dokładnym, to szerokość musiałaby wynosić poniżej 312,5 (150/0,48).
  Co było (jest?) możliwe do osiągnięcia: ux.stackexchange - 2016, popular-screen-resolutions - 2018 (iPhone 5, Touch i pewnie inne stare smartfony). MarMi wiki (dyskusja) 23:40, 20 sty 2023 (CET)

• Zamierzam wprowadzić choćby na jakiś czas proponowaną zmianę, którą zaimplementowałem w brudnopisie. Zauważyłem, że wersja mobilna ma większą czcionkę niż desktop (16px vs 14px). Wybrane przez mnie nastawy to 20em, 14em i 9em co powinno dawać odpowiednio 320px/280px (~300px), 224px/196px (~200px), 144px/126px (nie więcej niż 150px). Przy okazji jeszcze upewniłem się w historii edycji szablonu, że w mojej pierwotnej wersji zabrakło ograniczenia na maksymalną liczbę kolumn. W tej wersji nie ma tego błędu. Oczekuję, że po wrowadzeniu zmian, układ wielokolumnowy dla 2 lub 3 kolumn będzie na komórce wyświetlany domyślnie w postaci jednej kolumny, a dla 4 i więcej kolumn będą one dwie. Oczywiście na tablecie lub monitorze w wersji mobilnej będzie tego stosownie więcej. Mam nadzieję, że niczego nie zepsuję, a będzie lepiej. Paweł Ziemian (dyskusja) 22:45, 21 sty 2023 (CET)

  Ale na jakiej podstawie? Zrób sobie nowe szablon i wprowadzać tam co chcesz i zachęcaj innych do używania. Już klika razy tłumaczyłem dlaczego twoje założenia są nieprawidłowe. Nux (dyskusja) 23:05, 21 sty 2023 (CET)

  Pierwsza zmiana ustalająca szerokość na 150px z opisem test była wprowadzona bez żadnej konsultacji. Dyskusja się zrobiła dopiero po tamtej edycji. Dlaczego odbierasz mi prawo do mojej wersji? Zmienię, poklikam po kategoriach i artykułach, pooglądam. Chcę to zobaczyć. Klikanie w edit i podgląd jest jednak bardzo uciążliwe. Paweł Ziemian (dyskusja) 23:26, 21 sty 2023 (CET)

  Bo tamta zmiana nie ograniczała funkcji szablonu i nie zmieniała go w sposób zasadniczy. Napisałem to w dyskusji. Twojej zmiany też nie wycofałem od razu. Dopiero jak pojawiły się znaczące wątpliwości co do nowego sposobu działania szablonu. Nux (dyskusja) 23:46, 21 sty 2023 (CET)

Botowanie brakującej szerokości

Zamierzam uzupełniać botem szablony, które wstawiają kategorię Szablon Układ wielokolumnowy bez szerokości. W tej sekcji chciałbym ewentualnie omówić kryteria dobierania tej wartości przez bota. Każdy edytowany szablon będzie miał tę wartość dobraną indywidualnie do swojej zawartości. W pierwszym przebiegu chcę przerobić tylko proste listy jednopoziomowe. Mogę na próbę wygenerować zmiany na pewniej niewielkiej liczbie artykułów (na przykład 100) aby był materiał do dalszej dyskusji. Algorytm działania jest z grubsza następujący:

• lista dzielona jest na pojedyncze elementy, oczekiwana jest pewna minimalna liczba elementów
• dla każdego elementu określany jest jego minimalny (zawijane linie tekstu) i maksymalny (jedna linia tekstu) rozmiar poziomy
• maksymalna wartość z rozmiarów minimalnych jest minimalną szerokością kolumny
• ze statystyki wszystkich rozmiarów maksymalnych wybieram taki, żeby ustalony procent elementów listy mieścił się zawsze w jednej linii
• dodatkowo mam nastawy dla minimalnego i maksymalnego zalecanego rozmiaru kolumny, i jeśli wyliczony rozmiar maksymalny nie przekracza minimalnego zalecanego to będzie on docelową szerokością
• obliczenia wykonywane są w px, następnie konwertowane na em i zaokrąglane w górę do najbliższej liczby całkowitej.

Wstępnie przyjąłem następujące:

• minimalna liczba: 5 elementów
• ustalony procent: 90%
• minimum zalecane zależy od maksymalnej liczby kolumn w szablonie: 2 → 20em, 3 → 14em, pozostałe → 9em
• maximum zalecane również zależy od liczby kolumn: 2 → 28em, 3 → 18em, 4 → 13em, 5 → 10em, pozostałe → 9em

Czekam na uwagi. Paweł Ziemian (dyskusja) 20:33, 23 sty 2023 (CET)

SZEROKOŚĆ NIE POWINNA ZALEŻEĆ OD LICZBY KOLUMN. Dziękuję za uwagę [: Nux (dyskusja) 22:48, 23 sty 2023 (CET)

• @Nux wstawiałeś praktycznie jakąś szerokość w szablonie {{układ wielokolumnowy}}? Na próbę przebotowałem listę 10 artykułów: Gminy w Danii, San Fernando Valley Transverse Ranges, Tytulatura duchowieństwa wojskowego II RP, 0,25 mg, North American Soccer League, 1 Batalion Ciężkich Karabinów Maszynowych (II RP), 1 Morski Batalion Strzelców, 1 Pułk Lotniczy i 1 Pułk Piechoty (LP). Teraz zobacz, skrytykuj co jest źle i dlaczego, a na koniec popraw. Paweł Ziemian (dyskusja) 23:51, 23 sty 2023 (CET)

przejrzałem te przykłady i u mnie w większości wygląd nie uległ zmianie. Generalnie bot wrzuca wartości zbliżone nuxowemu 11em. Myślę że jak się przebotuje tą kategorię to nic strasznego się nie stanie ale obecnie większość z tych 10tysięcy artykułów z kategorii nie wymaga poprawek - mówię w tej chwili o wersji mobilnej; jeśli chcesz poprawić wyświetlanie na ekranach ultrawide to o ile rozumiem bot musiałby jednocześnie zdejmować parametr "liczba" bo tam z reguły kolumn jest za mało a nie za dużo.Archiwald (dyskusja) 02:29, 24 sty 2023 (CET)

z kolei na moim desktopie 8 stron nie uległo zmianie, 1 uległa poprawie (Transverse Ranges), 1 uległa raczej pogorszeniu (1 Pułk Piechoty (LP)). Ten algorytm jest bardzo pomysłowy swoją drogą i działa tak jak powinien; ale jednak pewna nieprzewidywalność układów kolumnowych (ich zawartości) skłania mnie ku niebotowaniu - może ta grupa kontrolna 100 stron o której pisałeś powiedziałaby coś więcej. Archiwald (dyskusja) 02:59, 24 sty 2023 (CET)

Część już Archiwald wyżej napisał. Ale proszę pierwszy przykład z brzegu w praktyce [12]. Artykuł powinien wyglądać spójnie dla tych samych rodzajów zawartości, a nie że bot będzie wstawiał jakieś losowe wartości. Można by do tego pewnie wytrenować jakąś formę sztucznej inteligencji, ale ogólnie to bym powiedział Wikipedia:Nie przeszkadzaj w pracy Wikipedii tylko po to, aby coś udowodnić.

Wybacz wcześniejsze krzyczenie, ale tłumaczyłem to już kilkukrotnie. Podawałem linki do materiałów... Jeśli ktoś gdzieś wstawił 5 czy 10 kolumn to nie ma żadnego znaczenia dla szerokości. Liczba kolumn ogranicza rozstrzelenie treści, czyli ogranicza zmniejszanie się wysokości. Nie wiem, wyobraź sobie rozlewanie tego samego piwa do 2 szklanek, a potem do 5 szklanek. Co zmieniłeś zmieniając liczbę szklanek? Nux (dyskusja) 07:44, 24 sty 2023 (CET)

a tu na przykład akurat bez sensu były kolumny w większości – jak jest za mało treści, to nie ma czego dzielić na szklanki. A poza tym układ wielokolumnowy utrudnia potem edycję np. w VE, więc nie powinno się go stosować jak nic nie daje. Nux (dyskusja) 07:51, 24 sty 2023 (CET)

• Po pierwsze ja wiem, że liczba kolumn nie ma znaczenia jeśli podamy szerokość. A teraz po ostatnich zmianach w szablonie w każdym układzie jest domyślna szerokość minimalna. Po drugie w większości przypadków po pracy bota nie będzie widać żadnej różnicy. Wynika to głównie stąd, że kolumn jest mało patrząc na nie przez monitor. Są one i tak dużo szersze niż szerokość zadeklarowana. Natomiast na małej komórce gdzie w porywach widać maksymalnie dwie kolumny, część z nich się zredukuje do jednej. Żeby zobaczyć różnicę trzeba zwężać przeglądarkę na monitorze aż do momentu, w którym nastepuje przełączenie liczby kolumn z 2↔1. Wtedy widać, że bot stara się nie łamać napisów w listach. Po trzecie mogę zrezygnować z ustalonych przez siebie limitów rozmiarów szerokości kolumn zależnych od liczby kolumn na jakieś globalne stałe. Tylko może warto ustalić czy wystarczy na to na przykład para 15em i 28em. Po czwarte informowałem, że każdy szablon jest traktowany indywidualnie. Zwykle występuje jeden, czasami dwa w artykule. Te gminy Danii to przypadek szczególny. Tym bardziej, że nie było wśród tych szablonów jednolitych wartości kolumn. Więc ostatnie poprawki to ogólne prace stylistyczno-typograficzno-redakcyjne, których bot nie wykona nigdy. Możemy nawet zmienić działanie bota. Obecnie minimalny rozmiar kolumny to 11em. Wobec tego bot wstawiając szerokość wybierze jakąś wartość z przedziału 11em do 28em. Nie przeszkodzi to zwłaszcza tym szablonom, którym potrzeba mniej. Zwłaszcza dla takich z listą nazw miejscowości. Natomiast poszerzenie kolumn pomoże szablonom z listą osób (z różnymi dopiskami lub flagami) oraz listom z tytułami różnych dzieł. Przygotuję kolejną próbkę. Paweł Ziemian (dyskusja) 21:41, 24 sty 2023 (CET)

  Uparłeś się, żeby to zrobić botem i zrobisz to pewnie dobrze, jak na bota, ale nie tak dobrze jak człowiek. Sprawdziłem dwa pierwsze podane przez Ciebie i dwa pierwsze były źle zrobione. Po zmianach bota artykuły znikają z kategorii do poprawy, więc nikt tego normalnie nie przejrzy.

  Są chętni ludzie, żeby to zrobić, zostaw to ludziom. Na pewno będzie na koniec pożytek taki, że będzie więcej ludzi, którzy będą umieli takie rzeczy formatować. O satysfakcji z dobrej roboty nie wspominając. Nux (dyskusja) 21:59, 24 sty 2023 (CET)

  • Liczba artykułów w kategorii to ponad 9k elementów. To nie jest na ręczną pracę. Mamy sporo kategorii technicznych, których nikt nie sprząta, a mają masę elementów na przykład Kategoria:Szablon cytuj książkę – autorzy do sprawdzenia. Dlaczego się boisz bota? Może napisz mi jak to robić lepiej. Na przykład zwiększyłeś szerokość ponad maksimum wyliczone botem. Dodatkowo zwiększyłeś liczbę kolumn. Dlaczego? Czy to jest wiedza tajemna i niemożliwa do opisania lub zautomatyzowania? Jeśli wolisz mogę wstawić jakieś wyrażenie min(14em,90vw), które też będzie w tej kategorii, a jednocześnie wskaże jakieś wartości sugerowane botem. Paweł Ziemian (dyskusja) 22:31, 24 sty 2023 (CET)

    Wszystkie informacje są już powyżej. Wystarczy się z nimi zapoznać. Nux (dyskusja) 22:37, 24 sty 2023 (CET)

• Zmieniłem zasady obliczeń. Teraz mam tylko jedną stałą wartość maksymalną 28em. Zrobiłem kolejną próbkę. Lista artykułów jest w Wikipedysta:Paweł Ziemian/Układ wielokolumnowy. Paweł Ziemian (dyskusja) 00:02, 25 sty 2023 (CET)

  Nie wiem czy rozumiesz, że działasz botem wbrew wątpliwościom wyrażonym przez co najmniej dwie osoby. I nadal stosujesz zasadniczo te same zasady. Tekst powinien się zawijać w kolumnach, a tymczasem robisz coś takiego: [13]. Naprawdę byś tak to zrobił jakbyś ręcznie to wstawiał. 28em?! To jest około 60 liter przecież! Wstawienie takich wartości nie ma żadnego sensu. Już lepiej w ogóle usunąć szablon. Nux (dyskusja) 00:13, 25 sty 2023 (CET)

• Czy mógłbyś wycofać zmiany swojego bota i przestać eksperymentować na Wikipedii? Z góry dziękuję. Dodam tylko, że moim zdaniem nie da się tego zrobić botem. To nie jest tak, że znam jakąś magiczną, prostą formułkę, tylko nie chcę się nią podzielić. --Nux (dyskusja) 00:43, 25 sty 2023 (CET)

  Cofać raczej nie ma sensu zważywszy na to że większość z tej listy nie wprowadza jakichś widocznych zmian. Może poza tym diffem który wskazałeś, jeszcze ten i ten wydają mi się raczej przestrzelone. Generalnie chyba zbyt niezauważalne są te różnice + miejscami ryzyko niepotrzebnego poprawiania po bocie. Archiwald (dyskusja) 00:53, 25 sty 2023 (CET)
  

Układy wielokolumnowe wywołane poprzez column-count

Póki temat układów wielokolumnowych nie zszedł jeszcze z tapetu to chciałem zwrócić uwagę na poboczny sposób wywołania układów, mianowicie poprzez tworzenie divów ze stylem column-count bądź moz-column-count; takich wywołań w prz. głównej jest około 1000 i o ile dobrze się orrientuję to problem z nimi jest podobny co był na początku z szablonem układu wielok., mianowicie brak minimalnej szerokości: kilka przykładów: Medycyna_ewolucyjna, Katherine_Helmond, Dynamiczny język programowania, Carl Fredrich, Electronic Sports World Cup 2010, Katastrofa górnicza w kopalni Wujek – Ruch Śląsk, James Franck, Sąd_Konstytucyjny_(Litwa), Philips Records etc. Z tego co widzę to znaczna większość tych divów jest wywołana wyłącznie w celu podziału na kolumny, tak więc może nie byłoby głupim pomysłem przebotowanie ich na Szablon:Układ wielokolumnowy? Archiwald (dyskusja) 02:12, 25 sty 2023 (CET)

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)

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)

Hmm, wszystkie boty są zajęte, nie ma takiego bota, albo za mało linków na bota? MarMi wiki (dyskusja) 23:17, 23 sty 2023 (CET)

@MarMi wiki: podmieniłem botem na archiwa. Peter Bowman (dyskusja) 00:41, 24 sty 2023 (CET)

Dziękuję. MarMi wiki (dyskusja) 00:54, 24 sty 2023 (CET)

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)

• Dziwna sprawa. Zacząłem wycinać px z szablonów orderów ([14], [15], [16]). Jednak to px było tam od dawna. A główny {{order}} też nie był ostatnio zmieniany. Paweł Ziemian (dyskusja) 23:26, 15 sty 2023 (CET)

  Nie szybciej/prościej/łatwiej było by wyciąć px z order (o ile we wszystkich pod-orderach jest px)? Albo replacem usuwać w nim nadmiarowe px.
  Edycja: Niestety nie da się wyszukać px w podszablonach (przynajmniej przez wyszukiwarkę na wiki - albo nie wiem jak), więc ciężko stwierdzić jaka jest skala zjawiska. Da się, tylko insource musi być z regexem - ok. 23. MarMi wiki (dyskusja) 23:43, 15 sty 2023 (CET)

  Poczyściłem te ordery. Liczba problemów spadła. Ale teraz bardziej ujawniły się sytuacje że "w haśle było 12px, a powinno być 12". Czy jakiś właściciel bota mógłby zerknąć na te rzeczy i je poczyścić? Bo ręcznie to jednak troche schodzi. PMG (dyskusja) 12:55, 16 sty 2023 (CET)

  Podobnie było z {{trofeum}} i trochę tego bot posprzątał (i ciągle pracuje). ~malarz pl ^PISZ 13:14, 16 sty 2023 (CET)

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)

To chyba [[Plik:przykład.jpg|thumb||Opis zdjęcia]] i podobne. [17], [18], [19] ~malarz pl ^PISZ 17:23, 16 sty 2023 (CET)

Hmm... nawet nie pomyślałem, że to może być przez to :-). XaxeLoled ⸤ AmA ⸣ 18:40, 16 sty 2023 (CET)

Załatwione ~malarz pl ^PISZ 09:22, 19 sty 2023 (CET)

Szablon:Infobox

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

• Nie ma go, bo nasze infoboksy mają inną implementację, więc taki szablon nie jest potrzebny. Paweł Ziemian (dyskusja) 20:58, 16 sty 2023 (CET)
  • @Paweł Ziemian Co to znaczy? Eurohunter (dyskusja) 18:28, 24 sty 2023 (CET)
    • Nikt z osób, które partycypują w tworzeniu kodu infoboksów nie widział potrzeby jego wdrażania. Paweł Ziemian (dyskusja) 21:52, 24 sty 2023 (CET)

Załatwione ~malarz pl ^PISZ 09:22, 19 sty 2023 (CET)

Wiadomości techniczne: 2023-03

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

Problemy

• Adresy URL w linkach „poprz.” w historii strony będą teraz zawierać diff=prev&oldid=[revision ID] zamiast diff=[revision ID]&oldid=[revision ID]. Rozwiąże to problem, gdy filtrowanie historii za pomocą znaczników zmian prowadziło do niepoprawnych diffów. Zmiana ta może negatywnie wpłynąć na działanie niektórych skrytpów użytkowników. [20]

Zmiany w tym tygodniu

• Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 17 stycznia, na stronach innych niż Wikipedia i niektórych Wikipediach od 18 stycznia, a następnie na wszystkich wiki od 19 stycznia (harmonogram).
• Pewne zmiany w wyglądzie stron dyskusji były dostępne wyłącznie w przestrzeniach Dyskusja: i Dyskusja wikipedysty:. Zostaną one wdrożone również do pozostałych przestrzeni dyskusji, np. Dyskusja Wikipedii:. Nadal nie będą jednak dostępne w „zwykłych” przestrzeniach, takich jak Wikipedia: (np. w kawiarence). Narzędzia dyskusji można włączyć w preferencjach (funkcja eksperymentalna). [21]
• Na Wikiźródłach, kiedy grafika jest powiększana lub przesuwana w przestrzeni Strona:, te same ustawienia powiększenia i przesunięcia zostaną zapamiętane dla wszystkich stron w przestrzeni nazw Strona:, połączonych z danym indeksem (z przestrzeni Indeks:). [22]
• Skórka Wektor 2022 stanie się domyślną na anglojęzycznej Wikipedii (dla użytkowników komputerów). Zmiana odbędzie się 18 stycznia o 15:00 UTC. Dowiedz się więcej.

Przyszłe zmiany

• Tegoroczna edycja Badania Życzeń Społeczności, które zachęca wikimedian do składania życzeń natury technicznej i głosowania nad narzędziami i ulepszeniami, rozpocznie się w przyszłym tygodniu, 23 stycznia 2023 o 18:00 UTC. Można rozpocząć pisanie na brudno zgłoszeń w brudnopisie Badania.

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

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

Załatwione ~Cybularny^{Napisz coś ✉} 08:09, 17 sty 2023 (CET)

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)

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)

Wszystkie (albo większość) wiki padło. Patrz T327196. AramilFeraxa (Napisz do mnie!) 19:47, 17 sty 2023 (CET)

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)

Załatwione ~malarz pl ^PISZ 09:22, 19 sty 2023 (CET)

Język ubyski

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)

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)

• Naniosłem zmiany. Zobaczymy czy problem zniknie za kilkanaście minut. Paweł Ziemian (dyskusja) 22:53, 18 sty 2023 (CET)

Załatwione ~malarz pl ^PISZ 09:21, 19 sty 2023 (CET)

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)

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

  szablony pionowe powinny zniknąć. Być moze spełniały kiedyś swoje funkcje - teraz już nie.--Kerim44 (dyskusja) 19:09, 18 sty 2023 (CET)

• Zgadzam się z „powinny zniknąć”. Tylko nie można tego zrobić hurtowo. Trzeba każdy szablon (lub ich tematyczną grupę) oddzielnie zgłosić i przedyskutować. Natomiast obecna implementacja powinna pozostać. Obawiam się, że szablony pionowe nie znikną. A gdyby nawet zniknęły, to by kiedyś chciały wrócić. Tym bardziej, że sporadycznie wciąż powstają nowe. Gdyby nie było dla nich wsparcia to powstawałyby w postaci pseudotabelek symulujących szablony nawigacyjne ([23], [24]). A takich łamigłówek nie chcemy ([25], [26]). Paweł Ziemian (dyskusja) 22:39, 19 sty 2023 (CET)
• Jak zatem to przeprowadzić? Owszem mogę w każdej chwili przerobić lub zgłosić dowolny szablon, ale jeśli go zedytuję to nie zdążę wprowadzić poprawek w masie artykułów które go wykorzystują (nie obsługuję botów). Zgłaszać poszczególne (lub grupy) szablonów tutaj a przy ewentualnej akceptacji, ktoś chętny zedytowałby i naniósł poprawki w art. botem? Sumek101 (✉) 09:05, 20 sty 2023 (CET)
  • Sprawdź czy nie mają odpowiedników poziomych (mogą być w różnych kategoriach - najlepiej sprawdzić w głównych artykułach) , popraw szablony i daj znać np. u mnie w dyskusji. ~malarz pl ^PISZ 09:24, 20 sty 2023 (CET)

    Ok, tak też zrobię przy czym całą operację trzeba będzie przeprowadzać dosyć sprawnie, bo zedytowane szablony zanim zostaną przeniesione na spód będę rozbijać formatowanie dziesiątek artykułów. Jeżeli będę miał jakieś wątpliwości co do zasadności zmiany szablonu z pionowego na poziomy, będę zakładał dla niego osobny temat żeby sprawę przedyskutować. Sumek101 (✉) 23:20, 20 sty 2023 (CET)

• Jest możliwe, ze powstają nowe nie dlatego, ze ktoś bardzo się przy nich upiera, a z czystej niewiedzy. Po prostu wikipedysta bierze za wzór "stary" pionowy i ...leci nowe teksty...(też tak robię z poziomymi;)--Kerim44 (dyskusja) 22:24, 20 sty 2023 (CET)

  Wg mnie to nawet bardzo prawdopodobne... i też robię tak samo :) Sumek101 (✉) 23:22, 20 sty 2023 (CET)

Gadżet poczekalniowy

Czołem! Zauważyłem, że praktycznie za każdym razem przy użyciu któregokolwiek guzika z gadżetu DelReqHandler pokazuje się błąd, że nie odnaleziono tytułu i trzeba odświeżyć stronę aby zadziałało (czasami kilka razy). Anomalia występuje zarówno na stronach zbiorczych, jak i na podstronach. Ktoś miałby pomysł jak to naprawić? AramilFeraxa (Napisz do mnie!) 13:19, 20 sty 2023 (CET)

Archiwizacja strony dyskusji

Coś wyszło nie tak podczas archiwizowania strony dyskusji, ale nie wiem co. Postępowałam wg opisu. Nie wiem co teraz zrobić. Pomponick (dyskusja) 20:27, 20 sty 2023 (CET)

Załatwione Nie było potrzeby wpisywania "Dyskusja:" w polu z nazwą strony (tj. po prawej od listy przestrzeni nazw). Polecam też automatyczną metodę archiwizacji dyskusji za pośrednictwem MalarzBOTa. Msz2001 (dyskusja) 20:59, 20 sty 2023 (CET)

Bardzo serdecznie dziękuję! Pomponick (dyskusja) 21:02, 20 sty 2023 (CET)

Tabele biathlonistów

W artykułach o biathlonistach w tabelach np. dotyczących mistrzostw świata została dodana kolumna "SR" czyli pojedyncza sztafeta mieszana i bardzo dobrze tyle, że po wpisaniu lokaty ona (ta lokata) nie wyświetla się. Czy ktoś mógłby to sprawdzić? Mechtal (dyskusja) 20:47, 21 sty 2023 (CET)

Nie wiem czemu (nie znam się na biathlonie), ale w {{biathlon/wyniki wiersz}} (np. Darja Domraczewa) 10 kolumna zależy od wypełnienia parametru nazwanego sr - generowany jest wtedy link postaci [[zawartość sr|zawartość 10 parametru]].
@Badibiathlon - zrobiłeś zmiany w maju 2022 ale nie dodałeś do dokumentacji jak tego używać.
Edycja: Chyba nie usunąłeś z if fragmentu z |nd., przez co po wypełnieniu 10 parametru (przy pustym sr) właśnie to się wstawiało. Poprawiłem. MarMi wiki (dyskusja) 22:36, 21 sty 2023 (CET)

Powinno już działać. Swoją drogą to musi być rzadki przypadek, skoro nikt tego nie zauważył od maja 2022. MarMi wiki (dyskusja) 22:59, 21 sty 2023 (CET)

Dzięki. Teraz jest w porządku tylko u każdego biathlonisty trzeba powpisywać dane bo obecnie wyświetla się w tej kolumnie - {{{10}}}. Mechtal (dyskusja) 11:04, 22 sty 2023 (CET)

U których? Być może występuje tam jakaś rzadka kombinacja parametrów (albo chodzi o inny szablon).
Na Darja_Domraczewa jest ok - zarówno z podaną wartością, z n (nd.), jak i przy pustym polu (-).
Przykład w dokumentacji szablonu {{Biathlon}} może zresztą sugerować, że nie powinno się wstawiać niewypełnionych pól MR i SR. MarMi wiki (dyskusja) 14:46, 22 sty 2023 (CET)

Jednak chodzi o ten sam szablon, w przypadku gdy jest podanych tylko 9 parametrów (np. w Magdalena_Forsberg).
Czy jest tego dużo?
Edycja: Zapewne tak - poprawiłem. MarMi wiki (dyskusja) 15:01, 22 sty 2023 (CET)

Teraz jest dobrze, pojawiły się myślniki. Pozostaje dodać lokatę lub oznaczyć "nie dotyczy" co zresztą już u szeregu zawodników zrobiłem. Mechtal (dyskusja) 21:53, 22 sty 2023 (CET)

Migracja z vector.css i vector.js

Cześć, od jakiegoś czasu toczy się dyskusja nad tym jak zmigrować skrypty do nowego V'22 (Wektor 2022). Na ten moment nowy i stary Wektor ładują pliki vector.css oraz vector.js. Planowane jest jednak wyłączenie tego, bo nowy Wektor ładuje jednocześnie vector-2022.css oraz vector-2022.js. Zaproponowałem zrobienie okresu przejściowego, ale sprawa ciągnie się już tak długo, że możliwe, że będą to chcieli uciąć w końcu. I możliwe, że szybko.

Proponuję zrobić tak:

1. Przejrzyj i wyrzuć stare rzeczy ze swojego vector.css oraz swojego vector.js (te linki przekierowują konkretnie do Twoich skryptów). Jeśli masz podobnie jak ja, to pewne sporo z tych rzeczy już nie używasz, więc szkoda zawracać sobie nimi głowę ;).
2. (opcjonalnie) Utwórz osobne moduły z fragmentów css i js. Czyli przenieś je do osobnych podstron i ładuj je za pomocą metod opisanych w Pomoc:Personalizacja - porady dla zaawansowanych.
3. Przerzucić uniwersalne rzeczy do common.css oraz common.js. Dzięki temu mniej rzeczy będziesz tracić przełączając się między skórkami. Większość skryptów powinna być i tak uniwersalna.
4. Część rzeczy jak np. tryb ciemny itp zrobione pod specyficzną skórkę przerzuć do swojego vector-2022.css oraz swojego vector-2022.js

Uwaga! Pamiętajcie, że póki co V'22 ładuje jeszcze oba skrypty (vector.js oraz vector-2022.js). Tak że uważajcie, żeby nie ładować sobie skryptów podwójnie ♊︎.

PS: Na koniec mam prośbę. Nie chcę tutaj toczyć dyskusji, czy V'22 będzie domyślną skórką, czy jest brzydki, czy jest piękny itp ;). Chciałbym się tu skupić nad praktycznymi aspektami migracji. Wybór domyślnej skórki jest niezależny od tego. Nux (dyskusja) 00:51, 22 sty 2023 (CET)

Czy wiadomo ile osób ma ten problem? Można zrobić ich listę? Sidevar (dyskusja) 02:28, 22 sty 2023 (CET)

Raczej niedużo. Pewnie ok. 60 aktywnych osób. Z tego też trudno powiedzieć ilu osób będzie to dotyczyć, bo nie wszyscy zmienią skórkę. Tak jak i sporo osób nadal używa Monobooka z różnych względów. Nux (dyskusja) 13:30, 22 sty 2023 (CET)

Może być więcej, bo to wyszukuje tylko skrypty ze słowem loader (z jakiegoś powodu słowo loader nie pokazuje się w polu wyszukiwania).
Przykład - brak np. mojego Wikipedysta:MarMi_wiki/vector.js, zawierającego tylko //window.removeTitles=false;. MarMi wiki (dyskusja) 14:26, 22 sty 2023 (CET)

@MarMi wiki Tak, to celowe. Zakładam, że jak ktoś nie ma mw.loader, to jest nieaktywny, albo ma pusty vector.js (tak jak ten twój). Ten loader jest w instrukcjach do nowych skryptów zazwyczaj. Nux (dyskusja) 15:00, 22 sty 2023 (CET)

I nie zapomnijcie sprawdzić też globalnie (na meta).
Informacyjnie: Nie tak dawno (kilka dni temu) enwiki zmieniło domyślną skórkę ze starego wektora na nowy.
I tak, V'22 jest brzydki i nieporęczny :) MarMi wiki (dyskusja) 02:38, 22 sty 2023 (CET)

@MarMi wiki o ile wiem z meta ładuje się tylko global.js chyba? Czy mi się źle wydaje? :) Nux (dyskusja) 13:32, 22 sty 2023 (CET)

A, pomieszałem global.js z commons.js, z czego wyszło przypuszczenie, że vector.js też może być globalny. MarMi wiki (dyskusja) 14:20, 22 sty 2023 (CET)

Nie, nie jest tak źle. W praktyce myślę, że dla większości osób to będzie mało roboty. Ja mam tam dużo, ale i tak muszę to uporządkować w końcu. Nawiasem mówiąc może część warto przenieść do tego globalnego jeśli skrypt jest w pełni uniwersalny. Nux (dyskusja) 15:02, 22 sty 2023 (CET)

• Średnio zrozumiałem problem, więc zapytam wprost: jeśli nie zamierzam używać V'22, to muszę coś robić? IOIOI₂ 20:57, 22 sty 2023 (CET)

  @IOIOI Nie. Przynajmniej na razie nie. Można się rozejść ;) Nux (dyskusja) 21:00, 22 sty 2023 (CET)

Abonament rtv

Status:	błędne

Bląd Wikipedii polega na złej informacji dot. abonamentu RTV, jego opłata jest obowiązkowa nie od 2005r, jak.podajecie, a od czasów glębokiej komuny , czyli przynajmniej od 1960 r., a nawet wcześniej.

W związku z tym proszę o sprostowanie Waszego wpisu, ponkeważ jest nieprawdziwy 5.173.4.5 (dyskusja) 19:08, 22 sty 2023 (CET)

przepraszam.za błąd w "ponieważ" 5.173.4.5 (dyskusja) 19:10, 22 sty 2023 (CET)

To jest stolik do zgłaszania problemów technicznych związanych z działaniem Wikipedii, a nie błędów merytorycznych w artykułach. Hasło Abonament radiowo-telewizyjny może edytować każdy, zapraszam do edytowania – w Wikipedii może robić to każdy! Jednak informacja o 2005 r. mówiła jedynie o dacie uchwalenia aktualnie obowiązującej ustawy, a nie o roku wprowadzenia abonamentu w Polsce. Były tam natomiast inne błędy, poprawiając które, doprecyzowałem informację o ustawie. Michał Sobkowski _dyskusja 11:03, 23 sty 2023 (CET)

Jeszcze o datach - tym razem w treści

Przepraszam jeśli pytam o rzecz oczywistą, ale ostatnio zostałem ochrzaniony za coś, co lata temu polecono mi stosować jako przyjęty zapis i trochę zgłupiałem, bo nie znalazłem jakoś tego w wytycznych do pisania artykułów. Chodzi o zapis daty w treści hasła - czy pisze się "r." po dacie rocznej, czy nie? Jak nadmieniłem, kiedyś wskazano mi, że w wiki "literackie" pisanie "r." po dacie nie jest przyjęte (nie pamiętam jak tłumaczono, zdaje się oszczędnością kodu? zbędnością, bo i tak wiadomo o co chodzi?). Ale ostatnio kolega wikipedysta zarzucił mi anglicyzm i cofnął edycję. Jak więc to jest, i czy gdzieś to jest zapisane? Zorro2212 (dyskusja) 22:15, 22 sty 2023 (CET)

• Zob. Wikipedia:Przedyskutowane#Pisownia roku – data bez r. Ważne aby w treści danego hasła było jednolicie. Zob. też podlinkowaną dyskusję z marca 2022 roku. Ented (dyskusja) 22:19, 22 sty 2023 (CET)
• ja bym nie dawal (niezaleznie od standardow) bowiem w szablonie {{cytuj}} jest zaszyty algorytm ktory formatuje date (i nie tylko) a ten (wiem z doswiadczeniea lepiej dziala bez r)--Ignasiak (dyskusja) 22:25, 22 sty 2023 (CET)

  Do szablonów lata wpisuje się oczywiście bez żadnych dodatków (chyba że są jakieś wyjątki). MarMi wiki (dyskusja) 22:32, 22 sty 2023 (CET)

• Zorro2212, anglicyzm to to nie jest, raczej „papieryzm” – forma stosowana w encyklopediach i słownikach papierowych dla zaoszczędzenia miejsca. Nie znam przekonywającego uzasadnienia, aby pomijać „r.” w encyklopedii internetowej. Michał Sobkowski _dyskusja 12:51, 24 sty 2023 (CET)

Wiadomości techniczne: 2023-04

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

Problemy

• W zeszłym tygodniu, przez około 15 minut, wszystkie wiki były niedostępne dla użytkowników zalogowanych (nieosiągalne były również strony nieobecne w pamięci cache). Było to spowodowane problemem z synchronizacją przy wdrażaniu aktualizacji oprogramowania. [27]

Zmiany w tym tygodniu

• Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 24 stycznia, na stronach innych niż Wikipedia i niektórych Wikipediach od 25 stycznia, a następnie na wszystkich wiki od 26 stycznia (harmonogram).
• U osób, które mają włączoną funkcję eksperymentalną Narzędzia dyskusji, strony dyskusji będą zawierały więcej informacji o aktywności dyskusji. [28][29]
• Tegoroczna edycja Badania Życzeń Społeczności, które zachęca wikimedian do składania życzeń natury technicznej i głosowania nad narzędziami i ulepszeniami, rozpocznie się w poniedziałek, 23 stycznia 2023 o 18:00 UTC.

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

MediaWiki message delivery 00:45, 24 sty 2023 (CET)

Załatwione ~Cybularny^{Napisz coś ✉} 00:45, 24 sty 2023 (CET)

wikisource: = en.wikisource

wikisource: linkuje do en.wikisource, tak ma być?
wikisource:M. Arcta Słowniczek wyrazów obcych/Ex officio
s:M. Arcta Słowniczek wyrazów obcych/Ex officio MarMi wiki (dyskusja) 01:44, 24 sty 2023 (CET)

Tak samo wiktionary:test linkuje do en.wiktionary. Jeżeli użyjesz prefiksów skrótówych, to linkuje do polskojęzycznych: wikt:test, s:M. Arcta Słowniczek wyrazów obcych/Ex officio. Peter Bowman (dyskusja) 15:18, 24 sty 2023 (CET)

Msz2k1 jest w tym bardziej obcykany, ale o ile pamiętam to co mówił, to dodanie języka Wikisource:pl: ma tą zaletę, że taki link działa zawsze. Niezależnie od tego w jakim serwisie się jest. Np. w tych uniwersalnych jak WikiDane, czy Meta tylko linki z językiem będą działać. Nux (dyskusja) 21:42, 24 sty 2023 (CET)

Projekty wielojęzyczne na potrzeby interwików są traktowane jak enwiki. To znaczy, jeśli napiszesz link postaci [[:pl:]], to wylądujesz na Wikipedii w danym języku, a jak [[s:]], to na anglojęzycznym siostrzanym. (Możliwe że na mul.wikisource działa to inaczej). Wszystkie prefiksy interwiki są tu: Specjalna:Interwiki. Msz2001 (dyskusja) 22:35, 24 sty 2023 (CET)

Jakby ktoś szukał odpowiednika tabelki z prefiksami z en:Help:Interwiki_linking#Prefix_codes_for_linking_to_Wikimedia_sister_projects,
to jest tutaj: Pomoc:Jak_wstawić_link#Linki_do_projektów_siostrzanych_2.
Dla utrwalenia: Pomoc:Interwiki, Jak wstawić link (w Informacje ogólne). MarMi wiki (dyskusja) 21:43, 24 sty 2023 (CET)

Nowy gadżet

Czy da się z tego zrobić gadżet? m:User:Jon Harald Søby/diffedit. Świetne narzędzie, bardzo ułatwia przeglądanie zmian. Więc czemu by nie wprowadzić tego jako opcje w preferencjach? SkrzydlatyMuflon Pisz tutaj 01:52, 24 sty 2023 (CET)

Wygląda bardzo ciekawie. Na początek przetłumaczyłem ten skrypt i dałem znać autorowi, żeby zintegrował zmiany do oryginału (o tu). Potem można to wrzucić do gadżetów. Msz2001 (dyskusja) 15:47, 24 sty 2023 (CET)

@SkrzydlatyMuflon, Załatwione Wrzuciłem do gadżetów (sekcja „Patrolowanie zmian”). Przetłumaczę opis na meta i wrzucę info na TO. Msz2001 (dyskusja) 18:11, 24 sty 2023 (CET)

City population - c.d.

[30] - takie przypadki nadają się do ponownego przebotowania. 2A00:F41:3821:1337:14A4:6A07:285:15CD (dyskusja) 08:43, 24 sty 2023 (CET)

• 29 trafień. Raczej do poprawy ręcznej, np. @PMG. ~malarz pl ^PISZ 09:05, 24 sty 2023 (CET)
• Jest tego więcej (choć w trochę innej formie zdania). Bot uruchomiony. Być może coś zostanie jeszcze do ręcznych poprawek. "City Population" nie jest nieużywanym zwrotem. ~malarz pl ^PISZ 09:16, 24 sty 2023 (CET)
• Do przejrzenia zostało 215 artykułów, ale wydaje mi się, że tam już nie ma takich przykładów, ani ukrytych linków do tej strony, typu: [31]. [32]. ~malarz pl ^PISZ 09:24, 24 sty 2023 (CET)