Wygląda na to, że od dzisiaj nie działają już linki do dotychczasowych profilów naukowców w bazie Nauka Polska. Zamiast tego uruchomiony został nowy serwis Ludzie Nauki, gdzie przykładowa strona naukowca wygląda tak. Mówiąc wprost: co z tym robimy? W kontekście szablonu {{Ludzie nauki}}, ale też właściwości P3124 w Wikidanych, która dobija już do 50 tysięcy wartości, a także dwóch zbiorów danych zaimportowanych do narzędzia Mix'n'Match. Będę wdzięczny za Wasze opinie, pomysły itd. Powerek38 (dyskusja) 14:49, 27 lut 2024 (CET)[odpowiedz]
Wygląda na to, że w tym nowym serwisie również jest jakiś identyfikator, który występuje w adresie URL, np. https://ludzie.nauka.gov.pl/ln/profiles/bWF1dbjxbLb, a ten ciąg kryteriów wyszukiwania w linku od ciebie na szczęście nie jest konieczny do wyświetlenia profilu. Myślicie, że sposób mapowania identyfikatorów udałoby się pozyskać od któregoś ministerstwa w ramach dostępu do informacji publicznej? Msz2001 (dyskusja) 15:03, 27 lut 2024 (CET)[odpowiedz]
Dokładnie przed chwilą na to zwróciłem uwagę - jeszcze wczoraj wieczorem miałem gotowy link do Marii Szumiec, a potem przestał działać i teraz w nowej wyszukiwarce w ogóle nie ma takiej osoby (podobnie jak męża). Jak wyżej - albo to się uda rozkodować (bo jest jakiś system), albo dadzą dodatkowy parametr do starego systemu albo przepadło i trzeba budować od nowa. Emptywords (dyskusja) 15:09, 27 lut 2024 (CET)[odpowiedz]
[KE]Mnie w starym serwisie na stronie głównej wyświetla się „Trwa przerwa serwisowa, zapraszamy wkrótce”. Więc może jeszcze nie koniec? Bo jeśli koniec, to mamy kaszanę. Zapowiedzi były takie, że „Ludzie Nauki” zastąpią PBN, o likwidacji „Nauki Polskiej” nie słyszałem. Nowy serwis nie jest jeszcze funkcjonalny, ale wygląda na to, że wycięto część informacji, np. daty dzienne stopni i tytułów. Pytanie zasadnicze, czy po uruchomieniu pełnej wersji „Ludzi Nauki” OPI będzie chciało utrzymywać oba serwisy? Albo czy zrobią chociaż przekierowania ze starych adresów na nowe? PAN rok temu nie zrobił i "identyfikator członka PAN” (P8832) nie działa i to raczej bezpowrotnie.
Wargo, byłoby świetnie, gdyby udało się to zrobić. Ja rok temu analizowałem nowe URL-e i nie znalazłem uniwersalnej reguły, wg której te nowe są tworzone. O ile pamiętam, problem był z polskimi literami, drugim imieniem i drugim członem nazwiska - jeśli występowały, to były w różny sposób uwzględniane w URL-ach. Michał Sobkowskidyskusja09:27, 28 lut 2024 (CET)[odpowiedz]
Nux, to jest coś! Art. 219 ust. 14: "Przepisów wprowadzających...": "Od dnia wejścia w życie ustawy, o której mowa w art. 1 [czyli ustawy "Prawo o szkolnictwie wyższym i nauce"], nie gromadzi się nowych danych i informacji w bazie Nauka Polska prowadzonej przez Ośrodek Przetwarzania Informacji – Państwowy Instytut Badawczy". Ustawa weszła w życie z dniem 1 października 2018 r., czyli wersja archiwalne z 2019 r. jest wersją ostateczną. Michał Sobkowskidyskusja09:27, 28 lut 2024 (CET)[odpowiedz]
Z własnego doświadczenia wiem, że nie jest ostateczną. Uzyskałem stopień dr w czerwcu 2022 r. i jeszcze w tym samym miesiącu poprosiłem o dodanie do bazy przez formularz on-line, bez problemu moja prośba została rozpatrzona pozytywnie dosłownie w 1-2 dni. Co więcej, podobną procedurę moi znajomi młodzi (stażem doktorskim) doktorzy przechodzili skutecznie jeszcze w styczniu 2024 r. Także niezależnie od tego przepisu, w praktyce baza rosła aż do ostatniej chwili. Powerek38 (dyskusja) 09:32, 28 lut 2024 (CET)[odpowiedz]
Czyli wg ustawy powinna być ostateczna, ale nie była. :-) Faktycznie, także osoby wypromowane w moim instytucie bylły dodawane do bazy po 2019 r. Sprawdziłem teraz (mam takie zestawienie) - urwało się to dopiero we wrześniu 2022 (doktoraty)/czerwcu 2022 (habilitacje). Michał Sobkowskidyskusja10:16, 28 lut 2024 (CET)[odpowiedz]
Kolejne rozpoznanie przez atak. Najpierw nowa strona a później przeniesienie danych. "Proces przenoszenia danych będzie trwał do końca roku. Prosimy o cierpliwość i już teraz zapraszamy na nowy portal! Co teraz z Twoimi danymi? Na portalu Ludzie Nauki swoje dane z bazy Nauka Polska zobaczysz w ciągu najbliższych miesięcy. Ale przez cały ten czas możesz je uzupełniać i aktualizować.". Gdyby baza miała przynosić dochód to już konkurencja by zacierała ręce. Może dałoby się coś pomailować (najlepiej z poziomu WMPL a nie szeregowego edytora) w sprawie translacji identyfikatorów. Trochę info jest w https://ludzie.nauka.gov.pl/pomoc/jak-zmienic-swoje-dane-w-bazie-nauka-polska/. ~malarz plPISZ15:56, 27 lut 2024 (CET)[odpowiedz]
Ja też zwracam uwagę na ten cytat: Zgodnie z prawem Twoje dane z bazy Nauka Polska możemy przechowywać tylko do 2028 roku. Kiedy przeniesiemy je już do portalu Ludzie Nauki, zobaczysz je po zalogowaniu na swoje konto i zdecydujesz, czy je opublikować. Jeśli tego nie zrobisz, w 2028 roku będziemy musieli je usunąć. (źródło). Tu jest ewidentnie rola dla nas, żeby to zachować na dłużej, bo chyba Wikimedia nie będą się aż tak przejmować tymi przepisami? (zresztą nie wiem - @Nadzik, czy w WMEU wiecie coś o takiej regulacji?) Powerek38 (dyskusja) 16:05, 27 lut 2024 (CET)[odpowiedz]
Ogromne dzięki @Wargo, nie doczytałem. Nie jestem prawnikiem, ale na moje oko ten przepis nie ogranicza nas jako Wikimediów, tym ważniejsze jest zatem uratowanie tych danych. Powerek38 (dyskusja) 21:05, 27 lut 2024 (CET)[odpowiedz]
Ktoś mi wyciągnął dywan spod nóg :-( Mam gigantyczny plik tsv z ~ 190 tys. naukowców (dr wzwyż) z danymi z Nauka Polska, zmapowane do Wikidata ~ 50 tys. a także cache sqlite 2,6 GB danych. Jeszcze wczoraj pisali, że nowy serwer uruchamiają od kwietnia do końca roku. To nie FAIR. Kpjas (∵ ✍) 20:16, 27 lut 2024 (CET)[odpowiedz]
Czy można to jakoś udostępnić publicznie na tools.wikimedia.pl (prawo autorskie)?. Jakiś frontend do tego mogę napisać na kolanie. Tylko, że najważniejszym pytaniem jest co zrobią/zrobili z identyfikatorami. ~malarz plPISZ20:33, 27 lut 2024 (CET)[odpowiedz]
Prawa autorskie chronią utwór, a nie zawarte w nim informacje. Zatem korzystanie z informacji pochodzących z z Nauki Polskiej nie narusza praw autorskich twórców serwisu, o ile ktoś nie będzie robił kopii. ~CybularnyNapisz coś ✉20:59, 27 lut 2024 (CET)[odpowiedz]
Jeżeli chciałbym całą bazę wrzucić do przeglądania publicznie to raczej potrzebuję posiadać do niej prawa. A o to pytałem kilka linijek powyżej. ~malarz plPISZ21:11, 27 lut 2024 (CET)[odpowiedz]
W takiej sytuacji może mieć zastosowanie prawo sui generis, chroniące bazy danych przed ponownym wykorzystaniem w całości lub istotnej części [1][2]. Natomiast prawo autorskie może zazwyczaj dotyczyć jedynie struktury bazy danych. Msz2001 (dyskusja) 21:23, 27 lut 2024 (CET)[odpowiedz]
Ale zakładam, że nie będziesz odtwarzał takiego samego układu informacji, interfejsu itp. Zapewne chodzi raczej o wyciąg suchych informacji zapisanych alfabetycznie w pliku np. alfabetycznie po nazwisku i imieniu z dołączonymi innymi danymi. A to już są informacje, a nie kopia strony. Gdybyśmy nie mogli korzystać z informacji z powodu praw autorskich do źródeł, to by trzeba było większość uźródłowionych haseł usunąć. ~CybularnyNapisz coś ✉21:25, 27 lut 2024 (CET)[odpowiedz]
Nie jestem prawnikiem, ale rozumiem tę kwestię w taki sposób, że ze względu na ochronę baz danych nie możesz stworzyć narzędzia, które replikuje funkcjonalność pierwotnej bazy danych, wykorzystując dane z niej pozyskane. Natomiast przetworzenie tych danych do wykorzystania w innym celu lub np. udostępnianie ich według innych kryteriów (np. wyszukiwanie według innych pól, agregacja danych itp.) nie jest publikacją bazy danych, lecz informacji w niej zawartych. Samo to prawo chroni bazę, a nie informacje same w sobie, co moim zdaniem jest odzwierciedlone w art. 2 ust. 1 pkt 3 ustawy o ochronie baz danych: „wtórne wykorzystanie oznacza publiczne udostępnienie bazy danych w dowolnej formie, a w szczególności poprzez rozpowszechnianie, bezpośrednie przekazywanie lub najem, z zastrzeżeniem art. 3”.
Ale ponownie, to tylko moje rozumienie tego przepisu, zresztą nie wszystkie bazy podlegają ochronie (jej sporządzenie lub prezentacja musiały wymagać istotnego nakładu, nie wiem jak to było z NP). Msz2001 (dyskusja) 21:46, 27 lut 2024 (CET)[odpowiedz]
Właśnie układ informacji i interfejs mogą być chronione prawem autorskim twórców oprogramowania prezentującego te dane. Prawo o ochronie baz danych dotyczy stricte bazy danych jako zbioru informacji (ale nie pojedynczych informacji w niej zawartych). Msz2001 (dyskusja) 21:48, 27 lut 2024 (CET)[odpowiedz]
@Msz2001, @Cybularny, @Powerek38, @Wargo Odgrzewam sprawę korzystania z kopii bazy danych. Czy jeżeli sama baza nie będzie dostępna do przeszukiwania, a jedynie pozwoli na wyciągnięcie informacji na podstawie identyfikatora, to czy byłoby to rozwiązanie ewentualnego problemu prawnego z korzystaniem z kopii? Nie można by dodawać wywołań dla nowych osób, ale przywróciłoby to do życia istniejące szablony {{Ludzie nauki}}. Gdarin, Aegis MaelstromLantuszka, Natalia Ćwik: czy WMPL mogłaby to skonsultować z prawnikami? Michał Sobkowskidyskusja17:02, 14 mar 2024 (CET)[odpowiedz]
Czysto technicznie my jesteśmy w stanie dalej dodawać informacje z Nauki Polskiej do projektów, zwłaszcza do Wikidanych, bo oprócz pliku Kpjasa mamy też całkiem dobrego scrapera (tak to się nazywa mądrze?), wykonanego przez koleżankę Czupirek i wrzuconego na Mix'n'Match. Tylko że edytując w ten sposób, de facto fałszowalibyśmy przypisy, no bo musielibyśmy podawać je do podstron bazy, które publicznie już nie istnieją. Oczywiście niby można to obejść (dając w przypisie wsteczną datę dostępu), ale nie jestem pewien, czy chcemy tak omijać własne zasady. Powerek38 (dyskusja) 21:25, 27 lut 2024 (CET)[odpowiedz]
I jeszcze w kwestii zaangażowania WMPL, o której część z Was pisała powyżej: otrzymałem informację, że @Natalia Ćwik (WMPL) napisała dzisiaj do OPI-PIB, czyli administatora obu baz (starej i nowej). Oczywiście nie wiemy, czy to da jakiś efekt, ale bardzo dziękuję Natalii za pomoc! Powerek38 (dyskusja) 09:24, 28 lut 2024 (CET)[odpowiedz]
Rozczarowujący jest brak tożsamości identyfikatora lub jasnego klucza migracji. Jeśli nie uda się uzyskać stary-nowy, to no cóż... Pozostanie nam na potrzeby Wikipedii przygotowywać ręcznie arkusze kalkulacyjne do podmian i podrzucać operatorom botów... Elfhelm (dyskusja) 19:59, 28 lut 2024 (CET)[odpowiedz]
I don't speak polish so hopefully you can read this through translation (I read some of this discussion through translation). This doesn't really concern wikidata as the links appear to have some archival coverage and we don't like deleting valid identifiers there (even if the source website is gone). If they issue a new identifier (as some of you indicate) we can make a new wikidata property and migrate over. BrokenSegue (dyskusja) 17:48, 28 lut 2024 (CET)[odpowiedz]
Tak, to jest niestety mój błąd przy tworzeniu propozycji właściwości, wynikający z niedostatków wiedzy informatycznej. Osoba tworząca właściwość zrobiła 1:1 to, o co wnioskowałem, nie zwracając uwagi na ten techniczny, ale ważny błąd. Powerek38 (dyskusja) 10:55, 13 mar 2024 (CET)[odpowiedz]
@Powerek38 nie za bardzo wiem jakbym mógł pomóc. Nie działam mocno w obszarze tworzenia czy modyfikowania przestrzeni nazw property. Czy to jest kwestia uprawnień, których Ty nie posiadasz? Rzuwig►15:37, 13 mar 2024 (CET)[odpowiedz]
@Rzuwig Tu są dwie kwestie. Po pierwsze, jakoś trzeba usunąć / zamknąć / wyłączyć P12540 jako utworzoną w wyniku oczywistego błędu, żeby ludzie nie dodawali kolejnych jej wartości. Po drugie, należy stworzyć nową właściwość dokładnie taką sama jak tamta, z wyjątkiem data type - musi być tak, jak Michał napisał wyżej. Ja zdecydowanie nie mam uprawnień do żadnej z tych czynności, bo ani nie jestem adminem ani nie mam flagi property creator (i nie chcę mieć, bo jak pokazała ta sytuacja, robiłbym to źle). Powerek38 (dyskusja) 15:42, 13 mar 2024 (CET)[odpowiedz]
Jakiekolwiek działania teraz (administracyjne) nic nie poradzą, od strony technicznej zmiana typu danych była kiedyś wykonywana przez WMDE, ale tylko przez pewien czas i każda zmiana była poprzedzana dyskusją. Obecnie wygląda to tak, że tworzy się nową właściwość, starą zgłasza do usunięcia (d:Wikidata:Properties for deletion). Właściwości nie da się też „wyłączyć”, ew. można wpisać w opisie właściwości że jest deprecated due to wrong data type during creation lub coś podobnego. Wostr (dyskusja) 17:28, 13 mar 2024 (CET)[odpowiedz]
Tylko nie wiem czemu na WD mi się te stringi nie klikają (póki były stringami, a nie ext. id. się klikały). Tylko mi? Coś się musi z cache'ami property zadziać? purge mi nie pomógł. Piastuβy język giętki…21:21, 13 mar 2024 (CET)[odpowiedz]
Dzięki! Z mojego punktu widzenia byłoby super, gdyby ktoś umiał zaimportować tę nową bazę na Mix'n'Match, tak jak Czupirek zaimportowała kiedyś większość starej. Nie wiem, czy to się okaże technicznie wykonalne, ale to by znacznie przyśpieszyło dodawanie nowego identyfikatora na WD, a tym samym do naszego Moduł:Kontrola autorytatywna. Powerek38 (dyskusja) 16:07, 14 mar 2024 (CET)[odpowiedz]
Przestudiowałem powyższe dokładnie i ... nie wiem, co należy/można robić. Na razie we wszystkich biogramach polskich naukowców (i, jak widzę, chyba nie tylko moich) mam dopisane "martwy link". Czekać dalej ? Pozdrawiam - Henry39 (dyskusja) 23:44, 30 mar 2024 (CET)[odpowiedz]
Tylko jak ? Na razie link do Ludzie Nauki nie działa. Z tego, co udaje mi się otworzyć, to wynika, że cała ta rewolucja z nową bazą zaczęła się ... 15 grudnia. Pozdrawiam - Henry39 (dyskusja) 09:49, 31 mar 2024 (CEST)[odpowiedz]
Obawiam się, ze problem leży w tym, że "neo" portalu "Ludzie Nauki" nie można otworzyć w systemie operacyjnym macOS (którym się posługuję), a działa tylko przez Windows. Co gorsza, nie jestem w stanie nawet otworzyć gotowego identyfikatora zewnętrznego w podanym dla przykładu biogramie prof. Jaskierni. W materiałach "Ludzie Nauki" sami o tym piszą. Henry39 (dyskusja) 00:08, 1 kwi 2024 (CEST)[odpowiedz]
Nie wiem jak to wygląda na maku, ale to może być kwestia przeglądarki. Jest tam jakaś funkcja blokowania reklam, może rozszerzenie typu adblock? Revsson (dyskusja) 11:12, 1 kwi 2024 (CEST)[odpowiedz]
W obecnych czasach dość trudne jest przypadkowe zrobienie strony, które nie działa na jakimś popularnym systemie operacyjnym, lub przeglądarce (celowo to jasne, ale przypadkowo, to już wyjątkowa niefrasobliwość). To, o czym piszą, to że aplikacja SYNABA, która służy do aktualizowania danych w starym systemie, działa tylko na Windowsie (apkę pod konkretny system się akurat pisze, ale to nie strona www) – to nie ma nic wspólnego z nowym serwisem. Szukałbym jednak problemu lokalnie, lub potwierdzenia, że innym osobom z MacOS nie działa (i inf. dodatkowych, jak przeglądarka wersje systemu i przeglądarki – żeby od razu mieć dokładniejsze info problemie), bo jasne, to może się i tak zadziać, mimo, że trudne, Piastuβy język giętki…22:52, 1 kwi 2024 (CEST)[odpowiedz]
Trafnie piszesz, że wprowadzić ten cały bałagan "celowo to jasne, ale przypadkowo, to już wyjątkowa niefrasobliwość". Mógłbym zacząć zmieniać moje systemy operacyjne lub przeglądarki, ale po co. Moim pierwszym Apple był Apple//e w 1983 i mimo wszystkich zmian dalej lubię Apple.
Jak na razie, tak mi wyszło z ograniczonego sprawdzania, to "Ludzi Nauki" nie można otworzyć na iMacach i MacBookach w macOS 10.13.6. Na tychże z macOS 12.7.4 można, ale i w tym ostatnim są niewielkie kłopoty. Natomiast iOS 17.4.1, czyli na iPhonie, można. Tutaj działa, co już zauważono.
Sprawa jest chyba unikalna i wysoce dziwna. Poprzedni "Ludzie nauki" byli przecież całkowicie wystarczający i wypróbowani. A, jak na razie, to niemal wszystkie biogramy naukowców zawierają oznaczenie "martwy link". Przecież większość tych naukowców nigdy nie zajmie się wprowadzaniem swoich danych do neo-systemu. Po co ta cała rewolucja? - Pozdrawiam - Henry39 (dyskusja) 13:28, 2 kwi 2024 (CEST)[odpowiedz]
Na WD id do nowych Ludzi… na już ponad 540 osób. Z tego ponad 270 jest opisanych na plWiki. (Wobec 46k odwołań w WD do starej bazy, z których 18k ma biogramy w plWiki – to kropelka.) Oni mają już link do nowej bazy w szablonie {{Kontrola autorytatywna}}. Można uzupełnić WD, a stary szablon usunąć botem :) (albo, gdy WD będą uzupełnione, zastąpić na ich podstawie stary nowym). Piastuβy język giętki…15:01, 2 kwi 2024 (CEST)[odpowiedz]
Na razie pomysł usuwania przypisów do dawnych Ludzi jest zdecydowanie niewłaściwy, bo nowy serwis jest mocno okrojony w stosunku do dawnego, więc nie da się nim uźródłowić prawie nic z dotychczasowych informacji. To jest tragedia! Michał Sobkowskidyskusja16:05, 2 kwi 2024 (CEST)[odpowiedz]
Zgadzam się Michałem Sobkowskim. Dla mnie szczególnie przykra jest nieobecność w nowym serwisie tytułów prac doktorskich i habilitacyjnych, bo wiele razy uźródławiałem te tytuły przypisami, a teraz jest "martwy link". Usunięcie szablonu "martwy link" z haseł sprawiłoby, że te tytuły brałyby się w hasłach z powietrza i kwalifikowałyby się do opatrzenia szablonem "fakt" (co chyba byłoby jeszcze gorsze). Moim zdaniem zaletą nowego serwisu jest jasne podanie specjalności naukowych w przypadku doktoratu i habilitacji, ściśle podawane są też okresy zatrudnienia. Może tytuły prac wrócą kiedyś wraz postępami migracji danych? Laked98 (dyskusja) 16:50, 2 kwi 2024 (CEST)[odpowiedz]
doktoraty habilitacje można by uźródławiać RADON-em, np. Andrzej Dziembowski, ale problem w tym, że jak ktoś przestanie być naukowcem/nauczycielem akademickim, albo umrze - jego dane znikają z RADON-u. Co równa się martwemu linkowi ponownie.
Dodatkowe zagadnienie to że naukowcy zmarli mieli swoje miejsce w Nauce Polskiej, ale o ile mi wiadomo nie ma ich Ludziach Nauki, a także nie wiem czy po śmierci nie będą usuwani z Ludzi Nauki ? Zmarłej 4.2.2024 prof. Krystyny Sancewicz-Pach nie ma w Ludziach Nauki. Kpjas (∵ ✍) 20:59, 2 kwi 2024 (CEST)[odpowiedz]
No ale to samo (stopnie i tytuły) jest przecież w nowych LN. Tylko są to wszystko jedynie nędzne ogryzki dawnych danych. Brak dat dziennych, brak jednostek, które naprawdę nadały stopnie (przecież nadawały je rady wydziałów, a nie uczelnie), brak tytułów dysertacji, brak promotorów i recenzentów. Brak wszystkiego. Michał Sobkowskidyskusja22:36, 2 kwi 2024 (CEST)[odpowiedz]
Adres p. Krzysztofa Wilińskiego widnieje jako kontakt na stronie OPI, więc napisałem. Korespondencję podaję w całości, skąd widać, że najklasyczniejsza z klasycznych przeglądarka Google niestety jest niewłaściwa. - Co za czasy! Henry39 (dyskusja) 23:15, 2 kwi 2024 (CEST)[odpowiedz]
---------- Forwarded message ---------
From: Krzysztof Wiliński <Krzysztof.Wilinski@opi.org.pl>
Date: Tue, Apr 2, 2024 at 8:42 AM
Subject: RE: :udzie Nauki, tylko w Windows?
To: hnery39 <hnery39@gmail.com>
Witam serdecznie,
Dziękuję za wiadomość.
Co do zasady do obsługi Ludzi Nauki powinna wystarczyć najnowsza wersja przeglądarki Chrome, Firefox lub Edge.
Konieczne może być także włączenia obsługi cookies (ciasteczek), Session Starage, Local Storage oraz włączenia obsługi JavaScript w przeglądarce.
Uprzejmie proszę o kontakt w przypadku pojawienia się dodatkowych pytań lub wątpliwości.
Pozdrawiam serdecznie,
Krzysztof Wiliński
-
From: hnery39 <hnery39@gmail.com>
Sent: Monday, April 1, 2024 12:28 AM
To: Krzysztof Wiliński <Krzysztof.Wilinski@opi.org.pl>
Subject: Ludzie Nauki, tylko w Windows?
Szanowny Panie,
Czy dostęp do nowej bazy Ludzie Nauki jest tylko dla posługujących się systemem Windows? A macOS? - Co robić?
@Nux Zamierzam więc spróbować Chrome. Ale w przeglądarce Safari nie mogę otworzyć strony https://ludzie.nauka.gov.pl/ln . Czy to się dzieje z powodu starego systemu operacyjnego na moim iMacu? Wyszukiwarki Google używam do wyszukiwania wpisując hasło. Pewnie to trywialne, ale wolę zapytać. Dziękuję i pozdrawiam - Henry39 (dyskusja) 09:56, 3 kwi 2024 (CEST)[odpowiedz]
@Henry39 Serdeczne dzięki w imieniu Wikimedia Polska za odkrycie kontaktu w osobie Pana Krzysztofa i przetestowanie, że odpowiada na wiadomości. Wcześniejsza wiadomość wysłana przez Natalię (dyrektorkę generalną WMPL) na ogólny adres OPI, w sprawie problemów, jakich przysporzyła nam zmiana Nauki Polskiej w Ludzi Nauki, pozostała bez odpowiedzi. Dziś poprosiłem Natalię, a ona uprzejmie już to zrobiła, o ponowne wysłanie tego maila właśnie do Pana Krzysztofa. Powerek38 (dyskusja) 11:31, 3 kwi 2024 (CEST)[odpowiedz]
To bardzo miłe, że tak piszesz. W jedności siła! A na marginesie, bardziej osobiście, to zawsze byłem zafascynowany brytyjskim prawem wyborczym, a szczególnie w wydaniu australijskim. - Serdecznie pozdrawiam - Henry39 (dyskusja) 15:44, 3 kwi 2024 (CEST)[odpowiedz]
Przyłączam się do podziękowań dla @Henry39 - kiedy przekierowałam naszą wiadomość do p. Krzysztofa nadeszła odpowiedź: "Państwa zlecenie zostało skierowane do analizy i realizacji. Uprzejmie informuję, że dane naukowców są sukcesywnie przenoszone z portalu Nauka Polska do Ludzi Nauki, dlatego chcemy zaproponować Państwu cykliczne przekazywanie raportów zawierających identyfikatory profili z Nauki Polskiej z odpowiednikami po stronie Ludzi Nauki. Tryb przekazywania danych oraz szczegółową zawartość raportów proponuję uzgodnić mailowo lub na spotkaniu roboczym." Może ustalimy wspólnie jak takie raporty miałyby wyglądać? Czy ktoś z tutaj dyskutujących chciałby wspólnie ze mną i @Powerek38 utworzyć grupę roboczą do omówienia szerszej współpracy z OPI? Natalia Ćwik (WMPL) (dyskusja) 11:17, 4 kwi 2024 (CEST)[odpowiedz]
Chętny! Co do formatu danych to wystarczający byłby raport zawierający dwie kolumny: identyfikator w NP - identyfikator w LN. Najlepiej zawsze cały a nie tylko przyrost (dodane), bo przegapienie jednej części nie powodowałoby problemu. Natomiast dużo lepszym rozwiązaniem byłoby gdyby przygotowali jakiś link, np. https://ludzie.nauka.gov.pl/nauka_polska_redirect/1234567, gdzie po wstawieniu starego identyfikatora zamiast 1234567 następowałoby przekierowanie pod nowy adres. Wtedy można by wiele rzeczy załatwiać automatycznie dla wszystkich potrzeb. Jakby dali coś podobnego dostępnego po zalogowaniu dla wybranych osób to też by było dobre. Natomiast najlepsze by było przygotowanie interfejsu do odczytu maszynowego. Korzystam z podobnego rozwiązania do bazy zagrożonych gatunków (https://apiv3.iucnredlist.org/) - napisałem do nich prośbę z uzasadnieniem, że potrzebuję do weryfikacji danych na polskojęzycznej Wikipedii i dostałem dostęp bez problemów. IUCN udostępnia tam też wyszukiwarkę przystosowaną do wyszukiwania maszynowego (przez program), dzięki czemu łatwo zlokalizować wpis po nazwie łacińskiej i paru innych warunkach bez drakońskich ograniczeń obecnych w wyszukiwarce www (typu maks 30 zapytań na godzinę). W bazie LN też by się coś podobnego przydało. Link do API podałem bo tam jest dokumentacja, która umożliwia zapoznanie się z możliwościami tego narzędzia. Może zaloguję się wieczorem na spotkaniu on-line - w razie potrzeby wyjaśnię na jakiś przykładach. ~malarz plPISZ17:34, 4 kwi 2024 (CEST)[odpowiedz]
Pamiętajmy tylko, że dopóki nie nastąpi przeniesienie pełnego zakresu danych z NP do LN, nie można zastąpić {{Ludzie nauki}} przez {{Ludzie Nauki}}, nawet jeśli będziemy mieć możliwość zrobienia tego maszynowo. Można co najwyżej w {{Ludzie nauki}} wyświetlać poradę, aby zajrzeć do rekordu w LN, z linkiem do nowego ID. Jest jeszcze pytanie, co z {{Instytucje naukowe}} i {{Prace badawcze}}? W tej chwili nie widać żadnego zamiennika w OPI. Linki dla instytucji w LN prowadzą do RADON-u (gdzie brak jest linków zwrotnych do LN), a o pracach nie wiadomo chyba nic. Michał Sobkowskidyskusja20:47, 4 kwi 2024 (CEST)[odpowiedz]
@Michał Sobkowski @Malarz pl RADON udostępnia wiele danych poprzez API/REST API na zasadzie opendata:
Kpjas: OK, na pewno można utworzyć ID naukowca w RADON-ie w Wikidanych. Czemu nie, jestem za. Dla Pawła Ceranki jest przynajmniej data dzienna i recenzenci doktoratu (choć niepodlinkowani), ale i tak dane są mocno okrojone – nie podano wydziału/rady dyscypliny, nie podano promotora. Żeby poznać tytuł rozprawy trzeba ją sobie ściągnąć! Dla mnóstwa innych osób jest znacznie gorzej, nie ma prawie nic. Zob. np. Annę Urbanowicz – w RADON-ie tragedia informacyjna. I to jest norma w RADON-ie, a nie jakiś wyjątek. Chodzi o to, aby odzyskać pełne dane z NP, a RADON daje jedynie ułamek dawnych informacji. Michał Sobkowskidyskusja22:14, 5 kwi 2024 (CEST)[odpowiedz]
Faktycznie, znowu działa! Dobra wiadomość! Żadnej informacji na ten temat nie znalazłem. Podejrzewam, że wdrożenie pełnej funkcjonalności nowego serwisu okazało się na tyle trudne, że postanowili przywrócić stary. Ale pewnie tymczasowo. W każdym razie przywróciłem dawnych „Ludzi Nauki” w Moduł:Kontrola autorytatywna. Zobaczymy, co się będzie działo. Michał Sobkowskidyskusja09:32, 1 maj 2024 (CEST)[odpowiedz]
Ptjackyll: wobec niepewności sytuacji byłoby to bardzo pożądane. Masowa archiwizacja trzech serwisów Nauki Polskiej: Ludzie nauki, Instytucje, Prace badawcze. A w razie kolejnego wyłączenia serwisu, przebotowanie na wersja archiwalne. Tylko czy WayBack Machine pozwoli na takie działanie? Michał Sobkowskidyskusja11:03, 1 maj 2024 (CEST)[odpowiedz]
Niestety nie wiem. Ale też pytanie do osób zajmujących się technikaliami: czy potrafilibyście zrobić to jakoś automatycznie lub choćby półautomatycznie? Czy koniecznie byłoby archiwizowanie ręczne? ptjackyll (zostaw wiadomość) 11:27, 1 maj 2024 (CEST)[odpowiedz]
Ktoś to jakiś czas temu robił. Ja bym przy okazji sugerował od razu po generowaniu archiwum, wstawianie parametru archiwum do szablonu. Bedzie to chyba łatwiejsze niż późniejsze odtwarzanie tego działania. ~malarz plPISZ12:34, 1 maj 2024 (CEST)[odpowiedz]
BTW na archive.org (Wayback Machine) strony z domeny nauka-polska.pl były od 2003 roku archiwizowane 27,222 razy.
Jest API do sprawdzania, które strony są zarchiwizowano tj. Wayback Availability JSON API
Może takie rozwiązania dla masowego archiwizowania ?
setup a local GrabSite (https://github.com/ArchiveTeam/grab-site) instance on a device you control, then make a URL list and feed that to grab-site. then ask some archive-team archivists to add it to archive.org so wayback machine sees that
Odnośnie archiwizacji, to po pierwsze można byłoby spytać operatorów User:InternetArchiveBot, oni pewnie mają lepsze dojścia oraz narzędzia do masowej archiwizacji. Jednak, wygląda na to, że Internet Archive nie współpracuje dobrze z Nauką Polską. Przykład, hasło: Witold Kulesza, id: 57379, link do nauki-polskiej: link. Spróbowałem to zarchiwizować i w rezultacie mamy komunikat: Maintenance break, the service will be back soon (link do web.archive.org). Archive.is daje sobie z tym jednak radę (link do archive.is). Patrzyłem na kilka innych linków i wygląda to podobnie ;/ Pozdrawiam, tufor (dyskusja) 20:26, 1 maj 2024 (CEST)[odpowiedz]
Tak, niestety webarchive często źle radzi sobie z dynamicznymi witrynami (tak jak by nie wszystko zapisuje). Archive.today/is w najgorszym razie ma jeszcze dostępny zrzut ekranu, który zazwyczaj wygląda dobrze (o ile nie ma paywall, ale z NP nie ma tego problemu). Nux (dyskusja) 22:27, 1 maj 2024 (CEST)[odpowiedz]
No chociaż to co wrzucił wyżej tufor działa prof. Kazimierz Ślaski również jest OK. W sumie dziwne, że na zrzucie jest info z ciasteczkami, a htmlowy snapshot jest OK i jest rozwinięty... Ale w sumie ważne, że działa i ładuje się o niebo szybciej niż webarchive.
To jest mega dziwne. Teraz jestem na smartphonie (Firefox mobilny), i jak otwieram podany przez siebie link w trybie prywatnym to wszystko wyświetla się prawidłowo, natomiast w trybie normalnym nadal wyskakuje mi błąd (z tym, że w języku polskim). Link podany niżej przez Michała wyświetla się prawidłowo w obu trybach. Czyli chyba wszystko się poprawnie archiwizuje, tylko jakiś plik JS steruje tym, co i jak jest wyświetlane dla różnych osób/ustawień. JSON z którego pobierane są dane też jest archiwizowany link. Hmmm... tufor (dyskusja) 04:26, 2 maj 2024 (CEST)[odpowiedz]
Poprosiłam @Ada Jakubowska (WMPL) o włączenie się w temat. Potrzebujemy się z Wami spotkać i dopytać o kwestie techniczne - nie wszystko co tutaj piszecie jest dla nas jasne a bardzo chcemy pomóc w rozwiązaniu sprawy i omówić z OPI jakieś długofalowe rozwiązania/współpracę. @Ada Jakubowska (WMPL) postara się ustalić z Wami termin spotkania online. Wtedy spiszemy wszystkie istotne wątki i zdecydujemy wspólnie w jakim składzie możemy iść na spotkanie (online czy offline) z OPI. Natalia Ćwik (WMPL) (dyskusja) 13:10, 8 maj 2024 (CEST)[odpowiedz]
Hej! Potwierdzam słowa @Natalia Ćwik (WMPL). Z tego, co udało mi się wyłapać w wątku, spotkaniem zainteresowani są: @Powerek38, @Kpjas, @Michał Sobkowski i @Malarz pl. Czy ktoś jeszcze chciałby zająć się tym tematem? Wstępnie proponuję spotkanie we wtorek (14.05) o 18:00. Czy wszystkim zainteresowanym ten termin pasuje? Jeśli chodzi o mnie, to w godzinach popołudniowych nie jestem dostępna tylko w środę i piątek. Ada Jakubowska (WMPL) (dyskusja) 13:19, 8 maj 2024 (CEST)[odpowiedz]
Ja mogę w tym terminie wpaść na 45 minut, bo potem mam już umówione inne zajęcia. Ale chyba taki czas będzie wystarczający, żeby przegadać najważniejsze rzeczy :) Powerek38 (dyskusja) 13:28, 8 maj 2024 (CEST)[odpowiedz]
Ja z kolei mogę mieć problem z początkiem. W razie czego włączę ok 18:10 w zestawie w samochodzie i najwyżej pod koniec aktywniej wzmę udział. Maj nie jest dla mnie najlepszym miesiącem na różne spotkania, bo mam dużo nieprzywidywalnych działań w pracy. ~malarz plPISZ14:08, 8 maj 2024 (CEST)[odpowiedz]
Co ciekawe, w odtworzonej Nauce Polskiej widzę aktualizacje profili w stosunku do wersji sprzed zniknięciem. Głowy nie dam, może stało się to jeszcze pod koniec 2023 r., ale może dopiero teraz. Np. 24.10.2023 nie było habilitacji Jacka Kolanowskiego (tego dnia mailowałem w tej sprawie, więc data jest pewna), a teraz jest. Michał Sobkowskidyskusja23:48, 1 maj 2024 (CEST)[odpowiedz]
Tak z innej beczki, ja nie wiem skąd to, ale dane w LN to chyba nie do końca są poprawne. Sprawdziłem kilka znajomych profili i tam po prostu są złe dane (nt. zatrudnienia, w tych konkretnycch przypadkach). Niby z Polonu, ale tam - zgodnei z informacją - wpisują je inni ludzie, no i się zaczyna. Jeden wpisał, inna baza danych łyknęła, kolejna powieliła. Masurjuhu?21:24, 18 maj 2024 (CEST)[odpowiedz]
Masur, zgadza się. Obecnie w LN jako „zatrudnienie” klasyfikowana jest np. umowa o dzieło, jak dajmy na to wygłoszenie wykładu. Jest to fundamentalny błąd. W moim rofilu w LN wygląda to tak, jakbym od kilku lat co roku był zatrudniany i zwalniany (dyscyplinarnie?) z PP. :-) Podczas spotkania on-line (powyżej) zwróciłem na to uwagę, i ma to zostać przekazane do OPI. Michał Sobkowskidyskusja12:44, 19 maj 2024 (CEST)[odpowiedz]
O toto. + dziury. Pamiętam, że swój proil na Polonie, radonie czy jak temu było, miałem może nie super aktualny, ale do pewnej daty kompletny. Teraz masy rzeczy nie ma. Masurjuhu?22:27, 19 maj 2024 (CEST)[odpowiedz]
Wklejam informację, którą WMPL otrzymało wczoraj od OPI co do powrotu "starej" Nauki Polskiej: Serwis Nauka Polska został podniesiony. Z wewnętrznych ustaleń wynika, że powinien funkcjonować do czasu, gdy zostaną udostępnione ekwiwalentne funkcjonalności w serwisie Ludzie Nauki. Nadmienię przy okazji, że wygląda na to, iż na początku czerwca odbędzie się spotkanie przedstawiciela OPI z przedstawicielkami i przedtawicielami WMPL i naszej społeczności, wyłonionymi podczas narady on-line, na którą Ada i Natka zapraszały wyżej. Powerek38 (dyskusja) 10:57, 28 maj 2024 (CEST)[odpowiedz]
W ostatni piątek odbyło się online spotkanie wspominanego wyżej Pana Krzysztofa z OPI z delegacją WMPL i społeczności w składzie: Natka, Ada, Kasia (świeżo zatrudniona w WMPL menedżerka ds. otwartej nauki) oraz Nux i ja. Spotkanie miało charakter zapoznawczo-roboczy, przebiegało w bardzo szczerej, otwartej i konstruktywnej atmosferze. Myślę, że publiczne relacjonowanie wszystkich jego szczegółów nie jest w tym momencie dobrym pomysłem, ale mówiąc dość oględnie, na pewno istnieje przestrzeń do współpracy z OPI, przy czym dużo jest tu do ogarnięcia kwestii prawnych i organizacyjnych, gdyż jest to instytucja państwowa, działająca ściśle w oparciu o istniejące przepisy. Odpowiednie osoby i organy w WMPL będą w najbliższych tygodniach i miesiącach pracować nad tym, żeby mogło się to udać w sensowny sposób. Zupełnie wprost i otwarcie mogę natomiast napisać dwie rzeczy, których dowiedzieliśmy się o samych bazach. Po pierwsze, OPI nie gwarantuje żadnej daty, do kiedy "stara" Nauka Polska będzie publicznie dostępna, także cóż, śpieszmy się edytować :) Po drugie, trwa intensywna migracja do "nowych" Ludzi Nauki, ale już wiadomo, że ze względów prawnych nie będzie to migracja pełna, przede wszystkim najprawdopodobniej docelowa wersja Ludzi Nauki nie będzie zawierać danych o nieżyjących już naukowcach. Powerek38 (dyskusja) 14:02, 10 cze 2024 (CEST)[odpowiedz]
@Gdarin Generalnie wszystkie kwestie prawne, o których Pan Krzysztof nam opowiadał, biorą się z prawa ochrony danych osobowych lub/i z ustawy "prawo o szkolnictwie wyższym i nauce". Myślę, że m.in. tu jest pole dla WMPL, żeby te przepisy przeanalizować i wspólnie poszukać rozwiązań, które będą ok dla obu stron. Znowu, jako szeregowy wolontariusz nie chciałbym wychodzić przed szereg i opowiadać publicznie zbyt szczegółowo, zresztą chcę też uszanować szczerość i otwartość naszego rozmówcy. Ty oczywiście jako prezes WMPL możesz, wraz z innymi osobami z władz, swobodnie decydować, w jakim zakresie będziecie publikować informacje o przebiegu dalszych rozmów, ale ja wolę na zupełnie publicznym forum, jakim jest Kawiarenka, powiedzieć za mało niż za dużo. Powerek38 (dyskusja) 17:03, 10 cze 2024 (CEST)[odpowiedz]
@Gdarin, @Powerek38 Bardzo polecam się w tym temacie. Jeśli chodzi o analizę przepisów oraz w szczególności proces wpływu na nie, zachęcam do kontaktu. Jako Wikimedia Europe prowadzimy obecnie kilka procesów w kraju, fajnie byłoby to mieć skoordynowane, w celu osiągnięcia lepszych wyników i posiadania jednego "frontu". Nadzik (dyskusja) 18:07, 10 cze 2024 (CEST)[odpowiedz]
Dane osoby po jej śmierci przestają być danymi osobowymi w rozumieniu RODO/UoODO [3]. Wyrzucanie takich danych z bazy to zbrodnia na pamięci. Niestety inaczej ma się sprawa z żyjącamu emerytami, którzy nie zawsze muszą się zgodzić (albo ciężko może być do nich dotrzeć aby się zgodzili). ~malarz plPISZ19:06, 10 cze 2024 (CEST)[odpowiedz]
To ja może tylko w uzupełnieniu dodam (znowu, nie ujawniając za dużo zbędnych szczegółów), że Ludzie Nauki (LN) nie będą najprawdopodobniej zawierać nic więcej niż zawiera/będzie zawierać ustawa o szkolnictwie. To jest praktyczna konsekwencja tego o czym pisał już Powerek - OPI działa ściśle w ramach ustawy. Może Nadzik coś tam wypatrzy w ustawie, albo uda się tam coś rozszerzyć, ale póki co wygląda na to, że m.in. również rodzaj zatrudnienia nie pojawi się w nowym serwisie. To znaczy w ustawie nie ma konieczności zbierania rodzaju zatrudnienia w Pol-onie, a Pol-on jest źródłem dla LN. Co nam będzie komplikować kwestię uźródławiania zatrudnienia poprzez LN (rozróżniania umowy o dzieło od zatrudnienia na stałe). Nux (dyskusja) 20:59, 10 cze 2024 (CEST)[odpowiedz]
Ogólnie wygląda to słabo. :-( Czy rozmawialiście o możliwości archiwizacji starych LN i wykorzystywania takich danych archiwalnych w Wiki? Gdyby OPI dało na to zgodę, póki dane są dostępne publicznie, to byłoby nieźle. Ewentualnie archiwizacja w web.archive.org - czy WMPL podjęła jakieś działania w tym kierunku? Póki LN działają i jest co archiwizować? A jeśli nie web.archive.org, to może archive.ph? Co z innymi serwisami Nauki Polskiej – instytucje i prace badawcze? Pójdą do piachu? :-( Co do POL-onu i form zatrudnienia, to niestety nie mam uprawnień, żeby to zobaczyć, ale czy rzeczywiście w POL-onie osoba na etacie i realizująca umowę o dzieło to to samo? Jeśli tak, to miejsce poniżej pleców blade, ale jeśli nie, to może OPI jakoć to rozfiltruje? Michał Sobkowskidyskusja22:00, 10 cze 2024 (CEST)[odpowiedz]
W moim odczuciu podstawowy problem jest taki, że OPI uważa pracę na tych danych za przetwarzanie danych osobowych. Czy to jest prawidłowa interpretacja przepisów, nie podejmuję się oceniać. W każdym razie jest tutaj silne oczekiwanie, żebyśmy w jakimś dialogu z Ministerstwem Nauki uregulowali właśnie tę kwestię - naszego (ale znowu - naszego, czyli czyjego formalnie?) dostępu do administrowanej przez ministerstwo bazy danych osobowych. OPI jest potem gotowe technicznie mocno nam wyjść naprzeciw, ale póki co to jest zasadniczy problem natury formalnej. Powerek38 (dyskusja) 22:43, 10 cze 2024 (CEST)[odpowiedz]
Myślę, że problem polega na tym, że to co jest publicznie widoczne, to nie jest wszystko co jest w tej bazie. W samej bazie starego serwisu są również dane prywatne – w tym adres zamieszkania i inne dane kontaktowe. Na razie nie traciłbym jeszcze nadziei na jakiś backup, ale niemal na pewno nie ma co liczyć na backup od OPI, ani tym bardziej od ministerstwa... Przypominam, że nadal czekamy na ustawę o fladze Polski z podaniem oficjalnych kolorów RGB. Ma być już lada dzień, ale na pewno przed Obchody 100-lecia odzyskania niepodległości przez Polskę ;]... Nux (dyskusja) 22:57, 10 cze 2024 (CEST)[odpowiedz]
Może dodam na wszelki wypadek, że powyższe to co napisałem to jest moja wiedza z innych źródeł. Nie jest to oficjalne stanowisko OPI. Po prostu moim zdaniem akurat tego tematu nie ma sensu ciągnąć, bo w naszych warunkach nie jesteśmy w stanie skutecznie, zgodnie z prawem odebrać tych danych po prostu (pełnych danych). Nux (dyskusja) 23:03, 10 cze 2024 (CEST)[odpowiedz]
Nie jest to wielki problem, no ale... :) Czasami sprawdzam OZ na telefonie (Opera, Android, OPPO) i gdy przechodzę na jaką stronę i potem wracam, wyświetla mi się OZ nawet sprzed kilku godzin. Jak odświeżę (automatyczna odświeżarka OZ), wraca wersja bieżąca. Nie jestem zalogowany, gdy to się dzieje. Na innych wiki (WMPL) czasami mnie wracało o parę tygodni:D Hedger z Castleton (dyskusja) 13:07, 4 kwi 2024 (CEST)[odpowiedz]
Problem widzę też na desktopie jak wyłączę stary tryb przeglądania OZ i przejdę do ustawień defaultowych. Na Wikipedii mam lag jednodniowy przed odświeżeniem - po włączeniu komputera. @Nux, @Msz2001, pingam, bo zaraz mnie bot zarchiwizuje :) Hedger z Castleton (dyskusja) 13:14, 8 maj 2024 (CEST)[odpowiedz]
Opera miała kiedyś agresywne cachowanie, może nadal mają (mimo przejęcia firmy Opery). Możesz w nowych tabach otwierać pewnie na wszelki wypadek. Albo zmienić na Firefoksa, który powinien być teraz lżejszy niż Opera (zwłaszcza FF z włączonym addonem uBlock). Nux (dyskusja) 14:29, 8 maj 2024 (CEST)[odpowiedz]
W jaki sposób wchodzisz na OZ? Z jakiej wersji OZ korzystasz po zalogowaniu i czy tez jest ten problem? Jaki adres URL masz, gdy wejdziesz świeżo i jest ten błąd? Wargo (dyskusja) 11:09, 13 maj 2024 (CEST)[odpowiedz]
@Wargo w przypadku wersji defaultowej OZ, zarówno jako niezalogowany na telefonie, jak i po zalogowaniu na dekstopie. hidebots, hidecategorization, hideWikibase, urlversion=2 Na wiki WMPL zamiast hideWikibase i hidecategorization mam translation=filter&categorizazion. Hedger z Castleton (dyskusja) 15:09, 22 maj 2024 (CEST)[odpowiedz]
Menu "Wygląd" będzie dostępne dla niezalogowanych użytkowników[edytuj | edytuj kod]
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]
Drzewo składniowe filtra z wartościami, (link do logu)
Jakby ktoś potrzebował takiego narzędzia, to przygotowałem analizator trafień filtra nadużyć, który wskazuje wartości we wszystkich węzłach w środku drzewa, dzięki czemu np. łatwiej poszukać, który z 30 regeksów się dopasował do edycji i spowodował false positive. Narzędzie jest cały czas w trakcie rozwoju, co widać po issuesach na GitHubie, ale swoją podstawową funkcję myślę że spełnia.
Ze znanych ograniczeń, to wpisy w logu są porównywane z aktualną treścią filtra (nie tą z momentu trafienia), nie są też obsługiwane funkcje z rodziny ccnorm. Całe parsowanie i ewaluacja odbywa się w przeglądarce (jest to oryginalny parser przepisany na JS, ale potencjalnie coś może działać inaczej – choć oryginalne testy przechodzą na zielono). Podobnie, muszę tłumaczyć regeksy ze składni w filtrze nadużyć (PCRE) na te z JS, co też otwiera pole do pewnych niezgodności w ewaluacji (acz nie powinny być duże).
Dołączyć skrypt można, dopisując importScript('Wikipedysta:Msz2001/abusefilter-analyzer-primer.js'); do common.js. Skrypt jest dość duży (ok. 200 kB), ale wczytuje się tylko w rejestrze nadużyć. Problemów, pomysłów itp. chętnie wysłucham. Msz2001 (dyskusja) 10:05, 26 kwi 2024 (CEST)[odpowiedz]
Przeciekawe… Sama implementacja "silnika" filtrów w JS może się przydać do wielu rzeczy, niektóre filtry na przykład warto by sprawdzać na żywo w edytorze. Matma Rexdyskusja23:51, 8 maj 2024 (CEST)[odpowiedz]
Link DOI, który prowadzi do domeny na ArferMarket[edytuj | edytuj kod]
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]
Dzień dobry, W wersji mobilnej przestało mi działać filtrowanie stron obserwowanych. Zawsze widzę pełną listę zmian, niezależnie od wyboru opcji. Proszę o pomoc. Szelma W (dyskusja) 11:32, 5 maj 2024 (CEST)[odpowiedz]
Dzień dobry, czy u wszystkich Was działa filtrowanie obiektów obserwowanych w wersji mobilnej? Czy u kogoś jeszcze, oprócz mnie, nie działa lub nie działało kiedyś filtrowanie obiektów obserwowanych w wersji mobilnej? Proszę o pomoc. Szelma W (dyskusja) 12:13, 8 maj 2024 (CEST)[odpowiedz]
Próbowałem na Samsung Internet, Safari, Google Chrome i Microsoft Edge. Filtrowanie nie działa. Jeszcze dwa tygodnie temu filtrowanie działało normalnie. Myślę, że to problem z moim profilem w Wikipedii, ale nie wiem gdzie szukać. Jakieś sugestie? Gdzie można przywrócić ustawienia domyślne? Szelma W (dyskusja) 20:50, 8 maj 2024 (CEST)[odpowiedz]
afrykaty /ʈʂ/ oraz /ɖʐ/ w szablonie IPA przesyłają na stronę poświęconą głosce bezdźwięcznej podniebiennej bocznej, /tɬ/, zamiast odpowiednio b'dźwięcznej i dźwięcznej retrofleksyjnej 31.182.254.117 (dyskusja) 00:24, 9 maj 2024 (CEST)[odpowiedz]
Mamy takie coś, dzięki czemu można się bawić małym wysiłkiem i ulepszać Wikipedię. Często jednak sugestie są "od czapy", z innej dziedziny. Czy można zabezpieczyć się jakoś, żeby na przykład Wabik (termin z myślistwa) nie pokazywał się jako sugestia przy torpedach, okrętach i rakietach/samolotach? One używają zupełnie innych urządzeń, też zwanych wabikami. Może jakieś inne reguły dałoby się wprowadzać, żeby nie sugerowało szerokość całkowita poza podkategoriami żeglugi? Ciacho5 (dyskusja) 23:03, 10 maj 2024 (CEST)[odpowiedz]
W zasadzie nie bez powodu są to sugestie, to znaczy świeżynki powinny sprawdzić czy dany link jest dobry, a złe sugestie odrzucać. Skuteczność algorytmu sugestii jest na poziomie 75% [4]. Jak chcesz to możesz zasugerować jakieś zmiany tam w dyskusji. Jest tam też publikacja naukowa z badań tej funkcji. Nux (dyskusja) 04:23, 11 maj 2024 (CEST)[odpowiedz]
Nieprawidłowe wyświetlanie symboli IPA w pop-upie nawigacyjnym[edytuj | edytuj kod]
Tak, to niestety normalne. Szablony w większości są wycinane z podglądu. Nie tylko w nowym podglądzie tak jest, ale również w Wikipedia:Narzędzia/Navigation popups (technicznie metoda jest inna, ale efekt podobny). Ten sam efekt, choć mniej widoczny jest w artykułach typu Iga Świątek, gdzie znika samo nazwisko z treści (choć nie jest źle, bo widać je w tytule okna i tak). Nux (dyskusja) 16:32, 11 maj 2024 (CEST)[odpowiedz]
Szablon {{IPA}} się nie wyświetla. Jednak, jeśli umieści się go w nawiasie, który też się nie wyświetla, przed datą urodzenia, to jest w porządku. Dla porównania:
Barack Obama – wyświetla się prawidłowo, kod: ''Barack Hussein Obama II''' (wym. {{IPA|/bəˈrɑ:k hu:ˈseɪn oʊˈbɑ:mə/|En-us-Barack-Hussein-Obama.ogg}}, ur. [[4 sierpnia]] [[1961]] w [[Honolulu]]
Donald Trump – wyświetla się dodatkowe „wym”, kod: '''Donald John Trump''', wym. {{IPA|/ˈdɒnəld dʒɒn trʌmp/|Donald John Trump.oga}} (ur. [[14 czerwca]] [[1946]] w [[Nowy Jork|Nowym Jorku]];
Joe Biden – wyświetla się dodatkowe „wym[]”, kod: '''Joe Biden''', właśc. '''Joseph Robinette Biden Jr.''', wym. [{{IPA|ˈʤoʊsɨf rɒbɨˈnɛt ˈbaɪdən}}] (ur. [[20 listopada]] [[1942]] w [[Scranton (Pensylwania)|Scranton]])
Czyli gdyby wymowę wrzucić do nawiasu, to chyba zostałoby to poprawione. Mamy kilkadziesiąt potencjalnie problematycznych artykułów: proste wyszukanie. Pytanie tylko, która wersja jest poprawna? Czy to nie ma większego znaczenia? @Beno. Pozdrawiam, tufor (dyskusja) 16:48, 11 maj 2024 (CEST)[odpowiedz]
U mnie się wszystko dobrze wyświetla wszędzie i na maku i na pc i na Androidzie, sprawdzałem zalogowany i nie w różnych przeglądarkach, więc nie wiem o co chodzi.Beno (dyskusja) 20:21, 11 maj 2024 (CEST)[odpowiedz]
Szablony są pomijane (częściowo dlatego, że nie chcemy mieć w podglądzie dużych szablonów typu disambig, czy dopracować, czy tym bardziej infoboks). Nux (dyskusja) 20:28, 11 maj 2024 (CEST)[odpowiedz]
Korzysttam z Navigation popups i też się zastanawiałem , czemu szablony są po prostu wycinane , gdy się najedzie na link do artykułu. XaxeLoled⸤ AmA ⸣21:23, 11 maj 2024 (CEST)[odpowiedz]
Patrzę z pewnym sentymentem na XHTML, jakieś dwa eony temu myślałem nawet, że XHTML, to przyszłość webu[5]... 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 [6]. Jakieś przeciwwskazania używania krótszej wersji br? Nux (dyskusja) 20:18, 15 maj 2024 (CEST)[odpowiedz]
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 plPISZ21:07, 15 maj 2024 (CEST)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
Ja się podepnę pod wątek bo problemy trochę pokrewne. W ramach czyszczenia błędów lintera dochodzimy powoli do ostatniej prostej, czyli "przestarzałych znaczników HTML". Większość błędów tej kategorii można poprawić botem (oczywiście o ile w artykułach nie ma innych błędów lintera). Zanim to zrobię chciałbym przedyskutować czy i na co zamieniać poszczególne znaczniki:
tt ==>> kbd
center ==>> div style=text-align:center
strike ==>> s
font ==>> span ...
Pozostałe chyba mają śladowe ilości, że nie warto się nad nimi zastanawiać. Największe wątpliwości mam do zamiany font w przestrzeni szablon. Wydaje mi się, że może warto przy okazji wyczyścić jakąś część tego zbędnego w wielu przypadkach formatowania tekstu. Czekam na opinie. Nie jestem w żaden sposób przywiązany do powyższych propozycji. A jak pisałem, prace na poważnie będzie można zacząć dopiero po posprzątaniu braków znacznika zamykającego. ~malarz plPISZ21:15, 16 maj 2024 (CEST)[odpowiedz]
Jeśli chcesz zmieniać wszędzie, to nie wiem czy z center → text-align:center to jest dobry pomysł. O ile w artykułach mam nadzieję, że nie ma to znaczenia, to jednak na stronach userów może być różnie. Tag center daje też wyśrodkowanie zwężonych elementów, nie tylko tekstu... Tak że wynik może nie być 1:1.
Osobiście od s wolę del. Aczkolwiek z jakiegoś powodu WMF zdecydowało się na s, no i może nie zawsze strike jest usunięciem, więc się nie upieram.
Natomiast tt zdecydowanie zmieniałbym na code. Myślę, że bardzo rzadko ktoś używał tt nie mając na myśli kodu i (może poza częścią pomocy) rzadko chodzi o klawiaturę. No i code akurat jest dostępny w edytorze (np. w narzędziach dyskusji). Nux (dyskusja) 22:00, 16 maj 2024 (CEST)[odpowiedz]
center jest często używany w tabelach, tam jednak najlepiej byłoby zamienić go na odpowiednie style komórki. Często występuje też w wywołaniach szablonów; z wywołań niektórych szablonów, typu {{Grafika rozwinięta}} można go kompletnie wywalić. Też zgodziłbym się na zamianę tt na code, chociaż są przypadki jak Choroba Jansky’ego-Bielschowsky’ego czy Pomnik Króla Jagiełły w Nowym Jorku, gdzie nie chodzi o kod komputerowy. Niemniej jakieś 99% przypadków będzie pasowało. Zamiana font na span style=... to chyba jedyna sensowna opcja, ale możesz mieć rację, że część formatowania można wywalić. tufor (dyskusja) 23:08, 16 maj 2024 (CEST)[odpowiedz]
OK. Dzięki za uwagi. Testowo puściłem bota tylko dla TT (zgodnie z sugestią na code) CENTER w przestrzeni kategoeii. Teraz uruchamiam dla main dla kilkuset artykułów, ale CENTER tylko tam, gdzie zaczyna się od początku wiersza (to powinno większość komórek w tabelach wykluczyć) oraz TT wszędzie. Co do centrowania, to czy można jakieś elementy wyśrodkować używając interfejsu VE. Mi się nie udało, ale może nie znalazłem pozycji w menu albo czegoś sobie nie włączyłem. ~malarz plPISZ17:44, 18 maj 2024 (CEST)[odpowiedz]
Co do regexpów w wyszukiwarce, to nie wyłapuje ona niestety znaków nowej linii, patrz mw:Help:CirrusSearch#Metacharacters. Niżej jest podana propozycja zastąpienia \n przez [^ -]; wcześniej z niej nie korzystałem, teraz spróbowałem i wygląda na to, że działa poprawnie ;) Co do wywalenia centerów okalających tabelę: wiadomo, że są one tylko tam, ponieważ autorzy myśleli, że umieszczenie tabel na środku strony wygląda estetyczniej niż po lewej. Wiem, że to będzie trudniejsze dla bota, ale może możnaby rozważyć dodanie styli typu margin: 0 auto do nagłówka tabeli, czy czegoś podobnego? Zobacz na przykład na kod Santander (miasto)#Klimat: tylko dolna tabelka jest otoczona centrami, szablon {{Średnia temperatura i opady}} sama z siebie jest wyśrodkowany. Usunięcie tylko centrów okalających drugą tabelkę powoduje nieestetyczny wygląd sekcji. tufor (dyskusja) 19:09, 18 maj 2024 (CEST)[odpowiedz]
Wątek ucichł, ale wydaje mi się wystarczająco istotny, aby 1) wydzielić go z dyskusji na nieco inny temat powyżej, 2) nie dać mu się tak szybko trafić do archiwum ;-) Pozdrawiam, tufor (dyskusja) 22:30, 12 cze 2024 (CEST)[odpowiedz]
To ja może podsumuję. Będę zamieniał:
tt ==>> code
strike ==>> s
font ==>> span ...
Co do tagu center to w tabelach należałoby go przenieść do stylu komórki w tabeli, a poza tym chciałem zaproponować jeszcze inne rozwiązanie na które w między czasie trafiłem: div class=center. ~malarz plPISZ12:39, 13 cze 2024 (CEST)[odpowiedz]
Można by pewnie szablon zrobić, bo to jednak dosyć specyficzne i może być długie i zmienne jednak. Jest już mocno rozpowszechniony szablon center (na WC). Co prawda dosyć dziwnie tam jest stosowany (w obrazkach), ale działa to nieźle. Z tagami center jest jeszcze ten problem, że mogą być dosyć dziwnie interpretowane w ramach Mediawki jeśli nie są zamknięte. Dosyć zaskakujące było dla mnie, że to działa w MW:
[[Plik:Colcoca01.jpg|mały|<center>Krzew koki]]
Nie wiem jak na pl.wiki, ale na WC było sporo tych niezamkniętych tagów i inne dziwności. O ile u nas pewnie nie ma takich w plikach, to okazuje się, że w tabelach też można używać niezamknięte tagi. Przykłady → Wikipedysta:Nux/test niezamknięte center (tabelka i więcej center w plikach). Nux (dyskusja) 20:52, 13 cze 2024 (CEST)[odpowiedz]
Niezamknięte centery są obecnie na ok. 300 stronach i sukcesywnie się ich pozbywamy. Botować poszczególne tagi zamierzam dopiero jak pozamykamy wszystkie, wtedy są dużo mniejsze szanse na wygenerowanie nowych problemów. Niestety centery są chyba najgorszym z wycofywanych tagów bo mają trochę różne działania w zależności od miejsca wywołania. ~malarz plPISZ21:13, 13 cze 2024 (CEST)[odpowiedz]
Coś ostatnio mi szwankuje działanie Szablon:MPC generującego linki do bazy planetoid i nie wiem czy to wina tego szablonu, czy samej strony Minor Planet Center. Problem istnieje od co najmniej miesiąca, ale że ostatnio nie edytuję artykułów o planetoidach, to sprawę zignorowałem myśląc, że to chwilowe problemy techniczne w Minor Planet Center. Edytując dziś nowo nazwaną planetoidę (669588) Pazura widzę, że linkowanie nadal nie działa. Wprowadziłem drobną poprawkę adresu url w szablonie (bo się zmienił), ale to nie pomogło. Szablon generuje poprawny adres, ale strona się nie wyświetla (sprawdzałem na Firefoxie i Edge na kompie oraz na Chrome na komórce). Co ciekawe, gdy ten sam adres się skopiuje i wklei w przeglądarkę, to strona wyświetla się poprawnie. Mógłby się ktoś obcykany w technikaliach tej sprawie przyjrzeć? Pikador (dyskusja) 07:00, 16 maj 2024 (CEST)[odpowiedz]
Tak i problem polega na tym, że szablon generuje dobry link, tylko strona w MPC na początku wyświetla się pusta, dopiero po odświeżeniu wygląda prawidłowo. Link, który wkleiłeś powoduje dokładnie takim sam efekt. Chyba mają jakieś zabezpieczenie antyscramblingowe? IOIOI214:07, 16 maj 2024 (CEST)[odpowiedz]
Problem zapewne jest związany z polityką referrerów po stronie Minor Planet Center. Strona MPC może blokować linki pochodzące bezpośrednio z zewnętrznych witryn. Nie wiem czy "blokują" tylko Wikipedię (po wejściu na stronę MPC z linku z angielskiej wiki jest to samo), czy z innych stron się można dostać. Należałoby chyba skontaktować się z MPC, bo tylko oni mogą rozwiązać ten problem. Kłaniam się, tufor (dyskusja) 21:51, 16 maj 2024 (CEST)[odpowiedz]
To pole będzie użyte w ... mniej niż 1% przypadków? Rozumiem że to ułatwi życie, ale z drugiej strony nie chcemy żeby infoboksy były wielkie. Ja na razie wolałym żeby to pole nie było dodawane. PMG (dyskusja) 15:30, 22 maj 2024 (CEST)[odpowiedz]
Już drugi artykuł próbuję zgłosić do czywiesza za pomocą funkcji "Zgłoś do Czy wiesz" i wyskakuje mi błąd "brak źródeł", kiedy źródła oczywiście są... Mix321 (dyskusja) 22:13, 28 maj 2024 (CEST)[odpowiedz]
Cześć, czy w szablonie Cytuj z zarchiwizowaną stroną, wpisujemy też datę dostępu? (czasami jest, a czasami nie jest to data archiwacji). --Czyz1 (dyskusja) 10:37, 30 maj 2024 (CEST)[odpowiedz]
Hm... Skoro już o tym mówisz, to nie, właściwie nie jest to wtedy istotne. Data dostępu jest potrzebna głównie jako określenie wersji strony, którą się widziało przy wstawianiu przypisu. Wersja strony w archiwum się nie zmienia, więc data dostępu jest zbędna. Nux (dyskusja) 11:37, 30 maj 2024 (CEST)[odpowiedz]
Hmm, to zależy, czy wtedy też jest generowane ostrzeżenie o braku daty dostępu (i czy to przeszkadza edytującemu). To normalne że daty mogą być różne. Nie polecam ustawiania daty dostępu w ciemno, bez sprawdzenia czy archiwum strony zawiera coś użytecznego (zdarza się, że link archiwum jest dla podanej daty, albo w całości, bezużyteczny). MarMi wiki (dyskusja) 15:27, 30 maj 2024 (CEST)[odpowiedz]
Myślałem, że najpierw wpisujemy zwykły link (niezarchiwizowany), z adresem, autorem, datą, info. kto opublikował i datą dostępu, a potem zarchiwizowany link z datą archiwacji. Data dostępu i data archiwacji mogą być różne, z tego względu powinno się, według mnie, podawać obie. Piszę o tym, bo jeden z redaktorów usunął, wpisaną przeze mnie, datę dostępu. --Czyz1 (dyskusja) 15:52, 30 maj 2024 (CEST)[odpowiedz]
Jeśli jest działający, niezarchiwizowany link, to moim zdaniem powinna być data dostępu. Archiwum w tym przypadku jest tylko zabezpieczeniem. Revsson (dyskusja) 16:19, 30 maj 2024 (CEST)[odpowiedz]
Ok. Czyli tak jak tutaj Szablon:Cytuj. Osobiście uważam, że datę dostępu powinno się wpisywać, aby wiedzieć, kto udostępnił link w artykule. Data archiwacji jest przecież wpisana w numerze archiwacji linku, więc po co ją powtarzać. A więc powinno być, według mnie, odwrotnie, niż się nakazuje. --Czyz1 (dyskusja) 17:23, 30 maj 2024 (CEST)[odpowiedz]
Istotna jest wersja strony. Data dostępu jest potrzebna, jeżeli zawartość strony może się zmieniać. Strona archiwalna jest niezmienna, więc podawanie daty dostępu nie ma sensu. Czyz1, informacja, kto podał link może być istotna dla edytujących, ale hasło tworzymy dla czytelników. Edytujący mogą łatwo znaleźć wszelkie potrzebne informacje o edycjach za pomocą narzędzia WikiBlame, klikalnego w historii edycji. Wg mnie dla źródeł zarchwizowanych optymalny jest kod {{cytuj | tytuł = [tytuł] | data = [opcjonalnie: data publikacji] | autor = [opcjonalnie: autor] | opublikowany = [instytucja publikująca stronę] | archiwum = [link do strony archiwalnej zawierający zakodowaną datę archiwizacji]}}. Michał Sobkowskidyskusja12:20, 1 cze 2024 (CEST)[odpowiedz]
WikiBlame nie radzi sobie z wyszukiwaniem adresów url (nawet jeśli, a może wtedy, gdy wstawiane były jako zwykły tekst), z mojego doświadczenia. W powyższym przykładzie zabrakło daty archiwizacji, też jest ważna (zwłaszcza jak nie ma daty/daty dostępu). Pod VE wystarczy skopiować 8 pierwszych cyfr z adresu archiwum i poprzedzielać myślnikiem. MarMi wiki (dyskusja) 16:51, 1 cze 2024 (CEST)[odpowiedz]
MarMi wiki: Nigdy nie zauważyłem żadnych problemów z wyszukiwaniem adresów url przez WikiBlame, a korzystam z tego narzędzia praktycznie codziennie wielokrotnie. Trzeba oczywiście użyć opcji „Wymuś wyszukiwanie w wikitekście”. W powyższym przykładzie nic nie zabrakło – szablon {{Cytuj}} automatycznie odnajduje i wyświetla datę archiwizacji z linku.
Np. kod {{cytuj | tytuł = Artyści | archiwum = https://web.archive.org/web/20200826215002/http://enterfestival.pl/artysci/ | opublikowany = Enter Enea Festival}}
Witam. Piszę tutaj, bo na Wikiprojekt:Infoboksy zagląda mniej osób. Ostatnio zauważyłem, że nasze infoboksy wyglądają niezbyt dobrze w wersji mobilnej. Chodzi o różny rozmiar czcionki po prawej i po lewej stronie; po lewej stronie czcionka jest mniejsza, po prawej zaskakująco duża. Wydaje mi się, że jest to spowodowane ostatnią zmianą @Pawła Ziemiana w szablonie {{Infobox wiersz}}. Przerzucenie parametru {{{2}}} do nowej linii powoduje, że parser generuje HTMLowy element akapitu <p>, a to kompletnie rozbija układ. Porównanie wyglądu: przed i po edycji Pawła. Aby uwypuklić problem: w szablonie {{Język infobox}} wiersze infoboxu są dodawane przy pomocy albo {{infobox wiersz dodaj}} albo wywołania funkcji modułu Infobox; ten drugi nie generuje znaczników akapitu, przez co tekst w infoboksie ma dwa różne wielkości (patrz np. Język niemiecki w wersji mobilnej).
Sugerowałbym przywrócenie poprzedniej wersji by poprawić wygląd, jednak w opisie zmian Paweł zaznaczył, że wprowadzona zmiana umożliwia łatwe tworzenie list. Zatem zwykłe usunięcie dodanego znaku nowej linii spowodowałoby inne kłopoty – jeśli chcemy stworzyć listę w tabeli to musimy to zrobić od nowej linii, inaczej pierwszy punktor będzie zwykłym znaczkiem *. Niestety skali nie potrafię oszacować; kilka infoboksów posiada parametry do których często wrzucane są listy, ale są one dodawane przy użyciu {{infobox nagłówek dodaj}}, np. parametr ważne dzieła w {{Artysta infobox}}. Jednak znalazłem np. Zawisza Czarny z Garbowa. Innym rozwiązaniem, które przychodzi mi do głowy, jest dodanie styli CSS, które sprawiałyby, że element <p> traciłby swoje domyślne właściwości (padding/margin, wielkość, itp.), coś jak tu: MediaWiki:Common.css#L-120. Jednak nie jestem pewien czy to nie przeglądarki ostatecznie decydują jak wyświetlają poszczególne elementy(?) i ostatecznie mogą nam spłatać psikusa. Jakieś inne pomysły? Kłaniam się, tufor (dyskusja) 23:50, 30 maj 2024 (CEST)[odpowiedz]
Hm... Ciekawe znalezisko, ale w sumie to szerszy problem. Dużo stylów boksów jest tylko w skórkach desktopowych, a nie ma ich w wersji mobilnej z tego co widzę. W większości wypadków to jest chyba jednak przypadkowe (wynika z problemów utrzymania dwóch wersji css). Ze wszystkich stylów tylko te wydaje się być explicite dla desktopa:
margin: 0 0 0.4em 1.4em;
float: right;
clear: right;
width: 250px;
Mogę zrobić domyślny gadżet i to ujednolicić. Gadżet rozwiąże problemy utrzymania tego w przyszłości. Pytanie czy coś przegapiłem poza tymi 4 linijkami? (oczywiście przetestuję jak będę wdrażał, ale może ktoś widzi jakieś wyjątki na pierwszy rzut oka) Nux (dyskusja) 00:34, 31 maj 2024 (CEST)[odpowiedz]
@Nux: działa, dzięki ;-) Dzisiaj zauważyłem, że u mnie ten efekt był bardziej widoczny, bo jakimś trafem na Specjalna:Ustawienia mobile miałem ustawioną "średnią" wielkość czcionki ;) Przy okazji zmiany, zmieniłeś też domyślne tło infoboksów; po lewej stronie jest teraz nieco ciemniejszy odcień szarości, tak jak na desktopie. Wcześniej w wersji mobilnej tło było jednolite, zobacz np. archiwalna wersja artykułu Czechy. IMO skoro teraz jest tak, jak w wersji desktopowej, to dla mnie wszystko pasuje, ale nie wiem, czy poprzedni, jednolity kolor tła, nie był aby zamierzony(??). Miałem też właśnie zgłaszać, że margin z klasy iboxtab nie działa, ale widzę, że to też ogarnąłeś ;) Dobra robota! Pzdr, tufor (dyskusja) 21:43, 31 maj 2024 (CEST)[odpowiedz]
Dzięki za dobre słowo :). Myślę, że większość tych efektów z kolorami była przypadkowa, bo to były kolory wymuszane przez style Mediawiki, które raczej były skrojone pod enwiki. Jeszcze podobno czasem cache coś tam szwankuje (u mnie działało, ale niżej u kogoś nie działało), tak że jednak jutro będzie pełna zmiana... Ale większość efektów powinna być już widoczna (mimo tych dwóch kroków wstecz). Nux (dyskusja) 00:11, 1 cze 2024 (CEST)[odpowiedz]
Przed chwilą sprawdzałem i w incognito na około 80% stron (tj. 8 z losowo wybranych 10) nowy gadżet ze stylami infoboksów się już ładuje. (Można sprawdzić w konsoli: mw.loader.getState('ext.gadget.infobox')==='ready';). Dziś po południu powinny być to już wszystkie strony. Taki poślizg wynika z faktu, że lista gadżetów do załadowania jest zapisana w sekcji <head> dokumentu HTML, a więc cache'uje się tak jak zawartość strony. Sama zawartość gadżetów ma mniejszy lag – pamięć podręczna jest przeładowywana w ciągu około 5–10 minut (dlatego edytowanie gadżetu ma ogółem mniejsze opóźnienie niż tworzenie gadżetu). Msz2001 (dyskusja) 10:32, 1 cze 2024 (CEST)[odpowiedz]
Przywróciłem wersje Nuksa, tj. ze stylami infoboksów wydzielonymi do gadżetu. Znaczna większość stron ładuje się z gadżetem, ale niektóre najwyraźniej muszą się jeszcze przeładować. Wydaje mi się, że nie ma co czekać w nieskończoność (nigdy nie będziemy pewni, że każda z 1,6M stron się przeładowała). Gdyby się okazało, że problem jednak występuje zbyt szeroko, śmiało cofajcie moje trzy edycje sprzed chwili w przestrzeni MediaWiki:. Msz2001 (dyskusja) 22:55, 1 cze 2024 (CEST)[odpowiedz]
Ten enter w prawej kolumnie jest potrzebny aby łatwo było wstawiać listy numerowanie/nienumerowane do komórek. Przy okazji tej zmiany były chyba też jakieś modyfikacji css, ale nie pamiętam. Cieszę się, że @Nux/@Msz2001 to naprawili na poziomie cssa. ~malarz plPISZ22:36, 1 cze 2024 (CEST)[odpowiedz]
Konwersja .mov do plików WebM lub Ogg Theora[edytuj | edytuj kod]
Sorry, że trochę obok, bo rzecz dotyczy Commons. Przyjmowane są tam pliki wideo tylko w formacie WebM lub Ogg Theora. Są jakieś dobre i bezpłatne konwertery z plików .mov? Próbowałem googlać, ale darmowe programy, które znajduję mają śmiesznie mały limit wielkości pliku (większe wymagają wersji płatnej). Kenraiz .ꓘ (dyskusja) 09:38, 7 cze 2024 (CEST)[odpowiedz]
Prywatnie używam FFmpeg z linii poleceń i sobie chwalę. Wspomagam się również en:VirtualDub#VirtualDub2 (łatwy podgląd kolejnych klatek). Myślę, że do samego przepakowania z mov do WebM wystarczy ten pierwszy:
Ostatnio użytkownik @KarolJakubiec pozgłaszał masę userboxów, co spowodowało ich błędne wyświetlanie. Aby to naprawić, musiałem powklejać do zgłoszonych szablonów <noinclude>. Aczkolwiek między zgłoszeniem tych szablonów, a moją reakcją minął cały dzień błędnego wyświetlania szablonów na dziesiątkach tysięcy stron użytkowników.
Więc moja prośba jest taka, aby ktoś dał zadanie jakiemuś botu, że jeżeli ktoś w przyszłości zgłosi do DNU jakiś szablon, to aby bot automatycznie dodawał <noinclude> aby zapobiec takiemu błędnemu wyświetlaniu (które można nadal zobaczyć na Wikipedia:Wieża Różności, gdyż specjalnie zostawiłem szablon poparcia dla SuwPolu, gdyż nikt go nie używa).
Wołam @malarz pl, gdyż myślę, że chyba to będzie idealne zadanie dla MalarzBOT. Szturnek¿?18:49, 8 cze 2024 (CEST)[odpowiedz]
O ile nie ma problemu z szablonami z przestrzeni szablon (łatwo je rozpoznać) to podobna operacja dla strony w przestrzeni Wikipdysta nie już taka oczywista. Nie wszystko z tej przestrzeni wymaga noinclude. ~malarz plPISZ19:43, 8 cze 2024 (CEST)[odpowiedz]
Czy jest jakiś rozsądny pomysł dlaczego w tym artykule tak wiele zdjęć jest skalowanych na 240 pikseli? Zwykle unikamy sztywnego skalowania. @0mang0ian pozmieniał z kolei na 277 px. Jak tak dalej pójdzie, to każdy będzie zmieniał do swojego wyświetlacza? Ciacho5 (dyskusja) 22:17, 9 cze 2024 (CEST)[odpowiedz]
thumb|240px daje w efekcie szerokość ramki porównywalną z infoboksem. Ale powinno być bez tego, za to w preferencjach można sobie ustawić domyślne 240px (zamiast 220px) i efekt będzie podobny. ~malarz plPISZ23:00, 9 cze 2024 (CEST)[odpowiedz]
A ja odpowiadałem na pytanie "Czy jest jakiś rozsądny pomysł dlaczego w tym artykule tak wiele zdjęć jest skalowanych na 240 pikseli?". ~malarz plPISZ23:10, 9 cze 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
Oprogramowanie, wykorzystywane do wyświetlania plików SVG zostało zaktualizowane, co wyeliminowało wiele obecnych od dawna błędów w renderowaniu SVG. [8]
Struktura HTML w przypisach, tworzona przez Parsoida zmieniła się w zeszłym tygodniu. W miejscach, gdzie poprzednio dodawana była klasa mw-reference-text, pojawi się również reference-text dla lepszej zgodności ze starszym parserem. Dostępne jest więcej szczegółów. [9]
Problemy
Błąd w interfejsie Tłumaczenia Treści powodował, że menu narzędziowe pojawiały się w złych miejscach. Naprawiono to. [10]
Zmiany w tym tygodniu
Nowa wersja MediaWiki będzie instalowana na wiki testowych i MediaWiki.org od 11 czerwca, na stronach innych niż Wikipedia i niektórych Wikipediach od 12 czerwca, a następnie na wszystkich wiki od 13 czerwca (harmonogram). [11][12]
Nowa wersja MediaWiki wprowadza kolejną zmianę w strukturze HTML w przypisach: Parsoid wygeneruje teraz element <span class="mw-cite-backlink"> otaczający zarówno nazwane, jak i nienazwane przypisy, aby osiągnąć lepszą zgodność ze starszym parserem. Administratorzy interfejsu powinny się upewnić, że gadżety działające z przypisami są zgodne z nową strukturą. Dostępne jest więcej szczegółów. [13]
Na wielojęzycznych wiki, korzystających z <translate>, nieaktualne tłumaczenia są oznaczane różowym tłem do momentu aktualizacji lub potwierdzenia. Od tego tygodnia, potwierdzanie tłumaczeń będzie rejestrowane, ponadto dostępne będzie nowe uprawnienie do potwierdzania tłumaczeń, o które społeczność może poprosić. [14]
Cześć wszystkim. Czy ja bym się mogła upomnieć o to, by ten szablon odróżniał zadeklarowany w preferencjach rodzaj gramatyczny? ;-). Z góry dziękuję. WstawiłaGytha (dyskusja) 12:04, 12 cze 2024 (CEST)[odpowiedz]
Ktoś odwrócił wytłuszczenie i teraz wyszukiwana fraza w podpowiedziach wyświetla się pod okienkiem wyszukiwania zwykłą czcionką, a warianty z odmiennymi zakończeniami są wytłuszczone. W efekcie odpowiadająca wyszukiwaniu fraza jest słabiej widoczna, a w oczy rzucają się alternatywne wyniki wyszukiwania. Do niedawna działało to odwrotnie tj. intuicyjnie (przykład w pierwszej ilustracji na stronie Pomoc:Wyszukiwarka dla frazy "wiki").
Spodziewam się, że to raczej nie jest zmiana dot. tylko naszej wersji językowej, ale może ktoś śledzący zmiany oprogramowania podpowie, czy trzeba zacisnąć zęby i przyzwyczaić się do tego utrudnienia, czy też to tylko nieudany eksperyment i jest szansa, że zmiana zostanie cofnięta? Kenraiz .ꓘ (dyskusja) 22:58, 12 cze 2024 (CEST)[odpowiedz]
Raczej błąd. Nie widzę tego na liście zmian, a nawet w styczniu było to testowane w wersji normalnej (odwrotnej niż teraz). Jest szansa, że to jakiś dziwny, przejściowy problem, ale zgłosiłem: phab:T367453. --Nux (dyskusja) 19:51, 13 cze 2024 (CEST)[odpowiedz]
To o czym pisze Kenraiz występuje w nowym Wektorze. Używam starego Wektora i tam jest po staremu ;) Znalazłem zgłoszenie z 2021 roku, gdzie już wtedy został zamieszczony fragment screenshotu z pogrubieniem zakończenia: phab:T280982#7058554. Osobiście obstawiałbym, że to jednak kwestia skórki i podejścia designerów i programistów WMF. Żadnej dyskusji/ustaleń/zaleceń jednak nie znalazłem. tufor (dyskusja) 20:10, 13 cze 2024 (CEST)[odpowiedz]
W coraz większej części artykułów, coraz ma bogatszą zawartość i w efekcie niestety staje się mniej czytelny.
1) Problem widać już na przykładzie (Stanisław Lem) wskazanym na stronie szablonu – zawartość podzielona jest na sekcje (w przykładzie "Kontrola autorytatywna", "Encyklopedia internetowa", "Identyfikatory zewnętrzne"); ich nagłówki nie są wyróżnione, co nie stanowiłoby problemu, gdyby znajdujący się pod nimi blok tekstu (identyfikatorów) został odsunięty o akapit. Teraz odsunięty jest tylko pierwszy wers, przez co kolejne wersy identyfikatorów zlewają się z następnym nagłówkiem.
2) Proponuję zmienić przy okazji nagłówek sekcji "Encyklopedia internetowa" na "Encyklopedie internetowe" wzorem "Identyfikatory zewnętrzne". Kenraiz .ꓘ (dyskusja) 09:37, 15 cze 2024 (CEST)[odpowiedz]
Szablon podkleja się pod style używane do wyświetlania kategorii. Jednak istnieje możliwość dostosowania go wedle własnych upodobań edytując Specjalna:Moja strona/common.css.
#normdaten>div+div{/* style dla drugiej lub kolejnej sekcji w szablonie kontroli autorytatywnej */margin-top:1em;/* odstęp od poprzedzającej sekcji */border-top:1pxsolidvar(--border-color-base,#a2a9b1);/* pozioma linia na górze sekcji */}#normdaten>div>div{/* nagłówek sekcji w szablonie kontroli autorytatywnej */background:#f5f6f7;/* kolor tła nagłówka sekcji */}
Z zasady nie korzystam z opcji optymalizujących podgląd artykułów dla własnych potrzeb, by widzieć to co użytkownicy. Dobrze byłoby poprawić czytelność szablonów właśnie dla nich. Kenraiz .ꓘ (dyskusja) 12:03, 15 cze 2024 (CEST)[odpowiedz]
Przy ostatnich dyskusjach na Phabrykatorze o CSS infoboksów programiści Fundacji zalecali stosowanie jednak Template Styles jak się da. Nawet jeśli szablon jest na 30% stron (zdaje się, że taka liczba padła w dyskusji). W każdym razie nawet bardzo popularne szablony powinny być OK dla użycia CSS w szablonach (o ile nie występują po kilkaset razy w w jednym artykule).
Tak że przenosiłem do CSS samego szablonu KA. Dodałem też trochę powietrza (mniej więcej jak w szablonach nawigacyjnych) i użyłem kolorów zdefiniowanych na wiki... Mam nadzieję, że nadal czytelne tak jak wersja Pawła :)
Teraz jest jeszcze ładniej, bo znikło wcięcie pierwszego wiersza w zestawieniach identyfikatorów (nie chciałem już o to marudzić, bo detal) i wygląda to elegancko i przede wszystkim czytelnie. Kenraiz .ꓘ (dyskusja) 22:57, 15 cze 2024 (CEST)[odpowiedz]
Parę minut temu zwiększyła się czcionka w infoboksach, na pewno w {{Szablon:Takson infobox}}, ale mam wrażenie, że w innych też. Nie wszędzie, ale tam gdzie była pomniejszona, np. link "Multimedia w Wikimedia Commons" mieścił się w jednym wierszu, teraz zajmuje dwa... Kenraiz .ꓘ (dyskusja) 11:37, 15 cze 2024 (CEST)[odpowiedz]
Może sobie zwiększyłeś czcionkę przypadkiem w preferncjach? To taka ikonka okularów na górze strony na desktopie. Co prawda robiłem dzisiaj zmianę w CSS, ale raczej powinno zmniejszyć czcionkę niż zwiększyć. Nux (dyskusja) 13:21, 15 cze 2024 (CEST)[odpowiedz]
Nie, stało się to w trakcie edytowania i zmiana stała się widoczna tylko w nowo otwieranych zakładkach (wciąż mam jeszcze otwarte zakładki z infoboksami, w których czcionki są pomniejszone). Problem jest o tyle istotny, że wiele infoboksów było tak tworzonych/konfigurowanych (szerokości kolumn, dobór słów) tak, by w miarę możliwości mieścić treść w jednym, a nie dwóch wierszach. Kenraiz .ꓘ (dyskusja) 13:30, 15 cze 2024 (CEST)[odpowiedz]
Sprawa zgłoszona na Wikipedia:Zgłoś błąd. Tytułowy plik wyświetla się (być może nie wszystkim) jako niemal w całości biały, z czerwonym kształtem hrabstwa w prawym dolnym rogu. Powinien być on wyświetlany na tle całego stanu. Plik utworzono w 2006, więc z pewnością nie zawsze tak wyglądał, ale nie ma w historii żadnych edycji. W kategorii Commons mniej więcej połowa plików wygląda tak jak powinna, a pozostałe – tak jak ten. Barcival (dyskusja) 21:50, 15 cze 2024 (CEST)[odpowiedz]
Wyżej, w wiadomościach technicznych, zostaliśmy poinformowani, że oprogramowanie do renderowania plików SVG zostało zaktualizowane. Wydaje mi się, że to może być przyczyną. Zgłosiłem błąd na Phabricatorze. W międzyczasie @Nux poprawił wyżej wymieniony plik. tufor (dyskusja) 23:04, 15 cze 2024 (CEST)[odpowiedz]