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)

disFixer vs Plik

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

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)

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

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

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

Pionowe szablony nawigacyjne

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

• Dałoby się, ale:
  • przeniosłem chyba już kilkadziesiąt podobnych szablonów, przy niektórych zmiany były cofane (również w wywołaniach), więc lepiej to do końca przedyskutować
  • czasami są dwa szablony (poziomy i pionowy) - wtedy trzeba je scalić, ale bot tego nie wymyśli
  • czasami w szablonie są nietypowe rzeczy (ilustracje, specjalne formatowania) - które trzeba raczej sprawdzić/poprawić ręcznie

  Z dwóch ostatnich powodów lepiej jest przerobić szablon ręcznie (co nie jest kłopotliwe po ujednoliceniu kodu szablonów) i botem przeniesienie ich na koniec artykułu. Tych szablonów nie jest też za wiele: Kategoria:Szablony nawigacyjne – pionowe. Znacznie gorsze są różnego rodzaju szablony pseudonawigacjne (zrobione bez {{szablon nawigacyjny}}). Ale tych tym bardziej botem się nie przerobi. ~malarz pl ^PISZ 12:36, 18 sty 2023 (CET)

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

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

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

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

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

Gadżet poczekalniowy

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

Migracja z vector.css i vector.js

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

Proponuję zrobić tak:

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

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

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

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

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

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

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

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

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

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

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

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

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

Jeszcze o datach - tym razem w treści

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

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

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

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

Hiperaktywność filtru nadużyć

Od kilku dni filtr nadużyć szaleje blokadami typu WANDALIZM STOP 6. Na pewno dobrze działa? IOIOI₂ 15:10, 25 sty 2023 (CET)

W ogóle te opisy reguł są jakieś dziwne. Dlaczego akurat takie? A potem weź się zastanawiaj, co autor miał na myśli... XaxeLoled ⸤ AmA ⸣ 15:15, 25 sty 2023 (CET)

To jest chyba celowe, aby nie ujawniać algorytmu (bo go można wtedy obchodzić). IOIOI₂ 15:17, 25 sty 2023 (CET)

Nawet się dostało pracownikom WMP ;) [13] SkrzydlatyMuflon Pisz tutaj 16:29, 25 sty 2023 (CET)

przed sprzątaniem warto się zabezpieczyć :) Już ogarnięte na przyszłość masti <dyskusja> 18:26, 25 sty 2023 (CET)

generalnie dobrze działa. są pojedyncze false positive ale niewiele. Zresztą obserwuję aktywność tego filtru prawie cały czas. masti <dyskusja> 15:21, 25 sty 2023 (CET)

aktywuje się falami w zależności od aktywności naszego ulubionego Wandala. masti <dyskusja> 15:22, 25 sty 2023 (CET)

Ja widzę trzy false positives raz za razem, przez trzy kolejne dni. Szanowni Operatorzy filtru chyba sobie urządzają kpinki. --WTM (dyskusja) 05:20, 26 sty 2023 (CET)

Taboiaki

Dane nt. populacji są chyba pobierane z Wikidanych, co sprawia, że data (2015) jest umieszczana w innym miejscu (pod liczbą mieszkańców) niż normalnie (kiedy dane są podane w kodzie, to data wyświetla się bezpośrednio przy tekście „populacja”). Potrzeba ujednolicenia. 2A00:F41:383F:FDB4:993D:B47A:602B:155 (dyskusja) 16:14, 25 sty 2023 (CET)

Dodatkowo liczba była tak naprawdę z 1990... (przynajmniej według obecnej postaci fr:Taboiaki_(Nonouti), bo źródeł oczywiście brak). Poprawiłem na WD. MarMi wiki (dyskusja) 17:13, 25 sty 2023 (CET)

Przypisy

Cześć! Czy ktoś umiałby podzielić przypisy w tym artykule na dwie kolumny? Z góry dziękuję za pomoc. Pomponick (dyskusja) 17:14, 26 sty 2023 (CET)

Przypisy dzielą się na kolumny automatycznie, w zależności od ilości wolnego miejsca. Na przykład u mnie w skórce Wektor 2022 jest jedna kolumna przypisów, a w starym Wektorze są dwie (ale to kwestia akurat takiej a nie innej szerokości miejsca na treść, nie stricte skórki). Msz2001 (dyskusja) 17:35, 26 sty 2023 (CET)

