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

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)

Może ktoś przygotuje dobry nowy szablon (projekt szablonu)? ~malarz pl ^PISZ 20:35, 9 lut 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 [1] 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 [2], 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 ([3]), 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: [4]. 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 [5]. 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) [6]. 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)

• Powiązane(?): dodano obsługę CSS Container Queries do FF. MarMi wiki (dyskusja) 13:58, 17 lut 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 [7]. 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: [8]. 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)
  

• Moim zdaniem główny problem mojego botowania dla Was jest taki, że ja mam inny gust. W zapisie wielokolumnowym są bardzo krótkie teksty. Dla mnie one lepiej wyglądają gdy żaden z nich się nie zawija. Dopuszczam zawijanie tylko gdy są wyświetlane 2 szerokie kolumny. Oczywiście wszystko z rozsądkiem. Jeśli lista ma same krótkie teksty, a tylko jeden lub nieliczne odstają to wtedy bym je zawinął do kolejnej linii zwężając kolumnę. Paweł Ziemian (dyskusja) 21:53, 25 sty 2023 (CET)

  Główny problem jest dla mnie taki, że chcesz przebotować kilka tysięcy artykułów. Co w pierwszej chwili wzbudziło moje wręcz przerażenie, bo podchodziłeś do tego ze strony niezgodnej ze sztuką. W dodatku nawet teraz chcesz wątpliwości rozstrzygać przez jakieś domyślne wartości. Gdy w rzeczywistości moim zdaniem jak nie ma się 100% pewności, to nie powinno się ruszać artykułu botem. Ogólnie, a nie tylko w przypadku tego szablonu.

  Wiesz jak dla mnie również dobrze mógłbyś chcieć redagować artykuły o fizyce kwantowej botem. Tak samo tutaj nie chcesz przyjąć do wiadomości, że po prostu nie jest realne zrobienie tutaj sensownych reguł. Nawet jakbyś oparł bota na GPT-4, to będziesz miał takie przypadki gdzie AI nie ma 100% pewności co "czyta".

  A w dodatku zamiast na treści chcesz opierać wnioskowanie na liczbie kolumn. Co już jest w ogóle bez sensu i niezgodne ze sztuką. To jest liczba mniej lub bardziej przypadkowo wpisana przez kogoś, czyli już samo to powoduje, że wnioskowanie ma podstawowe błędy założeń (jak już pisałem: 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). Pozdrawiam i liczę na to, że zatrudnisz bota do czegoś bardziej realnego i produktywnego, Nux (dyskusja) 22:14, 25 sty 2023 (CET)

  • Ja nic teraz nie wnioskuję z liczby kolumn. Ostatnia wersja bota miała tylko ograniczenie 28em. Jednak zrobiłem ostatnio skan 4k szablonów i policzyłem średnią szerokość maksymalną treści w zależności od kolumn. Wyniki są następujące: 2 kolumny to 19,1em; 3 kolumny to 13,5em; 4 kolumny to 10,8em; 5 kolumn to 8,7em; 6 kolumn to 5,9em. Szablony bez zadeklarowanej liczby kolumn to 18em. Skoro nie mają ograniczenia kolumn, to pewnie mają podaną szerokość. Nie sprawdzałem. Średnia ze wszystkich wywołań to 17,1em. Z tego wyraźnie widać, że osoby sugerowały się szerokością treści dobierając liczbę kolumn zamiast wstawiać szerokość minimalną. Najszersza treść ma 229em. Też tego nie sprawdzałem ale przypuszczam, że to szerokość mojej przeglądarki. Paweł Ziemian (dyskusja) 22:34, 25 sty 2023 (CET)
    • Uruchomiłem rano bota do ściągnięcia całej statystyki. Wyniki w postaci wykresu dodałem do brudnopisu. Bot pominął około 3k szablonów, bo nie były to proste listy lub miał jakieś problemy z odczytem strony. Paweł Ziemian (dyskusja) 20:46, 26 sty 2023 (CET)

      correlation is not causation ;-) Nux (dyskusja) 21:09, 26 sty 2023 (CET)

      Ale wykres ładny Nux (dyskusja) 21:10, 26 sty 2023 (CET)

      @Paweł Ziemian dzięki za zajęcie się sprawą. Jeśli postanowisz ostatecznie botować to nie będę oponował ani doszukiwał się na siłę przypadków gdzie powinno być em mniej czy więcej. Trzeba liczyć się z tym że bot gdzieniegdzie się pomyli - trudno, gdyby człowiek to poprawiał to pewnie też by się gdzieniegdzie pomylił. Poprawi się ręcznie albo cofnie batch jeśli skala będzie duża. BTW Niezależnie od tego jaki tryb postępowania ostatecznie przyjmiecie to prosiłbym abyście uwzględnili w nim grupę układów wywołanych divem (column-count) o której piszę niżej w osobnej podsekcji - jeśli odpalicie sobie przykłady które podałem w trybie responsywnym to zauważycie że to one w tej chwili wyświetlają się najgorzej (brak minimalnej szerokości) więc fajnie byłoby je ogarnąć w pierwszej kolejności Archiwald (dyskusja) 23:11, 26 sty 2023 (CET)

• Planuję pierwsze botowanie w poniedziałek rano. Będzie to czas, w którym nie używam mojego komputera bo jestem w pracy. Generalnie to botowanie świeci mi na pełnym ekranie przeglądarką, w której robiony jest podgląd i pomiary. To działanie utrudnia mi normalne korzystanie z komputera, więc wolę je wykonać bez swojej obecności. Uważam, że wstawienie dedykowanej szerokości z podpowiedzą w komentarzu o poprawnym zakresie polepszy ich prezentację i ułatwi ewentualne dalsze ręczne poprawki. Botowanie divów nie będzie w zakresie tego zadania. Ono działa inaczej i mam na to oddzielny kod, który jednak korzysta z obecnego w zakresie wykonywania pomiarów. Paweł Ziemian (dyskusja) 21:15, 29 sty 2023 (CET)

  OK, zapewne prędzej czy później wyklaruje się jakaś lista przypadków, które z różnych powodów trzeba przejrzeć ręcznie; w razie czego informuj, to chętnie pomogę. Przypomniała mi się jeszcze jedna sprawa odnośnie tych układów, mianowicie jakieś pół roku temu Malarz poprawiał szablony kolumna-podział na układy wielokolumnowe (więcej:ten temat) i z tego co pamiętam stanęło wtedy na wyznaczaniu odgórnego 300px na kolumnę; niewykluczone że Twoja obecna metoda wyznaczyłaby te szerokości nieco bardziej intuicyjnie; rzecz dotyczy kilku tys. artykułów, ale niestety nie wiem, czy jest jakaś ich lista, bo wtedy tylko zasygnalizowałem problem i zostawiłem temat. Pzdr Archiwald (dyskusja) 21:47, 29 sty 2023 (CET)

  • Bot wstawił szerokość do 6k szablonów w 6k artykułach, w których był tylko jeden szablon {{układ wielokolumnowy}}. Przypadki, gdy w artykule jest więcej niż jeden szablon zrobię w późniejszym terminie. Zastanawiam się nad sprawdzeniem, czy inne szablony mają już podaną szerokość i liczbę kolumn. Jeśli byłyby one stałe w obrębie artykułu, to dla równego stylu braki można spróbować uzupełnić zgodnie ze znalezionym wzorem. Ale może to jest zupełnie zbędne i błędne założenie. Paweł Ziemian (dyskusja) 22:22, 31 sty 2023 (CET)

• Rodzi mi się koncepcja drugiego botowania. Chodzi o przypadki, w których do uzupełnienia jest więcej niż jeden szablon. Pomysł jest taki, żeby we wszystkich szablonach o takiej samej liczbie kolumn ustawić taką samą szerokość. Z oczywistych względów użyta będzie największa znaleziona szerokość. Jednak pominąłbym artykuły, w których najmniejsza znaleziona szerokość będzie za bardzo odstawała od wyznaczonej wspólnej. Jako próg proponuję 80%. Z drugiej strony patrząc nie wiem czy ma to jakiś sens, jeśli kolumn jest mało. Na wersji telefonicznej i tak pewnie widać maksymalnie dwie kolumny. Natomiast na wersji desktopowej mała szerokość nie ma znaczenia bo kolumny i tak są rozciągnięte na wielkim ekranie. Dlatego przypadek dwukolumnowy najchętniej botowałbym bez algorytmu uwspólniającego szerokości kolumn między szablonami. To znaczy mogę go wziąć pod uwagę jeśli progi zadziałają, jednak wartości spoza widełek też bym zastosował. Paweł Ziemian (dyskusja) 21:23, 3 lut 2023 (CET)

  a podałbyś które szablony teraz masz na myśli? Archiwald (dyskusja) 05:49, 4 lut 2023 (CET)

  • Przygotowałem botem 2 raporty z listą artykułów i szerokościami dla kolejnych szablonów. Jeden zawiera próbę wstawiania po staremu. Drugi z próbą wyrównania szerokości. Ten drugi jest krótszy ponieważ nie zawiera artykułów, w których znajduje się szablon o wyliczonej szerokości mniejszej niż akceptowany próg. Nie mam raportu na okoliczność dopuszczenia niewyrównanych szablonów dwukolumnowych. To na razie tylko taki mój pomysł, który można zaimplementować później. Paweł Ziemian (dyskusja) 20:06, 4 lut 2023 (CET)

    to wyrównanie w przypadku kilku szablonów na 1 stronie to jest niezły pomysł. Na pewno jakaś próba kilkudziesięciu takich wstawień nie zaszkodzi. Archiwald (dyskusja) 05:49, 6 lut 2023 (CET)

    • Wykonałem botowanie na 30 artykułach. Paweł Ziemian (dyskusja) 22:00, 6 lut 2023 (CET)

      no moim zdaniem całkiem ładnie się to składa. nie widzę jakichś przypadków żeby bot coś rażąco źle zrobił. Zastanawiam się tylko czy ten komentarz który wstawia bot do kodu będzie zrozumiały poza tymi kilkoma osobami które przeczytają tą dyskusję? Archiwald (dyskusja) 11:49, 7 lut 2023 (CET)

      • Jeśli kiedyś ktoś o komentarze zapyta, a my jeszcze będziemy o tym pamiętać, to odpowiemy. Moim zdaniem nic to nie przeszkadza. Może nam teraz czasami coś pomóc lub wyjaśnić. No i zawsze można to usunąć w kolejnych edycjach. Paweł Ziemian (dyskusja) 20:51, 7 lut 2023 (CET)
        • Bot przerobił wczoraj dodatkowe 676 artykułów. Paweł Ziemian (dyskusja) 22:48, 8 lut 2023 (CET)

