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.
[1] - czy takie działanie bota jest pożądane? Czy bot w ogóle weryfikuje zgodność treści? Strona mogła się zmienić, a przecież tamto archiwum też działało, więc o co chodzi? Niech ktoś to kuriozalne ustrojstwo przyblokuje, zanim narobi większych szkód. Chociaż zdaje się, że robi też poprawne i potrzebne edycje, więc nie wiem, jak najlepiej do tego podejść. 83.23.186.148 (dyskusja) 10:54, 21 maj 2021 (CEST)[odpowiedz]
A można gdzieś zasugerować, aby to dziwne zachowanie zostało całkowicie usunięte? Po co zamieniać prawidłowe linki do archiwum (często idealnie dopasowane, ręcznie dodane) na takie, które prawie zawsze będą trochę starsze, trochę nowsze itp. (zresztą archive.today potrafi archiwizować treści, z którymi web.archive.org sobie nie radzi). Czy to nie absurd? Jak dla mnie wszystkie tego typu edycje nadają się do wycofania, bo nigdy nie wiemy, co jest pod danym linkiem (a można założyć, że wcześniej jednak było dobrze). Tak z innej beczki, to o wiele ciekawszą rzeczą byłoby np. automatyczne archiwizowanie linków z nowo dodawanych przypisów (czy na enwiki nie ma czegoś takiego?). 83.23.140.110 (dyskusja) 21:55, 10 lip 2021 (CEST)[odpowiedz]
Jeśli znasz angielski, to możesz spróbować to zasugerować na stronie dyskusji bota (wejdź na któryś z podanych diffów i wejdź na stronę użytkownika bota).
Trwa praca(?) nad tym na Phabricatorze, ale sądząc po czasie reakcji to może "trochę" potrwać. W zgłoszeniu podałem możliwość użycia długich linków z archive.is, zamiast ich zamiany na web.archive. MarMi wiki (dyskusja) 01:05, 13 lip 2021 (CEST)[odpowiedz]
Szablony nawigacyjne
Coś się wczoraj stało z szablonami nawigacyjnymi – ich treść została pomniejszona (to chyba ma związek z włączonymi gadżetami Pomniejszaj sekcję Bibliografia/Linki zewnętrzne/Przypisy) i nie są domyślnie rozwinięte, mimo że w ich kodzie znajduje się zwijanie = rozwinięte. Openbk (dyskusja) 14:58, 7 cze 2021 (CEST)[odpowiedz]
Ja wczoraj przełączyłem ich generowane na nową implementację w Lua. To już nie jest <table class="navbox ... lecz <div class="navbox .... Myślę, że kwestię rozmiaru można jeszcze dopracować w CSS. Obecnie ustawiony to
Coś jest jednak nie do końca, jak być powinno. Obok siebie dwa szablony nawigacyjne jak w adrenalina, jeden zwykły, drugi przez {{grupa szablonów}} — efekt jest taki, że czcionka innej wielkości (inaczej pomniejszone nagłówki, inaczej tekst właściwy), inne ustawienie przycisków do rozwijania (jeden pomniejszony, drugi nie pomniejszony, trzeci pomniejszony, ale inaczej wyrównany). Wostr (dyskusja) 19:29, 7 cze 2021 (CEST)[odpowiedz]
Trzy kwestie: (1) czy istnieje jakaś możliwość, aby szablony nawigacyjne wyłączyć spod działania gadżetu zmniejszającego czcionkę sekcji końcowych (gadżet mam włączony, czcionka w szablonie ma ok. 9,92 px, a nie powinna być nigdy mniejsza niż 11 px); (2) kosmetyczne: czy przyciski zwijania, rozwijania mogłyby mieć leciutko większy margines od prawej? Dodanie margin-right:5px raczej zbyt dużo miejsca nie zje, a wydaje mi się wizualnie lepiej; (3) nie związane z samym przełączeniem: da się ustandaryzować {{grupa szablonów}} i navboksy? Pierwszy ma „Rozwiń” i „Zwiń” (duże litery), drugie mają „pokaż” i „ukryj” (małe litery) + nie wiem, czy różny tekst przycisków jest zamierzony? Wostr (dyskusja) 23:24, 7 cze 2021 (CEST)[odpowiedz]
@Paweł Ziemian być może powiązane – zmieniło się zachowanie szablonów w przypadku, gdy jest ich w haśle kilka. Do tej pory w takiej sytuacji wszystkie były domyślnie zwinięte. Teraz jednak na przykład Stefan Kraft ma pierwszy szablon rozwinięty, a pozostałe zwinięte, Piotr Żyła dwa pierwsze rozwinięte, a resztę zwiniętą, ale już Kamil Stoch wszystkie ma zwinięte. Domyślam się, że po napotkaniu pierwszego zwijanie = zwinięte zwijane są też wszystkie szablony poniżej. Takie rozwiązanie jak u Krafta lub Żyły wygląda raczej nie najlepiej. Barcival (dyskusja) 16:15, 9 cze 2021 (CEST)[odpowiedz]
Domyślnie rozwinięte są wszystkie szablony z wyjątkiem tych z polem zwijanie = zwinięte. Potem do pracy wkracza skrypt, który zwija wszystko co zostało oprócz pierwszych dwóch. Osobiście wolałbym aby nie było pola zwijanie, a domyślnie wszystko byłoby zwinięte. Nie widzę powodu aby ten zbiór linków z serii zobacz też tak eksponować. Ale to tylko moja opinia. Ewentualnie można przerobić ten skrypt na gadżet z konfiguracją, aby każdy mógł sobie sam określić ile szablonów chce sobie rozwijać. Paweł Ziemian (dyskusja) 18:11, 9 cze 2021 (CEST)[odpowiedz]
Właśnie o tym mówię – przed zmianami, jeśli na końcu hasła były więcej niż 1/2 szablony, to domyślnie wszystkie były zwijane, łącznie z dwoma pierwszymi. Teraz to zachowanie się zmieniło. Inna sprawa, że dalej nie do końca rozumiem, jak obecny skrypt powinien działać: czy oprócz pierwszych dwóch oznacza pierwsze dwa szablony bez linii zwijanie = zwinięte, czy pierwsze dwa w ogóle? Jeśli to pierwsze, to źle działa w haśle Kamil Stoch (bo Szablon:Mistrzowie świata w skokach narciarskich nie ma tej linii), a jeśli drugie, to źle działa w Klemens Murańka (bo rozwinięte są drugi i trzeci w kolejności szablon). Barcival (dyskusja) 12:48, 10 cze 2021 (CEST)[odpowiedz]
Podpiąłem się pod API, jednak nie wiem w jakiej kolejności prezentuje ono w moim skrypcie znalezione szablony nawigacyjne. Zajrzę do tego kodu jeszcze raz. Może u nas wcześniej działał jeszcze jakiś inny skrypt zwijający. Najwyżej przerobię kod tak, że zwinę wszystko w zależności od liczby szablonów. Paweł Ziemian (dyskusja) 20:12, 10 cze 2021 (CEST)[odpowiedz]
Przełączyłem się na tę skórkę i nie rozumiem co się dzieje. Chyba skrypty skórki mają jakieś błędy w kodzie zwijania/rozwijania. Nie rozpoznają mw-collapsible-content, tylko praktycznie zwijają cały szablon nawigacyjny oparty o tabelę. Te oparte o divy działają lepiej. Paweł Ziemian (dyskusja) 20:12, 10 cze 2021 (CEST)[odpowiedz]
Ja w temacie, dlaczego posypały się szablony nawigacyjne na mojej stronie użytkownika Wikipedysta:Four.mg? Wyświetlają się teraz: Informacje diagnostyczne, Kanoniczne zestawienie parametrów i Kategorie. Czy były tam wcześniej jakieś błędy? Four.mg (dyskusja) 20:58, 15 cze 2021 (CEST)[odpowiedz]
@Four.mg Nic się nie wysypało. Jakoś nieco ponad tydzień temu przełączyłem je na nową implementację. Teraz każdy szablon nawigacyjny na swojej stronie źródłowej, czyli tej którą zadeklarował w polu nazwa robi wiele różnych analiz sprawdzających co znajduje się w pozostałych parametrach. Część z tych wyników umieszcza w postaci znaczników w treści docelowego szablonu, a wiele nowych dodaje pod szablonem w zwiniętej postaci. Jeśli nie jesteś zainteresowany tymi danymi to usuń z szablou pole nazwa. To skutecznie wyłączy wszelkie analizy i zaprezentuje wyniki w taki sam sposób jak w artykułach. Paweł Ziemian (dyskusja) 22:51, 15 cze 2021 (CEST)[odpowiedz]
Rozmiar czcionki w szablonach nawigacyjnych
Dostałem kolejne zgłoszenie, że czcionka jest za mała. Tym razem w skórce „Książka”. Zrobiłem więc takie zestawienie:
Skórka
Rozmiar bazowy
Rozmiar w szablonie
Vector
14px
11.6667px
Minerva
16px
13.3333px
Modern
13px
10.8333px
Monobook
12.7px
10.5833px
Timeless
15.2px
12.6667px
Jak widać w skórce nowoczesnej i książce szablon już na samym początku jest wyposażony w dość małą czcionkę. Stąd po kolejnym zmniejszeniu jego treść staje się mało widoczna. Jednym z rozwiązań jest ustalenie na sztywno w stylach stałego rozmiaru bazowego. Jednak to może zepsuć ogólny wygląd w skórkach, które startują z wyższego pułapu. Może wystarczy ustawić .navbox{font-size:14px;} w MediaWiki:modern.css i MediaWiki:monobook.css. Paweł Ziemian (dyskusja) 11:45, 13 cze 2021 (CEST)[odpowiedz]
Przy próbie tworzenia nowego szablonu wyskakuje błąd: Błąd Lua w module „Moduł:Navbox/diag”, w linii 278: bad argument #1 to 'gsub' (string expected, got nil) i nie można go utworzyć. Makary (dyskusja) 10:02, 18 lip 2021 (CEST)[odpowiedz]
Faktycznie rzuca takim błędem na podglądzie w nowym edytorze kodu (2017, włączona opcja eksperymentalna Nowy tryb wikitekstu). Na starym tego nie robi, widocznie nowy używa innego procesu podglądu. Przy okazji, to kontrola zmian edytora 2017 dziwnie działa z tym szablonem - przy nieistniejącej stronie pokazuje cały kod szablonu (bez podziału na kolumny z +), a po przełączeniu na pokazywanie zmian w trybie wizualnym, renderuje całą rozwiniętą stronę szablonu (jakby zamiast zmian był to podgląd) - ale to może wina innej (eksperymentalnej) opcji którą akurat mam włączoną. MarMi wiki (dyskusja) 23:54, 18 lip 2021 (CEST)[odpowiedz]
Naniosłem drobne zmiany. Mam nadzieję, że wystarczą. Jednak cudów nie będzie. To bardzo dziwny edytor ten eksperymentalny, który nie widzi normalnie pełnego kontekstu tworzonej strony. Moim zdaniem do edycji szablonów się kompletnie nie nadaje. Zwłaszcza tych, które zaglądają do kodu źródłowego strony. A kilka takich szablonów i modułów już napisałem. Jednak wolę staroświecki edytor lub zewnętrzny notepad++. Paweł Ziemian (dyskusja) 18:56, 19 lip 2021 (CEST)[odpowiedz]
Bot, który usuwa podkreślenia
Rzekomo znaczniki <u> i </u> są przestarzałe (wg kogo?) i The Polish Bot je usuwa; podkreślony tekst pozostaje po nim niepodkreślony(!). Tymczasem edytor wizualny podkreśla tekst tymże właśnie sposobem. Pomoc:Formatowanie tekstu również podpowiada „przestarzały” sposób. Co robić, jak żyć? Ambiroz (dyskusja) 13:45, 18 cze 2021 (CEST)[odpowiedz]
Coś takiego, bez względu na to, jakim sposobem (pogrubieniem, podkreśleniem, kursywą) będzie zrealizowane, jest niedopuszczalne. Wskazanie odpowiedzi powinno być bezpośrednie, a więc zawarte w tekście, nie zrealizowane za pomocą formatowania. Formatowanie jedynie pomaga w przekazie treści, nie może go zastępować. Odnośnie wzorów chemicznych: jest to wyłącznie próba zrobienia czegoś, co nie jest normalnie możliwe w tekście, nie na każdym urządzeniu będzie to dobrze wyglądać. Generalnie jest tak, że jeśli równanie chemiczne da się zapisać tekstem, to takiego formatowania nie trzeba używać; jeżeli czegoś nie da się zapisać bez tego rodzaju zabiegów, to potrzebna jest grafika. Wostr (dyskusja) 14:41, 18 cze 2021 (CEST)[odpowiedz]
Tak jak napisali przedmówcy. Znacznik <u> wraz z kilkoma innymi znacznikami został uznany jako przestarzały w HTML 4; co prawda, HTML 5 ponownie go uznaje ale ze znaczeniem tekstu niemającego adnotacji tekstowej. Można więc podkreślić to co nie jest tekstem, symbol itd. Ponadto u nas nie powinniśmy używać podkreślenia, które myli się z linkami. Znacznik <s> też jest przestarzały (powinno się używać text-decoration: line-through;) a jest wstawiany przez VE. The Polish(query)15:07, 18 cze 2021 (CEST)[odpowiedz]
@The Polish - nadgorliwość jest gorsza od faszyzmu. Ten znacznik jest przestarzały, ale jako styl. Nawet na samej stronie W3C czy MDN jednym z dozwolonych przypadków użycia są błędy w pisowni. Tak więc można spokojnie zinterpretować na pokazanie ogólnie jakichś błędów. Zresztą, ogólnie, takie autystyczne podejście, że usuwam jakieś elementy, bo tak jest po prostu głupie. Jeśli chcesz, to sprawdzaj samodzielnie, czy ma sens poprawa i zrób to, a nie na siłę robisz to botem, bo tobie się coś wydaje. KABEXXXIOR ≡ DYSKUSJA13:56, 1 sie 2021 (CEST)[odpowiedz]
Cześć, kiedyś już pisałem w tej sprawie, ale tym razem ówczesna wskazówka nie pomogła. Chodzi o sytuację, w której infobox po powiązaniu artukułu z elementem Wikidanych samoczynnie pobiera część danych w przypadku pozostawienia rubryki pustej. Problem pojawia się, kiedy w artykule są np. dwa szablony: dotyczące budynku i obiektu wpisanego na listę UNESCO. Albo biografia i żołnierz itp. Wówczas wpisanie tych samych danych do dwóch szablonów jest niecelowe. Zasadniczo wiem, że można próbować wypełniać odpowiednie pola jako "nie" (np. przy grafice), "brak", "blank", "pusta" (np. przy mapie lokalizacyjnej), "bez wartości" (w przypadku wywołania {{państwo}}), natomiast np. w {{Żołnierz infobox}} w artykule Witold Kieżun nie daje to oczekiwanego efektu. Pomijam już to, jakiego magicznego słowa tym razem powinienem użyć, ale czy istnieje możliwość ujednolicenia takiej funkcji? Zdaję sobie sprawę, że to nie jest element zapisany w kodzie samego szablonu, tylko gdzieś znacznie głębiej, ale jako że nie mam pojęcia, gdzie i czy to w ogóle wykonalne, piszę w tym miejscu. Aʀvєꝺuι+ 08:15, 21 cze 2021 (CEST) [E] Jeśli to dyskusja wyłącznie o infoboksach, to proszę o przeniesienie wątku. Nie umiałem ocenić z technicznego punktu widzenia. Aʀvєꝺuι+12:44, 21 cze 2021 (CEST)[odpowiedz]
Tak przy okazji: czy można zablokować pobieranie miejsca urodzenia w infoboksach? W jaki sposób należy wypełnić ten parametr? Zresztą czy nie przyjęło się czasami, że miejsce urodzenia podajemy również w leadzie? Szablon niestety sobie z tym nie radzi, zapewne ze względów technicznych. Z tego względu pomysł zasysania tej informacji wydaje się nietrafiony, bo tworzy pewną formę niekonsekwencji między hasłami. Nie wiem też, czy Wikidanym można ufać akurat w tym przypadku. Gdy zwykły użytkownik wstawia miejsce urodzenia bez wskazania źródła, to taka edycja jest raczej wycofywana. 2A00:F41:4893:2C75:F0CA:A24C:57F5:84B0 (dyskusja) 13:03, 21 cze 2021 (CEST)[odpowiedz]
No dobrze, a czy poza tym, że dwa infoboksy są niezalecane jakieś wskazówki, co do mojego pytania ktoś by miał? :) Co do jednolitego hasła blokującego pobieranie danych albo co do pełnej listy tych magicznych słów funkcyjnych? Aʀvєꝺuι+14:11, 22 cze 2021 (CEST)[odpowiedz]
Pamiętam analogiczną sytuację z ilustracjami automatycznie zasysanymi z Commons (oczywiście nierzadko błędnych). Wówczas parametr ilustracja wypełniało się słowem nie. Nie wiem czy tutaj też zadziała. ptjackyll (zostaw wiadomość) 21:07, 22 cze 2021 (CEST)[odpowiedz]
Tak jak pisałem, sprawdzałem „nie”, „brak”, „blank”, „pusta” i „bez wartości”, które niekiedy działają w różnych wariantach. Cały szkopuł w tym, od czego to zależy? I czy poza naszym zasięgiem jest ustanowienie uniwersalnej „blokady” np. hasłem „bez wartości”? Bo rozumiem, że np. „brak” albo „nie” mogą w jakiejś konfiguracji być prawidłowym argumentem w danej rubryce i przez to nie są wystarczająco uniwersalne. Widzę, że na podanym przez Pawła Ziemiana przykładzie to była kwestia indywidualnego wpisu warunku w wywołaniu szablonu. Aʀvєꝺuι+11:39, 23 cze 2021 (CEST)[odpowiedz]
Być może nie trzeba było by tego robić, gdyby w dokumentacji {{Infobox_grafika}} uwzględniono np. taką zmianę, nie mówiąc już o udokumentowaniu "nie".
Po pierwsze: nie bardzo rozumiem, co wniosła podawana przez ciebie zmiana. W sumie dlatego piszę w kawiarence, a nie załatwiam tego sam. Po drugie: moje pytanie jest znacznie szersze niż sama grafika – czasem to mapa lokalizacyjna, którą trzeba wstrzymać, żeby się nie wyświetlała dwukrotnie, czasem to data urodzenia i zgonu w dwóch kolejnych infoboksach, czasem to jest zbędny kod kraju itp. I dla każdej z tych rzeczy możliwość zablokowania występuje – jeśli dobrze rozumiem – o ile ktoś przewidział taką opcję i wpisał odpowiednie hasło do kodu szablonu. Aʀvєꝺuι+16:18, 26 cze 2021 (CEST)[odpowiedz]
Zmiana wniosła to (tak na oko), że podając dla param. cecha pustą wartość, można było pominąć ładowanie grafiki z WD.
Co do drugiego: jeśli w dokumentacji do podszablonów nie poda się sposobu na pomijanie WD, to nic dziwnego że twórcy infoboksów mogą o tym nie wiedzieć i robić to według własnego uznania. MarMi wiki (dyskusja) 16:41, 26 cze 2021 (CEST)[odpowiedz]
Mapy lokalizacyjne, przy których też majstrowałem, nigdy nie są ładowane z Wikidanych. Jedyny wyjątek to mapki, które są grafiką, i je można wyłączać przez nie, chyba że nie są zaimplementowane przez {{infobox grafika}}. Problem drugi znacznie łatwiej rozwiązać. Wystarczy zostawić na stronie tylko pierwszy infobox. Zaraz mogę dodać odpowiedni kod w MediaWiki:Common.css, aby każdy kolejny infobox zniknął. Albo zrobię z tego domyślnie włączony gadżet. Paweł Ziemian (dyskusja) 16:52, 26 cze 2021 (CEST)[odpowiedz]
Mapa lokalizacyjna to był przykład częściowo w oderwaniu do WD. Natomiast zasadniczo chodzi mi o uniwersalne blokowanie działania danej rubryki. Pamiętam casus artykułu Pałac Güell, w którym są infoboksy dotyczące budynku i drugi dotyczący obiektu wpisanego na listę UNESCO. Wpisanie koordynatów tylko do jednego z nich powodowało, że w drugim zamiast braku koordynatów uzupełniały się automatycznie z WD właśnie. A w konsekwencji pojawiały się dwie mapy lokalizacyjne. Jedna zamierzona i druga jako efekt uboczny. Tam wpisanie nie jako kodu mapy akurat wystarczało. No tylko tyle, że akurat tam tak, a gdzie indziej to jest zawsze inne słowo. Aʀvєꝺuι+21:35, 5 lip 2021 (CEST)[odpowiedz]
Nie ma kodu mapy nie. Jest kilka specjalnych nazw map, są one opisane na stronie projektu Wikiprojekt:Szablony lokalizacyjne#Mapy specjalne. Odpowiednikiem wyłączającym mapę jest pusta. Robienie jakiegoś uniwersalnego mechanizmu wyłączającego odczyt cech WD stoi w sprzeczności z ideą Wikidanych. Jeśli mogę coś doradzić to dyskusję, czy faktycznie chcemy ściągać daną cechę do konkretnego infoboksu. Jednak to nie rozwiąże problemu. Chociaż generalnie u nas nie ma jakiegoś szturmu na ściąganie danych z WD. Ich użycie w naszych infoboksach ciągle raczkuje. Paweł Ziemian (dyskusja) 22:11, 5 lip 2021 (CEST)[odpowiedz]
Zauważyłem w ostatnim czasie, że w biogramach hokeistów zniknęło w sekcji Bibliografia linkowanie do profili zawodników w portalu EliteProspects. Dotąd działało to na zasadzie numeracji pobieranej z adresu URL. Czy da się to naprawić? Dla przykładu nie działał w: Joseph Harcharik. Lowdown (dyskusja) 07:30, 30 cze 2021 (CEST)[odpowiedz]
Dzięki. I teraz pytanie co zrobić w przypadkach tysięcy haseł hokeistów posiadających ten brak? Czy można to uzupełnić np. botem czy w inny sposób za jednym zamachem? Lowdown (dyskusja) 14:29, 30 cze 2021 (CEST)[odpowiedz]
Sądząc po rozbudowanym switchu w szablonie, to może nie być takie proste, chyba że da się jakoś rozróżnić kto jest kim (albo inne przypadki nie występują).
A propo switcha: czy Szablon:Elitepro nie ma przypadkiem błędu? Pierwszy switch reaguje na pstlnad, a drugi na psclnad
@MarMi wiki Z Eurohockey jest inna sytuacja, ponieważ pierwotnie szablon dotyczył portalu www.eurohockey.net który zniknął, zaś obecnie istnieje www.eurohockey.com. Natomiast EliteProspects jest wg mnie najbardziej wartościowy merytorycznie, więc warto byłoby aby linkowania działały poprawnie. Lowdown (dyskusja) 13:06, 4 lip 2021 (CEST)[odpowiedz]
Mieszane łączenia w tabeli
Potrzebuję uzyskać efekt mieszanego łączenia komórek w tabeli, przykład wskazujący na problem znajduje się poniżej.
Po utworzeniu odpowiedniej liczby wierszy zabieram się do potrzebnego mi łączenia komórek, a w edytorze wizualnym zadanie takie wydaje się banalną zabawą na siatce i rzeczywiście można uzyskać pożądany efekt, ale tylko mając dodatkową kolumnę bez połączeń; bez takiej kolumny scalenia mieszają się ze sobą i pojawia się wprowadzająca w błąd tabela (bo przecież w marcu mamy i kalendarzową zimę, i kalendarzową wiosnę, a to, co się wyświetla sugeruje, że tylko wiosnę). Kiedyś udało mi się metodą prób i błędów dojść do ładu, ale później sprawa się rypła (być może ktoś w międzyczasie edytował tabelę)… Jest na to jakaś metoda, jakiś kod, a może da się pozostawić nadmiarową kolumnę, ale zrobić z niej kolumnę-widmo (niewidoczną dla czytelnika)?
Sprawdziłem na maku: Firefox - jak zwykle rysuje tabele najlepiej: najdokładniej i najładniej. Nigdy z FF nie było problemu w tabelach. Natomiast Chrome, Safari i Opera - do bani. Beno (dyskusja) 12:54, 3 lip 2021 (CEST)[odpowiedz]
Oto moja próba. Starałem się miesiące przełomów pokazać w proporcji 2/3 do 1/3, ale znów... tylko Firefox robi ładnie, a pozostałe przeglądarki 1/2 do 1/2. Efekt poniżej:
Chyba mi się udało. Obie kolumny to tak naprawdę tabele zagnieżdżone. Musiałem wprowadzić szereg zabezpieczeń dla zachowania kompatybilności z różnymi przeglądarkami. Podstawowy problem kompatybilności to różne interpretowanie grubości ramki - albo ramki się stykają, albo nakładają na siebie i mają różne grubości linii, więc zrobiłem puste komórki z krawędziami w kolorze "Transparent", bo tylko wtedy ramka zostaje zachowana ze swoją grubością, choć oczywiście jest koloru przezroczystego. Mamy 12 miesięcy, a więc 11 styków komórek, podczas gdy w porach roku mamy 5 pór (2 zimy), a więc 4 styki komórek. 11 styków vs. 4 styki - to jest różnica 11-4=7 jednostek grubości, bo ramki nie dodają się do wysokości komórki, stąd musiałem zrobić puste komórki dla zachowania grubości ramki. Ale obie zimy nie mogą mieć towarzyszących im pustych komórek, bo by się nie centrowały, stąd 51 zamiast 50 i 41 zamiast 40 (domyślnie piksele) dla zrównoważenia bilansu wysokości. Ja wiem, że to bełkot, ale tak wygląda ta technika programistyczna o nazwie "rzeźba okrutna". Prościej się nie dało. Efekt poniżej. Proszę sprawdzić na maku i piecu oraz w pozostałych przeglądarkach. U mnie jest identycznie z dokładnością powiedzmy do 2/3 piksela.
Przede wszystkim warto sprawdzić, czy miesiące przełomu dzielą się na 2/3 do 1/3 (znaczy 2:1). Ja wiem, że to powinno być bardziej 21:10, ale już nie róbmy laboratorium.
Już tak na chłodno policzę: 22 marca = 22/31, 21 czerwca = 21/30, 22 września = 22/30, 23 grudnia = 23/30. (0,71 + 0,7 + 0,73 + 0,77) / 4 = 2,91 / 4 = 0,73. # miesiące przełomu mają 30 dni, 1 ma 31, średnio wychodzi 30,25. 0,7275 x 30,25 / 100 = 22. Znakiem tego proporcje wysokości miesięcy przełomu wyszły 22:8 (wszystko oczywiście w przybliżeniach), czyli tak bliżej 3:1, a nie tak, jak wcześnie napisałem i zastosowałem w tabeli, gdzie zrobiłem 2:1. Do NASA by mnie nie przyjęli, ale myślę, że Bajkonur w zasięgu. Poza tym umówmy się, że różnicę 1/3 widać w tej tabeli, a 1/4 byłaby już słabo widoczna. Beno (dyskusja) 18:54, 3 lip 2021 (CEST)[odpowiedz]
Po pierwsze: na jakiej stronie to ma być umieszczone? Jeżeli w przestrzeni głównej, to nie tędy droga. Po drugie: co ta tabela ma przekazywać? Jaka jest jej treść? Czy ona zawiera dane tabelaryczne? Po trzecie: jeżeli to ma coś pokazywać (podział), a nie przedstawiać dane tabelaryczne, to tabeli do tego stosować nie wolno, tylko robi się to na div-ach. Wostr (dyskusja) 00:35, 4 lip 2021 (CEST)[odpowiedz]
Pory roku i miesiące to tylko przykład, na podstawie którego łatwiej zrozumieć, o co mi chodzi (a mam skłonności do komplikowania tłumaczenia). Przede wszystkim chodzi o tabelę w Jednym z dziesięciu i paru podobnych hasłach. Wszystkie takie spisy tworzy się, co w moim odczuciu oczywiste, w formie tabel – i w polskojęzycznej, i w anglojęzycznej i chyba w dowolnojęzycznej Wikipedii. Ambiroz (dyskusja) 11:25, 4 lip 2021 (CEST)[odpowiedz]
A to ciekawe. W tabeli w Jednym z dziesięciu poprawne wyświetlanie między wierszami jest nie tylko w Firefoxie, ale także... w Operze. A kod tabeli jest prosty, bez udziwnień. Natomiast Safari i Chrome wyrównują do krawędzi w sąsiednich wierszach. Beno (dyskusja) 12:05, 4 lip 2021 (CEST)[odpowiedz]
Ależ ta tabela jest na pewno całkowicie niezrozumiała dla osób używających czytników ekranowych. Szczerze mówiąc, ja widzę i też nie rozumiem sensu pierwszej kolumny. Gżdacz (dyskusja) 12:32, 4 lip 2021 (CEST)[odpowiedz]
Bez pierwszej kolumny druga nie ma sensu - liczba osób potrafiących wymienić wszystkie miesiące jest prawdopodobnie większa niż liczba osób potrafiących przyporządkować miesiąc danej porze roku (albo tak mi się tylko wydaje). MarMi wiki (dyskusja) 15:13, 4 lip 2021 (CEST)[odpowiedz]
Kolumna Sezon? Faktycznie nie za bardzo ma sens, z braku wyjaśnienia co to za podział na "sezony". Dlaczego np. jesień 2011 zaczyna się... w połowie kwietnia? MarMi wiki (dyskusja) 17:25, 4 lip 2021 (CEST)[odpowiedz]
W tym właśnie sęk – jedna przeglądarka (u mnie Chrome na Windowsie) pokazuje, że jesień zaczyna się w kwietniu, druga zaś (sprawdziłem na Samsung Internet Browser na Androidzie) wyświetla scalenia odpowiednio – w tym przypadku wskazanie na to, że część edycji 66. przypadała na sezon 2010/2011, a część na jesień 2011 (gdyż była przerwa wakacyjna). Co zabawne, gdybym nie był zgłaszającym i przeczytał swój pierwszy tutaj wpis w przeglądarce Samsungowej, w ogóle nie widziałbym, o co chodzi zgłaszającemu. Ambiroz (dyskusja) 20:30, 4 lip 2021 (CEST)[odpowiedz]
To nie jest zabawne, mamy najwyraźniej w main artykuły, które robią czytelnikom takie "dowcipy". Trzeba to jak najszybciej uprzątnąć, bo wstyd to ludziom pokazywać. Gżdacz (dyskusja) 20:39, 4 lip 2021 (CEST)[odpowiedz]
Ogólnie uważam, że jeśli robi się rzeczy tak bardzo "pod prąd", że nie tylko wikikod ale nawet silniki wielu czołowych przeglądarek sobie z tym nie radzą, to trzeba się bardzo głęboko zastanowić, czy to ma choćby ślad sensu. Bo ogromną większość sensownych rzeczy przeglądarki robią bez żadnego problemu. Gżdacz (dyskusja) 17:49, 4 lip 2021 (CEST)[odpowiedz]
Im bardziej skomplikowane będzie łączenie, tym gorzej dla efektu końcowego. W tym przypadku jak w Jeden z dziesięciu sama tabela z takimi komórkami pomiędzy to nie jest jakiś duży problem dla np. czytników pod względem technicznym. Większy problem stanowi pewien nadmiar informacji, które niewiele wnoszą, tj. właśnie pierwsza i druga kolumna. Czytnik oczywiście przeczyta, ale treść jest przez to nieco mniej zrozumiała. Dla czytelnika „wzrokowego” – czy rzeczywiście te dwie pierwsze kolumny coś dają? I na marginesie: coś takiego jak „bd.” lepiej zapisywać jako {{skr|bd.|brak danych}} → bd.. Wostr (dyskusja) 01:07, 5 lip 2021 (CEST)[odpowiedz]
Pierwsza i druga kolumna są właśnie podstawą – programy telewizyjne są emitowane seriami/sezonami, a nie edycjami. Na każdą zbędność znajdzie się kontragrument. Na przykład seria (ustalony przez twórców zbiór odcinków) nie zawsze pokrywa się z sezonem (sezonem telewizyjnym, którego w dodatku mamy dwa główne typy: roczny i w przybliżeniu pokrywający się z porą roku) – przykładami są chociażby: parę odcinków Koła Fortuny z września 2019 roku, które zaliczają się do serii przypadającej na sezon 2018/2019, ale tak właściwie poszły na ekran na początku sezonu telewizyjnego 2019/2020 i chyba parę seriali Czwórki, które na początku pandemii zawieszono. W przypadku Jednego z dziesięciu edycje są w zasadzie dodatkiem. Myślałem o zrobieniu dwóch osobnych zestawień – jednego podstawowego, który jest zawsze – podział na serie/sezony oraz osobnej listy zwycięzców, ale nie mam przekonania do tego pomysłu. Ambiroz (dyskusja) 08:35, 5 lip 2021 (CEST)[odpowiedz]
A są jakieś sensowne źródła na te serie i sezony? Widać to jakoś w czołówce programu albo w zestawieniach innych niż marketingowe i/lub fanowskie? To, że seria nie pokrywa się z sezonem jest silną wskazówką, że sezon jest bez znaczenia, to tylko kwestia daty emisji. Wystarczy ją podać i potrzeba wydzielania sezonu znika. Nie ma też u nas artykułu sezon (telewizja). To wszystko wskazuje, że waga tego pojęcia jest bardzo mała i nie warto tego prezentować w artykułach. Gżdacz (dyskusja) 08:56, 5 lip 2021 (CEST)[odpowiedz]
Właśnie zestawienia marketingowe czy inne komunikaty nadawcy byłyby lepsze, bo pochodziłyby od twórców. Czasem o seriach czy sezonach piszą w portalach medialnych (Wirtualne Media itp.), ale nie za każdym razem. Napisałem tutaj, gdy napotkałem problem w poprawieniu kwestii, która dolewa oliwy do ognia: dawniej nie było serii, bo odcinki leciały ciurkiem, nawet w wakacje, więc długość emisji liczono w sezonach (ale ogólnie przyjęło się liczyć sezony od jesieni do lata, taki zresztą podział był wyraźny co najmniej w latach 80. w Stanach Zjednoczonych). Na pewno nie można się pozbyć sezonów, choćby przez wgląd na historię. Choć można się zgodzić, że np. w takim brytyjskim The Cube, gdzie producent wyraźnie rozgranicza odcinki w pewne zbiory, wskazanie sezonu ma mało sensu, bo jedna seria potrafi być rozbita na kilka miesięcy (nieregularnie), a jednocześnie zdarzają się sytuacje, że w odstępie tygodnia pokazywane są dwa odcinki z różnych serii (wg podziału produkcji). Ale w Polsce raczej się tego nie spotyka. Ambiroz (dyskusja) 09:42, 5 lip 2021 (CEST)[odpowiedz]
Ten sezon to najzwyklejsza pochodna ramówki TV. Nie ma żadnego znaczenia dla programu. W ten sam sposób można dopisać sezony do rozgrywek sportowych, które są emitowane w TV. Zwykła bzdura reklamowa. Specyficzny zbieg okoliczności dotyczy seriali. TV zamawia coś na sezon do ramówki. Jeśli się spodoba i uzyska oglądalność to zamówią kolejną porcję na następny sezon. I tak to się kręci. Zostawić tylko daty emisji. Tak będzie najbardziej obiektywnie i wyczerpująco. Paweł Ziemian (dyskusja) 20:02, 5 lip 2021 (CEST)[odpowiedz]
Pusty wiersz pozostający po pustym przebiegu {{...}}
Na końcu sekcji mam generowaną switchem treść. Przy pustym przebiegu switcha (brak treści) pozostaje po nim nowa linia (<p><br></p> - switch jest w nowej linii, bo nad nim jest wypunktowanie), która zwiększa odstęp pomiędzy następną sekcją. Odkryłem, że wstawienie pustego <span></span> dla pustego przebiegu switcha (w #default) "znika" nadmiarową linię - czy to dobre wyjście (może jest już jakieś standardowe rozwiązanie tego problemu)?
Poprzednio ukrywałem większy odstęp przez komentarz z pustą linią kończący się na wierszu tuż nad kolejną sekcją (}}<!--
Sorry to write in English. Pomóż przetłumaczyć na Twój język.
I'm Trizek (WMF). I work as a community relations specialist for the Wikimedia Foundation, and in particular with the Growth team.
As you may already know, your wiki benefits from a set of tools, created to help newcomers in their first edits. Newcomers have access to a dedicated set of tools, mainly gathered on the newcomer Homepage.
Visiting their Homepage, newcomers have access to a set of tasks, filtered down by topics, and by task difficulty. One of the easy task is to add links between articles. We have improved this feature to make it easier for newcomers to use it.
The "new" Add a link allow users to review links that are suggested by the wiki. Links are suggested by a machine, and machines aren't perfect! Suggested links are about 75% correct but they need to be reviewed. As a user, your role is to determine if the links are the right ones, depending on the context.
At the moment, "Add a link" has been tested at 4 wikis (Arabic, Bengali, Czech and Vietnamese). There, newcomers are using it accurately, and are editing more. Please, discover how the links are added.
"Add a link" is now available at your wiki for test purposes. You can turn this tool on to test it, please follow the instructions.
This testing period will be two weeks long. After this, we will turn "Add a link" as the default feature for newcomers. The goal of the testing period is to figure out if the machine predicts accurate links.
Please let me know if you have any question, or feedback, about these tools. I will regularly check this page. If you move this message, please let me know as well.
Na niektórych zdjęciach, po najechaniu myszą, pokazują się (żółte) prostokąty z opisami. Jak się to-to nazywa i może ktoś podpowie, w jakim prostym programie to zrobić? Ciacho5 (dyskusja) 07:05, 8 lip 2021 (CEST)[odpowiedz]
VE: drugi przypis i kolejne nie umieszczają kursora w polu tekstowym
Jeśli w edytorze wizualnym doda się przypis, to przy dodawaniu kolejnych (nawet po innych edycjach) pole tekstowe na link/DOI/inne nie jest fokusowane (trzeba w nie ręcznie kliknąć aby coś wkleić). MarMi wiki (dyskusja) 20:28, 8 lip 2021 (CEST)[odpowiedz]
VE + ek
Od dawna miałem wrażenie, że jest coś nie tak z komunikatem, który ostrzega o próbie ponownego utworzenia strony, która została wcześniej usunięta (prawdopodobieństwo takiego konfliktu jest szczególnie wysokie w przypadku nowych artykułów, które są kasowane w trybie ekspresowym jako ewidentnie nieencyklopedyczne albo przenoszone do brudnopisu). Zrobiłem kilka testów i oto co się okazuje:
Jeśli użytkownik otworzył edytor już po usunięciu strony przez administratora, pojawi mu się wspomniany komunikat, ale komunikat ten natychmiast znika, gdy użytkownik wpisze jakąkolwiek literę.
Jeśli użytkownik najpierw otworzył edytor, później administrator usunął artykuł, a następnie użytkownik próbuje zapisać nowe zmiany lub przełączyć się na edytor kodu, pojawia się dość absurdalny (z punktu widzenia użytkownika) komunikat: Wystąpił błąd podczas kontaktowania się z serwerem Parsoid/RESTBase (HTTP 404).
Czy tak powinien się zachowywać VisualEditor, czy jest to błąd? Jak dla mnie zdecydowanie to drugie – administrator widzi uporczywe próby stworzenia tego samego artykułu, który nie nadaje się do przestrzeni głównej (przypadek 1), a użytkownik nie wie, czemu nie może zapisać edycji (przypadek 2) albo za co dostaje blokadę lub upomnienie (przypadek 1). Dodam jeszcze, że w edytorze kodu problem ten praktycznie nie występuje – komunikat jest cały czas doskonale widoczny i trudno go zignorować. PG (dyskusja) 11:04, 9 lip 2021 (CEST)[odpowiedz]
Kategorie a Wikidane
Użytkownik Pleoniak stworzył całą garść kategorii związanych z filmowcami czy ludźmi teatru. Problem w tym, że żadnej nie umieścił w odpowiednich wpisach na Wikidanych. Można to poprawić jakimś botem? W tej chwili żeby to poprawić, będzie potrzeba chyba paru godzin... (np. to: Kategoria:Słowaccy reżyserzy teatralni = Kategória:Slovenskí divadelní režiséri, warto przejrzeć wkład). 83.23.96.227 (dyskusja) 00:44, 10 lip 2021 (CEST)[odpowiedz]
Powtórzone przypisy w treści, tj. pod nagłówkiem „Przypisy” wyświetla się wielokrotnie taki sam przypis <ref>.
Powtórzone przypisy w kodzie, lecz nie w treści, tj. wikikod zawiera dwa lub więcej wystąpień znacznika <ref> z taką samą zawartością oraz identycznym atrybutem name. Parser MediaWiki traktuje to jako jeden i ten sam przypis.
Wydaje mi się, że narzędzie checkwiki obsługuje tylko pierwszy scenariusz. Uważam, że drugi również warto obsłużyć. Użytkownik otrzyma błąd, jeżeli zmieni zawartość powtórzonego przypisu bez przystosowania pozostałych jego wystąpień. Ponadto Edytor Wizualny nie potrafi rozpoznać przypisów o tej samej nazwie, jeżeli te są powtórzone w kodzie.
Przygotowałem już program do obróbki artykułów, kod źródłowy jest zakomentowany na dole strony listy roboczej. Ponieważ korzystam z zewnętrznego parsera HTML, ten wprowadza drobne zmiany jako skutek uboczny przetwarzania kodu, m.in.: zamienia <ref name=a/> na <ref name="a" /> i <ref name='b'></ref> na <ref name="b" />, upraszcza <br/> na <br>, podmienia spację niełamliwą na encję . Jeżeli grupy powtórzonych przypisów nie dostały jeszcze nazwy, nadaje im automatycznie wygenerowaną wg schematu "autonazwaX" (np. "autonazwa1").
Wykonałem już kilka testowych edycji, dla przykładu:
Resztę warunków opisałem na stronie listy roboczej. Warto nadmienić, że program ignoruje strony, na których pojawia się {{refn}} bądź {{#tag:}}, i nie obsługuje {{u}} ani zwykłych przypisów z atrybutem group. Peter Bowman (dyskusja) 18:19, 10 lip 2021 (CEST)[odpowiedz]
Generalnie Za. Czy bot wyszukuje duplikaty po stronie HTML czy dokonuje jakieś przekształcenia normalizujące wikikod aby zwiększyć prawdopodobieństwo odnalezienia duplikatów? Na przykład redukcja zbędnych odstępów lub przekształcenie szablonów cytowania do jakiejś formy kanonicznej? Wiem, jest kod, ale łatwiej zapytać niż analizować. Paweł Ziemian (dyskusja) 19:16, 10 lip 2021 (CEST)[odpowiedz]
Działa na wikikodzie, uruchamiając na nim parser HTML, żeby łatwiej i pewniej wyszukać znaczniki <ref>. Wykonuje trim na ich zawartości, tj. usuwa znaki białe po lewej i prawej stronie. Jeżeli po tym przekształceniu treść znacznika stanowi pojedyncze wywołanie dowolnego szablonu, parsuje jego parametry bez względu na kolejność; innymi słowy utożsamia <ref>{{Cytuj|autor=Jacek|tytuł=Test}}</ref> z <ref>{{Cytuj|tytuł=Test|autor=Jacek}}</ref> mimo różnic w wikikodzie. Pomija wewnętrzne komentarze HTML, np. <!-- Tytuł wygenerowany przez bota -->. Nie sprawdzałem, ale prawdopodobnie parser HTML skraca wielokrotne spacje do pojedynczej. Peter Bowman (dyskusja) 20:34, 10 lip 2021 (CEST)[odpowiedz]
Poprawka: spacji nie skraca (co zresztą widać na powyższych diffach), w przeciwnym razie narobiłby bałaganu w infoboksach. Po uwzględnieniu powyższych transformacji (trim, sortowanie szablonów, bez komentarzy HTML) włącznie z zamianą spacji niełamliwej na , algorytm wymaga całkowitej zgodności co do znaku, aby uznać, że dwa przypisy są tożsame. Peter Bowman (dyskusja) 21:42, 10 lip 2021 (CEST)[odpowiedz]
Czyli jest tak jak sobie wstępnie to zadanie wyobrażałem. Pytając o spacje miałem na myśli tylko wyszukiwanie duplikatów. Nie miałem na myśli generowania ostatecznego wyniku, bo tu wystarczy dowolny 1 z N przypisów. Można by się teoretycznie zastanawiać nad jego wewnętrzną estetyką, ale to jest zupełnie inne zadanie. Paweł Ziemian (dyskusja) 21:53, 10 lip 2021 (CEST)[odpowiedz]
Wobec braku zastrzeżeń zamierzam uruchomić botowanie przed nadchodzącym zrzutem bazy, czyli między sobotą (17) a poniedziałkiem. Niedługo po wykonaniu pracy będzie można porównać wyniki WP:CHECK. Peter Bowman (dyskusja) 01:15, 17 lip 2021 (CEST)[odpowiedz]
(@The Polish) Botowanie zakończone. Pominięto kilkadziesiąt artykułów, które po dokładniejszej analizie nie spełniały warunków bądź zawierały błędy składniowe, które mogłyby kolidować z programem bota. Wkrótce odświeżę listę i wyszukam nowe wystąpienia w kolejnym zrzucie bazy. W tym samym czasie powinno zostać odświeżone zestawienie WP:CHECK#81, które obecnie wyświetla się puste.
Edytowanie kategorii (treści, opisu itp., nie schematu kat.)
[18] -- tutaj żeby dodać przecinek, musiałem dodać jednocześnie (powtórzyć) jedną z kategorii, a następnie usunąć własny błąd, bo inaczej system wiki coś tam narzekał, że coś tam źle robię, że hasła w kategorii umieszcza się inaczej czy jakoś tak. Dziwne. 83.23.140.110 (dyskusja) 21:59, 10 lip 2021 (CEST)[odpowiedz]
Mea culpa, filtr blokujący błędne dodawanie do kategorii nie radzi sobie z edycjami w obrębie opisu kategorii. Kiedyś to naprawię, ale na tę chwilę nie mam na to pomysłu. W każdym razie gratulacje, że znalazłeś sposób na obejście problemu. PG (dyskusja) 12:07, 11 lip 2021 (CEST)[odpowiedz]
Formatowanie tabel
Cześć, mam nadzieję, że wybrałem odpowiedni dział (to chyba będzie jednak kwestia techniczna).
Stworzyłem następującą tabelę:
Komórka A
Komórka B
Komórka C
Komórka D
Komórka E
Wiersz 1A
X
Wiersz 1B
X
Wiersz 1C
X
Wiersz 1D
Wiersz 1E
Wiersz 2A
X
Wiersz 2B
X
Wiersz 2C
X
Wiersz 2D
Wiersz 2E
X
Wiersz 2B′
X
Wiersz 2D′
X
Wiersz 2D″
Czy jest możliwość aby wiersze 2B i 2B′ były jednakowej grubości, tj. linia oddzielająca wiersze była w połowie względem wierszy 2A i/lub 2C?
Niestety nie znalazłem odpowiedzi na pytanie Pomoc:Tabele--Grisha12 (dyskusja) 00:00, 11 lip 2021 (CEST)[odpowiedz]
Najprościej zwiększyć rowspan, tak by liczba wierszy była parzysta; tutaj: zamiast rzeczywistych 3 wierszy dać 6 - wtedy komórki mające zajmować połowę wysokości rozciągają się na trzy wiersze, a te których jest trzy - na dwa wiersze. Tu pojawia się problem, bo potrzebne są puste wiersze pomiędzy. W przeciwieństwie do czystego HTML-a wikikod nie pozwala na wstawienie takiego wiersza. Można to rozwiązać dodaniem ukrytej komórki, ale nie wiem, czy to rozwiązanie nie zaciemnia nazbyt kodu. 94.154.22.22 (dyskusja) 02:07, 11 lip 2021 (CEST)[odpowiedz]
Docelowo w głównej, póki co w moim brudnopisie (skok o tyczce, rok 1908). Niestety problem jest chyba nie od przeskoczenia w żaden sensowny sposób także zostawię to taki sposób jaki przedstawiłem oryginalnie. Te tabele są robione zgodnie już z istniejącym standardem, więc muszą wyglądać w ten sposób. Grisha12 (dyskusja) 09:17, 12 lip 2021 (CEST)[odpowiedz]
To jest propozycja standardu, a nie standard, to raz. Dwa: w tej propozycji tabele są raczej standardowe, bez udziwnień; powyżej zaczynają się w tabelach udziwnienia, które może i wizualnie mogą się jakoś prezentować, ale technicznie będą prawdopodobnie zbyt skomplikowane, aby były w przestrzeni głównej. Od pewnego czasu kierunek zmian to raczej upraszczanie tabel i podobnych elementów. Wostr (dyskusja) 00:47, 13 lip 2021 (CEST)[odpowiedz]
Zapytam jeszcze raz, tym razem w odniesieniu do innego szablonu – czy takie rzeczy można naprawić w sposób systemowy? Po co szablon wyświetla takie śmieci, jeśli brakuje parametru (nie można uznać, że parametr jest pusty?). Można to chociaż przebotować? Przeglądam sobie kategorię i widzę, że zepsuta jest chyba połowa wywołań tego szablonu... 83.23.97.173 (dyskusja) 13:57, 12 lip 2021 (CEST)[odpowiedz]
Faktycznie zdarza się, że jakiegoś parametru zabraknie. Jednak statystyka użycia dowodzi, że lepiej trzymać domyślnie puste parametry w wywołaniu niż je pomijać. Jeśli ktoś napotka puste dane to jest jakaś szansa, że je uzupełni. Natomiast jeśli ktoś (zwłaszcza nowy) nie widzi jakie dane można podawać, to próbuje wymyślać jakieś własne nieistniejące, które z oczywistych względów nie działają. Początkowy brak wiedzy, a potem lenistwo, nie pozwalają na ciągłe zaglądanie do dokumentacji szablonu. W dodatku lenistwo czasami nie pozwala na aktualizację dokumentacji. Reasumując, te puste parametry naprawdę bardzo wszystkim pomagają. Paweł Ziemian (dyskusja) 19:00, 12 lip 2021 (CEST)[odpowiedz]
Nie wiem, czy dobrze zrozumiałeś. Tu chodzi o to, że jeden z obowiązkowych parametrów nie był podany w wywołaniu szablonu, przez co szablon się sypał – czy nie dałoby się czegoś takiego poprawiać jakimś botem (poprzez dopisanie pustego parametru, jeśli w którymś wywołaniu go brakuje)? 2A00:F41:4898:FFA1:8577:3A3A:4618:3249 (dyskusja) 01:37, 13 lip 2021 (CEST)[odpowiedz]
Rzeczywiście, nie zrozumiałem. Systemowego rozwiązania nie znam. Zwykle polega to na nauczeniu bota generowania treści konkretnego infoboksu i przeskanowaniu wszystkich wywołań. Szanse na poprawę rosną jeśli w infoboksie jest więcej rzeczy do poprawy. Zmiany można zaproponować w dyskusji wikiprojektu od infoboksów. Paweł Ziemian (dyskusja) 18:04, 13 lip 2021 (CEST)[odpowiedz]
Botowanie pełnych przypisów na przypisy harwardzkie?
Czy byłaby możliwość stworzenia bota, który by robił coś takiego? Zdaję sobie sprawę, że technicznie może być to trudne. Ułatwiłoby to sprzątanie artykułów: odchudzić je "wagowo", oraz ich długość. Taki problem pojawia się np. w rozbudowanych ostatnio artykułów Język praindoeuropejski i Języki indoeuropejskie - mamy wszystkie źródła wymienione w akapicie "Bibliografia", a wcześniej 200/330 pełnych przypisów z tymi samymi źródłami różniącymi się tylko stroną. Można by też posprzątać mieszane "typy" przypisów. Bot mógłby więc przerabiać
Tekst artykułu[1]
Przypisy
↑Sławobóg, Książka, Warszawa: Wydawnictwo, 2000, s. 137 [dostęp 2020-09-01].
Sławobóg, Książka, Warszawa: Wydawnictwo, 2000, s. 137 [dostęp 2020-09-01].
Domyślam się, że problemem mogłoby być to, w które miejsce ma lądować {cytuj}/{cytuj książkę} itd., bo te akapity różnie są nazywane. Sławobóg (dyskusja) 19:43, 24 lip 2021 (CEST)[odpowiedz]
Warto zauważyć, że powyższy wpis jest raczej pytaniem o techniczne możliwości, a nie konkretnym zleceniem dla bota. Więc może warto przy okazji przedyskutować temat, a nie od razu mówić „stop”. Ja na przykład bardzo chętnie bym się dowiedział, dlaczego szablon Odn jest czymś co powinno znikać albo czy to jest dobre zjawisko, że przypisy harwardzkie stosujemy dość rzadko (o ile faktycznie są takie rzadkie – powiedziałbym raczej, że w ogóle [za] rzadko stosujemy przypisy). PG (dyskusja) 09:34, 25 lip 2021 (CEST)[odpowiedz]
Obecny sposób zapisu dla użytkownika Internetu jest korzystniejszy – wystarczy najechać kursorem na nr odnośnika i wszystko od razu się pojawia. Przy systemie harwardzkim trzeba kliknąć w odnośnik (bo po najechaniu kursorem ma się informację szczątkową, niemal nic nie dającą), a potem jeszcze raz w strzałkę, a potem jeszcze raz wrócić do czytanego fragmentu – to wymyślił chyba ktoś, by specjalnie skomplikować korzystanie ze stron. To co może i sprawdza się w publikacjach drukowanych może być koszmarnym rozwiązaniem w publikacjach internetowych. Wikipedia ma być przyjazna technicznie dla czytelnika, a nie, pod płaszczykiem wprowadzania jakiś wydumanych standardów, utrudniać odbiór artykułów. Aotearoa dyskusja09:53, 25 lip 2021 (CEST)[odpowiedz]
OK, to już jest jakiś konkret. Pytanie tylko, czy przy każdym najechaniu kursorem na odnośnik musimy koniecznie mieć tę pełną informację, czy w zupełności wystarczy to minimum, jakie dają przypisy harwardzkie. Informacja pełna jest zazwyczaj (chyba) potrzebna tylko raz, kiedy czytający lub edytujący jeszcze nie zna źródeł użytych w artykule. Później już trzyma te dane w pamięci krótkoterminowej, więc nie powinno przeszkadzać, że trzeba jedno kliknięcie więcej, żeby się do nich dostać. A szablon {{odn}} znacząco upraszcza wikikod i przy okazji czytelność listy przypisów. PG (dyskusja) 13:46, 25 lip 2021 (CEST)[odpowiedz]
Ja jestem trochę ułomny (czego jestem świadomy), ale nie jestem w stanie utrzymać w pamięci krótkoterminowej połączenia nazwisko+rok i utożsamić tego w locie z daną pozycją, której autora i tytuł znam. Paelius (dyskusja) 14:12, 25 lip 2021 (CEST)[odpowiedz]
Ja osobiście lubię {{odn}} bo jest on dla mnie wygodny w kodzie. Jednak nigdy nie zdecydowałem się go wstawiać botem. Wszelkie takie edycje robiłem ręcznie. W nowych artykułach od razu. W starych tylko gdy liczba odwołań do jednej publikacji była znaczna. Przy czym z {{odn}} podobno jest taki problem, że nie jest on przyjazny do pracy w VE. Osobiście mnie to nie dotyka, bo nie używam VE. Temat można pociągnąć w inną stronę. Można spróbować zrobić gadżet, który zamieni treść tworzoną przez {{odn}} na pełny przypis. Wymagałoby to jednak pewnych zmian w szablonach cytowania. Paweł Ziemian (dyskusja) 16:43, 25 lip 2021 (CEST)[odpowiedz]
{{Odn}}y są wyłącznie rozwiązaniem zastępczym wobec braku odpowiedniego rozwiązania w oprogramowaniu MediaWiki. Nie są rozwiązaniem powszechnie akceptowanym i należałoby uszanować sposób, w jaki dany artykuł został napisany. O ile dla wielu edytorów i czytelników mogą być ułatwieniem, dla innych mogą nie być — ich edytowanie w VE nie jest zbyt łatwe. Jeśli zaś chodzi o najeżdżanie kursorem na przypis — jest to prawdziwe jedynie dla użytkowników urządzeń, w których kursor występuje, a więc mniejszości. Były próby rozwinięcia oprogramowania MediaWiki o możliwość dodawania skróconych przypisów (T100645), jednak projekt ten został zarzucony, głównie ze względu na trudności w jego implementacji w VE. Jeżeli jakieś wysiłki powinny być podejmowane w tym zakresie, to raczej w kierunku wprowadzenia w oprogramowaniu jednolitego sposobu wprowadzania przypisów skróconych — inaczej prowadzić to będzie to jeszcze większego rozjeżdżania się nam różnych sposobów edycji projektu (jak obecny problem z {{r}} i zwykłymi przypisami po tym, jak WMF stwierdził, że nie przewiduje jakiegokolwiek wsparcia rozwiązań tego typu tworzonych oddolnie przez społeczności). Wostr (dyskusja) 18:16, 25 lip 2021 (CEST)[odpowiedz]
Chyba nastąpiło jakieś nieporozumienie. Ten bot nie ma służyć temu, żeby przelecieć nim wszystkie obecne artykuły. Są artykuły, np. krótkie o niewielkiej liczbie źródeł, gdzie zwyczajne przypisy są ok. Taki bot mógłby służyć osobom, które chciałby przerobić swoje artykuły w ten sposób. Ja prawie zawsze używam {{odn}} i robię tak od początku, więc gdy rozbudowuję artykuł, lub tłumaczę jakiś z innego języka, chciałbym móc przerobić przypisy na "moje", żeby miał je spójne. Zarzuty że "trzeba to najpierw przedyskutować" są tutaj niezasadne. Sławobóg (dyskusja) 22:27, 25 lip 2021 (CEST)[odpowiedz]
Po prostu nie jasno się wyraziłeś botowanie to robienie czegoś botem - na masową skalę, a tobie chodziło o narzędzie do przekształcania przypisów czyli skrypt który robi to automatycznie na życzenie użytkownika w konkretnych przypadkach. Krzysiek 123456789 (dyskusja) 22:39, 25 lip 2021 (CEST)[odpowiedz]
Może od razu zakażemy korzystania z {{odn}}? Z tego co wiem, to nie ma nigdzie przymusu korzystania z jednego słusznego sposobu wstawiania przypisów. Z tego co wiem, to nie ma również zakazu przerabiania wikikodu innych artykułów i zmieniania tego typu rzeczy. Dlaczego więc podczas przepisywania artykułu mogę przerabiać szablony na {{odn}} ręcznie, ale skryptem już nie? Sławobóg (dyskusja) 14:12, 27 lip 2021 (CEST)[odpowiedz]
Możesz przerabiać w stronę {{odn}}, nawet z wykorzystaniem skryptu, ktoś inny może przerabiać w drugą stronę, także z wykorzystaniem skryptu. Z tego powodu dobrym obyczajem jest, aby nie zmieniać sposobu cytowania, jeżeli istnieje uzasadnione przypuszczenie, że ktoś intencjonalnie użył innego sposobu. Wostr (dyskusja) 14:58, 27 lip 2021 (CEST)[odpowiedz]
Nie do końca. Wikipedia:Boty#Zalecenia jasno stanowią "Czynności, które obejmują dużo artykułów, w szczególności import dużej liczby masowo wygenerowanych stubów, powinno się w miarę możliwości skonsultować. Skala konsultacji powinna być odpowiednia do skali zmian – czyli o import 100 artykułów można po prostu spytać na IRCu, a w przypadku importu 100 000 lepiej ogłosić zapytanie wszędzie, gdzie to tylko możliwe, i odczekać odpowiedni czas.". Konsultujemy działania skryptem, głownie dlatego, że bardzo łatwo są one w stanie wywołać zmiany w bardzo dużej liczbie artykułów.
A co mają zalecenia dot. użycia botów do użycia skryptu w celu edycji aktualnie edytowanej strony? Użycie WP:SK czy jakiegokolwiek innego skryptu ma się nijak do działania botów. Wostr (dyskusja) 00:31, 28 lip 2021 (CEST)[odpowiedz]
Co do mojej wcześniej wypowiedzi dot. {{odn}}, jest to przestarzały szablon, zupełnie nie kompatybilny z edytorem wizualnym. Rozumiem, że są osoby, które wolą z niego korzystać, nie powinien on być jednak powszechnie propagowany, właśnie z powodu trudności jego obsługi przez wszystkich, którzy nie są jego codziennymi użytkownikami. Przypisy harwardzkie same w sobie nie są złe (chociaż nie jestem ich fanem), jednak ich obecna forma na Wikipedii jest... no nieodpowiednia. Nadzik (dyskusja) 15:08, 27 lip 2021 (CEST)[odpowiedz]
(po konflikcie edycji) Taki głos z boku dyskusji o botowaniu. Kształt przepisów harwardzkich (krótkich) jest jak najbardziej wskazany dla artykułów w wikipedii. Nie czyni z sekcji "przypisy" nadmiernie rozbudowanego elementu artykułu. W tym kierunku moim zdaniem winno iść masowe, jakże konieczne dla potrzeb wikipedii, źródławianie. Sprawę technicznej "przyjazności" ich stosowania przez redaktorów wikipedii zostawiam naszym "technikom". Na pewno COŚ wymyślą...--Kerim44 (dyskusja) 15:21, 27 lip 2021 (CEST)[odpowiedz]
Mój generator jest tylko nakładką do citoida, więc nie wygeneruje nic w przypadku gdy citoid nie dostarczy mu danych. A gdzie zgłaszać problemy z citoidem nie wiem. ~malarz plPISZ15:51, 27 lip 2021 (CEST)[odpowiedz]
@Michał Sobkowski, Citoid z tego co widzę pobiera głównie z Worldcat. Jeśli coś jest u nich, to powinno wygenerować przypis (u mnie działa normalnie przez VE i przez formularz malarza).
@Paweł Ziemian Dzięki wielkie :). Przy okazji, może warto przejrzeć opis szablonu {{uwagi}}, bo jako standard sugerowane jest w nim użycie w połączeniu z {{refn}}, a Twój sposób jest zdecydowanie prostszy i czytelniejszy. Maire♣00:06, 29 lip 2021 (CEST)[odpowiedz]
Ja bym zaproponował trochę inne rozwiązanie przy stosowaniu {{odn}} w przypisach rzeczowych (uwagach), tj. stosowanie parametru ref=nie. Wydaje mi się nieco frustrujące klikanie w odnośnik w przypisach rzeczowych, aby przejść do przypisu typu harwardzkiego, który muszę znowu kliknąć, aby przejść do pełnego opisu bibliograficznego (a wszystko w obrębie trzech krótkich sekcji mieszczących się na ekranie). A tworząc przypis rzeczowy w taki sposób: « Licząc ze wznowieniami, daje to 658 pozycji wydawniczych (Jamróz-Stolarska 2014 ↓, s. 100, Jamróz-Stolarska 2020 ↓, s. 313) » da się przejść od razu do opisu bibliograficznego. Uwaga (przypis rzeczowy) to też przypis, nie wiem więc, czemu z uwag nie odsyłać od razu do bibliografii. Wostr (dyskusja) 01:37, 29 lip 2021 (CEST)[odpowiedz]
Ostatnio nowicjuszowi nie spodobał się szablon, więc zmienił nazwę pola. Nie jego wina. Czy nie można byłoby zabezpieczyć wszystkich szablonów? Moim zdaniem należy to zrobić, do redaktora albo i admina (z informacją, że jeśli ktoś chce zmieniać, zostanie mu to udostępnione). Ciacho5 (dyskusja) 18:29, 30 lip 2021 (CEST)[odpowiedz]
Chyba bardziej uniwersalnym rozwiązaniem byłoby gdyby istniała osobna grupa z uprawnieniem do edycji szablonów i modułów. Wikitechnik albo coś. Mogliby do niej z automatu należeć redaktorzy. Chyba już było kiedyś coś takiego dyskutowane. Paweł Ziemian (dyskusja) 19:43, 30 lip 2021 (CEST)[odpowiedz]
Błąd ukazał się tylko tej grupie ok. stu osób z uprawnieniami redaktora. Dzięki mechanizmowi wersji przejrzanych pozostałym użytkownikom (oraz czytelnikom Wikipedii) powinna zostać wyświetlona wcześniejsza, działająca wersja. Peter Bowman (dyskusja) 19:47, 30 lip 2021 (CEST)[odpowiedz]
Szablony nawigacyjne może dla redaktorów lub autoconfirmed, chociaż kilkanaście edycji w 4 dni to może być stanowczo za mało na zdobycie wiedzy o szablonach. Z pewnością nie powinno być tak, że ktoś bez uzgodnienia i może bez zauważenia, zmienia infoboks. Większość infoboksów to efekt jakiejś pracy i uzgodnień, a jak komuś przyjdzie do głowy zmieniać współmałżonek na współmałżonka to może na kilka czy kilkanaście minut zrobić bałagan w setkach/tysiącach artów, nie? Ciacho5 (dyskusja) 19:51, 30 lip 2021 (CEST)[odpowiedz]
Infoboksy można by zabezpieczać prewencyjnie na średnim poziomie – są skomplikowane, nowicjusze nie mają tam po co grzebać (szczerze mówiąc, nawet większość administratorów nie ma ochoty tego robić, ale tutaj pewnie można liczyć na zdrowy rozsądek). Szablonów nawigacyjnych zabezpieczać raczej nie chcemy, bo będzie zaraz lawina próśb do administratorów w stylu „dodajcie nową płytę” albo „dodajcie nowy sezon serialu”. PG (dyskusja) 15:28, 1 sie 2021 (CEST)[odpowiedz]
Szablony mają przecież wersje przejrzane, czy nie ma możliwości zrobić tak, żeby na strony podstawiała się przejrzana zamiast najnowszej? Myślę, że to rozwiązałoby problem.--Krzysiek 123456789 (dyskusja) 22:24, 2 sie 2021 (CEST)[odpowiedz]
wstawianie krótkich informacji w uwagach w tabeli
Czy przenoszenie krótkich informacji z tabeli do sekcji uwagi jak w tym artykule ma jakikolwiek sens? Przecież te linki "wynik X" zajmują więcej miejsca niż przeniesiony do uwag właściwy wynik. A dostępność takich informacji na urządzeniach mobilnych jest IMO ograniczona. ~malarz plPISZ22:52, 30 lip 2021 (CEST)[odpowiedz]
Sekcja Uwagi przydaje się raczej do dłuższych tekstów i raczej powinna służyć do prezentowania uwag od redaktorów, a nie szczegółów merytorycznych (które wymagają przecież podania źródła, a przypisu do uwagi zrobić się chyba nie da). PG (dyskusja) 09:24, 31 lip 2021 (CEST)[odpowiedz]
"Uwagi" służą do umieszczania w nich przypisów rzeczowych, a nie merytorycznej treści. Wynik (w tym wypadku) jest merytoryczną treścią. To tak jakby wynik meczu w piłkę kopaną, o którym jest hasło, dać w "Uwagach"... Ogólnie, odpowiadając na pytanie: nie ma sensu, bo to nie tylko kwestia "miejsca", ale i układu w haśle merytorycznej treści. Ented (dyskusja) 18:17, 5 sie 2021 (CEST)[odpowiedz]
Podawanie w szablonie linku do Wikidanych jest według mnie bardzo sensownym rozwiązaniem, ponieważ (przynajmniej teoretycznie) pozwala użytkownikowi wybrać, w jakim języku przeczyta ten nieistniejący u nas artykuł. Jednak niestety, WD są raczej nieintuicyjne dla pierwszego z brzegu czytelnika, przez co prawdopodobnie nie dokopie się do interwikiów na samym dole.
Mając na uwadze powyższe, napisałem narzędzie, które wyszukuje w artykule linki do Wikidanych, wstawione za pomocą {{link-interwiki}}, i dołącza do nich wyskakujący panel z listą języków, w których istnieje dany artykuł. Jednocześnie, logo WD (nieczytelne w rozmiarze 10x7 px) jest zamieniane na japońską (chińską?) literę 字 (pierwszą z brzegu; nie wiem, co znaczy). W małym rozmiarze prezentuje się lepiej niż ikonki, które sprawdzałem, a mam nadzieję, że kojarzy się z czymś w stylu „wybór języka”.
Myślałem, żeby docelowo to narzędzie było gadżetem, włączonym domyślnie (ponieważ główną grupę docelową stanowią osoby z zerowym i małym doświadczeniem na Wikipedii).
Kod narzędzia jest dostępny tutaj: JS oraz CSS. Ten pierwszy plik jest raczej trudny w analizie, ponieważ powstał jako wynik transpilacji TypeScriptu dostępnego na GitHubie.
Jestem za wprowadzeniem tego narzędzia, myślę że ułatwiłoby to czytającym wejście na inne wersje językowe. BTW: ZNak który wybrałeś onzanacza sylabę(?) lub dwuznak(?) "Zì". Ynnarski (podyskutujmy) 19:31, 2 sie 2021 (CEST)[odpowiedz]
Nieczytelne logo Wikidanych zamieniane jest na jeszcze bardziej nieczytelny i nikomu nieznany znak z innego alfabetu? Czy tylko ja czegoś tu nie rozumiem? Wostr (dyskusja) 21:49, 3 sie 2021 (CEST)[odpowiedz]
@Wostr, Logo Wikidanych w tym rozmiarze wygląda jak kolorowa plama, która pierwszemu z brzegu użytkownikowi nic nie mówi. Natomiast ten symbol jest nieznany większości czytelników, ale czytelny (w znaczeniu - poszczególne kreski da się bez problemu rozróżnić). Wydaje mi się też, że symbol pochodzący z chińskiego lub japońskiego pisma, umieszczony przy czerwonym linku skojarzy się czytelnikowi z wyborem języka. Pierwotnie chciałem umieścić tam ikonkę kuli ziemskiej, ale żadna, którą znalazłem nie wyglądała wystarczająco ostro w tym miniaturowym rozmiarze. Msz2001 (dyskusja) 21:57, 3 sie 2021 (CEST)[odpowiedz]
A mi się nie wydaje. Znak alfabetu niełacińskiego zastosowany w zupełnym oderwaniu od jakiejkolwiek funkcji związanej z tym alfabetem lub językiem, a zastosowany do zupełnie niezwiązanej z tym znakiem funkcji? Coś tu nie gra, nawet dużo. Tak się nie robi, jeśli już takie dziwactwa się tworzy, to lepiej to robić w postaci grafiki zastępującej symbol, odpowiednio opisanej (tekst alternatywny, bez odnośnika itd.). Poza tym, kto powiedział, że to ma być jeden znak, jeden symbol, dwuznak, skrót, skrótowiec, coś krótkiego? Co jest złego w [w innych językach]? Mamy np. [niewiarygodne źródło?] albo [brak potwierdzenia w źródle]. Wostr (dyskusja) 22:06, 3 sie 2021 (CEST)[odpowiedz]
Jeśli to logo Wikipedii będzie dobrze wyglądało w tym miniaturowym rozmiarze, to w sumie może być. Chociaż nie jestem w 100% przekonany, bo raczej znaczy "Wikipedia" niż "obcojęzyczne Wikipedie" Msz2001 (dyskusja) 22:30, 3 sie 2021 (CEST)[odpowiedz]
Logo Wikidanych nie chcę wykorzystywać ze względu na to, że prawdopodobnie jest obce przeciętnemu czytelnikowi Wikipedii. Nie wskazuje też na wybór języka. Msz2001 (dyskusja) 22:30, 3 sie 2021 (CEST)[odpowiedz]
Celem symbolu, znajdującego się na prawo od czerwonego linku jest wskazanie użytkownikowi, że może
wybrać język, w którym przeczyta ten artykuł. To znaczy – po najechaniu na nią myszką, wyświetlany jest
panel z listą języków. Dlatego ikonka powinna spełniać następujące warunki:
Być zrozumiała dla użytkownika – tj. wskazywać na pojęcia typu „język”, „wybór języka”,
Wyglądać wyraźnie w niewielkim rozmiarze
Poniżej znajdują się przykłady, jak wyglądają propozycje, które padły powyżej. Dorzuciłem jeszcze parę wersji od siebie.
Nie istnieje – nie kojarzy się z wyborem języka, jest niewyraźna; ikona i tak nie jest linkiem do Wikidanych (w przeciwieństwie do „gołego” szablonu)
Nie istnieje – podobnie jak wyżej, lecz trochę wyraźniejsza wersja
Nie istniejeWD – czytelnik raczej nie będzie wiedział, co oznacza WD, nie jest to też związane z samym wyborem języka, ale z miejscem, skąd jest ona zaciągana (podobnie powyższe loga)
Nie istnieje字 – losowy znak z obcego alfabetu, może zmieszać użytkownika
Nie istnieje文 – symbol, który po chińsku znaczy „pismo”, ale również może zmieszać użytkownika
Nie istnieje(jęz.) – skrót od „języki”; po pierwszym sprawdzeniu, do czego służy, jego zastosowanie będzie oczywiste
Nie istnieje – wskazuje na Wikipedię, ale może konfundować czytelnika; napotkane gdziekolwiek w internecie oznaczałoby „przeczytaj na Wikipedii”, a tutaj?
Nie istnieje – kula ziemska raczej mogłaby się kojarzyć z wyborem języka, ale ta jest niewyraźna w małym rozmiarze
Nie istnieje – być może ta ikonka? Super wyraźna nie jest, ale wydaje mi się, że mogłaby być (ale jest na licencji CC-BY, więc gdzieś będę musiał zmieścić link do Commons).
↑W przeciwieństwie do [potrzebne źródło], dostępność treści w innych językach nie jest ważną informacją, ale dodatkową. Brak źródeł wpływa (lub ma wpływać) na odbiór tekstu i dobrze, jeśli czytelnik nie pominie tej uwagi.
moim zdaniem "[w innych językach]" jest najlepszą opcją. Podobnie jak "[potrzebne źródło]" wskazuje na pewne braki (w tym wypadku artykuł). ~malarz plPISZ11:55, 4 sie 2021 (CEST)[odpowiedz]
Ja sądzę, że pisanie "[w innych językach]" jest zbyt rozlazłe. Najlepsze w mojej opinii są lub proponowane przez przedmówcę . Ta ikona z wersji mobilnej ładnie się skaluje, i utrzymamy konwencję aby ta sama ikona oznaczała to samo o co walczy dużo osób np. tutaj. Pzdr. Krzysiek 123456789 (dyskusja) 19:48, 4 sie 2021 (CEST)[odpowiedz]
Dosyć mała jest ta ikona na monitorze. Może gdyby nie była wyboldowana, albo niebieska, to by się tak nie rozmazywała w oczach. Na pewno najbardziej czytelne jest w innych językach, choć rzeczywiście zajmuje dużo miejsca. PuchaczTrado (napisz tutaj lub wstaw ping) 07:29, 5 sie 2021 (CEST)[odpowiedz]
Wygląda na to, że preferowane jest w którymś z wariantów kolorystycznych. Jak wrócę z wakacji, pokombinuję z odcieniami (czarny, ciemnoszary, granatowy). Ewentualne głosy, które się do tego czasu pojawią, chętnie wysłucham. Msz2001 (dyskusja) 21:35, 6 sie 2021 (CEST)[odpowiedz]
Właśnie zaktualizowałem narzędzie. Ikonką, która wywołuje wybór języka jest . Przy okazji przygotowałem wersję panelu przyjazną użytkownikom smartfonów (wygląda tak: [20]). Co prawda nadal wymaga kliknięcia palcem w bardzo mały obszar, ale myślę, czy nie zintegrować panelu z językami z tym, który wyświetla się na Minervie po naciśnięciu czerwonego linku („czy utworzyć stronę?”)(już zrobione 12:19, 16 sie 2021 (CEST)). Z innych zmian, to nazwy języków wyświetlają się teraz po polsku. Msz2001 (dyskusja) 20:05, 15 sie 2021 (CEST)[odpowiedz]
Przegląd gadżetu „ikony w nagłówku” vs nowy Wektor
tl;dr: gadżet odpowiedzialny za wstawianie ikony kłódki skorzysta z elementu mw-indicators.
Za sugestią @SGrabarczuk (WMF)/@Tar Lócesilion przeprowadzam przegląd domyślnego gadżetu „Ikony w nagłówku – skrypt ustawiający obok siebie ikony wyświetlane w nagłówku” (kod źródłowy), konkretnie pod kątem nowej odsłony skórki Wektor (mw:Reading/Web/Desktop Improvements). To narzędzie ma lub miało wpływ na umieszczanie elementów w prawym górnym rogu, takich jak kłódka strony zabezpieczonej, odznaczenia AnM, minimapa, skróty itd. Z czasem jednak oprogramowanie MediaWiki zyskało nowe sposoby osiągnięcia tego samego efektu (mw:Help:Page status indicators), a ów gadżet stał się przestarzały. Wynik przeglądu:
Odznaczenia (m.in. AnM) zostały już jakiś czas wcześniej przystosowane do wywołania przez elementy <indicator>, lecz ikonka w opisie narzędzia pozostała.
Podobnie zostały potraktowane skróty (zob. {{skrót}}), w związku z czym gadżet nie musi już obsługiwać klasy shortcut_upper (wyniki wyszukiwania).
Użytkownicy mogli zdefiniować dowolne elementy z klasą put-in-header, zwykle na swojej stronie użytkownika, które gadżet miał następnie przenieść do górnego prawego rogu (wyniki wyszukiwania). Te elementy najlepiej zastąpić przez <indicator>.
Współrzędne również uległy wspomnianej modernizacji: nowe szablony potrafią umieścić je w odpowiednim miejscu bez potrzeby tego narzędzia. Istnieją jednak niektóre użycia klasy/id coordinates na stronach użytkowników (wyniki wyszukiwania); widocznie miały ten sam cel co wcześniejszy put-in-header. Do wymiany, zob. poprzedni punkt.
Gadżet jest przystosowany do współpracy z narzędziem meta:WikiMiniAtlas. Zdaje się, że zostało jednak całkowicie wyparte przez minimapy OSM (wyniki wyszukiwania). Do wyrzucenia.
Wspierał również gadżet „Dodawaj link [edytuj] do pierwszej sekcji”, przynajmniej póki nie wykonano tej zmiany w roku 2012. Do wyrzucenia.
Koniec końców jedynym sensownym dzisiaj przeznaczeniem tego gadżetu jest generowanie ikony kłódki na stronach zabezpieczonych. Przeróbkę umieściłem tutaj, proponuję zastąpić nią obecny kod i przenieść pod nazwę MediaWiki:Gadget-padlock-indicators.js z racji ograniczenia jego dotychczasowych funkcji. Wykonałem zrzuty ekranu ukazujące wynik działania owej przeróbki na stronach LOL, Sewastopol oraz Romuald Rajs, na starym i na nowym Wektorze: [21]. Nowy Wektor jeszcze trochę moim zdaniem kuleje (zob. pusty obszar między tytułem strony a pierwszym zdaniem artykułu, szczególnie w przypadku strony ujednoznaczniającej), ale to już inna sprawa. Peter Bowman (dyskusja) 21:08, 4 sie 2021 (CEST)[odpowiedz]
Dzięki! Z punktu widzenia zespołu Web Fundacji (tego, który ogólnie zajmuje się interfejsem, a obecnie robi nowego Wektora) jeśli można zrobić tak, żeby coś używało <indicator>, to lepiej tak zrobić. Co do tego, jak to obecnie wygląda na nowym Wektorze - tak jak pisałem przy stoliku Ogólnym - poprawimy to później, kiedy skończymy przesuwać narzędzia po ekranie, a zajmiemy się tym, jak one wyglądają razem. Powstanie kilka propozycji wyglądu, od bardzo zachowawczych po bardzo "nowoczesne". SGrabarczuk (WMF) (dyskusja) 17:57, 5 sie 2021 (CEST)[odpowiedz]
Tak przy okazji przypomnę o mojej starej propozycji zamiany symboli na takie które ułatwiają precyzyjne określenie typu zabezpieczenia. Ikony i gadżet (działający od 2 lat bezproblemowo) z nich korzystający mojego autorstwa [22] Pozdrawiam --Krzysiek 123456789 (dyskusja) 18:46, 5 sie 2021 (CEST)[odpowiedz]
Wdrożyłem nowy gadżet, jest dostępny w preferencjach z opisem „Kłódka w nagłówku – wyświetla ikonę kłódki () obok tytułu strony, gdy ta jest zabezpieczona przed edycją.” i domyślnie włączony. Starego „Ikony w nagłówku” już tam nie ma, choć ustanowiłem krótki, kilkudniowy okres przejściowy, w którym nadal będzie uruchamiany za kulisami zamiast tego nowego. Zrobiłem tak, ponieważ zwykle nowe, domyślne gadżety stawały się aktywne dla użytkowników niezalogowanych dopiero po upływie paru dni. Po tym czasie wyłączę stary całkowicie i poproszę adminów o scalenie historii kodu źródłowego. Uwaga: jeżeli ktoś z zalogowanych nie chce kłódek i miał poprzedni gadżet wyłączony, powinien sobie również wyłączyć ten nowy.
Pomogłem w czyszczeniu stron użytkowników z przestarzałych elementów. Usunąłem nieużywane klasy put-in-header oraz shortcut_upper z Common.css, Vector.css i Monobook.css. Tak samo postąpiłem z coordinates na Monobooku (Specjalna:Diff/64271214), przyjmując, że jest pozostałością po dawnych czasach, gdy współrzędne były umieszczane w rogu za pomocą CSS lub skryptów. Skutkiem ubocznym będzie przywrócenie wielkości czcionki do normalnych rozmiarów dla współrzędnych w tej skórce. Peter Bowman (dyskusja) 16:06, 10 sie 2021 (CEST)[odpowiedz]
@SGrabarczuk (WMF): zrobione, nowa wersja gadżetu została aktywowana, ikona kłódki wyświetla się teraz wewnątrz .mw-indicators. Zawsze pojawia się po lewej stronie, gdy towarzyszą jej inne elementy (odznaczenia, współrzędne), aby te nie były przesuwane w bok w trakcie ładowania strony. Peter Bowman (dyskusja) 10:11, 12 sie 2021 (CEST)[odpowiedz]
Ojciec Mateusz
Mógłby ktoś bardziej obeznany w definiowaniu szablonów / tabel / przeglądu sezonów spojrzeć do Ojca Mateusza? Na stronie Lista odcinków serialu Ojciec Mateusz jest tytułowa lista, ale przed nią duplikat właściwej strony. Dzisiaj byłem tam po raz pierwszy, więc dużo nie wyjaśnię, ale podejrzewam, że jakiś użytkownik uznał kawałek kodu za zbędny zbiór liter i znaków. Ambiroz (dyskusja) 17:42, 10 sie 2021 (CEST)[odpowiedz]
Cześć! Nie mogę sobie poradzić z umieszczeniem przypisów w uwagach. Chodzi o wstawienie przypisu 5 do uwagi a, oraz o wstawienie przypisu 6 do uwagi b (drugiej) do artykułu, nad którym pracuję w brudnopisie. Będę wdzięczna za pomoc. Hortensja (dyskusja) 21:26, 13 sie 2021 (CEST)[odpowiedz]
Bry. Pojawił się problem zbyt małych obrazków w CW. Nawet na komórkach z milijonem pikseli mało co widać na obrazkach ¯\_(ツ)_/¯. Na PC też zresztą słabo, ale to może już trochę stary jestem 😉. W każdym razie jest rozwiązanie! 🙂
Zasadniczo są dwie opcje moim zdaniem
Zrobić normalną, wbudowaną galerię. Przy czym wtedy na PC będą dwa obrazki obok siebie, a nie z boku.
Użyć specjalnych stylów (formatowania), które na PC ułożą dwa obrazki nad sobą (w pionie), a na komórce ułożą je obok siebie (w poziomie, nad tekstami czywieszowymi).
Pinguję osoby, z którymi rozmawialiśmy o tym: @Msz2001, @Peter Bowman i jeszcze @TORa pozwolę sobie dopingować, bo to częściowo powiązane z artykułem o fladze, który poprawiałeś 🙂.
Tak nawiasem mówiąc dobrze by było w obrazkach dodawać podpisy i/lub alt. Tą proponowaną galeryjkę można również z podpisami robić. Obecne doświadczenie czywiesza poprzez screen reader jest nieco... dziwne (czytane są nazwy plików, zwykle po angielsku). Nux (dyskusja) 11:56, 14 sie 2021 (CEST)[odpowiedz]
@Jckowal jeśli galeria dla według Ciebie w ogóle nie pasuje, to weź pod uwagę, że dla osób z czytnikiem takie właśnie jest obecne doświadczenie. Oba obrazki są dla tych osób na górze i mają jakiś podpis. Nux (dyskusja) 14:04, 14 sie 2021 (CEST)[odpowiedz]
Problem z czytelnością wynika najpewniej z parametru 100px określającego stały rozmiar grafik. Niestety nie widzę w zaproponowanych przez Ciebie rozwiązań żadnego (może poza wydzielonymi galeriami), które pasowałoby do naszej strony głównej. Tak naprawdę trzeba by zmienić układ całej strony głównej. W przeciwnym przypadku będzie to wyglądało tak:
Teraz
Z nowych i ostatnio rozbudowanych artykułów w Wikipedii:
…jaką kaczkę(na zdjęciu) można spotkać na Madagaskarze?
…w kontekście którego konfliktu założono nacjonalistyczną partię Alba?
Wszystkie rozwiązania trzeba przede wszystkim dopasowywać do wielkości rubryki na stronie głównej. Na Twojej stronie owszem, wygląda to znacznie lepiej. No, ale na naszej głównej połowa szerokości zasadniczego ekranu to Czywiesz (po lewej stronie), a druga połowa to rubryka z AnM (po prawej stronie). Trzeba na to spojrzeć szerzej. Odnośnie podpisów – w formie "alt" warto rozważyć (tylko kto je będzie pisał?), jako stały podpis – jestem przeciw. Czasami ta zagadkowość ma zaciekawić czytelnika, a jawny podpis ilustracji zdradzi zagadkę. Szoltys[Re: ]12:44, 14 sie 2021 (CEST)[odpowiedz]
@Szoltys Tak, trzeba dostosować to do szerokości, ale już to zrobiłem w CSS. Można zwęzić sobie okno, żeby to zasymulować... Ale będzie może łatwiej jak zrobię to na stronie. Zmieniłem szerokość mojego demka na z CW z wersji z PC. Możesz sobie teraz zobaczyć jak to z grubsza by wyglądało wchodząc normalnie na Wikipedysta:Nux/czywiesz-fotki-float. Nux (dyskusja) 13:39, 14 sie 2021 (CEST)[odpowiedz]
A gdyby tak wstawiać te same ilustracje podwójnie, lecz jeden zestaw byłby widoczny tylko na desktopie (małe i na prawym marginesie), a drugi tylko na komórce (pełna szerokość ekranu albo jedna obok drugiej, wedle ustaleń)?
<divclass="nomobile">[[Plik:Statue of Christ the Homeless, Regis College, Toronto.JPG|100px|right]]</div><divclass="mobileonly">[[Plik:Statue of Christ the Homeless, Regis College, Toronto.JPG|frameless]]</div>
Ciekawy pomysł, ale to mogłoby niestety powodować, że obrazek będzie się ładował dwa razy. Miałbyś większą swobodę, ale z drugiej strony byłoby to coś o czym trzeba pamiętać. Dlatego raczej łatwiej będzie zrobić CSS. Myślałem, że może będzie jakiś problem z przeskalowaniem obrazka, ale działa to całkiem nieźle 🙂 Nux (dyskusja) 13:58, 14 sie 2021 (CEST)[odpowiedz]
Według mnie, ta opcja flexi-float jest najlepsza, ale (moje zastrzeżenia odnoszą się do wersji mobilnej) obrazki powinny mieć ograniczony rozmiar. Ten pojedynczy zajmuje prawie pół ekranu, mimo że jest w pewnym sensie dodatkiem – główna zawartość CW to jednak pytania. Dodatkowo, jeśli w CW są dwa obrazki, to powinny mieć taką samą wysokość. Dzisiejsza ekspozycja jest na tyle szczególna, że oba są podobnych proporcji. Ale gdyby tam wrzucić jedno poziome i jedno pionowe, to zdarzy się katastrofa. Pozwoliłem sobie nanieść zmiany w CSS-ie (diff). Jeśli pojedynczy obrazek miałby mieć inne ograniczenia wymiarów niż dwa, to zawsze można użyć :only-child.
Jestem przeciwny każdemu z wariantów galerii. Zdjęcia zajmują wtedy za dużo miejsca, a na dodatek marnują przestrzeń po bokach (zamiast dwóch obok siebie mamy jedno pod drugim). Podobnie zresztą thumb, który dodatkowo wypada źle w wąskiej przestrzeni na desktopie.
Co do podpisów – jak najbardziej jestem za alt, ale przeciw jawnym podpisom ilustracji. Byłoby to wbrew charakterowi CzyWiesza, który ma raczej zaintrygować, a nie przekazać konkretną wiadomość. Ewentualnie można by zmienić tekst „(na obrazku)” na „(na pierwszym obrazku)”.
Myślę, że dla spójności takie samo rozwiązanie należy zastosować we wszystkich sekcjach SG, tj. w CzyWieszu, DA, AnM i rocznicach. One też polegają na floatach, które nie działają w wersji mobilnej. Msz2001 (dyskusja) 20:18, 14 sie 2021 (CEST)[odpowiedz]
Wygląda dobrze 🙂. Dobry pomysł z tą zmianą wysokości. To powinno załatwić problem wysokich obrazków. Ładnie się to skaluje nawet jak dorzuciłem wysoki jako trzeci. Tak że na pewno lepsza wersja niż poprzednia, dzięki. Popieram też wrzucenie do wszystkich boksów, bo to pozwoli tak ładnie, optycznie wyrównać wszystko.
To co, wrzucamy? 🙂 @Szoltys teraz wygląda dobrze dla Ciebie? I tak zdaje się potrzebujemy admina ze względu na kaskadowe zabezpieczenia głównej. No i chyba opiekujesz się CW, więc głównie Twojego błogosławieństwa pewnie potrzeba 😉. (aha, CSS może dołączyć przez tag templatestyles bezpośrednio z tego co jest, albo skopiować gdzieś). Nux (dyskusja) 21:37, 14 sie 2021 (CEST)[odpowiedz]
Galerie wyglądają źle, mają mikroskopijne obrazki umieszczone na wielkich białych kwadratach z cienką obwódką. Flexi float wygląda dobrze jeśli obrazek jest jeden lub dwa. Przygotowałem jednak do testów rocznice, w których są 4 pliki, 1 obrazek i 3 utwory muzyczne. Zrobiło się ciasno. Trzeba by to jeszcze dopracować. Przy okazji jest tam też przypadek z trzeba obrazkami.
Natomiast moje ogólne zdanie na temat przeglądarki mobilnej jest negatywne. Nie rozumiem dlaczego wersja standardowa jest tak nieczytelna. Fragmenty treści są pisane wielką czcionką, a inne mniejszą niż kropka z tej dużej. Wydaje mi się to całkowicie losowe i bez żadnych reguł. Chociaż jakieś na pewno są, bo przeładowana strona zawsze wygląda tak samo źle. Paweł Ziemian (dyskusja) 21:35, 14 sie 2021 (CEST)[odpowiedz]
3 grafiki na PC
Wydaje mi się, że 4 grafiki to i tak ciężko wcisnąć, żeby nie rozpychało boksa... 3 grafiki wyglądają spoko w obu wersjach jak dla mnie (zrzut z PC obok).
Można dodać jakiś parametr, który włączy zawijanie grafik automatycznie (zależnie od dostępnego miejsca). Ale można też w dwóch divach zrobić i wtedy jakby na sztywno są dwa wiersze lub dwie kolumny. To działa już teraz (zrzut obok z komórki, a na PC są dwie kolumny wtedy).
W przykładzie rocznic są 3 pliki muzyczne, a one są płaskie jak naleśniki. Musiałbym je wykrywać i pakować w 1 div float:right aby się dobrze układały z sąsiadującym obrazkiem jako 1 element. Chciałbym również zauważyć, że rocznice od lat nie są ręcznie redagowane. Ich dobór wraz z ilustracjami losuje automat „sierotka”, a następnie dokonuje składu do emisji w {{#invoke:Kalendarium|Rocznice}}. Człowiek jedynie napełnia bazę wydarzeń. Paweł Ziemian (dyskusja) 22:28, 14 sie 2021 (CEST)[odpowiedz]
Hm... To nawet nie znałem tego. Tak na oko można przerobić moduł, żeby generował inny kod dla grafik (z tego co widzę chyba nie jest tam na sztywno ustalana szerokość czy coś). Można by pewnie w kodzie policzyć grafiki i podzielić na dwa wiersze... Ale można to zrobić niezależnie od poprawienia CW. Nux (dyskusja) 00:49, 15 sie 2021 (CEST)[odpowiedz]
Ta "siatka" 2x2 wygląda według mnie dobrze w wersji mobilnej – na pewno lepiej niż cztery obok siebie. Jednak na komputerze kolumna tekstu obok mocno się zwęża. Wydaje mi się, że w wersji desktopowej te dwa divy powinny się układać jeden pod drugim. Msz2001 (dyskusja) 13:59, 15 sie 2021 (CEST)[odpowiedz]
Natomiast "płaskość" odtwarzaczy dźwięku może uratować align-items:center na .flexi-float-gallery, które spowoduje, że w wersji mobilnej wszystkie multimedia będą wycentrowane w pionie. Dla testów podzieliłem pliki na dwa divy po dwa elementy i wymusiłem wyśrodkowanie. Gdyby dźwięki były dwa, można byłoby je ułożyć w stos. Zrzuty ekranu z wersji mobilnej są tutaj. Oba rozwiązania można zrobić tak, by na desktopie wyświetlał się stos czterech plików. Msz2001 (dyskusja) 14:17, 15 sie 2021 (CEST)[odpowiedz]
To co, wrzucamy? – bardzo proszę bez pośpiechu. Ekspozycje mamy przygotowane na blisko 3 tygodnie do przodu i długości pytań dostosowane były do grafik ze stałym rozmiarem. Działanie w pośpiechu spowoduje, że część pytań się rozjedzie (w wersji PC, bo w mobilnej to tak czy siak nieuniknione), a od dłuższego czasu staram się, aby rubryka miała mniej więcej tę samą wielkość (w przeciwnym wypadku cały układ strony głównej się psuje i powstaje nieestetyczna luka). Osobiście nadal nie jestem przekonany, czy zmiana jest słuszna. :) Szoltys[Re: ]21:59, 14 sie 2021 (CEST)[odpowiedz]
Nawet dwa problemy są rozwiązane. W wersji mobilnej jest obecnie dziura. W nowej wersji obrazki będą wypełniać prawie całą szerokość.
Drugi problem jest taki, że obrazki mają tylko 100px. W takiej rozdzielczości nic nie widać. No i niestety zoomowanie nic nie daje. W nowej wersji obrazki mają 400px i są przeskalowane w dół. Dzięki temu o wiele lepiej widać co jest na obrazkach. To jakieś 10-15 razy więcej szczegółów.
BTW. Tą dziurę też da się rozwiązać. Chyba z rok temu robiłem projekt strony głównej, który to rozwiązywał... Ale chyba nie ma sensu zajmować się wszystkim na raz. Ale jakby co mogę poszukać ten projekt. Nux (dyskusja) 00:39, 15 sie 2021 (CEST)[odpowiedz]
Ja chyba zaczynam rozumieć o co chodzi. Chcemy zwiększyć obrazki ze 100px na 120px, aby były trochę większe w wersjach mobilnych. Ponadto chcemy domyślnie serwować te obrazki w wyższej rozdzielczości niż deklarowana szerokość (obecnie 100px, proponowane 120px) aby zoomowanie strony pokazywało więcej szczegółów. Przy okazji dochodzi do tego zmieniony układ obrazków dla wąskich ekranów. Trochę się pobawiłem i wyniki mam tutaj oraz podgląd jako skórka vector, minerva, timeless i monobook. Obecnie serwuję obrazki w ich naturalnej rozdzielczości. Oznacza to, że im większe zdjęcie tym wolniej się ładuje i to widać. Paweł Ziemian (dyskusja) 21:41, 15 sie 2021 (CEST)[odpowiedz]
Fb-wyniki-kluby
W szablonach związanych z meczami piłkarskimi mecze wygrane przez gospodarzy mają jasnozielony kolor, a w szablonie Fb-wyniki-kluby mają niebieski kolor. Czy mógłby ktoś ujednolicić tę kolorystykę i podmienić w szablonie Fb-wyniki-kluby kolor tła meczów wygranych przez gospodarzy na jasnozielony? W szablonach Mecz piłkarski zwinięty i Mecz piłkarski POL zwinięty jest to dokładniej kolor #e8ffd8, a w szablonie Fb r #ceffcd. ProDM (dyskusja) 23:58, 14 sie 2021 (CEST)[odpowiedz]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
You can add language links in the sidebar in the new Vector skin again. You do this by connecting the page to a Wikidata item. The new Vector skin has moved the language links but the new language selector cannot add language links yet. [23]
Problems
There was a problem on wikis which use the Translate extension. Translations were not updated or were replaced with the English text. The problems have been fixed. [24][25][26]
Changes later this week
A revision tag will soon be added to edits that add links to disambiguation pages. This is because these links are usually added by accident. The tag will allow editors to easily find the broken links and fix them. If your wiki does not like this feature, it can be hidden. [27]
Would you like to help improve the information about tools? Would you like to attend or help organize a small virtual meetup for your community to discuss the list of tools? Please get in touch on the Toolhub Quality Signal Sessions talk page. We are also looking for feedback from tool maintainers on some specific questions.
In the past, edits to any page in your user talk space ignored your mute list, e.g. sub-pages. Starting this week, this is only true for edits to your talk page. [28]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 August. It will be on non-Wikipedia wikis and some Wikipedias from 18 August. It will be on all wikis from 19 August (calendar).
Za. Czy bot wyszukuje duplikaty po stronie HTML czy dokonuje jakieś przekształcenia normalizujące wikikod aby zwiększyć prawdopodobieństwo odnalezienia duplikatów? Na przykład redukcja zbędnych odstępów lub przekształcenie szablonów cytowania do jakiejś formy kanonicznej? Wiem, jest kod, ale łatwiej zapytać niż analizować. Paweł Ziemian (dyskusja) 19:16, 10 lip 2021 (CEST)
Przeciw Najpierw proszę przedyskutować w szerszym gronie zgodę na takie działanie, a dopiero potem pytać o bota. ptjackyll (zostaw wiadomość) 20:16, 24 lip 2021 (CEST)
ponieważ w sumie linkujemy do różnojęzycznych Wikipedii? Paweł Ziemian (dyskusja) 22:10, 3 sie 2021 (CEST)
Sławobóg (dyskusja) 22:15, 3 sie 2021 (CEST)
– nie kojarzy się z wyborem języka, jest niewyraźna; ikona i tak nie jest linkiem do Wikidanych (w przeciwieństwie do „gołego” szablonu)
– podobnie jak wyżej, lecz trochę wyraźniejsza wersja
– wskazuje na Wikipedię, ale może konfundować czytelnika; napotkane gdziekolwiek w internecie oznaczałoby „przeczytaj na Wikipedii”, a tutaj?
– kula ziemska raczej mogłaby się kojarzyć z wyborem języka, ale ta jest niewyraźna w małym rozmiarze
– być może ta ikonka? Super wyraźna nie jest, ale wydaje mi się, że mogłaby być (ale jest na licencji CC-BY, więc gdzieś będę musiał zmieścić link do Commons).
– ikonka występuje już w innych miejscach interfejsu Wikipedii dla oznaczania wyboru języka (dopisane po sugestii poniżej Msz2001 (dyskusja) 20:08, 4 sie 2021 (CEST); podmieniłem na wariant niebieski – według sugestii Sławobóg, że sugeruje to klikalność Msz2001 (dyskusja) 20:39, 4 sie 2021 (CEST))
– pozwoliłem sobie dodać wersję z kolorem klikalnego linku
– ta wersja teoretycznie bardziej widoczna Sławobóg (dyskusja) 17:16, 7 sie 2021 (CEST)
.svg){kind=icon}
. Msz2001 (dyskusja) 10:46, 4 sie 2021 (CEST)
. Ta ikona z wersji mobilnej ładnie się skaluje, i utrzymamy konwencję aby ta sama ikona oznaczała to samo o co walczy dużo osób np. tutaj. Pzdr. Krzysiek 123456789 (dyskusja) 19:48, 4 sie 2021 (CEST)
. Przy okazji przygotowałem wersję panelu przyjazną użytkownikom smartfonów (wygląda tak: [20]). 
) obok tytułu strony, gdy ta jest zabezpieczona przed edycją.” i domyślnie włączony. Starego „Ikony w nagłówku” już tam nie ma, choć ustanowiłem krótki, kilkudniowy okres przejściowy, w którym nadal będzie uruchamiany za kulisami zamiast tego nowego. Zrobiłem tak, ponieważ zwykle nowe, domyślne gadżety stawały się aktywne dla użytkowników niezalogowanych dopiero po upływie paru dni. Po tym czasie wyłączę stary całkowicie i poproszę adminów o scalenie historii kodu źródłowego. Uwaga: jeżeli ktoś z zalogowanych nie chce kłódek i miał poprzedni gadżet wyłączony, powinien sobie również wyłączyć ten nowy.
Załatwione? XaxeLoled ⸤ AmA ⸣ 18:14, 13 sie 2021 (CEST)
_(cropped).jpg)
The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 August. It will be on non-Wikipedia wikis and some Wikipedias from 18 August. It will be on all wikis from 19 August (calendar).
![[11]](https://i.imgur.com/NIMKrrX.png){kind=link}