Dziękuję za wyjaśnienia, bo nie nadążam za tymi wszystkimi zmianami technicznymi. Pomponick (dyskusja) 20:15, 26 sty 2023 (CET)

Czy jest możliwość zmiany nazwy kategorii lub masowego przeniesienia artykułów z jednej kategorii do drugiej?

Zauważyłem, że mamy kategorie Kategoria:Rosyjskie rody szlacheckie i Kategoria:Rosyjskie rody arystokratyczne, chciałbym je scalić. Wiem, że jest taka możliwość na angielskiej wiki, ale nie wiem jak to zrobić na polskiej. Marcelus (dyskusja) 11:25, 27 sty 2023 (CET)

• Chyba tylko botem lub ręcznie. IOIOI₂ 20:51, 28 sty 2023 (CET)

Kontrola autorytatywna i PAN.pl

Parametr PAN na KA na Wikidata zaciągnął dane członków Akademii w formacji [14] (jak widać linki w KA też trafiają do specjalna:wysz. linków), czyli w formacie https://pan.pl/czlonkowie/BARAN,+Marceli (i są one nieaktywne). Aktualne adresy mają formę https://pan.pl/czlonkowie/baran_marceli . Sprawdziłem na kilku przykładach i dodatkowo 1) należy pominąć polskie bądź obce znaki diaktryczne, 2) można pominąć ze starych adresów drugie imię/inicjał (wtedy działa przekierowanie). Może operatorzy botów, WD i KA będą w stanie poprawić/podrzucić gdzie trzeba. Dzięki, Elfhelm (dyskusja) 19:26, 27 sty 2023 (CET)

• To się będzie chyba wiązało z utworzeniem nowej cechy w WD. Paweł Ziemian (dyskusja) 21:59, 27 sty 2023 (CET)
• Jeszcze w grudniu poinformowałem autora tej właściwości, ale to nie jest taka prosta sprawa, bo format zmienił się w różny sposób, w dodatku czasem z błędami. Mój wpis jest tu: d:User talk:Nomen ad hoc#Property:P8832 - "PAN member". Dość długo pozostał bez odpowiedzi, a potem zapomniałem o śledzeniu tej dyskusji. Jakieś sugestie, co z tym zrobić? Michał Sobkowski _dyskusja 23:24, 27 sty 2023 (CET)

MalarzBOT i Encyklopedia Britannica

diff. Bot nie przeniósł do szablonu parametrów data i zarchiwizowano. Czemu? 2A00:F41:3899:2D50:DC65:32BA:4609:8E2F (dyskusja) 00:22, 30 sty 2023 (CET)

Oraz ustawia swoją datę dostępu, zamiast przepisywać starą (jeśli była podana) - nawet jeśli to kilka dni różnicy, to czasem może mieć znaczenie. MarMi wiki (dyskusja) 13:03, 30 sty 2023 (CET)

Daty dostępu tam nie było. Nie wiem co miała oznaczać "data" w poprzednim szablonie, ale na pewno nie to co oznacza w obecnym. ~malarz pl ^PISZ 13:29, 30 sty 2023 (CET)

Przykłady zachowania daty dostępu: [15], [16] - jak widać potrafi poprawić wartość i pobrać datę dostępu z różnych zapisów, ale to musi być data dostępu. ~malarz pl ^PISZ 13:40, 30 sty 2023 (CET)

Ale w edycjach z 2022 daty dostępu były, np. w drugiej edycji z wkładu z 2022 - Ghi; wkład do 6 paź 2022 - nie wiem jak to działa, ale może bot nie przewiduje braku spacji przed parametrem? Bo dla Żółta łódź podwodna datę dostępu zachował (także Święty poniżej).
Data z diffu oznaczała w tym przypadku datę ostatniej zmiany hasła w encyklopedii (Last Updated: Article History; choć zapewne może też zawierać datę dostępu).
Święty też miał parametr data (wprawdzie podany z błędną datą, bo było 2012-06-02, a powinno być 2012-02-06 - chyba że wystąpiła tu wyjątkowa zbieżność dat). Hasło w encyklopedii zostało od tego czasu kilkukrotnie zaktualizowane (ale nie patrzyłem czy to były jakieś znaczące zmiany). Zakładam że data jest intencjonalnie pomijana, inaczej podejrzenie o spację upada (albo tu z kolei spacji jest za dużo?). MarMi wiki (dyskusja) 15:08, 30 sty 2023 (CET)

