Wikipedia:Kawiarenka/Kwestie techniczne

Taza de café.png
Kawiarenka pod Wesołym Encyklopedystą – kwestie techniczne
Tu rozwiązujemy problemy dotyczące oprogramowania MediaWiki, botów, skryptów, technicznych zmian w szablonach itp. W celu przyspieszenia rozwiązania problemu technicznego zapoznaj się z instrukcją zgłaszania problemów.

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



Boty a artykuły oczekujące na przejrzenieEdytuj

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

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

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

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

Przypisy do WyborczejEdytuj

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

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

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

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

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

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

  • Zapytałem o przykładowy link za pomocą wget i faktycznie ów serwis zapodał <title>Wyborcza.pl</title>, a w <body> jakiś komunikat z prośbą o wyłączenie AdBlocka. Paweł Ziemian (dyskusja) 16:22, 11 gru 2022 (CET)Odpowiedz[odpowiedz]
    • i to jest problem, że najpierw jest zwracana strona przekierowania. masti <dyskusja> 20:48, 11 gru 2022 (CET)Odpowiedz[odpowiedz]
    • Swoją drogą to w stronach jest kilka różnych opcji do wyboru, np. dla artykułu [1]:
    <title>Francja. Dziennik "Le Figaro": Polska dąży do stworzenia największej armii lądowej w Europie | Biznes na Next.Gazeta.pl</title>
    
    <meta property="og:title" content="Francja. &#034;Le Figaro&#034;: Polska dąży do stworzenia największej armii lądowej w Europie" />
    
    <meta name="twitter:title" content="Francja. &#034;Le Figaro&#034;: Polska dąży do stworzenia największej armii lądowej w Europie" />
    

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

Szablony Congbio i CANbioEdytuj

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

disFixer vs popupsEdytuj

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

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

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

disFixer vs PlikEdytuj

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

Niewidoczny szablon Aktualizuj po (VE)Edytuj

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

Automatyzacja pracy przewodnikaEdytuj

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

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

