Wikipedia:Kawiarenka/Kwestie techniczne dyskusja/Archiwum/2024-lipiec

Podświetlanie w ODN

Do niedawna kliknięcie w przypis typu {{odn|cośtam}} przerzucało do odpowiedniej pozycji bibliograficznej wraz z jej delikatnym podświetleniem, co było bardzo dobrym rozwiązaniem. Teraz wprawdzie dalej przerzuca, ale bez podświetlenia. Sprawdzałem FF/Edge, jako zalogowany (Książka) i IP – wszędzie tak samo. Można prosić o przywrócenie podświetlania? Michał Ski (dyskusja) 08:44, 1 lip 2024 (CEST)

Mój błąd – usunąłem ostatnio nadmiarowe reguły do kolorowania aktywnego przypisu (to robi domyślnie MediaWiki) i nie zauważyłem, że aktywnych {{odn}} MW nie koloruje samo w sobie. Przywróciłem odpowiednie style. Załatwione. Msz2001 (dyskusja) 10:43, 1 lip 2024 (CEST)

Wiadomości techniczne: 2024-27

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.

Ostatnie zmiany

• Tryb ciemny stanie się dostępny dla wszystkich (zalogowanych i niezalogowanych) w ciągu najbliższych trzech tygodni, poczynając od wersji mobilnej. Spełni się tym samym jedno z najbardziej pożądanych życzeń społeczności i pomoże to w korzystaniu z wiki w ciemnym otoczeniu. Użytkownicy będą mogli wyświetlać strony użytkowników oraz portale w trybie ciemnym. Więcej informacji w najnowszym komunikacie od zespołu Web. [1]
• Zalogowani użytkownicy mogą teraz ustawić globalną preferencje dla rozmiaru czcionki i trybu ciemnego. Stało się to dzięki połączonym wysiłkom zespołów w Fundacji. Pozwala to wikimedianom korzystać z wielu wiki przy spójnych doświadczeniach, np. przełączając tryby jednocześnie na wszystkich wiki. [2]
• Jeśli korzystasz z bardzo starej przeglądarki internetowej, niektóre funkcje mogą nie działać poprawnie na wiki Wikimedia. Dotyczy to Internet Explorera 11 oraz wersji Chrome, Firefoksa i Safari sprzed 2016. Pozwoli to na stosowanie nowszych funkcji CSS i poskutkuje wysyłaniem mniejszych arkuszy stylów do czytelników. [3][4]
• Administratorzy Wikipedii mogą dostosowywać lokalną konfigurację wiki z użyciem Konfiguracji społecznościowej. Została ona wprowadzona, aby pomóc społecznościom dostosowywać, jak działają pewne funkcje (bo każda wiki ma swoje unikatowe potrzeby). W tej chwili administratorzy mogą konfigurować funkcje Growth na swoich wiki, aby w lepszy sposób przyciągać i zatrzymywać nowicjuszy. Więcej opcji zostanie dodanych w najbliższych miesiącach. [5]
• Edytorzy zainteresowani kwestiami językowymi, związanymi ze standardami Unicode, mogą dyskutować o nich w nowej przestrzeni dyskusyjnej na MediaWiki.org. Fundacja Wikimedia jest teraz członkiem Konsorcjum Unicode, a grupa koordynująca może przyglądać się dyskutowanym kwestiom i zwracać na nie uwagę Konsorcjum, jeśli będzie to słuszne.
• Jedna nowa wiki została utworzona: Wikipedia w języku batak mandailing (w:btm:) [6]

Problemy

• Edytorzy mogą znowu klikać linki w podglądzie przypisu w edytorze wizualnym, dzięki poprawce wdrożonej przez zespół Editing. [7]

Przyszłe zmiany

• Prosimy o pomoc w poprawie jakości Tech News, poprzez wypełnienie tej krótkiej ankiety. Chcemy lepiej poznać potrzeby czytelników wiadomości technicznych. Ankieta będzie otwarta przez dwa tygodnie. Badanie jest objęte niniejszą deklaracją prywatności. Ankieta dostępna jest też w tłumaczeniu na wybrane języki.

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 01:56, 2 lip 2024 (CEST)

Załatwione, ~Cybularny ^{Napisz coś ✉} 09:37, 2 lip 2024 (CEST)

Kod mapy Malawi

Dzień dobry. Kiedy doczekamy się geograficznej wersji mapy Malawi? Jak np tu. Drzewianin (dyskusja) 16:25, 4 lip 2024 (CEST)

@Drzewianin, dzień dobry. Mówisz i masz. :) Gabriel3 (dyskusja) 17:09, 4 lip 2024 (CEST)

Ekstra:) Drzewianin (dyskusja) 17:25, 4 lip 2024 (CEST)

Dla bota: Załatwione Msz2001 (dyskusja) 17:52, 6 lip 2024 (CEST)

Niebieskie linki do nieistniejących stron dyskusji

Gdy wchodzę dziś na stronę dowolnego hasła, którego strona dyskusji nie istnieje, link do niej wyświetla się na niebiesko. Dopiero po kliknięciu go (i upewnieniu się, że faktycznie tej strony dyskusji nie ma), gdy wrócę do tego samego hasła, link do jego dyskusji zmienia kolor na prawidłowo czerwony. Salicyna (dyskusja) 19:54, 21 cze 2024 (CEST)

• @Msz2001 grzebałeś przed chwilą w cssach. Może to Twoje dzieło. ~malarz pl ^PISZ 20:10, 21 cze 2024 (CEST)

  Nie, widziałem już takie zachowanie wcześniej. Msz2001 (dyskusja) 20:12, 21 cze 2024 (CEST)

• Szczerze mówiąc, to gdyby to zostawić dla niezalogowanych, to może nawet byłoby lepsze – po otwarciu i tak wyświetla się info o możliwości rozpoczęcia dyskusji, więc dla nieobeznanych w temacie dyskusja pusta nie jest, a może czerwony kolor zniechęca do tworzenia nowych wpisów w dyskusjach? Dla zalogowanych, zwłaszcza nieco bardziej doświadczonych, to istotnie utrudnienie. Wostr (dyskusja) 15:49, 22 cze 2024 (CEST)

  Z taką argumentacją to można by zrobić też linki do wszystkich nieistniejących haseł niebieskie, bo przecież można je utworzyć... Mi osobiście to bardzo przeszkadza. Gdy wchodzę na kolejne hasło by je poprawić/rozbudować/uźródłowić, staram się pamiętać by zawsze wejść najpierw na stronę dyskusji o ile istnieje, by zapoznać się z ewentualnymi uwagami na temat hasła jakie mogły się pojawić. Teraz mylący niebieski link zmusza mnie do wchodzenia na każdą stronę dyskusji, i w większości przypadków okazuje się że jej nie ma... Salicyna (dyskusja) 17:25, 22 cze 2024 (CEST)

  Przecież napisałem, że dla zalogowanych edytorów to utrudnienie... Wostr (dyskusja) 18:33, 22 cze 2024 (CEST)

  Jaka różnica, czy dla zalogowanych czy niezalogowanych? Dla każdego musi to być mylące, jeżeli od lat jest przyjęte we wszystkich wiki, że link czerwony oznacza brak strony, do której on prowadzi, a link niebieski – istnienie tej strony. Salicyna (dyskusja) 18:50, 22 cze 2024 (CEST)

  Zgadzam się z Salicyną. Niebieskie/czerwone to praktycznie element naszego UX. Nadzik (dyskusja) 19:53, 22 cze 2024 (CEST)

  No ja się zupełnie nie zgodzę. Podejrzewam, że dla czytelnika (nie edytora) czerwony link do dyskusji oznacza bardziej, że tam nic nie znajdzie i nie może dyskutować, niż że to jest czerwone, a więc może sobie kliknąć i „utworzyć” stronę dyskusji. Wostr (dyskusja) 21:37, 22 cze 2024 (CEST)

Wydaje się że nie występuje na starym wektorze. MarMi wiki (dyskusja) 21:47, 22 cze 2024 (CEST)

Ani w Książce. Michał Ski (dyskusja) 11:11, 23 cze 2024 (CEST)

• Dzisiaj widzę, że już linki do dyskusji są prawidłowo czerwone. :) Salicyna (dyskusja) 06:57, 8 lip 2024 (CEST)

Załatwione. Michał Ski (dyskusja) 12:18, 8 lip 2024 (CEST)

Wiadomości techniczne: 2024-28

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.

Ostatnie zmiany

• W Fundacji Wikimedia została sformowana grupa zadaniowa, która zastąpi wyłączone rozszerzenie Graph bezpieczniejszymi i łatwiejszymi w wykorzystaniu wykresami (Chart). Możecie zasubskrybować newsletter, aby dostawać informacje o postępach związanych z nowymi wykresami.
• Rozszerzenie CampaignEvents jest teraz dostępne na Meta-wiki oraz Wikipediach w języku igbo i suahili. Może być także wprowadzone na wasze wiki, jeśli poprosicie. Pomaga ono zarządzać wydarzeniami oraz zwiększa ich widoczność, a organizatorom zapewnia narzędzia takie jak rejestracja użytkowników. Aby dowiedzieć się więcej o stanie wdrożenia i jak poprosić o to rozszerzenie na swojej wiki, odwiedźcie stronę CampaignEvents na Meta-wiki.
• Edytorzy, korzystający z aplikacji Wikipedia na iOS, którzy mają ponad 50 edycji, mogą teraz używać funkcji Dodaj ilustrację. Pomaga ona w małych, ale użytecznych edycjach Wikipedii.
• Dziękujemy wszystkim autorom, którzy wnieśli wkład w jądro MediaWiki. Liczba osób, które stworzyły więcej niż 5 poprawek, wzrosła o 25% względem zeszłego roku, dzięki czemu platforma dla projektów Wikimedia może się rozwijać w sposób bardziej zrównoważony.

Problemy

• Problem z zakładką „Dyskusja” w kolorze niebieskim, niezależnie od tego czy strona istnieje, który dotykał Wektora 2022, został naprawiony.

Przyszłe zmiany

• Zespół Trust and Safety Product chciałby, aby wprowadzenie kont tymczasowych odbyło się z możliwie najmniejszym wpływem na działanie gadżetów i narzędzi. Programiści-wolontariusze, w tym utrzymujący gadżety i skrypty na wiki, są proszeni o aktualizację swojego kodu, aby poprawnie obsługiwał konta tymczasowe. Zespół przygotował dokumentację, wyjaśniającą, co należy zaktualizować. Dowiedz się więcej.

Badanie Tech News