Nie wiem dlaczego tak się stało. Spróbuję to zbadać. Generalnie bot starał się zachować archiwum jeżeli był podany link (nawet gdy został wstawiony do url a nie do archiwum). ~malarz pl ^PISZ 13:29, 30 sty 2023 (CET)

Nie mam pojęcia dlaczego wtedy pominął. Wczoraj uruchomiłem go dla brudnopisów i zachował linki do archiwum. Być może w memencie sprawdzania archiwum bot dostał jakąś błędną odpowiedź od archiwum i dlatego je pominął. ~malarz pl ^PISZ 09:11, 31 sty 2023 (CET) Skreśliłem ja: ~malarz pl ^PISZ 09:37, 31 sty 2023 (CET)

• Coś źle odczytałem pierwotne pytanie. | zarchiwizowano = bot pomija (do teraz) bo nikt nie zwrócił mi na niego uwagi. Dla większości linków do archiwów data jest wyciągana przez {{#invoke:Cytuj}} z linku. Muszę nad tym popracować chwilkę i dodać funkcjonalność, która sprawdzi czy moduł to potrafi i w razie potrzeby zachować ten parametr. | data = w szablonach cytuj jest zgodnie z ich instrukcją datą powstania publikacji (nie jest więc datą dostępu, które bot stara się zachować). Jest pomijana z premedytacją i takiego postępowania bota będę bronić. Natomiast datę dostępu bot stara się odczytać (nawet jak jest podana z "palca" w linku bez szablonu cytuj) i w razie potrzeby przeformatować jak podałem w przykładach powyżej. ~malarz pl ^PISZ 09:37, 31 sty 2023 (CET)

  Chyba dobrze by było, gdyby w przypadku braku daty dostępu wstawiać tą z parametru data, o ile byłaby podana. MarMi wiki (dyskusja) 13:03, 31 sty 2023 (CET)

• Zestawienia zmian (i prób zmian) tego bota z 5-6 października jest w (prawie 1400 zmian), z 7 października w (ranne - 191 zmian) i (popołudniowe - 16 zmian). ~malarz pl ^PISZ 09:37, 31 sty 2023 (CET)
• Trudniejsze jest pytanie @MarMi wiki dlaczego bot pominął datę dostępu w Ghi. Spróbuję to jeszcze wyjaśnić. ~malarz pl ^PISZ 09:37, 31 sty 2023 (CET)

  @Malarz pl:
  Pewnie chodzi o występowanie znaku | w tytule (przed konwersją). W rannych właśnie takie mają wstawianą inną datę dostępu (w tym Ghi).
  Fraza do wyszukania: a [dostęp
  Edycja: Nie wiem czy to celowe, ale te pozycje na liście mają prefix >. MarMi wiki (dyskusja) 13:44, 31 sty 2023 (CET)

  • To chyba musiał być ówczesny błąd, który wtedy wyeliminowałem po tym jak go zobaczyłem. Może też to była pochodna innego błędu. Niestety już nie pamiętam jakie zmiany w kodzie wtedy wprowadzałem. Dzisiaj dla takiego samego wywołania u mnie w brudnopisie data dostępu została poprawnie przeniesiona, więc w nowszych edycjach bota błąd już nie występuje. . ~malarz pl ^PISZ 16:18, 31 sty 2023 (CET)
  • Poprawka. Znalazłem błąd. On wynikał z kontekstu, w którym był umieszczony szablon {{cytuj}}. W zależności od niego bot analizował wywołanie szablonu lub tylko link wydobyty z jego wnętrza. Inaczej traktował refy, inaczej listy (np. bibliografia) i inne elementy, w których występował szablon. Wydaje mi się, że już będzie zawsze działał tak samo po dzisiejszych poprawkach (problem dotyczył wszystkich linków przerabianych przez mojego bota na specjalistyczne szablony bazujące na {{#invoke:Cytuj}}). ~malarz pl ^PISZ 10:38, 1 lut 2023 (CET)

Edycja Obserwowanych

Czy ktoś wie, w jaki sposób można edytować listę obserwowanych stron w sytuacji, w której zarówno edycja zwykła, jak i tekstowa zwraca błąd (przekroczenie czasu oczekiwania)? Chodzi mi głównie o możliwość usunięcia części obserwowanych stron, które dostały się tam przypadkowo (zaznaczona opcja dodawania do obserwowanych każdej edytowanej strony). Wostr (dyskusja) 18:56, 28 sty 2023 (CET)

@Wostr, możesz spróbować przez API. Najpierw utwórz podstronę, np. Wikipedysta:Wostr/test, i umieść tam linki do stron, które chcesz usunąć z obserwowanych (obojętnie, w jakiej postaci, byle były podlinkowane). Potem wejdź tutaj i wykonaj zapytanie. Na wypadek gdyby ten link nie prowadził do już wypełnionego formularza: action=watch, zaznaczone "unwatch", titles=Wikipedysta:Wostr/test (bądź inna strona), generator=links, gpllimit=max. Peter Bowman (dyskusja) 19:32, 28 sty 2023 (CET)

mw:API:Watchlist_feed/pl, w Zobacz też jest link do edycji (API:Watch). Po angielsku. MarMi wiki (dyskusja) 19:36, 28 sty 2023 (CET)

Kolejną opcją jest usuwanie obserwowanych na liście. Pokazuj linki ×/+ przy zmienionych obserwowanych stronach (wymagany JavaScript do funkcji przełączania) w Specjalna:Preferencje#mw-prefsection-watchlist. Potem w obserwowanych × będzie usuwał stronę. To tak bardziej stopniowo pozwala oczyścić, ale zawsze coś. Nux (dyskusja) 20:55, 28 sty 2023 (CET)

A propo, to można też użyć skryptu Convenient Discussions, będzie można anulować subskrypcję tematów/sekcji na stronach dyskusji. MarMi wiki (dyskusja) 22:33, 28 sty 2023 (CET)

W sumie to sam sobie zapomniałem wyłączyć dodawanie, więc sobie poprawiałem właśnie. Jakby co takie coś jak niżej zadziała konsoli JS (CTRL+SHIFT+I):

function wylaczWgOpisuZmian(opisZmian) {
  var strony = [];
  document.querySelectorAll('.mw-contributions-list li').forEach((li) => {
    let strona = li.querySelector('.mw-contributions-title').textContent;
    let opis = li.querySelector('.comment')?.textContent;
    if (opis.indexOf(opisZmian) >= 0) {
      console.log('do wyłączenia: ', {strona, opis});
      strony.push(strona);
    }
  });
  var api = new mw.Api();
  api.unwatch(strony).done((data) => {
    console.log('gotowe; ', data);
  });
}
// TUTAJ wpisz filtr opisów (tekst, bez linków)
wylaczWgOpisuZmian(`WP:SK, int`);

Ja akurat miałem opis zmian „WP:SK, int”, więc nie zapomnij zmienić tej linijki odpowiednio. –Nux (dyskusja) 21:29, 28 sty 2023 (CET)

Edytor kodu ("nowy") - Kod programu bez nowiki

Edytor kodu ("nowy"), przy zaznaczeniu fragmentu i zastosowaniu stylu Kod programu, umieszcza go tylko w bloku code (brak bloku nowiki). MarMi wiki (dyskusja) 12:17, 1 lut 2023 (CET)

Rożnice wizualne: problem z porównywaniem tabel

W funkcjach eksperymentalnych jest dostępna funkcja "Rożnice wizualne." Chciałem ją sprawdzić na stronie Autobusy w Łodzi, gdyż tam nieprzejrzane zmiany opierają się na edytowaniu tabel. Spodziewałem się, że ta opcja podkreśli mi na tabeli komórki, w których dokonano zmiany. Niestety, funkcja ta jedynie stwierdza, że tabela została zmieniona i podkreśla ją całą, zamiast jedynie podkreślać komórki w których doszło do zmiany. Czy jest zatem jakiś prosty sposób, aby zmiany w tabelach były reprezentowane w sposób łatwy do zrozumienia? Chętnie bym skorzystał. Z poważaniem, Dominik. Dominik aus Polen (dyskusja) 19:29, 4 lut 2023 (CET)

@Dominik aus Polen: niestety nie ma takiej opcji ;/ Na stronie opisu narzędzia, w sekcji #Current limitations, w drugim punkcie jest napisane, że to narzędzie ma problem ze skomplikowanymi tabelami. Trzeba poczekać, aż programiści WMF coś wymyślą i to poprawią. Tak więc, tut mir leid ;) Kłaniam się tufor (dyskusja) 20:02, 4 lut 2023 (CET)

@Tufor Szkoda, myślałem, że to coś w stylu kwestii zmienienia jednej opcji. (P.S. link który wysłałeś nie działa, ale zaufam na słowo) Dominik aus Polen (dyskusja) 20:08, 4 lut 2023 (CET)

link poprawiony ;) tufor (dyskusja) 20:15, 4 lut 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: [17] 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)

Edycja komórek tabeli pod VE

Czy to tylko u mnie, czy przestała działać edycja komórek tabeli przez dwuklik? MarMi wiki (dyskusja) 01:19, 18 lut 2023 (CET)

Naprawione. Matma Rex dyskusja 19:36, 21 lut 2023 (CET)

Załatwione, ~malarz pl ^PISZ 20:03, 21 lut 2023 (CET)

Być może powiązane, albo to coś nowego:
Kopiuj/wklej przypisu tuż za wikilinkami w komórkach tabeli dodaje spację przed wstawianym przypisem (niewidoczną po wklejeniu, widoczne po przełączeniu w kod, podglądzie różnic w wikikodzie, albo po zapisie). Co ciekawe dotyczy to tylko istniejących wikilinków (przy redlinkach tego nie ma - [18]). MarMi wiki (dyskusja) 13:08, 27 lut 2023 (CET)

@MarMi wiki Niepowiązane, ale faktycznie ciekawe. Zgłosiłem jako T330679. Dzięki! Matma Rex dyskusja 18:12, 27 lut 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)

Błąd w spisie treści

Da się cos zrobić z błędnym renderowaniem nagłówka w spisie treści na TEJ stronie? Chodzi o sekcję 2. Przy sekcji jest ok. Krzysiek 123456789 (dyskusja) 20:19, 20 lut 2023 (CET)

Nie stosować znacznika math w nagłówku :) To UNIQ to wewnętrzna notacja z jakiejś pośredniej fazy parsowania strony Msz2001 (dyskusja) 20:22, 20 lut 2023 (CET)

@Msz2001tak myślałem, ze trzeba to usunąć tylko ja się nie wczytywałem za mocno i nie dotykałem bo może to jest tam konieczne. Krzysiek 123456789 (dyskusja) 21:47, 20 lut 2023 (CET)

Ten problem jest zgłoszony na Phabricatorze jako phab:T295091, ale chyba nikt za bardzo nie wie, jak go rozwiązać. Zamiast <math> w nagłówkach można użyć symboli Unicode, które można skopiować sobie z tabelki takiej jak en:Mathematical Alphanumeric Symbols#Tables of styled letters and digits. W tym artykule byłoby to 𝓛(𝜏). Nie wyglądają identycznie jak ${\mathcal {L}}(\tau )$ (inna czcionka), ale bardzo podobnie, i moim zdaniem byłoby to do przyjęcia. Matma Rex dyskusja 19:51, 21 lut 2023 (CET)

Załatwione, ~malarz pl ^PISZ 20:04, 21 lut 2023 (CET)

Wiadomości techniczne: 2023-08

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

Problemy

• W zeszłym tygodniu, podczas planowej konserwacji Cloud Services, nieprzewidziane komplikacje wymusiły wyłączenie wszystkich narzędzi na 2–3 godziny, aby zapobiec uszkodzeniu danych. Dokładamy starań, by uniknąć takich problemów w przyszłości. [19]

Zmiany w tym tygodniu

• Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 21 lutego, na stronach innych niż Wikipedia i niektórych Wikipediach od 22 lutego, a następnie na wszystkich wiki od 23 lutego (harmonogram).
• Faza głosowania w Badaniu Życzeń Społeczności kończy się 24 lutego o 18:00 UTC. Wyniki zostaną ogłoszone 28 lutego.

Przyszłe zmiany

• Wszystkie wiki będą 1 marca przez kilka minut w trybie tylko do odczytu. Planowane jest to na godzinę 14:00 UTC. Więcej informacji zostanie opublikowanych w Tech News oraz w oddzielnym komunikacie, który zostanie rozesłany na wiki. [20][21][22]

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:57, 21 lut 2023 (CET)

Załatwione, ~Cybularny^{Napisz coś ✉} 07:21, 21 lut 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)

Galerie wywoływane wikitabelką

cześć, jakiś czas temu trochę poprawiałem galerie wywoływane za pomocą kodu wikitabelki; d otej pory robiłem to ręcznie. Dzięki sprytnemu regexowi P. Bowmana mam do dyspozycji taką listę artykułów do poprawy: Wikipedysta:PBbot/galerie w postaci wikitabelek (lista może chyba nie być w 100% pełna).

Do tej pory robiłem to sam i ręcznie, ale ostatnio zauważyłem, że w nowym wektorze pojawił się pasek narzędzi z prawej strony ekranu. W związku z tym problemy z galeriami tabelkowymi stały się bardziej widoczne, poniżej przykłady:

• 
• 
• 
• 
• 

w związku z tym chciałem się Was poradzić, czy macie może jakiś pomysł na automatyzację procesu poprawy tych galerii; jest ich obecnie około 500, więc teoretycznie byłbym w stanie to zrobić ręcznie, zwłaszcza jak zbierze się kilka osób do pomocy, ale jeśli jest jakaś możliwość zrobienia tego łatwiej i szybciej, to chętnie się o niej dowiem. Z góry dzięki za odp, pzdr Archiwald (dyskusja) 02:59, 23 lut 2023 (CET)

• Szybciej: botem, czy łatwiej - nie wiem. Żeby było pewniej to pewnie warto by przejrzeć potem działalność bota. Można też spróbować zrobić to jakimś skryptem (typu WPSK). Przy tej liczbie artykułów pewnie nakład pracy będzie mniejszy niż ręczna zabawa. ~malarz pl ^PISZ 10:07, 23 lut 2023 (CET)

  Z WP:SK najprościej chyba będzie robić to w dwóch krokach - najpierw pozamieniać otwarcie/zamknięcie tabeli na odpowiednie tagi gallery, a potem usuwać z wierszy początkowe |[[ i końcowe ]] pomiędzy takimi tagami.
  Minimalne zmiany. MarMi wiki (dyskusja) 13:53, 23 lut 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)

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)

