Wikipedia:Kawiarenka/Kwestie techniczne dyskusja/Archiwum/2023-luty

Z Wikipedii, wolnej encyklopedii

Absolwenci gimnazjów na wschodzie[edytuj | edytuj kod]

Status: błędne

Krótkie wprowadzenie: przed I w.ś. zdarzało się, i to nierzadko, że z różnych przyczyn Polacy kończyli gimnazja gdzieś w innych miastach imperium. Np. Kotarbiński kończył trochę przymusowo w Parnawie (dzisiaj Estonia), Iłłakowiczówna w Petersburgu itp. Trochę brakuje mi kategorii grupującej takie osoby, bo przecież Kategoria:Absolwenci uczelni w Petersburgu i tym podobne to nie to samo. Macie jakieś sugestie? Jest sens wstawiać coś tak ogólnego? Zorro2212 (dyskusja) 09:35, 1 lut 2023 (CET)[odpowiedz]

Zorro2212, nie ten stolik. O kategoryzacji rozmawia się przy Wikipedia:Kawiarenka/Artykuły. Tu Załatwione, Michał Sobkowski dyskusja 10:07, 1 lut 2023 (CET)[odpowiedz]
OK, sorry. Przeniosę.--Zorro2212 (dyskusja) 10:20, 1 lut 2023 (CET)[odpowiedz]

Zmiana linkowania[edytuj | edytuj kod]

Chciałbym zmienić linkowanie z https://drive.google.com/file/d/0BxyG1Xdg1erqZXItQkhlWTBJUXc/view na https://www.pwnhc.ca/download/gazetteer-of-the-northwest-territories/?wpdmdl=3032, ale nie umiem wyszukać w wyszukiwarce wikipedii tego pierwszego ciągu. Paelius (dyskusja) 00:11, 5 lut 2023 (CET)[odpowiedz]

Załatwione ~malarz pl PISZ 00:27, 5 lut 2023 (CET)[odpowiedz]

Bot-uparciuch (kontrola autorytatywna)[edytuj | edytuj kod]

Bot niestrudzenie wprowadza szablon kontroli autorytatywnej do hasła (np. tu); problem w tym, że linki w dodanym szablonie prowadzą do zupełnie innego zagadnienia (mimo takiej samej nazwy).
Ambiroz (dyskusja) 08:55, 6 lut 2023 (CET)[odpowiedz]

Wiadomości techniczne: 2023-06[edytuj | edytuj kod]

MediaWiki message delivery 11:20, 6 lut 2023 (CET)[odpowiedz]

Załatwione ~Cybularny Napisz coś ✉ 11:23, 6 lut 2023 (CET)[odpowiedz]

Szablon Sortkey[edytuj | edytuj kod]

Szablon {{sortkey}} działa cokolwiek dziwnie - wie ktoś dlaczego?

1sza kol. 2ga kol. Liczby Liczby w Sortkey
es --- 1996 SSS
ru --- 1995 SSS
ceb 1254 4 SSS
nl 1095 3 SSS
pl ===== 0 SSS
ja 339 -4 SSS
fa 350 -5 SSS
vi --- -1701 SSS
sr --- -1705 SSS

Z uszanowaniem, Ency (replika?) 14:18, 3 lut 2023 (CET)[odpowiedz]

A o co konkretnie chodzi? (Bez zaglądania w kod).
Edycja po zajrzeniu w kod: kolumna Liczby w Sortkey są z sortkey ({{sortkey|1996}} SSS), więc zapewne powinna sortować się tak samo jak kolumna Liczby. MarMi wiki (dyskusja) 16:58, 3 lut 2023 (CET)[odpowiedz]
Dla porównania z {{L}}.
1sza kol. 2ga kol. Liczby Liczby w Sortkey
es --- 1996 1996 SSS
ru --- 1995 1995 SSS
ceb 1254 4 4 SSS
nl 1095 3 3 SSS
pl ===== 0 0 SSS
ja 339 -4 -4 SSS
fa 350 -5 -5 SSS
vi --- -1701 -1701 SSS
sr --- -1705 -1705 SSS
MarMi wiki (dyskusja) 17:06, 3 lut 2023 (CET)[odpowiedz]
Dodaj do kolumny z sortkey data-sort-type (linki na dole strony szablonu).
Edycja: Co ciekawe, po dodaniu tego samego do tabeli z L, kolumna przestanie się sortować. MarMi wiki (dyskusja) 17:16, 3 lut 2023 (CET)[odpowiedz]
Ok., widzę że Nux uzupełnił dokumentację szablonu (dzięki!). Przyda się. W ogóle kwestia wynikła z tego, że w końcu zmodyfikowałem kod comiesięcznego rankingu (vide {{Podstawowy ranking międzyjęzykowy}}) z sortowaniami, które od pewnego momentu działały niepoprawne, i chciałem zastosować {{sortkey}}, ale zanim Nux zadziałał poradziłem sobie inaczej. Z uszanowaniem, Ency (replika?) 00:07, 4 lut 2023 (CET)[odpowiedz]