• Prosimy o pomoc w poprawie jakości Tech News, poprzez wypełnienie tej krótkiej ankiety. Chcemy lepiej poznać potrzeby czytelników wiadomości technicznych. Ankieta będzie otwarta jeszcze przez tydzień. Badanie jest objęte niniejszą deklaracją prywatności. Ankieta dostępna jest też w tłumaczeniu na wybrane języki.

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 23:29, 8 lip 2024 (CEST)

Załatwione. Nadzik (dyskusja) 23:35, 8 lip 2024 (CEST)

Wiadomości techniczne: 2024-29

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.

Badanie Tech News

• Prosimy o pomoc w poprawie jakości Tech News, poprzez wypełnienie tej krótkiej ankiety. Chcemy lepiej poznać potrzeby czytelników wiadomości technicznych. Ankieta będzie otwarta jeszcze przez trzy dni. Badanie jest objęte niniejszą deklaracją prywatności. Ankieta dostępna jest też w tłumaczeniu na wybrane języki.

Ostatnie zmiany

• Deweloperzy Wikimedia mogą nadal oficjalnie używać zarówno Gerrita, jak i GitLaba. 24 czerwca Fundacja Wikimedia zdecydowała, że będzie dalej wspierać rozwój oprogramowania na obu platformach. Gerrit i GitLab to repozytoria kodu wykorzystywane przez programistów do tworzenia i przeglądania kodu, działającego w ramach MediaWiki oraz narzędzi autorstwa wolontariuszy. Ta decyzja ma na celu zachować produktywność programistów i nie dopuścić do pojawienia się problemów w procesie przeglądu kodu przez inne osoby. Więcej szczegółów dostępnych jest na stronie Migration status.
• Fundacja Wikimedia zaprasza chętnych do zgłaszania się do Komitetu doradczego Produktu i Technologii (Product and Techology Advisory Council, PTAC). Ta grupa, składająca się z edytorów technicznych i pracowników Fundacji Wikimedia, będzie razem współpracować, aby nasza platforma technologiczna była odporniejsza i lepiej przygotowana na przyszłe wyzwania. Członkowie komitetu ocenią aktywności techniczne w ruchu i będą mieli głos doradczy, abyśmy mogli lepiej budować wielopokoleniowe projekty. Poszukujemy edytorów technicznych z różnych zakątków Ziemi oraz z różnych projektów Wikimedia. Prosimy o zgłaszanie się tutaj do 10 sierpnia.
• Edytorzy z uprawnieniami do wycofywania zmian, którzy korzystają z aplikacji Wikipedia na Androida, mogą korzystać z nowych funkcji Edit Patrol. Zalicza się do nich nowy strumień ostatnich zmian, powiązane linki (takie jak cofnij i anuluj edycję) oraz biblioteka wiadomości w dyskusji, z których można skorzystać podczas patrolowania zmian. Jeśli chcecie, aby na waszej wiki te funkcje były dostępne również dla osób, które nie mają uprawnień do wycofywania, ale osiągną próg liczby edycji, możecie skontaktować się z zespołem. Więcej informacji o projekcie jest dostępnych we wpisie na blogu Diff.
• Edytorzy, którzy mają dostęp do Biblioteki Wikipedii, mogą znowu korzystać z treści w SpringerLinks, niepublikowanych w wolnym dostępie, ponieważ WMF skontaktowała się z nimi w tym celu. Możecie przeczytać więcej o tym i 21 innych zadaniach zgłoszonych przez społeczność, które wykonano w tym tygodniu.

Zmiany w tym tygodniu

• W tym tygodniu tryb ciemny zostanie udostępniony na wybranych Wikipediach, w wersjach komputerowej i mobilnej, dla zalogowanych i wylogowanych użytkowników. Zachęcamy administratorów interfejsu i osoby utrzymujące skrypty do poszukania zakodowanych na twardo kolorów i naprawy ich. Dostępne są rekomendacje dla zgodności z trybem ciemnym.

Przyszłe zmiany

• Zapraszamy osoby funkcyjne i utrzymujące narzędzia, aby testować konta tymczasowe na testwiki od przyszłego tygodnia. Konta tymczasowe podniosą prywatność wylogowanych użytkowników wiki. Nie ma na razie zaplanowanego wdrożenia tych kont na kolejne wiki. Prosimy o podzielenie się swoją opinią i zadawanie pytań w dyskusji projektu. [8]
• Edytorzy, którzy z poziomu edytora wgrywają pliki na Commons podczas edytowania artykułów, albo którzy uczą innych to robić, są zaproszeni do udziału w dyskusji na Commons. Społeczność dyskutuje nad ograniczeniem możliwości przesyłania plików w ten sposób wyłącznie do osób, które mają status automatycznie zatwierdzonych w Commons. Wynika to z dużej liczby plików naruszających prawa autorskie, które w ten sposób przesłano. Krótkie podsumowanie jest dostępne na stronie Commons:Cross-wiki upload a dyskusja toczy się na Commons:Village Pump.

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. Więcej wiadomości można znaleźć w Biuletynie Fundacji Wikimedia.

MediaWiki message delivery 03:28, 16 lip 2024 (CEST)

Załatwione, ~Cybularny ^{Napisz coś ✉} 09:29, 16 lip 2024 (CEST)

Przeglądanie nowych haseł - brak opcji

Zniknęła mi opcja (guzik) do przeglądnięcia nowego hasła. Czy coś się zmieniło w interfejsie? Używam starego monobooka czy jak to się tam nazywa, Masur juhu? 08:57, 14 lip 2024 (CEST)

• Przycisk „Oznacz jako przejrzaną” znajduje się pod artykułem, w ramce „Przejrzyj tę wersję” – jest tak również w Monobooku (np. tutaj). Msz2001 (dyskusja) 10:21, 14 lip 2024 (CEST)
• Można też użyć skrótu klawiaturowego Shift-Alt-S. Michał Ski (dyskusja) 09:13, 15 lip 2024 (CEST)

Załatwione. Michał Ski (dyskusja) 11:49, 16 lip 2024 (CEST)

Porównywanie zmian

Dawny system porównywania zmian nie był może rewelacyjny, ale obecna wersja, która unieczytelnia tekst główny bladoszarą czcionką, usunięte zasłania czerwonym mazianiem, a wprowadzone zasłania mazianiem zielonym jest (dla mnie) nieznośna. Czy da się to jakoś wyłączyć/przywrócić starą wersję/zamienić te mazaje na cienką ramkę, żeby było widać tekst zmieniany? Bo zwykle po parę OZ-etów dziennie przeglądałem, ale teraz to nie dam rady :( Felis domestica (dyskusja) 13:09, 20 lip 2024 (CEST)

@Felis domestica: Czy nie masz przypadkiem włączonego wizulanego porównywania wersji? Otwórz jakiś diff i na górze po prawej stronie powinieneś mieć przełączniki: "Wizualnie"/"Wikikod". Wybierz "Wikikod". tufor (dyskusja) 13:37, 20 lip 2024 (CEST)

A tam nie masz u góry przełączenia wizualnie / wikikod? Ja dopiero po Twoim wpisie zacząłem szukać, gdzie są takie kolory i zobaczyłem te porównania wizualne, średnio to wygląda. Jak nie porównania w wikikodzie to z pewnością da się kolory zmienić w swoim css. Wostr (dyskusja) 13:37, 20 lip 2024 (CEST)

@Tufor, @Wostr Bardzo dziękuję, przełączanie między trybem wizualnym a wikikodem przeoczyłem. Sam nie pamiętam bym włączał, więc pewnie po jakiejś aktualizacji jako domyślny wszedł tryb wizualny - z dość fatalnym układem kolorystycznym IMHO, ale widać nikomu to nie przeszkadza, skoro nikt nie zgłasza potrzeby zmian. Ja sobie wróciłem na kod --Felis domestica (dyskusja) 17:38, 20 lip 2024 (CEST)

Załatwione tufor (dyskusja) 23:07, 20 lip 2024 (CEST)

Kwadraty i sześciany do często używanych

Witam. Czy możliwe jest dodanie do "często używanych" symboli w edytorze wizualnym kwadratów i sześcianów (²,³)? Myślę, że nie tylko ja często używam tych symboli i byłoby to duże ułatwienie. Pozdrawiam i dzięki za ewentualne działania. MOs810 (dyskusja) 20:30, 21 lip 2024 (CEST)

 Komentarz: Należałoby dodać te znaki na tej stronie: MediaWiki:Visualeditor-quick-access-characters.json. tufor (dyskusja) 20:45, 21 lip 2024 (CEST)

Zmiana raczej niekontrowersyjna. @MOs810: wstawiłem je zaraz po innych symbolach matematycznych. Peter Bowman (dyskusja) 22:31, 21 lip 2024 (CEST)

WOW, to już nie będę musiał przełączać się na EKŹ :) Cyku_new (dyskusja) 23:51, 21 lip 2024 (CEST)

Wielkie dzięki (także za szybką reakcję)! Pzdr. MOs810 (dyskusja) 20:57, 22 lip 2024 (CEST)

Załatwione tufor (dyskusja) 21:44, 22 lip 2024 (CEST)

Wiadomości techniczne: 2024-30

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.

Nowe funkcje

• Stewardzi mogą teraz globalnie blokować konta. Przed tą zmianą tylko adresy i zakresy IP mogły być blokowane globalnie. Globalne blokady kont mogą być stosowane w sytuacjach, kiedy niewskazane jest wylogowywanie użytkownika. Globalne zamknięcie konta (podobna funkcja, ale powodująca wylogowanie) nie została zmieniona. Nowa funkcja jest związana z projektem kont tymczasowych, czyli nowego rodzaju kont użytkowników, które zastąpią adresy IP jako sposób identyfikowania anonimowych użytkowników (adresy IP nie będą docelowo widoczne publicznie).
• Później w tym tygodniu użytkownicy wiki Wikimedia zauważą, że interfejs wersji przejrzanych został poprawiony i uspójniony z resztą interfejsu MediaWiki oraz wzornictwem Wikimedia. Doświadczenia użytkowników tego rozszerzenia w wersji mobilnej i skórce Minerva były niespójne, zanim zespół Growth i wolontariusze przenieśli je na bibliotekę Codex. [9]
• Użytkownicy wiki Wikimedia mogą teraz przesyłać prośby o zniknięcie za pomocą strony GlobalVanishRequest. Tej funkcji można użyć, jeśli użytkownik chce przestać korzystać z konta na dobre. Pomaga to ukryć swoje wcześniejsze powiązania, aby lepiej chronić prywatność. Po wykonaniu prośby, konto zostanie zamknięte i będzie mieć zmienioną nazwę. [10]
• Próbowaliście monitorować i rozwiązywać problemy wandalizmu w Wikipedii, korzystając z telefonu? Post na Diffie na temat funkcji patrolowania w aplikacji mobilnej podkreśla niektóre z nowych możliwości, w tym przewijanie przez strumień ostatnich zmian oraz osobistą bibliotekę wiadomości do wysyłania podczas patrolowania z telefonu.
• Współpracownicy Wikimedia i organizacje GLAM (galerie, biblioteki, archiwa i muzea) mogą teraz dowiedzieć się i zmierzyć wpływ, jaki Wikimedia Commons ma na tworzenie wysokiej jakości treści encyklopedycznych za pomocą narzędzia analitycznego Commons Impact Metrics. Oferuje ono organizacjom możliwość analizy takich rzeczy jak edycje miesięcznie w kategorii, najczęściej przeglądane pliki i wykorzystanie obrazów w projektach Wikimedia. Korzystając z tych nowych dumpów danych organizacje GLAM mogą bardziej wiarygodnie mierzyć zwrot z inwestycji w programy wprowadzające treści cyfrowe do Commons. [11]