Nowa wersja disFixera (poprawa ujednoznacznień)

Cześć. Przygotowałem nową wersję disFixera.

Wystarczy wejść w edycję common.js i wkleić sobie takie coś, żeby przetestować:

mw.loader.load("https://pl.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&smaxage=21600&maxage=86400&title=Wikipedysta:Nux/disFixer.js");
mw.loader.load("https://pl.wikipedia.org/w/index.php?action=raw&ctype=text/css&smaxage=86400&maxage=259200&title=Wikipedysta:Nux/disFixer.css", "text/css");

Zmiany:

• Sortowanie alfabetyczne.
• Możliwość filtrowania listy linków.
• Nowy wygląd oparty na OOUI. Używam głównie nowego Vectora, ale na starym też powinno wyglądać dobrze.

U mnie działa, ale prośba o przetestowanie. Tym którym się nie podoba niech powiedzą to teraz lub zamilkną na wieki ;). Nux (dyskusja) 20:19, 25 lut 2023 (CET)

• Wada nr 1: jest mniejsza czcionka (co za tym idzie strzałki odwoławcze ⇗⇓ też są mniejsze i trudniej w nie ucelować). Wada nr 2: w niektórych hasłach (np. Osiedle Mikołaja Kopernika) pojawiają się dwie ranki "popraw linki do ujednoznacznień", przy czym tylko ta pierwsza działa. Po jej rozwinięciu pojawia się natomiast dwa razy to samo: możliwość poprawy linków do "Pomnik Mikołaja Kopernika" i "Ulica Mikołaja Kopernika" w starej i nowej wersji. Poza tym sortowanie alfabetyczne działało chyba już wcześniej (nie jestem pewny). To tyle co na szybko zauważyłem. BTW Nie znam się na technikaliach, ale zawsze mnie to nurtuje: po co naprawiać coś co dobrze działa? ptjackyll (zostaw wiadomość) 20:36, 25 lut 2023 (CET)

  @Ptjackyll a wyłączyłeś sobie starą wersję w preferencjach? AramilFeraxa (Napisz do mnie!) 20:37, 25 lut 2023 (CET)

  A, no faktycznie nie wyłączyłem. Ale to i tak już nieaktualne: wracam do starej wersji, która była bardzo dobra. :) ptjackyll (zostaw wiadomość) 20:38, 25 lut 2023 (CET) I jeszcze jedno: potwierdzam: w starej wersji sortowanie alfabetyczne działa. ptjackyll (zostaw wiadomość) 20:39, 25 lut 2023 (CET)

  @Ptjackyll pff, czcionka za mała, okulary kupić a nie marudzić ;). Ale serio to myślałem, czy tego na tekst nie zmienić nawet, ale nie mam pomysłu jaki (musiałby być bardzo krótki). Nux (dyskusja) 20:48, 25 lut 2023 (CET)

  @Nux Okulary są i to akurat miesiąc temu zmieniane! Znowu mi dioptrii dorzucili... A pomyśleć, że z wiekiem będzie tylko gorzej. :( ptjackyll (zostaw wiadomość) 20:51, 25 lut 2023 (CET)

  Poprawiłem czcionkę. Na krótkich disambigach może słabo widać zalety filtrowania. Zrobiłem stronkę testową: Wikipedysta:Nux/test disFixer. Jest w niej link do Aberdeen, który jest już dosyć długi. Przy filtrowaniu wystarczy wpisać „im”, żeby dostać podpowiedź do Aberdeen (imię). Nux (dyskusja) 21:01, 25 lut 2023 (CET)

  Zawiesił mi się na komórce na haśle Gonfalon Kościoła. Używałem FF dla Androida w trybie "wersja na komputer" i strony bez "m." w adresie. Gadżet się odpalił, ale po naciśnięciu przycisku "Popraw" kazał czekać bez końca na okienko wyboru. Gżdacz (dyskusja) 07:36, 26 lut 2023 (CET)

  Hm... Po naciśnięciu popraw to już raczej kwestia jakiś gadżetów do edycji, które masz włączone. U mnie działa w każdym razie. Też z Foksa korzystam :). Nux (dyskusja) 12:51, 26 lut 2023 (CET)

  Zacina się po pierwszym naciśnięciu belki "Popraw linki do ujednoznacznień i przekierowań", jeszcze zanim pojawią się okienka z filtrami i innymi cudami Twojego autorstwa. Więc to raczej nie jest kwestia gadżetów do edycji. Na kompie zresztą też się wiesza (też FF). Gżdacz (dyskusja) 14:17, 26 lut 2023 (CET)

  @Gżdacz Dziwne, a jakie masz opcje w Specjalna:GadgetPrefs? Nux (dyskusja) 14:37, 26 lut 2023 (CET)

  Zaznaczone są:

  • Oznacz zmiany jako małe.
  • Automatycznie uruchom WP:SK po każdej zmianie.

  Pozostałe dwie nie są zaznaczone. Gżdacz (dyskusja) 17:07, 26 lut 2023 (CET)

  Wygląda na to, że skrypt nie był odporny na błędy w danych zwracanych z API. Teraz powinien przynajmniej coś wyświetlić w konsoli JS i powinien dać możliwość spróbowania ponownie... Chociaż to ogólnie dziwne, bo tylko raz mi się to udało powtórzyć na kilkadziesiąt prób. Możliwe, że API Mediawiki co jakiś czas nie wyrabia.

  Aha. Wyczyść sobie cache zanim będziesz testować. Nux (dyskusja) 21:07, 26 lut 2023 (CET)

  Naprawiłeś Gonfalon, muszę coś nowego znaleźć ;) Gżdacz (dyskusja) 21:27, 26 lut 2023 (CET)