• Opracowałem obliczanie szerokości w szablonach, które nie są zwykłą listą. W kolejnym etapie botowania mogę więc uwzględnić takie przypadki jak w artykule „4 Pułk Czołgów Ciężkich”. Paweł Ziemian (dyskusja) 21:56, 9 lut 2023 (CET)

  mówimy teraz o artykułach zgrupowanych w Kategoria:Układ wielokolumnowy z wielopoziomową listą? Archiwald (dyskusja) 10:09, 10 lut 2023 (CET)

  Można tak przyjąć w uproszczeniu. Bot nie zagląda do tej kategorii, tylko przypadkiem artykuły z takimi szablonami są w dwóch kategoriach. Po botowaniu ta kategoria nie zniknie. Paweł Ziemian (dyskusja) 20:06, 10 lut 2023 (CET)

• Bot wczoraj około południa przerobił kolejną porcję artykułów. Lista powodów ominięcia pozostałych to:

1. istnieją inne szablony z szerokością i liczbą
2. szerokości kolumn w układach wielokolumnowych mają za duży rozrzut i nie można ich wyrównać
3. artykuł czeka na przejrzenie
4. Lopadotemachoselachogaleokranioleipsanodri... ma za długą nazwę, aby go zapisać na dysku :)
5. nieoczekiwanie mała lista elementów

Zwłaszcza ten ostatni może wymagać oddzielnej kategorii technicznej, którą zacząłem implementować w brudnopisie ale nie przeniosłem jeszcze do szablonu głównego. Paweł Ziemian (dyskusja) 08:55, 12 lut 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)

• Odpalam bota. Monitorujcie sytuację. Bot ma tylko zamieniać divy na szablon z wyliczoną przez siebie szerokością. Paweł Ziemian (dyskusja) 18:34, 27 sty 2023 (CET)
• Bot skończył. Raport z listą przerobionych artykułów jest tutaj. Paweł Ziemian (dyskusja) 21:16, 27 sty 2023 (CET)

  o wiele lepiej to wygląda, zwłaszcza w podanych wyżej przykładach.gdzie wcześniej wyświetlały się po 3-4 kolumny na telefonach. Archiwald (dyskusja) 02:05, 28 sty 2023 (CET)

• Dociągnąłem kolejną porcję (raporcik). Jeszcze trochę zostało. Głównie są to artykuły czekające na przejrzenie. W kilku przypadkach są do wyprostowania błędy składni XML, więc trzeba je zrobić ręcznie. Paweł Ziemian (dyskusja) 14:39, 28 sty 2023 (CET)
  • Poprawiłem jeszcze bo bocie kilka przypadków. Były tam wikitabelki lub znak = w treści. Paweł Ziemian (dyskusja) 20:45, 29 sty 2023 (CET)

Automatyczne blokowanie

Mamy jakieś mechanizmy automatyczne, które wykrywają wandalizmy i blokują. Tymczasem dzisiaj jeden nowy user przez 20 minut wykonał ponad 100 edycji, każda była kasowaniem sporej ilości tekstu. Coś chyba nie zadziałało, albo trzeba taki filtr zrobić. Choćby w formie, że nowo zarejestrowany może zapisywać 1 edycję na minutę, 3-5 kolejnych (wzrastająco, po jednej edycji za każdy dzień, ewentualnie)(z wyłączeniem brudnopisu) czy coś takiego. Ciacho5 (dyskusja) 23:03, 4 lut 2023 (CET)

• Właśnie nie kasował sporej ilości tekstu. To doświadczony user był, kasował max. 900 bajtów w jednej edycji - wiedział, co robi. IOIOI₂ 23:07, 4 lut 2023 (CET)
• No to trzeba coś zrobić. Ilość tekstu na kilka minut, liczba edycji... Zawiodła czujność adminów (nikt nie jest zobowiązany śledzić OZ non-stop), powinny jakieś mechanizmy zadziałać. Mając dobry komp, można uszkodzić połowę artykułów. Pomyślcie, fachowcy od filtrów, proszę, nad tym. Osobiście uważam linit dwóch edycji na minutę za rozsądny. Ciacho5 (dyskusja) 21:02, 5 lut 2023 (CET)

  A czy zabezpieczanie się w tak intruzywny sposób przeciwko nadużyciu, które zderza się raz na bardzo wiele lat, ma sens? Czy koszt tego działania nie przewyższy zysku? Gżdacz (dyskusja) 21:46, 5 lut 2023 (CET)

  Raczej czy koszt odwracania skutków jest mniejszy/większy niż zrobienie zabezpieczenia. MarMi wiki (dyskusja) 13:25, 6 lut 2023 (CET)

  Koszty odwracania jest jednorazowy, a wprowadzone automatyczne ograniczenia będą działać i hamować działania, raczej dobre, dowolnie długo. Gżdacz (dyskusja) 21:38, 7 lut 2023 (CET)

  Botom blokującym nie idzie ostatnio najlepiej (patrz wątek Hiperaktywność filtru nadużyć powyżej), aczkolwiek blokada wykonania powyżej x edycji na minutę to niegłupi pomysł. IOIOI₂ 10:45, 6 lut 2023 (CET)

Tu było 14 edycji w 2 minuty z jakiegoś szemranego IP: [9] Mathieu Mars (dyskusja) 15:58, 7 lut 2023 (CET)

• To, co wandal narobi przez 20 minut, zaradny zamiatacz może posprzątać w sekundy. Dla takich okoliczności napisałem sobie skrypt, który za jednym haustem blokuje, usuwa i rewertuje delikwenta (przycisk umieszcza na stronie wkładu). Ten z kolei dodaje przycisk obok [cofnij], który działa tak samo, ale nie wymaga przeładowywania strony (i dodatkowo ukrywa na OZ zarówno edycje wandala, jak i sam rewert). Peter Bowman (dyskusja) 22:16, 7 lut 2023 (CET)

Podgląd po zmianach w wersji mobilnej

Po edycji hasła w wersji mobilnej klikam strzałkę, aby zobaczyć, jak wyglądają wprowadzone zmiany, ale wszystkie sekcje są pozwijane i nijak nie idzie ich rozwinąć. Podejrzeć można tylko lead i infoboks. Zdaje się, że nierozwijalność dotyczy tylko nagłówków sekcji pierwszego stopnia (w wikikodzie podwójne „równasie”) po otworzeniu kodu całej strony (historia zmian → którakolwiek zmiana → przycisk „edytuj” przy nazwie strony). Aby zobaczyć, jak wygląda to, co wprowadzam, muszę zapisać zmiany i ewentualnie edytować hasło ponownie. Ten problem występuje od niedawna.
Ambiroz (dyskusja) 08:55, 6 lut 2023 (CET)

Subskrypcja wątków w dyskusjach wikiprojektu

Z racji iż jest bardzo nie wiele nowych wątków w wikiprojektach, zwykle jeden na miesiąc bez odpowiedzi. Proponuję żeby opcja subskrypcji działa na całą dyskusję wikiprojektu, nie poszczególne wątki, gdyż mija się to z celem. SkrzydlatyMuflon Pisz tutaj 13:09, 9 lut 2023 (CET)

• Wtedy nazywa się to "dodaniem do strony obserwowanych". IOIOI₂ 13:19, 9 lut 2023 (CET)

  To ja wiem ;). Tylko nie dostaję powiadomienia w formie dzwoneczka. Tak jak było wcześniej w poczekalni, że subskrybowało się całą sekcję (dobrze, że zmieniono). SkrzydlatyMuflon Pisz tutaj 13:22, 9 lut 2023 (CET)

Szablon Tabela odcinków

{{Tabela odcinków}} wymaga uzupełnienia do co najmniej s30 (Fifth Gear, patrz kod), oraz żeby jakoś sygnalizował przekroczenie dostępnych sezonów.
Edycja: Albo wymaga przerobienia, żeby nie trzeba było uzupełniać sezonów. MarMi wiki (dyskusja) 20:19, 9 lut 2023 (CET)