Jakby co dodałem przykład wymuszenia sortowania w wypadku ujemnych liczb: Szablon:Sortkey#Wymuszenie sortowania numerycznego. Rzymianie co prawda chyba nie mieli ujemnych liczb ;), ale mam nadzieję, że i tak to jest czytelne. Tak jak MarMi napisał – warto dodać typ dodatkowo, bo algorytm czasem sortuje liczby jak litery (jak nie jest pewien co do rodzaju zawartości). --Nux (dyskusja) 23:52, 3 lut 2023 (CET)[odpowiedz]

Jeszcze raz dzięki - można na was (Nuksa też :-)) liczyć, Z uszanowaniem, Ency (replika?) 00:08, 4 lut 2023 (CET)[odpowiedz]
Dla bota: Załatwione. XaxeLoled AmA 16:11, 7 lut 2023 (CET)[odpowiedz]

Problem z logowaniem do Meta[edytuj | edytuj kod]

Serwer meta.wikimedia.org odrzuca mi próby logowania poprawnym hasłem, którym loguję się bez problemu do pl. Otrzymuję komunikat:

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please resubmit the form.

Jestem jedyny czy wprowadzono jakiś hardening? — smyru 18:15, 8 lut 2023 (CET)[odpowiedz]

Wiadomości techniczne: 2023-07[edytuj | edytuj kod]

MediaWiki message delivery 02:48, 14 lut 2023 (CET)[odpowiedz]

Załatwione, AramilFeraxa (Napisz do mnie!) 06:03, 14 lut 2023 (CET)[odpowiedz]

błędy lintera 31 stycznia 2023[edytuj | edytuj kod]

Posprzątałem tego ponad 500 ale kilku nie potrafię. Osierocona zawartość, Nadmiarowe znaczniki tabeli do usunięcia, Niekompletne znaczniki. Razem 12 błędów, z czego 3 w 4 (album Wilków) PMG (dyskusja) 14:56, 31 sty 2023 (CET)[odpowiedz]

Załatwione, ~malarz pl PISZ 13:45, 18 lut 2023 (CET)[odpowiedz]

W pobliżu[edytuj | edytuj kod]

Na stronie [10] wypadałoby zmienić "twojej" na "Twojej". Wyraża to więcej szacunku dla czytelników. Sebek A. (dyskusja) 09:48, 19 lut 2023 (CET)[odpowiedz]

Zmieniłem w translatewiki:MediaWiki:Nearby-pages-info-heading/pl oraz translatewiki:MediaWiki:Nearby-pages-info-description/pl, po zatwierdzeniu zmiany staną się widoczne przy następnej aktualizacji oprogramowania. Peter Bowman (dyskusja) 11:19, 19 lut 2023 (CET)[odpowiedz]

Załatwione, ~malarz pl PISZ 11:39, 19 lut 2023 (CET)[odpowiedz]

Jakiś czas temu rozmawialiśmy sobie o pomyśle, żeby Nieprzejrzane strony wyświetlać nie alfabetycznie, tylko według daty tzn. nie alfabetycznie, tylko według daty. I właśnie zostało to wdrożone (phab:T45857, podziękowania dla Bartosz Dziewoński, SGrabarczuk, Tgr).

Pojawił się tylko taki niewielki problem, że po wdrożeniu nowego sortowania, na Nieprzejrzanych stronach wysypał się komunikat „Poniższe dane są kopią z pamięci podręcznej. Ostatnia aktualizacja odbyła się o…. W pamięci podręcznej znajduje się maksymalnie … wyników.” (mediawiki:perfcachedts). Nie jest zwracana wartość dla parametru $4. --WTM (dyskusja) 23:08, 17 lut 2023 (CET)[odpowiedz]

Załatwione, ~malarz pl PISZ 11:39, 19 lut 2023 (CET)[odpowiedz]

Szablon {{Szablon:Link-interwiki}} nie dzała, np. tutaj: Kategoria:Filozofia miłości, Galina Strielcowa#Życiorys i in. Zamiast linku do innych Wikipedii pojawia się wiadomość "Nie udało się wczytać listy języków". Puszczanin (dyskusja) 08:27, 12 lut 2023 (CET)[odpowiedz]