Dzięki za te zmiany, na pewno odświeżanie gadżetów (mówiąc innym językiem: modów) jest bardzo pożyteczne. Niestety, ja też widzę mniejszy tekst niż domyślny (zarówno "Popraw ujednoznacznienia:", jak i w menu rozwijanych), a do tego przyciski "Popraw linki do ujednoznacznień i przekierowań" oraz "Popraw" mają styl sprzed OOUI. Tak samo checkbox i tekst "popraw przekierowania". Ponadto usunąłbym zielony kolor fontu "popraw przekierowania". Tar Lócesilion (dyskusja) 03:06, 26 lut 2023 (CET)

Hm... Ciekawe. Byłem przekonany, że większość powie, że raczej nowa wersja jest za duża w stosunku do starej wersji... Ale jak tak, to OK. Powiększyłem wszystko.

Zmieniłem też przycisk na OOUI, chociaż nie jestem do tego przekonany, bo w sumie to komponenty tego typu raczej obniżają wydajność (a w tym wypadku nie daje nic w zamian w zasadzie)...

Checkboksa nie chcę zmieniać, bo w sumie to nie wiem co ten kolor oznacza. A nie lubię zmieniać rzeczy, które nie wiem po co są 😉. Nux (dyskusja) 14:13, 26 lut 2023 (CET)