Problem z szablonem {{Układ wielokolumnowy}}Edytuj

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 [2] 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[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[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[odpowiedz]
    • @Kenraiz Też tam trafiłem przypadkiem. I też mnie zdziwiło, że takie zmiany zostały omówione na prywatnej stronie wikipedysty. No ale się do niej dołączyłem. Chociaż teraz cieszę się, że w końcu trafiło to na publiczny stolik. Paweł Ziemian (dyskusja) 18:46, 12 sty 2023 (CET)Odpowiedz[odpowiedz]
    • "Z tym "szablon się posypał" bym nie przesadzał. IMO nie ma powodu do uznania, że coś jest porozwalane. ~malarz pl PISZ 11:11, 12 sty 2023 (CET)Odpowiedz[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[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[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[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[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[odpowiedz]
    • Przeredagowałem i uzupełniłem opis. Informacja, że szerokość 12em jest równa wysokości 12 wierszy tekstu była dość zagmatwana. Podałem, że „em” to w przybliżeniu szerokość litery „M”. Może jest to mniej precyzyjne, ale chyba łatwiejsze do zrozumienia dla laika. Michał Sobkowski dyskusja 16:56, 12 sty 2023 (CET)Odpowiedz[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[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[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[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[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[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 [3], byłbym bardzo wdzięczny, z góry dzięki. Keres 40 (dyskusja) 13:22, 12 sty 2023 (CET)Odpowiedz[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[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[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 ([4]), 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[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[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[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[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[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[odpowiedz]
Tutaj grafika ze wszystkimi przykładowymi czcionkami, które użyłem w brudnopisie: [5]. Msz2001 (dyskusja) 16:59, 12 sty 2023 (CET)Odpowiedz[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[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[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[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[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[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[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[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[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[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[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[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[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[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[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[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[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[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 [6]. Nux (dyskusja) 22:51, 14 sty 2023 (CET)Odpowiedz[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[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[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[odpowiedz]
  • Wrzuciłem zmiany z brudnopisu do szablonu. Uaktualniłem także dokumentację. Paweł Ziemian (dyskusja) 22:37, 14 sty 2023 (CET)Odpowiedz[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[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[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[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[odpowiedz]
      Przywróciłem zaimplementowane wcześniej kategorie techniczne. Paweł Ziemian (dyskusja) 23:30, 14 sty 2023 (CET)Odpowiedz[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[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[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[odpowiedz]
      Wstawiłem w brudnopisie. Paweł Ziemian (dyskusja) 23:48, 14 sty 2023 (CET)Odpowiedz[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[odpowiedz]
      Już dawno miałem z nazwy szablonu zrobić link. Paweł Ziemian (dyskusja) 10:56, 15 sty 2023 (CET)Odpowiedz[odpowiedz]
      @Paweł Ziemian Jak dla mnie OK :) Nux (dyskusja) 17:10, 15 sty 2023 (CET)Odpowiedz[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[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[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[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[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[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[odpowiedz]
    Mnie satysfakcjonuje takie rozwiązanie. Msz2001 (dyskusja) 20:33, 15 sty 2023 (CET)Odpowiedz[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[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[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[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[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[odpowiedz]
    Zerknę. PMG (dyskusja) 14:54, 17 sty 2023 (CET)Odpowiedz[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[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) [7]. 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[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[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[odpowiedz]
    nie, nie zniknęły, zamieniły się tylko w układ jednokolumnowy... Selso (dyskusja) 20:19, 18 sty 2023 (CET)Odpowiedz[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[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[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[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[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[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[odpowiedz]
    Przychylam się do opinii Ziemianina. Selso (dyskusja) 09:15, 19 sty 2023 (CET)Odpowiedz[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[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[odpowiedz]

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

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

Botowanie brakującej szerokościEdytuj

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

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

Układy wielokolumnowe wywołane poprzez column-countEdytuj

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

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

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

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

Pionowe szablony nawigacyjneEdytuj

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

  • Dałoby się, ale:
    • przeniosłem chyba już kilkadziesiąt podobnych szablonów, przy niektórych zmiany były cofane (również w wywołaniach), więc lepiej to do końca przedyskutować
    • czasami są dwa szablony (poziomy i pionowy) - wtedy trzeba je scalić, ale bot tego nie wymyśli
    • czasami w szablonie są nietypowe rzeczy (ilustracje, specjalne formatowania) - które trzeba raczej sprawdzić/poprawić ręcznie
    Z dwóch ostatnich powodów lepiej jest przerobić szablon ręcznie (co nie jest kłopotliwe po ujednoliceniu kodu szablonów) i botem przeniesienie ich na koniec artykułu. Tych szablonów nie jest też za wiele: Kategoria:Szablony nawigacyjne – pionowe. Znacznie gorsze są różnego rodzaju szablony pseudonawigacjne (zrobione bez {{szablon nawigacyjny}}). Ale tych tym bardziej botem się nie przerobi. ~malarz pl PISZ 12:36, 18 sty 2023 (CET)Odpowiedz[odpowiedz]
    szablony pionowe powinny zniknąć. Być moze spełniały kiedyś swoje funkcje - teraz już nie.--Kerim44 (dyskusja) 19:09, 18 sty 2023 (CET)Odpowiedz[odpowiedz]
  • Zgadzam się z „powinny zniknąć”. Tylko nie można tego zrobić hurtowo. Trzeba każdy szablon (lub ich tematyczną grupę) oddzielnie zgłosić i przedyskutować. Natomiast obecna implementacja powinna pozostać. Obawiam się, że szablony pionowe nie znikną. A gdyby nawet zniknęły, to by kiedyś chciały wrócić. Tym bardziej, że sporadycznie wciąż powstają nowe. Gdyby nie było dla nich wsparcia to powstawałyby w postaci pseudotabelek symulujących szablony nawigacyjne ([10], [11]). A takich łamigłówek nie chcemy ([12], [13]). Paweł Ziemian (dyskusja) 22:39, 19 sty 2023 (CET)Odpowiedz[odpowiedz]
  • Jak zatem to przeprowadzić? Owszem mogę w każdej chwili przerobić lub zgłosić dowolny szablon, ale jeśli go zedytuję to nie zdążę wprowadzić poprawek w masie artykułów które go wykorzystują (nie obsługuję botów). Zgłaszać poszczególne (lub grupy) szablonów tutaj a przy ewentualnej akceptacji, ktoś chętny zedytowałby i naniósł poprawki w art. botem? Sumek101 () 09:05, 20 sty 2023 (CET)Odpowiedz[odpowiedz]
    • Sprawdź czy nie mają odpowiedników poziomych (mogą być w różnych kategoriach - najlepiej sprawdzić w głównych artykułach) , popraw szablony i daj znać np. u mnie w dyskusji. ~malarz pl PISZ 09:24, 20 sty 2023 (CET)Odpowiedz[odpowiedz]
      Ok, tak też zrobię przy czym całą operację trzeba będzie przeprowadzać dosyć sprawnie, bo zedytowane szablony zanim zostaną przeniesione na spód będę rozbijać formatowanie dziesiątek artykułów. Jeżeli będę miał jakieś wątpliwości co do zasadności zmiany szablonu z pionowego na poziomy, będę zakładał dla niego osobny temat żeby sprawę przedyskutować. Sumek101 () 23:20, 20 sty 2023 (CET)Odpowiedz[odpowiedz]
  • Jest możliwe, ze powstają nowe nie dlatego, ze ktoś bardzo się przy nich upiera, a z czystej niewiedzy. Po prostu wikipedysta bierze za wzór "stary" pionowy i ...leci nowe teksty...(też tak robię z poziomymi;)--Kerim44 (dyskusja) 22:24, 20 sty 2023 (CET)Odpowiedz[odpowiedz]
    Wg mnie to nawet bardzo prawdopodobne... i też robię tak samo :) Sumek101 () 23:22, 20 sty 2023 (CET)Odpowiedz[odpowiedz]

Gadżet poczekalniowyEdytuj

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

Migracja z vector.css i vector.jsEdytuj

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

Proponuję zrobić tak:

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

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

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

Czy wiadomo ile osób ma ten problem? Można zrobić ich listę? Sidevar (dyskusja) 02:28, 22 sty 2023 (CET)Odpowiedz[odpowiedz]
Raczej niedużo. Pewnie ok. 60 aktywnych osób. Z tego też trudno powiedzieć ilu osób będzie to dotyczyć, bo nie wszyscy zmienią skórkę. Tak jak i sporo osób nadal używa Monobooka z różnych względów. Nux (dyskusja) 13:30, 22 sty 2023 (CET)Odpowiedz[odpowiedz]
Może być więcej, bo to wyszukuje tylko skrypty ze słowem loader (z jakiegoś powodu słowo loader nie pokazuje się w polu wyszukiwania).
Przykład - brak np. mojego Wikipedysta:MarMi_wiki/vector.js, zawierającego tylko //window.removeTitles=false;. MarMi wiki (dyskusja) 14:26, 22 sty 2023 (CET)Odpowiedz[odpowiedz]
@MarMi wiki Tak, to celowe. Zakładam, że jak ktoś nie ma mw.loader, to jest nieaktywny, albo ma pusty vector.js (tak jak ten twój). Ten loader jest w instrukcjach do nowych skryptów zazwyczaj. Nux (dyskusja) 15:00, 22 sty 2023 (CET)Odpowiedz[odpowiedz]
I nie zapomnijcie sprawdzić też globalnie (na meta).
Informacyjnie: Nie tak dawno (kilka dni temu) enwiki zmieniło domyślną skórkę ze starego wektora na nowy.
I tak, V'22 jest brzydki i nieporęczny :) MarMi wiki (dyskusja) 02:38, 22 sty 2023 (CET)Odpowiedz[odpowiedz]
@MarMi wiki o ile wiem z meta ładuje się tylko global.js chyba? Czy mi się źle wydaje? :) Nux (dyskusja) 13:32, 22 sty 2023 (CET)Odpowiedz[odpowiedz]
A, pomieszałem global.js z commons.js, z czego wyszło przypuszczenie, że vector.js też może być globalny. MarMi wiki (dyskusja) 14:20, 22 sty 2023 (CET)Odpowiedz[odpowiedz]
Nie, nie jest tak źle. W praktyce myślę, że dla większości osób to będzie mało roboty. Ja mam tam dużo, ale i tak muszę to uporządkować w końcu. Nawiasem mówiąc może część warto przenieść do tego globalnego jeśli skrypt jest w pełni uniwersalny. Nux (dyskusja) 15:02, 22 sty 2023 (CET)Odpowiedz[odpowiedz]

Jeszcze o datach - tym razem w treściEdytuj

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

Hiperaktywność filtru nadużyćEdytuj

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

W ogóle te opisy reguł są jakieś dziwne. Dlaczego akurat takie? A potem weź się zastanawiaj, co autor miał na myśli... XaxeLoled AmA 15:15, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
To jest chyba celowe, aby nie ujawniać algorytmu (bo go można wtedy obchodzić). IOIOI2 15:17, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
Nawet się dostało pracownikom WMP ;) [14] SkrzydlatyMuflon Pisz tutaj 16:29, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
przed sprzątaniem warto się zabezpieczyć :) Już ogarnięte na przyszłość masti <dyskusja> 18:26, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
generalnie dobrze działa. są pojedyncze false positive ale niewiele. Zresztą obserwuję aktywność tego filtru prawie cały czas. masti <dyskusja> 15:21, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
aktywuje się falami w zależności od aktywności naszego ulubionego Wandala. masti <dyskusja> 15:22, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
Ja widzę trzy false positives raz za razem, przez trzy kolejne dni. Szanowni Operatorzy filtru chyba sobie urządzają kpinki. --WTM (dyskusja) 05:20, 26 sty 2023 (CET)Odpowiedz[odpowiedz]

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

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

Szablony Cytuj i Cytuj książkę - pole wydanie i interpunkcjaEdytuj

W szablonach {{cytuj}} oraz {{cytuj książkę}} mamy pole wydanie, które zwykle wypełnia się numerem wydania książki. Problem pojawia się gdy numer wydania zawiera dodatkowo opis słowny i kończy się skrótem.

{{Cytuj |autor = Jan Nowak |tytuł = Książka |wydanie = 3 uzup |miejsce = Pcim |wydawca = Wydawnictwo Przykładowe |data = 2004}}

Jan Nowak, Książka, wyd. 3 uzup, Pcim: Wydawnictwo Przykładowe, 2004.

{{Cytuj książkę |autor = Nowak Jan |tytuł = Książka |wydanie = 3 uzup |miejsce = Pcim |wydawca = Wydawnictwo Przykładowe |data = 2004}}

Nowak Jan: Książka. Wyd. 3 uzup. Pcim: Wydawnictwo Przykładowe, 2004.

Większość takich parametrów (o ile nie wszystkie) jest bez kropki na końcu. Wstawienie kropki do parametrów poprawi wygląd szablonu "cytuj", ale zepsuje "cytuj książkę" - pojawią się dwie kropki. Najprościej (bez wyszukiwania i poprawiania każdego skrótowca) byłoby poprawić wyświetlanie szablonu "cytuj" poprzez zmianę przecinka na kropkę za wydaniem - tak jak jest w szablonie "cytuj książkę".

Przykłady: Perkusja (2 popr. i rozsz), Ulepszanie cieplne (12 zm), Sławentyn (2., popr), Czerwona Wieża w Chemnitz (3 aktualizowane i popr), Wysmalanie roślin (3 uzup), Władysława Keniżanka–Olbromska (2. popr. i uzup), Karabin automatyczny (3, popr. i uzup) Ololuki (dyskusja) 20:33, 25 sty 2023 (CET)Odpowiedz[odpowiedz]

Hm... A może w ogóle wywalić te dopiski? Zmienione, zaktualizowane, uzupełnione, poprawione... Jak tak się zastanawiam, to co za różnica? Albo pełną formę stosować, albo w ogóle. W praktyce i tak między wydaniami różnica jest taka, że numery stron są inne. I do tego wystarczy numer wydania (czy nawet sam rok wydania). Nux (dyskusja) 21:10, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
W dokumentacji {{cytuj}} jest napisane, żeby pomijać: "W przypadku książek należy podać wydanie (edition) cyfrą arabską, jeśli nie była to pierwsza publikacja książki. Pomija się inne informacje dot. wydania (np. „rozszerzone” itp.)."
Pytanie czy występują przypadki gdzie mamy dwa różne wydania o tym samym numerze i innym dopisku? Ololuki (dyskusja) 21:28, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
Hm... Widzę, że @Paweł Ziemian już częściowo zmieniał (dopisek z przodu jest już wywalony). To oryginalne "Wyd. 2 popr. i rozsz." wygląda na dopisek pobrany z BN (250$a) [15]. No i tak się zastanawiam, czy by nie wywalić tych standardowych dopisków do końca? To znaczy w opisie wydania mogłoby być takie coś: „Tekst na podst. wyd. 2 poprawiony przez autora, z uwzględnieniem rękopisu i wyd. 1” i wtedy OK, takie można zostawić. Ale liczba + wymienione dopiski do wywalenia raczej.
Zastanawiam się też, że czy nie wywalić może z citoid mapowania też? W szablonie jest mapowanie "edition": "wydanie" i to edition to pewnie wszędzie takie przegadane będzie i raczej mało użyteczne na wiki... Ale nie jestem pewien. Nux (dyskusja) 21:51, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
Jeszcze może dorzucę przykłady z OCLC. Moim zdaniem żadne z tych stwierdzeń nie będzie szczególne przydatne w identyfikacji źródła. A jakby co takie informacje o wydaniu można znaleźć w worldcat czy BN właśnie. Nux (dyskusja) 21:54, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
Takie opisy będą się powtarzać po użyciu generatora cytowania. Czy można poprawić generator albo dać stałe zadanie dla bota? Sidevar (dyskusja) 22:13, 25 sty 2023 (CET)Odpowiedz[odpowiedz]
Informacja, że wydanie jest uzupełnione, zmienione jest istotna. Jeśli jest wydanie "3 uzup.", a ktoś ma wyd. 2 to wie, że może części treści nie znaleźć w swoim wydaniu. Moim zdaniem. Joee (dyskusja) 07:03, 26 sty 2023 (CET)Odpowiedz[odpowiedz]
To jest przypis bibliograficzny, a nie katalog biblioteki. Nie zamieszczau tu wszelkich potencjalnie przydatnych (waznych dla kogoś) informacji. Istotny jest numer wydania, a nie jakieś dopiski, czy to tylko dodruk, aktualizacja, czy może faktycznie zupełnie nowe opracowanie (w dodatku w szeregu publikacji dopisków nie ma, pomimo istotnej zmiany treści między wydaniami). Przypis służy zidentyfikowaniu publikacji i miejsca zawartego w publikacji jako źródła do podanej w artykule informacji. Nie służy do dywagacji na temat samej publikacji (książki) i róznic miedzy jej wydaniami. Aotearoa dyskusja 09:07, 26 sty 2023 (CET)Odpowiedz[odpowiedz]
Jw., te wszystkie dopiski typu „rozszerzone”, „uzupełnione” są do wywalenia, one nie określają różnic między tym samym wydaniem – nie będzie dwóch wydań trzecich, z których jedno jest zwykłe, a drugie rozszerzone. Dla opisu bibliograficznego w tym miejscu ważny jest numer wydania. Ew. ważne informacje dotyczące wydania lądować powinny w parametrze opis szablonu {{cytuj}}, ale ważne z punktu widzenia poprawnego zidentyfikowania źródła. W innych językach też zdarza się sporo dopisków, ale nie zauważyłem, aby ktokolwiek w pl.wiki je kopiował/tłumaczył do opisu bibliograficznego... to taka maniera tylko w przypadku polskojezycznych źródeł. Wostr (dyskusja) 18:33, 26 sty 2023 (CET)Odpowiedz[odpowiedz]
Dla mnie dziwne stwierdzenia - bibliografia służy do weryfikowania, powinny do niej prowadzić przypisy. I teraz sięgam do wydania II i stwierdzam, że w danej pozycji nie ma tej informacji, bo nie wiem że wydanie III użyte w bibliografii jest uzupełnione/rozszerzone, bo wywalamy te "zbędne" dopiski. Przykro mi ale tego toku rozumowania ja pojąć nie mogę. Pozdrawiam Joee (dyskusja) 06:57, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
To wyobraź sobie sytuację, w której są wydania: 1, 2, 3 uzup. i 4. Przypis jest opisany 4, ty sięgasz do drugiego i ... nie ma w nim tych informacji, których szukasz. A w 4 też nie było żadnego "uzup". Ten opis "uzupełnione/zmienione/itp" to tylko zabieg marketingowy. ~malarz pl PISZ 09:02, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
Hm... OK, nie wiem jak Ty, ale jak sięgam do innego wydania, za pewne z innego roku, a może nawet innego wydawcy, to spodziewam się, że będzie inne. Czasem to od razu oczywiste, bo np, tłumacz jest inny. Z technicznych książek, to nie kojarzę, żebym kiedykolwiek widział nowe wydanie bez zmian (zawsze są jakieś korekty i uzupełnienia, bo świat się zmienia). Chyba tylko w beletrystyce są dodruki bez zmian. A i tak np. różne wydania Pratchetta w oryginalne mają zwykle różny format przez co numeracja stron jest inna. Zresztą Pratchetta i innej beletrystyki raczej nie będziemy używać w przypisach zazwyczaj ;). Biografie też jak kojarzę raczej mają uzupełnienia/erraty w kolejnych wydaniach. Tak że w praktyce z góry można przyjąć, że każde wydanie jest inne. Nux (dyskusja) 13:22, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
  • Naprawdę nie macie tu większych problemów, jak zmniejszanie szczegółowości opisów bibliograficznych? Wystarczająco idiotyczne było skasowanie możności rozdzielenia imienia od nazwiska w szablonie "Cytuj", teraz Wam zaczyna przeszkadzać, że ktoś dokładniej opisze wydanie. Nie chcecie dodawać takich informacji, nie ma obowiązku. Ale nie psujcie tym, którzy chcą robić staranniej. Prośba była o zmianę kropki na przecinek. Nie da się, nie chce się Wam, powiedzcie: nie. I z głowy. A zamiast dyskutować nad powodami dla których należy usunąć "popr." z opisu wydania dopilnujcie, żeby choć autorów w Czywieszu podawali, bo to jest realny problem --Felis domestica (dyskusja) 14:21, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
    • Brak rozdzielenia nazwisk i imion oraz automatyczne analizowanie tego parametru jest jedną z większych zalet tego szablonu. Jak dla mnie informacja zbędna a wstawiona do opisu = mniej starannie. Pozwól też, że sam będę sobie szukał zajęcia w Wikipedii, za wskazywanie, co powinienem robić, podziękuję i nie skorzystam. Wostr (dyskusja) 15:44, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
    • Bo rozdzielone nazwisko i imię tak się świetnie sprawdzało... Nic to, że wstawiano wszystko do nazwiska, albo odwrotnie niż się powinno. A dodawanie kilku autorów to był koszmar...
      Edycja: Tzn. nie mam nic przeciwko rozdzielaniu, o ile robiłby to automat, a nie sam użytkownik. MarMi wiki (dyskusja) 15:51, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
      @MarMi wiki Na niechlujstwo/głupotę nic nie poradzisz. Nie dalej jak wczoraj wyciągałem rocznik, numer i datę wydania z pola "tytuł" w opisie czasopisma... Nie jest to jednak argument, by zlikwidować pola "wolumin", "wydanie" i "data" z szablonu i zastąpić to ogólnym "tytuł, rocznik, numer i data". Dla tych co nie chcieli dzielić było pole "autor". I o to chodzi: dać możliwość i wesprzeć tych co chcą się nauczyć robić lepiej. --Felis domestica (dyskusja) 18:42, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
      Szablon „Cytuj” w miarę poprawnie wypełniony sam rozpoznaje co jest nazwiskiem, a co imieniem (ogromne ukłony dla Pawła Ziemiana!). I o to chodzi – zdjąć z edytujących żmudne wypełnianie „imię21 = ...| nazwisko21 = ...", skoro automat sam potrafi odpowiednio to zinterpretować. Michał Sobkowski dyskusja 23:51, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
      @Felis domestica dokładnie to o zmianę przecinka na kropkę. Jakby oprócz tego dodać jeszcze ignorowanie istniejącej kropki na końcu parametru wydanie (żeby uniknąć jej duplikowania) to cała zmiana obyłaby się bez botowania, a tym samym bez zmniejszania szczegółowości opisu bibliograficznego. A odnośnie dygresji na temat pola autor: Gdy mamy pola imię i nazwisko to wiadomo co jest czym, natomiast gdy wpisujemy autora w pole autor to zaczyna się zabawa, bo w szablonie cytuj mamy kolejność "Imię Nazwisko" a w cytuj książkę "Nazwisko Imię". Ololuki (dyskusja) 13:36, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
      @Ololuki, @Michał Sobkowski Ano zaczyna się zabawa. A o imionach i nazwiskach chińskich, japońskich i węgierskich to już nie mówię. Przy czym istnienie samego pola "autor" (nota bene było wcześniej, kto się nie chciał żmudzić nie musiał, żaden argument) i automatyzacja rozpoznawania mi nie przeszkadzają, wprost przeciwnie. Przeszkadza mi usunięcie opcji dla tych, którzy chcieli by ją wykorzystać. Bo dane detaliczne można skumulować i "imienia" i "nazwiska" zrobić "autor". Ale w drugą stronę już nie :( --Felis domestica (dyskusja) 14:08, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
      Zakładając, że wstawiający potrafi poprawnie rozdzielić chińskie, japońskie, węgierskie i inne nazwiska.
      Nie da się utrzymywać dwóch wersji tego samego pola, trzeba się zdecydować na jedną. No, teoretycznie się da, "tylko" trzeba by jakoś synchronizować obie wersje, żeby nie utrudniać życia tym, co wolą edytować wszystko w polu "autor" (mnie na przykład zamiana imię/nazwisko bardziej irytowała przy dwóch oddzielnych parametrach/polach, chociaż być może potrzeba na to tyle samo wysiłku co zamiana miejscami w jednym parametrze).
      Nigdy nie zrozumiem ludzi, którzy wolą pojedynczo kopiować i wklejać nazwisko po nazwisku i imię po imieniu, jak można skopiować i wstawić wszystko za jednym razem (a przeważnie można). ;) MarMi wiki (dyskusja) 15:23, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
      Nie, w Cytuj książkę jest kolejność taka, jaka była akurat wygodniejsza dla wstawiającego. Zresztą w Cytuj jest podobnie, tylko że tam łatwiej zauważyć złą kolejność (bo "imię" jest skracane).
      Cytuj książkę:
      Jan Nepomucen: test. / [imię=/nazwisko=] Jan Nepomucen: test.
      Nepomucen Jan: test.
      Cytuj:
      Jan Nepomucen, test.
      Nepomucen Jan, test. MarMi wiki (dyskusja) 14:17, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
  • Popieram botowanie pola „wydanie” i usuwanie dopisków. Tym bardziej, że citoid ładuje tam czasem bardzo dziwne teksty. Szczególnie niepożądane jest to przy cytowaniu książek obcojęzycznych, gdzie pojawiają się często kwiatki w rodzaju „wyd. 3rd edition”. Wszystko po „3” bot powinien kasować. A może byłby w stanie uwzględnić liczby rzymskie? Michał Sobkowski dyskusja 23:51, 27 sty 2023 (CET)Odpowiedz[odpowiedz]
    Mogą też, być może, wystąpić wydania w postaci słownej (first, second). MarMi wiki (dyskusja) 00:19, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    Jasne, że mogą, ale to chyba rzadkość. Problemem jest to, że citoid bierze nr wydania z OCLC, które podaje wynik w postaci typu „wydanie = 3rd edition” itp. Ręczne niestandardowe wypełnienia są chyba znacznie rzedsze. Je też należy oczywiście poprawiać, ale nie wiem, czy to zadanie dla bota. Z drugiej strony raczej nic nie zaszkodzi, jaśli bot zmieni wszystkie angielskie (niemieckie, francuskie?) słowa na liczby. Michał Sobkowski dyskusja 00:32, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    No tak, zapominam, że po wygenerowaniu cytowania wkleja się je na pałę, bez sprawdzania, i potem autorem jest "archive.org" i wszyscy się cieszą i uważają, że cacy. Sorry, kończę marudzenie, bo jeszcze napiszę o słowo za dużo i jakiegoś bana podłapię --Felis domestica (dyskusja) 14:08, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    Jestem zdecydowanie przeciwny botowaniu i usuwaniu informacji z pola wydanie, ponieważ użytkownicy potrafią różne dziwne rzeczy umieszczać w tym polu. Tutaj choćby przeglądając raport z ostatniego botowania Pawła Ziemiana Wikipedysta:Paweł Ziemian/wydanie można znaleźć:
    Wiktor Tylski - "Wyd. wydanie według oryginału z 1931" - po mechanicznym przebotowaniu dostaniemy "wyd. 1931" :)
    A ile takich rzeczy jest jeszcze nieodkrytych? (raport zawiera jedynie użycia, gdzie w polu wydanie znajdował się napis "wydanie", "wyd.", itp.)
    Jeżeli już botować to tylko z białą listą przypadków, które można bezpiecznie zmienić bez utraty informacji, tylko czy tworzenie takiej białej listy ma sens? Ololuki (dyskusja) 15:47, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
  • Poprawiłem kwestię dopisków w module Cytuj. Testy tutaj: Wikipedysta:Nux/test Cytuj wydanie. Co do interpunkcji, to moim zdaniem w {{Cytuj}} jest ona bardziej spójna. Ogólnie wszystko tam jest rozdzielone przecinkami. Jeśli coś jest skrótem, to należy dodać kropkę i tyle. Czyli „wydanie = wyd. 1 uzup.” będzie OK. Dodałem też obsługę wykrywania słowa „wydanie” oraz „wyd.”, a także „edition” wspomniane wyżej. Czyli nie trzeba botować, zajmie się tym Lua. --Nux (dyskusja) 15:21, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    @Nux zostawiając przecinek w szablonie cytuj niestety dalej botowanie jest potrzebne, żeby dodać brakujące kropki po każdym skrótowcu (patrz: Wikipedysta:Nux/test Cytuj wydanie). Alternatywnie można dodać listę skrótowców do modułu i dodawać kropkę automatycznie. Dodatkowo warto byłoby też poprawić szablon cytuj książkę, żeby ignorował istniejącą kropkę na końcu zawartości pola wydanie (żeby uniknąć wyświetlania dwóch kropek):
    Jan Nowak: Książka. Wyd. 3 uzup. Pcim: Wydawnictwo Przykładowe, 2004.
    Ololuki (dyskusja) 15:56, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    @Ololuki tylko, że co do zasady to, że ktoś nie podał kropki na końcu to jest błąd dodającego szablon. A tego drugiego szablonu, to chyba się nie podejmuję poprawić... Ale jak ktoś chce i poprawi (i przetestuje), to mogę wrzucić zmiany. Nux (dyskusja) 15:59, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    Kropki w skrótach w Cytuj|wydanie poprawiłem. Jakby ktoś jeszcze jakieś widział, to dajcie znać. Mogę poprawić. Nux (dyskusja) 20:51, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    @Nux zweryfikuj proszę dlaczego te dwa zostały pominięte (a były w moim pierwszym poście): Karabin automatyczny (3, popr. i uzup), Ulepszanie cieplne (12 zm) Ololuki (dyskusja) 21:43, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    Nie miałem „zm” na liście (i małego cytuj). Teraz się powinny załapać. Nux (dyskusja) 22:29, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
    @Nux dodałem ignorowanie ostatniej kropki w polu wydanie. Jeżeli na końcu zawartości pola wydanie znajduje się kropka, to jest ona zamieniana na pusty string. Ololuki (dyskusja) 15:10, 29 sty 2023 (CET)Odpowiedz[odpowiedz]
    Wstawiłem zmiany w Cytuj książkę. testy Cytuj książkę wyglądają OK. Wygląda na   Załatwione Nux (dyskusja) 21:02, 29 sty 2023 (CET)Odpowiedz[odpowiedz]

PrzypisyEdytuj

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

Przypisy dzielą się na kolumny automatycznie, w zależności od ilości wolnego miejsca. Na przykład u mnie w skórce Wektor 2022 jest jedna kolumna przypisów, a w starym Wektorze są dwie (ale to kwestia akurat takiej a nie innej szerokości miejsca na treść, nie stricte skórki). Msz2001 (dyskusja) 17:35, 26 sty 2023 (CET)Odpowiedz[odpowiedz]
Dziękuję za wyjaśnienia, bo nie nadążam za tymi wszystkimi zmianami technicznymi. Pomponick (dyskusja) 20:15, 26 sty 2023 (CET)Odpowiedz[odpowiedz]

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

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

Kontrola autorytatywna i PAN.plEdytuj

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

MalarzBOT i Encyklopedia BritannicaEdytuj

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

Edycja ObserwowanychEdytuj

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

@Wostr, możesz spróbować przez API. Najpierw utwórz podstronę, np. Wikipedysta:Wostr/test, i umieść tam linki do stron, które chcesz usunąć z obserwowanych (obojętnie, w jakiej postaci, byle były podlinkowane). Potem wejdź tutaj i wykonaj zapytanie. Na wypadek gdyby ten link nie prowadził do już wypełnionego formularza: action=watch, zaznaczone "unwatch", titles=Wikipedysta:Wostr/test (bądź inna strona), generator=links, gpllimit=max. Peter Bowman (dyskusja) 19:32, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
mw:API:Watchlist_feed/pl, w Zobacz też jest link do edycji (API:Watch). Po angielsku. MarMi wiki (dyskusja) 19:36, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
Kolejną opcją jest usuwanie obserwowanych na liście. Pokazuj linki ×/+ przy zmienionych obserwowanych stronach (wymagany JavaScript do funkcji przełączania) w Specjalna:Preferencje#mw-prefsection-watchlist. Potem w obserwowanych × będzie usuwał stronę. To tak bardziej stopniowo pozwala oczyścić, ale zawsze coś. Nux (dyskusja) 20:55, 28 sty 2023 (CET)Odpowiedz[odpowiedz]
A propo, to można też użyć skryptu Convenient Discussions, będzie można anulować subskrypcję tematów/sekcji na stronach dyskusji. MarMi wiki (dyskusja) 22:33, 28 sty 2023 (CET)Odpowiedz[odpowiedz]

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

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

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

Wiadomości techniczne: 2023-05Edytuj

MediaWiki message delivery 01:04, 31 sty 2023 (CET)Odpowiedz[odpowiedz]

  Załatwione ~CybularnyNapisz coś ✉ 02:00, 31 sty 2023 (CET)Odpowiedz[odpowiedz]

błędy lintera 31 stycznia 2023Edytuj

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

Zazwyczaj słowa wpisywane w szablony językowe wychodzą w kursywie. tutaj jednak kursywy nie ma. Czy mogę w jakiś sposób zrobić kursywę?

Zwiadowca21 21:05, 31 sty 2023 (CET)Odpowiedz[odpowiedz]

Przepraszam, wystarczy dodać '' Zwiadowca21 21:16, 31 sty 2023 (CET)Odpowiedz[odpowiedz]

  Załatwione Archiwald (dyskusja) 21:17, 31 sty 2023 (CET)Odpowiedz[odpowiedz]
  • Te szablony służą do wpisywania tekstów w zadeklarowanym języku. Kursywą są pisane tylko treści używające alfabetu łacińskiego, żeby je odróżnić od tekstu polskiego. Inne alfabety wyraźnie odstają od reszty, stąd nie wymagają pochylania. Jeśli mimo to potrzebujesz kursywy, musisz poszukać inne rozwiązanie. Nawiasem mówiąc wpisanie słowa „Wikipedia” z zadeklarowanym językiem greckim uważam za błąd. Paweł Ziemian (dyskusja) 21:24, 31 sty 2023 (CET)Odpowiedz[odpowiedz]

Absolwenci gimnazjów na wschodzieEdytuj

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[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[odpowiedz]
OK, sorry. Przeniosę.--Zorro2212 (dyskusja) 10:20, 1 lut 2023 (CET)Odpowiedz[odpowiedz]

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

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

Szablon SortkeyEdytuj

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

Jeszcze raz dzięki - można na was (Nuksa też :-)) liczyć, Z uszanowaniem, Ency (replika?) 00:08, 4 lut 2023 (CET)Odpowiedz[odpowiedz]

Rożnice wizualne: problem z porównywaniem tabelEdytuj

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

Automatyczne blokowanieEdytuj

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[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[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[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[odpowiedz]
    Raczej czy koszt odwracania skutków jest mniejszy/większy niż zrobienie zabezpieczenia. MarMi wiki (dyskusja) 13:25, 6 lut 2023 (CET)Odpowiedz[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[odpowiedz]

Zmiana linkowaniaEdytuj

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

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

Podgląd po zmianach w wersji mobilnejEdytuj

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

Bot-uparciuch (kontrola autorytatywna)Edytuj

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

Wiadomości techniczne: 2023-06Edytuj

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

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

Statystyki wyszukiwania nieistniejących hasełEdytuj

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[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ą oczywiście tendencyjne – różne kręgi językowe (kulturowe) mają różne skrzywienie informacyjno/tematyczne. Kenraiz (dyskusja) 08:47, 7 lut 2023 (CET)Odpowiedz[odpowiedz]