Pierwszą kwestię ogarnąłem, drugą pozostawiaw bardziej obeznanym technicznie userom. XaxeLoled ⸤ AmA ⸣ 21:03, 9 lut 2023 (CET)

• Nie rozumiem w jakim celu do zrobienia regularnej tabeli potrzebny jest szablon. Takie rzeczy robi się jako zwykłe tabelki. W artykułach sportowych widuję tabelki tworzone szablonami, ale są one w zestawach po 3 szablony: nagłówek, wiersz, stopka. Mamy też {{lista utworów2}}, ale tutaj szablon oblicza sumę czasu trwania utworów, więc to ma jakiś sens. Natomiast w tabeli odcinków pojawia się nic nie mówiący, może tylko dekoracyjny, kolor w pierwszej kolumnie. Paweł Ziemian (dyskusja) 21:11, 9 lut 2023 (CET)

Adres parafii

Tak w związku z wypowiedzią @Jacek555 (nie bardzo wiem skąd bierzesz wiedzę jakoby adresem parafii miałby być adres kancelarii parafialnej? Jak wskazałem wyżej, ośrodkiem parafii jest kościół parafialny.) w Wikipedia:Kawiarenka/Wikipedyści#Kościół Zesłania Ducha Świętego w Krakowie i sądząc, że takie błędne rozumienie wypisywanego w infoboksie {{Parafia infobox}} adresu może być powszechne, zastanawiam się co dodać do tekstu wypisywanego w infoboksie adres, by zminimalizować tego rodzaju nieporozumienia. Stok (dyskusja) 17:44, 10 lut 2023 (CET)

Automatyczne przeglądanie wycofanych zmian

Zauważyłem kiedyś, że gdy zmiana wprowadzona przez nieredaktora jest później przez niego wycofana i przywracana do poprzedniej wersji to jest automatycznie oznaczana: diff Internet Przypuszczam, że dzieje się tak, gdyż bieżąca wersja jest identyczna z wersją wcześniej przejrzaną i nie ma sensu jej ponownie przeglądać.

Z drugiej strony mamy sytuację, gdy jeden nieredaktor wprawadza daną zmianę a drugi nieredaktor ją wycofuje - tutaj nie ma już automatycznego przeglądania, choć moim zdaniem spokojnie taka zmiana mogłaby być automatycznie oznaczona, np: diff Celebrity Splash diff Macaulay Culkin.

Argumentem przeciw automatycznemu oznaczaniu mogłoby być to, że pośrednia wersja może być wulgarna lub naruszać prawo autorskie i chcielibyśmy, by ktoś to zauważył i zgłosił do ukrycia. Choć ten argument wydaje się słaby biorąc pod uwagę to, że zwykle przegląda się zmiany "ostatnia przejrzana" vs "ostatnia nieprzejrzana" bez sprawdzania wersji pośrednich. Ololuki (dyskusja) 14:17, 12 lut 2023 (CET)

Rewert nieredaktora może być niezasadny, system działa tak jak powinien moim zdaniem. -- niepodpisany komentarz użytkownika 89.66.42.56 (dyskusja) 14:22, 12 lut 2023

Argument brzmi sensownie, tylko czy wszyscy redaktorzy przeglądają wszystkie wersje pośrednie, żeby potwierdzić słuszność rewertu? Poza tym jednego IP może używać kilka osób - jedna osoba wprowadzi zmiany, inna spod tego samego IP wycofa i zostaną automatycznie oznaczone. Ololuki (dyskusja) 15:06, 12 lut 2023 (CET)

Też się zgadzam, że obecne zachowanie jest OK. Czasami sprawdzam co zostało wycofane. O ile ktoś nie wycofał sam-siebie (też się zdarza). Ew. właśnie takie wycofanie samego siebie mogłoby być oznaczone jako przejrzane automatycznie. Nux (dyskusja) 22:07, 15 lut 2023 (CET)

Szablon APR (Archiwum Polskiego Rocka) - zmiana adresu i schematu

{{APR}} - serwis przeniósł się na https://polskirock.eu/, zmienił się także schemat linków.

Stare linki (*.art.pl) prowadzą na stronę 404. MarMi wiki (dyskusja) 23:42, 12 lut 2023 (CET)

Ok, okazało się że częściowo działa po aktualizacji adresu.
Działają (linki z opisu szablonu): wytwórnia/muzyk/wykonawca
Nie działają: utwór/album
Utwór nieużywany, pozostaje tylko album (890 przypadków). MarMi wiki (dyskusja) 21:08, 14 lut 2023 (CET)

Szablon TV.com - martwa strona

{{TV.com}} - strona padła w 2021 (wg enwiki i web.archive). MarMi wiki (dyskusja) 19:42, 14 lut 2023 (CET)

Nadchodzące zmiany struktury grafik i być może szablonów

Cześć. Nadchodzi zmiana struktury grafik, ze względu na... W sumie to z paru względów chyba (wcag, ujednolicenie, pielęgnacja), ale będzie zmieniona struktura grafik. Co do idei i wykonania mam parę wątpliwości, ale ja nie o tym... Zmiana jest już powoli wdrażana (poprosiłem o wstrzymanie się, ale nie znalazłem grafiku i nie wiem jaki jest plan). Można to sobie już podejrzeć w praktyce na Wikiźródłach, gdzie zmiana została już wdrożona.

Na ten moment zmiany nie powinny być duże. Na WŹ musiałem poprawić parę starych szablonów i stary CSS. Jeśli robiliście jakiś skrypt, moduł itp który polega na konkretnej strukturze grafiki, to może on wymagać poprawy od razu. Dobrze jest otoczyć grafikę innym tagiem, może z jakąś klasą. Tak, żeby uniezależnić się od tego czy grafika (po renderowaniu wikikodu do HTML) jest otoczona przez div, czy przez figure, czy przez span.

Jak już linkowałem, więcej o zmianach struktury grafik na MW: mw:Parsoid/Parser Unification/Media structure/FAQ.

Będą też szersze zmiany, które będą wymagały zmiany w naszych modułach. Jeśli chcecie wyrazić swoje zdanie, to najlepiej tutaj: T318433 Templates (and extensions) that mimic parser media output need migration to new structure, Phabricator, wrzesień 2022. Po tych zmianach za pewne trzeba będzie zmodyfikować Moduł:Kalendarium czy Moduł:Mapa, które używają klasy thumbinner. To jeszcze nie teraz, ale osobiście spodziewam się, że niedługawo. Kierunek zmian jest już ustalany we wspominanym phab:T318433. Nux (dyskusja) 22:05, 15 lut 2023 (CET)

Załatwione, ~malarz pl ^PISZ 22:43, 17 mar 2023 (CET)

Grupowanie przypisów

Czy ktoś mógłby mnie pouczyć jak grupować przypisy harwardzkie? Chodzi o to, że niekiedy w hasłach kończę zdanie kilkoma takimi przypisami (wraz z podanymi stronami) i tworzy to większą grupę odwołań obok siebei, więc pożądane byłoby ich scalenie w jednym przypisie w celu zaoszczędzenia miejsca w treści. A poza tym czy analogiczne możliwe jest też grupowanie przypisów harwardzkich razem z odwołaniami <ref name=""><ref name=""/> ? Lowdown (dyskusja) 08:00, 19 lut 2023 (CET)

• Jeżeli dobrze zrozumiałem problem to: jak masz dwa identyczne przypisy utworzone za pomocą szablonu {{odn}} to one automatycznie staną się jednym odwołaniem. Jeżeli natomiast chcesz w jednym miejscu zamienić kilka odwołań będące przypisami harwardzkimi na jeden to – nie wnikając w sens takiego działania – można w każdym z szablonów {{odn}} dać parametr ref=nie i wszystkie te szablony {{odn}} wstawić w jeden znacznik <ref>...</ref>. Więc – jeżeli dobrze zrozumiałem Twój problem – zobacz w kodzie, jak wyglądją te przypisy w moim komentarzu.
  Ogólnie raczej odradzałbym takie działanie, a przynajmniej robienie tego z głową. Dwa czy trzy odwołania obok siebie ^[1][2][3] to nic strasznego, a jeżeli jest ich bardzo dużo, to raczej problemem jest nadmiar źródeł w danym miejscu.

Aaa 2010 ↓, s. 10.

Bbb 2010 ↓, s. 12.

Ccc 2010 ↓, s. 13.

Ddd 2010 ↓, s. 15.

Eee 2010 ↓, s. 18.

Aaa 2010 ↓, s. 10, Bbb 2010 ↓, s. 12, Ccc 2010 ↓, s. 13, Ddd 2010 ↓, s. 15, Eee 2010 ↓, s. 18

Wostr (dyskusja) 12:14, 19 lut 2023 (CET)

Jeśli obejmuje je ten sam standard co dla refów, to też nie powinno się ich grupować. MarMi wiki (dyskusja) 12:36, 19 lut 2023 (CET)

@Lowdown Mamy konsensus, żeby nie grupować źródeł. Jeden ref - jedno źródło, patrz: Wikipedia:Kawiarenka/Artykuły dyskusja/Archiwum/2022-listopad#Kilka źródeł w jednym przypisie. Jest nawet odpowiednia uwaga na stronie: Pomoc:Przypisy#Sposób nr 1: wplatanie w treść. Ololuki (dyskusja) 22:26, 21 lut 2023 (CET)

Załatwione, ~malarz pl ^PISZ 22:43, 17 mar 2023 (CET)