A propo checkboxa: jest o wiele za szeroki, powinien dostosowywać się do swojej zawartości (testowane wczoraj). MarMi wiki (dyskusja) 16:15, 26 lut 2023 (CET)

Nie wiem, czy tak ma być, ale guzik Popraw linki do ujednoznacznień i przekierowań wyświetla mi się na środku, rozciągnięty na całą szerokość, a wcześniej wyświetlał się z boku po lewej. AramilFeraxa (Napisz do mnie!) 15:10, 26 lut 2023 (CET)

Tego akurat nie ruszałem. Ja zawsze miałem taki rozciągnięty, chociaż nie używam tego za dużo. Za pewne zmiany w skórce na to wpłynęły. Nux (dyskusja) 20:24, 26 lut 2023 (CET)

Belka/przycisk disFixera pokazuje się czasem (wyszarzona) po wejściu w edytuj kod sekcji (nie pamiętam czy tak było przy starej wersji).
Edycja: Przycisk pokazuje się zawsze przy obu edycjach (zakładki Edytuj/Edytuj kod źródłowy).
Edycja2: A czasami potrafi nawet być aktywny (przynajmniej w trybie edycji sekcji). MarMi wiki (dyskusja) 13:08, 28 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ą: [23] (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)

Lintera problem z szablonami