Wiadomości o projektach

• Zapraszamy do dzielenia się pomysłami na polepszenie działania wiki w ponownie otwartym Badaniu Życzeń Społeczności. Jest ono miejscem, gdzie wolontariusze mogą zgłaszać pomysły („życzenia”), które mogą usprawnić funkcjonowanie wiki. Nowa wersja Listy jest stale otwarta i współpracuje z edytorem wizualnym i wikikodu. Życzenia można zgłaszać w dowolnym języku.

Dowiedz się więcej

• Zastanawialiście się kiedyś, jak oprogramowanie Wikimedia działa w ponad 300 językach? To o 253 języki więcej niż interfejs Google Chrome, i nie jest to przypadek. Zespół Language and Product Localization w Fundacji Wikimedia wspiera Twoją pracę poprzez dostosowanie wszystkich narzędzi i interfejsów używanych do Twojego i innych języków. Dowiedz się więcej o zespole i ich nadchodzącej pracy w Diff.
• Jak Wikimedia mogą budować innowacyjne i eksperymentalne produkty, jeśli muszą utrzymywać tak często używane strony internetowe? Niedawny post na blogu pracownika WMF Johana Jönssona zarysowuje działania inicjatywy WMF Future Audience, której celem nie jest dostarczanie dopieszczonych produktów, ale testowanie pomysłów, takich jak plugin do ChatGPT czy Add a Fact, mających pomóc zanieść Wikimedia w przyszłość.

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. Więcej wiadomości można znaleźć w Biuletynie Fundacji Wikimedia.

MediaWiki message delivery 02:01, 23 lip 2024 (CEST)

Załatwione, ~malarz pl ^PISZ 09:35, 23 lip 2024 (CEST)

Wersje przejrzane i przejście na Codex

Nie sądzę, że to docelowy efekt końcowy, ale wyżej wspominano przechodzenie systemu wersji oznaczonych na Codex, a dzisiaj rozwinięcie zakładki wygląda u mnie jak na zrzucie obok... Wostr (dyskusja) 21:07, 25 lip 2024 (CEST)

@Wostr wyczyść sobie cache w przeglądarce. Wydaje mi się, że trafiłeś w trakcie wdrażania nowej wersji. U mnie na Foksie tego efektu nie widzę w każdym razie. Nux (dyskusja) 23:49, 25 lip 2024 (CEST)

@Nux, nie, to jak nie działało przed moim zgłoszeniem, tak nie działa i teraz. U mnie zarówno w Opera One (wersja: 112.0.5197.30), jak i teraz sprawdzałem na Microsoft Edge (wersja 126.0.2592.113), efekt jest taki sam. Żeby sprawdzić, czy to nie problem na Chromium, odpaliłem tę stronę w Tor Browser i jest jw. Może to i coś u mnie tylko, ale w swoim css-ie nie widzę nic, co mogłoby to powodować. Klasa cdx-info-chip generuje u mnie border-radius: 9999px, max-width: 32rem i display: inline-flex;, po usunięciu których wszystko wyświetla się normalnie jak wcześniej. Wostr (dyskusja) 00:27, 26 lip 2024 (CEST)

• Załatwione. Żadne czyszczenie cache’u nie działało i na każdej przeglądarce wyglądało tak samo, ale po dwóch dniach wygląda to już inaczej. Przy czym ⧼diff-empty⧽ i tak słabo wygląda. Wostr (dyskusja) 16:06, 27 lip 2024 (CEST)

  Dodałem jakby co zgłoszenie na diff-empty phab:T371181 Nux (dyskusja) 16:36, 27 lip 2024 (CEST)

Gerard Bernacki

W haśle pojawiło się u dołu: Błąd w przypisach: Znacznik <ref> o nazwie „Dlaczego na pogrzebie Gerarda Cieślika nie było jego przyjaciela biskupa? Oburzeni kibice Ruchu piszą do papieża”, zdefiniowany w <references>, nie był użyty wcześniej w treści.BŁĄD PRZYPISÓW Można prosić o naprawienie? Dzięki. Abraham (dyskusja) 14:44, 23 lip 2024 (CEST)

• Załatwione. Usunięto zdanie, pozostawiając przypis (w sekcji Przypisy). Wiktoryn <odpowiedź> 17:25, 23 lip 2024 (CEST)
• Dla bota szablon: Załatwione tufor (dyskusja) 16:53, 27 lip 2024 (CEST)

Wiadomości techniczne: 2024-31

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.

Nowe funkcje

• Użytkownicy, korzystający z edytora wizualnego w językach niestosujących cyfr arabskich, np. hinduskim, manipuri czy arabskim, zobaczą zmiany w formatowaniu numeracji przypisów. Jest to efekt uboczny przygotowywania nowej funkcji – rozszerzania przypisów – i przy okazji poprawienia kilku ogólnych problemów z numerowaniem w edytorze wizualnym. Jeśli zauważycie jakieś problemy na swojej wiki, napiszcie na stronie dyskusji projektu.

Błędy

• Niektórzy zalogowani użytkownicy nie mogli wyświetlać ani edytować stron w zeszłym tygodniu. Te błędy wynikały głównie z wprowadzenia nowych reguł lintera, które doprowadziły do problemów z pamięcią podręczną. Naprawiono błędy, a analiza ich przyczyn nadal trwa.
• Użytkownicy mogą korzystać z narzędzia IP Info, aby pozyskiwać informacje o adresach IP. Jest ono dostępne w preferencjach jako funkcja eksperymentalna. Przez kilka dni w zeszłym tygodniu nie było ono dostępne, ale teraz już działa. Dziękujemy Shizhao za zgłoszenie błędu. Możecie przeczytać więcej o tym i 28 innych zgłoszeniach ze strony społeczności, które rozwiązano w ubiegłym tygodniu.

Informacje o projektach

• Do Phabricatora wprowadzono kilka nowych funkcji i usprawnień (autorstwa zespołów Release Engineering i Collaboration Services oraz wolontariuszy), w tym: w wyszukiwarce, nowy system tworzenia zadań, w systemie logowania, wsparcie dla większej liczby języków (dzięki, Pppery), poprawki błędów w wielu przypadkach brzegowych. Więcej szczegółów dostępnych jest w tym podsumowaniu.
• Dostępne są nowe wieści o projekcie przywrócenia wykresów. Zespół wybrał bibliotekę do wizualizacji, rodzaje wykresów, od których należy zacząć oraz gdzie przechowywać definicje wykresów.
• Jedna nowa wiki została utworzona: Wikipodróże po czesku (voy:cs:) [12]

Dowiedz się więcej

• Otwarta została nowa serwerownia Fundacji Wikimedia w São Paulo w Brazyli, która pomaga zmniejszyć czasy ładowania naszych witryn.
• Trwa nowe badanie na temat problemów z procesem przesyłania obrazów.
• Miary wpływu Commons są teraz dostępne poprzez zrzuty danych i API.
• Najnowszy kwartalny Newsletter społeczności technicznej jest już dostępny.

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 01:07, 30 lip 2024 (CEST)

Załatwione, ~Cybularny ^{Napisz coś ✉} 01:10, 30 lip 2024 (CEST)

Problemy z trybem ciemnym

Kilka spostrzeżeń na szybko. Chodzi o niedawno udostępniony tryb ciemny, nie wcześniej istniejący gadżet autorstwa Msz2001. IMO gadżet wizualnie prezentuje się lepiej, ale skoro już WMF dała nam tryb ciemny, to należy go udoskonalić.

1. WP:Strona główna: w Wektorze 2022 ikonki są ucięte z lewej strony (przynajmniej u mnie); w trybie dziennym ten problem nie występuje.
2. Nowy tryb ciemny nie współpracuje z rozszerzeniem FlaggedRevs (wersje przejrzane). Historia, obserwowane, OZety i inne miejsca, w których można natknąć się na tego typu wpisy, są nieczytelne. Wiemy, że programiści Fundacji raczej się nie zajmują aktywnie tym rozszerzeniem, dlatego chyba sami powinniśmy coś wymyślić. Wydaje mi się, że można wziąć kilka rozwiązań z gadżetu (MediaWiki:Gadget-vector-dark-styles.css), przynajmniej kilka linijek, które mają wpływ na wygląd FlaggedRevs (klasy typu .flaggedrevs-color-0 itd.)
3. Kolory wprowadzone przez gadżet "Kolorowanie i zamiana nicków" (MediaWiki:Gadget-colored-nicknames.css) dobrze wyglądają w trybie jasnym, ale w trybie ciemnym są nieco nieczytelne. Ponownie, sugerowałbym skorzystanie ze styli z gadżetu Msz2001.

Pozdrawiam, tufor (dyskusja) 14:22, 20 lip 2024 (CEST)

Hm... Główną wyczyszczę. Tam już jest w stylach nagłówków namotane. Nux (dyskusja) 16:44, 20 lip 2024 (CEST)

Poprawiłem główną. Powinno być lepiej i stabilniej na przyszłość (niezależne od dziwności renderowania nagłówków przez MW). Nux (dyskusja) 18:27, 20 lip 2024 (CEST)

Co do 1 - w trybie jasnym problem jak najbardziej występował, technicznie rzecz biorąc, ale nie był tak widoczny, skoro białe było na białym. Co do 3 - trzeba by zmienić gadżetowe kolory, sugerowałbym design tokeny z Codex zamiast kolorowania „na twardo” (nie wiem, jak to zrobić technicznie, ale wiem, kogo zapytać). Co do 2 - tu może niespodzianka - w przyszłotygodniowym Tech News jest informacja, że w FlaggedRevs jest wprowadzany Codex, a więc będą śmigały w trybie ciemnym. Chciałbym dla jasności dodać, że użycie komponentów Codex w danym rozszerzeniu nie ma nic wspólnego z tym, czy produkt jest rozwijany - to tylko prace porządkowe. Tar Lócesilion (dyskusja) 01:38, 21 lip 2024 (CEST)

