Wikipedia:Kawiarenka/Kwestie techniczne

Skrót: WP:KT
Z Wikipedii, wolnej encyklopedii
To jest stara wersja tej strony, edytowana przez XaxeLoled (dyskusja | edycje) o 17:18, 30 lis 2022. Może się ona znacząco różnić od aktualnej wersji.
Kawiarenka pod Wesołym Encyklopedystą – kwestie techniczne
Tu rozwiązujemy problemy dotyczące oprogramowania MediaWiki, botów, skryptów, technicznych zmian w szablonach itp. W celu przyspieszenia rozwiązania problemu technicznego zapoznaj się z instrukcją zgłaszania problemów.

Obserwuj stolikArchiwum stolikaWszystkie stoliki • Skróty: WP:KT, WP:BAR:KT, WP:TECH



Witam wszystkich!

Temat już się pojawił przy okazji konkretnego albumu, ale zdecydowałem się, z uwagi na jego znaczenie, założyć oddzielny wątek. Od pewnego czasu "grzebię" w tym temacie poprawiając/uzupełniając bazę danych, ale i im dłużej w tym siedzę, tym coraz większe mam wątpliwości, czy ten dopełniacz jako taki jest w szablonie "Album muzyczny infobox" w ogóle potrzebny. Czy nie byłoby lepiej i prościej postawić przy pozycji "wykonawca" dwukropek i wstawiać nazwę/nazwisko i imię w mianowniku? Po prostu. Co o tym sądzicie? Krzysztof 13 (dyskusja) 14:41, 26 wrz 2022 (CEST)[odpowiedz]

Jako człowiek który kiedyś dodał tam 80k kodu jak najbardziej jestem za wywaleniem tego z pl.wiki. Uważam że po prostu powinno się zmienić to jak podane są parametry (tak by używały mianownika a nie dopełniacza) i dać sobie spokój z tym szablonem. PMG (dyskusja) 22:17, 15 paź 2022 (CEST)[odpowiedz]

Patrząc na Twoje edycje zastanawiam się czy nie lepiej by było zamienić na w miarę klasyczne podejście:

jest propozycja
{{{tytuł}}}
[[Plik:{{{okładka}}}|240x240px|alt=Okładka|]]
Wykonawcy albumu studyjnego
{{{wykonawca}}}, {{{2. wykonawca}}}, {{{3. wykonawca}}}, {{{4. wykonawca}}}, {{{5. wykonawca}}} oraz {{{6. wykonawca}}}
Wydany

{{{wydany}}}

{{{tytuł}}}
[[Plik:{{{okładka}}}|240x240px|alt=Okładka|]]
Szablon:Album muzyczny infobox/rodzaj
Wykonawca

{{{wykonawca}}}

Wydany

{{{wydany}}}

przy jednoczesnym połączeniu parametrów {{{x. wykonawca}}} do jednego {{{wykonawca}}}. ~malarz pl PISZ 22:49, 19 paź 2022 (CEST)[odpowiedz]
  • Mogłeś wcześniej to zaproponować. Moje zmiany są mniej inwazyjne i spójne we wszystkich szablonach. Jest tam trochę więcej miejsca na zapisywanie sumy wykonawców w postaci jednej linii. Ponadto w albumach i trasach koncertowych ci wykonawcy mają potem swoje dedykowane sekcje chronologiczne, więc ich tak łatwo nie zredukujesz do jednego pola. Chyba że te dane następny/poprzedni faktycznie wyrzucisz. Byłby to dobry kierunek w dalszym etapie połączony z botowaniem wywołań. Paweł Ziemian (dyskusja) 23:34, 19 paź 2022 (CEST)[odpowiedz]
    • Tak, to jest zdecydowanie propozycja w dążeniu do dalszego uproszczenia szablonów. Twoje zmiany są świetne na teraz. Mój bot właśnie przeczesuje wartości parametrów {{{x. wykonawca}}} aby wyłapać dopełniacze do wyrugowania. A moja propozycja niestety nadaje się tylko jako początek dyskusji. I nie wiem czy coś z niej wyjdzie czy zakończy się brakiem konsensusu. ~malarz pl PISZ 23:45, 19 paź 2022 (CEST)[odpowiedz]
  • Przygotowałem zestawienie wykonawców, które nie są linkiem do artykułu bez zmiany nazwy (nie licząc pozbycia się nawiasu): Wikipedysta:Malarz pl/szablony/Album muzyczny infobox/wykonawcy. Jest tego niecałe 10%, ale chyba połowę można szybko naprawić. Ja bym przede wszystkim wyrzucił z infoboksu "wykonawca = różni wykonawcy". Co do reszty to czekam na opinie. ~malarz pl PISZ 17:33, 20 paź 2022 (CEST)[odpowiedz]
  • Wstępnie można chyba również podzielić kilka linków na poszczególnych {{{wykonawców}}}, a każdy link ze zmienionym opisem zamieniać w ciemno. Po takim zabiegu do sprawdzenia pozostaną tylko wykonawcy nielinkujący. Oczywiście wszelkie wyrazy nie wskazujące na wykonawcę „różny”, „zespół”, „grupa” itp. itd do eliminacji. Paweł Ziemian (dyskusja) 18:27, 20 paź 2022 (CEST)[odpowiedz]
  • No, wygląda na to, ze problem z Szablonem:Album muzyczny infobox/dopełniacz został rozwiązany i to zgrabnie. Dzięki wszystkim! Teraz infobox prezentuje się o niebo lepiej. Jedna rzecz tylko chodzi mi po głowie, mianowicie nazwa/nazwisko wykonawcy - czy nie dałoby się jej/jego wyróżnić wytłuszczonym drukiem i ewentualnie umieścić też na kolorowym tle, choć nieco mniej intensywnym niż tytuł, bo w tej chwili nazwa/nazwisko trochę ginie w całości infoboxu. Krzysztof 13 (dyskusja) 18:16, 23 lis 2022 (CET)[odpowiedz]

Mamy trzy szablony {{Ludzie nauki}}, {{Instytucje naukowe}} i {{Prace badawcze}} do linkowania różnych baz w serwisie https://nauka-polska.pl. Potrzebuję stworzyć mechanizm linkujący do kolejnej bazy, tym razem publikacji. Stwierdziłem więc że warto zamiast tworzyć kolejny podobny szablon zintegrować wszystko w jeden.