Gdzieś głęboko w naszych szablonach są albo nowe problemy, albo linter zaczął zgłaszać nowe rzeczy.

• tutaj gdzieś jest tak zaszyte że nie mogę nic znaleźć.
• tutaj chyba jest nowa reguła użyta, bo te rzeczy czasem nie były edytowane przez lata

PMG (dyskusja) 11:52, 27 lut 2023 (CET)

Pierwszy problem rozwiązany: Special:Diff/69733209. tufor (dyskusja) 12:05, 27 lut 2023 (CET)

A ja trochę to rozwiązanie uprościłem i poprawiłem dodatkowo jeszcze inny błąd. ~malarz pl ^PISZ 12:11, 27 lut 2023 (CET)

A co do drugiego to chyba ktoś zajrzał na te strony i dopiero teraz linter po raz pierwszy od wprowadzenia informacji o błędach je obejrzał. IMO to te smalle trzeba usunąć, onie nie współpracują dobrze z {{show}}. Ew. mozna to zamienić na diva z css'em, ale moim zdaniem szkoda na to czasu. ~malarz pl ^PISZ 12:16, 27 lut 2023 (CET)

<small>
#pęcherzyk mózgowy
...
#uchyłek wątrobowy
</small>

generuje (bez formatowania; raw html z Rozwijania szablonu)