Naprawiłem trzecie. Co do drugiego, to jest otwarte zgłoszenie na Phabricatorze T369391. Spróbuję przygotować poprawkę i zgłosić ją ogólnie do repozytorium kodu FlaggedRevs, zamiast dokonywać tego tylko lokalnie u nas (za cenę opóźnionego wdrożenia). Msz2001 (dyskusja) 16:34, 28 lip 2024 (CEST)

Oznaczam jako Załatwione. Pkt. 1 i 3 są już poprawione i widoczne, pkt. 2 doczekał się poprawki w rozszerzeniu FlaggedRevs, która wejdzie na wiki jutro (podgląd po zmianie kolorów). Msz2001 (dyskusja) 10:56, 31 lip 2024 (CEST)

Dzięki wielkie, @Nux i @Msz2001! Dobra robota! tufor (dyskusja) 11:03, 31 lip 2024 (CEST)

refLinks - dodanie obsługi linków z tytułami

Dodałem analizę linków z tytułami na stronie czyli przypisów w postaci <ref>https://kornik.travel/pl/obiekty/zwiedzanie/rynek-i-ratusz-w-korniku Informacja na stronie miasta</ref>.

I mam do Was pytanie jak najlepiej uwzględnić tytuł strony w wyniku:

1. Informacja na stronie miasta [online], kornik.travel [dostęp 2024-06-30]  (pol.). - zostawiamy sam opis ze strony Wiki a pomijamy tytuł pobrany ze strony www
2. Rynek i Ratusz w Kórniku - serwis turystyczny Gminy Kórnik [online], kornik.travel [dostęp 2024-06-30]  (pol.). - wstawiamy opis pobrany ze strony ww a pomijamy dotychczasowy opis na stronie wiki
3. Informacja na stronie miasta (Rynek i Ratusz w Kórniku - serwis turystyczny Gminy Kórnik) [online], kornik.travel [dostęp 2024-06-30]  (pol.). - zostawiamy opis ze strony Wiki a w nawiasie tytuł pobrany ze strony www
4. Rynek i Ratusz w Kórniku - serwis turystyczny Gminy Kórnik (Informacja na stronie miasta) [online], kornik.travel [dostęp 2024-06-30]  (pol.). - tytuł pobrany ze strony www a w nawiasie opis ze strony Wiki

Skłaniam się ku wersji 3 lub 4. A Wy? masti <dyskusja> 14:52, 30 cze 2024 (CEST)

Ja bym preferował coś w rodzaju:

1. Informacja na stronie miasta: Rynek i Ratusz w Kórniku - serwis turystyczny Gminy Kórnik [online], kornik.travel [dostęp 2024-06-30]  (pol.).

albo po prostu wariant 2. Czasami te opisy (szczególnie takie do 10-20 znaków) są bez sensu jak podamy cały opis. Trzeba też uważać, bo ten link pierwotny mógłby być opisany tytułem pobranym z www: <ref>[https://kornik.travel/pl/obiekty/zwiedzanie/rynek-i-ratusz-w-korniku Rynek i Ratusz w Kórniku - serwis turystyczny Gminy Kórnik]</ref> albo trochę zmodyfikowany: <ref>[https://kornik.travel/pl/obiekty/zwiedzanie/rynek-i-ratusz-w-korniku Rynek i Ratusz w Kórniku w serwisie turystycznym Gminy Kórnik]</ref>. Wtedy zamieszczenie go dwukrotnie będzie wyglądało kiepsko. Więc bardziej za 2. ~malarz pl ^PISZ 15:08, 30 cze 2024 (CEST)

• zastanawiam się czy nie odrózniać tego przy stronach obcojęzycznych. Bo często polski opis na wiki jest sensowniejszy niż pobrany. Zwłaszcza sporo stron rosyjskojęzycznych ma dziwne tytuły. I wtedy pewnie #4 masti <dyskusja> 15:38, 30 cze 2024 (CEST)
  • Dla obcych alfabetów na www i polskiego w linku 4 jest ok. ~malarz pl ^PISZ 15:41, 30 cze 2024 (CEST)
• Jak dla mnie opcja chyba 4. najlepsza. ptjackyll (zostaw wiadomość) 15:42, 30 cze 2024 (CEST)
• Tradycyjnie: ilu Polaków, tyle odmiennych zdań. :-) Ja jestem zdecydowanie za opcją 1. Choć te opisy wikipedystów są często od czapy, to jednak często są też poprawne. Jedno zastrzeżenie (zresztą takie samo dla wszystkich propozycji): jeśli „język = pl”, to należy go opuścić. Polski jest językiem domyślnym w pl:wiki i nie ma sensu wskazywać, że coś jest napisane po polsku.

Możliwe problemy w innych propozycjach:

(2): Możemy dostać opis w stylu „Wałęsa Lech, Encyklopedia PWN: źródło wiarygodnej i rzetelnej wiedzy” (wiem, że akurat dla EPWN poprawia to bot, to tylko przykład, jak mogą wyglądać automatyczne tytuły) albo „Gazeta Wyborcza” (taki tytuł w każdym razie generuje Citoid dla każdego artykułu z GW; jeżeli refLinks potrafi wyłuskać prawdziwe tytuły, to ten przykład jest do skasowania)

(3) i (4): nie rozwiązuje problemu (2), a dodatkowo możemy dostać to, o czym wspomniał już Malarz pl – zdublowanie identycznych lub prawie identycznych opisów. Michał Ski (dyskusja) 09:19, 1 lip 2024 (CEST)

• To ma być tytuł strony, więc "Rynek i Ratusz w Kórniku". "Serwis turystyczny Gminy Kórnik" lub "kornik.travel" można dać w parametrze opublikowany, a "Informacja na stronie miasta" jest zbędna. 2003:C6:2748:1500:2947:6D6C:DE23:3459 (dyskusja) 00:25, 3 lip 2024 (CEST)

• Tak, ale to ma być automatyczne przerobienie istniejącego linku i możliwe jest jedynie z informacji już podanych oraz metadanych ze strony. Michał Ski (dyskusja) 09:55, 3 lip 2024 (CEST)

  Ok, wobec tego 2 wydaje się najlepszym rozwiązaniem. 2003:C6:2748:1500:F7AD:B0C1:4843:83B (dyskusja) 11:42, 3 lip 2024 (CEST)

Co jest w de wiki, a nie ma w pl

Wczoraj napisałem hasło Jerzy Witkowski. To kolejny już, po Pawle Lewieckim, polski muzyk od lat opisany w de wiki, a w pl wiki pominięty. I natrafiłem na kolejne takie hasło, de:Helena Oleska. Z tego, co widzę, wszystkie opisała jedna osoba, user Toolittle. Niestety kategoryzacja tych haseł jest beznarodowościowa, więc próżne wyszukanie ich po kategoriach (rycie w liczącej kilka tysięcy elementów kategorii ogólnej z pianistami sobie odpuszczę, a jak widać oprócz pianistów będą też np. śpiewacy/śpiewaczki).

Czy byłaby szansa na wybotowanie listy takich haseł? Jakieś hasła tego usera z polnische i polnischer w definicji czy coś tego typu? Hoa binh (dyskusja) 07:44, 5 lip 2024 (CEST)

@Hoa binh Co prawda nie dałem rady wyszukać po nazwie usera, ale jeżeli potrzebujesz po prostu listy polskich pianistów z de wiki, którzy nie zostali opisani w pl wiki, to może się przydać. (Listę wygenerowałem w Wikidata Query Service). Ironupiwada (dyskusja) 09:19, 5 lip 2024 (CEST)

@Ironupiwada Dzięki, choć nie tylko jak zaznaczyłem o pianistów chodzi :) Przejrzę, jedno hasło jak widzę (Władysław Eiger) miało dwa różne rekordy w WD, powiązałem. Hoa binh (dyskusja) 09:39, 5 lip 2024 (CEST)

@Hoa binh Dorzucam jeszcze śpiewaków operowych. :) (Na podstawie tego zapytania w WQS). Ironupiwada (dyskusja) 09:47, 5 lip 2024 (CEST)

Czyszczenie kodu szablonów cytowania w WP:SK

Zauważyłem, że WP:SK koryguje linki przez dodawanie spacji - przykład:

{{Cytuj stronę|url=https://samorzad2014.pkw.gov.pl/357_rady_woj/0/06.html |tytuł=Serwis PKW – Wybory 2014 |data dostępu=2019-12-10

zmienia na:

{{Cytuj stronę | url = https://samorzad2014.pkw.gov.pl/357_rady_woj/0/06.html | tytuł = Serwis PKW – Wybory 2014 | data dostępu = 2019-12-10 }}

Jaki jest sens takiego poprawiania, gdy to wydłuża kod o dodane spacje, nic nie zmienia dla czytelnika i dla działania kodu. Oczywiście, że w szablonie takie spacje ułatwiają czytanie redaktorowi notki. Natomiast pozbycie się spacji wokół znaku równości i ewentualnie znaki "pipe" | skraca kod składowany na serwerach. Czy autor WP:SK może wyłączyć dodawanie spacji? Zylla (dyskusja) 21:17, 1 lip 2024 (CEST)

Przede wszystkim WP:SK nie jest dla serwerów, tylko dla ludzi. Czyli działa to z założenia podobnie jak inne automaty formatowania kodu. Linków nie zmieniło, więc nie ma tu żadnego problemu z formatowaniem sensu stricto.

Czy bardziej czytelne jest ze spacjami czy bez, to już pewnie kwestia gustu. VisualEditor wstawia ze spacją przed kreską...

Natomiast podstawowa wersja WP:SK nie wprowadza tych zmian. Pewnie masz wersję z upiększaniem infoboksów. Nux (dyskusja) 21:45, 1 lip 2024 (CEST)

Sens jest taki, że jest to czytelniejsze dla człowieka w edytorze kodu. Szablony Cytuj ładniej się zawijają (zwłaszcza w wąskich oknach/rozdzielczościach). MarMi wiki (dyskusja) 20:40, 2 lip 2024 (CEST)

Czytelniejsze? Bez przesady. Zresztą gadżet do dodawania szablonów dodaje bez spacji i słusznie, bo stawianie jej po otwarciu i przed zamknięciem szablonu wygląda jak oddzielanie spacją przecinka z obu stron. Albo stawianie spacji przed kropką. 2003:C6:2748:1500:2947:6D6C:DE23:3459 (dyskusja) 00:23, 3 lip 2024 (CEST)

A edytujesz coś w edytorze kodu i zdarza ci się kopiować fragmenty z szablonu Cytuj?
Te dwie spacje na początku i końcu są oczywiście niepotrzebne, wcześniej mi umknęły. MarMi wiki (dyskusja) 18:15, 3 lip 2024 (CEST)

Tak, edytuję i nie korzystam z wizualnego. 2003:C6:2748:1500:3A0A:1743:2CCD:F3B (dyskusja) 21:24, 4 lip 2024 (CEST)

Wydajnośc: na en.wiki mają o tym całą stronę: en:Wikipedia:Don't worry about performance. W skrócie - jako edytorzy nie powinniśmy się tym przejmować. I na logikę - gdyby nam (wikipedii) zależało tak bardzo na tych spacjach to na wejściu od użytkownika te spacje by trimowano. Ale tak się nie dzieje - pozwalamy ludziom robić niestworzone rzeczy bo nie potrafimy przewidzieć do czego będą chcieli użyć MediaWiki (ba - wzięli nawet oprogramowanie do tworzenia tekstowej encyklopedii i nawet serwer z obrazkami na nim zrobili i nazwali go Commons).

Czytelnośc - dla edytora w kodzie wizualnym jest to przezroczyste. Dla edytora w kodzie źródłowym zwiększa to bardzo czytelność. PMG (dyskusja) 15:42, 4 lip 2024 (CEST)

"Pozwalamy ludziom robić niestworzone rzeczy bo nie potrafimy przewidzieć do czego będą chcieli użyć MediaWiki" - coś tam coś tam rekrutacja na produkt menedżerów dla MediaWiki (przykład), skupienie na treściach encyklopedycznych, cele WE5 i WE6 w planie rocznym 2024-2025, zapraszam na Wikimanię, gdzie będziemy rozmawiali o przyszłości MediaWiki... poza tym, jak sam świetnie wiesz (ale piszę to dla innych) jest linter, gdzie możemy zbierać raporty o elementach sformatowanych w sposób nieprzyjazny dla urządzeń mobilnych, trybu ciemnego itd., ten zakres można poszerzać. Tak że w skrócie: nie wiem, czy "nie potrafimy", ale na pewno chcemy lepiej potrafić. Tar Lócesilion (dyskusja) 23:52, 4 lip 2024 (CEST)

Podałeś przykład, który akurat mnie nie dotyczy, natomiast mój skrypt (od wielu lat) robi podobną rzecz w składni o postaci "_|parametr_=_wartość" przez analogię do szablonów. Jest to rozwiązanie ułatwiające czytanie, bo zbitka jest kompletnie nieczytelna. Poza tym oczywiste jest, że takie rzeczy powinny mieć zawsze jednolitą postać. Zarówno składnia podana przeze mnie, jak i ogólnie składnia szablonów ma ustabilizowaną od wielu lat postać, do której dążą skrypty, usuwając lub dodając w różnych miejscach spacje. Jest wynikiem głosów wielu wikipedystów już naprawdę dawno temu, ponad 10 lat. Jedną z wygód jest również ułatwienie posługiwania się myszką w kopiuj/wklej, jeszcze inną ułatwienie innych automatyzacji bazujących na ustalonej składni. Natomiast podany przez Ciebie przykład zawiera nadmiar spacji. Jeśli zauważyłeś kto konkretnie lub co konkretnie wprowadza takie zmiany, to daj znać. "Moja" składnia jest również w opisach szablonów (to znaczy w większości). [edit] Również na styku nawiasów klamrowych od wewnątrz nie powinno być spacji, a w Twoim przykładzie są. Beno (dyskusja) 23:21, 1 lip 2024 (CEST)

Uważam te spacje za bardzo pożyteczne. Łatwiej czytać i analizować przypisy, łatwiej kopiować i wklejać, wiersze się dobrze zawijają (nie ma dużych pustych odstępów, co występuje, gdy przypisy są bez spacji). Kelvin (dyskusja) 08:41, 3 lip 2024 (CEST)

Wersja ze spacjami dla mnie też jest wygodniejsza. @Beno Przykład nie tyle zmian, co stanu początkowego z nadmiarem spacji. Przy dodawaniu przypisu w kodzie źródłowym za pomocą „refTools”, generuje się szablon ze spacjami z obu stron parametru. Revsson (dyskusja) 10:05, 5 lip 2024 (CEST)

• To i ja dodam swoje trzy grosze. Kwestia spacji jest subiektywna. Dla mnie spacje powodują, że tekst jest na tyle rozproszony, że przestaje być czytelny. Wiktoryn <odpowiedź> 07:39, 5 lip 2024 (CEST)

Specjalna:Błędy składniowe/night-mode-unaware-background-color

Przygotowania do "nocnej skórki" ujrzały światło dzienne. Kilka dni temu pojawił się ten błąd na stronie błędów składniowych. Liczba błędów jest obecnie szacowana na 3,5 mln co daje średnio 2 błędy na artykuł. Zacząłem poprawiać często używane szablony (2-3 infoboxy, dokumentacja, ombox, itp.) i napotkałem na małą wątpliwość. Czy background:transparent; bez ustawionego koloru jest rzeczywiście problemem? Czy/jak można dodać dodać tutaj odpowiedni (dziedziczony z elementu pod spodem) kolor? Czekam na jakieś opinie przed masowymi poprawkami. ~malarz pl ^PISZ 17:20, 6 lip 2024 (CEST)

Tak, to jest problem, bo w arkuszu dla ciemnego stylu istnieje reguła html.skin-theme-clientpref-night .mw-parser-output [style*='background'] { color:#202122; }, jako ogólne zabezpieczenie w miejscach, gdzie ktoś wymusił jakiś kolor tekstu – tutaj przezroczysty może się okazać ciemnym i doprowadzi w efekcie do nieczytelnego tekstu. Wykrywanie transparent w tym miejscu będzie raczej nieefektywne, ze względu na liczne możliwe kombinacje.

Inna sprawa to to, czy te deklaracje przezroczystego tła są w ogóle potrzebne. Przejrzałem kilka pierwszych wyników wyszukiwania, to raczej występuje w podejrzanych miejscach: albo zbędne, albo w jakiejś konstrukcji do przerobienia na coś bardziej odpowiedniego. Msz2001 (dyskusja) 17:39, 6 lip 2024 (CEST)

Mała poprawka - światło dzienne te przygotowania ujrzały w marcu. Skoro już o tym rozmawiamy, to niedługo wstawię oficjalną wiadomość, którą miałem przygotowaną. Tar Lócesilion (dyskusja) 21:27, 6 lip 2024 (CEST)

To w marcu to nie pokazanie w światle dziennym trybu nocnego. Wtedy nic nie dało się zobaczyć w artykułach ani w informacjach o artykule. Dopiero od kilku dni :-) błędy są widoczne w "informacji o stronie". W marcu była zapowiedź nieodległych działań i zaproszenie do konsultacji. ~malarz pl ^PISZ 20:30, 7 lip 2024 (CEST)

Dlaczego tak piszesz? przecież sam komentowałeś tamtą dyskusję, widziałeś, że tryb nocny już działał. Owszem, tylko w wersji mobilnej i dla zalogowanych, ale rekomendacje już były, tracker błędów na najczęściej czytanych artykułach działał, był parametr URL. Z kolei w połowie maja tryb nocny stał się dostępny jako funkcja eksperymentalna w Wektorze 2022. Tar Lócesilion (dyskusja) 20:39, 7 lip 2024 (CEST)

Wyrzucenie zmian xHTML w kodzie

Patrzę z pewnym sentymentem na XHTML, jakieś dwa eony temu myślałem nawet, że XHTML, to przyszłość webu[13]... By-gones. Czasy się zmieniły, Wikipedia ma Doctype HTML5. Tymczasem w WP:SK zmieniamy nadal krótsze <br> na dłuższe <br /> i w sumie nie widzę już uzasadnia do tego, i chciałbym to odwrócić. Zasadniczo przeglądarki i tak nie używają tego ukośnika w br w trybie HTML [14]. Jakieś przeciwwskazania używania krótszej wersji br? Nux (dyskusja) 20:18, 15 maj 2024 (CEST)

• Ja mam jakiś niczym nieuzasadniony sentyment do <br /> (lepiej widzę to oczami w kodzie :-), ale uważam, że spokojnie można bez czekania na dyskusję wyłączyć w WP:SK zamianę <br> na coś innego zostawiając na razie czyszczenie wszelki innych sposobów "zamykania" BRek (bez spacji, slash przed, itp). Wyłączenie tej zmiany może (nie musi) spowodować też jakiś odzew tych co zauważą tę zmianę a nie śledzą kawiarenki technicznej. ~malarz pl ^PISZ 21:07, 15 maj 2024 (CEST)
• Ja też mam pewne odchyły w kierunku <br />, ale to chyba z nagminnego obcowania z plikami w formacie XML i ich ewentualnym przetwarzaniem w XSL. Na szczęście tutaj gdzie edytuję raczej ich nie spotykam. Paweł Ziemian (dyskusja) 22:30, 15 maj 2024 (CEST)
• Jak przedmówcy, również jestem przyzwyczajony do wersji XHTMLowej, ale skoro mamy podążać za standardem to można wyłączyć zamienianie w WP:SK. tufor (dyskusja) 23:08, 16 maj 2024 (CEST)
  • Miesiąc minął, brak uwag, chyba już można wyłączyć w WP:SK zamianę <br> → <br /> ;) tufor (dyskusja) 22:30, 12 cze 2024 (CEST)

    OK, v.2.19 Nux (dyskusja) 19:24, 13 cze 2024 (CEST)

    @Nux a czy jest włączona zmiana odwrotna, <br\s*/> → <br> -- Jakub T. Jankiewicz (@Jcubic) (zagadaj) 13:23, 8 lip 2024 (CEST)

    @Jcubic Tak (tutaj). Beno (dyskusja) 13:57, 8 lip 2024 (CEST)

Przypisy solo do sekcji

Mam drobny problem - nie bardzo mogę rozstrzygnąć sam ze sobą jakie formatowanie przypisu jest lepsze. Chodzi o przypis wstawiany do sekcji, w której jest tylko wyszczególniona zawartość, bez jakiegokolwiek zdania merytorycznego. Do czego tu dostawić przypis - do nagłówka sekcji [na logikę tak jest sensowniej, ale wtedy się pogrubia], czy do sztucznie wstawionego zdania, np "Źródło"? Obydwa przypadki nie wyglądają na superpoprawne rozwiązania.
Fizycznie wygląda to tak: PRZYKŁAD (1. wariant po słowach 'Lista utworów', 2. wariant po słowie 'Źródło:'). Jeśli było już rozstrzygane, bardzo proszę o pouczenie. Zorro2212 (dyskusja) 10:03, 5 lip 2024 (CEST)

A tak właściwie, to po co w tak krótkim artykule sekcje? Czytelnik na smartfonie dostanie infobox, jednolinijkowy wstęp i 3 wiersze tytuły sekcji. I musi klikać, by te sekcje otworzyć.

Kolejnym problemem występującym dość często jest traktowanie tytułu sekcji jak początku tekstu w sekcji. Tekst w sekcji ma być tak skonstruowany by rozpoczynał się poprawnie bez tytułu sekcji. Stok (dyskusja) 15:35, 5 lip 2024 (CEST)

Wstawianie odsyłaczy w nagłówkach to zło. Zabaw się w redaktora i skleć jakieś ogólne krótkie zdanie, by mieć pretekst wstawienia tam odsyłacza. Beno (dyskusja) 14:09, 5 lip 2024 (CEST)

Jak wyżej: w nagłówku nie powinno być w zasadzie niczego (ani odnośników do przypisów ani nawet linkowania do artykułów; poza jakimś prostym formatowaniem). Albo po prostu dodaj pod tabelą informację, że dane pochodzą z danego źródła + odsyłacz, albo dodaj poprawnie nagłówek tabeli (|+ i tam wklej odsyłacz. Wostr (dyskusja) 15:12, 5 lip 2024 (CEST)

Wygodniej (dla ewentualnego weryfikującego) jest mieć źródła od tabeli na górze. Nie trzeba przewijać czasami kilku ekranów, żeby do nich dotrzeć.
W przypadkach, gdy przypis np. w zasadzie powinien być w nagłówku sekcji, wstawiam "Źródło[1].". MarMi wiki (dyskusja) 16:52, 5 lip 2024 (CEST)

Toteż zwykle tak robię, w nagłówku po prostu źle to wygląda. Ale żaden filolog nie pochwali konstrukcji typu: Źródło: [1]. No ale to encyklopedia, powiedzmy pewna licencja poetica może być dopuszczalna. Może faktycznie jakieś zdanko szablonowo wymyślić? Zorro2212 (dyskusja) 19:10, 5 lip 2024 (CEST)

W zasadzie, konstrukcja „Źródło: ^[1]” (o której uważam, że jest jakimś potworkiem) wcale nie jest konieczna. Równie dobrze mogłoby być „Źródło: {{Cytuj|...}}” (lub z {{odn}}). Przypisy są m.in.

po to, aby artykuł w Wikipedii nie brzmiał jak tekst prawniczy, gdzie pełen odnośnik jest podawany w tekście ciągłym. A ponieważ podpis tabelki czy listy tekstem ciągłym nie jest, to moim zdaniem można stosować redakcję zgrabniejszą dla takiego miejsca. WP:WER nakłada wszak obowiązek podawania źródeł, w formie przypisu lub notatki bibliograficznej – przypis nie jest bezwzględnie konieczny (choć na ogół zalecany, to w takiej sytuacji moim zdaniem nie musi być). Msz2001 (dyskusja) 22:43, 5 lip 2024 (CEST)

To nawet niezły pomysł wstawiać bezpośrednio Cytuj. Z tym że pod VE trzeba by przechodzić do kodu żeby to zrobić (przypis generowany automatycznie; z poziomu VE nie można usuwać tagów ref, z tego co wiem). MarMi wiki (dyskusja) 14:23, 7 lip 2024 (CEST)

• Chciałbym zauważyć, że szablony cytowania są źródłem linków zewnętrznych, których jako takich chcemy unikać w treści artykułu. Wszystkie one powinny być umieszczane w sekcjach końcowych albo w specjalnych polach infoboksowych. Dlatego proponuję wariant:

Źródło: ''Tytuł''<ref>szablon cytowania</ref>

Podobny schemat proponowałbym w spisach twórczości u wielu opisanych pisarzy lub naukowców.

* (data) ''Tytuł''<ref>szablon cytowania</ref>

Paweł Ziemian (dyskusja) 18:12, 8 lip 2024 (CEST)

@Paweł Ziemian, dzięki. To jest najlepsze rozwiązanie.--Zorro2212 (dyskusja) 19:07, 8 lip 2024 (CEST)

Masowa edycja książek

Nie do końca jestem przekonany o słuszności masowych zmian wprowadzanych w hasłach dot. książek. IPek A01:115F... wprowadził na oko ponad 200 korekt, zmieniając zapis 'tytuł oryginalny/tytuł oryg.' na 'tyt. oryg.'. Może i zmiana nie jest taka zła, zgodnie z jego/jej twierdzeniem, że 'W opisach bibliograficznych używa się tego skrótu' (choć chyba Wikipedia nie do końca odtwarza zasady bibliograficzne wprowadzane w polskich normach przez Bibliotekę Narodową?). Niestety, widzę, że przy okazji zostały gdzieniegdzie skasowane zapisy z zastosowaniem szablonu W języku, który podaje z jakiego języka to tłumaczenie. Tu mam poczucie pewnej straty, w końcu ktoś ten szablon po coś stworzył. Zorro2212 (dyskusja) 17:29, 7 lip 2024 (CEST)

Rozmawiałam z owym IP i mnie przekonał ;-), ale ja w ogóle uważam stosowanie {{w języku}} w stosunku do tytułów utworów za błąd/niepotrzebne, także z tego względu, że nieraz polski tytuł wcale nie jest wiernym przekładem tytułu oryginalnego (poza tym są i przypadku, gdy tytuł jest w zgoła innym języku niż utwór). W znakomitej większości haseł o utworach są infoboksy z podaniem języka oryginału, zaraz po tytule jest też narodowość/przynależność autora (swoją droga lepiej byłoby mieć tam być linki do "literatura X", a nie do państwa) - podanie języka tytułu wydaje się zbędne. Gytha (dyskusja) 18:08, 7 lip 2024 (CEST)

No dobrze, Tobie ufam i wierzę, że wiesz co robisz :) Choć z tymi infoboksami trochę bym się pospierał. Daty urodzin też tam są podane, ale przecież nie opuścisz ich w leadzie biogramu. Już kiedyś się zastanawiałem, czy przypisy dot. urodzin/śmierci lepiej podać w infoboksie czy w leadzie? Infobox jest edycyjnie pierwszy, ale dla czytającego logicznie pierwszy jest lead. A może w jednym i drugim? No ale z kolei nie powinno się powtarzać raz podanych informacji, zwłaszcza w tak bliskiej odległości. Ale, żebyśmy tylko takie zmartwienia mieli... Pozdrawiam --Zorro2212 (dyskusja) 09:16, 9 lip 2024 (CEST)

Wyświetlanie autorów w szablonie {{Cytuj}}

Sprawa 1: Obecnie szablon wyświetla maks. 3 autorów, a jeśli jest ich więcej, zmienia to na „Jan Kowalski i inni”. Wg mnie ograniczenie do 3 autorów jest zbyt restrykcyjne. Miejsca na ekranie mamy sporo i można podać ich więcej. Proponowałbym zmienić limit trzykrotnie, czyli na 9 (arbitralnie, ale chyba realnie). W naukach ścisłych i przyrodniczych autor korespondencyjny (czyli ten najważniejszy) zwykle umieszczany jest jako ostatni. Nie zawsze, ale zwykle tak. Zwiększenie limitu pozwoli na ujawnienie go w znacznie większej liczbie artykułów. I podlinkowanie, gdyż jest zazwyczaj autoency. Często także pierwszych autorów, czyli zazwyczaj tych, którzy byli głównymi wykonawcami pracy, jest więcej niż 1. Zwiększenie limitu pozwoli docenić ich wkład.

Sprawa 2: Jeżeli liczba autorów przekracza limit, to najechanie kursorem na „i inni” wyświetla pop-up z pozostałymi autorami. Tyle, że jest on nietekstowy (nie można zaznaczyć czegokolwiek i skopiować do schowka) i bez linków. Czy dałoby się zmienić zachowanie szablonu, aby po kliknięciu w „i inni” wyświetliła się pełna lista autorów? Czyli np. widok z:

  A. Abski i inni, On the Transmission Capacity, „Electrocommunications”, 2001, s. 27–45.

zmieniałby się na:

  A. Abski, B. Bebski, P. Cebulski, B. Dębski, On the Transmission Capacity, „Electrocommunications”, 2001, s. 27–45.

Przy okazji warto jakoś wyróżnić to „i inni” wśród współautorów (np. tak, jak zrobiłem wyżej), bo pewnie mało komu niezorientowanemu przyjdzie do głowy, że najechanie kursorem na ten tekst da jakiś efekt.

Naszym guru od {{Cytuj}} jest niewątpliwie Paweł Ziemian, więc pinguję go, aby od razu wylał kubeł zimnej wody, jeśli jest to nierealne technicznie. Michał Ski (dyskusja) 20:54, 11 lip 2024 (CEST)

Ad. 1) Teoretycznie można podnieść poprzeczkę, jednak to będzie będzie wyłom w stosunku do pozostałych szablonów cytowania. Nie wiem czy nie wprowadzi zamieszania wśród osób używających {{odn}}. Spowoduje wydłużenie działania szablonu, co może mieć negatywny wpływ na stronach, w których liczba wywołań oscyluje w okolicach tysiąca. No i na końcu zwiększy rozmiar generowanego HTMLa. Szablon wstawia dużo tagów span dookoła imion, inicjałów i nazwisk. Dzięki temu możliwe jest ustalanie innej kolejności zapisu autorów w sekcjach Przypisy i Bibliografia.

Ad. 2) Podobne pytanie padło na stackoverflow. Niestety obecnie MediaWiki nie zezwala na tag details. Do tego trzeba by chyba napisać gadżet. Jednak aby działały też wikilinki, trzeba by się zastanowić bardziej i może całkowicie zmienić koncepcję implementacji prezentacji listy autorów uwzględniając to co działa obecnie. Może nawet uda się znaleźć rozwiązanie bardziej zwięzłe niż to co jest obecnie.