P. S. @Paweł Ziemian dziękuję, ale ten szablon w tym haśle wkrótce zostanie zbyteczny i będzie w ogóle do usunęcia, bo właśnie zamierzam utworzyć na pl-wiki to brakujące hasło (filozofia miłości). Nawet możemy to zaraz zrobić, bo już mamy załążek polskiego odpowiednika artykułów powiązanych z elementem d:Q7186272: Miłość#Teorie filozoficzne. Po prostu chcę, by szablon działał, bo jest pożyteczny i używa się go w innych artykułach. --Puszczanin (dyskusja) 10:49, 12 lut 2023 (CET)[odpowiedz]
Szablon działa (przynajmniej u mnie), bez Q, dla małej i dużej litery.
Być może było (jest) coś nie tak z którymś z szablonów, z których link korzysta (albo WD)?
Edycja: Po komunikacie wnoszę, że to "wina" gadżetu MediaWiki:Gadget-interwiki-langlist (MediaWiki:Gadget-interwiki-langlist.js), którego nie używam. MarMi wiki (dyskusja) 13:14, 12 lut 2023 (CET)[odpowiedz]
@MarMi wiki Ja nie wiem, co to za gadżet i jak go używać, bo nie znam się na kwestiach technicznych. Co znaczy WD? Przepraszam, a np. tutaj (Jakob Böhme, "filozofia erotyczna") u Ciebie działa? Co raz muszę zmieniać małą literę na dużą (np. tutaj, art "Sens miłości" Sołowjowa). Czy szablon nie działa dla małej litery tylko u mnie? --Puszczanin (dyskusja) 13:37, 12 lut 2023 (CET)[odpowiedz]
Szablon działa z małą literą, gadżet już nie.
Specjalna:Preferencje#mw-prefsection-gadgets - odznacz "Rozszerzenie szablonu {{link-interwiki}} ...". Musiałeś go kiedyś sobie włączyć (albo ja sobie to kiedyś wyłączyłem). Z tym że wtedy będzie tylko jeden język do "wyboru".
Być może mało ludzi tego używa, albo miałeś akurat pecha trafiając na takie przypadki. MarMi wiki (dyskusja) 13:53, 12 lut 2023 (CET)[odpowiedz]
@Msz2001
Ping do autora gadżetu. MarMi wiki (dyskusja) 13:54, 12 lut 2023 (CET)[odpowiedz]
Dzięki za ping. Poprawiłem gadżet. Okazuje się, że Wikidane odpytane o nazwę artykułu, zaczynającą się od małej litery, zwracały pusty zbiór. Załatwione Msz2001 (dyskusja) 14:26, 12 lut 2023 (CET)[odpowiedz]
@MarMi wiki Teraz zrozumiałem: ten gadżet naprawdę istnieje w mych preferencjach i był tam włączony. Nie mogłem go włączyć, bo nie wiedziałem o jego istnieniu i tylko byłem zdumiony, że od pewnego czasu zamiast jednego języka pojawiło się kilka języków do "wyboru". Myślałem, że to jakiś fachowiec dopracował szablon. Po Twojemu wyjaśnieniu wyłączyłem ów gadżet i szablon u mnie znów zaczął działać (z jednym językiem, jak wcześniej). Dziękuję. @Msz2001 Po Twojej odpowiedzi spróbowałem włączyć gadżet i okazało się, że szablon zaczął działać z kilkoma językami również. Fajnie. Tak więc mamy, o ile rozumiem, dwie wersje szablonu: z gadżetem i bez gadżetu. Nie wiedzałem o tych możliwościach. --Puszczanin (dyskusja) 15:34, 12 lut 2023 (CET)[odpowiedz]
Szablon jest jeden, gadżet (najprawdopodobniej) modyfikuje tylko jego wygląd, co w przypadku błędu, jak widać, może spowodować "zepsucie" wyniku szablonu. MarMi wiki (dyskusja) 17:03, 12 lut 2023 (CET)[odpowiedz]