<div class="mw-parser-output">
  <p><small>
    </small></p><small>
    <ol>
      <li>pęcherzyk mózgowy</li>
      ...
      <li>uchyłek wątrobowy</li>
    </ol>
  </small><small></small>
  <p><small></small>
  </p>
</div>

Edycja: Najwyraźniej small nie może być obecnie używany do pomniejszania list (albo lint jest nadgorliwy - inne walidatory online też tak uważają - elementy ul/ol nie są dozwolone wewnątrz small). MarMi wiki (dyskusja) 12:22, 27 lut 2023 (CET)

Ponieważ te wszystkie opisy i tak były rozwijalne, to stwierdziłem że ten small tak średnio jest potrzebny. A skoro jest niepoprawny składniowo to skasowałem te smalle. PMG (dyskusja) 13:27, 27 lut 2023 (CET)

Załatwione PMG (dyskusja) 13:28, 27 lut 2023 (CET)

Wiadomości techniczne: 2023-09

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, w niektórych miejscach na świecie występowały problemy z ładowaniem stron. Trwały one przez 20 minut, a z zapisywaniem edycji - 55 minut. Spowodowane one były problemem z serwerami pamięci podręcznej, który wystąpił podczas rutynowych prac technicznych. [24][25]

Zmiany w tym tygodniu

• Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 28 lutego, na stronach innych niż Wikipedia i niektórych Wikipediach od 1 marca, a następnie na wszystkich wiki od 2 marca (harmonogram).
• Wszystkie wiki będą 1 marca przez kilka minut w trybie tylko do odczytu. Jest to zaplanowane na 14:00 UTC. [26]

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

MediaWiki message delivery 00:46, 28 lut 2023 (CET)

Załatwione, ~Cybularny^{Napisz coś ✉} 00:47, 28 lut 2023 (CET)