Paweł Ziemian (dyskusja) 18:16, 12 lip 2024 (CEST)

Ad. 1) Co do wyłomu, to i tak wygląda to inaczej.

• Dla 3 autorów:

{{Cytuj}}: A. Abski, B. Bebski, P. Cebulski, On the Transmission Capacity, „Electrocommunications”, 2001, s. 27–45 .

{{Cytuj pismo}}: A. Abski, B. Bebski, P. Cebulski. On the Transmission Capacity. „Electrocommunications”, s. 27–45, 2001. 

• Dla 4 autorów:

{{Cytuj}}: A. Abski i inni, On the Transmission Capacity, „Electrocommunications”, 2001, s. 27–45 .

{{Cytuj pismo}}: A. Abski, B. Bebski, P. Cebulski, B. Dębski. On the Transmission Capacity. „Electrocommunications”, s. 27–45, 2001. 

• Dla 5 autorów:

{{Cytuj}}: A. Abski i inni, On the Transmission Capacity, „Electrocommunications”, 2001, s. 27–45 .

{{Cytuj pismo}}: A. Abski, B. Bebski, P. Cebulski, B. Dębski i inni. On the Transmission Capacity. „Electrocommunications”, s. 27–45, 2001. 

Nie wiem, jakie zamieszanie z odn mogłoby nastąpić. A używam. Przy 4 autorach "Cytuj pismo/Cytuj książkę" nie skraca, przy >4 dodaje „i in.”, natomiast odn >3 skraca do jednego nazwiska. Więc i tak już teraz nie ma zgodności, a zamieszania to chyba nie powoduje.