@Msz2001 Dopiro co zauważyłem: jeśli włączyć Twój gadżet w preferencjach, to {{link-interwiki|Dialogi o miłości|Q=58510334}} (zob. Jehuda Abrabanel#Dialoghi d'amore) nie powoduje linku do WIKIDATA. --Puszczanin (dyskusja) 17:58, 15 lut 2023 (CET)[odpowiedz]

Gadżet działa zgodnie z oczekiwaniami - Wikidane nie są językiem, więc pokazuje się że strona nie jest dostępna w żadnym języku, a link do Wikidanych jest u dołu panelu. Msz2001 (dyskusja) 18:03, 15 lut 2023 (CET)[odpowiedz]

Załatwione, ~malarz pl PISZ 11:40, 19 lut 2023 (CET)[odpowiedz]

Statystyki wyszukiwania nieistniejących haseł[edytuj | edytuj kod]

Czy istnieje narzędzie, które pozwoliłoby wylistować najczęściej wyszukiwane nieistniejące hasła/zagadnienia? Utworzenie pożądanych treści byłoby bardzo pożyteczne. Mathieu Mars (dyskusja) 22:29, 6 lut 2023 (CET)[odpowiedz]

  • Jest takie narzędzie GapFinder, które wskazuje najczęściej odwiedzane artykuły danej wersji językowej, nieobecne na innej. Np. z porównania en i pl.wiki wychodzi, że najbardziej brak nam filmu Knock at the Cabin (165 tys. odwiedzin na en.wiki), Super Bowl LVII – nadchodzące wydarzenie (60 tys.), Vadh (film), Critical race theory, Shrinking (TV series), Hindenburg disaster, Cristian Stellini (piłkarz). Te wyniki i inne porównania oczywiście są tendencyjne – różne kręgi językowe (kulturowe) mają różne skrzywienie informacyjno/tematyczne. Kenraiz (dyskusja) 08:47, 7 lut 2023 (CET)[odpowiedz]
  • Dziękuję. Mathieu Mars (dyskusja) 15:05, 7 lut 2023 (CET)[odpowiedz]

Załatwione, ~malarz pl PISZ 11:40, 19 lut 2023 (CET)[odpowiedz]

Wiadomości techniczne: 2023-08[edytuj | edytuj kod]

MediaWiki message delivery 02:57, 21 lut 2023 (CET)[odpowiedz]

Załatwione, ~Cybularny Napisz coś ✉ 07:21, 21 lut 2023 (CET)[odpowiedz]

Błąd w spisie treści[edytuj | edytuj kod]

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

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)[odpowiedz]
@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)[odpowiedz]
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 (inna czcionka), ale bardzo podobnie, i moim zdaniem byłoby to do przyjęcia. Matma Rex dyskusja 19:51, 21 lut 2023 (CET)[odpowiedz]

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

Lintera problem z szablonami[edytuj | edytuj kod]

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

Pierwszy problem rozwiązany: Special:Diff/69733209. tufor (dyskusja) 12:05, 27 lut 2023 (CET)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
<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)[odpowiedz]
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)[odpowiedz]

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

Wiadomości techniczne: 2023-09[edytuj | edytuj kod]

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

Załatwione, ~Cybularny Napisz coś ✉ 00:47, 28 lut 2023 (CET)[odpowiedz]

MalarzBOT i Encyklopedia Britannica[edytuj | edytuj kod]

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

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)[odpowiedz]
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)[odpowiedz]
Przykłady zachowania daty dostępu: [18], [19] - 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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
  • 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)[odpowiedz]
    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)[odpowiedz]
  • 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)[odpowiedz]
  • 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)[odpowiedz]
    @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)[odpowiedz]
    • 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)[odpowiedz]
    • 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)[odpowiedz]

Edytor kodu ("nowy") - Kod programu bez nowiki[edytuj | edytuj kod]

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

Rożnice wizualne: problem z porównywaniem tabel[edytuj | edytuj kod]

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

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

Podgląd po zmianach w wersji mobilnej[edytuj | edytuj kod]

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

Automatyczne blokowanie[edytuj | edytuj kod]

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

  • 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. IOIOI2 23:07, 4 lut 2023 (CET)[odpowiedz]
  • 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)[odpowiedz]
    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)[odpowiedz]
    Raczej czy koszt odwracania skutków jest mniejszy/większy niż zrobienie zabezpieczenia. MarMi wiki (dyskusja) 13:25, 6 lut 2023 (CET)[odpowiedz]
    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)[odpowiedz]
    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ł. IOIOI2 10:45, 6 lut 2023 (CET)[odpowiedz]
Tu było 14 edycji w 2 minuty z jakiegoś szemranego IP: [20] Mathieu Mars (dyskusja) 15:58, 7 lut 2023 (CET)[odpowiedz]
  • 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)[odpowiedz]

Subskrypcja wątków w dyskusjach wikiprojektu[edytuj | edytuj kod]

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