Szablon dla Ludzi nauki jest jako jedyny dopracowany (oparty na {{#invoke:Cytuj}}). Wywołania dwóch pozostałych trzeba by uzupełnić o brakujące parametry. Stąd pierwsza propozycja zachowująca sposób wywołania tego szablonu dla "Ludzi nauki":

* {{Nauka Polska/temp |identyfikator |osoba=      |data dostępu=}} 
* {{Nauka Polska/temp |identyfikator |instytucja= |data dostępu=}} 
* {{Nauka Polska/temp |identyfikator |praca=      |data dostępu=}} 
* {{Nauka Polska/temp |identyfikator |publikacja= |data dostępu=}} 

Ta propozycja jest zrealizowana w {{Nauka Polska/temp}}. Być może coś trzeba tam poprawić bo nie tetstowałem. Opis jest "minimalistyczny" - w zasadzie tylko przykład. Pominąłem też w opisie opcjonalne parametry, które oczywiście pozostały w szablonie, ale do tej dyskusji są zbędne.

Druga propozycja nie zachowuje sposobu wywołania żadnego z wcześniejszych szablonów:

* {{Nauka Polska/temp |osoba=identyfikator      |tytuł= |data dostępu=}} 
* {{Nauka Polska/temp |instytucja=identyfikator |tytuł= |data dostępu=}} 
* {{Nauka Polska/temp |praca=identyfikator      |tytuł= |data dostępu=}} 
* {{Nauka Polska/temp |publikacja=identyfikator |tytuł= |data dostępu=}} 

Co o tym sądzicie? Ping do tych co ze mną dyskutowali o {{Ludzie nauki}}: @Michał Sobkowski, @Paweł Ziemian, @Kpjas, @Elfhelm. Jak kogoś pominąłem - przepraszam. ~malarz pl PISZ 10:51, 12 paź 2022 (CEST)[odpowiedz]

Co do szablonu zbiorczego, zgoda. Druga propozycja mnie bardziej przypadła do gustu.
Inna sprawa, jakie będzie w najbliższej przyszłości miejsce Nauki Polskiej w otoczeniu innych zbiornic danych https://radon.nauka.gov.pl/o-systemie/czym-jest-rad-on
RADON też ma naukowców i instytucje
PBN też ma publikacje
itd.
Kpjas (∵ ✍) 17:03, 12 paź 2022 (CEST)[odpowiedz]
  • Ja tylko powiem, że technicznie dość upierdliwe jest sprawdzanie czy podany i wypełniony jest tylko jeden z parametrów sterujących. Najlepiej żeby szablon nie umożliwiał podawania jednocześnie osoby, instytucji, pracy i czegokolwiek jeszcze. Wymagało by to oddzielnego parametru z typem na przykład
* {{Nauka Polska/temp |typ|identyfikator|tytuł= |data dostępu=}} 
Gdzie typ to osoba, instytucja itd. Takie podejście mamy w szablonach odsyłających do niektórych bazodanowych serwisów sportowych. Paweł Ziemian (dyskusja) 20:18, 12 paź 2022 (CEST)[odpowiedz]
* {{Nauka Polska/temp |typ=(osoba|instytucja|...) |id=identyfikator |tytuł= |data dostępu=}} 
w ten sposób można uniknąć tych nienazwanych, a składania prawie taka sama jak w /temp2. ~malarz pl PISZ 21:59, 12 paź 2022 (CEST)[odpowiedz]
Ja też nie jestem fanem parametrów indeksowanych. Same problemy z nimi, spacje wiodące, znak równości itd. itp. Można jeszcze rozważyć zapis id = typ/identyfikator, czyli na przykład |id = osoba/1234. Albo zamiast nazwy typ użyć baza bo to się jakby samo przeniesie na „[w:] baza ...”. Paweł Ziemian (dyskusja) 22:08, 12 paź 2022 (CEST)[odpowiedz]
  • Co to za baza publikacji na Nauka Polska, że chcemy do niej linkować? Czy to nie będzie dubel? Czy te publikacje nie pochodzą tak czy siak z innych baz/czasopism? Masur juhu? 11:30, 14 paź 2022 (CEST)[odpowiedz]
    • 7 i 8 przypis w Błażej Błażejowski. ~malarz pl PISZ 12:45, 14 paź 2022 (CEST)[odpowiedz]
      • W przypadku BB lepiej linkować do artykułów, ale jestem w stanie wyobrazić sobie naukowców, których dorobku nie da się potwierdzić inaczej niż w Nauce Polskiej. Lub najłatwiej w NP. W każdym razie nie widzę powodów, aby technicznie nie umożliwiać wygodnego linkowania do NP odnośnie do publikacji. Michał Sobkowski dyskusja 19:13, 15 paź 2022 (CEST)[odpowiedz]
      • 1. doi 10.4202/app.2008.0078 [1], 2. racja- gdzie to w ogóle opublikowano? Poza tym "wybrane publikacje" łamie WP:ZTL. I jak mówi Michał - lepiej linkować do artykułów, choć pewnie jestem w stanie wyobrazić sobie naukowców, których dorobku nie da się potwierdzić inaczej niż w Nauce Polskiej. Lub najłatwiej w NP.. I choć nie widzę powodów, aby technicznie nie umożliwiać wygodnego linkowania do NP odnośnie do publikacji, pamiętajmy, że NP to baza wtórna, wielce wybrakowana. I wg mnie nie powinna być stosowana do artykułów. Masur juhu? 15:25, 16 paź 2022 (CEST)[odpowiedz]

Z ostatniego zgłoszenia problemu w gadżecie CzyWiesz na Discordzie (spowodowanego zmianą struktury Spisu wikiprojektów, bo 3 obecnie gadżety, w tym mój do CW, scrape-ują stamtąd listę wikiprojektów) rozwinęła się dyskusja (na Discord#techniczne i u mnie w dyskusji) czy nie lepiej:

  1. stworzyć listę wikiprojetów w formacie JSON (a Lua tworzyłby z niej obecną stronę "Spis…",
  2. wydzielić fragment tych skryptów, służący do pobierania listy, jako osobny *.js – wspólny i jednolity dla wszystkich gadżetów (obecnych i przyszłych), importowany podczas ładowania gadżetu – obecnie mój CW pobiera listę i tyle, AjaxQuickDelete już ma funkcję jej cache-owania a gadżet do wyróżnień też ją ma, ale usprawnioną.

Projekt JSON-a tu → user:Kaligula/brudnopis/Wikipedia:Wikiprojekt/Spis_wikiprojektów.json, wyjaśnienie na górze strony. Można go zrobić używając skomplikowanej hierarchii, można zrobić zwykłą array i tylko tagować… IMO łatwiej będzie gadżetom odczytać całą listę zwykłych wikiprojektów, jeśli nie będzie hierarchiczna, dlatego dziedziny wiedzy tylko tagowałem. Czy specjalne i instytucjonalne wrzucić razem tak jak teraz czy oddzielić je w osobne arraye? To jest do dogadania.

Co o tym myślicie? Kaligula (dyskusja) 10:50, 13 paź 2022 (CEST)[odpowiedz]

Opis JSON-a przeniosłem do dyskusji tamtej strony Dyskusja wikipedysty:Kaligula/brudnopis/Wikipedia:Wikiprojekt/Spis wikiprojektów.json. Kaligula (dyskusja) 20:05, 13 paź 2022 (CEST)[odpowiedz]

Generalnie pomysł mi się podoba. Mam jeszcze takie przemyślenie, że część pól tego JSONa można zrobić opcjonalnymi i wyznaczać na podstawie innych pól. Na przykład name w większości przypadków (zawsze?) będzie tym samym co page, ale pozbawione przedrostka Wikiprojekt:. Podobnie ma się sprawa z linkiem do dyskusji (chyba zawsze do określenia automatycznie), nazwą portalu (na podst. strony portalu, która często jest taka jak nazwa wikiprojektu, tylko inna przestrzeń), link do napisania nowej sekcji też zwykle ma formę do określenia na podstawie innych pól. W mojej opinii uczynienie ich opcjonalnymi pomoże w ogarnięciu strony i wykonaniu ewentualnych korekt w przyszłości (rozpropagują się same do powiązanych pól). Ponadto zmniejszy się czas pobierania danych na potrzeby gadżetów, bo odchudzi to plik JSON (szczególnie dotyczy osób z wolnym łączem). Msz2001 (dyskusja) 11:00, 13 paź 2022 (CEST)[odpowiedz]
Zgadzam się z odchudzeniem Jasona, faktycznie niektóre pola są do wygenerowania (dyskusje wszystkie są standardowe, widzę). Nie patrzyłem na to wcześniej, zająłem się tylko głównie określeniem struktury i przemapowaniem. Jednak jeśli chodzi o name i page to zazwyczaj są podobne, za wyjątkiem:
  • GLAM – mają przedrostek "GLAM/", ale nawet to uwzględniając to jest jeszcze "Zamek Królewski na Wawelu - Państwowe Zbiory Sztuki" ("Wikiprojekt:GLAM/Zamek Królewski na Wawelu") i "Faras" ("Wikiprojekt:GLAM/Kolekcja Muzeum Narodowego w Warszawie/Faras")
  • w nieaktywnych "Kolejnictwo" ("Wikiprojekt:Transport szynowy/Kolejnictwo"), "Metro" ("Wikiprojekt:Transport szynowy/Metro"), "Szkoła austriacka" ("Wikiprojekt:Szkoła austriacka (ekonomia)"), "Grafika" ("Wikiprojekt:Projekt Grafiki"), "Saska Kępa" ("Wikiprojekt:Saska Kępa w Wikipedii") i "Tworzenie stron ujednoznaczniających dla nazwisk" ("Wikiprojekt:Nazwiska/Tworzenie stron ujednoznaczniających dla nazwisk").
Wśród ww. można w nieaktywnych zostawić domyślny zapis nazwy (poza tymi 2-ma z Transportu), a w GLAM-ie nie wiem, nie znam się. Wychodziłoby na to, że domyślnie można generować domyślny page, o ile nie zostanie podany customowy (obecnie w 2-4 ww. wikiprojektach tak będzie).
A z Portalami już bym uważał, bo nie zawsze jest taka sama nazwa – i tu teoretycznie możnaby domyślnie generować jeśli nie będzie podanego customowego – ale też nie zawsze jest taki portal jak wikiprojekt – więc nie zawsze w ogóle będzie można generować, jeśli customowego nie będzie podanego; a czasem portali jest kilka pod opieką jednego wikiprojektu. IMO z Portalami trzeba je tam wpisywać. Obecnie są jako String lub Array of Strings. Kaligula (dyskusja) 12:33, 13 paź 2022 (CEST)[odpowiedz]
  • Jak masz czas to wydzielenie do oddzielnego skryptu jest dobrym pomysłem. Uważam jednak, że sam JSON jest technicznie dobrym pomysłem, ale użytkowo już mniej. Pobieranie danych z Wikipedia:Wikiprojekt/Spis wikiprojektów ma tę wielką zaletę, że uzupełnienie tej listy jest łatwe dla niewtajemniczonych. To niestety jest też wadą, bo łatwo mogą ją popsuć. Ale generalnie moim zdaniem zaleta przeważa wadę. ~malarz pl PISZ 12:29, 13 paź 2022 (CEST)[odpowiedz]
    • Też widzę ten minus, dla niewtajemniczonych, ale jakby nie patrzeć, JSON nie jest nieczytelny :) Jest bardzo podobny do stosowanych na wiki szablonów. Może wystarczy tylko dodać dobry opis parametrów wymagancyh i opcjonalnych. Kaligula (dyskusja) 12:33, 13 paź 2022 (CEST)[odpowiedz]
    • Przed zapisaniem strony JSON z błędami składni (np. niesparowane cudzysłowy, brak przecinka itp.) MediaWiki wyświetla komunikat, który należy zatwierdzić. Edytor kodu podpowiada, gdzie te błędy występują. Peter Bowman (dyskusja) 14:59, 13 paź 2022 (CEST)[odpowiedz]
    Zgadzam się, że to będzie trudne dla części osób, ale z drugiej strony jak psuje się gadżet to jest znacznie gorzej. To znaczy zaletą JSON jest stabilność gadżetów. Wadą jest ew. nieaktualność spisu... Myślę jednak, że można dodać link do dyskusji żeby zaproponować zmiany, albo tutaj na kaw. techniczną. Tam i tak jest średnio parę edycji w roku, więc pod tym względem moim zdaniem stabilność przeważa za JSONem. Nux (dyskusja) 16:14, 15 paź 2022 (CEST)[odpowiedz]

Zaktualizowałem roboczego JSONa do stanu listy Wikiprojektów na dziś (była zmieniana w międzyczasie). Ujednoliciłem linki do dołączenia do uczestników w atrybucie "join" (http→https, veaction=editsource→action=edit). W sumie, jeśli chodzi o odchudzenie, to wszystkie te linki mają wspólny początek https://pl.wikipedia.org/w/index.php i fragment &action=edit, więc też można to powycinać i wpleść w kod generatora, a dla zwiększenia uwagi można zmienić nazwę atrybutu na "joinlink". Kaligula (dyskusja) 12:19, 30 paź 2022 (CET)[odpowiedz]

Jeśli nie ma więcej uwag to wygląda na to, że @Msz2001 może pisać parser :) A kiedy wszystko zostanie przetestowane to można będzie przenieść JSON-a z mojego brudnopisu to innej przestrzeni. Właśnie – jakiej? Najbardziej odpowiednią wydawała mi się strona Wikipedia:Wikiprojekt/Spis_wikiprojektów.json analogiczna do obecnej Wikipedia:Wikiprojekt/Spis wikiprojektów, stąd też nazwa mojego brudnopisu. Kaligula (dyskusja) 22:21, 4 lis 2022 (CET)[odpowiedz]
Wydaje mi się, że ta strona, którą zasugerowałeś będzie okej. W czasie pisania parsera zauważyłem jeszcze że pola o dwuwyrazowej nazwie mają niespójny system nazewnictwa: report_link i portalname. Warto to ujednolicić. Proponuję albo snake_case (jak report_link) albo camelCase (reportLink). Msz2001 (dyskusja) 17:47, 6 lis 2022 (CET)[odpowiedz]
Parser umieściłem tutaj: Wikipedysta:Msz2001/lib-wikiprojects.js. Na razie nie podpinałem go do żadnego z gadżetów. Dokumentacja jest wypisana tylko w komentarzach, ale jak to będzie w finalnej postaci, to chyba opiszę coś więcej na stronie dyskusji. Funkcja zwracająca projekty jest dostępna jako gadget.getWikiprojects() i, oprócz samej listy, zwraca też liczbę dni, które upłynęły od pobrania tych danych z serwera. Msz2001 (dyskusja) 19:32, 6 lis 2022 (CET)[odpowiedz]
Nie wiem tylko w jakiej kolejności ogarnąć gadżety. Czy dopiero jak uda się to wdrożyć (czytaj: zostanie faktycznie zaakceptowane i będzie działać)? Czy jak tylko JSON zostanie przeniesiony z mojego brudnopisu do przestrzeni wspólnej? Czy od razu poprawiać kod gadżetów, żeby korzystały z JSON-a póki jest w mojej przestrzeni? Kaligula (dyskusja) 22:28, 4 lis 2022 (CET)[odpowiedz]

Ponieważ powyższa dyskusja zamarła, wykonałem następujące:

  1. ustandaryzowałem nazewnictwo pól w JSON-ie do snake_case,
  2. przeniosłem parser do MediaWiki:Gadget-lib-wikiprojects.js.

Jeśli nie pojawią się do pojutra obiekcje, to:

  1. przeniosę spis wikiprojektów do Wikipedia:Wikiprojekt/Spis wikiprojektów.json,
  2. zmodyfikuję AjaxQuickDelete, aby korzystał z nowej metody pobierania listy (i aby wychwycić ewentualne błędy).

Dodatkowo, warto pomyśleć o parserze listy w Lua, który mógłby wygenerować zawsze aktualną listę na Wikipedia:Wikiprojekt/Spis wikiprojektów. Jeśli nie zgłosi się chętny, to takowy napiszę. Msz2001 (dyskusja) 19:48, 14 lis 2022 (CET)[odpowiedz]

Wykonałem powyższe, ponadto zacząłem pisanie parsera listy: Moduł:Brudnopis/Msz2001/Parser wikiprojektów. Jeśli w przeciągu najbliższych dni nie zostaną zgłoszone błędy w bibliotece, to myślę, że będzie można podpiąć do niej pozostałe dwa gadżety - Czywiesz i Zgłoś do wyróżnienia. Msz2001 (dyskusja) 18:10, 17 lis 2022 (CET)[odpowiedz]

Usunięcie całej treści podczas tworzenia nowego artykułu

Podczas przełączania z edytora kodu źródłowego na edytor wizualny, wyskoczyła mi informacja o błędzie serwera. Po kliknięciu "spróbuj ponownie", przekierowało mnie do edytora wizualnego, jednak skasowało całą treść artykułu, nad którym pracowałem od paru godzin (Mistrzostwa Świata w Piłce Nożnej Kobiet 2023). Aglw (dyskusja) 18:43, 22 paź 2022 (CEST)[odpowiedz]

  • Ja używając Firefoxa mam od ok. dwóch miesięcy częste komunikaty błędów przy próbach podglądu, zapisie itp., ale "spróbuj ponownie" zwykle pomaga. Czasem wracałem wstecz do poprzednich okien wyszukiwarki i też kiedyś pomogło. Kiedyś jednak też straciłem edytowany artykuł i dlatego edytując coś dłużej, zawsze zapisuję co jakiś czas bieżącą wersję w pliku txt. Alternatywą jest używanie brudnopisu i zapisywanie w nim wersji przed każdą operacją. Kenraiz (dyskusja) 19:24, 22 paź 2022 (CEST)[odpowiedz]
Dlatego przy dłuższych edycjach należy co jakiś czas zapisywać edycje, albo kopiować kod do notatnika.
Nie ma co kusić losu.
Być może cofając się w historii przeglądarki dałoby się coś odzyskać (zwłaszcza jeśli to był edytor kodu z podglądami przeładowującymi stronę; albo dość często przełączało się między typami edycji kod/VE). MarMi wiki (dyskusja) 21:19, 22 paź 2022 (CEST)[odpowiedz]

Tajemnicza litera "a­"

@Piotras18 po kliknięciu na link wewnętrzny w Puchar Karpat w skokach narciarskich utworzył artykuł Va­lentin Tatu, którego tytuł zawiera znak . Znak ten wygląda identycznie jak zwykła litera a, ale jest traktowany jako inny symbol (w efekcie link do Valentin Tatu w pozostałych hasłach był czerwony, póki nie przeniosłem artykułu). Znak ten różny jest również od litery а z cyrylicy. Pytanie, co to za symbol i skąd on się wziął w haśle. Może warto przejrzeć (np. botem), czy takie lub podobne znaki nie występują w większej liczbie artykułów? Barcival (dyskusja) 21:18, 22 paź 2022 (CEST)[odpowiedz]

  U+0056 LATIN CAPITAL LETTER V     V
  U+0061 LATIN SMALL LETTER A     a
  U+00ad SOFT HYPHEN     ­ \-
  U+006c LATIN SMALL LETTER L     l
  U+0065 LATIN SMALL LETTER E     e
  U+006e LATIN SMALL LETTER N     n
  U+0074 LATIN SMALL LETTER T     t
  U+0069 LATIN SMALL LETTER I     i
  U+006e LATIN SMALL LETTER N     n
  U+0020 SPACE     \space
  U+0054 LATIN CAPITAL LETTER T     T
  U+0061 LATIN SMALL LETTER A     a
  U+0074 LATIN SMALL LETTER T     t
  U+0075 LATIN SMALL LETTER U     u
Czyli „a” jest normalne, tylko tam siedzi niewidzialny znak. Paweł Ziemian (dyskusja) 21:33, 22 paź 2022 (CEST)[odpowiedz]

Specjalna:Cytuj generuje linki bez protokołu

Przykładowo, dla Specjalna:Cytuj/Polska linki są generowane w formie //pl.wikipedia.org/w/index.php?title=Polska&oldid=68578549, natomiast na stronie MediaWiki widnieje protokół http://. Czy jest to zachowanie celowe? Mmikolaj0 (dyskusja) 23:19, 24 paź 2022 (CEST)[odpowiedz]

To nie jest zachowanie stricte błędne z zasady. Oznacza to, że schema protokołu może być czy to http: czy https:. Silniki współczesnych przeglądarek desktopowych radzą sobie z tym bez problemu. Niemniej sugeruje to, że zasób jest także dostępny po niezabezpieczonym protokole HTTP, co w przypadku polskiej Wikipedii nie ma miejsca, bo klient przy próbie dostępu po nagim HTTP od razu dostaje polecenie załadowania zasobu w trybie szyfrowanym. – smyru 13:59, 30 paź 2022 (CET)[odpowiedz]

Zepsute szablony zabytków na Commons

Parę problemów z szablonem Zabytek i Zabytek nieruchomy na Commons.

1. Przede wszystkim oczekuje ID zabytku z naszych rejestrów, ale moim zdaniem powinny obsługiwać Q. Byłoby to wygodniejsze i chyba nawet bardziej jednoznaczne.

2. Przy obsłudze Q mogłoby wyświetlać numer inspire ID, który jest jak rozumiem nowszy i bardziej uniwersalny niż te nasze stare numery które się zmieniają przez lata (np. A.3/1-4 z 2003-06-30, A.3/1-4 z 2003-07-16, A.3/1-5 z 2009-09-30, A.3/1-5 z 2011-12-01).

3. Jeśli nawet szablony działają jak powinny to nawet przy dobrych chęciach i włożeniu sporej pracy nie umiałem ich wypełnić poprawnie... Oto moja (krótka) historia ;]

  • Poprawiłem Q dodając inspire ID i numer zabytku: [3].
  • Próbowałem poprawić również wpis w grafice, ale nadał grafika jest w kategorii nieznanych ID: [4].
  • Próbowałem różnych ID (Q z WD, inspire, zwykły numer zabytku).

Jeśli ktoś ma czas i uprawnienia, to trzeba coś zrobić z tym szablonem. Przy okazji trzeba poprawić szablon do przesyłania danych dostępny pod takim adresem: https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=wlm-pl&id=Q9213267

Pozdrawiam, Nux (dyskusja) 00:26, 26 paź 2022 (CEST)[odpowiedz]

PS: To mogło być niejasne, ale to "id=Q9213267" z kreatora przesyłania trafia potem jako pierwszy parametr szablonu Zabytek nieruchomy (możliwe że czasem do Zabytek). Nux (dyskusja) 00:34, 26 paź 2022 (CEST)[odpowiedz]

Commons - jak ze starszej wersji pliku stworzyć nowy plik?

Mam taki problem z mapkami na Commons - zmienia się systematyka jakiegoś gatunku ptaka (według jednej z kilku konkurencyjnych list ptaków świata), np. gatunek dzielony jest na kilka innych, i często ktoś nadgorliwie zmienia mapkę nie myśląc zupełnie o tym, że systematyka wciąż jest sporna i różne Wikipedie stosują różne ujęcia systematyczne. Weźmy np. ten plik - część autorytetów podzieliła ten gatunek na afrykański i azjatycki, ale u nas nadal obowiązuje systematyka panów Mielczarka i Kuziemki zaliczająca doń populacje zarówno z Afryki jak i Azji. Jak utworzyć nowy plik ze starej wersji pliku, czyli aby istniały osobne mapki z obiema wersjami systematyki? Ściągnąć na dysk i uploadować jako nowy czy jest inny sposób? Co wtedy z autorstwem pliku - jest na to jakiś szablon? Pikador (dyskusja) 11:29, 26 paź 2022 (CEST)[odpowiedz]

Jako to zrobili w Gdańsku?

Niedawno któryś boot, wyrzucał z infoboksów herby miast. A jak Gdańsku to obeszli? Np. Baszta Browarna, Baszta Raduńska i inne - jest. A jak wpisuję jakiekolwiek inne miasto, nie działa, nawet Warszawa! Jak oni to wykombinowali??? Braniewiak (dyskusja) 13:32, 29 paź 2022 (CEST)[odpowiedz]

Błędnie wypełniony infoboks (miasto podane w polu Państwo) - obie baszty powstały grubo przed XIX w., żadna nie została ostatecznie zniszczona w okresie gdy Gdańsk był (conajmniej?) dwukrotnie państwem (Wolne_Miasto_Gdańsk_(1807–1814), Wolne Miasto Gdańsk wg Gdańsk#Przynależność_państwowa).
Kraków też pewnie zadziała.
Szablony Państwo dane Gdańsk i Państwo dane Wolne Miasto Gdańsk (zakładam że czymś się różnią?), podobnie Kraków (z tym że dłuższa nazwa to przekierowanie na krótszą wersję). Być może warto by mieć tylko wersje z długimi nazwami? MarMi wiki (dyskusja) 16:35, 29 paź 2022 (CEST)[odpowiedz]

Szablony Cytuj - niespójne spacje między edytorem tekstowym i wizualnym

Wstawiając szablon cytowania w edytorze tekstowym otrzymujemy:

<ref>{{Cytuj | tytuł = Jakaś strona | url = https://example.com}}</ref>

Jak wstawimy przypis w edytorze wizualnym mamy mniej spacji (brak spacji za pionową kreską):

<ref>{{Cytuj |tytuł = Jakaś strona |url = https://example.com}}</ref>

Jeszcze, jakby tego było mało, gdy przy tworzeniu nowej strony w edytorze tekstowym wstawimy szablon Cytuj stronę, potem przełączymy na edytor wizualny, a następnie z powrotem na tekstowy, wszystkie spacje dookoła pionowej kreski znikają (pomimo, że pierwotnie były po obu stronach):

<ref>{{Cytuj stronę|url=https://example.com|tytuł=Jakaś strona|data dostępu=2022-10-30}}</ref>

Może warto by to ujednolicić? Ololuki (dyskusja) 20:52, 30 paź 2022 (CET)[odpowiedz]

Błąd HotCata przy dodawaniu kategorii z {{Kategorie tematyczne}}

Dodając do artykułu za pomocą HotCata kategorię, na stronie której znajduje się szablon {{Kategorie tematyczne}} (np. Kategoria:Kategorie według materiałów), zamiast owej kategorii HotCat wstawia Kategoria:Kategorie dla kategorii, jak to miało miejsce np. tutaj [5]. Zapewne ma to coś wspólnego z tym fragmentem kodu w {{Kategorie tematyczne}}:

<includeonly>[[Kategoria:Kategorie dla kategorii|{{PAGENAME}}]]</includeonly><noinclude> 

Czy dałoby się to w jakiś sposób naprawić? Delta 51 (dyskusja) 21:08, 30 paź 2022 (CET)[odpowiedz]

Szablon Link-interwiki

Linki typu {{link-interwiki|...|Q=...}} na stronie ze zmarłymi we wrześniu mają się dobrze. Tymczasem próba zastosowania ich w kolejnym miesiącu jest konsekwentnie tępiona (24 paź 2022, 26 paź 2022) przez niezalogowaną osobę, która poświęciła temu dwie z trzech swoich edycji (i do tego jej aktywność się ogranicza). Czy zostało coś gdzieś ustalone, że się tego od października’22 nie stosuje? Jeśli moje edycje są zgodne ze sztuką, a ktoś je cofa, to mam ot tak po prostu odpuścić? 89.68.171.222 (dyskusja) 23:28, 30 paź 2022 (CET)[odpowiedz]

  • Szablon jest akceptowany w pl.wikipedii. Podobnie jak niestety edytowanie przez użytkowników niezarejestrowanych, co wiąże się z niemożnością kontaktu z takim edytorem, śledzenia jego aktywności, doświadczeń i motywów. W przypadku powtarzających się niepoprawnych edycji spod dynamicznego IP na określonej stronie jedynym rozwiązaniem problemu jest zgłoszenie jej do zabezpieczenia. Podobny skutek może mieć też toczenie w tej sprawie wojny edycyjnej. Kenraiz (dyskusja) 01:01, 31 paź 2022 (CET)[odpowiedz]
  • Mam podobny pogląd w tej sprawie. Jeśli dynamiczny IP zrobił coś, z czym się nie zgadzasz, a nie wyjaśnił w opisie zmian, dlaczego to robi, możesz po prostu anulować jego edycję. A jeśli sytuacja przerodzi się w wojnę edycyjną, to tak jak napisał Kenraiz, artykuł pewnie zostanie zabezpieczony, więc najlepiej założyć sobie konto. PG (dyskusja) 11:09, 31 paź 2022 (CET)[odpowiedz]
    • Dziękuję. Teraz mam przynajmniej czego się trzymać ;-) Bo choć sama kwestia dodania tego szablonu w tym wypadku nie jest jakoś szalenie istotna, to jednak byłem nieco zdezorientowany, nie po pierwszej cofce, ale po drugiej już tak. 89.68.171.222 (dyskusja) 12:03, 31 paź 2022 (CET)[odpowiedz]

W rzeczonym artykule nie podano, do jakiego pasma należy ta "góra", przez co w infoboksie wyświetla się pytajnik ze strzałką kierującą do Wikidata. Ponieważ nie mamy opisanego tego pasma, nie bardzo można coś zrobić (oprócz opisania). Ale jak zrobić, żeby w infoboksie nie wyświetlała się linia pasmo? Ciacho5 (dyskusja) 11:50, 2 lis 2022 (CET)[odpowiedz]

  • Szablon należy zmienić, by pasmo nie było obowiązkowym parametrem. Nie każda góra przynależy do pasma – w efekcie w wielu artykułach wpisywane jest coś na siłę, choć góry nie przynależą do jakiegokolwiek pasma (np. Etna – pasmo: brak, Teide – jako pasmo dano masyw, Kīlauea – jako pasmo dano grzbiet oceaniczny, Dzierżyńska Góra – jako pasmo dano wysoczyznę, Ararat – jako pasmo dano wyżynę, Town Hill – jako pasmo dano wyspę itd. itp). Z drugiej strony są takie artykuły jak Piton de la Petite Rivière Noire, gdzie pasmo nie jest wypełnione i parametr jest po prostu pominięty... Aotearoa dyskusja 12:18, 2 lis 2022 (CET) PS. Zauważyłem, że w przypadku Dzierżyńska Góra i Town Hill parametr "pasmo" nie jest wypełniony w artykule, a jednak pole w widoku artykułu jest (błędnie) wypełnione. Skąd zatem to jest zaczerpnięte? Czy to automat z WikiData? Bo jeśli automat, to należałoby go wyłączyć, bo na WikiData są w tym zakresie nonsensy.[odpowiedz]
  • Pole już nie jest wymagane, choć jest sugerowane. Jest połączone z P4552 na Wikidanych. Ja bym połączenia nie wycinał z WD, tylko pracowicie usuwał błędy z WD. Inaczej się ich nie pozbędziemy. Jeżeli chodzi zaś o sam znak zapytania to nie trzeba stworzyć polskiego artykułu a jedynie wpisać etykietę w języku polskim do d:Q485633. W efekcie w infobokise pojawi się ta etykieta, ale nie będzie linkiem do nieistniejącego artykułu. 13:42, 2 lis 2022 (CET)
  • Tu pojawia się jednak problem wyszukiwania błędów na WikiData i pewnie czasami przepychanie się z tymi, dla których masyw, czy wysoczyzna jednak mieści się w terminie "mountain range" (przy czym należy pamiętać, że w wielu przypadkach, także w tym, nie ma 100% przełożenia terminu angielskiego na polski). Jednak takie automatyczne zaciąganie w przypadku terminologii geograficznej i różnie stosowanych podziałów na jednostki fizyczno-geograficzne stosowanych przez geografie różnych państw, nie jest dobrym pomysłem. Aotearoa dyskusja 16:52, 2 lis 2022 (CET)[odpowiedz]
    • Ja jak znajdę błędy, głównie powstałe w wyniku działania bota, to je usuwam, czasami nawet szukam w infoboksach na wiki, z których zostały pobrane. I jeszcze mi się nie zdarzyło aby te usunięcia zostały zrewertowane. Parę razy miałem przepychanki, ale one chyba w większości dotyczyły ręcznie dodanych na WD informacji. Z wymienionych przez Ciebie artykułów na WD usunąłem "łańcuch górski/mountain range". Zobaczymy co z tego będzie. Ten parametr jest w infoboksie od ponad 4 lat. A patrząc na d:Property talk:P4552 to tam nie powinno być wpisywanych obiektów, które nie są (P31): łańcuch górski (Q46831), masyw górski (Q1061151), pasmo górskie niezwiązane geologicznie (Q1437459), hill group (Q19850234), Skarpa (geotechnika) (Q1174791), góra (Q8502). A wśród tych usuwanych przeze mnie kilka nie spełniało tego warunku. ~malarz pl PISZ 17:24, 2 lis 2022 (CET)[odpowiedz]
      Tylko, że masyw, góra, czy skarpa to nie są łańcuchy górskie. To, że ktoś sobie kiedyś ustalił, że to są łańcuchy, nie zmieni faktu, że w polskiej geografii one łańcuchami nie są, a skoro piszemy o tym w polskiej Wikipedii, to musimy stosować terminologię zgodną z terminologią polską, a nie obcą. To jest właśnie duży problem Wikidata – próba standaryzacji wszystkiego, nawet tego czego zestandaryzować się nie da, ze względu na różne słownictwo (i co ważniejsze różne jego znaczenie) w różnych językach. Akurat kwestia terminologii angielskie v. polskiej jest mocno kłopotliwa i często wymaga dość dużej ekwilibrystyki by prawidłowo przetłumaczyć, gdyż zasięgi terminów często istotnie się różnią. Aotearoa dyskusja 07:09, 3 lis 2022 (CET) PS W artykułach jak Rowokół, czy Kilimandżaro nadal przy braku wypełnienia parametru pojawia się znak zapytania i link do jakiś elementów z Wikidata (mocno naciąganych elementów jak East African mountains w praktyce bez źródeł by geografowie coś takiego wyróżniali, czy Baltic Uplands, które jak wynika ze źródeł wyróżniają sobie Niemcy jako region ciągnący się od Jutlandii po Estonię, a który w polskiej geografii nie istnieje i linkowanie do niego z artykułów o polskich obiektach ukształtowania terenu jest bezsensowne). Aotearoa dyskusja 07:34, 3 lis 2022 (CET)[odpowiedz]

Pirackie strony na czarną listę

Dobry wieczór, wypadałoby zczarnolistować stronki: dic.academic.ru, etnolog.ru, nations.su. Wszystkie czerpią z jakichś tam papierowych encyklopedii i leksykonów bez poszanowania praw autorskich. Na ruwiki taki academic jest na czarnej liście, tutaj bywa podawany w źródłach, więc to poważniejsza sprawa. Może potrzeba jakiejś masowej akcji, jeśli skala problemu jest duża? 2A00:F41:383A:9A3A:D913:3BCA:F4ED:7FE2 (dyskusja) 22:46, 6 lis 2022 (CET)[odpowiedz]

Na jakiej licencji

Jest na internecie portal, którego autor pozwala na wykorzystywanie zdjęć. Byłyby bardzo przydatne, gdyż na Commons brak zdjęć niektórych gatunków. Rzecz w tym, że ich autor pozwala je wykorzystywać tylko w celach niekomercyjnych, tylko w formie oryginalnej i bez możliwości przetwarzania. Czy mogą być wykorzystane na commons i jaką należałoby im dać licencję, bo zdaje się, że wszystkie licencje na commons pozwalają na przetwarzaniue zdjęć. Selso (dyskusja) 18:27, 7 lis 2022 (CET)[odpowiedz]

W takim razie nie mogą trafić na Commons, bo wolna licencja w myśl zasad Wikimedia Commons musi dopuszczać tworzenie prac zależnych oraz wykorzystanie komercyjne. ~CybularnyNapisz coś ✉ 18:36, 7 lis 2022 (CET)[odpowiedz]
@Cybularny. Dziękuję za odpowiedź. Selso (dyskusja) 18:53, 7 lis 2022 (CET)[odpowiedz]

Cytuj książkę - brak pola "wydanie" w edytorze kodu źródłowego w kreatorze "Cytuj/Dodaj przypis"

W edytorze kodu źródłowego po kliknięciu "Cytuj" pojawia się kreator dodawania szablonu cytowania. Po wybraniu rodzaju "Książka" nie ma pola "Wydanie". W rodzajach "Pismo" i "Uniwersalny" takie pole jest. Myślę, że warto byłoby dodać takie pole, gdyż często różne wydania różnią się zawartością i zawierają cytowane informacje na różnych stronach, a nie zawsze numer ISBN jest różny dla różnych wydań. Ololuki (dyskusja) 11:15, 12 lis 2022 (CET)[odpowiedz]

Szablon:Link-interwiki

Cześć. Szablon:Link-interwiki nie działa ( za to działa stare en. Przykład : na stronie sedacja. Link

{{link-interwiki|sedacja paliatywna|en|Palliative sedation}}

do angielskiej stronu en:Palliative sedation Soul surfer (dyskusja) 16:42, 14 lis 2022 (CET)[odpowiedz]

Działa dokładnie tak jak powinien: sedacja paliatywna[[:d:{{{Q}}}#sitelinks-wikipedia|(inne języki)]]. Jest czerwony link do brakującego u nas hasła i niebieski (zmniejszony) do angielskiej wersji podpisany "(ang.)". ~malarz pl PISZ 16:50, 14 lis 2022 (CET)[odpowiedz]
1. Coś na stronie sedacja było dla ciebie na tyle nieoczekiwane, że pomyślałeś, że szablon nie działa. Czy możesz rozwinąć swoją myśl? Jakiego dokładnie zachowania byś oczekiwał na stronie sedacja?
2. Twój podpis zbyt bardzo różni się od twojej nazwy użytkownika. Jest to niezalecane, zob. Pomoc:Podpis wikipedysty, ponieważ może u niektórych powodować dezorientację Masz możliwość zmiany podpisu lub zmiany nazwy użytkownika. WTM (dyskusja) 17:09, 14 lis 2022 (CET)[odpowiedz]
1. Główny link był czerwony. Dzięki za wyjaśnienie. Rzeczywiście są dwa linki. Ok, choć dla mnie wydaje się to trochę zbyt skomplikowane. Po co 2 linki skoro stary sposób działa ( en). To oczywiście moja subiektywna opinia, ale jak bym miał głosować który sposób wybrać to na pewno bym wybrał stary sposób. Czy była jakaś ankieta ? Czy są wskazania techniczne/bezpieczeństwa żeby wybrać link-interwiki ?
2. Lubię ten nick z powodu jego znaczenia. Jeśli klikniesz to widać nazwę użytkownika. Nie znalazłem takiego zalecenia :"Twój podpis zbyt bardzo różni się od twojej nazwy użytkownika" na tej stronie. Istnieją natomiast wskazania żeby nie używać prawdziwych ( ang. real name ) danych. --Soul surfer (dyskusja) 11:43, 15 lis 2022 (CET)[odpowiedz]
  • Słabo czytałeś: "W podpisie powinien znaleźć się login (nazwa) danego użytkownika". To zdanie jest tam pogrubione i raczej się rzuca w oczy. ~malarz pl PISZ 11:47, 15 lis 2022 (CET)[odpowiedz]
    Ok. Mam 2 odpowiedzi. 1. wystąpiłem o zmianę globalnego loginu ( Rename request pending approval ). 2. Zmieniłem podpis w preferencjach, korzystając ze standardowych narzędzi. Jeśli "W podpisie powinien znaleźć się login (nazwa) danego użytkownika" to dlaczego po co jest to narzędzie ? Dlaczego pozwala na podpis niezgodny z tą zasadą ? Soul surfer (dyskusja) 15:36, 15 lis 2022 (CET)[odpowiedz]
Ad 1: kiedy wstawi się niebieski link do wersji obcojęzycznej, to czytelnik nie wie że zostanie przeniesiony gdzieś poza polskojęzyczną Wikipedię (spodziewa się artykułu na ten temat po polsku), ani wikipedysta (potencjalnie zainteresowany napisaniem artykułu) nie zauważy łatwo, że linkowanej strony brakuje. Ponadto, kiedy dana strona powstanie, to istniejące linki nadal będą wskazywać na stronę w języku obcym a nie na polską wersję. Msz2001 (dyskusja) 14:49, 15 lis 2022 (CET)[odpowiedz]
Ad.1 Jak wyżej, plus:
Zasada działania jest w opisie {{Link-interwiki}}.
W skrócie: link-interwiki zamienia się w zwykły wikilink, gdy czerwonolinkowy artykuł zostanie utworzony na plwiki. (Czerwony link z tymczasowym wskazaniem artykułu w innej wersji językowej).
Prefix :en: w wikilinku zaś będzie na stałe (dopóki ktoś go nie zedytuje) wskazywać na enwiki. (Co by sugerowało, że z jakichś powodów ta wersja językowa jest ważniejsza niż ewentualne utworzenie hasła na plwiki.). MarMi wiki (dyskusja) 15:07, 15 lis 2022 (CET)[odpowiedz]
Ok. Dziękuję za informacje. Już rozumiem. Chodzi o informację o zmianie strony językowej. To ma sens. Czy link anglojęzyczny nie jest za mały ? Ja go nie zauważyłem. Czy jest możliwe sprawdzić czy takie linki ( te małe do obcojęzycznej strony) są używane ? czy ktoś w nie klika ? Soul surfer (dyskusja) 15:33, 15 lis 2022 (CET)[odpowiedz]

Losing style of 'gora' field in 'Szablon nawigacyjny'

If you use align template inside gora field in Szablon nawigacyjny you lose style of gora field, which probably is wrong. I've met this trying to add seasonal navigation. The background should stay purple, but it becomes white for << and >> links. 5-hydroxytryptamine (dyskusja) 18:48, 14 lis 2022 (CET)[odpowiedz]

Nie działa stary pasek narzędzi

Od kilku miesięcy nie działa stary pasek narzędzi, w związku z tym jestem pozbawiony narzędzi takich jak Sprzątanie kodu (WP:SK). Wygląd paska narzędzi. Pasek narzędzi działa na ENWP. Eurohunter (dyskusja) 17:06, 16 lis 2022 (CET)[odpowiedz]

Hm... Tamten pasek z 2005 roku to nie wiem czy jeszcze działa. Ale ten bardziej standardowy możesz włączyć w Specjalna:Preferencje#mw-prefsection-editing. Ten z „edytor wikitekstu 2010”. Nux (dyskusja) 17:28, 16 lis 2022 (CET)[odpowiedz]
@Eurohunter: działa zgodnie z intrukcjami, właśnie wypróbowałem. Peter Bowman (dyskusja) 17:35, 16 lis 2022 (CET)[odpowiedz]
@Nux @Nux To jest pasek z 2010, który mi nic nie daje i zabiera pół ekranu. Chcę pasek z 2005, na ENWP i innych działa. Eurohunter (dyskusja) 17:40, 16 lis 2022 (CET)[odpowiedz]
Przeklejam na wszelki wypadek: Upewnij się, że opcja „Włącz pasek narzędzi edycyjnych” na karcie „Edycja” jest wyłączona. Musisz mieć również wyłączony „Podgląd w czasie rzeczywistym”. Peter Bowman (dyskusja) 17:47, 16 lis 2022 (CET)[odpowiedz]
@Peter Bowman Gdzie znajduje się opcja "Podgląd w czasie rzeczywistym"? U mnie są tylko "Pokaż podgląd strony po rozpoczęciu edycji", "Pokazuj podgląd powyżej obszaru edycji" i "Pokazuj podgląd bez przeładowywania strony", a przynajmniej jedna opcja musi być aktywna, aby zapisać zmiany. Odznaczyłem „Włącz pasek narzędzi edycyjnych” na karcie „Edycja” i pasek z 2005 ładuje się tylko na sekundę i zamienia się na nowy pasek narzędzi. Eurohunter (dyskusja) 18:48, 16 lis 2022 (CET)[odpowiedz]
@Eurohunter: znajduje się w zakładce gadżetów, następny po "Aktywuj stary pasek edycji wikikodu (2006)" (tutaj omawianym). Swoją drogą dodam tu przypomnienie dla siebie samego lub ktokolwiek będzie pilnował, że wkrótce (phab:T313420) ów gadzet stanie się kolejną opcją w preferencjach. Peter Bowman (dyskusja) 19:44, 16 lis 2022 (CET)[odpowiedz]
@Peter Bowman Działa, dzięki. Eurohunter (dyskusja) 21:24, 16 lis 2022 (CET)[odpowiedz]

Zły zapis daty w przypisach

"16 listopada 2022" jest prawidłowym zapisem daty w języku polskim, więc komunikat "zły zapis daty dostępu" jest absurdalny. Eurohunter (dyskusja) 17:17, 16 lis 2022 (CET)[odpowiedz]

Wiele formatów dat jest poprawnych, ale nie wszystkie są przyjazne do maszynowego przetwarzania... A gdzie masz taki komunikat (w jakim polu, w jakim edytorze...)? Nux (dyskusja) 17:25, 16 lis 2022 (CET)[odpowiedz]
@Nux Błąd wyświetla się w przypisach zarówno w podglądzie jak i zapisanej wersji. Komunikat wyświetla się na końcu przypisu i co ciekawe zgłasza tylko "daty dostępu" pomijając parametr daty i daty archiwizacji. "nie wszystkie są przyjazne do maszynowego przetwarzania" - na ENWP z powodzeniem używa się "16 November 2022", więc raczej nie ma tutaj problemu. Eurohunter (dyskusja) 17:43, 16 lis 2022 (CET)[odpowiedz]
A chodzi o artykuł w przestrzeni głównej czy jakiś poza nią? Konkretne przykłady? Screeny? tufor (dyskusja) 17:53, 16 lis 2022 (CET)[odpowiedz]
  • Od początku istnienia2014 w dokumentacji szablonu {{cytuj stronę}} siedzi w nim informacja, że data dostępu ma być podawana w formacie RRRR-MM-DD. I tak w większości przypadków była i jest podawana. Pozostałe wywołania stanowiły około 5% (ale to i tak były grube tysiące) i po dyskusji w barze większość z nich sprzątnąłem botem w imię spójności wyglądu przypisów. To co zostało ląduje w kategorii technicznej Szablon cytowania – zły zapis daty dostępu. Stare szablony nie ingerują w format zapisu tego parametru. To co jest podane jest wyświetlane. Aby zwrócić na to uwagę dodałem sprawdzanie, czy podawana data pasuje do formatu wskazanego w jego dokumentacji. Paweł Ziemian (dyskusja) 17:56, 16 lis 2022 (CET)[odpowiedz]
    • @Paweł Ziemian Kto w ogóle zapisuje daty w formacie RRRR-MM-DD? Amerykanie? 10-10-2010 to powinno być minimum. "To co jest podane jest wyświetlane" - dlaczego nie ma tego w szablonie cytuj stronę? Kto będzie zmieniał całą datę w kilkudziesięciu przypisach podczas tłumaczenia artykułu? Eurohunter (dyskusja) 18:53, 16 lis 2022 (CET)[odpowiedz]
      • Format RRRR-MM-DD jest praktycznie jedynym formatem, który łatwo przekształcić w inny z pomocą funkcji #time. Ponadto jest to zapis zgodny z ISO. Trudno go nie zrozumieć. Zapis odwrotny już nie jest jednoznaczny. Zwłaszcza, że często widywałem angielską notację M/D/Y. Jeśli D w tym zapisie nie przekroczy 12 to nie wiadomo o co chodzi. To znaczy myślimy, że wiemy o co chodzi ale możemy być w błędzie. W dodatku separator / bywa w tym zapisie zamieniony na kropkę, myślnik lub pauzę. Paweł Ziemian (dyskusja) 19:30, 16 lis 2022 (CET)[odpowiedz]
        • @Paweł Ziemian MM-DD-YYYY jest używany w Stanach Zjednoczonych, nie Wielkiej Brytanii i to owszem jest mylące, ale ten problem będzie istniał niezależnie od formatu daty używanego w PLWP. To co jest obecnie na PLWP - oczywiście nie trudno jest to zrozumieć, ale według mnie to jest zapisywanie daty "od tytułu" i zawsze w sytuacji dodawania daty mam myśl, że muszę dodać datę od tyłu... Taki format daty kojarzy mi się raczej z niechlujstwem tak jak pisanie "dnia 15 marca 2022". Na dodatek w podpisach używamy "normalnego" formatu daty DD-MM-YYYY. Eurohunter (dyskusja) 21:34, 16 lis 2022 (CET)[odpowiedz]
          Format y-m-d był przez wiele lat domyślnym formatem w Windows. Jeśli dobrze pamiętam to od Windows 95 aż do Windows 8 (wiem, bo w bibliotekach w Polsce taki format jest normą). Jest to też format ISO (norma międzynarodowa) i polska norma (PN). Nie wiem o co chcesz tu kruszyć kopię. Jeśli wpisujesz datę ręcznie to format ISO jest łatwiejszy do wpisania. Jeśli używasz do przypisów automatu, to on zawsze używa formatu ISO. Nux (dyskusja) 21:57, 16 lis 2022 (CET)[odpowiedz]
          Sprawdziłem. Nawet jeszcze w pierwszych, polskich, wersjach Windows 10 format ISO był domyślnym formatem daty. Tak czy inaczej na pewno miałeś taką datę wpisaną przy zegarku na większości Windowsów/komputerów z których korzystałeś. Minęło ledwie 6 lat odkąd d.m.y stał się domyślny w Windowsach. Nux (dyskusja) 22:21, 16 lis 2022 (CET)[odpowiedz]
          @Nux W bibliotekach czy ogólnie w pismach urzędniczych równie często błędnie jest pisane "dnia 4 marca 2020", więc na to bym się nie powoływał. Co ciekawe są w tym bardzo uparci... Co do Windowsa masz rację, ale jest tam wiele niespójności nawet w Win 11. Może tłumaczący mieli takie same podejście jak w urzędach... Idąc dalej ile razy w mediach słyszysz z ust dziennikarzy i innych osób "tą grę" albo źle wymawianą nazwę roku po 2000 (od 2001)? Eurohunter (dyskusja) 23:02, 16 lis 2022 (CET)[odpowiedz]
          Tak się składa, że robię oprogramowanie dla polskich bibliotek i mamy większość rynku. I wiem jakiego formatu używają biblioteki w swoim oprogramowaniu ;) Nux (dyskusja) 23:08, 16 lis 2022 (CET)[odpowiedz]
  • @Paweł Ziemian, @Eurohunter, @Nux, @Muzyk98, @Beno: A tak przy okazji tej dyskusji, może zmienilibyśmy format wyświetlanej daty dostępu w szablonie {{cytuj}} z [dostęp RRRR-MM-DD] na zwykły polski, np. [dostęp DD.MM.RRRR] lub [dostęp DD MIESIĄCA RRRR]? Nie widzę uzasadnienia do wyświetlania daty w formacie ISO, zamiast w formacie zgodnym z polskimi normami językowymi. Michał Sobkowski dyskusja 22:54, 16 lis 2022 (CET)[odpowiedz]
I jeszcze tu: https://sjp.pwn.pl/poradnia/haslo/zapis-daty;10340.html Michał Sobkowski dyskusja 23:29, 16 lis 2022 (CET)[odpowiedz]
  • Zacznijmy może od szablonu Cytuj, który najpewniej i tak stopniowo wyprze stare szablony specjalistyczne. Z tego co widzę, to szablon Cytuj świetnie sobie radzi z różnymi formatami daty, także z tymi odmiennymi od ISO:
  • data = 2022-11-11 | data dostępu = 2022-11-11: Test [online], 11 listopada 2022 [dostęp 2022-11-11] [zarchiwizowane z adresu 2013-07-17].
  • data = 11.11.2022 | data dostępu = 11.11.2022: Test [online], 11 listopada 2022 [dostęp 2022-11-11] [zarchiwizowane z adresu 2013-07-17].
  • data = 11 listopada 2022 | data dostępu = 11 listopada 2022: Test [online], 11 listopada 2022 [dostęp 2022-11-11] [zarchiwizowane z adresu 2013-07-17].
Chodzi tylko o to, żeby zmienić format wyświetlania daty dostępu (i archiwizacji). Interpretację danych wejściowych szablon już teraz robi (i daje radę!) dla różnych formatów wejściowych. Jeśli po zmianie wynik miałby być nieoczekiwany, to przecież i obecnie jest nieoczekiwany. Nic się pod tym względem by nie zmieniło. Michał Sobkowski dyskusja 23:29, 16 lis 2022 (CET)[odpowiedz]
Przede wszystkim rrrr-mm-dd jest również polskim formatem daty. Jest to nawet podane w linku poradni PWN, który wrzuciłeś ;). Ale format ISO można stosunkowo łatwo skonwertować. Mam wątpliwości czy warto, ale można. Jeśli już to raczej z nawą miesiąca chyba. Nux (dyskusja) 23:40, 16 lis 2022 (CET)[odpowiedz]
Jest polskim formatem daty, ale dla celów "technicznych", nie w tekstach do czytania. Muzyk98 (dyskusja) 23:42, 16 lis 2022 (CET)[odpowiedz]
Przez ponad 20 lat ISO było używane standardowo również do wyświetlania dat w ok. 90% komputerów w Polsce... W każdym razie tak jak wspomniałem i tak jak pisał Paweł można skonwertować tą datę, ale powinna być wprowadzona do danych w formacie ISO. Nawet przeciwnicy tego formatu przyznają przecież, że jest właśnie do zastosowań technicznych ;-). Osobiście nie podzielam opinii, że ISO trudno się czyta. Mi się czyta bardzo dobrze - na początku są najważniejsze informacje. Dla starych przypisów liczy się dla mnie z którego roku były te przypisy, a nie z którego miesiąca czy tym bardziej dnia... No, ale to jest dyskusja typu de gustibus...
Data powinna być zapisana jako ISO (ze względów technicznych). Powinna być wprowadzana przez kalendarz (tego VisualEditor jeszcze niestety nie oferuje, ale to raczej kwestia czasu). Data powinna być ostatecznie wyświetlana zgodnie z ustawieniami danego użytkownika (tego nie mamy, ale jeśli zapis będzie jednolity, to będzie się dało to zrobić). Nux (dyskusja) 00:30, 17 lis 2022 (CET)[odpowiedz]
@Nux Format RRRR-MM-DD powinien być rozpoznawany, ale format DD-MIESIĄCA-YYYY również powinien być rozpoznawany, a oba powinny być wyświetlane jako DD-MIESIĄCA-YYYY, ewentualnie jak ktoś chce inaczej to powinien mieć opcję wyboru w ustawieniach. PLWP powinna rozpoznawać nawet całe przypisy zapisane w języku angielskim i wyświetlać je w języku polskim, czyli tak jak jest w innych wersjach Wikipedii. Nie pamiętam dokładnie, ale chyba na FRWP jak wstawisz przypis z ENWP to FRWP go rozpozna i wyświetli normalnie w języku francuskim (rozpoznaje angielski kod). Eurohunter (dyskusja) 20:19, 17 lis 2022 (CET)[odpowiedz]
@Eurohunter w sumie to {{cytuj}} łyka różne daty, tak jak byś tego oczekiwał, a zestaw jego podstawowych parametrów jest identyczny jak dla {{cytuj stronę}}. Z czego wynika Twój sentyment do starego szablonu? Paweł Ziemian (dyskusja) 22:50, 17 lis 2022 (CET)[odpowiedz]
Nie wiem, być może to dziwne, ale osobiście preferuję te stare szablony, przynajmniej pod względem kosmetycznym. Estetycznie „Cytuj” wydaje się dość przekombinowany, zwłaszcza gdy w grę wchodzą linki do archiwum. Po prostu jest w nim za dużo różnie poformatowanych elementów – być może chodzi o ich kolejność, kursywę użytą w tym, a nie innym miejscu... (w każdy razie coś gryzie w oczy, trudno mi określić co dokładnie). A tak nawiasem mówiąc, w „Cytuj” brakuje parametru „adres rozdziału”, który z kolei jest zawarty w „Cytuj książkę” (i w tym drugim nie potrzeba robić żadnych akrobacji z parametrem rozdział). Na enwiki wszystkie szablony prezentują się schludnie i mają wszystkie potrzebne parametry, a tutaj właśnie czasem czegoś brakuje lub coś subtelnie zgrzyta. No i zdarza się, w jednym haśle występują różne szablony z różnymi formatami (co widać np. w datach) -- czy jest jakiś powód, dla którego nie ujednolicono chociaż wyglądu omawianych szablonów? 2A00:F41:385A:EB5A:F0B8:3320:6B05:34D7 (dyskusja) 00:12, 18 lis 2022 (CET)[odpowiedz]
@Paweł Ziemian Już zapomniałem, że był nowy szablon. Coś w nim było nie tak, ale już nie pamiętam co. W Szablon:Cytuj tylko data jest wyświetlana jako 5 lipca 2019, natomiast data dostępu jest wyświetlana jako "2022-01-24". Eurohunter (dyskusja) 16:50, 18 lis 2022 (CET)[odpowiedz]
Jakże niezwykle merytoryczny komentarz... coś było nie tak, coś zgrzyta, czegoś brakuje, coś gryzie w oczy. Z pewnością te rzeczy zostaną niezwłocznie poprawione. O, już coś zostało poprawione. Wostr (dyskusja) 18:45, 18 lis 2022 (CET)[odpowiedz]
No, w „Cytuj” brakuje parametru „adres rozdziału”. A co do tego, że coś gryzie, to wydaje mi się, że szablon nadużywa formatowania (przykładowo: kursywa zarówno w tytule rozdziału, jak i w tyle książki; kursywa w tytule strony internetowej (który jednocześnie wyświetla się niebiesko, więc jest dostatecznie wyróżniony). Dlatego preferuję „Cytuj książkę” i „Cytuj stronę”, które używam za prostsze, a zarazem bardziej estetyczne. 2A00:F41:3890:B401:2C42:441E:9013:34CD (dyskusja) 18:52, 19 lis 2022 (CET)[odpowiedz]
Zanim powstał nowy szablon były uwagi, że pozostałe za bardzo się od siebie różnią. Nowy powstawał w wyniku długich dyskusji przy założeniu, że będzie podobny do pozostałych. Stąd między innymi takie formatowanie dat w zależności od jej kontekstu. Był też głos, że nowi nie potrafią poprawnie wypełniać szablony cytowania, bo mają za dużo parametrów i nie wiedzą co cytują. Dlatego w nowym nie ma wszystkiego, lecz tylko to co najważniejsze i najczęściej używane. Paweł Ziemian (dyskusja) 18:41, 18 lis 2022 (CET)[odpowiedz]
  • Szablon {{cytuj stronę}} jest znacznie bardziej popularny więc często będzie występował obok {{cytuj}}. Będzie ładniej jeśli różne szablony będą stosowały takie same formaty daty na wyjściu. Opracowuję w brudnopisie odpowiedni kod dla starych szablonów. Paweł Ziemian (dyskusja) 23:37, 16 lis 2022 (CET)[odpowiedz]
    • Przypomniałem sobie jeszcze, że #time ma ograniczenia ilościowe na przetwarzanie danych. Limit to 6000 znaków. Patrząc na daty takie jak 31 października 2022 to możemy tę funkcję wywołać 300 razy. Dla zapisu ISO liczba ta wzrośnie do 600. Istnieją jednak artykuły, w których przypisów jest więcej. To już mi pachnie błędami parsera, które nawet teraz się zdarzają w różnych większych artykułach. W {{cytuj}} rozwiązałem ten problem w ten sposób, że nie korzystam z systemowych funkcji obsługi dat lecz napisałem własne, które są wolne od tych ograniczeń. Paweł Ziemian (dyskusja) 22:50, 17 lis 2022 (CET)[odpowiedz]
      • Na ENWP nie ma takich problemów? Tam bez problemu dodasz 700 przypisów z datami "31 October 2022" w czterech parametrach. Eurohunter (dyskusja) 16:44, 18 lis 2022 (CET)[odpowiedz]
        • Pewnie nie stosują #time w przypisach. Wyświetlają daty tak jak są podawane. Nie zaglądam w kod ich przypisów. U nas też pewnie nie trzeba by z tego korzystać, gdyby do szablonów podawać każdą datę podzieloną na 3 składniki. Jednak wygoda, że data to jedna data kosztuje. Paweł Ziemian (dyskusja) 18:41, 18 lis 2022 (CET)[odpowiedz]
Nie spodziewałem się, że ktoś może chcieć używać innego formatu daty niż ISO (tym bardziej w zastosowaniu czysto technicznym jakim jest kod szablonu) i że może z tego wyniknąć tak duża dyskusja. Moim zdaniem data w szablonach cytowania powinna być zawsze wpisana w formacie ISO (po coś te standardy są), tym bardziej, że w dokumentacji każdego szablonu jest dokładnie opisane jakiego formatu daty ten szablon oczekuje. A to, jak się będzie ta data wyświetlać, może zależeć od ustawień użytkownika.
Zalety formatu RRRR-MM-DD: spójność i brak problemów z interpretacją, w porównaniu ze słownym zapisem miesiąca - brak potrzeby tłumaczenia z/na inne języki i dużo mniejsza podatność na literówki.
Takie pytanie (eksperyment myślowy) do osób uważających zapis RRRR-MM-DD za pisany od końca: Dlaczego zapisujecie godziny od końca, zamiast zacząć od sekund, potem podać minuty, a godzinę na końcu? ;)
Szablon:Cytuj_odcinek - tutaj tylko w jednym miejscu jest podany format daty dostępu inny niż RRRR-MM-DD (zapewne przeoczenie)
Szablon:Cytuj_pismo tutaj data dostępu i data w dokumentacji ma format ISO, ale zakresy dat już podane są z nazwą miesiąca w przykładach: 1-2 grudnia 2018 r. Zakresy dat też właściwie można by zapisywać w ISO np. 2018-12-01 - 2018-12-02 i wyświetlać zgodnie z preferencjami użytkownika, ale to już jest bardziej skomplikowane.
A poza tym gadżet refTools (przycisk Cytuj) sam dodaje dzisiejszą datę dostępu w odpowiednim formacie po wybraniu opcji Strona WWW. Ololuki (dyskusja) 18:39, 19 lis 2022 (CET)[odpowiedz]

Wychwytywanie nieprawidłowych parametrów w Commons

Czy dałoby się jakoś wychwytywać i umieszczać w jakies kategorii sytuacje gdy w parametrze "commons=" są takie rzeczy? Przypuszczam że akurat ten parametr może być wypełniony prawidłowo tylko w taki sposób, który dałoby się opisać za pomoca regexa. PMG (dyskusja) 18:38, 18 lis 2022 (CET)[odpowiedz]

@PMG: Takie wyszukiwanie zwraca błąd, natomiast to nic. XaxeLoled AmA 14:31, 19 lis 2022 (CET)[odpowiedz]
@XaxeLoled: Do not run a bare insource:/regexp/ search. It will probably timeout after 20 seconds anyway, while blocking the queries of responsible users. (mw:Help:CirrusSearch#Regular expression searches) Peter Bowman (dyskusja) 15:35, 19 lis 2022 (CET)[odpowiedz]

Od jakiegoś czasu kliknięcie w link "anuluj edycję" prowadzi to wycofania nie ostatniej zmiany (spośród porównywanych wersji hasła), lecz wszystkich porównywanych zmian (choć mowa o jednej edycji). Bardzo proszę o szybką naprawę błędu, bo łatwo się naciąć. 2A00:F41:38E0:B85C:A93D:9497:279A:D8CD (dyskusja) 13:53, 23 lis 2022 (CET)[odpowiedz]

Jeżeli otwierasz podgląd zmian obejmujący więcej niż jedną edycję, przycisk "anuluj edycję", mimo swojej nazwy, anuluje wszystkie. O ile się orientuję, tak było od dawna/zawsze. Peter Bowman (dyskusja) 13:55, 23 lis 2022 (CET)[odpowiedz]
Szczerze mówiąc, to pierwszy raz się z tym spotykam. Z pewnością jest to mylące - powinno być "anuluj porównywane edycje" czy coś w ten deseń. Co ciekawe, kiedy dochodzi do zaproponowania takiej edycji (anulującej więcej niż jedną wersję), nie jest proponowany opis zmian typu "anulowanie wersji X, Y i Z". 2A00:F41:38E0:B85C:A93D:9497:279A:D8CD (dyskusja) 13:57, 23 lis 2022 (CET)[odpowiedz]

Zmiana struktury HTML nagłówków na stronach dyskusji

W najbliższym czasie zamierzam wprowadzić na plwiki zmianę konfiguracji, która spowoduje zmiany w strukturze HTML nagłówków na stronach dyskusji. Obecnie dodatkowe metadane (np. liczba komentarzy – widoczne dla osób, które włączyły funkcję eksperymentalną „Narzędzia dyskusji”, lub które można zobaczyć tutaj: [6]) wstawiane są wewnątrz znacznika nagłówka <h2>, co utrudnia nawigację edytorom korzystającym z czytników ekranowych. Po zmianie nagłówki otoczone zostaną nowym znacznikiem <div>, wewnątrz którego wstawiane będą również metadane.

Nie powinno mieć to żadnego wpływu na działanie stron dyskusji, ale może okazać się, że jakieś gadżety itp. nie będą kompatybilne z tą zmianą, więc ogłaszam ją wcześniej na wszelki wypadek. Zamierzam wprowadzić zmiany w najbliższy wtorek, 29 listopada. Naprawię potem ewentualne problemy z gadżetami, jeśli tylko jakieś zauważę lub jeśli ktoś je zgłosi.

W przyszłości te same zmiany będą wprowadzone również na wszystkich innych projektach. (Powiązany bug na Phabricatorze: T314714.) Matma Rex dyskusja 19:15, 24 lis 2022 (CET)[odpowiedz]

Zrobione. Wstępnie nie widzę żadnych problemów. Matma Rex dyskusja 22:57, 29 lis 2022 (CET)[odpowiedz]

Brak italiki dla oznaczeń języków alfabetów niełacińskich

Czy dobrze rozumiem, że brak italiki w szablonach poszczególnych języków opakowujących szablon {{w języku}} w przypadku języków nie posługujących się alfabetem łacińskim, jest świadomym wyborem i jest spodziewany? Por. niem. Beitrag wobec ukr. nesamovýtyj. – smyru 11:12, 25 lis 2022 (CET)[odpowiedz]

MalarzBOT Archiwum psuje rok w szablonie Brak podpisu

Z jakiegoś powodu bot robi coś z rokiem podanym w parametrze {{Brak podpisu}} (data przekopiowana z historii) (diff, ostatnie zmiany na dole). Po usunięciu pierwszej spacji z parametru bp, znowu jest on poprawnie parsowany (diff). MarMi wiki (dyskusja) 16:28, 25 lis 2022 (CET)[odpowiedz]

@MarMi wiki A nie prościej byłoby skontaktować się najpierw z operatorem @malarz pl, albo go pingnąć? Nad czym tu twoim zdaniem ma radzić społeczność? Mathieu Mars (dyskusja) 17:07, 25 lis 2022 (CET)[odpowiedz]
Problem może leżeć po jednej ze stron, albo po obu (bot/szablon). No chyba że za oba obszary odpowiada jedna osoba.
To chyba nie jest znowu aż tak krytyczny problem, żeby kogoś pingować.
Zawsze jest też jakaś szansa, że ktoś inny spotkał się z czymś podobnym, albo wie o co chodzi. MarMi wiki (dyskusja) 18:47, 25 lis 2022 (CET)[odpowiedz]
Wygląda na to, że po skopiowaniu (i wklejeniu) daty z historii rok zakończony jest znakiem U+200E, który jest usuwany przy archiwizacji (z części, która nie jest przenoszona do archiwum).
Jeśli tak ma być, to problem leży po stronie szablonu (a w zasadzie modułu - początkowa spacja nie jest usuwana? Brak takiego przypadku w regexach?). MarMi wiki (dyskusja) 19:26, 25 lis 2022 (CET)[odpowiedz]
WP:SK robi dokładnie tę samą zmianę (diff), @Paweł Ziemian więc raczej szablon do poprawy. ~malarz pl PISZ 20:20, 25 lis 2022 (CET)[odpowiedz]

Załatwione ~malarz pl PISZ 22:35, 25 lis 2022 (CET)[odpowiedz]

Ostrzeżenie o licencji przy zapisie

Zauważyłem pewną niespójnośc komunikatów o wymaganiach licencyjnych przy zapisie edycji.

Gdy używa się narzędzia Odpowiedz albo Dodaj temat (tak jak w tym momencie, gdy to piszę), ostrzeżenie brzmi tak:

Klikając „Odpowiedz”, zgadzasz się na nasze warunki użytkowania oraz wyrażasz nieodwołalną zgodę na udostępnianie twojego wkładu na warunkach licencji CC BY-SA 3.0 oraz GFDL.

Przy normalnej edycji ostrzeżenie jest bardziej rozbudowane:

Zapisując zmiany, wyrażasz nieodwołalną zgodę na udostępnianie Twojego wkładu na licencjach CC-BY-SA 3.0 i GFDL oraz na wykorzystanie go w dowolnej formie pod warunkiem podania przynajmniej hiperłącza lub adresu URL do strony, na której powstała treść. Treść ta musi być dostępna na tych zasadach, jeśli nie jest wynikiem Twojej samodzielnej pracy. Zobacz szczegółowe informacje o warunkach korzystania.

Sądzę, że oba warianty powinny być bardziej rozudowane, żeby nikt sobie nie tworzył teorii opartych na ich różnicy. Gżdacz (dyskusja) 11:58, 28 lis 2022 (CET)[odpowiedz]

Jeszcze tylko dla uzupełnienia podam formułkę, która jest wyświetlana w wersji mobilnej (inna od powyższych, choćby brakuje w niej słowa nieodwołalną):

Zapisując zmiany, zgadzasz się na Warunki użytkowania oraz wyrażasz zgodę na udostępnianie Twojego wkładu na licencjach CC BY-SA 3.0 oraz GFDL.

Msz2001 (dyskusja) 16:14, 28 lis 2022 (CET)[odpowiedz]
Gdyby ktoś chciał wyedytować: te trzy komunikaty zdefiniowane są na stronach MediaWiki:wikimedia-discussiontools-replywidget-terms-click, MediaWiki:wikimedia-copyrightwarning, MediaWiki:mobile-frontend-editor-licensing-with-terms. (TranslateWiki: [8] [9] [10])
Ja proponowałbym raczej skrócić niż rozbudować ;) Zwłaszcza ten drugi (MediaWiki:wikimedia-copyrightwarning) zawiera fragmenty, których nie ma w ogóle w angielskojęzycznym oryginale (MediaWiki:wikimedia-copyrightwarning/en). Nasza wersja różni się przy tym od tłumaczenia na TranslateWiki.
Swoją drogą, w oryginale (MediaWiki:wikimedia-discussiontools-replywidget-terms-click/en, MediaWiki:wikimedia-copyrightwarning/en, MediaWiki:mobile-frontend-editor-licensing-with-terms/en) również każdy komunikat sformułowany jest nieco inaczej. Nie ma to chyba żadnego praktycznego znaczenia. Ważne, aby był link do warunków użytkowania, gdzie te zasady są szczegółowo opisane. Matma Rex dyskusja 23:18, 28 lis 2022 (CET)[odpowiedz]
  • A tu się nie zgadzam. Kto czyta warunki? Nowicjuszy odsyłam właśnie do informacji pokazującej się przy zapisie i to ona powinna zawierać najważniejsze nakazy i zakazy. Jest też różnica między nami a enwiki: oni mają 'fair use', a my mamy tylko prawo cytatu i nie akceptujemy treści nim objętych. Właśnie chodzi mi o najdłuższy wariant, który wyraźnie wskazuje, że cała treść na być na wolnej licencji, a nie tylko to, co od siebie napisał nasz autor. To jest ten zwrot, który wyklucza cytaty. Gżdacz (dyskusja) 23:39, 28 lis 2022 (CET)[odpowiedz]
    Myślę, że lepiej jednak krótko. Lepsza krótka wiadomość, którą przeczyta powiedzmy połowa, niż długa, którą przeczyta może 5%. Ta obecna wiadomość jest krótka i na temat. Jak ktoś zna licencję, to tylko spojrzy i widzi która jest tu używana. Nux (dyskusja) 11:40, 30 lis 2022 (CET)[odpowiedz]
    W sumie to można by dodać link do wikietykiety ewentualnie. Może więcej osób będzie znało, bo zauważyłem, że wiedza o tym trochę zanika ;-) Nux (dyskusja) 11:43, 30 lis 2022 (CET)[odpowiedz]

Wiadomości techniczne: 2022-48

MediaWiki message delivery 21:02, 28 lis 2022 (CET)[odpowiedz]

Dla bota: Załatwione Msz2001 (dyskusja) 21:56, 28 lis 2022 (CET)[odpowiedz]