Na możliwe problemy techniczne nie mam kontrargumentu. :-( Może chociaż do 5 nazwisk wyświetlać?

Ad. 2) Jeśli jednak udałoby się wdrożyć to rozwiązanie, to pkt. 1 robi się mało istotny. Ostatnie zdanie budzi nadzieję! :-) Michał Ski (dyskusja) 16:31, 15 lip 2024 (CEST)

X zmian(a) oczekuje na przejrzenie

Nie jestem pewien, czy tak wcześniej było, ale coś mi tu nie gra. W Wypadek samolotu M-346 Bielik na lotnisku Gdynia-Babie Doły były dwie zmiany do przejrzenia. Natomiast belka u góry artykułu informowała mnie, że tylko 1 zmiana oczekuje na przejrzenie...? Tak było, czy to dalszy ciąg zamieszania z wersjami przejrzanymi po tym, jak WMF wywaliło większość kodu? Wostr (dyskusja) 19:22, 15 lip 2024 (CEST)

• Okazuje się, że błąd już występował wcześniej, potem sam znikł i niedawno znowu powrócił: T324422. Wygląda na problem z cache'owaniem bo wymuszenie przeładowania strony (purge) powoduje wyświetlenie poprawnej liczby.Msz2001 (dyskusja) 19:28, 15 lip 2024 (CEST)
• @Wostr, @Msz2001: ja spotykam się (sporadycznie, ale od dawna) raczej z sytuacją odwrotną: są np. 2 wersje nieprzejrzane, a na górze, w ramce „Nieprzejrzane wersje” wyświetlają się 3 wersje, z których ostatnia jest przejrzana. Przy najbliższej okazji spróbuje purge'a. Michał Ski (dyskusja) 11:58, 16 lip 2024 (CEST)

Tryb ciemny dla niezalogowanych użytkowników już wkrótce!

Cześć wszystkim, przez ostatni rok zespół Web w Wikimedia Foundation pracował nad trybem ciemnym. Prace te są częścią inicjatywy Accessibility for Reading, która wprowadza zmiany w skórkach Vector 2022 i Minerva. Poprawia on czytelność i pozwala wszystkim, zarówno zalogowanym, jak i niezalogowanym użytkownikom, dostosować ustawienia związane z czytelnością.

Od początku tego roku tryb ciemny jest dostępny jako funkcja eksperymentalna zarówno na stronie mobilnej, jak i stacjonarnej. Współpracowaliśmy z edytorami szablonów i innymi edytorami technicznymi, aby przygotować wiki do tej funkcji. Praca ta obejmowała naprawę szablonów i upewnienie się, że wiele stron może być wyświetlanych w trybie ciemnym bez żadnych problemów z dostępnością. Chcielibyśmy wyrazić ogromną wdzięczność wszystkim zaangażowanym w te prace. Ponieważ zrobiono tak wiele, w ciągu najbliższych dwóch tygodni udostępnimy tę funkcję wszystkim Wikipediom!

Konfiguracja wdrożenia i harmonogram

• Wikipedie grupy 1 i 2: wiki, na których liczba problemów w trybie ciemnym w porównaniu z trybem jasnym nie jest znacząca. Te wiki otrzymają tryb ciemny zarówno dla zalogowanych, jak i niezalogowanych użytkowników. Niektóre drobne błędy mogą jednak nadal występować w szablonach. Będziemy dodawać sposoby zgłaszania tych problemów, abyśmy mogli kontynuować naprawianie szablonów wspólnie z edytorami.
• Wikipedie grupy 3 (obecnie plwiki jest w tej grupie): wiki, na których liczba błędów w trybie ciemnym w porównaniu z trybem jasnym jest znacząca. Te wiki otrzymają tryb ciemny tylko dla zalogowanych użytkowników. Chcielibyśmy udostępnić tryb ciemny wszystkim użytkownikom. Jednak niektóre wiki nadal wymagają pracy ze strony społeczności w celu dostosowania szablonów. Podobnie jak w przypadku powyższej grupy, te wiki otrzymają również link do zgłaszania problemów, który pomoże zidentyfikować pozostałe problemy.
• Tydzień 1 lipca: strona mobilna (skórka Minerva) na Wikipediach grupy 1.
• Tydzień 15 lipca: strona desktopowa (skórka Vector 2022) na wszystkich Wikipediach; strona mobilna: zalogowani i niezalogowani na Wikipediach grupy 2, tylko zalogowani na Wikipediach grupy 3.

Jak włączyć tryb ciemny

Funkcja pojawi się w menu Wygląd obok opcji wielkości tekstu i szerokości strony. W zależności od kompatybilności i architektury technicznej niektóre strony mogą nie być dostępne w trybie ciemnym. W przypadku tych stron w menu pojawi się powiadomienie zawierające więcej informacji.

Jak uczynić tryb ciemny jeszcze lepszym!

Jeśli chcesz pomóc w uczynieniu większej liczby stron przyjaznymi dla trybu ciemnego, przejdź do naszej poprzedniej wiadomości i zobacz sekcję "Co chcielibyśmy, abyście zrobili (edytorzy szablonów, administratorzy interfejsu, edytorzy techniczni)".

Dziękujemy wszystkim. Czekamy na wasze pytania, opinie i komentarze! SGrabarczuk (WMF) (dyskusja) 21:39, 6 lip 2024 (CEST)

Tryb ciemny jest teraz dostępny dla wszystkich (niezalogowanych i zalogowanych) na wersji mobilnej i desktopowej.

Zalogowani mogą zgłaszać błędy w formatowaniu kolorów występujące w artykułach. Mogą to zrobić poprzez link "Zgłoś problem z trybem ciemnym", który prowadzi do strony Reading/Web/Accessibility for reading/Reporting/pl.wikipedia.org. Stamtąd zagregowane informacje o błędach będą co jakiś czas wysyłane z powrotem do Kawiarenki.

Społeczność może zmodyfikować ten link, kierując zgłaszanie błędów na wybraną stronę polskojęzycznej Wikipedii, na przykład do Kawiarenki technicznej.

Niezalgowani też widzą ten link, ale w ich przypadku Fundacja, zamiast ładowania formularza zapisania błędu, gromadzi tylko statystyki, na których stronach te linki są klikane. Chodzi o ograniczenie eksperymentów edycyjnych i spamu.

Więcej o projekcie możecie dowiedzieć się z nowego posta na Diffie. Dziękuję SGrabarczuk (WMF) (dyskusja) 15:29, 18 lip 2024 (CEST)

Dodam jeszcze od siebie, że jest to rozwiązanie niezależne od Ciemnego Wektora (mojego trybu ciemnego, dostępnego od 2019). W przypadku korzystania z obu naraz, niektóre elementy interfejsu mogą się wyświetlać nieoptymalnie (lepsze efekty daje korzystanie z tylko jednego w danym momencie). Msz2001 (dyskusja) 16:31, 18 lip 2024 (CEST)

Cześć, mam problem z Moduł:Build bracket i Moduł:Team bracket w dark mode. W enwiki ścieżki są ładnie zamieniane na biały kolor, u nas zostają czarne. Źródło z enwiki także źle zachowuje się u nas. Quri.inka (dyskusja) 18:25, 18 lip 2024 (CEST)

@SGrabarczuk (WMF) zmodyfikowałem Moduł:Build bracket, czy można coś zrobić prościej z border? Quri.inka (dyskusja) 11:34, 19 lip 2024 (CEST)

Ombox w opisach plików

W opisach (niewielu, ale jednak) plików, które mamy załadowane lokalnie istnieją określone szablony dot. głównie licencji. Jeżeli są zbudowane na {{mbox}} to w przestrzeni Plik wywołują {{ombox}}. Ma on wbudowany 10% margines z lewej i z prawej strony, przez co w {{Plik}} jeszcze bardziej się zwęża.

Nie widzę sensu dla tych kilkuset plików tworzyć nowego {{imbox}} (jak w en.wiki), jednak:

1. albo w {{ombox}} wypadałoby zmienić styl z uwzględnieniem, że w przestrzeni Plik nie dodaje 10% marginesu (standardowy rzędu .4em czy 4px byłby wystarczający);
2. albo dodać w {{ombox}} opcję dodania stylu w ramach dodatkowego parametru.

Osobiście widziałbym po prostu opcję nr 1 (dodanie przy tych 10% ifeq sprawdzającego przestrzeń), ale wolę zapytać tutaj, czy to odpowiednie rozwiązanie. Wostr (dyskusja) 22:59, 8 lip 2024 (CEST)

Jakby przenieść style do TemplateStyles, to można by to łatwo zmienić w CSS (Plik: to body.ns-6). Pewnie można by nawet się pokusić o ujednolicenie części szablonów... może. Jakiś czas temu zrobiłem {{ambox/2}}. Właściwie to zrobiłem go głównie dla CzyWiesza, ale może można to rozszerzyć... Trzeba by przeanalizować różnice i zastanowić się które zachowania są celowe, a które są przypadkowe (np. przypadkowe pewnie jest te 10% marginesu w plikach).

PS: Przykładowa grafika: Plik:Bubo bubo.jpg. Nux (dyskusja) 22:22, 9 lip 2024 (CEST)

No właśnie widzę, 5 szablonów, z których 2 są zwężone, a trzy na pełną szerokość... TemplateStyles dla tak szerokiego tematu, to nie moja bajka, zbyt łatwe jest popsuci czegoś na dużą skalę. Na ten moment w {{ombox}} dodam warunek usuwający 10% dla przestrzeni Plik. Wostr (dyskusja) 14:10, 20 lip 2024 (CEST)

Wstawianie modułów do artykułów

