Wszedłem bez problemu. Wyszukałem rekordy dotyczące Wiesława Jędrzejczaka i Kazimierza Slaskiego. Oba rekordy są dostępne. Wtedy zauważyłem, że przy obu wpisach w Wikipedii pojawiła się informacja o martwym linku. Szelma W (dyskusja) 17:02, 30 kwi 2024 (CEST)[odpowiedz]
Na stronach w przestrzeni Moduł (na przykład Moduł:Kalendarium/05-05) w pasku narzędzi nie pojawia przycisk disFixera. Na stronach w przestrzeni głównej bez problemów.
Pamiętam, że dawniej (przed zmianami w marcu 2023 - @Nux?) przycisk, po kliknięciu którego wyświetlała się lista i możliwości poprawy, zachowywał się tak samo w modułach, jak i w main.
Disfikser (i WP:SK) nie umie edytować modułów itp. To są moduły służące do edytowania wikitekstu. Nigdy nie wiadomo co jest w module. Na tej konkretnej stronie jest zresztą ~JSON, w którym klamerki {używane normalnie do tabelek} są tam używane w innych celach... Ale jeśli umiesz rozpoznać poprawną składnię JSON-a, to możesz sobie ustawić zaawansowane opcje Specjalna:GadgetPrefs. Nux (dyskusja) 19:48, 30 kwi 2024 (CEST)[odpowiedz]
Do niedawna wyszukiwarka dawała sensowne podpowiedzi po wpisaniu początku hasła. Teraz są one jakieś losowe i absurdalne. Wyszukiwarka fajnie podpowiadała np. pełne nazwy roślin, gdy zaczęło się wpisywać ich początek. Teraz wpisując "bluszcz pospolity" muszę dojść do ostatniej litery, by wyświetlić hasło, po drodze otrzymując podpowiedzi: Bluszczyk, Bruszczewo, Błyszczyk, Bluszcz kanaryjski itp. Wpisując "dąb szypułkowy" dostaję podpowiedzi: Dąb Szaszkewycza, Daszyna, Dobszyńska Jaskinia Lodowa i też muszę wpisać pełną nazwę gatunkową, by wyświetlić w końcu podpowiedź z popularnym przecież hasłem. Wygląda to jakby ktoś zhakował wyszukiwarkę. Oglądalność haseł poleci na łeb na szyję, bo nawet ja jako botanik mam problem z bezbłędnym zapamiętaniem pełnych nazw gatunkowych w języku polskim, a inaczej nie znajdzie się hasła. Kenraiz .ꓘ (dyskusja) 17:38, 25 kwi 2024 (CEST)[odpowiedz]
Faktycznie, po tym jak przeszukałem taski w czwartek powstał T363516 i to właśnie w nim się toczyła dyskusja. Zapytania do autouzupełniania w wyszukiwarce zostały przekierowane do zapasowego centrum danych (ten moment, kiedy ono faktycznie się przydaje ;D), dlatego zaczęło działać. Wygląda na to, że znana jest też oryginalna przyczyna problemu. -- niepodpisany komentarz użytkownika Msz2001 (dyskusja)
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
Przykładowy wygląd strony dyskusji po zmianach (po francusku).
Wygląd stron dyskusji zmienił się na wszystkich wiki, oprócz Commons, Wikidanych i większość Wikipedii (kilka już wcześniej otrzymało tę zmianę). Więcej informacji o zmianach znajduje się na Diffie. Jest możliwe, by zrezygnować z nowego wyglądu stron dyskusji, w tym celu należy udać się do preferencji i przełączyć opcję „Pokaż aktywność wątków dyskusji”. Na pozostałych wiki wdrożenie odbędzie się w nadchodzących tygodniach. [1][2]
Administratorzy interfejsu mają teraz większą kontrolę nad stylami komponentów w wersji mobilnej. Dzięki wprowadzeniu rozszerzenia SiteAdminHelper, część wbudowanych stylów będzie mogła zostać wyłączona. Więcej informacji znajduje się na stronie rozszerzenia. [3]
Wikimedia Enterprise zawiera teraz również sekcje artykułu w odpowiedzi JSON oraz pole z krótkim opisem do istniejącego przeparsowanego infoboksu. Ta zmiana jest dostępna również w Wikimedia Cloud Services. [4]
Zmiany w tym tygodniu
Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 7 maja, na stronach innych niż Wikipedia i niektórych Wikipediach od 8 maja, a następnie na wszystkich wiki od 9 maja (harmonogram). [5][6]
Na stronie Specjalna:Rejestr pierwsza opcja do wyboru to „Wszystkie publiczne rejestry”. Ze względu na to, że pokazuje tylko część rejestrów, będzie się ona nazywać „Główne publiczne rejestry”. [7]
Niektórzy nowicjusze jako przypis wstawiają gołe linki URL, jak choćby tutaj. Czy jest jakiś bot/mechanizm/skrypt, żeby szybko takie linki zamienić na porządniejsze przypisy?
Przydałby się przy tym mechanizm sprawdzający (w tle) czy dana strona jest zarchiwizowana, otwierający archiwum lub próbujący zarchiwizować obecna wersję (ale po ręcznym zatwierdzeniu). Ciacho5 (dyskusja) 11:52, 21 kwi 2024 (CEST)[odpowiedz]
Nie za bardzo podoba mi się ustawianie przez bota aktualnej daty jako daty dostępu. Przykład: diff - link wstawiany w 2013, nieaktualny (przekierowanie na inną stronę), a data dostępu ustawiana na 2024. MarMi wiki (dyskusja) 13:41, 25 kwi 2024 (CEST)[odpowiedz]
Przy podmianie opakowania linku (plus wstawienie tytułu) raczej nie ma takiej potrzeby. Ale pomysł niezły, może ktoś to kiedyś zaimplementuje przy użyciu sztucznej inteligencji. Edycja: Chociaż jeśli dobrze pamiętam to ostatnio o czymś podobnym niedawno informowano na wiki (na razie w wersji angielskiej). MarMi wiki (dyskusja) 16:34, 26 kwi 2024 (CEST)[odpowiedz]
Cytat: Data (…), która określa dzień, w którym podane źródło było rzeczywiście przeglądane i w którym informacje podane w artykule rzeczywiście znajdowały się pod podanym odnośnikiem.[9]SpiderMum (dyskusja) 18:56, 26 kwi 2024 (CEST) UP!? SpiderMum (dyskusja) 23:49, 6 maj 2024 (CEST)[odpowiedz]
@MarMi wiki bot ustawia datę dostępu gdyż odczytał link i zawartość strony. Bo z zawartości pobiera tytuł do wstawienia. A zatem potwierdza też, że strona w danym dniu żyła i istniała i miała taki tytuł w dniu odczytania. Nie może potwierdzić informacji z 2013, jak w podanym przykładzie. masti<dyskusja>16:48, 26 kwi 2024 (CEST)[odpowiedz]
Tylko że to kłóci się z przeznaczeniem tego parametru, jak zacytowała SpiderMum. To, że strona zdaniem bota "działa", to za mało moim zdaniem dla dodawania tej daty (nawet jeśli dodaje się tytuł). MarMi wiki (dyskusja) 21:15, 27 kwi 2024 (CEST)[odpowiedz]
Ja kiedyś przy botowaniu szablonów LZ bądź cytowania również wstawiałem datę dostępu, jednak ustalałem ją na podstawie historii edycji. Przyznaję, że jest to dość karkołomne i czasochłonne zajęcie. Próbowałem nawet skorzystać z wyszukiwarki oferowanej na stronie historii edycji. Jednak serwis szybko zbanował mojego bota. Myślę, że najlepszym rozwiązaniem automatycznym byłoby, gdyby bot sprawdził czy dany link pojawił się w artykule w jednej z ostatnich edycji, na przykład w nie później niż ostatnie 48h. To byłby taki test świeżości danych, konieczny acz niewystarczający, aby go zamienić później w szablon. Paweł Ziemian (dyskusja) 07:56, 28 kwi 2024 (CEST)[odpowiedz]
Jakoś dziwnie zachowują się ostatnio wersje przejrzane:
1. Chcę anulować nieprzejrzaną edycję i powrócić do poprzedniej, przejrzanej wersji. Klikam "anuluj edycję" i widzę opcję "[ ] Oznacz tę wersję jako przejrzaną (włącznie z 1 oczekującą zmianą)". Nie powinno tego być i dawniej nie było. jest też zupełnie zbędne, bo niezależnie, czy zaptaszkuję tę opcję, czy nie (i kliknę w guzik „Zapisz i pozostaw do przejrzenia”), to moja wersja i tak jest przejrzana. Przy anulowaniu przez edycję poprzedniej wersji oraz przez "revert" w pop-upsach jest poprawnie, opcja oznaczania nie pojawia się.
2. Przenoszę hasło w wersji przejrzanej pod nową nazwę. Nowy artykuł wymaga przejrzenia. Nie powinno tego być i dawniej nie było.
Też zaobserwowałem ten problem. Wydaje się, że kliknięcie "Oznacz tę wersję jako przejrzaną..." nie ma żadnego efektu – musiałem w takich sytuacjach przeglądać własne edycje ręcznie. Przeglądam też dziś wyjątkowo dużo edycji doświadczonych redaktorów, które nie wyglądają na pozostawione bez przejrzenia celowo. Epsilon598 (dyskusja) 20:00, 8 kwi 2024 (CEST)[odpowiedz]
Problem został już zgłoszony na Phabricatorze i ma gotowe rozwiązanie, które zostanie wdrożone w tym tygodniu (plwiki zwykle dostaje wdrożenia w czwartki): T361940. Zgłoszenia dotyczyły wprost przenosin oraz akcji, które nie powodują zmiany treści, czyli np. zabezpieczenia. Jest prawdopodobne, że tak samo ten znany problem dotyczy wycofywania zmian. Msz2001 (dyskusja) 20:34, 8 kwi 2024 (CEST)[odpowiedz]
@Wargo, @Msz2001, @Matma Rex: Dzięki za działania w tej sprawie w Phabricatorze! Jeszcze jedno dziwne zachowanie, nie wiem, czy poprawka Matmy Rexa (która chyba jeszcze nie została włączona?) to załatwi: Jeśli w sytuacji jak wyżej, oglądam sobie diffa i zamiast anulowania edycji otworzę do edycji poprzednią, oznaczoną wersję, to jedyną opcją jest Zapisz i pozostaw do przejrzenia, co nie ma sensu, bo przecież edytuję wersję przejrzaną. Nie ma opcji [ ] Oznacz tę wersję jako przejrzaną. Po zapisaniu moja edycja jest nieprzejrzana i muszę ją oznaczyć ręcznie. Michał Sobkowskidyskusja09:57, 19 kwi 2024 (CEST)[odpowiedz]
Dawniej anulując nieprzejrzaną edycję oprogramowanie magicznie "wiedziało", że po anulowaniu hasło będzie przejrzane. Dziś na przycisku pojawia się napis Zapisz i pozostaw do przejrzenia i pojawia się ten checkbox Oznacz tę wersję jako przejrzaną (włącznie z 1 oczekującą zmianą), mimo, że po zapisaniu hasło jest oczywiście przejrzane. Nieco irytujące, bo nie mam pewności, czy faktycznie zapisuję nieprzejrzaną edycję, czy nie. Da się jakoś przywrócić lepsze czasy? IOIOI200:32, 16 kwi 2024 (CEST)[odpowiedz]
Rzuciłem okiem i się złapałem za głowę. Poprawianie kodu na tych stronach to istny koszmar. Przykładowo Portal:Dąbrowa Górnicza/Zabytki/podstrona: tabele tworzone bez nagłówków <table></table>, po prostu wrzucone <tr> i reszta tabeli, w środku zagnieżdżone tabele tworzone wikisposobem, dodatkowo tu i ówdzie wrzucone szablony tworzące kolejne tabele. Wydaje mi się, że sam spowodowałeś kilka błędów lintera, poprzez usunięcie okalających <td></td>, np. [10], patrz na podpis pod treścią: Spis podstron portalu. Tworzy własną komórkę tabeli HTML <td>...</td>. Szczerze, czy jest sens poprawiania tych podstron oraz utrzymywania tego kodu? Raczej i tak nikt tam nie zagląda, jest box na górze o wygaszaniu portali (ostatnia dyskusja). Ręczna poprawa tego to długie godziny rozgryzania jak co powinno wyglądać, co i gdzie powinno być inkludowane, itp. a zysk dla Wikipedii z tego zerowy(?), bo, jak wcześniej pisałem, nikt tam nie zagląda. Chyba, żeby to jakoś wszystko zamienić na szablony z Kategoria:Szablony do budowy portalu, ale czy to nadal byłaby archiwizacja (zachowanie czegoś w oryginalnym stanie)? Szczerze, to nie wiem co należałoby zrobić. tufor (dyskusja) 20:04, 22 kwi 2024 (CEST)[odpowiedz]
Zrobiłem trochę porządku z Portalem "Architektura". Może nie wygląda teraz idealnie, ale wszystko co w portalu było zrobione jest widoczne na jednej stronie i tabelki są normalnie składane (a nie częściami na różnych podstronach). Inne muszą poczekać na innych/później. ~malarz plPISZ23:20, 22 kwi 2024 (CEST)[odpowiedz]
Teraz poszła "Dąbrowa Górnicza". Posprzątany w podobny sposób. Później jeszcze przeklikam Żywiec. Z tego o czym początkowo wspominał PMG zostało tylko to. ~malarz plPISZ17:59, 24 kwi 2024 (CEST)[odpowiedz]
Widzę, że PMG wraz z Malarzem poprawili pozostałe strony i wszystkie błędy lintera, przynajmniej z tych trzech kategorii, zostały wyeliminowane. Jednak zanim wątek zostanie oznaczony jako załatwiony, to jeszcze pociągnę kwestię portali. @malarz pl, mógłbyś może uruchomić bota i zastąpić te amboxy, które wstawił @AramilFeraxa, na szablon {{Wygaszanie portali}} (zrobiony na szybko, poprawki redakcyjne mile widziane), przykładowy diff. IMO dobrze jest mieć możliwość zmiany komunikatu w jednym miejscu. Dodatkowo, wydaje mi się, że można też pousuwać w tej przestrzeni wywołania szablonu {{porzucony projekt}}; mówi on o możliwości reaktywacji portalu, a tego raczej nie przewidujemy(?). Myślałem też chwilę nad portalami Portal:Aktualności i Portal:Kategorie Główne. Czytałem pierwotną dyskusję, ale nie widziałem w niej pomysłu zwykłego przeniesienia tych stron do przestrzeni Wikipedia: bądź Wikiprojekt:; może w tą stronę należałoby pójść? Kłaniam się, tufor (dyskusja) 18:33, 26 kwi 2024 (CEST)[odpowiedz]
Dzięki za przypomnienie. Zmieniłem jeszcze nazwę szablonu (dla większości miejsc wywołań jest właściwsza). Bot poprawił 216 portali i 5 stron poza przestrzenią Portal. Jeżeli coś jeszcze jest to ma inną treść. Dwa wywołania zostały zmienione przez IPka i rewertowałem. Może coś bardziej zostało zmienione. ~malarz plPISZ23:59, 13 maj 2024 (CEST)[odpowiedz]
Nie wiem co zrobić. Chcę napisać o albumie muzycznym, w którym zamieszczono utwory: demo, live, studyjne, single, nagrania z prób. Cokolwiek dam w obowiązkowym polu "rodzaj albumu" będzie nieprawdziwe, lista możliwości jest określona "na sztywno" i nie ma czegoś takiego jak mix. Czy ktoś obeznany nie mógłby dodać możliwości określenia typu "różne" albo "inne" lub coś podobnego ? To obecne rozwiązanie jest moim zdaniem zbyt zamknięte i nie uwzględnia takich nietypowych sytuacji. Pozdrawiam Joee (dyskusja) 13:27, 13 maj 2024 (CEST)[odpowiedz]
Obecnie to pole wpływa głównie na kolor szablonu (i dopełniacz przy wykonawcy). Pewnie wypadałoby w końcu przepracować ten szablon usuwając pozostałości po nadmiarowej "magii" i posprzątać jego wywołania. Zrób jakoś i podaj nazwę artykułu. Zastanowimy się jak najlepiej/najszybciej coś z tym zrobić. ~malarz plPISZ17:38, 13 maj 2024 (CEST)[odpowiedz]
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
Na Wikiźródłach istnieje strona specjalna, która zbiera strony bez odpowiadających im skanów. Od teraz można używać magicznego słowa __EXPECTWITHOUTSCANS__, aby powstrzymać niektóre strony (np. spisy wydań czy tłumaczeń) przed pojawianiem się na wspomnianej liście. [11]
U osób korzystających z ustawienia „Pokazuj podgląd bez przeładowywania strony” funkcja „Podgląd strony z tym szablonem” również zadziała bez przeładowywania strony. [12]
Mapy Kartographera mogą teraz mieć podany tekst alternatywny z użyciem atrybutu alt=. Działa to podobnie jak alt= w składni ilustracji i galerii. Nie dotyczy to wiki takich jak Wikipodróże, gdzie miniaturki map są interaktywne. [13]
Stary samouczek, pokazujący „nowe filtry do przeglądania zmian” został usunięty. Utworzono go w 2017 roku, aby pokazać doświadczonym użytkownikom, jak zmienił się interfejs. Od tej pory zobaczyło go większość ludzi, do których był kierowany. [14]
Zmiany w tym tygodniu
Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 14 maja, na stronach innych niż Wikipedia i niektórych Wikipediach od 15 maja, a następnie na wszystkich wiki od 16 maja (harmonogram). [15][16]
Dla lepszej dostępności, strona Specjalna:Szukaj będzie korzystać teraz z układu CSS flex. Jeśli wasze gadżety wpływają na wyświetlanie wyników wyszukiwania, powinny zostać dostosowane do nowej struktury HTML tej strony. [17]
Przyszłe zmiany
W skórce Wektor 2022, strony główne będą pokazywane na pełnej szerokości (podobnie jak strony specjalne). Dzięki temu liczba znaków w wierszu będzie lepsza. Jest to związane z nadchodzącymi zmianami w typografii w Wektorze 2022 Dowiedz się więcej. [18]
Dwie kolumny tabeli pagelinks w bazie danych (pl_namespace i pl_title) zostaną niedługo skasowane. Użytkownicy powinni zamiast tego korzystać z dwóch kolumn tabeli linktarget (lt_namespace i lt_title). W istniejących zapytaniach SQL należy:
zamienić JOIN pagelinks na JOIN linktarget i pl_ na lt_ w klauzuli ON
dodać JOIN pagelinks ON lt_id = pl_target_id poniżej
Dzisiaj we wszystkich przeglądarkach (Safari, Chrome) główna strona Wikipedii i niektóre dalsze (nie wychwyciłem schematu) po zalogowaniu czarne mi się otwierają, nie mam pojęcia co zrobiłem i nie potrafię tego odkręcić. W każdym razie zawsze gdy wybiorę listę obserwowanych stron to przełącza mnie na czarny interfejs. Kiedyś, przed laty, korzystałem z takiego ustawienia intefejsu ale je porzuciłem, a dzisiaj nawet nie mogę przycisków do niego znaleźć aby to odkręcić. Czonek (dyskusja) 10:25, 16 maj 2024 (CEST)[odpowiedz]
Mi tak się Wikidane dzisiaj otwierały. W najnowszym Wektorze na górze jest ikonka okularów, tam jest wybór trybu (jasny/ciemny/automatyczny). Wostr (dyskusja) 12:45, 16 maj 2024 (CEST)[odpowiedz]
Ja na szczęście nie mam tego problemu (jeszcze?) ale nie widzę opcji wyboru trybu ani w menu głównym po lewej, ani pod ikonką okularów. Zdaje się, że ten tryb był przez jakiś czas funkcją eksperymentalną, ale też go już tam nie ma (podobnie jak gdziekolwiek indziej w preferencjach). Barcival (dyskusja) 13:09, 16 maj 2024 (CEST)[odpowiedz]
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
Masowe usuwanie będzie obsługiwało teraz również te strony, które zostały przeniesione pod inny tytuł. [21]
Wprowadzono zmiany w Kreatorze przesyłania plików: poprawiono ogólny układ, dostosowując style i odstępy w formularzu i jego polach; poprawiono nagłówki i teksty pomocy dla poszczególnych pól; pole Podpis jest teraz obowiązkowe i jego treść może być skopiowana do opisu pliku. [22][23]
Zmiany w tym tygodniu
Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 21 maja, na stronach innych niż Wikipedia i niektórych Wikipediach od 22 maja, a następnie na wszystkich wiki od 23 maja (harmonogram). [24][25]
Struktura HTML wykorzystywana do wyświetlania nagłówków zostanie zmieniona, aby poprawić dostępność. Nastąpi to 22 maja w niektórych skórkach (Timeless, Nowoczesna – Modern, Błękit – CologneBlue, Nostalgia i Książka – Monobook). Prosimy o przetestowanie gadżetów w tych skórkach i o zgłaszanie powiązanych problemów, tak aby mogły być naprawione przed wdrożeniem tej zmiany do pozostałych skórek. Jest rozważane również wprowadzenie API do dodawania przycisków do tytułów sekcji, jeśli byłoby to pomocne twórcom gadżetów. Zapraszamy do podzielenia się opinią na ten temat.
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
Naprawiono kilka błędów związanych z ostatnimi aktualizacjami Kreatora przesyłania plików na Wikimedia Commons. Aby uzyskać więcej informacji, zobacz T365107 i T365119.
W marcu 2024 dodano nowe API – addPortlet – aby ułatwić gadżetom tworzenie nowych menu w skórce. W niektórych skórkach może posłużyć do tworzenia rozwijanych menu. Zapraszamy twórców gadżetów do przetestowania API i podzielenia się opinią o nim.
Pewne reguły CSS w skórce Minerva zostały usunięte, aby pozwolić na łatwiejszą konfigurację przez społeczność. Edytorzy interfejsu powinni sprawdzić wyświetlanie się na urządzeniach mobilnych elementów związanych z klasami .collapsible, .multicol, .reflist, .coordinates, .topicon. Dostępne jest więcej szczegółów o zastępczym CSS, jeśli będzie potrzebne.
Zmiany w tym tygodniu
Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 28 maja, na stronach innych niż Wikipedia i niektórych Wikipediach od 29 maja, a następnie na wszystkich wiki od 30 maja (harmonogram). [26][27]
Kiedy odwiedzasz wiki, na której nie masz jeszcze lokalnego konta, zasady na tej wiki (takie jak filtry nadużyć) mogą powstrzymać automatyczne utworzenie konta dla ciebie. Od tego tygodnia, MediaWiki będzie również uwzględniać globalne uprawnienia podczas sprawdzania, czy możesz ominąć takie zasady. [28]
SK nie uwzględnia nazwy grupy podanej w szablonie Przypisy (przynajmniej dwóch wariantów "=nazwa" i "grupa=nazwa", o ile w ogóle). Powinien to zamieniać na <references group="nazwa">, a nie oddzielnie na tag references z nazwą grupy wstawioną jako tekst poniżej tego tagu. Albo przynajmniej powinien nie tykać szablonu z nazwą grupy, skoro nie potrafi tego obsłużyć. Przy okazji, podawanie nazwy grupy moim zdaniem nie jest jasno opisane w dokumentacji szablonu/modułu - bo co to niby znaczy "wartość pusta" (brak przykładu)? Sam dopiero po dłuższej chwili skojarzyłem, że to po prostu chodzi o podanie samego znaku "=" bez cyferki (parametry nie/nazwane; wcześniej domyśliłem się że "=" oznacza nazwę grupy patrząc w kod modułu...). Edycja: Ba, nawet Pomoc:Parametry nie wspomina o takim czymś. MarMi wiki (dyskusja) 22:59, 25 maj 2024 (CEST)[odpowiedz]
Hm... SK uwzględnia jak się wpisze parametr grupa=nazwa (a przynajmniej powinien). Ten parametr bez nazwy jest bardzo dziwny... Moim zdaniem to nieczytelne (nieintuicyjne) i nie powinniśmy czegoś takiego używać. Wydaje mi się, że to działa chyba tylko dlatego, że to jest w Lua, bo w normalnym szablonie, jak słusznie zauważył MarMi, coś takiego raczej nie będzie działać...
W każdym razie mogę spróbować to jakoś obsłużyć w SK, albo zbotować dodając normalną nazwę parametru (jeśli nie jest tego dużo). Spróbuję to ogarnąć w najbliższych dniach. Nux (dyskusja) 14:02, 28 maj 2024 (CEST)[odpowiedz]
Witam. Zauważyłem przypadkowo, że w tym komunikacie nie ma rozróżnienia na strony użytkownika i brudnopisy (podstrony). Komunikat zawsze myśli, że chcemy utworzyć stronę użytkownika, nawet jeśli w tytule jest znak /, sugerujący, że mamy do czynienia z podstroną. Utworzyłem propozycję komunikatu: Wikipedysta:Tufor/noarticletext. Prośba do administratorów interfejsu o przeczytanie i – po ewentualnych poprawkach redakcyjnych – o wrzucenie w przestrzeń MediaWiki. Kłaniam się, tufor (dyskusja) 18:00, 17 maj 2024 (CEST)[odpowiedz]
Ależ oczywiście. Dlatego zaproponowałem warunek {{#if: {{#titleparts: {{PAGENAME}} | 2 | 2 }} | ... | ... }} w przestrzeni Wikipedysty by stwierdzić czy jest to brudnopis czy faktycznie strona użytkownika, a co za tym idzie, by wyświetlić użytkownikowi prawidłowy komunikat. A prośba została skierowana do adminów interfejsu, ponieważ jest tam nieoczywisty element „programistyczny” (wspomniana wyżej instrukcja warunkowa). tufor (dyskusja) 18:18, 17 maj 2024 (CEST)[odpowiedz]
Tak mnie w sumie zastanawia, o co chodzi z tymi dwoma 2 w warunku, który wpisał @Tufor. Bo ja wiem , że namespace 2 oznacza przestrzeń Wikipedysta, Wikipedystka albo User. Strony dyskusji to to nie są, bo one mają już ns 3. XaxeLoled⸤ AmA ⸣18:54, 17 maj 2024 (CEST)[odpowiedz]
Zatem... wstawi ktoś? ;) Wiem, że nikt nie lubi wrzucać nieswojego kodu/tekstu, ale nie ma tam raczej nic kontrowersyjnego, a i Malarz poprawił warunek, więc powinno hulać ;) tufor (dyskusja) 20:29, 19 maj 2024 (CEST)[odpowiedz]
Dodałem przypis z DOI, co zrobić jak link prowadzi do domeny na AfterMarket, czyli do kupienia (https://doi.org/10.52652/inaw.25). Czy coś powinno się z tym zrobić? Np. dodać link do archive.org. Czy może to doi.org, powinno coś z tym zrobić? -- Jakub T. Jankiewicz (@Jcubic) (zagadaj) 18:57, 1 maj 2024 (CEST)[odpowiedz]
Jest link do artykułu, więc jeżeli DOI jest nieprawidłowe, usunąć z opisu bibliograficznego. Potem zgłosić ten fakt do wydawnictwa – jak poprawią to ze swojej strony, to DOI można przywrócić. Wostr (dyskusja) 20:48, 1 maj 2024 (CEST)[odpowiedz]
@Nux teraz to już za późno, domena jest na After Market. Chyba że zmienili, aby nie płacić dodatkowo. Więc może trzeba gdzieś zgłosić, że adres nieaktualny. -- Jakub T. Jankiewicz (@Jcubic) (zagadaj) 00:07, 2 maj 2024 (CEST)[odpowiedz]
Problem jest szerszy. DOI są wprawdzie unikatowe, ale mogą przestać działać. Obecnie szablon {{Cytuj}} ukrywa datę dostępu dla artykułów z DOI, ale czy jest to właściwe? Osobiście niejednokrotnie usuwałem pole „data dostępu”, jeśli szablon cytowania zawierał DOI, ale teraz mam wątpliwości. I niestety nie mam pomysłu na rozwiązanie. Archiwizacja? W zgłoszonym przypadku to działa: https://web.archive.org/web/20210415000000*/https://doi.org/10.52652/inaw.25, ale potrzebne by było rozwiązanie ogólne. Michał Sobkowskidyskusja18:48, 2 maj 2024 (CEST)[odpowiedz]
Data dostępu dotyczy treści dynamicznej (strony internetowej, która może ulegać zmianom). W opisie bibliograficznym zaś cytujemy artykuł naukowy, nie zaś stronę, na której się znajduje. Jeżeli zaś DOI przestał działać – zarchiwizowany URL może trafić do parametru url. Wostr (dyskusja) 19:44, 2 maj 2024 (CEST)[odpowiedz]
Znalazłem URL to tego artykułu w Google Scholar, tam link działa normalnie. Więc parametr URL jest ok, nie trzeba zmieniać linku na archiwum. Problem jest tylko z DOI, więc teraz są dwa adresy URL, jeden z URL, który działa i drugi z DOI, który prowadzi do błędnego przekierowania. -- Jakub T. Jankiewicz (@Jcubic) (zagadaj) 20:53, 2 maj 2024 (CEST)[odpowiedz]
Cześć! Wiele stron na Wikipedii posiada linki do Biblioteki Ossus. Mimo to Biblioteka Ossus nie posiada u nas interwiki, w przeciwieństwie do wielu innych mniej lub bardziej znanych wiki, od Wookieepedii począwszy (wookieepedia:), na czeskiej wiki o prawie skończywszy (iuridictum:). Czy nie warto byłoby więc dodać linków do Biblioteki Ossus (https://ossus.pl)? (Lista bieżących interwiki: Specjalna:Interwiki) Pozdrawiam, ~Mustafar29(dyskusja • wkład)19:37, 3 maj 2024 (CEST)[odpowiedz]
Gdy otwieram do edycji (VE) hasło Hans Geissel prawie każde słowo podkreślone jest na czerwono. W innych artykułach tylko słowa w obcych językach lub błędnie zapisane. W kodzie nie widzę nic zdrożnego. Czy to nie jest przypadkiem efekt jakichś białych spacji czy użycia dziwnej czcionki przez autora? Sprawa może jest błaha, przeszkadzając tylko edytorom słabo ortograficznym, a może jakiś bug? 77.254.44.35 (dyskusja) 10:38, 5 maj 2024 (CEST)[odpowiedz]
(KE) Widoczne są w edytorze wikikodu z włączonym podświetlaniem składni (tryb edycji + ikonka ołówka w pasku narzędzi nad oknem edycji). W miejscu tych kropek znajdują się znaki niewidoczne, np. owe spacje białe. Peter Bowman (dyskusja) 12:27, 5 maj 2024 (CEST)[odpowiedz]
Ciekawe... Te kropki były do dzielenia wyrazów (podział na sylaby). U nas raczej niepotrzebne, bo i tak nie justujemy tekstu. Natomiast przeglądarka powinna brać pod uwagę, że są to znaki specjalne, które nie powinny mieć znaczenia dla sprawdzania poprawności tekstu (również wyszukiwanie na stronie powinno działać poprawnie przy tego typu dodatkach). Tak że ciekawe, że jest jakaś przeglądarka, która tego nie ogarnia (FF nie ma z tym problemu). Nux (dyskusja) 13:21, 5 maj 2024 (CEST)[odpowiedz]
Używam Opery, Wersja:95.0.4635.90, Kanał aktualizacji:Stable, System:Windows 7 64-bit, Wersja Chromium:109.0.5414.149. O ile komuś to coś mówi. Podobno używam najnowszej wersji Opery. 77.254.44.35 (dyskusja) 14:00, 5 maj 2024 (CEST)[odpowiedz]
Menu "Wygląd" będzie dostępne dla niezalogowanych użytkowników
Cześć wszystkim! Piszemy w imieniu zespołu Web z Wikimedia Foundation. Pracujemy nad ułatwieniem czytania projektów Wikimedia. Jest to związane z celem "Czytanie i korzystanie z mediów" w planie na bieżący rok budżetowy. W drodze do tego celu w grudniu 2023 wprowadziliśmy funkcję eksperymentalną – Ułatwienia czytania. Dodaje ona menu, które działa tylko na skórce Wektor 2022 i umożliwia zalogowanym użytkownikom dostosowanie wielkości tekstu zgodnie z indywidualnymi potrzebami. Jednocześnie funkcja ta zaspokaja potrzeby związane z dostępnością.
W menu jest opcja "Normalny". Nieznacznie zwiększa ona rozmiar i szerokość linii tekstu względem obecnych ustawień domyślnych. Została ona wybrana na podstawie zaleceń dotyczących dostępności dla wszystkich użytkowników (jaki tekst najłatwiej czytać większości osób), a także sugestii i projektów ponad 600 wikipedystów. Więcej o niej poniżej.
Jesteśmy gotowi do udostępnienia menu Wygląd zalogowanym i niezalogowanym użytkownikom. Jednocześnie, tylko dla niezalogowanych użytkowników, ustawimy domyślną opcję na "Normalny". Planujemy wprowadzić tę zmianę 29 kwietnia.
Więcej o menu
Menu Wygląd pozwoli zalogowanym i niezalogowanym użytkownikom ustawić:
Rozmiar tekstu i interlinii (dostępne teraz jako funkcja eksperymentalna): Użytkownicy mogą wybierać między opcjami: "Mały" (obecnie domyślna), "Normalny" (zalecana dla lepszej dostępności) i "Duży". Wybór ustawienia tekstu spowoduje zmianę zarówno wielkości tekstu, jak i interlinii.
Szerokość szpalty (dostępna dotąd jako osobny przełącznik): Przenieśliśmy przełącznik szerokości szpalty (widoczny na obrazku obok) z ikony na dole strony do okrągłego przycisku w nowym menu Wygląd. Przycisk będzie działał tak samo jak przełącznik, którego odtąd nie będzie.
Tryb ciemny (już wkrótce!): Użytkownicy będą mogli wybrać, czy chcą widzieć stronę w trybie nocnym na stałe, czy też użyć ustawienia "automatycznego", które ustawi tryb dzienny/nocny zgodnie z preferencjami urządzenia lub przeglądarki.
Opcja "Mały" to obecne domyślne ustawienie. Opcje "Normalny" i "Duży" zostały oparte na dwóch źródłach:
po drugie – na zaleceniach dostępności dla najlepszego przeciętnego rozmiaru tekstu dla większości czytelników. Zalecenia te stwierdzały, że obecny rozmiar jest zbyt mały, aby większość ludzi mogła wygodnie czytać. Oznacza to, że średnio ludzie czytają wolniej, męczą oczy podczas czytania lub mają trudności z wyraźnym widzeniem tekstu.
Menu pojawi się po prawej stronie, bezpośrednio pod menu Narzędzia. Będzie domyślnie przypięte i będzie można je odpiąć. Po odpięciu stanie się zwijalnym menu pod ikoną u góry strony (co przedstawiliśmy na zrzucie ekranu na początku tej wiadomości).
Dotychczasowa praca i kolejne kroki
To menu zostało sprawdzone w wersji eksperymentalnej przez zalogowanych użytkowników na różnych wiki, a także w testach z czytelnikami. Dzięki temu poprawiliśmy wrażenia użytkownika, ułatwiliśmy znalezienie i używanie menu, a także sprawiliśmy, że gadżety na różnych wiki mogą być z nim kompatybilne.
Zalogowani użytkownicy pozostaną na razie przy domyślnym ustawieniu "Mały", ale w każdej chwili będą mogli zmienić je na dowolne inne. W ciągu kilku następnych miesięcy zbadamy, ilu zalogowanych przełącza się na "Normalny" i rozpoczniemy rozmowy na temat tego, czy jest sens, aby "Normalny" stał się domyślny także dla nich. Z wczesnych danych z używania funkcji eksperymentalnej wynika, że w 55% sesji, w których użytkownik wszedł w interakcję z menu, zostały wybrane opcje "Normalny" lub "Duży".
Bardzo zła informacja. Dziesiątki tysięcy artykułów są nieprzygotowane na powiększenie czcionki. WMF nie podjęła żadnych kroków, by temu przeciwdziałać. Jesteśmy postawieni przed faktem dokonanym, bez żadnych narzędzi dających kontrolę nad sposobem wyświetlania tabel. Barcival (dyskusja) 12:25, 14 kwi 2024 (CEST)[odpowiedz]
Hej @Barcival, dzięki za komentarz, pamiętam o Twoich uwagach co do spacji niełamiących i klas wskazujących, żeby nie łamać tekstu. Czy możesz podać przykłady, gdzie może pojawić się problem z tabelami i jak według Ciebie powinno być? Może jakiś zrzut ekranu? Zespół byłby bardzo wdzięczny - inaczej trudno im się odnieść. Dziękuję. SGrabarczuk (WMF) (dyskusja) 15:34, 15 kwi 2024 (CEST)[odpowiedz]
@SGrabarczuk (WMF)Tutaj widać, jak nazwiska po podziale na dwie linie znajdują się pod cyfrą bądź flagą, co wygląda nieestetycznie. Tutaj widać, że jako najdłuższa nazwa miejscowości, Garmisch-Partenkirchen podzieliła się na dwie linijki, ale większość uzyskanego w ten sposób miejsca, zamiast poszerzać pozostałe kolumny jest marnowana – Bischofshofen jest w całej kolumnie drugą co do długości nazwą, a 12 mm miejsca widoczne bezpośrednio na prawo od tego słowa nie jest wykorzystywane. Jest to niewłaściwe zachowanie. Kolejny plik – oprogramowanie dzieli wiersze na kolejne linie, by zmieścić tabelę na szerokość i pozostawia ten podział nawet, gdy nie pozwoli on na zmieszczenie się na jednym ekranie. Mamy więc poszczególne wiersze zajmujące na zmianę od 1 do 3 linijek, co zmniejsza mocno ich czytelność, a równocześnie części tabeli i tak nie widać. Różnicę w czytelności można porównać pomiędzy tą wersją (oprogramowanie usiłujące zmieścić wszystko na jednym ekranie i ponoszące porażkę), a tą wersją (obecnie stosowaną w haśle, wykorzystującą Szablon:Nowrap). Różnica w czytelności jest wyraźna, a wspomniany szablon jest jedyną znaną mi metodą wymuszenia na oprogramowaniu Wiki niedzielenia zawartości kolumny na wiele linijek. Szablon stosowany jest w komórce o największej szerokości, wymagana jest więc jego podmiana za każdym razem, gdy w zawodach startuje nowy zawodnik o dłuższym nazwisku niż wszyscy poprzedni. Powinna istnieć możliwość ustawienia poszczególnych kolumn bądź całej tabeli jako niepodzielnych w ramach preambuły tej tabeli. Oprogramowanie nie powinno też zostawiać wierszy podzielonych w sytuacji, gdy nie pozwala to na zmieszczenie całej tabeli wewnątrz ekranu, bo uniwersalnie psuje to czytelność. Wreszcie tutaj widać, jak rozdzielane są wartości i jednostki (odległości i metry) oraz jak zawartość komórki rozwleczona zostaje aż na 4 linie. No i przypominam, że o ile wszystkie te konkretne sytuacje są ważne, to głównym problemem jest fakt, że dziesiątki tysięcy haseł, które do tej pory mieściły się na jednym ekranie na desktopach, po przeforsowaniu zwiększenia czcionki przestaną się mieścić. Barcival (dyskusja) 22:24, 16 kwi 2024 (CEST)[odpowiedz]
Cześć @Barcival, jestem Olga, menedżerka produktu w zespole Web. Dzięki za dokładne wskazanie na te artykuły! Chciałam wyjaśnić, jakie założenia przyjmujemy i jak oceniamy konsekwencje naszych zmian.
Po pierwsze, masz rację, gęstość informacji jest czynnikiem, który wszyscy musimy wziąć pod uwagę, myśląc o czytelności. Istnieją jednak także inne czynniki ważne dla czytelności, takie jak fizyczny komfort czytania. Jednocześnie, nawet teraz ze względu na wiele zmiennych, artykuły nie są statyczne i ich wyglądu nie da się w pełni kontrolować. Chcę podkreślić, że jest to normalne i nie oczekujemy, żeby było inaczej. Ważne, aby brać to pod uwagę przy podejmowaniu decyzji dotyczących układu elementów w artykułach.
Na przykład problem, który zauważyłeś, że nagłówki tabel dzielą się na dwie linie, już teraz występuje u wielu użytkowników – tych z wąskimi ekranami i tych, którzy zwiększyli rozmiar czcionki za pomocą ustawień przeglądarki. Najlepiej byłoby nie dzielić tekstu w tabelach tam, gdzie to możliwe. Uważamy jednak, że w tym przypadku zmniejszenie czytelności jest mniejsze niż zmniejszenie czytelności spowodowane niewłaściwym rozmiarem czcionki i obecnymi domyślnymi ustawieniami tekstu. Poza tym podzielenie tekstu na dwa wiersze nie powoduje podobnego zmęczenia oczu. W związku z tym nie uważamy wprowadzanej zmiany za regresję.
Chcielibyśmy również zachęcić wszystkich do zapoznania się z naszymi zaleceniami dotyczącymi formatowania artykułów. W szczególności warto wziąć pod uwagę sposób, w jaki elementy w artykułach są prezentowane na wąskich ekranach, na urządzeniach mobilnych, w różnych przeglądarkach i przy różnych ustawieniach przeglądarki, w tym przy różnych rozmiarach czcionki. Może to być dobra okazja dla waszej społeczności, aby wspomnieć o tych zaleceniach na odpowiednich stronach pomocy i zaleceń.
Wszystkie te idee brzmią pięknie i może są nawet słuszne, Nie zmienia to faktu, że zadanie wprowadzenia ich zrzucacie na wolontariuszy, nie dając żadnych narzędzi mogących w tym pomóc. Barcival (dyskusja) 16:03, 26 kwi 2024 (CEST)[odpowiedz]
@Barcival, dzięki za odpowiedź. Dopytam, żebyśmy się dobrze zrozumieli – co Twoim zdaniem wolontariusze mają teraz wprowadzić, do czego nie mają narzędzi? Myślę, że wiem, o co Ci chodzi, ale sprawa jest na tyle poważna, że wolę nie zakłócać i poprosić dalej o Twój własny komentarz. Nawet jeśli faktycznie wolontariusze muszą (czy będą musieli) coś zrobić, bardzo nie chcę, żeby nasze wnioski co do tego się rozmijały. To ma znaczenie dla wielu wiki. SGrabarczuk (WMF) (dyskusja) 21:03, 26 kwi 2024 (CEST)[odpowiedz]
@SGrabarczuk (WMF) Ta dyskusja jest męcząca, ile razy mam pisać to samo? W wyniku wprowadzonych przez WMF zmian w tysiącach haseł dla typowych rozdzielczości ekranu obniżona zostanie czytelność tabel poprzez rozdzielenie treści pisanych przy założeniu, że będą mieścić się w jednej linii, na wiele linii bądź poprzez wypchnięcie części treści poza szerokość ekranu. Przywróceniem tej czytelności do akceptowalnego stanu będą musieli zająć się wolontariusze, bo WMF-u ten problem wyraźnie nie obchodzi. Nie ma prostych narzędzi do modyfikacji tabel, więc przywracanie czytelności będzie zajęciem pracochłonnym i czasochłonnym. Barcival (dyskusja) 21:42, 26 kwi 2024 (CEST)[odpowiedz]
Myślę, że Olga na to odpowiedziała:
"obniżona zostanie czytelność" - "nie uważamy wprowadzanej zmiany za regresję", bo "w tym przypadku zmniejszenie czytelności jest mniejsze niż zmniejszenie czytelności spowodowane niewłaściwym rozmiarem czcionki i obecnymi domyślnymi ustawieniami tekstu" (innymi słowy: lepiej mieć tekst zawinięty, niż za mały);
co do "typowych rozdzielczości ekranu", rekomendacje nie wykładają tego wprost (może powinny - zasugeruję to Jonowi, głównemu informatykowi w Web), ale zespół zaleca nie patrzeć na typowe rozdzielczości ekranu komputera (desktopu) i skupić się tylko na tym, żeby elementy artykułu nie sypały się poniżej 500px. Powyżej nie ma żadnej kontroli i założenie, że coś będzie się mieściło w jednej linii, albo że będzie na ekranie, jest błędne.
Po weekendzie poproszę zespół o doprecyzowanie stanowiska.
Osobiście wydaje mi się, że perspektywa edytorów jest taka: zakładamy, jaka jest typowa wielkość ekranu, jaki jest domyślny układ i jeśli tekst w tabeli zawija się przy domyślnej wielkości, to robimy CSS-em style="font-size:x%", gdzie x jest możliwie duży, ale na tyle mały, żeby tekst już się nie zawijał. Z tym że to rozwiązanie zakłada, ile bezwzględnie wynosi 100%, co jest błędne, jak się okazuje.
@SGrabarczuk (WMF) Re: "nie uważamy wprowadzanej zmiany za regresję" – przy dotychczasowej czcionce artykuły wyświetlały się zgodnie z intencją edytorów, po waszej zmianie nie będą. To w oczywisty sposób jest obniżeniem jakości. Re: perspektywa edytorów – moja perspektywa jako edytora jest taka, że niemal wszystkie tabele w "moich" artykułach (tzn. takich, za które staram się być odpowiedzialny, często jako pierwszy autor) nie zostały wstawione do nich przeze mnie, a pozostałe wstawiłem, kopiując kod z jakiegoś innego hasła. Nie wiem, czym jest CSS, nie wiem, jak będę mógł naprawić rozwalone tabele, ale będę musiał to robić zamiast wykonywać edycje merytoryczne. Barcival (dyskusja) 00:57, 27 kwi 2024 (CEST)[odpowiedz]
To bardzo lekkomyślne żeby łączyć treść z firmą. Ekrany i rozdzielczości będą się zmieniać. Pisząc na Wikipedii nie ma podstaw zakładać że u mnie wyświetla się tak jak u Ciebie. Marek Mazurkiewicz (dyskusja) 01:58, 27 kwi 2024 (CEST)[odpowiedz]
Wszystkich rozdzielczości nie da się kontrolować. Ale jeśli i u mnie, i u Ciebie, i u każdego innego czytelnika tabela wyświetla się źle, to trzeba ją naprawić. Barcival (dyskusja) 09:45, 27 kwi 2024 (CEST)[odpowiedz]
@Barcival, zapytam o to kolegów wprost, ale wydaje mi się, że absolutnie nie będziesz musiał tego robić. Chyba wręcz prosiliby Cię, żebyś tego nie robił. "Artykuły wyświetlały się zgodnie z intencją edytorów" - tak, ale nie. To znaczy: przy określonych ustawieniach się wyświetlały, przy innych nie, i branie takich, a nie innych ustawień jako 1. główny punkt odniesienia 2. pewnik (stałą) okazuje się [tutaj sam też się uczę] błędnym założeniem. SGrabarczuk (WMF) (dyskusja) 02:02, 27 kwi 2024 (CEST)[odpowiedz]
Nie wiem, co na to odpowiedzieć. "Popsujemy Wikipedię i zabraniamy wam jej naprawiać" nie jest wypowiedzią, której publicznego wyrażenia spodziewałem się po pracowniku WMF, ale też nie jestem nią jakoś bardzo zaskoczony. Barcival (dyskusja) 09:45, 27 kwi 2024 (CEST)[odpowiedz]
@Barcival odpowiem jako stary wikipedysta i stary webmaster (obecnie frontendowiec)... To co opisujesz jako "oprogramowanie", które coś wymusza, to obawiam się, że jest to przeglądarka, a nie mediawiki. Przeglądarki mają określone zasady przełamywania tekstów, dostosowywania układu różnych elementów, w tym tabel. Obawiam się, że tylko Ci się wydawało, że artykuły wyświetlają się w jakiś sposób. Jeśli polegasz na konkretnej szerokości ekranu czy wielkości czcionek, to one wyświetlały się "prawidłowo" tylko na Twoim ekranie. Tak, wiem, to jest strasznie upierdliwe, ale równocześnie pozwala innym lepiej konsumować internety, że tak powiem.
...rozmiar tekstu może zostać powiększony do 200% bez użycia technologii wspomagających oraz bez utraty treści lub funkcjonalności.
To oznacza, że zgodnie z założeniami WCAG (oraz polskiego prawa) witryny powinny być czytelne nawet przy znacznym powiększeniu tekstu. Jeśli artykuł staje się nieczytelny po powiększeniu tekstu, to obawiam się, że jest to w dużej mierze nasza wina.
Nie mówię, że jest to proste. Sam się głowię od dłuższego czasu, jak ogarnąć duże, szerokie tabele. W idealnej sytuacji nie powinniśmy mieć szerokich tabel... ale to jest mało realne, niestety. Parę testów robiłem tutaj: Wikipedysta:Nux/test szerokie tabele wide-wikitable. Można by dorzucić klasę narzędziową, która zrobi `nowrap`, póki ma to sens. W sumie fajnie by było, gdyby WMF zaproponowało jakieś klasy narzędziowe (podobne do `wikitable`). Trzeba jednak pamiętać, że problem stał się tylko lepiej widoczny (m.in. po wprowadzeniu nowej skórki). Problem jednak istnieje od wielu lat, jakoś tak od 2007 roku #winajabłka ;). Nux (dyskusja) 11:20, 27 kwi 2024 (CEST)[odpowiedz]
@Nux Dzięki za odpowiedź. Od początku rozumiem, że różne szerokości ekranu i ustawienia systemowe wielkości czcionki dają różny efekt wizualny. Nowością jest dla mnie za to wieść, że to przeglądarka jest odpowiedzialna za podział na linie. Rozumiem, że w związku z tym na wskazany przeze mnie wyżej przykład z Garmisch-Partenkirchen nic się nie poradzi. Zgadzam się, że problem robienia tabel pod konkretne rozdzielczości istniał zawsze, a teraz staje się tylko lepiej widoczny. Ale skoro staje się widoczny, to trzeba mu pilnie przeciwdziałać, podczas gdy do tej pory nie był on priorytetowy. Fundacja, wprowadzając zmianę czcionki, powinna ten problem przewidzieć i przed jej wprowadzeniem podjąć kroki, a nie udawać, że on nie istnieje nawet po jego wskazaniu.
Twoje testy wyglądają ciekawie. Z paskiem przesuwania prawo-lewo na dole tabeli widzę problem, że jest bardzo ciężki w użyciu, jeśli tabela jest dłuższa niż wysokość ekranu. Czy pisząc o dorzuceniu klasy narzędziowej masz na myśli stworzenie czegoś lokalnie na pl-wiki, czy jest to coś, co musiałaby przygotować fundacja? Barcival (dyskusja) 21:56, 27 kwi 2024 (CEST)[odpowiedz]
Już to komentowałem, sugerując odpuszczenie tej funkcjonalności. Użytkownicy mający problem z czytaniem małych czcionek powiększają lub pomniejszają je za pomocą "CTRL +/-", co pozwala na powiększenie i pomniejszenie całej strony bez psucia jej kompozycji. Dotyczy to też nas – powiększenie samych czcionek rozwala wszystkie infoboksy i tabele. Kenraiz .ꓘ (dyskusja) 12:39, 14 kwi 2024 (CEST)[odpowiedz]
@Kenraiz, chciałbym wyjaśnić, jaki jest cel projektu. Nie wprowadzamy tego menu tylko dla osób mających wyraźny problem z czytaniem. Zmiana ma dotyczyć wszystkich, ponieważ to obecne ustawienia są problematyczne same w sobie. Więcej o tym znajdziesz na stronie projektu w sekcji Wprowadzenie oraz w raporcie z kwerendy literatury.
Co do infoboksów i tabeli, oprócz sprawy szerokich elementów, na którą odpowiedziałem niżej, czy mógłbyś napisać, jakiego dokładnie problemu z infoboksami chcesz uniknąć? Dziękuję. SGrabarczuk (WMF) (dyskusja) 15:31, 15 kwi 2024 (CEST)[odpowiedz]
Elegancko :) Niech przynajmniej włączenie czcionki Duża automatycznie ustawi też szerokość na Dużą. A propos dostępności - jak niepełnosprawny ma dotrzeć do tej opcji za pomocą klawiatury? Tabulatorem przez wszystkie LW? IOIOI213:08, 14 kwi 2024 (CEST)[odpowiedz]
co do wyświetlania układu okresowego pierwiastków - bardzo dobre spostrzeżenie. Jest to niestety ogólniejszy, głębszy problem przy szerokich tabelach, ilustracjach czy szablonach. Dotyczy on wszystkich skórek i występuje nie tylko przy tej funkcji, ale może pojawić się zawsze, kiedy u czytelnika treść wyświetla się trochę inaczej niż u edytora. Zespół Web opracował zalecenia, w których odniósł się do takich przypadków. Elementy szersze niż 500px powinny być zawinięte w element dodający im poziomy pasek przewijania.
Co do dużej opcji - różni czytelnicy mają różne preferencje. Dajemy im te opcje, żeby łatwiej i w sposób mniej zależny od działania przeglądarki i urządzenia ustawiali sobie takie opcje, z którymi będzie im wygodnie. Wymuszenie szerokości szpalty osobom, które po prostu chcą mieć większe litery, mijałoby się z celem projektu.
Co do tego, jak osoby z niepełnosprawnościami mogą korzystać z tego menu - jeśli dobrze rozumiem (nie mam innych informacji od naszych specjalistów od dostępności), nie inaczej niż z jakiegokolwiek innego menu. Czy zauważasz tutaj jakiś szczególny problem?
Podoba mi się ta zmiana. Szczególnie możliwość przełączenia na obrazu "szeroki". Wielkość czcionki łatwo było zmienić używając Ctrl+Scroll, to przełączenie daje efektywnie możliwość powiększenia jedynie szpalty z treścią artykułu (control myszka powiększała również menu) co dla czytelnika jest na pewno lepsze, czy dla mnie jako edytora - nie wiem. Dobrze by było aby te ustawienia zapisywały się w ciasteczkach na komputerze a nie w "użytkowniku". Ja często zmieniam komputer przy którym pracuję (przynajmniej 5 stałych różnych) i mam przy nich różne monitory (w jednym przypadku ustawiony na stałe pionowo - mój syn się kiedyś zapytał, dlaczego z monitora zrobiłem telefon) i dobrze by było aby akurat to ustawienie nie wędrowało za kontem tylko trzymało się lokalnie sprzętu. @SGrabarczuk (WMF) jakby Ci się chciało wymienić grafikę na górze na polskojęzyczną łatwiej by się czytało opis. Bo pisałeś co o "normalny", na grafice nic takiego nie ma :-) Uwaga IOIOI o potrzebie możliwości dotarcia do tego ustawienia z klawiatury jest IMO zasadna. Teraz zostaje nam zakasać rękawy i dostosować niektóre szablony do tych zmian. Pytanie tylko co się źle skaluje? ~malarz plPISZ23:11, 6 maj 2024 (CEST)[odpowiedz]
Zrobione i w razie czego zapraszam do wątku wyżej. ~malarz pl PISZ 17:12, 30 kwi 2024 (CEST)
.jpg)
Administratorzy interfejsu mają teraz większą kontrolę nad stylami komponentów w wersji mobilnej. Dzięki wprowadzeniu rozszerzenia 
Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 7 maja, na stronach innych niż Wikipedia i niektórych Wikipediach od 8 maja, a następnie na wszystkich wiki od 9 maja (harmonogram). [5][6]
Załatwione, ~malarz pl PISZ 18:45, 6 maj 2024 (CEST)
