Wikipedia:Kawiarenka/Kwestie techniczne

- Błędy w oprogramowaniu MediaWiki należy zgłaszać w serwisie Phabricator (użyj formularza). Możesz też zapoznać się ze stroną Pomoc:Błędy techniczne.
- Problemy z infoboksami należy zgłaszać na stronę Dyskusja wikiprojektu:Infoboksy.
- Spis aktualnie przeprowadzanych zmian technicznych i osób kontaktowych jest dostępny na stronie Wikimedia Product.
Obserwuj stolik • Archiwum stolika • Wszystkie stoliki • Skróty: WP:KT, WP:BAR:KT, WP:TECH
Ankieta: Proponowany kierunek dla Community Wishlist (życzenia społeczności)
[edytuj | edytuj kod]Zapraszamy do wyrażenia swojej opinii na temat nowego kierunku dla Community Wishlist zaproponowanego przez społeczność. [chodzi o coroczne Community Wishlist, czyli listy życzeń społeczności]. Dziękujemy! MediaWiki message delivery (dyskusja) 05:07, 29 maj 2026 (CEST)
Od Femke:
W ostatnich dniach pojawiło się wiele propozycji dotyczących tego, jak powinien wyglądać proces Wishlisty. Członkowie społeczności są zgodni, że proces powinien zostać wzmocniony, a nie osłabiony. Selena Deckelmann wskazała, że jest otwarta na część zmian sugerowanych przez społeczność, i zasugerowała, że fundacja mogłaby w ciągu 3 miesięcy przygotować nowy plan we współpracy z meta:PTAC.
Po pierwsze, uważam, że ważne jest przyjęcie jasnej propozycji społeczności. Bazując na propozycjach Sohom Datta, Novem Linguae i mojej własnej, proponuję, aby społeczność poparła następujący kierunek działań:
- Przywrócenie CommTech. Chcemy zespołu dobrze znającego normy społeczności, utrzymującego krytyczne dla społeczności narzędzia, organizującego wishathony i pracującego nad mniejszymi życzeniami. Zapobiegnie to również sytuacji, w której życzenia pozostają niezrealizowane, ponieważ nie należą do zakresu odpowiedzialności żadnego konkretnego zespołu.
- [Zobowiązania innych zespołów] Inne zespoły powinny otrzymać obowiązkową pulę życzeń do realizacji, niezależną od zobowiązań wynikających z rocznego planu. Oznacza to, że zespoły muszą realizować określoną liczbę życzeń i nie mogą być zobowiązywane przez kierownictwo do pracy wyłącznie nad życzeniami zgodnymi z rocznym planem.
- Przywrócenie corocznej ankiety. Skoro życzenia byłyby realizowane przez różne zespoły w ramach WMF, główny problem starej corocznej listy życzeń – nieproporcjonalnie duża ilość czasu poświęcana na zbieranie życzeń zamiast ich realizacji – zostałby rozwiązany. Dobrze nagłośniona coroczna ankieta integruje różne społeczności edytorów i zapobiega przekształceniu listy życzeń w stale rosnący backlog.
- Indywidualne rankingi życzeń. Obszary tematyczne („focus areas”) powinny zostać całkowicie porzucone.
- Proces priorytetyzacji powinien w większości należeć do społeczności. Samo formułowanie życzeń i głosowanie nie powinno być jedynymi zadaniami społeczności w listach życzeń. Wykonalność powinni oceniać inżynierowie mający doświadczenie w rozwoju narzędzi dla społeczności, tacy jak pracownicy Community Tech i deweloperzy-wolontariusze. Społeczności powinny być również odpowiedzialne za dopilnowanie, aby mniej reprezentowane społeczności, takie jak Commons, które historycznie miały stosunkowo niską frekwencję w procesie listy życzeń, były priorytetyzowane zgodnie ze swoimi potrzebami, a nie tylko wg frekwencji w głosowaniach.
W geście solidarności, —Femke (dyskusja) 🐦 08:34, 25 maja 2026 (UTC)
Formatowanie i tłumaczenie wstępu do ankiety: Nux (dyskusja) 12:29, 29 maj 2026 (CEST)
PS: Komentarze poparcia (support) oraz sprzeciwu (oppose) możecie wpisywać na: meta:Talk:Community Wishlist#Proposed direction for Wishlist.
Czy kopiuj wklej z nazwą artykułu wymaga łączenia historii?
[edytuj | edytuj kod]Chodzi o historię: zmieniona przez Tarkowski. Tekst był skopiowany z innej strony (nazwa strony jest w opisie zmian). Czy wtedy wymagane jest mergowanie historii? Tak jak opisane Pomoc:Łączenie historii stron. Czy jest to coś, co trzeba zgłaszać na stronie Wikipedia:Prośby do administratorów?
Drugi problem to to, że Państwowe Nieruchomości Ziemskie (PRL) (który jest w opisie zmian) przekierowuje na stronę domową pana Bogdana. Pan Bogdan już nie używa strony domowej do pisania artykułów, używa do tego szablonu: {{Magiczny Brudnopis}}, ale zmiany magą w każdej chwili zniknąć ze strony domowej. @Jcubic (dyskusja) 01:06, 31 maj 2026 (CEST)
- Moim zdaniem takie kopiowanie to jest WP:NPA na tym samym poziomie jak wtedy gdy ktoś wrzuca cudze zdjęcie z opisem „źródło: Wikipedia”. Właściwie do pewnego stopnia to wręcz przywłaszczenie cudzej pracy. Powinno się podać autorów w opisie zmian lub przynajmniej w dyskusji strony. Można też dodać link do historii w opisie. Można też połączyć historię, chociaż to może być trochę overkill czasami. Tutaj to szczerze powiedziawszy nie wiem co @Tarkowski próbował zrobić, bo to przekierowanie też nie jest prawidłowe. Nux (dyskusja) 13:32, 31 maj 2026 (CEST)
- No @Tarkowski pewnie chciał dobrze, ale nie widział, jak to się powinno zrobić. Ja w sumie też nie wiem, co teraz można zrobić, aby to poprawić.
- Czy wystarczy dodać pana Bogdana w dyskusji jako autora? Wydaje mi się, że właśnie powinno być to w historii, gdzie jest lista autorów.
- A czy admin może zmienić opis? Może wystarczy dodać autora w opisie zmian. @Jcubic (dyskusja) 15:21, 31 maj 2026 (CEST)
- Znaczy tu nie jestem pewien czy jeden artykuł w pełni zastępuje drugi.
- Mamy kilka szablonów do integrowania artykułów:
- {{Integruj}} (sugestia połączenia)
- {{Integrowanie}} (w trakcie łączenia)
- {{Zintegrowany}} (po połączeniu)
- {{Połącz historie}} (po połączeniu, gdy trzeba jeszcze zintegrować historię)
- Jeśli jeden w pełni zastępuje drugi, to wtedy faktycznie można by połączyć historię (ten ostatni szablon). Tutaj powinno dać się ładnie połączyć, bo historie się nie przeplatają nadmiernie (artykuły nie były rozwijane równolegle, jedynie edycja Alana mogłaby zostać zagubiona). Tylko, że merytorycznie się nie znam i nie wiem dlaczego Bogdan użył tytułu Państwowe Nieruchomości Ziemskie (PRL) zamiast zmienić Państwowe Nieruchomości Ziemskie? Nux (dyskusja) 15:37, 31 maj 2026 (CEST)
- Witajcie @Nux i @Jcubic i przepraszam że tak namieszałem! Widziałem że te dwa artykuły istniały dość długo z propozycją, by je połączyć, myślałem że to prosta sprawa. Nauka jest taka by może na tym etapie redagowania nie robić takich większych edycyjnych rzeczy.
- Natomiast do co uwagi @Nux o WP:NPA, to przepraszam ale sugerowanie że edytowanie w dobrej wierze to naruszenie praw kogoś, kto zgadza się wszystko udostępniać na wolnych licencjach to trochę przesada - prawo autorskie jest dla ludzi. Natomiast dziękuję za rady jak to zrobić bardziej prawidłowo. Tarkowski (dyskusja) 09:44, 1 cze 2026 (CEST)
- @Tarkowski WP:NPA nie musi być celowym działaniem. Bardzo podoba mi się zasada w Wikidanych: Wikidata:Assume good faith. @Jcubic (dyskusja) 10:21, 1 cze 2026 (CEST)
- @Tarkowski: nie będę wchodził w meritum, a jedynie sprawy formalne. Możesz wkleić treść jednego hasła do drugiego, w całości lub w części, zastępując obecną treść w całości lub zostawiając część. Aby nie było zarzutów NPA, najlepiej zrobić tak:
- 1. Warunkiem koniecznym jest podanie w opisie edycji docelowego hasła tekstu w rodzaju „wklejam treść z hasła [[Państwowe Nieruchomości Ziemskie (PRL)]]”. Kluczowe jest, aby podać link do hasła źródłowego.
- 2. Warunkiem koniecznym jest, aby hasło źródłowe zmienić na przekierowanie, a nie kasować je. Dzięki temu pozostaje cała historia jego edycji.
- 3. Pożądane jest, aby zmiana hasła źródłowego na przekierowanie miała opis edycji w rodzaju „dubel – przenoszę treść do hasła [[Państwowe Nieruchomości Ziemskie]], a to zmieniam na przekierowanie”.
- 4. Wreszcie na stronie dyskusji hasła docelowego dobrze jest wstawić odpowiednio wypełniony szablon {{Zintegrowany}}, najlepiej ze wskazaniem – w polu „wersja” - numeru wersji hasła, z której treść była kopiowana (teraz byłoby to „wersja = 79884592”)
- Żadnego łączenia historii nie trzeba – i nie należy – wówczas robić (łączenie historii to masakra, jeśli ktoś później chce coś w takiej historii znaleźć), pod warunkiem że hasło źródłowe pozostaje jako przekierowanie. Michał Ski (dyskusja) 12:06, 1 cze 2026 (CEST)
- @Tarkowski „WP:NPA, to przepraszam ale sugerowanie że edytowanie w dobrej wierze to naruszenie praw kogoś, kto zgadza się wszystko udostępniać na wolnych licencjach to trochę przesada”. Zakładałem, że nie zrobiłeś tego specjalnie. Natomiast wolnych licencji nie należy mylić z wolną amerykanką. Nadal istnieją zasady używania tego tekstu (opisanego zresztą w licencji). Jeśli sami tego nie przestrzegamy, to jak możemy wymagać tego od innych. Link o którym pisze Michał, to jest jakieś minimum. W zasadzie zgodnie z licencją lepiej byłoby podać autorów.
- Hasło zaraz zintegruję. Tutaj akurat jest to możliwe, chociaż tak jak pisze Michał, czasem może to być bardzo karkołomne. Nux (dyskusja) 14:42, 1 cze 2026 (CEST)
- Dziękuję za wyjaśnienie! I jeszcze raz przepraszam za zamieszanie. Jest to też dla mnie lekcja o tym jak przestrzegać wolnego licencjonowania "na wiki" - mam doświadczenie z wolnymi licencjami poza wiki. Tarkowski (dyskusja) 15:17, 1 cze 2026 (CEST)
Wikipedyści(tki), którzy(e) wrzucaja zdjecia na Commons
[edytuj | edytuj kod]Chciałem stworzyć Wikiprojekt:Fotografia miał by dwa cele robienie zdjęć i dodawanie/poprawianie haseł zwiazanych z fotografią (to drugie opjonalnie).
Chciałem zrezurekować stronę Wikipedia:Zamówienia na obrazki.
Potrzebuje znaleźć osoby, które regularnie wrzucaja zdjecia na Commons i maja konto w Wikipedii założone w pl wiki.
Da sie to jakoś wyciągnąć?
Na pl wiki jest kilka osob w wikimedia:Wypożyczalnia są też userboxy foto i fotograf, wiec jest kogo pingnąć, ale fajnie by było znaleźć sktywnych fotografów. @Jcubic (dyskusja) 10:00, 31 maj 2026 (CEST)
- Z tego co kojarzę, aktywnymi fotografami są @Wojciech Pędzich i @Jacek Halicki. ptjackyll (zostaw wiadomość) 10:35, 31 maj 2026 (CEST)
- Domyślam się, że jest ich jednak więcej. Tylko problem, aby ich znaleźć. @Jcubic (dyskusja) 10:46, 31 maj 2026 (CEST)
- Na stronie Wikiprojektu jest lista, choć może być mocno nieaktualna, zwłaszcza, że jest tam osoba która już nie żyje... ptjackyll (zostaw wiadomość) 10:52, 31 maj 2026 (CEST)
- Dzięki za link, totalnie zapominałem, że jest już taki projekt, tylko jest martwy. @Jcubic (dyskusja) 10:57, 31 maj 2026 (CEST)
- Wydaje mi się, że wyszukanie osób pokazałoby zupełnie inną listę. @Jcubic (dyskusja) 11:00, 31 maj 2026 (CEST)
- Domyślam się, że jest ich jednak więcej. Tylko problem, aby ich znaleźć. @Jcubic (dyskusja) 10:46, 31 maj 2026 (CEST)
- Zajrzyj na WP:PInM i sprawdź autorów zdjęć. A projekt powstał 12 lat temu. ~malarz pl PISZ 11:09, 31 maj 2026 (CEST)
- Dzięki dobry pomysł. Tak projekt powstał dawno temu, nawet jestem na liście, ale jest martwy. @Jcubic (dyskusja) 11:33, 31 maj 2026 (CEST)
- Tylko dużo zdjęć (z medalem w 2026) zostało wrzuconych do Commons wiele lat temu. @Jcubic (dyskusja) 11:43, 31 maj 2026 (CEST)
- Jeśli chcesz mieć pełną listę, to wyszukaj np. w Quarry konta, który wrzuciły więcej niż X zdjęć w ostatnich dwóch latach (więcej niż X nowych stron w File z rozszerzeniem jpg). Zestaw to sobie z kategorią: https://commons.wikimedia.org/wiki/Category:User_pl-N. Z kategorią będziesz miał prościej, bo masz wszystko w ramach jednej bazy i boty powinny być pominięte. Dodatkowo myślę, że można przyjąć, że ludzie nie posiadający babelek nie są zainteresowani szerszymi działami wspólnymi (i np. przesłali tylko parę fotek na konkurs Wiki lubi zabytki). Nux (dyskusja) 13:18, 31 maj 2026 (CEST)
- O, to to. Wyszła mi taka grupa użytkowników, którzy są aktywni i tu i tam. X było bardzo trochę niestałe w tym wybieraniu :D
- Pibwl → wkład w Commons
- Piotrus → wkład w Commons
- Nova → wkład w Commons
- Pko → wkład w Commons
- Polimerek → wkład w Commons
- Abraham → wkład w Commons
- Kroton → wkład w Commons
- Jakubhal → wkład w Commons
- Topory → wkład w Commons
- Klapi → wkład w Commons
- Selso → wkład w Commons
- Botev → wkład w Commons
niezainteresowany - Rdrozd → wkład w Commons
- Pudelek → wkład w Commons
- Kenraiz → wkład w Commons
- Zwiadowca21 → wkład w Commons
- Salicyna → wkład w Commons
- R.komorowski → wkład w Commons
- Crusier → wkład w Commons
- Delta 51 → wkład w Commons
- Grzexs → wkład w Commons
- Leszek Jańczuk → wkład w Commons
- Athantor → wkład w Commons
- Fczarnowski → wkład w Commons
- Lahcim n → wkład w Commons
- Zorro2212 → wkład w Commons
- Lowdown → wkład w Commons
- Kgbo → wkład w Commons
- Ptjackyll → wkład w Commons
- Gordon2007 → wkład w Commons
- Zala → wkład w Commons
- Czupirek → wkład w Commons
- Jacek Halicki → wkład w Commons
- Szczecinolog → wkład w Commons
- MacQtosh → wkład w Commons
- Cybularny → wkład w Commons
- Kapitel → wkład w Commons
- Serecki → wkład w Commons
- Waraciła → wkład w Commons
- Wlodek k1 → wkład w Commons
- W2k2 → wkład w Commons
- Lord Ya → wkład w Commons
- Krzysztof J1 → wkład w Commons
- Rail01 → wkład w Commons
- Jaqbpl → wkład w Commons
- ElectroTiel → wkład w Commons
- @Jcubic, możesz grupę poszerzać ;) Hedger z Castleton (dyskusja) 13:38, 31 maj 2026 (CEST)
- Ze strzelaczy koncertowych, na ESC był ze mną w tym roku @Itokyl, Pol'and Rocka fotografował @KrzysztofPoplawski. Wojciech Pędzich Dyskusja 13:45, 31 maj 2026 (CEST)
- O, nawet mnie wypluło. :) Ale to głównie przez zdjęcia ze Wzlotu. ptjackyll (zostaw wiadomość) 13:46, 31 maj 2026 (CEST)
- Dodałem do tabelki w projekcie {{aktywność}}. Wychodzi że jest nas tak z 10 osób. xD Zwiadowca21 14:13, 31 maj 2026 (CEST) Alternatywnie można wybrać losową kategorię, np commons:Category:Poland photographs taken on 2026-05-31 i a nuż się trafi. Zwiadowca21 14:23, 31 maj 2026 (CEST)
- Jak nie ma np. mnie ani Bostona (a musi być tego więcej) to lista o kant :D Emptywords (dyskusja) 14:49, 31 maj 2026 (CEST)
- </facepalm> @Emptywords, @Boston9, byliście na liście, ale przypadkowo część listy wyciąłem przy formatowaniu. Stara myszka albo, co bardziej prawdopodobne, stara ręka :/ Ale zapiszcie się chłopaki :D Hedger z Castleton (dyskusja) 13:50, 1 cze 2026 (CEST)
- @Hedger z Castleton, @Nux Dzięki.
- Jak ktoś z powyższych osób z listy, chce zabrać udział w dyskusji, nad wikiprojektem Fotografia, to zachęcam do dyskusji na stronie: Co dalej z projektem. Możecie komentować swoje pomysły i potrzeby. Będę pewnie jeszcze raz pingował wszystkich, jak znajdziemy lepszy sposób, aby znaleźć aktywnych(e) fotografów(ki).
- Jak ktoś dostanie powiadomienie, a nie jest zainteresowany, proszę o dopisanie szablonu {{przeciw|niezainteresowany}} przy swoim nicku. @Jcubic (dyskusja) 15:06, 31 maj 2026 (CEST)
- Ja wrzucam sporo fotek (dotąd 81 tys.), ale jestem monotematyczny – specjalizuję się w dokumentowaniu roślin (makro, portrety, krajobrazowe z rośliną w siedlisku na pierwszym planie, ostatnio też focus stacking). Ponieważ pracuję w terenie sporadycznie dorzucam jakieś jezioro, czy rzekę. Ludzie, zabytki i inne takie mnie nie interesują. Dopiszę się, by podglądać projekt, ale raczej będę pasywnym obserwatorem. Kenraiz .ꓘ (dyskusja) 16:06, 31 maj 2026 (CEST)
- Hej
- Tak, wrzucam zdjęcia na Commons, głównie w tematyce kolejowej. Jeśli jest coś z tego zakresu, co wymaga fotografii i da się zrealizować w Warszawie albo okolicach to bardzo chętnie pomogę ^^
— rail (dyskusja | edycje) 🏳️🌈 🏳️⚧️ 16:08, 31 maj 2026 (CEST) - Hej, dzięki za opingowanie. Wrzucam zdjęcia przeważnie okołocelebryckie, ale głównie „z doskoku”, jak np. akurat jestem na jakiejś imprezie show-biznesowej. Na co dzień jednak nie mam ani odpowiedniego sprzętu, ani umiejętności, by mocniej wesprzeć projekt, tak więc niestety muszę odmówić, ale dziękuję za zainteresowanie i trzymam kciuki za rozwój projektu :) Serecki (dyskusja) 12:03, 1 cze 2026 (CEST)
- @Serecki, zdjęć aktorów też brakuje, więc wiesz, każdy obiektyw się przyda ;) Hedger z Castleton (dyskusja) 13:50, 1 cze 2026 (CEST)
- Jasna sprawa, dlatego jak tylko będę miał okazję robić zdjęcia aktorskie, to oczywiście będę je robił, ku chwale Wikimedii Commons, ale po prostu chcę uniknąć wszelkich deklaracji, że "tak, tak, na pewno będę regularnie chodził na konferencje, premiery itd.", bo wiem, że nie będę miał ku temu sposobności. Serecki (dyskusja) 14:01, 1 cze 2026 (CEST)
- @Serecki Jeśli chodzi o aktorów i innych celebrytów. To można zrobić listę osób, którym brakuje zdjęcia w projekcie jako podstronę.
- Coś w stylu Wikipedia:Wikipedia też jest kobietą/Brakujące/malarki.
- Stowarzyszenie jest też w stanie pomagać w zdobywaniu akredytacji i można uzyskać legitymacje, która może też pomóc w uzyskaniu dostępu (chociaż to bardziej symboliczna legitymacja).
- Jak masz jakiś pomysł, na działania, to możesz go dodać do dyskusji projektu. Każda inicjatywa jest wartościowa, a udział w projekcie nie oznacza, że musisz brać udział we wszystkim, co projekt robi. Tak jak ze wszystkim, każdy rozwija Wikipedię w sposób, jaki uważa za stosowny. Nic na siłę. @Jcubic (dyskusja) 17:08, 1 cze 2026 (CEST)
- @Serecki, zdjęć aktorów też brakuje, więc wiesz, każdy obiektyw się przyda ;) Hedger z Castleton (dyskusja) 13:50, 1 cze 2026 (CEST)
- A ja wrzucam zdjęcia różniste, które autokratycznie uważam za warte publikacji 😀 (ale nie fotografuję ludzi). Nie bardzo wiem, w czym wikiprojekt Fotografia mógłby mi pomóc. To nie jest coś dla ludzi bez większej ilości wolnego czasu. Grzexs (dyskusja) 17:23, 4 cze 2026 (CEST)
- Podczepiam się, lubię fotografować, zdarza mi się robić zdjęcie z Commons w głowie, potem przeglądam archiwa i te zdjęcia wrzucam. Byłbym zainteresowany uczestnictwem. ElectroTiel | łiir! 10:09, 21 cze 2026 (CEST)
- @ElectroTiel możesz się dopisać do listy. @Jcubic (dyskusja) 10:15, 21 cze 2026 (CEST)
- O, to to. Wyszła mi taka grupa użytkowników, którzy są aktywni i tu i tam. X było bardzo trochę niestałe w tym wybieraniu :D
- Aczkolwiek przekategoryzowałem jakieś 120 tysięcy plików, to mój wrzut na Commons jest skromny (mniej niż 500 plików), z czego większość to nie zdjęcia a skany i przerobione grafiki. Stąd może moja perspektywa jest skrzywiona, ale IMHO, zdjęć nam mniej brakuje, a ilustracji tak ;) Map, grafik objaśniających itp. Popatrzcie, że w dyskusjach na ilustracjach na medal nie-zdjęcia pojawiają się sporadycznie, a dyskusje nad zdjęciami z reguły odnoszą się do tego, czy sześćdziesiątypiąty piksel od lewej nie ma aby krzywego balansu pomarańczu, a sporadycznie - czy na zdjęciu widać czytelnie to, co ma przedstawiać. W związku z powyższym: skoro próbujemy reaktywować wikiprojekty, to a) jak się ma Wikiprojekt:Ilustrowanie b) czy nie warto uczynić go nadrzędnym, zintegrować z nim nowo-ożywiany Wikiprojekt: Fotografia i zgromadzić wszelkie wysiłki ilustracyjne w jednym miejscu? Jakiekolwiek by nie były? --Felis domestica (dyskusja) 23:31, 1 cze 2026 (CEST)
- Masz rację co do większych deficytów ilustracji i map, ale nie sądzę by edytorzy-fotografowie mogli tu pomóc jakoś bardziej niżeli uczestnicy innych wikiprojektów. Kenraiz .ꓘ (dyskusja) 00:04, 2 cze 2026 (CEST)
- Zgadzam się, to są dwa różne projekty. Jeśli jesteś zainteresowany reaktywacją Wikiprojekt:Ilustrowanie to śmiało, ale łączenie tych dwóch rzeczy moim zdaniem jest bez sensu. Są to zazębiające się projekty, ale żadnej z nich nie jest podzbiorem drugiego.
- Ja osobiście mógłbym dołączyć do obu (mógłbym się zająć ilustrowaniem haseł z matematyki). Więc jak chcesz reaktywować Ilustrowanie, to daj znać. @Jcubic (dyskusja) 00:21, 2 cze 2026 (CEST)
- A może właśnie powinien być podzbiorem? Jak sądzę, celem nomen omen Wikiprojektu Fotografia nie jest tworzenie onlajnowego kółka fotograficznego, ale zapewnianie fotograficznych materiałów do ilustrowania Wikipedii. Nie sugeruję, że fotografowie mają rzucić aparaty i zacząć rysować schematy. Sugeruję, żeby zmniejszyć liczbę Wikiprojektobytów, skupiając wysiłki pod szyldem bardziej ogólnym --Felis domestica (dyskusja) 02:45, 2 cze 2026 (CEST)
- Nie zgodzę się. Główny cel to nie dodawanie zdjęć do Wikipedii, tylko do Commons. Tylko nieliczne zdjęcia dokumentują artykuły w Wikipedii. Wydaje mi się, że projekt Fotografia to zbiór osób, które interesują się fotografią, wrzucają zdjęcia na Commons i poprawiają hasła związane z fotografią. Nie ma tutaj nigdzie nic napisanego, że jest to głównie dodanie zdjęć do artykułów. Tym zajmuje się projekt Ilustrowanie. Oczywiście będzie część wspólna, czyli zamawianie zdjęć pod artykuły, czy dodawanie zdjęć do konkretnych artykułów. @Jcubic (dyskusja) 03:24, 2 cze 2026 (CEST)
- @Felis domestica można byłoby równolegle odświeżyć, uaktualnić wikiprojekt ilustrowanie, może z czasem nawet wikiprojekt grafik wektorowych, do tego można by włączyć problem z poprawianiem wykresów, które parę lat temu się posypały itd. Osobiście byłoby mi bliżej do wykorzystywania ilustracji, może nawet do wypracowania jakiegoś standardu ilustrowania artykułów, bo niekiedy to jest dalekie od optimum. Tylko trzeba też pewnej liczby zainteresowanych osób. Jeśli znalazłbyś czas, to też w to wchodzę (czas u mnie też nie z gumy, ale próbować trzeba ;). @Jcubic, dodaj proszę do celów wikiprojektu fotografia opisywanie artykułów związanych z fotografią, bo na razie tego nie ma. Wtedy wyraźniej to będzie wychodzić poza zakres ilustrowania. A za inicjatywę czapki z głów :) Hedger z Castleton (dyskusja) 12:01, 2 cze 2026 (CEST)
- Nie będę angażował w przedsięwzięcie, które jest przeciwieństwem tego co proponowałem - czyli likwidacji nadmiaru martwawych Wikiprojektów i kumulację wysiłków w jednym miejscu, żeby był do nich wzajem dobry dostęp. Rozpraszanie nikłych sił na sztuczną reaktywację - IMHO bez sensu. A tym bardziej skoro, jak się dowiedzieliśmy wyżej, podejmowane teraz wysiłki nie mają służyć podnoszeniu jakości Wikipedii --Felis domestica (dyskusja) 17:32, 4 cze 2026 (CEST)
- A może właśnie powinien być podzbiorem? Jak sądzę, celem nomen omen Wikiprojektu Fotografia nie jest tworzenie onlajnowego kółka fotograficznego, ale zapewnianie fotograficznych materiałów do ilustrowania Wikipedii. Nie sugeruję, że fotografowie mają rzucić aparaty i zacząć rysować schematy. Sugeruję, żeby zmniejszyć liczbę Wikiprojektobytów, skupiając wysiłki pod szyldem bardziej ogólnym --Felis domestica (dyskusja) 02:45, 2 cze 2026 (CEST)
Odchudzenie Szablon:Strona użytkownika
[edytuj | edytuj kod]Ten szablon w założeniu miał służyć do informowania użytkowników mirrorów Wikipedii, że... cóż, są na mirrorze i znaleźli na nim stronę użytkownika, a ten najpewniej nic nie ma wspólnego z mirrorem. Na stronie śp. User:PawełMM jest box o podobnej funkcji, aczkolwiek postanowiłem go zmodyfikować:
| To jest strona użytkownika Wikipedii.
Jeśli znalazłeś tę stronę w innym serwisie, oznacza to, że jest to mirror Wikipedii. Strona ta może być nieaktualna, a użytkownik ten najprawdopodobniej nie jest w żaden sposób związany z oglądanym przez ciebie serwisem, a jedynie z Wikipedią. Oryginał tej strony znajduje się pod adresem https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie techniczne. |
Dajcie znać, co o takim pomyśle sądzicie. ElectroTiel | łiir! 21:44, 3 cze 2026 (CEST)
- @ElectroTiel IMHO, to jest szablon, który Wikipedyści mają na swoich stronach. Byłbym ostrożny z edycją i wprowadzaniem zmian do cudzych stron domowych. Sam masz napisane, aby nie edytować twojej strony, a chcesz edytować wszystkich, którzy używają tego szablonu.
- PS: twojej nazwy użytkownika nie widać w trybie ciemnym. @Jcubic (dyskusja) 02:04, 4 cze 2026 (CEST)
- Sam używam trybu ciemnego - fakt, jest mniej czytelne niż na białym, ale da się zobaczyć. W sumie, poprawię. ElectroTiel | łiir! 13:36, 4 cze 2026 (CEST)
- Jak używasz gadżetu to może jest widoczne. W domyślnym trybie ciemnym jest mało widzoczne, a w podpisie jest prawie niewidzialne. Żeby przeczytać trzeba zaznaczyć tekst. @Jcubic (dyskusja) 20:10, 4 cze 2026 (CEST)
- @Jcubic Poprawiłem czytelność podpisu, w trybie ciemnym z gadżetu (bo siedzę na starym Wektorze) działa, sprawdzę jeszcze działanie na nowym. ElectroTiel | łiir! 21:29, 7 lip 2026 (CEST)
- Jak używasz gadżetu to może jest widoczne. W domyślnym trybie ciemnym jest mało widzoczne, a w podpisie jest prawie niewidzialne. Żeby przeczytać trzeba zaznaczyć tekst. @Jcubic (dyskusja) 20:10, 4 cze 2026 (CEST)
- @Jcubic Po to zakładam wątek w Kawiarence, aby przedyskutować kwestię zmiany tego szablonu. ElectroTiel | łiir! 13:37, 4 cze 2026 (CEST)
- Sam używam trybu ciemnego - fakt, jest mniej czytelne niż na białym, ale da się zobaczyć. W sumie, poprawię. ElectroTiel | łiir! 13:36, 4 cze 2026 (CEST)
Lista nowicjuszy
[edytuj | edytuj kod]Da się jakoś wyciągnąć listę osób, których mam "pod sobą" jako przewodnik?
Chciałem spróbować dodać ich wszystkich na jednej stronie za pomocą szablonu:
{{Wikipedysta:Jcubic/Monitoring}}
Jak jest ich za dużo, to mogę dodać jakąś paginację. @Jcubic (dyskusja) 00:59, 4 cze 2026 (CEST)
- Wg Pomoc:Przewodnicy/Dokumentacja, musiałbyś udać się na Specjalna:Panel przewodników, bo tam jest lista twoich podopiecznych. Nie wiem natomiast, jak ona wygląda (czy jest możliwość jej eksportu/edycji w trybie tekstowym), bo nie jestem zapisany na listę przewodników. Musiałbyś popróbować.
XaxeLoled ⸤ AmA ⸣20:36, 4 cze 2026 (CEST)- Niestety ta specjalna strona to GUI. Nie widzę też możliwości ekspertu, myślałem żeby odpytać bazę danych przez Quarry. @Jcubic (dyskusja) 21:03, 4 cze 2026 (CEST)
- Jeśli jest taka możliwość , to dlaczego by nie spróbować?
XaxeLoled ⸤ AmA ⸣16:06, 8 cze 2026 (CEST)
- Jeśli jest taka możliwość , to dlaczego by nie spróbować?
- Niestety ta specjalna strona to GUI. Nie widzę też możliwości ekspertu, myślałem żeby odpytać bazę danych przez Quarry. @Jcubic (dyskusja) 21:03, 4 cze 2026 (CEST)
- https://pl.wikipedia.org/wiki/Specjalna:%C5%9Arodowisko_testowe_API#action=query&format=json&list=growthmentormentee&formatversion=2&gemmmentor=jcubic Wargo (dyskusja) 00:03, 9 cze 2026 (CEST)
- @Wargo Dzięki przyda się. @Jcubic (dyskusja) 00:52, 9 cze 2026 (CEST)
Podprzypisy
[edytuj | edytuj kod]Szukałem informacji na temat pod przypisów i znalazłem tylko tą stronę Pomoc:Techniczne aspekty stosowania przypisów, która ma link do dyskusji (w szablonie dopracuj).
Oraz kategoria stron, które używają pod przypisów. Zrobiłem sobie krótki test jak one działają Wikipedysta:Jcubic/Pod przypisy. I nie widzę żadnej różnicy między nimi a {{odn}}. Powyższa dyskusja opisuje problem (duplikowane przypisy różniące się numerem strony), którego w pl Wiki nie ma, bo jest {{odn}}.
Czy była jakaś dyskusja na temat wprowadzenia pod przypisów do PL wiki? Bo ja osobiście nie widzę sensu.
Czy może coś przeoczyłem i numery stron to nie jest jedyny problem, który pod przypisy załawiają? Do tego Bibliografia w aktualnej postaci po prostu lepiej wygląda.
Trochę to przypomina efekt, gdy powstaje nowy framework JavaScript i wszyscy się na niego rzucają, bo jest hot. @Jcubic (dyskusja) 01:58, 4 cze 2026 (CEST)
- Hm... To jest dziwne, bo pamiętam, że byłeś na mojej prezentacji o podprzypisach. A nawet z tego co pamiętam byłeś jednym z tych co mnie pytali czy możemy automatycznie zamienić {{odn}} na podprzypisy. Nie wiem zatem skąd ta zmiana :). Wtedy na prezentacji ja raczej starałem się nieco gasić ten entuzjazm z sali mówiąc o tym, że podprzypisy mogą funkcjonować obok odn i nie ma nagłej potrzeby by to zmieniać. Nadal uważam, że może kiedyś pożegnamy się z odn, ale na pewno nie szybko. Odn na pewno jest dobry dla bardziej zaawansowanych osób. Dla nowicjuszy raczej odn się nie nadaje niestety.
- Czy wprowadzenie podprzypisów było dyskutowane? Och, wiele razy. Poczynając od licznych głosowań za zrobieniem podprzypisów w życzeniach społeczności (meta:Community Wishlist), przez kolejne konsultacje już przy tworzeniu tej funkcji, po różne dyskusje u nas po wprowadzeniu prototypu podprzypisów na dewiki. Pierwszy raz temat podprzypisów pojawił się jeszcze w 2008 roku w bugzilli, a w życzeniach społeczności pojawiał się kilka razy pomiędzy 2015, a 2023 rokiem (dla kontekstu odn jest u nas od 2012 roku). Tak że było tego sporo i trwało to bardzo długo zanim się udało.
- Jeśli już porównać do JavaScript, to ja bym porównał do powstającego w bólach standardu JavaScript z klasami. Nawet lata się w miarę zgadzają, bo już w 2008 roku miały się pojawić klasy w JS i niedługo później były też propozycje dodania właściwości prywatnych. Klasy pojawiły się jednak dopiero w 2015 roku, a właściwości prywatne dopiero w 2022 roku. Teraz klasy to już normalka w JS, choć cały czas zdarza się kod pisany starymi metodami. Nux (dyskusja) 03:30, 4 cze 2026 (CEST)
- Chodziło mi o dyskusje w pl wiki. Rozumiem że podprzypisy mogą działać lepiej niż odn (np w VE), ale moglyby wyglądać tak samo.
- Zastanawiałem sie czy dodać je do mojego narzędzia do cytowania, które dodaje odn i bibliografie. Dlatego sprawdziłem sobie dokładnie jakie sa różnice. W kodzie zmiany sa niewielkie. Jest inaczej, akceptuje tą zmianę. Ale wygląd jest o wiele gorszy niż to co mamy teraz z odn. Przypisy harwardzkie wyglądają po prostu lepiej od syrony czytelnika.
- A jeśli chodzi o prezentacje to chyba dotknął mnie efekt świeżości. @Jcubic (dyskusja) 04:16, 4 cze 2026 (CEST)
- Ech... Mówiłem o tym wszystkim w Łodzi, zachęcam do obejrzenia ponownie. Prezentacja różnic między odn, r, zwykłym ref i podprzypisami też tam jest. Prezentacja (slajdy) jest podlinkowana na mojej stronie, a na Commons jest link do YT.
- Nie rozumiem czemu dopytujesz o dyskusje u nas, życzenia społeczności to też nasze życzenia, Polacy uczestniczyli w nich... No ale teraz to jakie to ma znaczenie? Podprzypisy już są i zostaną z nami, to jest funkcja zintegrowana z przypisami.
- Oczywiście nie ma obowiązku używania ani odn, ani podprzypisów, każdy ma swoje przyzwyczajenia, ale próg wejścia do dodawania odn jest duży. Dużo większy niż dodawanie zwykłych przypisów, a to tylko jeden z problemów odn i R o których mówiłem w Łodzi.
- Podprzypisy definiuje się dużo łatwiej i można to zrobić nawet edytując jedną sekcję. Tego w odn się nie da, bo musisz osobno definiować bibliografię i potem osobno dodawać odn.
- Dodatkowo zarówno przy edycji wizualnej, jak i dla czytelników (pod)przypisy są lepsze niż odn z powodu tego jak działa podgląd. Zarówno przy przypisach jak i podprzypisach użytkownik ma dostępne wszystkie dane pod ręką. W odn musi nomen omen używać dodatkowego odnośnika, żeby przejść do bibliografii. Czy podgląd mógłby działać inaczej dla odn? Raczej nie, bo każda Wiki ma nieco inaczej działający szablon, a co za tym idzie nie jest realne stworzenie i utrzymanie dobrego rozwiązania na odn, sfn i inne. To jest chyba jedyna rzecz którą można by sprowokować rozwiązać lokalnie, chociaż podpięcie się pod wbudowany podgląd na pewno nie będzie łatwe, nie wiem czy tam w ogóle są hooki, które można by wykorzystać do zmiany podglądu. A rozwiązanie nie oparte na hookach będzie niestabilne... Ale jak już mówiłem na prezentacji – jeśli ktoś chce spróbować poprawić podgląd odn to śmiało, jeśli uda się to ładnie i stabilnie zrobić to można z tego zrobić gadżet. Jeśli testy gadżetu wyszłyby stabilnie to można zrobić z tego gadżet domyślny. Osobiście uważam że konstrukcja odn jest zbyt wrażliwa na zmiany i zbyt specyficzna by obsłużyć różne rodzaje edycji w sensowny sposób. Nux (dyskusja) 11:11, 4 cze 2026 (CEST)
- @Jcubic, kojarzę przynajmniej dwie dyskusje na ten temat w Barze, które toczyły się w tym roku: 1 i 2 Frangern (dyskusja) 10:38, 4 cze 2026 (CEST)
- @Frangern Pierwsze jest linkowane w moim pytaniu, to jest ogłoszenie wprawdzenia ich do MediaWiki i do PL Wiki. Drugie to pytania o tym kiedy będą usuwane {{odn}}, to nie jest dyskuja nad tym czy powinniśmy ich używać.
- Wygląda na to, że wszyscy przyjeli, że muszą ich używać bo zostały dodanie. @Jcubic (dyskusja) 11:11, 4 cze 2026 (CEST)
- @Jcubic, a to przepraszam, nie kliknąłem w link, który podałeś. Frangern (dyskusja) 14:59, 4 cze 2026 (CEST)
- @Jcubic muszą używać? Nie rozumiem czemu używasz tego sformułowania. Podprzypisy to jedna z opcji. Jak dla mnie dużo lepsza dla czytelników i nowicjuszy, ale to nadal tylko jedna z opcji. Nux (dyskusja) 11:17, 4 cze 2026 (CEST)
- @Nux jak ktoś pyta kiedy odn zostanie skasowany w dyskusji, która wygląda, że jest jedyną na temat pod przypisów. To chyba zakłada że to jest coś co muszą używać bez zastanawiania się.
- No ale ok, przekonałeś mnie. Chociaż nadal wydaje mi się że odn z bibliografią wygląda lepiej. Ale to może dlatego, że generalnie nie lubię zmian. @Jcubic (dyskusja) 11:50, 4 cze 2026 (CEST)
- Dyskusji było dużo i naturalnie pojawiał się czasem temat odn, ale nie tylko. Nawet w tym podlinkowanym archiwum, jak sobie je poprzewijasz, to jest mowa o obsłudze atrybutu details (podprzypisów) w prettyref, czy o kropce w podprzypisach (kwestie interpunkcji). Być może nie znalazłeś dyskusji, bo różnie to nazywaliśmy. Oficjalna nazwa od dłuższego czasu to „podprzypisy” (razem, tak samo jak „podkategorie”). Nie pamiętam, kiedy dokładnie powstała polska nazwa „podprzypisy”, więc trzeba też brać pod uwagę angielskie „subref” (czasem jeszcze pisane z kreską). dyskusje w Barach o podprzypisach.
- Tak pokrótce historia: tutaj są linki do życzeń społeczności (tam m.in. głosowali Kpijas, Wargo, Aegis, a to tylko przy zgrubnym przejrzeniu). Ostatnie życzenia były w 2023, jak widać, a start pierwszych konsultacji był w lipcu 2024. A tutaj ogłoszenie Johannesa z sierpnia 2024 w Barze i to na pewno jedna z istotnych dyskusji, a chyba też pierwsze szersze opinie o prototypie podprzypisów na samym plwiki.
- Na pewno było dużo różnych dyskusji i konsultacji i w różnych wymiarach (również o odn). Osobiście chciałem, żeby podprzypisy weszły na plwiki jeszcze przed Kopalnią Wiedzy 2025 (październik). Chciałem żeby można było już wtedy to potrenować wspólnie podczas edytonu, ale wówczas w dyskusji, w sumie słusznie, niektórzy zwracali uwagę, że może jeszcze za wcześnie, i razem ustaliliśmy, że poczekamy na wdrożenie kolejnej fali poprawek. Teraz już jesteśmy po kolejnych poprawkach i udoskonaleniach oraz jesteśmy też po kolejnych wdrożeniach. W skrócie aktualizacje i pomoc jest na Meta: instrukcja do podprzypisów, aktualizacje itp. Instrukcję można skopiować też na plwiki, ale tą na Meta co jakiś czas aktualizuję (właśnie dokończyłem tłumaczenie całości, w tym archiwalnych aktualizacji). Nux (dyskusja) 12:55, 4 cze 2026 (CEST)
- @Jcubic muszą używać? Nie rozumiem czemu używasz tego sformułowania. Podprzypisy to jedna z opcji. Jak dla mnie dużo lepsza dla czytelników i nowicjuszy, ale to nadal tylko jedna z opcji. Nux (dyskusja) 11:17, 4 cze 2026 (CEST)
Prośba o pomoc z importem modułu z Wikipedii na Wikicytaty
[edytuj | edytuj kod]Chciałbym poprosić o pomoc z importem modułu z Wikipedii na Wikicytaty. Zaimportowałem ostatnio z Wikipedii na Wikicytaty dokumentację szablonu Ikona. Zaimportowałem również Szablon:Lua i Szablon:Układ wielokolumnowy używane przez tę stronę. Teraz na stronie dokumentacji szablonu ikona widnieje napis Błąd skryptu: nie ma takiego modułu „Sprawdź”.. Jak skopiowałem kod tego modułu Sprawdź do edytora i na dole pod tekstem Podgląd strony z tym szablonem wpisałem Szablon:Ikona wyświetlał się błąd Błąd Lua w module „package.lua”, w linii 80: module 'Moduł:Cytuj/dane' not found.. Czy ktoś kompetentniejszy ode mnie w technikaliach mógłby zaimportować moduł Sprawdź? Nie wiem czy ten moduł Moduł:Cytuj/dane w Wikicytatach jest potrzebny, bo nie mamy tam dedykowanych szablonów do podawania źródeł i też wolałbym uniknąć sytuacji, że konieczne będzie zaimportowanie nie wiadomo ilu niekoniecznie potrzebnych szablonów/modułów byleby tylko nie było błędów. Sam też nie jestem biegły w Lui i nie wiem czy pogorszę sytuacji grzebiąc w kodzie. Swam pl (dyskusja) 00:20, 7 cze 2026 (CEST)
- @Swam pl No dobra, powinno działać, możesz sprawdzić czy czegoś nie przegapiłem. Nux (dyskusja) 19:49, 15 cze 2026 (CEST)
- @Nux: bardzo dziękuję. Widzę, że na stronie szablonu ikona nie ma już żadnych komunikatów o błędzie, więc chyba jest dobrze. Widzę, że na zaimportowanej stronie dokumentacji szablonu Lua są odwołania do nieistniejących w Wikicytatach szablonów. Na stronach dokumentacji zaimportowanych modułów są tylko odnośniki do strony z jakiej został zaimportowany moduł. Czy nie lepiej byłoby zaimportować też dla nich całą stronę dokumentacji? Na stronach dokumentacji szablonów q:Szablon:!!, q:Szablon:!(, q:Szablon:)!, q:Szablon:!(( i q:Szablon:))! w tabelce Podobne szablony są czerwone linki do nieistniejących szablonów. Nie wiem czy się do czegoś przydadzą, ale jeśli tak to chyba można je też zaimportować, a jeśli nie to chyba można usunąć. Nie wiem też na ile potrzebny jest moduł q:Moduł:Cytuj/dane jeśli nie ma w Cytatach modułu Cytuj, ale być może przyda się jeśli kiedyś zostaną wprowadzone szablony cytowania. Swam pl (dyskusja) 20:36, 15 cze 2026 (CEST)
- @Swam pl, @Nux W {{#invoke:Cytuj/dane}} jest tablica
supportedUriSchemas, którą ładuje lokalna funkcja {{#invoke:Sprawdź|checkUri}}. Wydaje się więc, że można by to uprościć przez skopiowanie tejże tablicy bezpośrednio do modułu, który jej potrzebuje. Paweł Ziemian (dyskusja) 21:00, 15 cze 2026 (CEST)- Dziękuję. Spróbowałem poprawić kod w ten sposób i na stronie szablonu Ikona nie pojawił się żaden błąd, więc chyba faktycznie ten sposób zadziałał i ja też nic przypadkowo nie popsułem. Jako, że moduł q:Moduł:Cytuj/dane nie jest już używany, pozwoliłem go sobie usunąć (jeśli kiedyś na Cytatach zostaną wprowadzone szablony cytowania to można go przywrócić/ponownie zaimportować z Wikipedii). Swam pl (dyskusja) 02:24, 24 cze 2026 (CEST)
Logo w infoboksie
[edytuj | edytuj kod]Napisałem szablon {{Theme}}[1] (za sugestią @Nuxa), na początku potrzebowałem go, aby dodać dwa obrazki (ciemny/jasny tryb) dla WP:TRENER. Ale szablon ten może przydać, aby poprawić wszystkie infoboxy, gdzie jest logo, np. {{Przedsiębiorstwo infobox}} pierwsze dwa z brzegu Apple (przedsiębiorstwo) i Borland czarna grafika bez tła.
Można by dodać do parametr {{{logo dark}}} (czy inny). Sam parametr to nie problem, ale potem trzeba będzie poprawić wszystkie artykuły i dodać jasną grafikę (dla ciemnego trybu) do commons.
Co o tym sądzicie?
- Notka
- ↑ Szablon był testowany tylko z Vektorem, ale chyba klasy na tagu
<html>są takie same w każdej skórce. Testowany gadżetem i domyślnym trybem ciemnym.
@Jcubic (dyskusja) 20:12, 7 cze 2026 (CEST)
Trzeba by dodać parametr do {{infobox grafika}} i tam to obsłużyć, a potem w każdym infoboksie osobno. Czyli byś miał coś w rodzaju:
{{infobox grafika
|grafika = {{{logo<includeonly>|</includeonly>}}}
|ciemna grafika = {{{ciemne logo<includeonly>|</includeonly>}}}
|opis grafiki = {{{opis logo<includeonly>|</includeonly>}}}
|alt grafiki = {{{alt logo|Logo}}}
...
}}
Pewnie zależy ile tych ciemnych wersji mamy i czy warto się w to bawić. --Nux (dyskusja) 21:21, 7 cze 2026 (CEST)
- Wydaje mi się, że mało firm ma przygotowane logotypy do ciemnego tła. Jeszcze mniej takich grafik mamy na commons (jeżeli w ogóle). Własnoręczne przeróbki "bo tak mi się wydaje" grożą powstawaniem WP:OR. Jedyne akceptowalne wzory powinny wynikać z odpowiednich "ksiąg znaku" tych firm. Tak więc zanim przygotujemy zmiany w szablonie chciałbym zobaczyć do czego można je od razu użyć. ~malarz pl PISZ 10:32, 8 cze 2026 (CEST)
- jestem dokładnie tego samego zdania – ale chcę zwrócić uwagę że jeśli chodzi o {{przedsiębiorstwo infobox}} to nie może być tak jak jest w tej chwili – ciemne tło motywu rujnuje wyświetlanie tysięcy logotypów które są zapisane w formatach svg czy png bez tła. Przykłady: Oberheim – Mitchell & Ness – Tiffany & Co. – Whirlpool Corporation – Oldsmobile – Eastpak ... a otwarłem tylko kilkadziesiąt haseł nt. amerykańskich przedsiębiorstw. W mojej opinii jedynym sensownym rozwiązeniem jest po prostu zrobienie tak żeby tło pozostawało białe również w trybie ciemnym (czyli tak jak na enwiki). Ta biała plama nie będzie na tyle duża żeby psuć efekt darkmode Archiwald (dyskusja) 20:02, 13 cze 2026 (CEST)
- PS: oczywiście większość z tych większych przedsiębiorstw ma swoje księgi znaku które przewidują ciemne tło i w przyszłości rozwiązanie o którym pisał Jcubic może wchodzić w grę, ale to zapewne kwestia wielu lat. Archiwald (dyskusja) 20:08, 13 cze 2026 (CEST)
- jestem dokładnie tego samego zdania – ale chcę zwrócić uwagę że jeśli chodzi o {{przedsiębiorstwo infobox}} to nie może być tak jak jest w tej chwili – ciemne tło motywu rujnuje wyświetlanie tysięcy logotypów które są zapisane w formatach svg czy png bez tła. Przykłady: Oberheim – Mitchell & Ness – Tiffany & Co. – Whirlpool Corporation – Oldsmobile – Eastpak ... a otwarłem tylko kilkadziesiąt haseł nt. amerykańskich przedsiębiorstw. W mojej opinii jedynym sensownym rozwiązeniem jest po prostu zrobienie tak żeby tło pozostawało białe również w trybie ciemnym (czyli tak jak na enwiki). Ta biała plama nie będzie na tyle duża żeby psuć efekt darkmode Archiwald (dyskusja) 20:02, 13 cze 2026 (CEST)
Brakuje nam takiej strony. Z jednej strony mówimy nowicjuszom, że wątków w dyskusjach nie należy usuwać, a co najwyżej należy je archiwizować. Z drugiej część wikipedystów, w tym także o długim stażu, ciągle prosi innych, aby im pomogli w archiwizacji. Czasami da się popełnić błąd i masowo przenieś podstrony. No i jeszcze też nie wszyscy wiedzą, że można zautomatyzować ten proces, zatrudniając bota :) Te prośby o archiwizację widzę na tyle często, że chyba warto byłoby taką stronę pomocy popełnić. Jest sekcja na stronie Pomoc:Strona dyskusji, ale ktoś (poza autorami tej strony pomocy) pamięta, że tam ona jest? Jest tam wątek o bocie, ale niezbyt zrozumiały (nie do zastosowania). A jeszcze archiwizowanie z wykorzystaniem szablonów {{status zgłoszenia|+}} / {{załatwione}}. Taka strona jest prawie we wszystkich dużych wiki, nie licząc botopedii. Hedger z Castleton (dyskusja) 17:49, 10 cze 2026 (CEST)
- Archiwizacją z wymienionymi szablonami zajmuje się bot Malarza.
XaxeLoled ⸤ AmA ⸣18:50, 11 cze 2026 (CEST)- @XaxeLoled, ja wiem, ty wiesz, ale ci, których wymieniłem, często nie wiedzą - dla siebie bym takiej strony pomocy nie robił :) Hedger z Castleton (dyskusja) 11:57, 13 cze 2026 (CEST)
- Instrukcja dla mojego bota jest w Wikipedysta:MalarzBOT/archiwum/config. I należy co najwyżej wskazywać tę stronę a nie powtarzać zapisane na niej informacje - nie uważam, że powinna stać się podstawą ww. strony. W związku z brakiem bezstronności nie uważam, że powinienem ją redagować (co nie przeszkadza poprawić mi ew. błędy, jak już strona będzie). Wydaje mi się, że stronę z proponowaną nazwą można stworzyć zaczynając od aktualnej zawartości sekcji Pomoc:Strona dyskusji#Archiwizacja, zaś w pomocy strony dyskusji skrócić ją wskazując Pomoc:Archiwizacja. ~malarz pl PISZ 12:40, 13 cze 2026 (CEST)
Sortowanie tabeli po kolumnie z obrazkami, które mają alt
[edytuj | edytuj kod]Da się jakoś zrobić, aby to działało? Czy trzeba zgłosić jako feature request do Phabricatora?
Na Wikiprojekt:Fotografia/Uczestnicy jest lista osób z szablonem {{Aktywność}}. Każdy obrazek ma alt "aktywny" lub "nieaktywny", ale sortowanie nie działa po kolumnie aktywność. @Jcubic (dyskusja) 21:01, 11 cze 2026 (CEST)
- Na mój gust nie da się tego zrobić. Tabela widzi szablon
{{Aktywność|[nick]}}, a nie efekt jego działania. Michał Ski (dyskusja) 10:33, 12 cze 2026 (CEST)- @Michał Ski ale sortowanie chyba jest po zawartości w JS. Problemem jest to, że nie ma tekstu. @Jcubic (dyskusja) 13:13, 12 cze 2026 (CEST)
Lista w przypisach
[edytuj | edytuj kod]Przejrzałem dokumentację chyba wszystkich potencjalnie interesujących szablonów, strony pomocy i dyskusji, ale odpowiedzi nie znalazłem. Czy mamy może w polskiej Wikipedii jakiś ukryty odpowiednik angielskiego {{multiref}}, pozwalający dodać w <ref> więcej niż jedno źródło, żeby całość wyświetlała się w formie listy tak jak tutaj? Czasami by się przydał jakiś szybki sposób zamiast babrania się z punktorami, twardymi spacjami, elementami blokowymi, CSS-em itd. Ewentualnie, jeżeli nie ma u nas żadnego takiego szablonu, to czy jest możliwe utworzenie odpowiednika multirefa? Pottero (dyskusja) 04:06, 12 cze 2026 (CEST)
- @Pottero teoretycznie by się dało tylko po co? Robiąc takie rzeczy psuje się wygląd artykułu, wprowadza zamieszanie dla czytelnika niestandardowym rozwiązaniem. W efekcie wymagasz od czytelnika dodatkowej analizy.
- A na dodatek, jeśli potem ktoś chce dodać jeden akapit, i użyć tylko jednego źródła, to będzie miał kłopot. Sam zresztą dodając takie cuda namęczysz się bardziej, zamiast normalnie wygenerować przypisy i je skopiować. Nux (dyskusja) 08:42, 12 cze 2026 (CEST)
- Zdecydowanie jestem za pojedynczymi przypisami. Znacznie łątwiej je użyć w innych miejscach artykułu. ~malarz pl PISZ 13:51, 12 cze 2026 (CEST)
- Każde źródło powinno być umieszczone w osobnym przypisie. Ewentualne sytuacje łączenia różnych przypisów z tekstem wyjaśniającym to rola przypisów rzeczowych (uwag). Wostr (dyskusja) 18:40, 13 cze 2026 (CEST)
Migration to Parsoid
[edytuj | edytuj kod]Hello everyone! I am glad to inform you that as the next step in the Parser Unification project, Parsoid will soon be turned on as the default article renderer on your wiki. We are gradually increasing the number of wikis using Parsoid, with the intention of making it the default wikitext parser for MediaWiki's next long-term support release. This will make our wikis more reliable and consistent for editors, readers, and tools to use, as well as making the development of future wikitext features easier.
If this disrupts your workflow, don’t worry! You can still opt out through a user preference or turn Parsoid off on the current page using the Tools submenu, as described in the Extension:ParserMigration documentation.
There is more information about our roll-out strategy available, including the testing done before we turn on Parsoid for a new wiki.
To report bugs and issues, please look at our known issues documentation and if you found a new bug please create a phab ticket and tag the Content Transform Team in Phabricator.
Content Transform Team 00:30, 13 cze 2026 (CEST)
- Cześć. W razie gdyby wiadomość była zbyt zagadkowa – chodzi o zmianę sposobu zamiany wikitekstu na to co potem widzimy w artykule (w podglądzie artykułu i w zapisanej wersji artykułu). Zmiana może powodować najróżniejsze problemy w tym znikania fragmentów tekstów, zwłaszcza przy użyciu bardziej nietypowych mechanizmów. Aczkolwiek w praktyce nie powinno być źle i problemy powinny być dotyczyć głównie użycia szablonów (pośrednio w szczególności: modułów i funkcji parsera). Problemy mogą być również z wyświetlaniem przykładów na stronach szablonów itp, więc zwróćcie proszę uwagę na problemy na tych stronach. Pozdrawiam, Nux (dyskusja) 12:51, 13 cze 2026 (CEST)
Nowa strona pomocy
[edytuj | edytuj kod]Cześć, informacyjnie: zamieściłem dziś nową stronę pomocy, Pomoc:Podprzypisy. Obiecałem ją kilka miesięcy temu @Gowerowi, który zwrócił uwagę na potrzebę jej stworzenia podczas dyskusji o nowej wersji strony Pomoc:Przypisy. W obecnym kształcie strona jest biedniejszą siostrą tego poradnika autorstwa WMDE Technical Wishes, choć wyczerpuje temat. Będę wdzięczny za wszelkie sugestie jej poprawy, dodania nowych treści itd. Pozdrawiam, Karol739 (dyskusja) 22:21, 14 cze 2026 (CEST)
SPAM
[edytuj | edytuj kod]@Aw58 (Specjalna:Wkład/Aw58) Od ponad dwóch tygodni dodaje zbędne linki do polski-org.pl i fotopolski.eu. Część usunąłem, ale jest tego bardzo dużo. Eurohunter (dyskusja) 19:35, 18 cze 2026 (CEST)
- @Eurohunter dodałem link do jego edycji. To by chyba trzeba zgłosić na stronie Wikipedia:Prośby_do_administratorów. @Jcubic (dyskusja) 20:54, 18 cze 2026 (CEST)
- Blokada załatwiona. Sprzątania się nie podejmuję. Nux (dyskusja) 00:44, 19 cze 2026 (CEST)
Przypisy bez pod przypisów
[edytuj | edytuj kod]Jeśli pod przypisy mają się zachowywać jak bibliografia to czy powinny pojawiać się błędy, jak jakiś przypis nie jest użyty w treści[1.1]? @Jcubic (dyskusja) 23:36, 23 cze 2026 (CEST)
- Marek Andruszkiewicz, Dariusz Gąsior, Jacek Pająk: Osłona przeciwlotnicza w działaniach taktycznych (dywizjonu brygad). Wrocław: Akademia Wojsk Lądowych im. gen. Tadeusza Kościuszki, 2021. ISBN 978-83-66299-42-9.
- ↑ s. 11
- Jacek Droszcz. Mobilizacyjne rozwinięcie jednostki wojskowej. „Obronność. Zeszyty Naukowe”. 4/28, 2018. Warszawa: Akademia Sztuki Wojennej. ISSN 2299-2316.
Znacznik <ref> o nazwie „Droszcz_2018”, zdefiniowany w <references>, nie był użyty wcześniej w treści.
Ale podprzypisy nie są zamiennikiem bibliografii tylko są mechanizmem umożliwiającym wielokrotne używanie tych samych pozycji w przypisach, z podaniem lokalnie szczegółu (np. strony), którego brak był obchodzony przez wykorzystanie pozycji Bibliografii. ~malarz pl PISZ 23:42, 23 cze 2026 (CEST)
- Tak, ale teraz nieużywany ref się wyświetla, kiedyś był ukryty, więc błąd miał sens. Teraz nieużyty ref wygląda jak bibliografia, która nie ma żadnego {{odn}}. Moim zdaniem Media Wiki nie powinna pokazywać już tego błędu. @Jcubic (dyskusja) 00:27, 24 cze 2026 (CEST)
- Znaczy wiesz co do zasady w bibliografii powinny być wyłącznie rzeczy, które zostały użyte do pisania artykułu. Wręcz co do zasady każda pozycja w bibliografii musi mieć przypis (przynajmniej w nowych artykułach). Różnica jest zatem tylko taka, że jak masz nieużyty przypis to oprogramowanie pokaże ten błąd, a błędu w bibliografii nie wyłapie.
- Inna sprawa, że ten błąd jest jak dla mnie przesadnie krzykliwy. Nie widzę uzasadnienia dla wielokrotnego wyróżnienia. Wystarczyłaby mała ikonka z tooltipem jak dla mnie. Nux (dyskusja) 02:08, 24 cze 2026 (CEST)
- Akurat moim zdaniem walenie takimi błędami po oczach jest sensowne. Wikipedia bazuje na tym że mamy źródła. Więc jeżeli jest problem ze źródłami to on powinien walic po oczach. Ten błąd nie jest dla programistów/technicznych, jest dla edytorów. PMG (dyskusja) 10:33, 24 cze 2026 (CEST)
- Mogłoby być krzykliwe, ale tylko w trybie edycji oraz dla zarejestrowanych osób, które miałyby włączoną taką funkcję. Czytelnik nie powinien tego w ogóle widzieć, bo po co walić mu po oczach informacją, że kawałek kodu jest niewykorzystany. Michał Ski (dyskusja) 11:22, 24 cze 2026 (CEST)
- Statystycznie znacznie więcej ludzi ogląda - więc ograniczenie tego tylko do trybu edycji to ścięcie z kilku ludzi dziennie do pojedynczych osób raz w tygodniu. Prawo Linusa jest bezlitosne. PMG (dyskusja) 14:19, 24 cze 2026 (CEST)
- Nie bardzo rozumiem, czy popierasz, czy krytykujesz moją opinię. :-) Chodzi o to, aby czytelnicy niezainteresowani edytowaniem nie widzieli krzykliwego komunikatu technicznego niemającego wpływu na treść. Michał Ski (dyskusja) 16:33, 24 cze 2026 (CEST)
- Statystycznie znacznie więcej ludzi ogląda - więc ograniczenie tego tylko do trybu edycji to ścięcie z kilku ludzi dziennie do pojedynczych osób raz w tygodniu. Prawo Linusa jest bezlitosne. PMG (dyskusja) 14:19, 24 cze 2026 (CEST)
- Niezalogowanym można rzeczywiście te błędy ukryć. Ale wszystkim zalogowanym bym jednak zostawił na siłę. ~malarz pl PISZ 11:57, 24 cze 2026 (CEST)
- Wg mnie możliwość wyłączenia powinna być, w każdym razie w trybie czytania. Z pewnością są wikipedyści zupełnie niezainteresowani korygowaniem takich błędów – i tak nic z tym nie zrobią, więc ten komunikat niczemu im nie służy, nie zachęci ich do korekty. Michał Ski (dyskusja) 16:33, 24 cze 2026 (CEST)
- Mogłoby być krzykliwe, ale tylko w trybie edycji oraz dla zarejestrowanych osób, które miałyby włączoną taką funkcję. Czytelnik nie powinien tego w ogóle widzieć, bo po co walić mu po oczach informacją, że kawałek kodu jest niewykorzystany. Michał Ski (dyskusja) 11:22, 24 cze 2026 (CEST)
- Akurat moim zdaniem walenie takimi błędami po oczach jest sensowne. Wikipedia bazuje na tym że mamy źródła. Więc jeżeli jest problem ze źródłami to on powinien walic po oczach. Ten błąd nie jest dla programistów/technicznych, jest dla edytorów. PMG (dyskusja) 10:33, 24 cze 2026 (CEST)
- Pytanie zatem, czy jest sens takiej pozycji niepowiązanej z konkretną informacją w treści umieszczać w przypisach. Ona jednak powinna zostać wymieniona w Bibliografii. ~malarz pl PISZ 11:56, 24 cze 2026 (CEST)
- O ile rozumiem, to nie chodzi o wsadzanie do <references> przypisów bez odwołania w tekście, tylko o to, że dawniej tych przypisów-sierotek nie było widać, a teraz się pojawiły na liście przypisów. Takie sierotki powstają zazwyczaj w wyniku usunięcia informacji, którą uźródławiały (wraz z refem), więc nie powinno ich być w Bibliografii. Aczkolwiek możliwa jest sytuacja przypadkowego usunięcia refu z pozostawieniem danej informacji – wtedy należy go przywrócić. Michał Ski (dyskusja) 16:33, 24 cze 2026 (CEST)
- Takie błędy o nadmiarowym ref występują zwykle po edycji sekcji w kodzie. Ktoś przepisuje lub po prostu aktualizuje jakiś fragment usuwając stare przypisy. Wówczas zapisuje zmiany i nawet nie wie, że powstał błąd (sekcja przypisów może być kilka ekranów dalej). O ile takiego przypisu nie powinno być w kodzie, to zasadniczo niczemu nie szkodzi. Nie zgodziłbym się z PMG, że to jest błąd, bo to niczego nie zmienia. To jest niewłaściwie (podobnie jak zakomentowanie fragmentu zamiast usunięcia go jest niewłaściwie), ale to nie błąd. Nux (dyskusja) 09:28, 25 cze 2026 (CEST)
- Zgadza się, ale możliwa jest sytuacja, że ktoś ze zdania „Słoń jest duży i czerwony<ref name=":0" />” zrobi „Słoń jest duży” zamiast „Słoń jest duży<ref name=":0" />” (tu oczywiście błąd widać od razu, ale przy większych edycjach coś takiego może się zdarzyć każdemu). Dlatego warto widzieć informację o przypisie-sierotce. W typowej sytuacji, o której piszesz, to rzeczywiście nie jest błąd, tylko zbędny kawałek kodu. Michał Ski (dyskusja) 10:09, 25 cze 2026 (CEST)
- Takie błędy o nadmiarowym ref występują zwykle po edycji sekcji w kodzie. Ktoś przepisuje lub po prostu aktualizuje jakiś fragment usuwając stare przypisy. Wówczas zapisuje zmiany i nawet nie wie, że powstał błąd (sekcja przypisów może być kilka ekranów dalej). O ile takiego przypisu nie powinno być w kodzie, to zasadniczo niczemu nie szkodzi. Nie zgodziłbym się z PMG, że to jest błąd, bo to niczego nie zmienia. To jest niewłaściwie (podobnie jak zakomentowanie fragmentu zamiast usunięcia go jest niewłaściwie), ale to nie błąd. Nux (dyskusja) 09:28, 25 cze 2026 (CEST)
- O ile rozumiem, to nie chodzi o wsadzanie do <references> przypisów bez odwołania w tekście, tylko o to, że dawniej tych przypisów-sierotek nie było widać, a teraz się pojawiły na liście przypisów. Takie sierotki powstają zazwyczaj w wyniku usunięcia informacji, którą uźródławiały (wraz z refem), więc nie powinno ich być w Bibliografii. Aczkolwiek możliwa jest sytuacja przypadkowego usunięcia refu z pozostawieniem danej informacji – wtedy należy go przywrócić. Michał Ski (dyskusja) 16:33, 24 cze 2026 (CEST)
Gdzie jest u nas en:Template:Reference page?
[edytuj | edytuj kod]Jest na 118 wiki, ale nie u nas. Tłumaczę swoje hasło z en wiki do nas (tam jest DA, u nas nie, mam nadzieję zsynchronizować: en:Władysław Umiński), tam jest to użyte (dość często tego używam, lubię) i mam zagwozdkę co zrobić u nas... Jasne, znam obejścia, ale mało wygodne (inne sposoby cytowań). Od biedy mogę sam ten szablon do nas skopiować, ale hmmm. Czemu u nas nie ma, znowu się pytam? Wygodny, prosty... Piotr Konieczny aka Prokonsul Piotrus Słucham? 06:56, 28 cze 2026 (CEST)
- Widać się nie przyjęło. Obecnie należy raczej używać podprzypisów. ~malarz pl PISZ 12:08, 28 cze 2026 (CEST)
- Mamy podprzypisy, nie musimy już używać tych niestandardowych wynalazków (których choćby dostępność jest dyskusyjna). Nux (dyskusja) 12:09, 28 cze 2026 (CEST)
- Nie będę teraz szukał, ale kiedyś był dyskutowany i na szczęście został wycofany. Sam w kilku artykułach go usuwałem, zmieniając na prawidłowe odnośniki. Nie może być sytuacji, w której mamy tego rodzaju hybrydowe rozwiązania – część jest w opisie bibliograficznym, część w jakimś dziwnym potworku, co do którego użytkownicy mieli wątpliwości, czym w ogóle są te numery. Wostr (dyskusja) 17:19, 28 cze 2026 (CEST)
- Nawet to ja go usuwałem, nie pamiętałem już tego. Wikipedia:Poczekalnia/kwestie techniczne/2017:12:27:Szablon:Rp. W dyskusji w poczekalni są linki do innych dyskusji w kawiarence. ~malarz pl PISZ 17:35, 28 cze 2026 (CEST)
Automatyzacja zmian ("korekt") przekierowań i narzędzia do tego celu
[edytuj | edytuj kod]Jest to w istocie kopia/kontynuacja wątku rozpoczętego w dyskusji o konkretnym narzędziu ale zgodnie z radą, wrzucam temat do bardziej ogólnego miejsca; w sumie temat jest bardziej ogólny... Zacytuję tutaj by nie trzeba było skakać po stronach (dot. narzędzia disFixer):
Narzędzie to zmienia linkowania ze stron przekierowujących na docelowe. O ile w określonych przypadkach może to być właściwe, w wielu tak nie jest, ponieważ strona z przekierowaniem jeśli istnieje to jest tam w jakimś celu, tj. dane pojęcie/temat ma powszechnie używane znaczenie. Znaczenie to wcale niekoniecznie pokrywa się z miejscem (artykułem), do którego prowadzi przekierowanie, czasem jest to jedynie (pod)sekcja, czasem jedno ze znaczeń. Tak czy inaczej, jeśli układ aktykułów się zmieni i strona z przekierowaniem stanie się artykułem (albo zostanie przekierowana gdzie indziej) to dla utrzymania konsystencji należałoby przeglądnąć wszystkie miejsca i uwzględniając kontekst zostawić lub poprawić linki (co jest, w mojej ocenie, niewykonalne). Prowadzi to więc do kompletnego bałaganu w linkowaniach.
Z uwagi na powyższe chciałbym zapytać, bo może tutaj grać moja niewiedza, czy gdzieś jest jakaś reguła, która mówi, że linki muszą prowadzić do pełnoprawnych artykułów (a nie stron z przekierowaniami). Rozumiem, że jeśli jest, to narzędzie działa jak najbardziej prawidłowo.
Jeśli jednak takiej reguły nie ma, sugeruję usunięcie tej funkcjonalności. W mojej ocenie każdy link powinien być rozważony i ustawiony indywidualnie, a nie żadnym automatem, i w wielu przypadkach prawidłowym ich ustawieniem (zgodnym znaczeniowo z linkowanym tekstem) jest strona z przekierowaniem, a nie artykuł docelowy. Robienie tego w bezmyślny sposób jak ma to miejsce obecnie (widzę to w wielu miejscach) prowadzi do kompletnego chaosu w znaczeniach linkowań w artykułach (co będzie bardzo trudne i czasochłonne w naprawie, o ile w ogóle możliwe).
Generalnie chodzi o same praktyki zmiany linków z przekierowań na strony docelowe, które najwyraźniej często są przeprowadzane automatami (stąd mój wątek tamże).
Podsumowując, moje pytania są następujące:
1. czy jest gdzieś taka reguła/zalecenie by linki zawsze ustawiać na stronę docelową (i, jednocześnie, zmieniać zgodnie z nią linki prowadzące do stron przekierowujących)?
2. jeśli tak - to czy ktoś poza mną uważa, że należałoby się zastanowić nad tym czy to jest właściwe? (a jeśli nie to być może zmienić)?
3. jeśli takiej reguły nie ma (to już nie pytanie tylko temat do przemyślenia) - chyba trzeba byłoby przyglądnąć się narzędziom, które są zbyt pochopnie wykorzystywane do "poprawiania" linków , tj. albo w ogóle usunąć takie funkcjonalności, albo zmodyfikować je tak by każdy przypadek (link) musiał być rozważony indywidualnie, uwzlględniając kontekst i znaczenie, dla którego został użyty.
Znaczenie każdego linka jest nierozerwalnie związane z miejscem (pojęciem/tematem), do którego on prowadzi i zmiany w tym zakresie wykonywane w nieprzemyślany sposób zamiast porządkować prowadzą do chaosu w znaczeniach linków w artykułach.
Pozdrawiam. Shirrapal (dyskusja) 20:15, 28 cze 2026 (CEST)
- Tak, od dosyć dawna na plwiki zamieniamy wszystkie przekierowania na docelowy artykuł. Stąd też zazwyczaj jeśli nie ma artykułu na dany temat, to nie powinno się tworzyć przekierowania tylko zostawić czerwony link (przynajmniej o ile artykuł może powstać w przyszłości). Nawiasem mówiąc te zwyczaje są inne na plwiki i inne na enwiki (na enwiki zazwyczaj nie zmienia się przekierowań).
- Co do pochopności zmiany przekierowań, to pewnie zależy jak bardzo nagniesz definicję tego słowa. Przekierowania są poprawiane na plwiki automatycznie co najmniej od 17 lat . Czyli pochopność niedługo będzie mogła wypić piwo ;)
- Czy możemy to zmienić? Być może, ale patrz pkt 1 i pkt 2. Na plwiki raczej inaczej myśli się o przekierowaniach poprzez to jak działają narzędzia. O ile pamiętam kiedyś plagą było to, że zostawały podwójne przekierowania (czy ogólniej wielokrotne przekierowania), co tworzyło problemy wydajności dla czytelników oraz, co ważniejsze, problemy zerwanych przekierowań (był łańcuch A → B → C, ktoś usuwał B i psuł przekierowanie z A do C)...
- To, że zmiana przekierowań może prowadzić do chaosu uważam za co najmniej przesadzone zdanie, bo podmieniamy przekierowania od dawna i jakoś sobie radzimy z konsekwencjami. Żeby nie było, nie uważam, że dyskusja jest bezprzedmiotowa. Na pewno wyłączenie tej funkcji w narzędziach spowodowałby jakiś tam chaos (zamieszanie), być może zdziwienie, być może protesty, niemal na pewno zwiększone problemy z zerwanymi przekierowaniami.
- Tutaj zamieściłem parę typów przekierowań: Wikipedysta:Nux/test/wpsk/redir. Jeśli w ogóle rozważać zmianę zachowania narzędzi, to raczej inaczej dla każdego typu. Wbrew pozorom każdy z tych przypadków da się rozróżnić, choć nie każdy da się zrobić szybko (zaawansowane sprawdzenia mogłyby mocno zamulać komputery wikipedystów/-ek). Najłatwiej byłoby zablokować zmianę jeśli cel jest przekierowaniem do sekcji. Nux (dyskusja) 01:49, 29 cze 2026 (CEST)
- @Nux " Najłatwiej byłoby zablokować zmianę jeśli cel jest przekierowaniem do sekcji." - rozwiniesz proszę? Przekierowania do sekcji są IMO bardzo sensowne - biogram nieencyklopedycznej samodzielnie osoby można zmienić w kilka linijek w biogramie encyklopedycznego członka rodziny (i zostawić redir do sekcji "Rodzina"); po integracji części treści do artykułu głównego zostaje redir do sekcji itp. W jakich sytuacjach blokowanie rediru do sekcji byłoby warto blokować? Jakby się to odbywało i kto mógłby to robić? --Felis domestica (dyskusja) 11:32, 29 cze 2026 (CEST)
- @Felis domestica nie chodziło o blokowanie tworzenia takich przekierowań, tylko o blokowanie podmiany przekierowania. To znaczy teraz WP:SK (i za pewne disFixer) podmieni Amneris na link do Aida (opera), a przekierowanie jest do sekcji: Aida (opera)#Osoby. Do tej pory nikt chyba nie zwracał na to uwagi, ale po tym co napisał Shirrapal, to w sumie to teraz się zastanawiam, czy taka podmiana linka ma sens. Może w tym wypadku powinien pozostać link do przekierowania?
- Z tego co widzę da się to prosto wykryć w API, z którego i tak korzysta WP:SK, więc ta zmiana byłaby dosyć prosta. Dzięki temu jeśli w przyszłości powstałaby sekcja o Amneris, to wystarczyłoby zmienić cel przekierowania. Nux (dyskusja) 13:20, 29 cze 2026 (CEST)
- @Nux Czyli zablokowane zostałaby podmiana z linku do sekcji artykułu na link do całości artykułu? To faktycznie niezły pomysł. Dzięki za wyjaśnienie :) --Felis domestica (dyskusja) 14:10, 29 cze 2026 (CEST)
- (Dzięki za odpowiedź).
- ad. 1. Wszystko zależy od sytuacji, jeśli znaczenie jest zawarte jednym z głównych (tj. zawartych w definicji/-ach) znaczeń w innym artykule, powinno być chyba raczej przekierowanie, a nie czerwony link (znów, każdy przypadek jest w pewnym sensie indywidualny). I to jest dokładnie sytuacja, o której napisałem.
- ad. 2. Ja to widzę tak, że w takim razie przez 17 lat nikt nie zauważył z tym problemu. Tj. to problem jest pełnoletni ;-) a poważnie, to przez pochopność miałem na myśli zmianę każdego indywidualnego linku, co jak pisałem powinno być indywidualnie ocenione w każdym przypadku. Wieloletnia praktyka stosowania narzędzi do rozwiązania jakiejś kwestii technicznej nie zmienia faktu, że ktoś w mojej ocenie rozwiązał jeden problem techniczny (pewnie istotny, nie neguję), ale nie pomyślał o kwestii znaczenia linków (semantyce, nie tylko czysto technicznych aspektach połączeń w WP). Jak pisałem, samo istnienie przekierowań świadczy o tym, że jest taka potrzeba, a jest, bo są to hasła powszechnie stosowane, i niekoniecznie tożsame z docelowym.
- Sam ten układ link -> hasło (z przekierowaniem) -> art. docelowy niesie ze sobą znaczenie likwidowane w dyskutowanym procesie. Więc tutaj zapytam - jak w takim razie, jeśli hasło wieloznaczne zostanie rozbite na mniejsze hasła, przywrócić prawidłowe znaczenie w linku, w którym zlikwidowano powiązanie z przekierowaniem (które stało się nowym artykułem)? W mojej ocenie jest to niewykonalne, a może to dot. tysięcy art., w każdym znaczenie linka może być inne. Prowadzi to do w pewnym sensie ukrytego, stopniowego chaosu znaczeniowego. Naprawa może nastąpić prawdopodobnie jedynie gdy ktoś zauważy w danym artykule, że link powinien prowadzić do innego art. (jeśli ma świadomość jego istnienia!), co, jakkolwiek możliwe, jest znacznie wolniejszym procesem niż automatycznie usuwanie semantyki powiązań.
- ad. 3. To wiele tłumaczy, co pewnie jest zrozumiałe, bo wiele rzeczy trzeba prostować. Natomiast zawartość znaczeniowa przekierowań, która zostaje zniszczona w takim zautomatyzowanym procesie, wydaje się być nieuwzględniona. To co opisujesz, wielokrotne przekierowania i popsute wielokrotne przekierowania, to zdecydowanie są rzeczy do wykrycia i poprawy przy pomocy narzędzi. Ale, IMHO, nie linki do przekierowań (z uwagi na to co opisałem).
- Pozdrawiam. Shirrapal (dyskusja) 16:42, 29 cze 2026 (CEST)
- @Nux " Najłatwiej byłoby zablokować zmianę jeśli cel jest przekierowaniem do sekcji." - rozwiniesz proszę? Przekierowania do sekcji są IMO bardzo sensowne - biogram nieencyklopedycznej samodzielnie osoby można zmienić w kilka linijek w biogramie encyklopedycznego członka rodziny (i zostawić redir do sekcji "Rodzina"); po integracji części treści do artykułu głównego zostaje redir do sekcji itp. W jakich sytuacjach blokowanie rediru do sekcji byłoby warto blokować? Jakby się to odbywało i kto mógłby to robić? --Felis domestica (dyskusja) 11:32, 29 cze 2026 (CEST)
- @Shirrapal "Prowadzi do kompletnego chaosu w znaczeniach linkowań w artykułach"; "są to hasła powszechnie stosowane, i niekoniecznie tożsame z docelowym"; "Prowadzi to do w pewnym sensie ukrytego, stopniowego chaosu znaczeniowego"; "zawartość znaczeniowa przekierowań, która zostaje zniszczona w takim zautomatyzowanym procesie" - bardzo to wszystko brzmi groźnie i aż dziwne, że faktycznie nikt się od 17 lat nie połapał, że mamy aż taki problem. A podasz może garść przykładów, gdzie taki proces ukrytego, stopniowego chaosu i znaczeniowego doprowadził do kompletnego chaosu w znaczeniach? Bo szczerze mówiąc, siedzę na PlWiki niemal tak długo jak kol. DisFixer i choć widziałem liczne błędne linki, w tym nieco stworzonych za pomocą DisFixera, to aż tak dramatycznej sytuacji nie widzę - ale może mnie zżerać rutyna i nie dostrzegam rzeczy oczywistych --Felis domestica (dyskusja) 21:43, 29 cze 2026 (CEST)
- Niestety nie jestem tak biegły w czytaniu tysięcy art. i dogłębnym analizowaniu każdego z linków i powiązanych znaczeniowo artykułów. Może jakiś AI kiedyś będzie (może zresztą z tego względu nie warto zawracać sobie tym co piszę głowy...). To co piszę to moje wnioski z obserwacji zmian jakie są dokonywane i odrobiny wyobraźni do czego to prowadzi. Mogę się tutaj oczywiście mylić, natomiast rzuciłem sprawę do przemyślenia, bo w mojej ocenie problem potencjalnie jest. Jeśli np. w angielskiej WP jest pod tym względem inaczej to być może są po temu jakieś przesłanki (nie twierdzę, że we wszystkim trzeba się wzorować na en. czy jakiejkolwiek innej, ale warto korzystać z doświadczeń, może mieli jakieś wnioski na ten temat).
- Sądzę, że warto odpowiedzieć na pytanie zadane przeze mnie powyżej: jak po zmianie z przekierowania na hasło docelowe znaleźć miejsca i poprawić/przywrócić prawidłowe linkowania w sytuacji gdy hasło wieloznaczne (z wieloma terminami prowadzącymi poprzez przekierowania do niego) zostanie rozbite na osobne hasła? Takie sytuacje są bardzo trudne do wykrycia i poprawienia. Więc po prostu nikt tego nie zauważa (łącznie ze mną...), z wyj. sytuacji gdy konkretnie zacznie się ktoś przyglądać linkowi i istniejącym w WP powiązanym znaczeniowo artykułom. Przyznajesz, że widziałeś błędne linki stworzone automatami. To ja sobie zadaję pytanie - to w takim razie ilu tak zmienionych nieprawidłowo linków nie zauważyłeś?
- Z drugiej strony być może problem ten jest sporadyczny (rzadko dzieli się hasła) i znika przy odpowiedniej ilości edytujących. Więc może, tak jak piszesz, problemu żadnego (realnie) z tym nie ma. Mnie się wydaje, że problem z tym może być, tylko jest to trudne do wykrycia, bo z pozoru wszystko wygląda (technicznie) ok. Shirrapal (dyskusja) 22:51, 29 cze 2026 (CEST)
- "gdy hasło wieloznaczne (z wieloma terminami prowadzącymi poprzez przekierowania do niego) zostanie rozbite na osobne hasła" - dasz jakiś konkretny przykład? Bo zgaduję, ale nie wiem, czy mam rację, że chodzi o taki proces: hasło [[dżdżownica]] ktoś rediruje na [[glista]], potem ktoś inny przerabia [[glista]] na disambig i wreszcie jeszcze ktoś podczas likwidacji disambiga doprowadza do stworzenia przekierowania o postaci [[glista ludzka|dżdżownica]]? Potencjalnie to możliwe. Siłą rzeczy nie mogę się wypowiadać o rzeczach, których nie widziałem ;) ale z tego co widziałem, nie sądzę, by błędne linki były produkowane przez disFixer częściej niż bez niego. Większość błędnych linków to (IMHO) wynik nieintuicyjnych nazw haseł - przykładowo, jak szybko zgadnąć, czy wojewoda wileński Mikołaj Radziwiłł to Mikołaj Radziwiłł Rudy czy Mikołaj Radziwiłł (1515–1565)? --Felis domestica (dyskusja) 01:44, 30 cze 2026 (CEST)
- Nie chodzi mi o wszystkie błędne linki (np. nieintuicyjne nazwy. o których piszesz), tylko i wyłącznie o konkretny wynik procesu, który opisałem. Przykład:
- 1. Załóżmy, że istnieje hasło Warszawa, w którym są opisane wszystkie Warszawy (to niekoniecznie disabig, są takie art.), czyli Warszawa (w stanie jakimstam), Warszawa (samochód) etc., i istnieją strony (przekierowania) do art. Warszawa ze wszystkich znaczeń; do poszczególnych przekierowań (np. Warszawa (samochod)) są linki z różnych art. (np. w art. Historia motoryzacji w Polsce pewnie by się znalazła Warszawa (samochód))
- 2. Linki do przekierowań do art. Warszawa (np. do Warszawa (samochód)) zostają (automatycznie lub ręcznie, w każdym razie zgodnie z panującym zwyczajem) zastąpione linkami do art. Warszawa
- 3. Art. Warszawa zostaje rozbity na art. Warszawa, Warszawa (samochód) etc. czyli przekierowania zostają zastąpione artykułami.
- 4. Po 3. link w Historia motoryzacji w Polsce (i wszystkich art. z linkami do przekierowań) prowadzą (nieprawidłowo) do art. Warszawa (zapewne o mieście, które niewątpliwie jest najważniejszym hasłem spośród Warszaw)
- Gdyby nie zrobiono 2. to nie byłoby problemu 4.
- Nie jest to jakiś bardzo częsty przypadek, że tak się dzieje, ale jednak ma miejsce. Moja wątpliwość jest odnośnie wykonywania czynności 2., która, jak rozumiem, jest zwyczajowa w PlWP. Pytanie moje jest czy wykonywanie tego daje więcej korzyści czy przysparza problemów (takich jak opisany).
- W kontekście tego problemu w mojej ocenie lepszym rozwiązaniem wydaje się pozostawienie linków do przekierowań. Natomiast być może są inne, ważniejsze przyczyny, dla których jednak warto to robić. Shirrapal (dyskusja) 11:51, 30 cze 2026 (CEST)
- Btw. akurat Warszawa to może nie jest najlepszy przykład dla samych przekierowań, bo przekierowań takich jak Warszawa (samochod) raczej się nie robi, ale chodzi o cokolwiek wieloznacznego, przypadek, w którym istnieją po prostu są różne hasła (przekierowania) do czegoś i linki do tych przekierowań. Shirrapal (dyskusja) 12:02, 30 cze 2026 (CEST)
- @Shirrapal no właśnie w praktyce nie robi się takich przekierowań. Nux (dyskusja) 13:59, 30 cze 2026 (CEST)
- W tym przypadku (jedno hasło wieloznaczne) nie, natomiast istniejące przekierowania są z wielu różnych haseł. Przykład ilustrował jedynie opisywany mechanizm. Shirrapal (dyskusja) 14:09, 30 cze 2026 (CEST)
- @Shirrapal no właśnie w praktyce nie robi się takich przekierowań. Nux (dyskusja) 13:59, 30 cze 2026 (CEST)
- Btw. akurat Warszawa to może nie jest najlepszy przykład dla samych przekierowań, bo przekierowań takich jak Warszawa (samochod) raczej się nie robi, ale chodzi o cokolwiek wieloznacznego, przypadek, w którym istnieją po prostu są różne hasła (przekierowania) do czegoś i linki do tych przekierowań. Shirrapal (dyskusja) 12:02, 30 cze 2026 (CEST)
- @Shirrapal jeśli stawiasz silne tezy, to Ty powinieneś je udowodnić. Jeśli nie chcesz przeglądać artykułów i nie umiesz podać nawet pojedynczych przykładów, to dyskusja staje się pusta. Między teorią a praktyką jest taka różnica, że zachowanie ludzi zmienia się zależnie od otoczenia – pisałem o tym na początku tej dyskusji. Nux (dyskusja) 09:37, 30 cze 2026 (CEST)
- Znasz kawał o bacy, który siedzi na gałęzi, którą odcina? ("Spadniecie, baco", - "Eee, nie spadnę...") Jakoś dziwnie akurat w Polsce wszędzie się spotyka sytuacje, w których wiadomo, że z czymś jest potencjalny problem, ale reakcja jest dopiero po tym jak już coś się stanie (niedawny przykład z mojego miasta - nie koszono poboczy przy pewnej drodze (co powodowało problemy z widoczością) do czasu gdy doszło do wypadku z dzikiem; dzień po wypadku wszystko było uporządkowane). Tyle w temacie wymogu konieczności "udowadniania" każdej tezy o potencjalnym problemie bez praktycznego przykładu. Są rzeczy oczywiste wynikające z elementarnej logiki. Jeśli wyjaśnienie, które napisałem nie wystarcza to raczej faktycznie nie ma o czym dyskutować. Zadałem dość oczywiste pytanie, na które nie ma na razie odpowiedzi.
- Rzuciłem temat do dyskusji i przemyślenia. Jeśli nikt poza mną nie widzi opisanego problemu, i w ogóle nikogo nie interesuje przemyślenie potencjalnych problemów bez jakichś "dowodów", to chyba faktycznie szkoda czasu.
- Być może w praktyce jest, jak piszesz, jest OK. Ja mam do tego wątpliwości, błędne linki (poza czerwonymi) nie są widoczne na pierwszy rzut oka.
Shirrapal (dyskusja) 14:28, 30 cze 2026 (CEST)- @Shirrapal ale wiesz, to nie jest tak, że baca ucina gałąź. Ty mówisz, że baca ucina gałąź, a w rzeczywistości on rzeźbi w gałęziach od 17 lat i od 17 lat z sukcesami wystawia te rzeźby dla turystów ;). Być może kilka razy się zaciął dłutem, ale nie ma tragedii :). Nux (dyskusja) 21:02, 30 cze 2026 (CEST)
- "gdy hasło wieloznaczne (z wieloma terminami prowadzącymi poprzez przekierowania do niego) zostanie rozbite na osobne hasła" - dasz jakiś konkretny przykład? Bo zgaduję, ale nie wiem, czy mam rację, że chodzi o taki proces: hasło [[dżdżownica]] ktoś rediruje na [[glista]], potem ktoś inny przerabia [[glista]] na disambig i wreszcie jeszcze ktoś podczas likwidacji disambiga doprowadza do stworzenia przekierowania o postaci [[glista ludzka|dżdżownica]]? Potencjalnie to możliwe. Siłą rzeczy nie mogę się wypowiadać o rzeczach, których nie widziałem ;) ale z tego co widziałem, nie sądzę, by błędne linki były produkowane przez disFixer częściej niż bez niego. Większość błędnych linków to (IMHO) wynik nieintuicyjnych nazw haseł - przykładowo, jak szybko zgadnąć, czy wojewoda wileński Mikołaj Radziwiłł to Mikołaj Radziwiłł Rudy czy Mikołaj Radziwiłł (1515–1565)? --Felis domestica (dyskusja) 01:44, 30 cze 2026 (CEST)
- @Shirrapal "Prowadzi do kompletnego chaosu w znaczeniach linkowań w artykułach"; "są to hasła powszechnie stosowane, i niekoniecznie tożsame z docelowym"; "Prowadzi to do w pewnym sensie ukrytego, stopniowego chaosu znaczeniowego"; "zawartość znaczeniowa przekierowań, która zostaje zniszczona w takim zautomatyzowanym procesie" - bardzo to wszystko brzmi groźnie i aż dziwne, że faktycznie nikt się od 17 lat nie połapał, że mamy aż taki problem. A podasz może garść przykładów, gdzie taki proces ukrytego, stopniowego chaosu i znaczeniowego doprowadził do kompletnego chaosu w znaczeniach? Bo szczerze mówiąc, siedzę na PlWiki niemal tak długo jak kol. DisFixer i choć widziałem liczne błędne linki, w tym nieco stworzonych za pomocą DisFixera, to aż tak dramatycznej sytuacji nie widzę - ale może mnie zżerać rutyna i nie dostrzegam rzeczy oczywistych --Felis domestica (dyskusja) 21:43, 29 cze 2026 (CEST)
- Czyli znowu mamy szukać rozwiązania nieistniejącego problemu. Szkoda czasu. A błędne przekierowania trzeba ekować/usuwać (w zależności od poziomu uprawnień) i tyle. Wtedy nie ma problemu z ich podmianą. ~malarz pl PISZ 13:10, 30 cze 2026 (CEST)
- Hmm. Chyba nigdzie nie pisałem o błędnych przekierowaniach tylko o operacjach na linkach... Chodzi (jeszcze raz, w skrócie) o zmianę prawidłowych linków do prawidłowych przekierowań na linki bezpośrednie do art., co znaczeniowo niekoniecznie jest prawidłowe i może powodować problemy w przyszłości (przykład powyżej).
- To czy opisany problem istnieje czy nie jest tematem dyskusji. Sprawa, jak widać, jest nie całkiem oczywista. Shirrapal (dyskusja) 14:03, 30 cze 2026 (CEST)
- Jak najbardziej jest tematem. Jak problem nie istnieje to należy tę dyskusję zamknąć. Szkoda klawiatur. Więc zacznij może w końcu od pokazania kilku przykładów, gdzie problem wystąpił (przed rozpoczęciem tej dyskusji). ~malarz pl PISZ 14:27, 30 cze 2026 (CEST)
- Mowa o potencjalnym problemie, który może występować (dalsza część odp. powyżej, z kawałem o bacy).
- Jeśli brak merytorycznego zainteresowania tematem to zamykamy dyskusję bo szkoda czasu. Shirrapal (dyskusja) 14:49, 30 cze 2026 (CEST)
Współrzędne a Wikidane
[edytuj | edytuj kod]Współrzędne z infoboksów na plwiki mają niekompatybilny z wikidanymi format: 54°21′15,00″N 18°39′06,07″E W sensie nie da się ich bezpośrednio przekleić do Wikidanych, tylko trzeba wejść np. w geohack. Wystarczy, że dodamy przecinek: 54° 21′ 15″ N, 18° 39′ 6.07″ E i już jest kompatybilnie. Może dałoby się to zmienić, żeby w infoboksie wyświetlały się one z przecinkiem? Byłoby łatwiej kopiować ręcznie współrzędne do Wikidanych jeśli ktoś nie korzysta z odpowiednich gadżetów. @Paweł Ziemian co myślisz? Gower (dyskusja) 22:01, 1 lip 2026 (CEST)
- No nie wiem. Zapis bez przecinka jest stosowany tutaj od zawsze. Na tę zmianę potrzebne jest szerokie poparcie. Paweł Ziemian (dyskusja) 17:47, 2 lip 2026 (CEST)
- Hm... Pomysł mi się w pierwszej chwili spodobał, ale jak teraz sprawdziłem to niestety nie jest to tylko kwestia przecinka rozdzielającego. Są jeszcze części dziesiętne/setne sekundy kątowej. W języku polskim części dziesiętne są po przecinku, ale wikidane przyjmują tylko wersję angielską (po kropce). Nux (dyskusja) 18:03, 2 lip 2026 (CEST)
- @Nux faktycznie, ale może dobrze by to było jakoś ujednolicić? Gower (dyskusja) 18:37, 2 lip 2026 (CEST)
- Swego czasu sporo naszych współrzędnych z infoboxów kopiowałem do Wikidanych i zwyczajna ręczna zamiana "naszych" przecinków na kropki w standardzie WD (co przykładowo uczyniłem przed chwilą chociażby tu) nigdy nie była jakimś znaczącym problemem. Gabriel3 • dyskusja. 19:42, 2 lip 2026 (CEST)
- @Gabriel3 ja to robię gadżetem więc nic nie muszę zmieniać, ale nie każdy ma gadżety lub jest ich świadomy. Gower (dyskusja) 19:55, 2 lip 2026 (CEST)
- Dodałem zgłoszenie o wsparciu polskiej notacji na Wikidanych: phab:T431187. --Nux (dyskusja) 12:01, 5 lip 2026 (CEST)
Potencjalny błąd w Szablon:Cytuj
[edytuj | edytuj kod]Szablon:Cytuj po umieszczeniu w nim argumentu |autor = admin wyświetla jako autora n (przykład: Alcomindz). Czy jest to działanie zamierzone, czy znany bug? Jeż0216 (dyskusja) 15:44, 6 lip 2026 (CEST)
- Zamierzone. W podobnych przypadkach (np. nazwa instytucji) trzeba autora podać w cudzysłowie:
|autor = "admin". W tym konkretnym nic bym nie wpisywał. Revsson (dyskusja) 16:02, 6 lip 2026 (CEST) - [KE] Obojętnie co się wpisze, jeżeli są same małe litery, to szablon wyświetla tylko ostatnią literę. Szablon oczekuje w tym polu dużej litery jako początku imienia/nazwiska. Zawsze można wyłączyć interpretację imion i nazwisk przez wpisanie
|autor = *adminlub|autor = "admin". A najlepiej w ogóle nie wpisywać nic w takiej sytuacji – gdy prawdziwy autor nie jest znany. Ping Paweł Ziemian. Michał Ski (dyskusja) 16:09, 6 lip 2026 (CEST) - Taka informacja jest raczej zbędna w opisie bibliograficznym i ja bym jej w ogóle nie podawał (tak samo jak „autorów” na niektórych portalach typu „aj/pf/PAP”). Wostr (dyskusja) 16:14, 6 lip 2026 (CEST)
Wiadomości techniczne: 2026-28
[edytuj | edytuj kod]Najnowsze wiadomości ze środowiska technicznego Wikimedia. Poinformuj innych użytkowników o tych zmianach. Nie wszystkie zmiany będą dotyczyć ciebie lub twojej wiki. Dostępne są tłumaczenia na inne języki.
Komunikaty dla edytorów
Zobacz wszystkie 34 kwestie, zgłoszone przez społeczność, które naprawiono w ostatnim tygodniu. Na przykład problem, w którym wyniki paska wyszukiwania w Wikidanych pokazywały wyniki w języku angielskim zamiast używać odpowiedniej wersji językowej dla użytkowników wariantów językowych, został rozwiązany. Sugestie wyszukiwania będą teraz wyświetlane w języku zgodnym z kolejnością języków zapasowych.
Komunikaty dla edytorów technicznych
- W ramach przygotowań do kampanii Celebrate Women planowanej na marzec 2027, zespół Fundacji Wikimedia Content Enablement przygotował ankietę z 22 pytaniami na temat zaangażowania w sprawy techniczne kobiet (i osób identyfikujących się jako kobiety) w projektach Wikimedia. Jej wypełnienie zajmie około 15–20 minut i będzie dostępna do 20 lipca 2026. Z pytaniami można zapoznać się też na wiki.
- Rozszerzenie do pisania nut "Score" obsługuje teraz renderowanie zapisów nutowych jako obrazy SVG, a nie tylko PNG, co realizuje dawną prośbę oraz rozwiązuje problemy z jakością grafik. Oba formaty są wskazywane dla przeglądarek - wersja PNG w atrybucie
srci SVG w atrybuciesrcset. - Nowy parser, Parsoid jest wdrażany na kolejne wiki, dzięki czemu będzie można łatwiej wdrażać nowe możliwości związane z czytaniem i edytowaniem. Włączono go na francuskojęzycznej Wikipedii, co sprawia, że osiągnięto już generowanie przez niego 78.9% wyświetleń stron w Wikipedii. W tym tygodniu nastąpi wdrożenie na anglojęzyczną wersję Wikipedii na komputerach stacjonarnych.
Szczegółowe informacje o zmianach w kodzie, które zostaną wdrożone w tym tygodniu: MediaWiki
Wnikając w szczegóły
- Został opublikowany post na blogu podsumowujący Wikimedia Hackathon 2026. Omawiane są w nim projekty, sesje i aktywności jakie odbyły się na tegorocznym wydarzeniu, a także wskazano wstępne plany na Wikimedia Hackathon 2027.
Wiadomości techniczne przygotowane przez redaktorów Tech News i wysłane przez bota • Dołącz do zespołu • Przetłumacz na swój język • Uzyskaj pomoc • Wyraź swoją opinię • Subskrybuj lub zrezygnuj z subskrypcji.
MediaWiki message delivery 15:56, 6 lip 2026 (CEST)
Załatwione ~Cybularny Napisz coś ✉ 16:25, 6 lip 2026 (CEST)
W infoboksie wyświetla się opis "Położenie na mapie Włoch", ale nie wyświetla mapy Włoch tylko "Map of comune of Favara". Prośba o interwencję techniczną. Abraham (dyskusja) 07:12, 7 lip 2026 (CEST)
- Poprawiłem, jako położenie miejscowości na mapie gminy Favara. Przydała by się druga mapka, z położeniem gminy.
Albo drugi infobox dla miejscowości, bo obecny jest dla gminy. MarMi wiki (dyskusja) 15:50, 7 lip 2026 (CEST)
Niemożliwe przekierowanie
[edytuj | edytuj kod]Nie udaje mi się wykonać przekierowania trzęśnik → Phaeotremella, gdyż prowadzi ono do artykułu Trześnik. Jeżeli ktoś wie jak to zrobić – to bardzo proszę to zrobić. Selso (dyskusja) 08:11, 10 lip 2026 (CEST)
- Selso:
Załatwione, jest trzęśnik. A na przyszłość podpowiedź: Jeżeli w okienku wyszukiwania wpisywałeś „trzęśnik”, a po kliknięciu w guzik Szukaj lądowałeś w haśle Trześnik, to rób inaczej: wpisz „trzęśnik”, ale nie klikaj w Szukaj, tylko na wyświetlonej liście podpowiedzi popatrz na sam dół i kliknij w Szukaj stron zawierających trzęśnik. Wtedy pojawi się informacja o braku takiego hasła i opcja jego utworzenia (tak jest w domyślnej skórce Wektor 2022, w innych może wyglądać to nieco inaczej, ale idea jest taka sama). - A tak przy okazji: nie wiem, jak to osiągnąłeś, ale spójrz na diffa swojego zgłoszenia. :-) Zrewertowałem te zmiany, zostawiając tylko zgłoszenie. Michał Ski (dyskusja) 08:56, 10 lip 2026 (CEST)
- @Michał Ski Też nie wiem jak to się stało. A za poprawki i info dzięki. Selso (dyskusja) 09:21, 10 lip 2026 (CEST)
- @Selso - masz dodane w gadzetach sprzątanie kodu od Beno. Spora część tych zmian jest takimi typowymi zmianami od Beno - podmiany cudzysłowów, zamiana "30 maj" na "30 maja" itp. Więc jakoś musiał się odpalić i dlatego tak wyszło. PMG (dyskusja) 12:16, 10 lip 2026 (CEST)
- Dlatego lepiej utworzyć nowy wątek klikając w
Dodaj tematalboNowy wątekzamiast edytować całą stronę. :-) Michał Ski (dyskusja) 14:01, 10 lip 2026 (CEST)
- Dlatego lepiej utworzyć nowy wątek klikając w
- @Selso - masz dodane w gadzetach sprzątanie kodu od Beno. Spora część tych zmian jest takimi typowymi zmianami od Beno - podmiany cudzysłowów, zamiana "30 maj" na "30 maja" itp. Więc jakoś musiał się odpalić i dlatego tak wyszło. PMG (dyskusja) 12:16, 10 lip 2026 (CEST)
- @Michał Ski Też nie wiem jak to się stało. A za poprawki i info dzięki. Selso (dyskusja) 09:21, 10 lip 2026 (CEST)
WP:SK i ref za cyframi i kropką
[edytuj | edytuj kod]Wygląda, że WP:SK nie poprawia kropki, gdy jest taki kod 0000169923.<ref name="KRS"/> – diff. @Jcubic (dyskusja) 11:24, 10 lip 2026 (CEST)
- Kropka po liczbie nie zawsze jest kropką kończącą zdanie. Przykład "XYZ wystąpił w 30.<ref> i 32.<ref> konkursie ABC<ref>." ~malarz pl PISZ 17:34, 10 lip 2026 (CEST)
- Faktycznie
Załatwione @Jcubic (dyskusja) 23:18, 10 lip 2026 (CEST)
VE nie wykrywa usunięcia znaku . lub ; za "potrzebny przypis"
[edytuj | edytuj kod] - czy tylko u mnie VE nie wykrywa usunięcia kropki lub średnika po szablonie "potrzebny przypis"?
Zamiast usuwać, tylko ukrywa - znak pojawia się znowu, jak kliknie się wskaźnikiem gdzieś indziej, a potem na prawo od ukrytego znaku. MarMi wiki (dyskusja) 00:00, 13 lip 2026 (CEST)
- MarMi wiki: u mnie nic takiego się nie dzieje, skasowana kropka ginie na dobre, a na podglądzie przed zapisaniem zmian widać, że jest usunięta (Firefox, niezalogowany). Ale w tej edycji usunąłeś tę kropkę, razem ze znacznikami kursywy, więc może tylko coś z wyświetlaniem Ci się dzieje. Michał Ski (dyskusja) 11:16, 13 lip 2026 (CEST)
- To widocznie coś się u mnie zadziało przy edycji tej wersji artykułu.
Zmiana: poprzednio "Zapisz zmiany" w VE pozostawało wyszarzone, teraz z kolei jest aktywne już po wejściu w tryb edycji (kontrola zmian pokazuje "Brak zmian"). W edytorze kodu jest to samo (aktywny "Zapisz zmiany", ale usuwanie działa tak jak powinno).
Edge 150.0.4078.65, jakby co. MarMi wiki (dyskusja) 17:53, 13 lip 2026 (CEST)
- To widocznie coś się u mnie zadziało przy edycji tej wersji artykułu.
Wiadomości techniczne: 2026-29
[edytuj | edytuj kod]Najnowsze wiadomości ze środowiska technicznego Wikimedia. Poinformuj innych użytkowników o tych zmianach. Nie wszystkie zmiany będą dotyczyć ciebie lub twojej wiki. Dostępne są tłumaczenia na inne języki.
Komunikaty dla edytorów
- Poprawa stylu to narzędzie pomagające nowicjuszom znaleźć fragmenty artykułów Wikipedii, które zawierają język nieencyklopedyczny, zachęcając do poprawy brzmienia. Ta funkcja była testowana metodą A/B na Wikipediach w językach arabskim, angielskim, francuskim i portugalskim, gdzie wskaźnik ukończenia zadania przez nowicjuszy zwiększył się o 38.7% w porównaniu z zadaniem Redakcja, bez obniżenia jakości edycji. Test zakończył się 9 lipca i ta funkcja jest już dostępna dla wszystkich na tych wiki, a można ją konfigurować za pomocą Konfigurowania przez społeczność. Planujemy wprowadzić to zadanie na kolejne wiki.
- Konfigurowanie przez społeczność: 16 lipca zostanie dodane ustawienie do włączania automatycznego wypisywania przewodników na podstawie określonych kryteriów (na niektórych wiki) aby lista wikiprzewodników była świeża. Przewodnicy to doświadczeni redaktorzy, którzy zadeklarowali pomoc nowym użytkownikom przy wykorzystaniu narzędzi Growth. Administratorzy mogą już przygotować ustawienia na Special:CommunityConfiguration/Mentorship; wejdą one natomiast w życie od czwartku.
Zobacz wszystkie 38 kwestii, zgłoszonych przez społeczność, które naprawiono w ostatnim tygodniu. Na przykład problem, w którym niektórzy użytkownicy aplikacji Wikipedii na Androida byli wylogowywani zaraz po zalogowaniu, uniemożliwiając im pozostawanie zalogowanym i edytowanie stron, został już rozwiązany.
Komunikaty dla edytorów technicznych
- Edytowanie strony za pomocą skryptów użytkownika lub gadżetów powodowało, że etykiety listy obserwowanych, które użytkownik przypisał do danej strony, były czyszczone. Zostało to naprawione.
- Aby ominąć błąd w przeglądarce Safari (zobacz phab:T425211), na wiki z włączonym Parsoidem, adresy docelowe wikilinków są teraz adresami url bezwzględnymi zamiast względnymi do protokołu. Wyniki REST API nadal będą generowane jak dotychczas, czyli linki będą względne do protokołu. Gadżety, skrypty użytkowników, boty i CSS być może będzie trzeba dostosować, jeśli zależą od rodzaju względności adresów url w atrybutach href wikilinków.
Szczegółowe informacje o zmianach w kodzie, które zostaną wdrożone w tym tygodniu: MediaWiki
Wnikając w szczegóły
- Zespół Fundacji Wikimedia Foundation, Experiment Platform, opublikował post na blogu skupiający się na pierwszym roku eksperymentów strukturyzowanych. Podkreśla udane eksperymentu, takie jak kontrola wklejania, sprawdzanie przypisów i stylu, które to poprawiły jakość edytowania i wdrożono je u kolejnych użytkowników. Wspomniano także o eksperymentach, które nie doprowadziły do zmian w produktach. Czytaj więcej.
Wiadomości techniczne przygotowane przez redaktorów Tech News i wysłane przez bota • Dołącz do zespołu • Przetłumacz na swój język • Uzyskaj pomoc • Wyraź swoją opinię • Subskrybuj lub zrezygnuj z subskrypcji.
MediaWiki message delivery 18:10, 13 lip 2026 (CEST)
Załatwione ~Cybularny Napisz coś ✉ 18:20, 13 lip 2026 (CEST)