Wieści od zespołu Editing 1/2023

Przeczytaj w innym języku • Subskrybuj

W tym wydaniu newslettera podajemy dwie informacje o pracy zespołu Editing:

1. zakończą się prace nad nowymi funkcjami wchodzącymi w skład Ulepszenia stron dyskusji i funkcje te zostaną włączone,
2. rozpoczną się prace nad kolejnym projektem, Edit check.

Ulepszenia stron dyskusji

Niektóre z nadchodzących zmian

Zespół Editing prawie ukończył pierwszą fazę projektu Ulepszeń stron dyskusji. Niemal wszystkie nowe narzędzia są już dostępne jako funkcja eksperymentalna „Narzędzia dyskusji”.

Nowy wygląd zawiera informację o aktywności dyskusji, w tym o czasie dodania ostatniego komentarza. Pojawi się także przycisk „Dodaj temat”. To wszystko będzie można wyłączyć na stronie Special:Preferences#mw-prefsection-editing-discussion. Zapraszamy do dzielenia się opiniami.

Odsetek zapisanych edycji w poszczególnych dniach według grup: z nowymi narzędziami (grupa testowa) i bez nich, interfejs przeglądarki na urządzenia mobilne (grupa kontrolna)

Zakończyliśmy test A/B dotyczący narzędzi dyskusji w wersji mobilnej. Wyniki dowiodły, że uczestnictwo w dyskusjach było łatwiejsze z włączonymi narzędziami niż bez nich. Editing włączy te narzędzia dla wszystkich użytkowników urządzeń mobilnych.

Nowy projekt: Edit check

Zespół Editing rozpoczyna projekt przeznaczony dla nowych użytkowników. Zespół chce pomóc nowicjuszom sprawdzić, czy edycja nie jest problematyczna, przed kliknięciem „Zapisz”. Pierwszym narzędziem będzie funkcja zachęcająca do dodawania przypisów do nowych treści. Obserwuj tę stronę, jeśli chcesz śledzić ten projekt. Dołącz do spotkania 3 marca, żeby poznać więcej szczegółów.

–Whatamidoing (WMF) (dyskusja) 00:24, 23 lut 2023 (CET)

Załatwione, ~malarz pl ^PISZ 22:43, 17 mar 2023 (CET)

Przycięty tekst w popupie podglądu artykułu

Czasami się zdarza, że w popupie podglądu artykułu ostatnia linijka tekstu jest przycięta. To kwestia ustawień po mojej stronie? Velta (dyskusja) 14:16, 25 lut 2023 (CET)

• Problem dotyczy oprogramowania. Zgłosiłem na Phabricatorze. Msz2001 (dyskusja) 14:59, 25 lut 2023 (CET)

Załatwione, ~malarz pl ^PISZ 22:43, 17 mar 2023 (CET)

Szablon Cytuj linkuje to pisma zamiast artykułu/rozdziału

Czy jest jakiś sposób, aby {{Cytuj}} aplikował podany URL do rozdziału/artykułu podanego w przypisie zamiast do pełnej publikacji? Obecnie wypełnienie pola URL powoduje objęcie linkiem tytułu dzieła zamiast rozdziału/artykułu. — smyru 14:19, 25 lut 2023 (CET)

dopuszczone jest zwykłe linkowanie w parametrze "rozdział".

Kod taki:

• {{Cytuj|autor r= Jan Kowalski| rozdział = [https://onlinelibrary.wiley.com/doi/10.1002/9781444338386.wbeah09156 przyszłość Wikipedii w kontekście braku prądu]|tytuł = Studia z dziejów Wikipedii i prądu|redaktor = Jan Nowak| url=https://onlinelibrary.wiley.com/doi/full/10.1002/9781444338386.wbeah04060}}

da wynik taki:

• JanJ. Kowalski JanJ., przyszłość Wikipedii w kontekście braku prądu, [w:] JanJ. Nowak (red.), Studia z dziejów Wikipedii i prądu .brak strony (książka)

Archiwald (dyskusja) 14:42, 25 lut 2023 (CET)

Albo zmienić na {{Cytuj książkę}}, tam jest do tego parametr. MarMi wiki (dyskusja) 18:15, 25 lut 2023 (CET)

A może podałbyś jaki kod próbujesz wstawić do artykułu, bo może coś jest niepoprawnie wypełnione po prostu? Wostr (dyskusja) 17:01, 25 lut 2023 (CET)

Próbowałem następującego:

<ref name="Skóra2011">{{Cytuj |autor r = Wojciech Skóra |rozdział = Polskie placówki konsularne w Niemczech we wrześniu 1939 roku |tytuł = Z morza i Pomorza. Spojrzenie na wrzesień 1939. Polityka i wojna |inni = Andrzej Drzewiecki (red.), Bartłomiej Siek |url = https://www.academia.edu/4194451/Polskie_plac%C3%B3wki_konsularne_w_Niemczech_we_wrze%C5%9Bniu_1939_roku_Polnischen_Konsulaten_in_Deutschland_im_September_1939_w_Z_morza_i_Pomorza_Spojrzenie_na_wrzesie%C5%84_1939_Polityka_i_wojna_red_Andrzej_Drzewiecki_Bart%C5%82omiej_Siek_Toru%C5%84_2011_s_432_457}}</ref> — smyru 21:18, 25 lut 2023 (CET)

• Historycznie w pierwszej wersji szablonu nie było pola url. Nowy szablon miał mieć mniej parametrów aby był prostszy w obsłudze. Linkowanie z dowolnego pola miało się realizować standardowymi mechanizmami wiki [link opis]. Jednak pojawiły się głosy aby ten url dodać. Powodem był VE notabene też w początkowym stadium. Jednak ten url potrafi się podpiąć „wyżej” pod czasopismo jeśli nie ma tytułu. Paweł Ziemian (dyskusja) 22:26, 25 lut 2023 (CET)

VE ikona komunikatu - brak treści

Dobrze by było, żeby po kliknięciu w ikonę komunikatu w VE (trójkąt z wykrzyknikiem w środku) pokazywał się jakiś treściwy komunikat.

Przykłady:

- Dodaj temat (np. tutaj) - treść „1 komunikat”.

- Po wykonaniu ve.ui.toolFactory.register( ve.ui.BoldAnnotationTool ); w konsoli (przy edycji pod VE) - nie wiadomo co poszło nie tak, po kliknięciu w ikonę nic się nie pokazuje. MarMi wiki (dyskusja) 18:13, 26 lut 2023 (CET)

Nieco dziwne, ale nie dziwne. Wyświetla się komunikat MediaWiki:Visualeditor-editnotices-tool. Komunikat ten pokazuje liczbę możliwych komunikatów (editnotices, oznaczeń zabezpieczenia, możliwe że coś jeszcze). I właśnie tutaj niby wyświetla editnotice, ale editnotice jest pusty ;) Ciąg zassań: MediaWiki:Editnotice-4 > Szablon:Dołącz editnotice > Szablon:Dołącz editnotice/content > Szablon:Editnotice/Przestrzeń nazw/Wikipedia. Ten ostatni szablon wyświetla editnotice, gdy jesteśmy na podstronach WikiLubiZabytki, Poczekalni lub Biblioteki, dla całej reszty nic nie wyświetlając. Jednak jako że strona Szablon:Editnotice/Przestrzeń nazw/Wikipedia istnieje to Szablon:Dołącz editnotice/content tworzy diva (pustego). Czyli komunikat jest, ale jest to ten pusty div. Dlatego treść „1 komunikat” jest technicznie rzecz biorąc poprawny. Należałoby przysiąść i pomyśleć nad jakimś lepszym rozwiązaniem kwestii zasysania tych editnotice, typu wywalenie obecnego zasysania i zamiast tego utworzenie stron typu MediaWiki:Editnotice-4-Poczekalnia-artykuły i innych, których potrzebujemy; tak jak już istnieje MediaWiki:Editnotice-4-Propozycje tematów), ale nie mam czasu ni uprawnień i się za to nie biorę ;PP Kłaniam się, tufor (dyskusja) 19:32, 26 lut 2023 (CET)

Czyli to nie ma nic wspólnego z ewentualnym wyświetlaniem jakiegoś błędu z VE, tylko służy do wyświetlania predefiniowanych uwag (en:Wikipedia:Editnotice na to by wskazywało), a błędy(?) w VE tylko to z jakiegoś powodu uaktywniają. MarMi wiki (dyskusja) 00:53, 27 lut 2023 (CET)

Nie tylko editnotice. Spróbuj edytować Wikipedia:Strona główna/Jutro - jest jeszcze komunikat o zabezpieczeniu. Jak na przykład będziesz chciał utworzyć stronę Wikipedia:Comperia.pl_(spółka (wcześniej usunięta) to zobaczysz komunikaty MediaWiki:Newarticletext i jeszcze jeden ostrzegający o utworzeniu usuniętej wcześniej strony (MediaWiki:Recreate-moveddeleted-warn). Nie powiedziałbym, że są to błędy w VE; raczej my wrzucamy pustego diva jako editnotice. Nie wiem w ogóle po co jest jest tekst o liczbie komunikatów; IMO można byłoby wywalić. Więcej w tej kwestii będzie Ci zapewne w stanie powiedzieć Matma Rex. Kłaniam się, tufor (dyskusja) 10:39, 27 lut 2023 (CET)

Samo usunięcie tekstu o liczbie komunikatów nie rozwiąże problemu, bo wciąż będzie wyświetlał się przycisk z ikonką ⚠, tylko że kliknięcie go otworzy zupełnie puste okienko. Problem trzeba rozwiązać poprzed pozbycię się tego pustego <div>-a. Wydawało mi się, że kiedyś to już było naprawione (zobaczcie zresztą historię Szablon:Dołącz editnotice/content i link do phab:T95822 tamże); ciekawe, czemu problem powrócił… Matma Rex dyskusja 18:28, 27 lut 2023 (CET)

Powinno być naprawione tą edycją: [10] (teoretycznie uprawnienia do edycji tej strony mam tylko jako globalny edytor interfejsu, i nie jestem pewien, czy powinienem to robić ;), ale skoro zostałem poproszony o pomoc, to mam nadzieję, że nikt mi nie będzie miał tego za złe). Matma Rex dyskusja 18:39, 27 lut 2023 (CET)

Uwaga w VE

Uwaga (przypis w grupie uwaga) wyświetla się jako sama litera [a], ale obramowane pod VE ma nadal jak dla uwaga a. Utrudnia to edycję przypisów znajdujących się za taką uwagą (np. Nowa_Gwinea#cite_ref-73, do przypisów da się przejść kursorami). MarMi wiki (dyskusja) 18:00, 1 mar 2023 (CET)

Zgłosiłem T330957. Matma Rex dyskusja 01:16, 2 mar 2023 (CET)

Nie mamy wpływu na czas rozwiązania, więc oznaczam jako Zrobione. ~malarz pl ^PISZ 22:42, 17 mar 2023 (CET)

Informacje o dodaniu strony do danej kategorii

Czy istnieje możliwość otrzymywanie powiadomień, komunikatów lub podobnych na temat nowych artykułów dodanych do wybranej kategorii? Dodanie kategorii do obserwowanych nie daje tego typu powiadomień. Rpoleski (dyskusja) 17:36, 3 mar 2023 (CET)

New mechanism for the Moscow Metro stations number graph

Hi,
Please take a look at Dyskusja szablonu:Wykres:Rozbudowa metra w Moskwie. I tried to port the new mechanism from mediawiki but the template won't display. Michgrig (dyskusja) 17:54, 4 mar 2023 (CET)

Edit: Actually, the mechanism is the same, on plwiki it's just tailored version of the Graph template output (add |debug=on as a parameter to Graph:Stacked and you see similar output). Do you want just to update the data? Or add the legend? (Or both?).

Before edit: You need to input the colors array manually (ex. copy values from the code of {{Wykres:Rozbudowa_metra_w_Moskwie}} template) - or port the "MoscowMetro" module.
With manual colors (copied from execution on ru:Special:ExpandTemplates)

W tym miejscu powinien znaleźć się wykres. Z przyczyn technicznych nie może zostać wyświetlony. Więcej informacji

Zobacz lub edytuj surowe dane wykresu.

MarMi wiki (dyskusja) 20:45, 4 mar 2023 (CET)

No i ktoś musiałby dodać polskie tłumaczenie do danych na Commons.
Edycja: Nie wiem też czemu See or edit source data jest po angielsku (ani gdzie to zmienić).
Już wiem - {{Graph:Stacked}} wywołuje {{#invoke:TNT}} z Original/Template:Graphs.tab, gdzie to nie jest było przetłumaczone. MarMi wiki (dyskusja) 21:11, 4 mar 2023 (CET)

Hi @MarMi wiki,
Thank you!
The main idea is to have source data in one place and to have the template updated automatically. The Russian and English templates have already been updated, while only your version remained old, with the data valid as of several years ago.
In ruwiki, we additionally use colors from a module, so that they are centralized and unified. But specifying them as hash codes, as in enwiki, is also OK.
The only thing that is left is translating line names to Polish. I suppose it should be done on the source data page. Michgrig (dyskusja) 07:47, 6 mar 2023 (CET)

Dodałem polskie wersje nazw - linie podane do wykresu różnią się od tego co podaje Metro_w_Moskwie#Czynne w dwóch punktach: 8 i 11A. MarMi wiki (dyskusja) 12:54, 6 mar 2023 (CET)

@MarMi wiki, well, lines 8 and 8A are planned to be linked with a central stretch, but that's for somewhere in the far future.
Line 11A was once Kakhovskaya line (that is reflected in the template data). In 2019, this line was closed, its stations were reconsturcted and are now part of Line 11. Now, Line 11A is an appendix of Line 11, that will be closed later this year. That's all very complicated :) Michgrig (dyskusja) 14:09, 6 mar 2023 (CET)

Mobilne navboksy – prototyp

Cześć! Około 63% wyświetleń Wikipedii to wyświetlenia na komórkach. Te osoby nie widzą szablonów nawigacyjnych pod artykułami (i nie mają żadnej opcji, by je zobaczyć – poza przełączeniem na wersję komputerową). Oznacza to, że mają dużo bardziej ograniczone możliwości nawigowania po tematach pokrewnych, a praca wikipedystów, którzy te szablony przygotowali i utrzymują nie jest na tyle wykorzystana, na ile mogłaby być.

Aktualna – tabelkowa – implementacja daje małe możliwości dostosowania struktury navboksa w zależności od wymiarów urządzenia. Z tego powodu przygotowałem prototyp oparty na CSS grid, który może się poprawnie skalować również na mniejszych wyświetlaczach: Wikipedysta:Msz2001/Navbox. Ten projekt obsługuje wszystkie trzy główne warianty navboksa: „zwykły”, kolumnowy i ze zwijanymi grupami, a ich wybór jest niezależny od struktury HTML (kontrolowany klasą CSS w jednym miejscu). Testować można zmieniając szerokość okna przeglądarki lub otwierając tę stronę na telefonie.

Według CanIUse.com, grid jest wspierany przez 97,3% przeglądarek wykorzystywanych w Polsce. Głównym wyjątkiem jest Opera Mini z wykorzystaniem 2,4%, choć dla niej wynik jest niemiarodajny, bo do tej wartości zalicza się zarówno przeglądarka na smartfony (wsparcie dla grida na Androidzie potwierdzone doświadczalnie) i przeglądarka na tzw. „stare nokie”, gdzie brak wsparcia dla grida nie dziwi i raczej nie jest przeszkodą.

Na ten moment nie jest obsługiwane zwijanie tego navboksa w wersji mobilnej (tj. pl.m.wikipedia.org), ale to wynika z niedostępnego tam mechanizmu mw-collapsible, co docelowo można obejść.

Zapraszam do komentowania prototypu. Wszystko jeszcze można zmienić :). Msz2001 (dyskusja) 13:53, 5 mar 2023 (CET)

Uwaga do statystyki: zakładam że te 63% to ci co się przełączają na wersje desktop (albo w ogóle docierają na koniec artykułu), a nie mobilni użytkownicy ogółem? Bo to, jak podejrzewam, robi dużą różnicę. MarMi wiki (dyskusja) 14:33, 5 mar 2023 (CET)

63% to liczba wyświetleń wersji mobilnej podzielona przez liczbę wyświetleń wszystkich wersji (1,7 mld / 2,7 mld w 2022 roku). Nie są to wyłącznie ci, co docierają na koniec artykułu, nie wiem nawet czy takie dane są zbierane i w ogóle dostępne publicznie. Msz2001 (dyskusja) 14:44, 5 mar 2023 (CET)

Takie dane były zbierane kilka lat temu, chociaż wtedy to dotyczyło wersji na komputery, a nie mobilnej. Wyszło, że bardzo mała część odsłon zawiera przewijanie na sam dół. Może uda mi się to znaleźć. Tar Lócesilion (dyskusja) 18:09, 5 mar 2023 (CET)

Statystyka byłaby ciekawa, ale... To czy przewijają teraz na sam dół niekoniecznie jest aż tak istotne... To znaczy nawet jeśli teraz część nie przewija, to może dlatego, że się nauczyli, że nie ma tam nic ciekawego (bo też nie ma domyślnie kategorii póki co). Jak dorzucimy tam szablony, to te statystyki mogą się zmienić mocno... Inna sprawa, że jestem ciekaw jak był mierzony fakt przewinięcia. Może być sporo technicznych problemów z takim pomiarem. Np. jak ktoś dojdzie do końca, to zamyka stronę i fakt przewinięcia się nie zarejestruje; albo nie dochodzi do końca, ale miałby ostatnią sekcję w widoku itp... Nux (dyskusja) 19:59, 5 mar 2023 (CET)

• Nie używam wersji mobilnej. Na desktopie wygląda bardzo dobrze. Jednak jeden prototyp to za mało. Istnieje kilka typów szablonów nawigacyjnych. Popularne obejmują głównie jedną poziomą listę lub jedną listę z układem wielokolumnowym. Nietypowe są też pionowe. Dlatego warto zrobić listę przypadków do zaimplementowania. Ja się kiedyś interesowałem gridem. Jednak rekurencyjne wywołania tabelek w potencjalnie różnych trybach mnie ostatecznie od tego odwiodły. Ostatecznie skupiłem się na wyeliminowaniu grafik z obszarów opisowych i statystycznej analizie treści szablonu. Może jednak warto to pociągnąć dalej choćby dla samej responsywności. Paweł Ziemian (dyskusja) 22:34, 5 mar 2023 (CET)

  Umieściłem na tej stronie również warianty „kolumnowy” i „ze zwijanymi grupami”. Wariant pionowy byłby, jak mniemam, bardzo podobny do tego z grupami, ale odpowiednio węższy i wyfloatowany do prawej (nie jest aktualnie zaimplementowany). Msz2001 (dyskusja) 17:33, 6 mar 2023 (CET)

  • Jednak szablony nawigacyjne czasami nie są jednolite w sensie grupy, kolumny, pionu. To jest raczej drzewo wywołań szablonów. Najlepiej robić dema na praktycznych przykładach. Zestawiać obok siebie obecny oryginał i nowy gridowy. Oczekuję, że na wersji desktop będą nieodróżnialne. Polecam {{funkcje matematyczne}} i inne pionowe, {{legenda szlaków turystycznych}}, ze stylami jak również coś prostego ostatnio dodanego na przykład {{Alcoià}}. Istnieje też specjalny przypadek class="rok" używany przez katastrofy lotnicze i być może również gdzieś indziej. Albo jeszcze lepiej może od razu zrobić mechanizm do testów, który przełączy „rysowanie” na nowy tryb. Paweł Ziemian (dyskusja) 22:48, 6 mar 2023 (CET)

    Dzięki za podesłanie przykładów. Przygotuję sobie w brudnopisie kopię odpowiednich podmodułów {{#invoke:Navbox}} i będę się bawił. Msz2001 (dyskusja) 15:53, 7 mar 2023 (CET)

• Nie wiem czy się przyda, ale mamy też nieużywany tryb drukowania włączany parametrem | spis = * inny *. To generuje drzewo samych divów. Można dodać do tego do testów jakąś dozwoloną dedykowaną klasę w Moduł:Navbox/res pod validExtraClasses, na przykład class = grid. Ewentualnie zawsze można stworzyć nowy printer jeśli obecny generuje za mało divów aby to poprawnie gridem oCSSować. Paweł Ziemian (dyskusja) 20:49, 7 mar 2023 (CET)

  Na razie stworzyłem swój printer w brudnopisie, żeby generować modułem coś co wygląda tak samo, jak mój html-owy prototyp. To co jest w * inny * na razie nie wystarczy, bo potrzebuję dodatkowych elementów dla mechanizmu mw-collapsible przy każdym nagłówku. (Acz docelowo może za to odpowiadać customowy skrypt, który będzie dostępny też na mobile). Msz2001 (dyskusja) 20:58, 7 mar 2023 (CET)

  • No to polecam skrypty włączane za pomocą class="ll-script ll-script-nazwa-gadzetu". Mamy od tego dedykowaną ładowarkę. Tylko nie wiem czy działa domyślnie w wersji mobilnej. Paweł Ziemian (dyskusja) 21:22, 7 mar 2023 (CET)

    Cześć z tych gadżetów działa na mobilnej, kwestia włączenia w definicji. Msz2001 (dyskusja) 21:44, 7 mar 2023 (CET)

Brak automatycznej aktualizacji linkujących

W szablonie zostały usunięte niezgodności pomiędzy dołączeniami i linkami, tymczasem z linkujących do artykułu wynika, jakby nadal istniało przekierowanie. Kwestia dotyczy konkretnie artykułów: Górka (Sumin), Gromada (Pańków) i Suminek (Niemirówek-Kolonia), które łączy Szablon:Gmina Tarnawatka. Zmiana była dokonywana ponad 2 dni temu. Czyszczenie pamięci podręcznej nie przyniosło efektów. Problem zauważony również przez innych Wikipedystów. Asteq (dyskusja) 00:47, 9 mar 2023 (CET)

@Asteq: zmiany w szablonach nie zawsze są natychmiast propagowane do stron, które je transkludują. Czasami nawet cały proces wygląda, jakby się zawiesił i ten stan może trwać wiele dni (tygodni?). Aby wymusić aktualizację, należy wykonać albo pustą edycję na stronach linkujących, albo purge na szablonie przez API z opcją forcerecursivelinkupdate=true i poczekać. Wykonałem to drugie, już się sprzątnęło. Peter Bowman (dyskusja) 02:38, 9 mar 2023 (CET)

Gdyby znowu się powtórzyło (a na pewno się powtórzy): Specjalna:Środowisko testowe API > "action=purge" > zaznaczyć "forcerecursivelinkupdate" i podać nazwę szablonu (z prefiksem przestrzeni nazw) w polu "titles" > Wykonaj zapytanie. Peter Bowman (dyskusja) 02:42, 9 mar 2023 (CET)

@Peter Bowman: dzięki wielkie za informację i pomoc. Asteq (dyskusja) 10:49, 9 mar 2023 (CET)

Ło matko, purge na API? Może by to dopisać na Pomoc:Czyszczenie_pamięci_podręcznej#Jak_wykonać_funkcję_purge? IOIOI₂ 11:09, 9 mar 2023 (CET)

Załatwione, ~malarz pl ^PISZ 22:40, 17 mar 2023 (CET)

Limit szablonów

Hej!

Jaki jest limit szablonów na artykuł? Zdaję się, że w tym artykule Medaliści igrzysk olimpijskich w lekkoatletyce trochę przesadziłem. O ile jest możliwość pozbycia się 'sortkey', to boję się, że zabraknie limitu dla 'flaga', 'sortname' i przypisów. Czy jest możliwość zwiększenia limitu użytych szablonów? Ewentualnie zamiast 'sortname' dobrym konceptem byłoby zastąpienie poprzez data-sort-value="xyz"? Grisha12 (dyskusja) 12:12, 10 mar 2023 (CET)

• Limit wynosi 2Mb rozwinięć wszystkich szablonów (łącznie z tymi, które są argumentami wywołania innych szablonów) i nie można go zmienić. Warto unikać wywołań szablonów jako argumentów dla innych szablonów. Przy zastępowaniu szablonu kodem pamiętaj, że długość kodu artykułu też może mieć maksymalnie 2Mb.
• Na pewno do usunięcia {{sortkey}}, {{u}}, {{sortname}} (im więcej usuniemy tym lepiej) i ewentualnie {{tooltip}}, {{refn}} (ale można np. zawartość refów z tego szablonu przenieść na koniec artykułu). ~malarz pl ^PISZ 14:09, 10 mar 2023 (CET)
• Wyrzuciłem z artykułu {{sortkey}} i niestety dalej nie wszystko działa tak jak powinno. Albo trzeba podzielić na kilka artykułów albo istotnie ograniczyć flagi (jest och ponad 4000). ~malarz pl ^PISZ 22:55, 17 mar 2023 (CET)

Artykuł warto podzielić na mniejsze według dat. Obecnie ciężko nawigować na dużym ekranie, nie mówiąc już o telefonach. Sidevar (dyskusja) 11:40, 19 mar 2023 (CET)

Nowy prototyp Wektora 2022. Wizualne oddzielenie części interfejsu

Cześć wszystkim. Dziękujemy za zaangażowanie i udział w rozmowach na temat skórki Wektor 2022. W ciągu ostatnich dwóch tygodni skupiliśmy się na dwóch głównych problemach, które pojawiły się w dotychczasowych opiniach na temat skórki – oddzieleniu treści i jasności interfejsu. Pracowaliśmy nad kilkoma prototypami dotyczącymi tej kwestii i w końcu ustaliliśmy ostateczny prototyp. Chcielibyśmy poznać Wasze opinie na jego temat. Chcemy również porozmawiać o tym, jak chcemy zmierzyć skuteczność potencjalnych zmian w porównaniu z obecnym układem. Zamieściliśmy więcej szczegółów i konkretnych pytań na stronie dyskusji projektu - zapraszamy do wyrażania opinii i zadawania pytań (w dowolnym języku, może być po polsku) na MediaWiki.org! SGrabarczuk (WMF) (dyskusja) 00:16, 11 mar 2023 (CET)

Załatwione, ~malarz pl ^PISZ 22:40, 17 mar 2023 (CET)

Poprawianie redirów disFixerem w Kalendarium

Ze stron modułu Kalendarium (np. Moduł:Kalendarium/03-13) zniknął button Popraw linki do przekierowań disFixera, włączenie opcji Używaj starego sposobu rozwiązywania przekierowań. nie pomaga. Celowo czy coś się popsuło? @Nux, coś tam poprawiałeś ostatnio. IOIOI₂ 11:50, 12 mar 2023 (CET)

To jest kwestia tego, że to nie jest wikitekst (dokładnie tam jest model "Scribunto")... Zastanawiam się się jak do tego podejść. Nie chciałbym przede wszystkim, żeby przycisk pojawiał się w skryptach JS i CSS, bo to bez sensu. Kojarzysz inne nietypowe formaty w których mógłbyś chcieć poprawiać linki? Czy tylko kalendarium jest takie nietypowe? Nux (dyskusja) 12:24, 12 mar 2023 (CET)

Mówię tylko za siebie, ale innych nie-wikitekstowych stron nie kojarzę a jeśli nawet byłyby na nich rediry, to na pewno nie w takiej ilość, jak w Kalendarium. Kalendarium jest nietypowe, bo pojawia się na SG, gdzie rediry mnie lekko drażnią a poprawiając je poprawiam też redlinki i okazyjnie treść, dlatego tam akurat disFixer jest bardzo przydatny. IOIOI₂ 12:36, 12 mar 2023 (CET)

• Dobra, dodałem nową opcję, która pomija sprawdzanie rodzaju zawartości (modelu). Właściwie w tym wypadku musiałbyś mieć wszystkie opcje zaznaczone, bo tam nie ma disambów. Może pewnie chwilę potrwać zanim cache się odświeży. W Specjalna:GadgetPrefs będzie opcja [zaawansowane] Wyświetl przycisk także dla Modułów, JS i innych typów zawartości (nie tylko wikitext).
• Dodatkowo poprawiłem problem z przyciskiem zgłaszany przez @Tar Lócesilion oraz @Aramil Feraxa. To był problem właściwie tylko w V'22 i tylko czasami... No, ale teraz domyślnie przycisk będzie w prawym pasku i wstawianie go koło tytułu (w nagłówku) jest dodatkową opcją w Specjalna:GadgetPrefs.
• Przy okazji zachęcam do używania mojego lang on top. To przenosi wybór języków do górnej belki. I wtedy nie ma problemu z przyciskiem do dismabów w V'22 🙂.
• I jeszcze jedna nowość – teraz przycisk nie będzie znikał jeśli API zwróci za mało danych. W razie błędów będzie można po prostu ponownie nacisnąć przycisk.

Jakby co oprócz ew. krytyki można również wyrażać zachwyt i wdzięczność 😉. Nux (dyskusja) 19:59, 12 mar 2023 (CET)

Ciekawe rozwiązanie z przeniesieniem linku do prawego menu w V22. Podoba mi się. Tar Lócesilion (dyskusja) 11:03, 13 mar 2023 (CET)

Dzięki, Nux, działa! Trochę muli, ale poza tym, to chyba najfajniejszy przycisk w całym internecie :) IOIOI₂ 14:38, 13 mar 2023 (CET)

Global RfC filled to enable global abuse filters on large Wikimedia projects by default

Cześć!

Apologies for writing in English. Pomóż przetłumaczyć na Twój język.

On Meta-Wiki, a set of global abuse filters is maintained by Meta-Wiki's administrators and the stewards. Global abuse filters are a powerful tool designed to fight against long-term abusers that operate cross-wiki. It is especially useful (and often irreplaceable by other means) when a cross-wiki LTA starts to rapidly change IP addresses (when that happens, regular blocks are significantly limited due to the IP hopping).

As of today, all small/medium Wikimedia projects (as-determined by number of articles) are automatically subscribed to global abuse filters. They are not, however, enabled on several Wikimedia projects classified as large (except several large Wikimedia projects who opted-in, such as Wikidata). This makes it possible for global long-term abusers to vandalize a project with no global filters enabled, which makes it significantly more difficult for the Stewards to fight against the abuse.

By this message, I'd like to let you know I submitted a global RfC (request for comments), where I propose enabling global abuse filters on large Wikimedia projects as an opt-out feature. This change will make global abuse filters an even more effective tool for combating long-term abuse at the global level. Please feel free to participate in the discussion, which happens at Meta-Wiki.

Thank you for your time.

Sincerely,
--Martin Urbanec (dyskusja) 18:15, 12 mar 2023 (CET)

Załatwione, ~malarz pl ^PISZ 22:40, 17 mar 2023 (CET)

Szablon:dts

W opisie szablonu jest, że "Wywołania szablonu są oznaczane znacznikiem _(dts), który w przestrzeni artykułów (głównej) jest widoczny tylko podczas edycji w edytorze wizualnym (lub na podglądzie strony, jeśli używamy edytora kodu)."

Otóż nie tylko w tych przypadkach. Jest on widoczny też podczas czytania w aplikacji w trybie do czytaniach, nie edycji.

Zwiadowca²¹ 19:40, 14 mar 2023 (CET)

Zgadza się, (dts) widać.
Aplikacja nie ma także przetłumaczonych przycisków przy "Wyślij anonimowo dane" - pokazuje się Reject/Accept. MarMi wiki (dyskusja) 02:09, 16 mar 2023 (CET)

Aplikacje mobilne są przetłumaczone w około 86%. Jeśli ktoś ma czas i ochotę, to tutaj można się przyczynić do powiększenia tego odsetka: [11]. Msz2001 (dyskusja) 19:03, 16 mar 2023 (CET)

<kbd> </kbd> ??

Status:	wykonane

Zobaczyłem dziś tę edycję, a w niej jak w tytule. Co to takiego i do czego tego używać? Przyznam, że w zastosowaniu jakiego go użył Zwierzak2603 (w połączeniu z <nowiki> </nowiki>) to raczej nie widzę sensu... Julo (dyskusja) 19:11, 16 mar 2023 (CET)

Znacznik służy do oznaczania w tekście skrótów klawiaturowych (np. w instrukcjach). Tu było pewnie nieumiejętne wstawienie szablonu i to w edytorze wizualnym. Wargo (dyskusja) 19:49, 16 mar 2023 (CET)

Dzięki.
Widzę, że ta edycja już jest poprawiona. Julo (dyskusja) 15:37, 17 mar 2023 (CET)

Załatwione, ~malarz pl ^PISZ 22:39, 17 mar 2023 (CET)

DisFixer

Kto tutaj ma za dużo wolnego czasu (który mógłby spożytkować na np. przestrzeń główną) i dla zabawy psuje gadżety? Dlaczego disfixer nie działa tak jak powinien i zamiast pokazywać na górze ramkę "popraw link do przekierowań" pokazuje ją teraz małym druczkiem na bocznym pasku narzędzi? ptjackyll (zostaw wiadomość) 22:01, 17 mar 2023 (CET)

• Faktycznie! Czy można prosić o odkręcenie tej, eufemistycznie mówiąc, idiotycznej zmiany? --Felis domestica (dyskusja) 22:34, 17 mar 2023 (CET)

Zajrzyjcie powyżej do #Poprawianie redirów disFixerem w Kalendarium. ~malarz pl ^PISZ 22:39, 17 mar 2023 (CET)

• Widzę, że komuś nudziło się bardziej, niż początkowo zakładałem. Nie tylko zepsuł stary (dobry!) sposób poprawiania przekierowań, ale jeszcze teraz po kliknięciu na starą (dobrą!) ramkę pojawia się wielka czerwona ramka, która aż kłuje w oczy. Nie wiem kto się tym bawi, ale czy naprawdę nie można zablokować tych zabaw, żeby móc wrócić do edytowania? ptjackyll (zostaw wiadomość) 22:49, 17 mar 2023 (CET)

Czcionka o różnej szerokości znaków w widoku diffów

Jeśli ktoś chce mieć w widoku diffów czcionkę, która nie jest o stałej szerokości, niech wklei to do swojego common.css:

.diff-editfont-monospace .diff-addedline, .diff-editfont-monospace .diff-deletedline, .diff-editfont-monospace .diff-context {
	font-family: "Arial";
}

Oczywiście zamiast Ariala można wybrać inną czcionkę - wówczas w cudzysłów należy wpisać nazwę innej czcionki. XaxeLoled ⸤ AmA ⸣ 14:49, 18 mar 2023 (CET)

Filtr antyspamowy

Zatrzymał mnie dzisiaj, gdy do artykułu Lej krasowy chciałem dodać przypis [https*//sjp.pl/werteb] (zamienić gwiazdkę na dwukropek). Słownik na czarnej liście? Można to obejść albo co? Albo ktoś może dać jakieś inne źródło, że piszemy werteb.... To wydaje mi się zbyt szczegółowe, tam się może literówka wkraść. Ciacho5 (dyskusja) 19:48, 19 mar 2023 (CET)

@Ciacho5: w Wikisłowniku doszliśmy do wniosku, że sjp.pl jest skrajnie niewiarygodnym źródłem. Hasło występuje u Doroszewskiego: [12]. Peter Bowman (dyskusja) 20:34, 19 mar 2023 (CET)

w Wikipedii też te same wnioski trochę wcześniej: Wikipedia:Nierzetelne źródła, Wikipedia:Kawiarenka/Artykuły dyskusja/Archiwum/2015-październik. Ololuki (dyskusja) 00:17, 21 mar 2023 (CET)

• Dzięki. Załatwione Ciacho5 (dyskusja) 20:52, 19 mar 2023 (CET)

Wiadomości techniczne: 2023-12

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

• Tydzień temu niektórzy mogli zauważyć problemy z wyświetlaniem miniatur zdjęć. Spowodowane to było nieprawidłowościami w działaniu pamięci podręcznej zdjęć. [13]

Zmiany w tym tygodniu

• Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 21 marca, na stronach innych niż Wikipedia i niektórych Wikipediach od 22 marca, a następnie na wszystkich wiki od 23 marca (harmonogram).
• Na stronie Specjalna:Wkład pojawi się link do Specjalna:Zarządzanie kontem uniwersalnym — niektóre skrypty użytkowników, które dodawały dotychczas taki link mogą powodować konflikty. Ta możliwość była na miejscu #17 w Badaniu Życzeń Społeczności 2023.
• Okno edycji w Specjalna:Filtr nadużyć będzie domyślnie większe i będzie można zmieniać jego wielkość. To prośba, która znalazła się na miejscu #80 w Badaniu Życzeń Społeczności 2023.
• Podczas odblokowywania użytkownika pojawi się opcja obserwowania strony użytkownika. Będzie ona dostępna zarówno na Specjalna:Odblokuj jak i w API. [14]

Spotkania

• Możesz dołączyć na spotkanie z zespołem rozwijającym aplikacje mobilne Wikipedii. Podczas tego spotkania omówimy obecne funkcje oraz plany na przyszłość. Spotkanie odbędzie się 24 marca o 17:00 (UTC). Sprawdź jak dołączyć.

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:25, 21 mar 2023 (CET)

Załatwione, ~Cybularny^{Napisz coś ✉} 03:13, 21 mar 2023 (CET)

Automatyczne commons w infoboksach

Cześć, od kilku dni zajmuję się dodawaniem brakujących parametrów commons do infoboksów i zauważyłem, że dużo jest przypadków, w których kategoria commons jest już podana na WD (P373), a nie jest dodana lokalnie. W wyniku tego link do commons pojawia się tylko w pasku narzędzi w sekcji "W innych projektach", a w wersji mobilnej wcale.

Z tego, co się dowiedziałem, to jest możliwe zaimplementowanie automatycznego zasysania parametru commons na podstawie WD, na zasadzie podobnej jak w przypadku Szablon:Infobox grafika, przynajmniej w przypadku tych infoboksów, które korzystają z Szablon:Infobox projekt.

Mając świadomość generalnej zasady ostrożności przy automatycznym pobieraniu danych między projektami, sądzę jednak, że taka automatyzacja byłaby bezpieczna i mało kontrowersyjna; w każdym razie w ciągu moich ostatnich kilkuset ręcznych edycji sytuacja, w której P373 na WD byłoby błędnie podane, wystąpiła raptem raz lub dwa razy.

Będę wdzięczny, jeśli dacie znać, jak się na to zapatrujecie, oraz jakie ew. przeszkody techniczne taka automatyzacja mogłaby napotkać. Pzdr Archiwald (dyskusja) 05:25, 21 mar 2023 (CET)

Myślę, że tak samo jak domyślna grafika to też powinno być automatyczne. Ew. zagryzienia są nawet mniejsze, a zyski podobne.

W ogóle to fajnie by było jakby przy edycji było widać dane z WD, żeby móc uzupełniać łatwiej boksy... Ale to inna sprawa. Nux (dyskusja) 10:34, 21 mar 2023 (CET)

Zdecydowanie popieram automatyczne pobieranie tej informacji z Wikidanych. Jeśli jest taka możliwość (i jeśli te dwie rzeczy nie są automatycznie synchronizowane w WD), to nie tylko z P373, ale także z linków „Inne projekty”. Myślę, że ryzyko pobrania złej kategorii jest nieistotnie małe, a nawet jeśli tak by się stało to szkodliwość z posiadania złego linku w tym miejscu będzie bardzo niewielka. Pyrlandczyk^(…?) 17:15, 21 mar 2023 (CET)

Kategoria Commons pobierana jest już automatycznie np. w {{Związek chemiczny infobox}}. Przy każdym infoboksie wypadałoby najpierw sprawdzić, na ile wpisy obecne w artykułach pokrywają się z WD. Jest różnie nawet w samej chemii, bo pamiętać trzeba o tym, że WD może mieć trochę inny zakres znaczeniowy elementu, do którego prowadzą interwiki (i zazwyczaj jest to błąd użytkowników danego projektu, a nie WD, że dodają interwiki do elementu znaczeniowo powiązanego, a nie tożsamego). Druga sprawa: istnienie właściwości P373 jest w WD kontrowersyjne, dyskusje nad usunięciem tej właściwości zawsze balansują, choć jak na razie na korzyść jej pozostawienia. Najlepiej korzystać nie z właściwości, a z odnośnika z elementu do Commons (lub pośrednio poprzez właściwość główna kategoria tematu (P910)). Dodatkowo, ja na potrzeby tego stworzyłem automatyczne kategorie typu Kategoria:Odnośnik do Commons w Wikidanych inny niż wpisany lokalnie (Związek chemiczny infobox) → pozwala to zobaczyć, co jest nie tak i w którym projekcie (choć czasami w obu projektach jest okej, tylko wychodzą problemy z tym, że WD są znacznie bardziej szczegółowe niż Wikipedia i nie zawsze da się dopasować artykuł do elementu 1:1). Wostr (dyskusja) 21:42, 21 mar 2023 (CET)

Błąd parsera dla niezalogowanych w Prawo rozpadu naturalnego

W tytułowym haśle niezalogowani widzą czerwony tekst:

Po zalogowaniu (także jako „goła” pacynka) wzór wyświetla się poprawnie. Da się to naprawić? Michał Sobkowski _dyskusja 19:59, 21 mar 2023 (CET)

@Michał Sobkowski: naprawione, wykonałem purge na stronie (dodaj ?action=purge do adresu). Peter Bowman (dyskusja) 21:14, 21 mar 2023 (CET)

@Peter Bowman: To nie jest skuteczny sposób. Też wykonywałem wcześniej purge i później czerwony tekst wrócił. Strona wpada do kategorii Strony z błędami renderowania wyrażeń matematycznych. WTM (dyskusja) 21:54, 21 mar 2023 (CET)

Już nie wpada. MarMi wiki (dyskusja) 12:32, 22 mar 2023 (CET)

Namolny komunikat

Kiedy otwieram stronę pojawia się komunikat Błąd krytyczny - konflikt nazw!, Jeden ze skryptów używa już nazwy wp_sk jako zmienną globalną.

Wcześniej taki komunikat otwierał się, kiedy chciałem edytować jakąś stronę, teraz przy każdym przejściu na nową stronę. W moim .js (Wikipedysta:Ciacho5/monobook.js) jest wp_sk na początku, ale nie chciałbym usuwać tego skryptu. Można coś z tym zrobić? Ciacho5 (dyskusja) 22:02, 21 mar 2023 (CET)

• Tak. Obecnie chcesz korzystać dwukrotnie z wp:sk. Wyrzuć import skryptu od Nuxa z .js i zostaw (bo też masz zaznaczony) skrypt z gadżetów. Ten Nuxowy to brudnopis do testowania poprawek. ~malarz pl ^PISZ 22:15, 21 mar 2023 (CET)
• Dzięki @Malarz pl. Pomogło z namolnym komunikatem, ale zniknęły mi dodatkowe przyciski do opisu zmian. A lubiłem je. Ciacho5 (dyskusja) 13:23, 22 mar 2023 (CET)
• Jakie dodatkowe przyciski? Co i skąd zniknęło. Problem jest gdzie indziej. Skrypty z gadżetu i Nuxa są obecnie identyczne, więc niezależnie od tego który się załadował wcześniej powinno być tak samo. ~malarz pl ^PISZ 13:39, 22 mar 2023 (CET)
• Hm. Przyciski pokazują się, ale nie zawsze. I w ogóle to mam jakiś bałagan. W każdym razie problem, który tu zgłaszałem jest Załatwione. Dzięki. Ciacho5 (dyskusja) 14:23, 22 mar 2023 (CET)

Błędy lintera marzec 2023

(Berni Sanders I Am Once Again Asking For Your Support)

• brak znacznika końca - z tym samolotem to już nawet nie chcę dotykać. Ten zawodnik pewnie ma coś skopane w nagłówkach medali.
• tabela popsuta
• osierocona zawartość

PMG (dyskusja) 09:38, 23 mar 2023 (CET)

• trochę ja, trochę msz i Zrobione. ~malarz pl ^PISZ 10:57, 23 mar 2023 (CET)

Niedziałający Ciemny wektor

Jak się domyślam trwają przygotowania do wdrożenia u nas Wektora2022. Mimo że mam go wyłączonego, polska Wiki przestała mi się wyświetlać w kontrze – nie działa gadget „Ciemny wektor”. W angielskiej także mam wyłączony Wektor2022 i ciemny wektor działa. Czy to znana kwestia? — smyru 10:06, 23 mar 2023 (CET)

@Smyru, w nowym wektorze przełącznik motywów może być ukryty (znajduje się w menu strony, wywoływanym przyciskiem z trzema kreskami). Czy kiedy ręcznie spróbujesz przełączyć motyw klikając „Tryb jasny”/„Tryb ciemny” udaje się włączyć wersję ciemną? Msz2001 (dyskusja) 10:37, 23 mar 2023 (CET)

Sęk w tym, że nowego nie używam. W angielskiej Wiki – gdzie także przywróciłem stary Vector – widzę przełącznik w ramach #p-personal po Preferences. Na polskiej Wiki nie ma go tam ani w markupie ani w DOM-ie. — smyru 10:57, 23 mar 2023 (CET)

W starym Wektorze przełącznik jest dostępny również w lewym menu - tak jak na czwartej ilustracji na stronie Wikipedia:Narzędzia/Ciemny Wektor. Sprawdziłem przed chwilą i u mnie się wyświetla również w starej skórce. Msz2001 (dyskusja) 11:19, 23 mar 2023 (CET)

OK, tę sekcję uznałem za bezużyteczną dla siebie i ukryłem w global.css. Najwyraźniej za szybko poddałem wyszukiwanie w DOM, spodziewając się znaleźć przełącznik w #p-personal. Wychodzi na to, że checkbox w Gadżety jedynie włącza dostępność tej opcji konfiguracyjnej, a zresetowało mi wartość ciasteczka lub zmieniła się jego nazwa. Dziękuję za pomoc, oczy mi odpoczną. Załatwione – smyru 11:35, 23 mar 2023 (CET)