Szablony Congbio i CANbio[edytuj | edytuj kod]

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

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

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

Może ktoś przygotuje dobry nowy szablon (projekt szablonu)? ~malarz pl PISZ 20:35, 9 lut 2023 (CET)[odpowiedz]

Szablon Tabela odcinków[edytuj | edytuj kod]

{{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)[odpowiedz]

Pierwszą kwestię ogarnąłem, drugą pozostawiaw bardziej obeznanym technicznie userom. XaxeLoled AmA 21:03, 9 lut 2023 (CET)[odpowiedz]
  • 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)[odpowiedz]

Adres parafii[edytuj | edytuj kod]

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

Szablon TV.com - martwa strona[edytuj | edytuj kod]

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

Szablon APR (Archiwum Polskiego Rocka) - zmiana adresu i schematu[edytuj | edytuj kod]

{{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)[odpowiedz]

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

Automatyczne przeglądanie wycofanych zmian[edytuj | edytuj kod]

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

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

Problem z szablonem {{Układ wielokolumnowy}}[edytuj | edytuj kod]

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 [21] oraz było w innych projektach co spowodowało, że nie wstawiam szablonu np. {{Układ wielokolumnowy}}. Proszę o poprawę mojego profilu i pomoc w naprawieniu tegoz szablonu, abym mógł go wstawić w projektach. Keres 40 (dyskusja) 10:11, 12 sty 2023 (CET)[odpowiedz]

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

dyskusja nad zmianą w obsłudze domyślnej szerokości kolumn[edytuj | edytuj kod]

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

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)[odpowiedz]
Nie rozumiem. Jakie „sztywno”? Podaj przykład gdzie to działa źle. Paweł Ziemian (dyskusja) 21:03, 19 sty 2023 (CET)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
"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)[odpowiedz]
  • 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)[odpowiedz]
  • 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)[odpowiedz]
    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)[odpowiedz]
    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)[odpowiedz]
    Korelujesz ze sobą przypadkowe powiązania. Liczba kolumn nie decyduje o zawartości. Nux (dyskusja) 22:20, 20 sty 2023 (CET)[odpowiedz]
    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)[odpowiedz]
    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)[odpowiedz]
    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)[odpowiedz]
    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)[odpowiedz]
    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)[odpowiedz]
    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)[odpowiedz]
  • 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)[odpowiedz]
    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)[odpowiedz]
    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)[odpowiedz]
    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)[odpowiedz]

Botowanie brakującej szerokości[edytuj | edytuj kod]

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

SZEROKOŚĆ NIE POWINNA ZALEŻEĆ OD LICZBY KOLUMN. Dziękuję za uwagę [: Nux (dyskusja) 22:48, 23 sty 2023 (CET)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
Część już Archiwald wyżej napisał. Ale proszę pierwszy przykład z brzegu w praktyce [27]. 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)[odpowiedz]
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)[odpowiedz]
  • 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)[odpowiedz]
    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)[odpowiedz]
    • 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)[odpowiedz]
      Wszystkie informacje są już powyżej. Wystarczy się z nimi zapoznać. Nux (dyskusja) 22:37, 24 sty 2023 (CET)[odpowiedz]
  • 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)[odpowiedz]
    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: [28]. 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)[odpowiedz]
  • 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)[odpowiedz]
    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)[odpowiedz]
  • 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)[odpowiedz]
    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)[odpowiedz]
    • 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)[odpowiedz]
      • 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)[odpowiedz]
        correlation is not causation ;-) Nux (dyskusja) 21:09, 26 sty 2023 (CET)[odpowiedz]
        Ale wykres ładny Nux (dyskusja) 21:10, 26 sty 2023 (CET)[odpowiedz]
        @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)[odpowiedz]
  • 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)[odpowiedz]
    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)[odpowiedz]
    • 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)[odpowiedz]
  • 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)[odpowiedz]
    a podałbyś które szablony teraz masz na myśli? Archiwald (dyskusja) 05:49, 4 lut 2023 (CET)[odpowiedz]
  • 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)[odpowiedz]
    mówimy teraz o artykułach zgrupowanych w Kategoria:Układ wielokolumnowy z wielopoziomową listą? Archiwald (dyskusja) 10:09, 10 lut 2023 (CET)[odpowiedz]
    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)[odpowiedz]
  • 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)[odpowiedz]

Układy wielokolumnowe wywołane poprzez column-count[edytuj | edytuj kod]

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

VE ikona komunikatu - brak treści[edytuj | edytuj kod]

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

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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
Powinno być naprawione tą edycją: [29] (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)[odpowiedz]