Cześć. W ostatnich dniach zająłem się porządkowaniem szablonów z Kategoria:Szablony turniejowe, dużą część z nich usuwając, integrując itd, w większości zdecydowanej przechodząc w nich na moduły. Jednak przy tej okazji zauważyłem, że w niektórych artykułach znajdują się wstawione bezpośrednio moduły (nie przez szablon). Dla zobrazowania kod zmienia się wtedy z takiego:
{{32TeamBracket |byes=y,
na taki:
{{#invoke:Build bracket|main | rounds=5 | col1-matches = 3,6,9,12,15,18,21,24 | col2-matches = 3,6,9,12,15,18,21,24 | col3-matches = 4.5, 10.5, 16.5, 22.5 | col4-matches = 7.5, 19.5 | col5-matches = 13.5 | col2-col3-paths = (3,6)-4.5, (9,12)-10.5, (15,18)-16.5, (21,24)-22.5 | col3-col4-paths = (4.5,10.5)-7.5, (16.5,22.5)-19.5 | col4-col5-paths = (7.5,19.5)-13.5,
dając w zasadzie taki sam efekt wizualny. Zauważone przeze mnie zmiany wprowadzał @Quri.inka, np [15], ale moduły też są wstawione w serii art o Puchare Polski i wielu innych. Poprosiłem @Quri.inka, żeby zaprzestał tej praktyki, bo uważam, że na dłuższą metę jest ona szkodliwa. Sam miałem okazję chyba dwa razy wstawić moduł bezpośrednio do artykułu, jednak to były sytuacje wyjątkowe, gdzie drabinka była skomplikowana. Podtrzymuję argumenty przedstawione na stronie dyskusji @Quri.inka, że

1. obsługa modułu jest na tyle skomplikowana, że jeśli ktoś będzie chciał coś poprawić to zwyczajnie sobie nie poradzi - użytkownicy są już oswojeni z szablonami, a ciąg różnych cyfr w module może wprowadzać zamieszanie;
2. moduły wstawiane bezpośrednio, nie w szablonie, powodują, że każdy artykuł w zasadzie może wyglądać inaczej - nie będzie żadnej spójności;
3. moduł zamiast szablonu nie daje również możliwości (albo mocno ogranicza) botowania artykułów, gdy zajdzie potrzeba jakiejś zmiany
4. @Quri.inka przedstawił argument, że taka praktyka jest stosowana na en.wiki - jednak uważam, że to akurat zła praktyka i nie powinniśmy jej kopiować.

Jako, że nie doszliśmy do porozumienia, chciałbym poznać Wasze zdanie na ten temat. Czy powinniśmy na szerszą skalę akceptować wstawianie modułów do artykułów, czy ograniczyć tą praktykę do wyjątkowych przypadków? Mateusz.ns (dyskusja) 18:15, 7 lip 2024 (CEST)

• Jestem przeciwny wstawianiu czegokolwiek do artykułów co zaczyna się od {{#. To są zaklęcia opracowane z myślą o tworzeniu szablonów i wydaje mi się, że VE ich nie obsługuje poprawnie. ~malarz pl ^PISZ 20:27, 7 lip 2024 (CEST)

  Z opisu VE, jaki znalazłem, wynika, że ma on liczne błędy, co jest nieuniknione. Sam go nie używam. Na początku moich edycji sprawiał mi problemy.

  Prośba, ponieważ @Malarz pl ma większe doświadczenie, a ja nie korzystam z VE, proszę o przykład. Sugerowanie przez wydaje mi się nie jest w porządku.

  Tak dla wyjaśnienia, moduły te zaimportowałem kilka lat temu i przez ten okres trochę artykułów z nimi się nazbierało. Moje poprawki dotyczyły artykułów tworzonych tudzież edytowanych, jeszcze przed czasami modułów.

  Co do punktu czwartego, spór rozpoczął się od drabinki wstawionej w Liga Młodzieżowa UEFA (2019/2020), która nie pasowała do tego artykułu i pozostałych z serii (moja wina, że wcześniej nie usunąłem starego szablonu).

  Czy ten konkretnie przytoczony argument jest dobry, czy zły nie wiem. enwiki ma olbrzymi zasób, a i pewnie osoby tam pracujące większe doświadczenie. Tym bardziej, że to one są autorami modułów i szablonów z, których korzystamy.

  Sposób użycia jest dla mnie obojętny. Ja się w cyferkach nie gubię, z literami to już inna sprawa. Na razie w tych szablonach jest wielki bajzel (dużo dubli, nazwy, chyba błędy), także cieszy mnie, że wreszcie ktoś się znalazł i robi z tym porządek. Quri.inka (dyskusja) 22:02, 7 lip 2024 (CEST)

  Lepiej korzystać z szablonów, tak jak już pisał wyżej malarz i Quri. Nawet nie ze względu na VE, ale na to, że nie trzeba za każdym razem dodawać konfiguracji (i w razie czego można poprawić konfigurację w jednym miejscu, a nie w 100 artykułach 😉).

  Jakby co do prostych drabinek (4team, 8team,.... 32team) mam edytor, który może jest nieco specyficzny, ale może ułatwić edycje: http://nostalgia.enux.pl/smp/drabinki/#wynik

  Pozdrawiam, Nux (dyskusja) 23:08, 7 lip 2024 (CEST)

  Popieram malarza - żadnych takich invoke. To że technicznie da się zrobić coś, nie oznacza że powinnismy to robić. PMG (dyskusja) 14:04, 8 lip 2024 (CEST)

• Również jak malarz. Moduły od samego początku były projektowane w taki sposób, aby stanowić wsparcie w szablonach. Stąd mają one możliwość bezpośredniego dostępu do parametrów z nadrzędnego wywołania. Innymi słowy moduł wywołany z szablonu widzi parametry, z którymi wywołany jest ów szablon. Jako przykład podam implementację {{cytuj}} → {{#invoke:Cytuj|auto}}. Paweł Ziemian (dyskusja) 18:02, 8 lip 2024 (CEST)

Większość osób opowiedziała się za niewstawianiem wywołań modułów do artykułów, padły przekonujące argumenty. Chciałem nawet już wpisywać do WP:Przedyskutowane, ale sprawdziłem jak tam sytuacja w artykułach. No i nadal powstają tego artykuły z modułami w treści: Prva crnogorska liga (2024/2025), Primeira Liga (2024/2025), Mistrzostwa Świata w Piłce Nożnej 2026 (eliminacje strefy OFC), Mistrzostwa Świata w Koszykówce Mężczyzn 2023. Przychylam się do podanych powyżej argumentów, ale – szczerze – porównując kod źródłowy wstawionego modułu z kodem źródłowym jakiejś tabelki tego typu: Prva_crnogorska_liga_(2024/2025)#Wyniki (Moduł:Wyniki sportowe), to pod względem jasności i przejrzystości: moduł wygrywa. W tabelach można się szybko pogubić w gąszczu kresek, zwłaszcza, gdy cały wiersz tabeli jest podany w jednej linii. Podobnie z modułem Moduł:Tabela sportowa: jak dla mnie kod jest czytelny i zrozumiały. Właściwie nie mam pomysłu jak zastąpić moduły: zamienienie na najzwyklejsze tabelki to IMO wylanie dziecka z kąpielą; wielokrotne użycie modułu zapewnia pewną jednolitość w artykułach, no i dla wstawiających wyniki, kod jest prostszy. Zamiana na serię szablonów w stylu: Tabela sportowa nagłówek, Tabela sportowa, Tabela sportowa stopka wydaje się być jakimś rozwiązaniem. Można byłoby również rozważyć wyrzucenie tych utworzonych przez moduły gotowych (wypełnionych) tabelek do przestrzeni Szablon (tam nie ma domyślnie przycisku do edycji w VE) i później transkludowanie ich w artykułach. Jednak to też skomplikowałoby cały proces tworzenia i edytowania artykułów. Utworzenie szablonu-nakładki na moduły nie wydaje mi się być możliwe, ze względu na ich skomplikowanie i mnogość opcji. Pytanie więc: co robimy? tufor (dyskusja) 23:49, 20 lip 2024 (CEST)

• To powinno być zamienione na wywołanie szablonu, który wywołuje moduł. Tak jak jest np w {{Szachownica}}. Niestety część modułów nie jest do tego przygotowana. ~malarz pl ^PISZ 00:13, 21 lip 2024 (CEST)

Autocytowanie (z poziomu VE): [No title found]

Zwraca taki "tytuł" np. dla 10.1023/A:1024607414959 (Przypis, automatycznie), a tak to wygląda w narzędziu Malarza. To na pewno ma jakieś wyjaśnienie, którego ja na tą chwilę nie posiadam. W ostatnim czasie poprawiłem parę takich (Special:Diff/74237830, Special:Diff/74237815), może dodać jakieś ostrzeżenie na poziomie VE przy wpisywaniu parametrów, albo czerwoną czcionką "sprawdź tytuł" etc.? InternetowyGołąb (dyskusja) 01:15, 23 lip 2024 (CEST)

Edit check

Pod koniec 2023 pojawiło się takie narzędzie. Jego wprowadzenie mogłoby potencjalnie poprawić jakość treści publikowanych (szczególnie przez nowicjuszy) na Wikipedii. Co o nim sądzicie?

(jeśli odgrzałem kotlet to... cóż... może przynajmniej będzie smaczny ;) )

Karol739 (dyskusja) 00:50, 25 lip 2024 (CEST)

Przekierowanie do podstrony z polskim tłumaczeniem

Nie jest to problem z pl.wiki, ale może ktoś będzie mi w stanie pomóc. W WD, Commons, meta istnieją podstrony z tłumaczeniami danych stron (podstrony z końcówką /pl), które automatycznie ładują się, gdy wchodzi się na daną stronę. Da się to jakoś wyłączyć to automatyczne przekierowanie do przetłumaczonych podstron? One z reguły się nieaktualne, niezbyt dobrze przetłumaczone i za każdym razem i tak muszę klikać na English. Wostr (dyskusja) 17:35, 28 lip 2024 (CEST)

Jeżeli wchodzisz przez Special:MyLanguage, to zawsze będzie Cię przekierowywało (jeśli jest dostępne) na stronę w języku, w którym masz interfejs. Co do wyłączenia tego, widziałem chyba kiedyś u kogoś skrypt, ale nie mogę teraz na szybko znaleźć. Nadzik (dyskusja) 17:39, 28 lip 2024 (CEST)

Ja się przełączyłem na angielski z tego powodu na Meta. Wystarczy wybrać j.ang. w górnym menu i automatycznie ustawi lokalny wyjątek. Chociaż minusem jest, że będzie to dotyczyć ogólnie GUI, a nie tylko tłumaczonych treści artykułów. Nux (dyskusja) 02:01, 29 lip 2024 (CEST)