Wikipedia:Kawiarenka/Kwestie techniczne

Dla czytelników

Pierwsze kroki

Portal wikipedystów

Zasady

Współpraca

Społeczność

Szablony

Pomoc

Wikipedyści

Komunikacja

Konflikty

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.

• Błędy w oprogramowaniu MediaWiki należy zgłaszać w serwisie Phabricator,
• Problemy z infoboksami należy zgłaszać na stronę Dyskusja wikiprojektu:Infoboksy.

Obserwuj stolik • Archiwum stolika • Wszystkie stoliki • Skróty: WP:KT, WP:BAR:KT, WP:TECH

Nowy wątek

Oznaczanie fragmentów dezaktualizujących się

W części artykułów obecne są informacje, o których wiadomo już podczas umieszczania, że będą wymagać aktualizacji za określony czas. Chodzi mi przykładowo o informacje dot. tego, że dany lek do 2016 roku nie został zarejestrowany w Polsce, dana substancja psychotropowa nie znajduje się (stan na 2016) w wykazie substancji psychotropowych bądź sprawa porzuconej broni chemicznej pozostaje (2013) wciąż nierozwiązana. Wiele z takich przypadków jest możliwa do szybkiego zaktualizowania, problemem jest jednak to, że nie mam żadnego sposobu, aby w interesującym mnie drzewie kategorii wyszukać takie artykuły. Może dałoby radę stworzyć szablon, działający podobnie do {{fakt}}, za pomocą którego można byłoby zaznaczyć taki fragment tekstu z podaniem odpowiedniego roku, co powodowałoby dodanie do odpowiedniej kategorii, a jakiś gadżet/css sprawiałby, że chętni widzieliby taki fragment w jakiś sposób zaznaczony/podkreślony/cokolwiek? Raczej pomijalne byłyby w tym przypadku dane statystyczne np. GUSu w każdym artykule o miejscowości itp., o których z góry wiadomo, że i tak wymagają okresowego uaktualnienia. Czy może jednak takie rozwiązanie jest słabe i ktoś ma lepszy pomysł? Wostr (dyskusja) 18:08, 22 lip 2016 (CEST)

Jeden problem jaki widzę to komplikowanie kodu i jest to IMO dość spory problem. Część tekstu byłaby traktowana jako szablon, a wiesz jak w VE się je edytuje (podpowiem: bardzo źle). Zastanowiłem się pokrótce nad alternatywami i wymodziłem taką tabelkę:

HTML	Wikikod	Jak wygląda (z przykładowymi stylami)	Plusy/minusy
<span class="dezaktualizujace_sie">Informacja podatna na dezaktualizację</span>	{{zdez|Informacja podatna na dezaktualizację}}	Informacja podatna na dezaktualizację	+ wyraźnie zaznaczone, widoczne, obejmuje tekst + jeden szablon - komplikacja kodu, źle się edytuje w VE, tekst jest przekazywany jako parametr
<span class="dezaktualizujace_sie">Informacja podatna na dezaktualizację</span>	{{zdez-start}}Informacja podatna na dezaktualizację{{zdez-stop}}	Informacja podatna na dezaktualizację	+ wyraźnie zaznaczone, widoczne, obejmuje tekst - aż dwa szablony; należy pamiętać o szablonie zamykającym
<div class="dezaktualizujace_sie"></div>Informacja podatna na dezaktualizację	{{zdez}}Informacja podatna na dezaktualizację	Informacja podatna na dezaktualizację	+ jeden szablon +/- nie aż tak bardzo widoczne, ale wciąż widoczne - nie obejmuje tekstu

Pozdrawiam, tufor (dyskusja) 19:52, 22 lip 2016 (CEST)

O, o. Właśnie. Jeszcze @Sławek Borewicz podrzucił, że na en.wiki jest en:Template:Update_after (i en:Template:Update_inline). Wiem natomiast jak niektórzy reagują na jakiekolwiek próby większego szablonowania artykułów, ale... przecież {{fakt}} jest powszechnie w użyciu, a w nim również tekst przekazywany jest jako parametr (przynajmniej w założeniach). Rozumiem, że jakiekolwiek wyróżnienia mogłyby być domyślnie niewidoczne dla każdego? Wostr (dyskusja) 21:15, 22 lip 2016 (CEST)

@Wostr: tak, wyróżnienia domyślnie byłyby niewidoczne. Ja też nie jestem za zbytnim szablonowaniem artykułów, osobiście byłbym za trzecią opcją. Jednak i tak musiałbym zobaczyć jak działałoby to w praktyce. tufor (dyskusja) 23:52, 23 lip 2016 (CEST)

• Przypominam o Pomoc:Ponadczasowość. Marek Mazurkiewicz (dyskusja) 00:18, 23 lip 2016 (CEST)
  • Bez związku. W każdym z podanych przeze mnie przykładów nie jest możliwe (znaczy możliwe to jest wszystko, ale to totalnie bez sensu), aby redagować tekst w taki sposób, aby zachować wszystkie informacje. Jeśli lek zostanie zarejestrowany w Polsce w 2017 roku, to nie będziemy pisać, że w latach XXXX-XXXX nie był zarejestrowany w Polsce, a został zarejestrowany w 2017 roku, bo wystarczy zmienić Do 2016 roku lek nie był zarejestrowany w Polsce na Lek został zarejestrowany w Polsce w 2017 roku. Jest multum informacji, które niestety lub stety wymagają i będą wymagać okresowej aktualizacji bez pozostawiania w artykułach wcześniejszych danych. Wostr (dyskusja) 00:25, 23 lip 2016 (CEST) PS Ale zakładając wątek zastanawiałem się jak szybko podasz tutaj ten link ;) Wostr (dyskusja) 00:26, 23 lip 2016 (CEST)
    • Związek jest jak najbardziej. Dlaczego należy pisać o tym że coś nie zostało zarejestrowane? Jeśli już to należało by pisać o tym że podjęto próbę rejestracji lub że rejestracji odmówiono. Dlaczego tak należy robić jest wyjaśnione na linkowanej stronie pomocy. W skrócie - encyklopedyczność informacji nie może być tymczasowa. Marek Mazurkiewicz (dyskusja) 03:18, 23 lip 2016 (CEST)
      • Ale informacja, że nie został zarejestrowany jest ważna. I nie da się napisać, że podjęto próbę bądź odmówiono, bo tak nie jest. Lek po prostu nie został zarejestrowany w Polsce, a w innych krajach tak. Zresztą nie dotyczy to tylko leków. Jest wiele substancji psychotropowych i podobnych, które znajdują się w wykazach substancji niedozwolonych innych państw, a w Polsce nie. W końcu: jest też wiele sytuacji, w których należy zaznaczyć, że coś nie zostało zrobione/rozwiązane/itd. Ale da się to zrobić wyłącznie podając datę/rok, dla którego to zdanie jest prawdziwe, np. (stan na 2016). Ponadto: mylisz się, encyklopedyczność informacji może być jak najbardziej tymczasowa, encyklopedyczność dotyczy wyłącznie danego zagadnienia, a nie całej treści opisującej to zagadnienie. Wspominana strona pomocy (a nie nawet zalecenie!) była zresztą dyskutowana w kontekście zupełnie innych problemów i nie pojawiła się tam nawet wzmianka o tym, o czym teraz dyskutujemy. A na koniec: na tej stronie pomocy na pierwszy rzut oka już jest jeden feler: W 2010 rzecznik prasowy ministerstwa poinformował, że budowa ma się ukończyć w 2012.”) Tak skonstruowana informacja nie będzie wymagała usunięcia, lecz tylko uzupełnienia – ta informacja jak najbardziej może wymagać usunięcia, jeśli tylko budowa zakończy się w terminie, bo wtedy info o tym, że jakiś rzecznik coś tam gadał stanie się zupełnie nieistotna. Wostr (dyskusja) 10:19, 23 lip 2016 (CEST)
• Inny przypadek, gdy coś się dezaktualizuje: w artykule bitwa nad rzeką Tollense jest opisany stań badań na stanowisku archeologicznym: ile i czego dotąd znaleziono. To trzeba uaktualniać i oczywiście nie ma sensu utrzymywać informacji historycznej: do 2015 roku znaleziono szczątki 130 ludzi i 5 koni, do 2016 (powiedzmy) 177 ludzi i 7 koni, itd. Pisać należy ponadczasowo, ale uaktualniac też, przy czym przy aktualizacji stara informacja z zasady wyleci. Gżdacz (dyskusja) 00:25, 25 lip 2016 (CEST)

• W takim wypadku dodałbym tabelę z kolumnami: rok || znalezione szczątki. Nadal uważam że jeżeli jakaś informacja ma zostać skasowana w aktualizacji to znaczy że nigdy nie była dość istotna by ją zapisywać co jest równoważne z tym, że jeżeli słuszne było zapisać to nie należy kasować przy okazji aktualizacji. Marek Mazurkiewicz (dyskusja) 02:25, 18 wrz 2016 (CEST)

• @Marek Mazurkiewicz @Gżdacz @Wostr @tufor Pozwolę włączyć się do dyskusji z głosem popracia dla inicjatywy.
  Zgadzam się jak najbardziej z postulatem ponadczasowości. Tak powinniśmy pisać. Ale pragmatycznie nie zawsze się da. Mój przykład: Erasmus+. Program skończy się w 2020 roku. Według mojej najlepszej wiedzy nie da się tak sformuować jego opisu w artykule, aby był uniwersalnie poprawny zarówno w okresie obowiązywania programu jak i po jego zakończeniu. Aby to osiągnąć należałoby wszystkie zdania zamienić na równoważniki zdań typu „Całkowity budżet to…”, „Narodowa Agencja programu to…”. Przy dłuższych podobnych opisach (zakładam, że znaleźlibyśmy inne przykłady) takie równoważniki brzmią moim zdaniem co najmniej niezręcznie.
  Natomiast co do samego znacznika: jestem zdania, że szablon powinien mieć wymagany parametr – datę dezaktualizacji. Do tej daty nie powinien ujawniać się czytelnikom Wikipedii, a po jej przekroczeniu wyświetlać analogicznie jak potrzebny przypis – napis w górnym indeksie i w nawiasie potrzebna aktualizacja. Popieram na pewno pomysł ukrytej kategorii. Pozdrawiam, Maćko[dysk.] 01:23, 24 paź 2016 (CEST)
• Powstał {{aktualizuj po}}. Wostr (dyskusja) 20:51, 17 gru 2016 (CET)

Jak sprawdzić, czy dany artykuł był już odwiedzony przez czytelnika

Czy ktoś może wie, jak sprawdzić z poziomu parsera, czy dany artykuł (inny niż wyświetlany w danej chwili) był już odwiedzany przez czytelnika (a dokładniej, czy jego przeglądarka pamięta, że go odwiedzał)? A jeśli nie ma takiej funkcji, to czy wiecie, do kogo się uśmiechnąć, aby dokodował? :-) KamilK7 (dyskusja) 14:27, 1 wrz 2016 (CEST)

jakiegokolwiek czytelnika czy konkretnego? generalnie Wikipedia nie śledzi swoich użytkowników zgodnie z m:Privacy policy. Informacje o edycjach sa dostępne publicznie. Inne nie i bez zmiany tej polityki, na co bym nie liczył, nie będą dostępne. masti <dyskusja> 14:40, 1 wrz 2016 (CEST)

O, podepnę się: konkretnego użytkownika to na pewno nie, ale może jest gdzieś coś w rodzaju licznika wszystkich wyświetleń danej strony? --CiaPan (dyskusja) 15:23, 1 wrz 2016 (CEST)

@CiaPan Jest coś takiego. Ale nie mam pojęcia na jakiej zasadzie to działa i czy jest wiarygodne. Wostr (dyskusja) 15:54, 1 wrz 2016 (CEST)

@KamilK7 @CiaPan Lub po prostu można wejść w zakładkę "Historia i autorzy" danego artykułu, a u góry będą różne statystyki, w tym "Statystyka oglądalności strony". Na dole wykresu masz podsumowanie dla danego okresu czasu. --Maattik (dyskusja) 16:32, 1 wrz 2016 (CEST)

@masti Nie konkretnego, tylko tego, który akurat czyta stronę. @Maattik To mi nic nie da. Chodzi o to, że w środowiskach, które korzystają z LaTexu (mam na myśli <math> elementy ani wyniki ustawień wikikodu nie działają i nie bardzo jest jak podlinkować np. funkcję, albo symbol tak, aby było na pierwszy rzut oka widać że jest link. Tymczasem niektóre z nich warto czasem podlinkować, bo dawniej stosowało się w polskiej literaturze inne nazwy (np. staruszkowie tacy jak ja pamiętają tylko "rz" dla rzędu macierzy, a teraz stosuje się "rank". Podlinkować oczywiście mogę (pozwolę sobie użyć przykładu, który stworzył @Mariusz Swornóg, a ja tylko dodałem w nim linkowanie):

$(A,B,C)\sim (A',B',C')\Leftrightarrow \exists _{\lambda \in \mathbb {R} }:A=\lambda A',B=\lambda B',C=\lambda C'\Leftrightarrow$${\mbox{rank}}$${\begin{pmatrix}A&B&C\\A'&B'&C'\end{pmatrix}}=1$.

Link jest, ale nie widać, że jest ponieważ wzór jest renderowany do postaci graficznej. Ale to nie problem, bo pokolorować można, można też sprawdzić, czy artykuł istnieje i dobrać kolor linku korzystając np. z takiego rozwiązania:

[[Rząd macierzy|{{#ifexist: Rząd macierzy|<math>{\color[RGB]{34,85,187}\mbox{rank}\color{black}}</math>|<math>{\color[RGB]{187,0,0}\mbox{rank}\color{black}}</math>}}]]

Da to po wstawieniu do powyższego równania taki efekt (link niebieski, bo likowany artykuł akurat istnieje):

$(A,B,C)\sim (A',B',C')\Leftrightarrow \exists _{\lambda \in \mathbb {R} }:A=\lambda A',B=\lambda B',C=\lambda C'\Leftrightarrow$${\color [rgb]{0.13333333333333333,0.3333333333333333,0.7333333333333333}{\mbox{rank}}\color {black}}$${\begin{pmatrix}A&B&C\\A'&B'&C'\end{pmatrix}}=1$.

Napisałbym szablon i byłoby wygodne. Ale szablony powinno się pisać jako kompletne rozwiązania, a przecież przeglądarki inaczej wyświetlają "niebieski" link nieodwiedzany przez czytelnika, a inaczej odwiedzany (jest bardziej fioletowy). I dlatego potrzebuję funkcji parsera, która to sprawdzi. KamilK7 (dyskusja) 16:40, 1 wrz 2016 (CEST)

pomysł dobry ale taka informacja na pewno nie jest udostępniana gdyż pozwalałoby to sledzić kto czyta jakie strony. masti <dyskusja> 17:58, 1 wrz 2016 (CEST)

@masti No nic... dziękuję za odpowiedź, przynajmniej wiem, że nie muszę tracić czasu na szukanie, bo i tak nie znajdę. :-) Ale... mam jeszcze jeden pomysł. Zasugerowałem, że potrzebna jest funkcja parsera. No tak, rzeczywiście parser pewnie działa po stronie serwera, więc zrobienie tego jako funkcji parsera rzeczywiście by musiało łamać politykę prywatności wikipedii. A LaTeX? Czy on przypadkiem nie renderuje po stronie klienta? Ja pewnie pisząc kod tak bym zrobił, aby odciążyć serwery wikipedii. ;-) Przyglądając się sposobowi w jaki wyświetlane są strony też mam wrażenie, że niektóre operacje są wykonywane właśnie po stronie klienta. Jeśli LaTeX działa po stronie klienta, to może w nim można zdefiniować małe rozszerzenie, coś takiego jak \linkcolor{adres}. Wtedy po stronie klienta byłoby to sprawdzane i polityka prywatności byłaby zachowana, bo nic na serwer by nie szło. Przy okazji rozwiązałoby to problem polegający na tym, że w różnych przeglądarkach linki mogą być oznaczane nieco innymi kolorami, bo LaTeX pobrałby ustawienie z przeglądarki użytkownika. KamilK7 (dyskusja) 09:36, 2 wrz 2016 (CEST)

z LaTeXem niestety nie pomogę :) masti <dyskusja> 15:06, 2 wrz 2016 (CEST)

• @KamilK7 Świetny pomysł na szablon! LaTeX jest wykonywany po stronie serwera, do klienta trafia już obliczone SVG. Obecnie wstawia się jako tag img. Gdyby wstawiał się jako inline SVG, nie byłoby problemu, żeby zmienić kolor literek za pomocą CSS, przy użyciu selektora pseudoklasy :visited… ale flagi przestawiającej wtyczkę LaTeX na inline SVG się nie doszukałem. Ewentualnie można się dobrać do takiej grafiki JavaScriptem, aby wtłoczyć jej strukturę do bieżącego dokumentu. Najbardziej realny pomysł na fioletowy kolor to wymusić renderowanie się wzoru nie jako LaTeX ale jako MathML (można samym CSS-em) i w strukturze MathML-a ostylować napis korzystając z :visited. Ale według mnie nawet bez fioletowego szablon LaTeX-owy będzie super :) Maćko[dysk.] 02:09, 24 paź 2016 (CEST)

• @Maćko To, w jaki sposób wzór trafia do użytkownika, zależy od tego, co sobie ustawi użytkownik wiki. Domyślnie jest to zdaje się PNG (nie pamiętam już, ale chyba tak, bo w ustawieniach figuruje jako pierwsze). Może być ustawione wysłane też jako źródło w w LaTeX, no i może też oczywiście być to jako MathML z przejściem w SVG lub PNG, ale nie wiem, jakie czynniki decydują o tym, czy będzie to SVG (i do tego, czy inline) czy PNG. JavaScript, to chyba nie jest dobry pomysł, gdyż nawet o wiele bardziej przydatne narzędzia to użytkownicy/redaktorzy muszą dodawać u siebie w commons.js. To, co pokazałem wyżej, będzie działało u każdego użytkownika bez względu na ustawienia, ale niestety "fioletowego" linka już odwiedzonego w ten sposób nie uzyskamy. Cieszę się, że uważasz to za świetny pomysł na szablon, ale nie wiem, kto w wikiprojekcie matematyka zajmuje się szablonami, a nie chcę się tam pakować z butami. Może @Olaf będzie coś wiedział, bo jest użytkownikiem tego projektu, a przy okazji adminem, który na wiki zagląda (zdaje się jest to dość unikalna kombinacja w tym wikiprojekcie). KamilK7 (dyskusja) 13:48, 24 paź 2016 (CEST)
• MathML nie przejdzie przecież nigdzie nie działa i wsparcie nie jest rozwijane. Zostaje tylko grafika, najlepiej wektorowa. KABEXXXIOR | DYSKUSJA | 23:52, 9 lis 2016 (CET)

• @Kabexxxior Nie wiem, czy jest wspierane, ale wiem, że to nie może być prawda, że nigdzie nie działa, bo u mnie przecież działa. :-) W obecnie dostępnych opcjach tylko MathML (o ile jest przejście w SVG) daje szanse na wygenerowanie grafiki wektorowej. KamilK7 (dyskusja) 13:16, 10 lis 2016 (CET)

• Może inaczej - nie we wszystkich popularniejszych przeglądarkach działa, a jak już, to szczątkowo. A o to chodzi z punktu widzenia Wikipedii. I co rozumiesz przez ostatnie zdanie?

Funkcji parsera, Lua, ani Javascript do sprawdzania czy ktoś wszedł na linka nie ma i nie będzie, ze względów bezpieczeństwa: [1]. Coś takiego umożliwiałoby sprawdzenie, czy klient wchodzi na przykład na strony pornograficzne, wystarczyłoby dodać linka do jednej i sprawdzić, czy ma atrybut :visited. Faktycznie było to kiedyś możliwe w IE i zostało spatchowane. Dodawanie linków w LaTeXu teoretycznie istnieje (en:b:LaTeX/Hyperlinks), tylko w projektach Wikimedia jest wyłączone, pewnie też żeby nie dało się wsadzać linków do swoich stron w ukryty sposób. Można próbować mieszać kod z szablonu math i normalne linki z wikicode. W zasadzie powinno to się dać zrobić jako moduł Lua, który by to robił: parsował przekazaną treść LaTeXa i wytwarzał odpowiedni kod z linkami i LaTeXem. W zasadzie to nawet własny renderer LaTeXa dałoby się w Lua napisać z dowolnymi funkcjami. Tylko nie wiem, czy to gra warta świeczki. Olaf @ 10:37, 13 lis 2016 (CET)

@Olaf mieszanie lików wikikodu z szablonem math daje kiepskie rezultaty ponieważ nie da się dobrać czcionki i jej rozmiaru (użytkownik może zmieniać warianty w ustawieniach i gdy dobierzemy do jednego, to u innych wygląda koszmarnie) - to już rozwiązanie podane przeze mnie wyżej jest lepsze, bo tam tylko kolor odwiedzonego linka się nie zgadza, a cała reszta pasuje. Pisanie własnego modułu renderującego LaTeX moim zdaniem nie jest warte świeczki. Natomiast nie bardzo wiem, o co chodzi z tym wyłączeniem hiperlinków w LaTeX'ie, aby zapobiec tworzeniu ukrytych linków - przecież i tak zawsze musi wystąpić owo "*ref*" lub "url", które rzucają się w oczy. To już tworząc szablony łatwiej jest zrobić linki, które w kodzie nie rzucają się w oczy, a tworzenie szablonów wyłączone nie jest. :-) A jest to istotne, dlatego, że włączenie hiperlinków w lateksie i napisanie odpowiedniego szablonu, to byłaby jedyna chyba metoda, która byłaby wystarczającą mało pracochłonna, aby być warta świeczki, a jednocześnie wystarczająco kompleksowa, abym nie miał oporów pisać szablonu z obawy o to, że będzie wyglądał, jak świeżo ociosany, jeszcze nieoheblowany. KamilK7 (dyskusja) 10:07, 15 lis 2016 (CET)

Kategorie dla kategorii - HotCat

Utworzyłam np. kategorię Zagadnienia według czasu jako podkategorię kategorii Kategorie dla kategorii. Teraz chcąc wstawić w Zagadnienia według czasu jakąś kategorię posługując się narzędziem HotCat, po wpisaniu w stosowne pole nazwy Zagadnienia według czasu i zatwierdzeniu, automat zmienia tekst, tzn. próbuje wymusić wstawienie kategorii Kategorie dla kategorii zamiast Zagadnienia według czasu. SpiderMum (dyskusja) 21:43, 3 lip 2016 (CEST); up! 06:58, 28 lis 2016 (CET)

PS teraz np. był problem z Kategoria:Aosdána. Dodałam ja do kontenerowej Kategoria:Kategorie według organizacji i za pomocą HotCat nie dało się „poprawić” na inna kat. niż na Kategorie dla kategorii. SpiderMum (dyskusja) 22:48, 9 lip 2016 (CEST)

Przywracam wątek... Dzisiaj wstawiłam hotcatem kategorię "Kategorie dla kategorii" gdy chciałam dodać kategorię "Kategorie tematyczne"... SpiderMum (dyskusja) 00:44, 29 wrz 2016 (CEST)

Rzeczywiście, potwierdzam takie dziwne zachowanie. Próbując wstawić Kategoria:Kategorie tematyczne wskakuje zamiast tego przy zapisie Kategoria:Kategoria dla kategorii. Wostr (dyskusja) 00:55, 29 wrz 2016 (CEST)

Cytuj pismo

Czy możliwe byłoby przeniesienie roku (daty) w tym szablonie przed strony? W obecnej postaci wygląda to nieco dziwnie: wolumin (numer), s. strony, rok. Czasem strony są czterocyfrowe i nie wiadomo, czy rok jest rokiem czy stroną. Chyba najlepiej byłoby to umieścić w kolejności: wolumin (numer), rok, s. strony. Wostr (dyskusja) 01:04, 1 paź 2016 (CEST)

Popieram powyższą prośbę. Niedawno zetknąłem się z takim przypadkiem. Demkoff _dyskusja 17:18, 1 paź 2016 (CEST)

Jestem także za taką zmianą. To logiczne rozwiązanie. Lowdown (dyskusja) 09:15, 2 lis 2016 (CET)

Domyślny edytor

W niemieckiej i angielskiej wikipedii domyślny jest edytor kodu a nie wizualny. Proszę o to samo w polskiej Wikipedii. Nie chcę wstępnego ładowania VE przed oknem wyboru, to się wiesza często i gubi sekcję przy pierwszym kliknięciu gdy chcę edytować tylko sekcję tekstu. 83.30.0.225 (dyskusja) 14:38, 1 lis 2016 (CET)

Popieram. Proszę przestać na siłę uszczęśliwiać wszystkich jakimiś bzdurnymi gadżetami. Dla niezalogowanych bzdurny edytor wizualny jako domyślny, analfabetom dany automatyczny translator (udało się trochę wyłączyć), a w dyskusji Tara nie da się pisać bo ustawiony jest jakiś bajer z fajerwerkami, którego nikt nie umie obsługiwać. Dosyć nowinek, wróćmy do funkcjonalności. Hoa binh (dyskusja) 15:15, 1 lis 2016 (CET)

 Za powrotem do tego jak było. Zgadzam się z przedmówcami. Jak zawsze, lepsze wrogiem dobrego. Flow jest nieintuicyjnym bublem i chyba nawet nie jest już rozwijany. Visual editor może być czasem przydatny, ale powinien być domyślny wybór. Teraz po założeniu konta jest domyślny tylko VE i trzeba ręcznie zmieniać ustawienia. ~Cybularny^{Napisz coś ✉} 15:26, 1 lis 2016 (CET)

Przy pierwszym wejściu do edycji powinny być jasno opisany wybór pomiędzy obiema wersjami (i bez wstępnego ładowania VE). Tyle i aż tyle. Nie powinno się z jednej strony ukrywać VE, ale z drugiej nie można wciskać go na siłę wszędzie, gdzie się da, bo ma być super-ułatwieniem (dla mnie jeśli ktoś nie jest w stanie nauczyć się używać edytora kodu, to najprawdopodobniej edytowanie Wikipedii nie jest jego przeznaczeniem). Flow, z tego co się dowiedziałem, ma być całkowicie usunięty z en.wiki (z tych stron, na których był używany) i bez możliwości selektywnego włączania go na pojedynczych stronach. Z tego, co przeczytałem, jest to decyzja z października tego roku. (wpis z mojej dyskusji). Tak samo powinien być IMHO usunięty z pl.wiki, do czasu aż będzie (jeśli będzie) poprawnie działającym narzędziem i będzie zgoda na jego pełne wprowadzenie. Wostr (dyskusja) 15:43, 1 lis 2016 (CET)

Przez to preładowanie VE dla zalogowanych wychodzi coś takiego w Google Chrome:

"Uwaga! Serwer nie może przetworzyć tej edycji z powodu utraty danych sesji. Być może doszło do wylogowania. Proszę, upewnij się, że nadal jesteś zalogowany (zalogowana), i wtedy spróbuj ponownie. Jeśli to nie pomoże – spróbuj wylogować się i zalogować ponownie, a także upewnij się, że twoja przeglądarka akceptuje ciasteczka z tej witryny."

Koniecznie pozbyć się tego preładowania VE w trybie pilnym. 83.7.255.77 (dyskusja) 09:28, 7 lis 2016 (CET)

Dublowanie przy dwóch infoboksach

Poruszam kwestię występowania podwójnych informacji w wersach przy wstawieniu dwóch infoboksach w biogramie. Było już wyjaśnione, iż aby uniknąć podwójnego występowania grafiki, należy w drugim infoboksie wpisać "nie" w wersie "grafika". Ale co zrobić gdy pojawia się w drugim infoboksie miejsce urodzenia, podczas gdy nie zostało wpisane w edytorze? Np. tu: Stanisław Kara. Lowdown (dyskusja) 09:15, 2 lis 2016 (CET)

Odnośniki - czyli linki ;-)

@Paweł Ziemian, @Peter Bowman – tak już personalnie, formalnie i w pierwszej kolejności do Was, chociaż ktoś inny też oczywiście może się tu tak samo włączyć i coś zaradzić. Uprosiłem już (w opisikach edycji) o "spr", a dałoby radę wstawić jeszcze tam "linki"? Wiem, słówko krótkie, może użycie nie jest też częste, ale biorąc pod uwagę wszystko globalnie, też może usprawniać. Dzięki, jak się da zrobić. Jeśli się nie da, ewentualnie niekoniecznie warto, to wiem, że na pewno ktoś mi odpowie i też dzięki ;-) --Mozarteus (dyskusja) 22:28, 3 lis 2016 (CET)

• Ale tam są „linki-zew”, „linki-popr” i „przypisy”. Czy w Twoim przypadku nie chodzi o ten drugi typ (poprawiono linki zewnętrzne/wewnętrzne)? Paweł Ziemian (dyskusja) 22:34, 3 lis 2016 (CET)
  • Raczej o dodano linki wewnętrzne. Poprawę rozumiem jako zmianę typu: Cykl Pierścień Nibelunga skomponował Wagner, gdzie mielibyśmy Wagner linkowane jako czyste Wagner, na właściwy w tym przypadku link Richard Wagner (z "pałeczką") ;-) --Mozarteus (dyskusja) 08:21, 4 lis 2016 (CET)
    • To "drobna edycja redakcyjna" (ew. "linki-popr."), podobnych edycji różnego rodzaju jest mnóstwo i jeśli dla każdej będziemy tworzyć osobny guzik ze skrótem to ich zestaw straci funkcjonalność. Im więcej skrótów tym trudniej/dłużej się z nich korzysta. Kenraiz (dyskusja) 08:50, 4 lis 2016 (CET)
      • A nie lepiej (nie tylko dla symetrii) zamienić ten opis na krótkie linki wewnętrzne. Czy poprawiono, czy dodano to już nie takie ważne - czasami robi się jedno i drugie, a dodaje chyba częściej niż poprawia. Skoro jest „linki-zew”, to niech będzie i „linki-wew” :). Czasami przy dodawaniu linków aż chciałoby się tam kliknąć, ale to jest ograniczone tylko do poprawy. Hedger z Castleton (dyskusja) 12:25, 4 lis 2016 (CET)
• Zawsze możesz użyć gotowego narzędzia/skryptu pozwalającego na personalizację paska z guzikami :). Np. Wikipedia:Narzędzia/magicOfGreenRectangles. O, jest i drugi gadżet: Wikipedia:Narzędzia/dodatkowe przyciski opisu edycji. Sir Lothar (dyskusja) 10:03, 4 lis 2016 (CET)
• Przecież jest guziczek "wikizacja", który dotyczy właśnie dodania LW. Michał Sobkowski _dyskusja 14:03, 4 lis 2016 (CET)
  • Wikizajca to ogólne formatowanie znacznikami wiki. W sumie mogłaby być, ale można by przy okazji odchudzić pasek i uciąć te "linki-popr". Narzędzia poprawiające disambigi/redirecty same dodają komentarz w pasku edycji :) Teraz to jest tak, jakby był przycisk do informowania o poprawie przypisów przy braku przycisku do informowania o uźródłowieniu ;) Hedger z Castleton (dyskusja) 14:24, 4 lis 2016 (CET)
• Obecnie mamy takie możliwości:

guzik "linki-zew" ma w opisie "poprawiono/dodano linki zewnętrzne"

guzik "linki-popr" ma w opisie "poprawiono linki zewnętrzne/wewnętrzne"

dodatkowo guzik "wikizacja" dla wszystkich czynności formatowania łącznie ze wstawieniem linków wewnętrznych, czyli z opisem: zmiana zwykłego tekstu na tekst sformatowany. Najważniejsze jest wstawianie linków hipertekstowych do innych stron w ramach Wikipedii

Jeśli już, to zlikwidowałbym guzik "linki-popr" nie dodając żadnego. Ented (dyskusja) 14:42, 4 lis 2016 (CET)

O, tak tak. To wystarczy, bo ten przycisk myli (gdy się szuka przycisku wikizacji). Hedger z Castleton (dyskusja) 14:43, 5 lis 2016 (CET)

Ten przycisk jest przydatny. Można go użyć podczas zmiany linku na inny (wewnętrznego lub zewnętrznego) lub jego poprawy (kod, źle wklejony link...). Przycisk o wstawianiu wewnętrznych też by się przydał. Wargo (dyskusja) 15:04, 5 lis 2016 (CET)

Ohoho, ale gdyby do każdego rodzaju poprawki był osobny przycisk... :) Lepiej, gdyby było więcej przycisków do tego, co się ręcznie robi często niż do tego, co się robi rzadziej. Do poprawek technicznych (linków, szablonów, tagów, urli itd.) wystarczy chyba "dr. tech."). Cała zagadka, jaką tu @Mozarteus przedstawił, polega na tym, że mamy brak symetrii: Poprawiono/dodano linki zewnętrzne x Poprawiono linki zewnętrzne/wewnętrzne. Są więc aż 2 przyciski do poprawiania linków zewnętrznych, 1 do dodawania linków zewnętrznych, 1 do poprawiania linków wewnętrznych i 0 do dodawania linków wewnętrznych. A linki wewnętrzne dodaje się raczej częściej niż zewnętrzne, najrzadziej w tych operacjach chyba poprawia się linki zewnętrzne. Poprawiono/dodano linki zewnętrzne/wewnętrzne ze skrótem linki. Hmm? Albo 2: Poprawiono/dodano linki wewnętrzne (linki wew) Poprawiono/dodano linki zewnętrzne (linki zew). A zamiast wikizacji (trzeba się naszukać, aby zrozumieć o co chodzi) format. od formatowanie tekstu. ujedn. chyba też zbędne - jest i narzędzie, i mieści się to w poprawianiu linków. Hedger z Castleton (dyskusja) 15:23, 5 lis 2016 (CET)

Zdecydowanie przeciwko usuwaniu "linki-popr". Jeśli już chcemy coś zmieniać, to raczej opis "linki-zew" np. na "dodano linki zewnętrzne". Dodawanie linków wewnętrznych jest zawarte w wikizacji, więc mielibyśmy wówczas wszystkie możliwości objęte raz. Barcival (dyskusja) 21:00, 5 lis 2016 (CET)

• Coś mi się zdaje, że zrobiła się akademicka dyskusja nad wyższością jednych świąt nad drugimi ;) Czy nie może być jeden przycisk "linki" z opisem Poprawiono/dodano linki zewnętrzne/wewnętrzne. Po co nam kolejne przyciski z "linkami". Link to link i tyle ;) Ented (dyskusja) 22:38, 6 lis 2016 (CET)
• Wnioskodawca chyba już wie, jak co można zmienić ;) Ale pewnie za jakiś czas podobne pytania będą się tu pojawiać. Czy obok przycisku +rozwiń skróty można by dodać link [[Wikipedia:Narzędzia/dodatkowe przyciski opisu edycji|stwórz własne skróty]]? Hedger z Castleton (dyskusja) 15:51, 7 lis 2016 (CET)
  • Wnioskodawca to już nawet zapomniał, że kiedyś zapoczątkował taką dyskusję, ale... edytując dzisiaj Parmezan, zaglądnąłem i tutaj. Ented ma rację, któreś linki z opisem najlepiej przerobić na linki i tyle. Wikizacja też jest dość enigmatyczna. Natomiast Hedger z Castleton ma taką samą "szklaną kulę", jak ja, bo według mnie też ktoś kiedyś znowu to może zgłosić. Warto więc to zrobić wcześniej. --Mozarteus (dyskusja) 10:50, 24 lis 2016 (CET)

Adresy w przypisach

Czy da się w przypisach dodać obok podstawowego adresu url, url do innej wersji językowej? Eurohunter (dyskusja) 16:41, 7 lis 2016 (CET)

• @Eurohunter Tak, da się. Na przykład: <ref>{{cytuj | tytuł = ABDA-Aktuelle Info (ang.) | url = http://www.dimdi.de/dynamic/en/db/dbinfo/index.htm | opis = [http://www.dimdi.de/static/de/db/dbinfo/ah87.htm ''ABDA-Aktuelle Info (niem.)''] | wydawca = DIMDI | data dostępu= 2016-11-08}}</ref> da efekt widoczny poniżej. KamilK7 (dyskusja) 10:40, 8 lis 2016 (CET)
  • Wygląda to bardziej na trik niż rozwiązanie, ponieważ ten sposób konfliktuje z parametrem język, a informacje o języku umieszczane są w linku zewnętrznym razem z adresem strony bez linka wewnętrznego do artykułu o konkretnym języku. Eurohunter (dyskusja) 13:11, 8 lis 2016 (CET)
• A po co ? Albo informacja ma jedno źródło więc i jeden przypis albo ma źródła dwa (i 2 przypisy). 5.45.62.149 (dyskusja) 17:03, 8 lis 2016 (CET)
  • Chodzi o przypadek w którym to samo źródło zostało udostępnione w innej wersji językowej pod innym adresem url. Eurohunter (dyskusja) 17:29, 8 lis 2016 (CET)
    • Ale korzystałeś z obu wersji wstawiając informację ? Nie wiem jaki jest sens dodawania przypisu tylko dlatego, że ma tez inną wersję językową. Książki też bywają wydawane w różnych językach z ta sama informacją. 5.45.62.149 (dyskusja) 17:34, 8 lis 2016 (CET)
      • To jest jedna wersja. Eurohunter (dyskusja) 18:10, 8 lis 2016 (CET)
      • 5.45.62.149, warto dodać rożne wersje językowe (o ile pomiędzy nimi nie ma linków), bo czytelnicy znają różne języki. Dlaczego im nie pomóc wskazując, że źródło jest dostępne w rożnych wersjach? A co do szablonu, to nie ma on wbudowanej możliwości dodawania różnych wersji, a więc trzeba stosować triki. Sytuacja jest na tyle rzadka, że IMHO nie ma sensu rozbudowywać szablonu. Michał Sobkowski _dyskusja 20:19, 8 lis 2016 (CET)
• Tego rodzaju triki jak zaprezentowany to IMHO nadużycie szablonu cytowania. Ktoś będzie potem chciał coś botem zrobić i będzie miał pełno jakichś takich dziwnych parametrów. Już lepiej albo dać dwa przypisy, albo w jednym przypisie dwa szablony cytowania (albo po prostu ręcznie dopisać po szablonie cytowania coś w stylu Wersja niemiecka dostępna pod adresem), albo najzwyczajniej zrezygnować w danym przypadku w ogóle z szablonu cytowania. Ale pod żadnym pozorem nie wypełniać parametrów szablonu rzeczami, które w tych parametrach nie powinny się znaleźć (i tylko dlatego, że w tej konkretnej chwili takie wypełnienie daje nam pożądanych efekt wizualny). Wostr (dyskusja) 22:43, 8 lis 2016 (CET)
  • Dwa szablony w jednym refie to najlepszy pomysł. Tylko dlaczego znak * tworzy większy odstęp pomiędzy wierszami od zwykłego tekstu (Pozemní síly)? W angielskiej wersji jest w porządku. Eurohunter (dyskusja) 23:15, 8 lis 2016 (CET)
    • Bo oni mają do tego dedykowany wpis CSS. U nas każda lista ma 0.3em marginesu od góry. A tutaj jest lista nienumerowana w liście numerowanej (przypisach). Może zamiast nowej linii i „*” między szablonami cytowania wstaw „<br />{{bullet}}”. Unikniesz w ten sposób drugiej listy symulując jej wygląd ręcznie. Ewentualnie pomiń nową linię. Daj wszystko w jednej. Paweł Ziemian (dyskusja) 23:34, 8 lis 2016 (CET)

Przypisy - ref i R

Cześć, chciałbym omówić te dwa sposoby tworzenia przypisów. Mnie się wydaje, że wstawianie ich przez szablon jest tragiczne. Nie da się ich edytować przez VE (początkujący Wikipedyści oraz edytujący dłuższe artykuły mają przekichane), przetwarzanie szablonów bardziej obciąża serwery i potrafi też się robić bałagan, gdy oba rodzaje się miesza. Z jakiego powodu więc ten szablon jest stosowany? Przecież prostszy od stosowania refów nie jest. Czy może o czymś nie wiem? Czy może dałoby się go wycofać? Na akcję BATUTA właśnie pracuję w brudnopisie nad artykułem o HTML-u, przez pół godziny przepisywałem przypisy z formatu szablonu "R" do zwykłych REF-ów przy okazji dodając nowe informacje do nich. A jeszcze jest skrypt, który konwertuje refy do "R" i skoro jest prawdopodobne, że ktoś puści w piździec moją pracę przejeżdżając raz skryptem wracając do początku, to takie edytowanie jest bez sensu. Sam jestem fanem szablonów, ale niech one naprawdę coś dają. To tak naprawdę tylko przeszkadza. Uważam, że zgodność z VE jest bardzo potrzebna, a szablony tego nie dają. W przeciwieństwie do infoboksów i niektórych działań, wstawianie przypisów dotyczy wszystkich wikipedystów i nie należy tego utrudniać. Bardzo ważne jest, aby wstawianie przypisów było łatwe oraz żeby było zgodne z VE, bo to nie tylko ułatwia początkującym, ale też wstawianie w ogóle - nie muszę mieć ściągawki ani się uczyć, jak powinien wyglądać przypis, a szkół co do tego jest jeszcze bardzo dużo. A informacji o źródłach jest również jest dużo i nie muszę się zastanawiać, gdzie umieścić tłumaczy, edytorów, gdzie poszczególne identyfikatory, datę i miejsce wydania itd. Ewentualnie, może ktoś mi będzie w stanie wytłumaczyć, jaka jest idea tego szablonu? KABEXXXIOR ≡ DYSKUSJA 15:06, 12 lis 2016 (CET)

Szablon R był promowany jako doskonale czyszczący z "technicznego bełkotu" treść artykułów i działał w tej roli doskonale do czasu wprowadzenia Visual editor. Przed edytorem wizualnym stosowałem go z lubością, bo znakomicie ułatwiał edytowanie, teraz odpuściłem i znów niestety sadzę kody przypisów w treści artykułów... Kenraiz (dyskusja) 15:18, 12 lis 2016 (CET)

Więc czy może jest jakaś możliwość wycofania tego? Wiadomo, że nagle usunąć się tego nie da, ale niech nie będą wstawiane nowe, z czasem uźródławiania ten sablon mógłby umrzeć śmiercią naturalną. KABEXXXIOR ≡ DYSKUSJA 15:25, 12 lis 2016 (CET)'

@Matma Rex - a jakie jest Twoje zdanie? I czy mógłbyś wycofać ten skrypt konwersji refów na R? Bo tym narzędzie można zniszczyć całą pracę kogoś, kto przepisuje R na refy. KABEXXXIOR ≡ DYSKUSJA 15:27, 12 lis 2016 (CET)

@Kabexxxior Skryptem obecnie zarządza Paweł Ziemian. A przynajmniej ostatnio naprawiał, jak skrypt się zepsuł :) Moim zdaniem skrypt jest nadal przydatny (treść przypisów zgrupowana na końcu artykułu jest fajna), ale pewnie faktycznie zamiast {{r|…}} powinien generować <ref name="…" />. Matma Rex dyskusja 16:05, 12 lis 2016 (CET)

Jaki skrypt? Link poproszę. Paweł Ziemian (dyskusja) 18:39, 12 lis 2016 (CET)

Wikipedysta:Matma_Rex/prettyref.js KABEXXXIOR ≡ DYSKUSJA 19:12, 12 lis 2016 (CET)

Właściwy kod jest teraz tutaj, jedynie przepisałem oryginalny skrypt w Ruby na Javę. Pozdrawiam, Peter Bowman (dyskusja) 19:45, 12 lis 2016 (CET)

On służy właśnie do skracania (ułatwiania) gdy jest kilka takich samych przypisów. --Wargo (dyskusja) 17:14, 12 lis 2016 (CET)

Ale to wszystko refy obsługują. Listę przypisów tworzy się za pomocą <references /> , a powtarzające się przypisy skraca się do takiej składni: <ref name=":nadany identyfikator przypisowi, który chcemy powtarzać" /> . To jest jeszcze prostsze, niż wszystkie formy zastępcze, więc nadal nie rozumiem ich idei. KABEXXXIOR ≡ DYSKUSJA 17:20, 12 lis 2016 (CET)

Szablon r nie ma nic wspólnego z listą przypisów (którą tworzy się także za pomocą szablonów {{Przypisy}} i {{Przypisy-lista}}. A jego przewaga nad tradycyjnym znacznikiem to uproszczenie kodu. Np. zamiast

Informacja<ref name="p1" /><ref name="p2" /><ref name="p3" /><ref name="p4" />

jest

Informacja{{r|p1|p2|p3|p4}} .

Gdy przypisów jest dużo, widok kodu jest znacznie klarowniejszy. IMHO właściwa droga to doprowadzenie do obsługi {{r}} w VE, a nie odchodzenie od tego wygodnego rozwiązania. Michał Sobkowski _dyskusja 21:40, 12 lis 2016 (CET)

Jestem tego samego zdania. Piszę niemal wyłącznie w widoku kodu i wygoda {{r}} jest nie do przecenienia. Zadziwia mnie wiadomość, że VE go nie obsługuje – czy to takie trudne do zaimplementowania? Szczureq (π?) 09:15, 13 lis 2016 (CET)

Szablony i przypisy są obsługiwane w szczególny sposób; coś, co jest jednocześnie szablonem i przypisem, wymagałoby podwójnie szczególnego traktowania :/ (a gdy w jednym szablonie jest kilka przypisów, to robi się już całkiem… szczególnie). Wszystko się da zrobić, ale nie jest to łatwe. A chyba niestety jesteśmy jedyną z dużych Wikipedii, gdzie tego typu rozwiązanie jest popularne, a problemy dotykające więcej niż jednej społeczności mają priorytet. Matma Rex dyskusja 15:27, 13 lis 2016 (CET)

Również bardzo boleśnie bym odczuł niemożność używania {{r}}. Gżdacz (dyskusja) 10:46, 13 lis 2016 (CET)

• Kolejny post w stylu: Jaki piękny jest VE i Flow, wszystko co z nimi nie działa jest bee. VE jest wciąż narzędziem, które wymaga bardzo wielu poprawek i to jest jedna z nich. To VE powinno dostosować się do obecnego stanu (albo zaproponować rozwiązania lepsze), nie na odwrót. Nie widzę poza tym możliwości, aby VE kiedykolwiek mogło zastąpić edytor kodu (bo nie nadaje się do ciut bardziej skomplikowanych edycji). Nie było zresztą nigdy zgody na to, abyśmy mieli dostosowywać wszystko pod VE, z którego obecnie większość edycji jest niepoprawna (mój własny OR na podstawie obserwowanych). Nie lubisz {{r}} – nie używaj. Tyle. Wostr (dyskusja) 13:16, 13 lis 2016 (CET)
• Dokładnie, szablon {{r|lista nazw przypisów}} jest bardzo wygodny w użyciu i bardzo rozjaśnia widok kodu artykułu. Każdego narzędzia należy używać w takim zakresie, w jakim ono dobrze funkcjonuje - ja rozumiem, że niektóre rzeczy pod VE robi się wygodniej, ale akurat przypisy do tych rzeczy nie należą, bo są przez VE niewłaściwie obsługiwane. Więc do puki dopóki nie poprawią VE, proponuję do użródławiania stosować edytor kodu. W każdym razie jestem absolutnie przeciwny odchodzeniu od "r", to nowe narzędzia należy dostosowywać tak, aby obsługiwały ten szablon. KamilK7 (dyskusja) 10:54, 14 lis 2016 (CET)

Przywoływanie grup użytkowników według zainteresowań

Przy stoliku Wikipedia:Kawiarenka/Wikipedyści zacząłem dyskusję (link) na tytułowy temat, ale ponieważ wiąże się to przede wszystkim z problemem technicznym – proszę o odpowiedź czy możliwe jest wdrożenie przedstawionej tam propozycji. Kenraiz (dyskusja) 22:28, 12 lis 2016 (CET)

Kategoryzacja biografii według miast - wyższy poziom

Witam, przy okazji edycji artykułów biograficznych związanych z miastami zauważyłem, że miasta są posegregowane tylko według kontynentów. Może niepotrzebnie, ale miałem wrażenie, że jest to jakieś za szerokie kryterium, więc pomyślałem, że można by to posegregować według kryterium geograficznego - państw, w których te miasta leżą. Starscream zwrócił mi uwagę (dobrze, że tak niewiele zdążyłem narozrabiać), że w kwietniu już się przewinął ten wątek i dlatego wszystko wróciło do kontynentów. Ale może wypracujemy jakieś rozwiązanie, proszę o pomysły przy okazji tego autozgłoszenia DNU. Pozdrawiam AlexKazakhov (Dyskusja) 11:53, 13 lis 2016 (CET)

Automatyczne obliczanie w infoboksie - czy to możliwe?

Witam, aktualizuje informacje o francuskich gminach i przy każdej zmianie liczby mieszkańców trzeba ręcznie policzyć także jaka jest gęstość zaludnienia do zmianie. Zabiera to oczywiście sporo czasu, jeśli artykuły aktualizuje się na potęgę. Dlatego chciałbym się zapytać czy istnieje możliwość automatycznego obliczania gęstości zaludnienia (parametr liczby ludności podzielony przez parametr powierzchni) w infoboksach miejscowości i jednostki administracyjnej, a by może także państwo, miasto, czy jakie tam jeszcze inne podobne infoboksy. Taka funkcja bardzo ułatwiłaby mi pracę (i myślę, że nie tylko mi) na wikipedii. Pozdrawiam i życzę miłego wieczoru, Tournasol Słucham :) 21:19, 16 lis 2016 (CET)

Obawiam się, że to jest tylko teoretycznie możliwe. Obliczanie to twórczość własna, a na wszystko powinny być źródła. Często liczba ludności i gęstość pochodzą z różnych źródeł i lat. Paweł Ziemian (dyskusja) 22:44, 16 lis 2016 (CET)

Ale tu chodzi o obliczanie gęstości na podstawie ludności (zmienia się z roku na rok) i powierzchni (jest generalnie stała). Nie przesadzałbym z zakazem policzenia prostej rzeczy. Czy zawsze mamy źródło potwierdzające wiek człowieka w chwili śmierci, czy jednak pozwalamy sobie odjąć datę urodzenia od daty śmierci i podać wynik? Czy zawsze jak podajemy informację, że liczba ludności wzrosła albo zmalała, to mamy źródło na kierunek zmiany, czy też wolno nam porównać dwie liczby i napisać, która jest większa? A w sporcie, czy wolno napisać o meczu piłkarskim, że jedna z drużyn kończyła go w 10 graczy, gdy wiemy ze źródła, że jeden otrzymał czerwoną kartkę, czy też chcemy zawsze mieć źródło na wynik odejmowania 11-1? Gżdacz (dyskusja) 23:13, 16 lis 2016 (CET)

Tak jak napisał Gżdacz. Powierzchnia jest stała, zmienia się liczba ludności, więc gęstość zaludnienie będzie zawsze tej samej daty co ludność. Tournasol Słucham :) 23:33, 16 lis 2016 (CET)

„Powierzchnia jest stała”. No właśnie nie zawsze! Powierzchnia z reguły jest stabilna, ale też ulega zmianom i jeśli zastosujemy bezmyślny automat porównujący nową powierzchnię i starą liczbę ludności, to będzie cyrk. --WTM (dyskusja) 23:38, 16 lis 2016 (CET)

Może należałoby zaznaczyć, że narzędzie mogłoby być stosowane tylko w sytuacjach, gdy wiadomo, że dane o ludności odnoszą się do określonej powierzchni (czyli są z tego samego roku lub nie wystąpiła zmiana powierzchni w okresie różniącym daty pochodzenia danych). Tak czy siak przeliczanie gęstości zaludnienia lepiej by robił program z podanych danych wyjściowych, niż gdyby miał to człowiek omylny za każdym razem przeliczać i wpisywać z palca. Kenraiz (dyskusja) 02:08, 17 lis 2016 (CET)

• Właśnie, jak wskazał WTM, coś co wydaje się nam zwykłym działaniem matematycznym może być jednak klasycznym OR. Otóż wbrew obiegowym opiniom powierzchnia jednostek administracyjnych nie jest stała. Przykład Polski pokazuje, że co roku wprowadzane są mniejsze i większe zmiany administracyjne (np. od 1 stycznia będą 3 spore zmiany w granicach powiatów), ba GUGiK przelicza i weryfikuje powierzchnie gmin, nawet jeśli takie zmiany nie nastąpiły. W innych krajach jest zapewne podobnie. Zatem obliczanie gęstości zaludnienia może być wykonane samodzielnie jedynie w przypadku, gdy na dany rok mamy i ludność i powierzchnię (obie wartości uźródłowione). W przeciwnym razie należy zostawić ludność dla innego roku i gęstość dla innego (z podaniem oczywiście roku, dla którego są to dane) – tak podane dane będą poprawne, w odróżnieniu od przeliczanych tylko na podstawie zmian liczby ludności, niezależnie, czy to przeliczanie będzie ręczne, czy automatyczne. Aotearoa dyskusja 08:31, 17 lis 2016 (CET)
• Poza tym, czy mamy pewność, jak jest obliczana gęstość zaludnienia w danym źródle? Niektóre obszary mogą być w dużej mierze pokryte np. zbiornikami wodnymi i gęstość może być liczona zarówno z całej powierzchni, jak i lądu stałego. Jeśli chodzi o automatyzmy - już prędzej bym wprowadził ten patent z en.wiki podający aktualny wiek osoby żyjącej w infoboksie :) Emptywords (dyskusja) 10:48, 17 lis 2016 (CET)
• aż się prosi, żeby dane o ludności, powierzchni i gestości wrzucić do Wikadnych z datami (latami) i pobierać automatycznie. Co do wieku to się zgadzam, że warto. masti <dyskusja> 10:55, 17 lis 2016 (CET)
• A dałoby się zrobić tak, że automat by się włączał tylko wtedy, gdy dane z powierzchni i ludności są z tego samego roku? Wymagałoby to dodania dodatkowych parametrów w infoboksie |powierzchnia rok = i |ludność rok = Jeśli wynik byłby identyczny, automat wstawiałby wartość przy parametrze |gęstość zaludnienia Jeśli nie byłby identyczny, to w ogóle nie należałoby przeliczać, bo skąd byłoby wiadomo, że wartości się nie zmieniły w kolejnych latach. Hedger z Castleton (dyskusja) 12:09, 17 lis 2016 (CET)
  • Te dane powinny być jednego dnia, a nie np. z 1 stycznia i 31 grudnia. Kilka lat temu zastanawiałem się nad wprowadzeniem automatu w tym zakresie, ale wydaje mi się po zastanowienia, że więcej jest z tym problemu niż pożytku. Podstawowym problemem jest już wcześniej wskazany problem z ORem związanym z własnym wyliczaniem tego wskaźnika, a dyskusja kiedy nie powinno się automatycznie tego wyliczać tylko to pogłębia. ~malarz pl ^PISZ 13:40, 17 lis 2016 (CET)

Szablon:Technikalia

Co o tym sądzicie? Czy to się przyda? Krottyianock^(PISZ) 14:56, 6 lip 2016 (CEST) 12:57, 18 lis 2016 (CET)

Może być ale czy nazwa nie zbyt ogólna? Wargo (dyskusja) 13:14, 18 lis 2016 (CET)

Już jest {{wysokie ryzyko}}. Nie ma potrzeby tworzenie kolejnych podobnych szablonów. ~malarz pl ^PISZ 19:58, 18 lis 2016 (CET)

Malarz, nie wiesz może, że tu określa się dokładne technikalium, {{Wysokie ryzyko}} działa ogólnie. Krottyianock^(PISZ) 14:56, 6 lip 2016 (CEST) 20:53, 20 lis 2016 (CET)

Te dokładne to powinna być widać na stronie Specjalna:Linkujące. Wskaż do jakich szablonów byś wstawił ten nowy proponowany. Ja pamiętam tylko jeden taki szablon, ale akurat ten jest wstawiony chyba w dziesięciu różnych metastronach, więc proponowany szablon nie nadaje się do tego. Zresztą taki szablon powinien być zablokowany na poziomie sysopa (tak jak przestrzeń MediaWiki), a żaden komunikat w stylu {{mbox}} nie zastąpi rzetelnego opisu. ~malarz pl ^PISZ 16:51, 21 lis 2016 (CET)

Przez miesiąc brak zainteresowania pozostawieniem. Usunąłem jako zbędny. Wątek oznaczam jako Szablon:Załatwiony ~malarz pl ^PISZ 12:32, 16 gru 2016 (CET)

Podgląd przypisów

Dlaczego w komunikacie „Ostrzeżenie Cite: Znacznik <ref> o nazwie Seattle_Weekly nie może być wyświetlony na tym podglądzie, ponieważ jest zdefiniowany poza edytowaną sekcją lub wcale.” wyrazy składowe w nazwie refa oddzielone są pokreśleniem? Utrudnia to nawigację. Czy dałoby się go zamienić na spację? Eurohunter (dyskusja) 11:49, 28 lis 2016 (CET)

To wynika z mechanizmów zaszytych w MediaWiki. IMO dużo większym problemem w tym przypadku są polskie literki zamieniane na kody. ~malarz pl ^PISZ 12:24, 16 gru 2016 (CET)

Edytor szablonów

Drodzy admini!

Czy w plwiki nie przydałoby się to?

Krottyianock^(PISZ) 14:56, 6 lip 2016 (CEST) 21:31, 28 lis 2016 (CET)

Mógłbyś doprecyzować przydatność? I czy to, co mamy na dziś, nie wystarcza? Nie każdy zna angielski, a nawet jeśli, to nie chce mu się męczyć ;) I wyjaśnisz dlaczego widzę dwie różne daty w Twoim podpisie? :) Stanko (dyskusja) 19:27, 1 gru 2016 (CET)

Brakuje wikiprojektów na listach Zgłoś do...

Na liście w Zgłoś do Czy Wiesza brakuje minimum jednego wikiprojektu (listy przebojów), a przy zgłaszaniu do DNU brakuje jeszcze więcej wikiprojektów. Eurohunter (dyskusja) 14:56, 29 lis 2016 (CET)

A propos automatu Poczekalni mam własną wersję : Wikipedysta:Krottyianock/DNUv2.json. Dodałem kilka projektów, bedę dodawać następne. --Krottyianock^(PISZ) 14:56, 6 lip 2016 (CEST) 12:40, 30 lis 2016 (CET)

Tworzenie książek

Witam. Od czasu do czasu potrzebuję z kilku artów zrobić "książkę" (broszurę właściwie). Problemem jest zbyt duża szczegółowość niektórych artykułów. Np. do "książki" o chlebie potrzebuję artu o pszenicy, ale bez danych o chorobach, gatunkach, ochronie chemicznej. Jak można to obejść? Nie skasuję przecież połowy artu na kilka minut nawet. Jeżeli przeniosę treść do brudnopisu, to zgubię historię. Ciacho5 (dyskusja) 14:00, 5 gru 2016 (CET)

Automatyczna archiwizacja przypisów

Kiedy link do przypisu staje się martwy, na archiwizację jest już za późno. I wówczas pojawia się pytanie, czy nie był wcześniej zarchiwizowany. A przecież wiadomo, że każdy link prędzej czy później stanie się martwy. Zastanawiam się zatem nad najlepszym rozwiązaniem i do głowy mi przychodzą 2 pomysły:

1. uruchomienie bota, który by szukał w artykułach przypisów i je automatycznie archiwizował
2. dodanie do szablonu cytowania gadżetu, który by automatycznie archiwizował link

Pierwszy sposób ma ten plus, że zarchiwizowane by były dotychczas istniejące przypisy. Drugi ma tą zaletę, że od momentu wprowadzenia gadżetu wszystko działoby się już automatycznie i nie trzeba by było co jakiś czas uruchamiać bota. Oczywiście nie wiem na ile jest to możliwe od strony technicznej, jednak jak np. zaglądam na francuskojęzyczną wersję wikipedii, to tam mają niemal wszystko zarchiwizowane. Tournasol Słucham :) 19:37, 7 gru 2016 (CET)

To nie jest takie proste, bo np. w serwisie archive.org wiele zarchiwizowanych wersji stron jest pustych (kod 404 itp.), bot musiałby umieć odróżnić takie strony od stron z wartościowymi informacjami, co raczej nie jest łatwe do zaimplementowania. Pikador (dyskusja) 23:34, 11 gru 2016 (CET)

Sklonowanie artykułu

Czy ktoś wie czy istnieje możliwość sklonowania artykułu, tak aby powstała 2 identyczne artykułu pod względem treści i historii, a różnice się jedynie nazwą pod którą występują? Chce dokonać takiej operacji po to, żeby podzielić artykuł na pół, ale zależy mi żeby oba nowe artykuły miały całą historię. Therud (dyskusja) 14:54, 11 gru 2016 (CET)

Ja to kiedyś tak zrobiłem, że przeniosłem pod nową nazwę, a w starym, gdzie zostało przekierowanie, anulowałem edycję. Potem już tylko drobne edycje wycinające treść i poprawki redakcyjne na osobnych historiach w obu wersjach. Paweł Ziemian (dyskusja) 15:38, 11 gru 2016 (CET)

Tak też uczyniłem, ale nie widzę tutaj nigdzie opcji anulowania ([2]). Therud (dyskusja) 15:47, 11 gru 2016 (CET) EDIT: udało mi się cofnąć operację, ale nadal jest jeden artykuł (znowu pod pierwotną nazwą). Therud (dyskusja) 15:51, 11 gru 2016 (CET)

Faktycznie to nie zachowuje historii, bo pozostawione przekierowanie dostaję nową. Chociaż na pierwszej pozycji jest w niej link o przenosinach do innego artykułu, który ma pełną historię. Znalazłem moją edycję w artykule „Jawor (Góry Hańczowskie)”. Paweł Ziemian (dyskusja) 15:53, 11 gru 2016 (CET)

Tylko, że w artykule Jawor (Góry Hańczowskie) nie ma historii z przed przenosin. Therud (dyskusja) 15:57, 11 gru 2016 (CET)

To chyba nie jest dobry pomysł. Jeżeli już to dzielenie historii - przenosisz tylko edycje ingerujące w wydzielaną połowę. Skomplikowane do zrobienia, ale wykonalne. Wargo (dyskusja) 16:04, 11 gru 2016 (CET)

Znalazłem jeszcze taki opis mw:Help:Export. Paweł Ziemian (dyskusja) 16:06, 11 gru 2016 (CET)

Re: Wargo: Artykuł ma już ponad 600 edycji, także czasowo jest to zupełnie nie opłacalne.

Re: Paweł Ziemian: Jest też mw:Extension:Duplicator, ale nie jest u nas zainstalowany. Therud (dyskusja) 16:14, 11 gru 2016 (CET)

• Ale... po co? Skoro wystarczy dać odpowiedni szablon i opis edycji? W dodatku duplikowanie tych samych edycji pomiędzy dwoma artykułami IMHO mogłoby przynieść tylko więcej szkody niż pożytku. Wostr (dyskusja) 17:16, 11 gru 2016 (CET)
• [konflikt edycji] Szkoda czasu na takie kombinacje - dla poprawnej licencji wystarczy w opisie edycji tworzącej hasło z przeniesioną treścią podać skąd pochodzi, na jego stronie dyskusji warto też wstawić odpowiednio wypełniony szablon {{Wydzielony}}, a w opisie edycji hasła masakrowanego podać "treść dotyczącą xxx przenoszę do hasła xxx". Proste, klarowne i nie wymaga specjalnych uprawnień. Michał Sobkowski _dyskusja 17:24, 11 gru 2016 (CET)

Nieprawidłowe działanie Wikipedia:Narzędzia/CzyWiesz

Gadżet Wikipedia:Narzędzia/CzyWiesz przestał wstawiać autorom haseł do dyskusji informacji o zgłoszeniu hasła do Czywiesza. Przykłady - hasła Baleron, Podatek węglowy, Day Tripper. --Teukros (dyskusja) 22:31, 11 gru 2016 (CET)

Uwaga! Serwer nie może przetworzyć tej edycji z powodu utraty danych sesji...

Cześć. Będąc zalogowanym wyskakuje mi to powiadomienie i nie mogę zapisywać zmian. O co w tym chodzi i jak się z tym rozprawić. Proszę o porady.

Pierwsza porada to: zapoznać się z instrukcją jak zgłaszać problemy. W szczególności ważne: nazwa przeglądarki, której używasz; czy problem występuje jeżeli używasz innych przeglądarek; czy po wyczyszczeniu pamięci podręcznej (i ciasteczek) jest bez zmian? --WTM (dyskusja) 10:18, 14 gru 2016 (CET)

• Zapoznałem się instrukcją zastosowując „purge” zarówno przed edycją, w trakcie i po ale nadal będąc zalogowanym wyskakuje mi ten sam komunikat. Edytować mogę, podczas edycji moje zmiany są widoczne ale gdy klikam w „Zapisz zmiany” pojawia się ten komunikat. Bez logowania wszystko jest ok. Zanim się ten problem pojawił dwa dni temu nic w preferencjach nie zmieniałem – wszystko jest tak samo już od długiego czasu. Mam Firefoxa i korzystam z niego też już bardzo długi czas i na wiki nigdy nie było z nim problemu. 14:33, 14 gru 2016 (CET)

  Prawdopodobnie chodzi o phab:T151770. Deweloperzy przypuszczają, że zawiniła ostatnia wersja FF i doradzają korzystanie z innej przeglądarki do czasu rozwiązania problemu przez Mozillę. Ponoć wyczyszczenie ciasteczek rozwiązuje problem tymczasowo. Pozdrawiam, Peter Bowman (dyskusja) 14:20, 25 gru 2016 (CET)

O {{odn}}

Chcę użyć {{odn}} i mam kłopot. Książka do której chcę dawać liczne przypisy jest dostępna w sieci (pomińmy kwestię legalności tego faktu), ale podzielona na rozdziały, każdy pod własnym url. Ponieważ chcę dawać url, to muszę (?) mieć dwa wpisy w bibliografii z tą samą książką, co słabo wygląda i jeszcze gorzej współpracuje z {{odn}}. Jak to się pokonuje?

Gżdacz (dyskusja) 00:11, 14 gru 2016 (CET)

• odn=a, ..., odn=z z przykładem w {{Odn#Parametry_zaawansowane}} ? IOIOI₂ 00:24, 14 gru 2016 (CET)
• Próbowałem, dostaję przypisy Abacki 2007a, Abacki 2007b, itd., co stwarza wrażenie dwóch książek, a tymczasem jest jedna. W dodatku w Bibliografii najchętniej miałbym tylko jeden wpis, ale dwa url-e. Gżdacz (dyskusja) 00:37, 14 gru 2016 (CET)

• (Chyba) możesz podać url dla książki i url dla rozdziału w {{Cytuj książkę}}. Ale podanie autora rozdziału skutkuje generowaniem identyfikatora przypisu dla rozdziału (wg opisu szablonu). IOIOI₂ 00:48, 14 gru 2016 (CET)

• Ja bym kwestii legalności nie pomijał i zastosował w tym przypadku zasadę odnoszącą się do linków zewnętrznych - nie powinno się dodawać odsyłaczy do stron zawierających materiały łamiące prawo. Jeszcze tego brakuje, byśmy w przypisach linkowali np. do chomikuj.pl czy innych hostingów... Muri (dyskusja) 00:50, 14 gru 2016 (CET)
  • Racja. Usunę url z przyczyn prawnych, a mój problem techniczny przy okazji śam się zlikwiduje. Gżdacz (dyskusja) 07:02, 14 gru 2016 (CET)
• A może da się url przemycić w parametrze loc? PuchaczTrado (dyskusja) 09:57, 14 gru 2016 (CET)

  Tak, to zadziała, do linku można dorzucić nawet ikonkę otwartego dostępu - przykładowo {{odn|Nazwisko|Rok|loc={{Otwarty dostęp}} [link do rozdziału 1 Rozdział 1]|s=strony}} i {{odn|Nazwisko|Rok|loc={{Otwarty dostęp}} [link do rozdziału 2 Rozdział 2]|s=strony}}. Muri (dyskusja) 10:33, 14 gru 2016 (CET)

NWE a DisFixer

Postanowiłm testować Nowy Edytor Wikitekstu, czli NWE. Dziś odkryłem, że jest on jakoś niekompatybilny z DisFikserem, którego nawykowo używam. Po ustawieniu wszystkich rozwiązań dezambiguaji w DisFikserze, niestety NWE nie przejmuje automatycznie robionych zmian w kodzie (a dotyczą też zastąpienia przekierowań ich docelowymi stronami oraz sprzątania kodu). W efekcie DisFixer dla użytkownika NWE sprowadza sie do wskaźnika problemu, który trzeba korygować ręcznie. Pisałem na stronie do zgłaszania problemów z NWE, dostałem sugestię, to to DisFixer wymaga korekty. Gżdacz (dyskusja) 16:12, 19 gru 2016 (CET)

Tech News: 2016-51

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.

Wiadomości techniczne

• Z powodu przerwy świątecznej następne wydanie Nowości Technicznych zostanie wysłane 9 stycznia 2017.
• Redaktorzy newslettera technicznego chcą poznać Twoją opinię. Czy otrzymałeś w tym roku informację, której oczekiwałeś? Czy pominęliśmy w nim coś ważnego w 2016 roku? Jakie rodzaje informacji znalazły się w nim za późno? Daj nam znać! Możesz napisać w swoim języku. Dziękujemy!

Ostatnie zmiany

• Administratorzy i administratorzy tłumaczeń mogą teraz użyć Special:PageLanguage na wiki z rozszerzeniem Translate. Można więc określić, w jakim języku jest dana strona. Rozszerzenie Translate użyje tego języka jako język źródłowy podczas tłumaczenia. Poprzednio był to zawsze domyślny język wiki, zazwyczaj angielski. [3]
• Wiki połączone z Wikidanymi mogą teraz korzystać z funkcji parsera {{#statements: }}, aby pobrać sformatowane dane. Możesz też użyć {{#property: }} do pobrania surowych danych. Można zauważyć różnicę między tymi dwoma wyrażeniami. Są też nowe podobne funkcje dla Lua. [4]

Problemy

• Niektóre filtry nadużyć dla przesyłanych plików nie działały tak jak powinny. Nie wiemy jeszcze dokładnie, które filtry nie działały. Oznacza to, że niektóre pliki, których przesłaniu powinny zapobiec te filtry, zostały pomyślnie przesłane na wiki. Dotyczyło to MediaWiki.org i Testwiki od 13 października, a Commons i Meta od 17 października. Z innymi wiki ten problem występował od 17 listopada. [5]

Zmiany w tym tygodniu

• Nie będzie nowej wersji MediaWiki w tym, ani w następnym tygodniu.

Spotkania

• Następne spotkanie z zespołem odpowiedzialnym za edytor wizualny odbędzie się 3 stycznia o 20:00 (UTC). Podczas tego spotkania będziesz mógł poinformować twórców o tym, jakie błędy uważasz za najważniejsze. Zobacz jak dołączyć.

Przyszłe zmiany

• Zakończyło się Badanie Życzeń Społeczności 2016. Zdecydowano w nim, jak zespół Community Tech team będzie pracował podczas roku 2017. Możesz zobaczyć wyniki.

Wiadomości przygotowane przez ambasadorów technicznych i opublikowane za pomocą systemu komunikatów globalnych • Dołącz do zespołu • Przetłumacz na swój język • Uzyskaj pomoc • Wyraź swoją opinię • Subskrybuj lub zrezygnuj z subskrypcji.

21:33, 19 gru 2016 (CET)

Załatwione, ~Cybularny^{Napisz coś ✉} 21:41, 19 gru 2016 (CET)

Szablon:Wymowa

Witam, dodałem wymowę miejscowości w artykule La Carneille. Jednak moim zdaniem to trochę brzydko wygląda. Czy dałoby radę tak przeredagować szablon, aby nazwa hasła pozostała czarna, a ikona głośnika ewentualnie niebieska i żeby plik wymowy uruchamiał się po kliknięciu na tą ikonę. Moim zdaniem tak by było przejrzyściej. Jak dodałem, to jest tylko moje zdanie i według Was powinno zostać tak jak jest. Zapraszam do pisania opinii :) Tournasol Słucham :) 15:36, 20 gru 2016 (CET)

Ikona głośnika jest wstawiona przez CSS. Tam jest tylko link do pliku medialnego, a linki są niebieskie. Paweł Ziemian (dyskusja) 17:16, 20 gru 2016 (CET)

Wydaje mi się, że nie w taki sposób powinno się ten szablon umieszczać. Pogrubiony tytuł powinien zostać jaki jest, a szablon wymowy umieścić zaraz po nim (np. w nawiasie). A już w ogóle najlepiej, tekstem w tym szablonie był zapis tego, jak wymawiać bądź obok tego szablonu (czyli <tytuł> (<wymowa> <szablon wymowy>) albo <tytuł> (<szablon wymowy z zapisem wymowy>). Wostr (dyskusja) 21:12, 20 gru 2016 (CET)

Od zapisu wymowy jest {{IPA}}, który również pozwala na dodanie dźwięku na przykład „la kaʁ.nɛj ( odsłuchaj)”. Paweł Ziemian (dyskusja) 21:37, 20 gru 2016 (CET)

No okej, ale tak czy inaczej taki szablon jak {{wymowa}} nie powinien być umieszczany w taki sposób, jak w tym artykule; albo powinna być podana wymowa będąca linkiem do audio, albo napis „wymowa”. I poza wytłuszczonym tytułem artu. Wostr (dyskusja) 21:43, 20 gru 2016 (CET)

Zmieniłem trochę w podanym powyżej artykule. Tak chyba jest lepiej. Tournasol Słucham :) 21:54, 20 gru 2016 (CET)

Problem z wykresem

[6] Wykres fajny, ale legnda (2012-2016) cos miesza, bo wszystko w tym samym kolorze. Ktora linia jest do ktorego roku? Daloby sie to poprawic? (Ping Wikipedystka:Enstropia, autorka wykresu w artykule, ktora tez nie wie jak to naprawic i mysle, ze chetnie przeczyta odpowiedzi w tym watku). --Piotr Konieczny aka Prokonsul Piotrus _Słucham? 13:45, 21 gru 2016 (CET)

Dodam tylko, że jak się zrobi podgląd zmian to te kolory są widoczne Marycha80 (quaere) 13:49, 21 gru 2016 (CET)

Chyba nie można podawać nazw kolorów tylko kod. Therud (dyskusja) 13:56, 21 gru 2016 (CET)

@Enstropia, @Piotrus Z moich prób wynika, że wystarczy nazwy kolorów zmienić na małe litery: Purple na purple, LightSkyBlue na lightskyblue itd. --CiaPan (dyskusja) 16:57, 21 gru 2016 (CET)

Écrouves (Meurthe i Mozela)

Niestety narobiłem trochę bałaganu. Proszę o przeniesienie artykułu Écrouves (Meurthe i Mozela) do Écrouves. Wcześniej utworzyłem tam stronę ujednoznaczniającą, jednak druga miejscowość nie nazywa się tak samo, lecz tylko podobnie... Więc cofnąłem swoje edycje, ale przekierowania już nie dam rady cofnąć. Ponadto trzeba będzie poprawić też linkujące... Przepraszam za kłopot, Tournasol Słucham :) 17:10, 21 gru 2016 (CET)

@Tournasol7. Mam nadzieję, że o to chodziło. Jeśli tak, to Załatwione. Torrosbak (dyskusja) 13:06, 22 gru 2016 (CET)

@Torrosbak, tak, o to chodzi. Wielkie dzięki. Tournasol Słucham :) 14:39, 22 gru 2016 (CET)

Pomocy! (z zapytaniem sql)

Czy jest na sali ktoś, kto ogarnia bazy danych? Na en.wiki działa takie fajne cuś, gdyby zapuścić to samo zapytanie dla pl.wiki byłby w sam raz cudny materiał na podsumowanie roku (choćby dla @Magalia i mediów społecznościowych). @Masti mówi, że dałoby się to zapuścić dla zrzutu bazy danych, nie musi być przecież wersja live (bo tę mogliby chyba tylko ludzie z dostępem deweloperskim wykonać). Ktoś chętny do pomocy? Aha, za inspirację posłużył @WTM, który podrzucił link do tego materiału. //Halibutt 12:54, 22 gru 2016 (CET)

https://quarry.wmflabs.org/ Wargo (dyskusja) 14:35, 22 gru 2016 (CET)

Widać już jakieś rezultaty. No pięknie: w czołówce najczęściej edytowanych Jarosław Maciej Goliszewski, 1104 edycje, z czego sam Paul Fishman PL wykonał 1057 zmian. Nie wiem czy jakieś mądre wnioski z takiego zestawienia będzie można wyciągnąć. --WTM (dyskusja) 17:18, 22 gru 2016 (CET)

Zapytania SQL dla pl.wiki: 14975 i 14976. --The Polish (query) 23:13, 22 gru 2016 (CET)

Szablon:Martwy link dyskusja

Czy jest możliwość, aby ktoś zedytował kategoryzację wykonywaną przez ten szablon w taki sposób, aby do K:DEAD dodawane były tylko linki z przestrzeni nazw Dyskusja? Aktualnie dodawane są także Dyskusja wikipedysty, gdy artykuł z martwym linkiem zostanie przeniesiony do brudnopisu. --Kamil-b DYSKUSJA 13:09, 24 gru 2016 (CET)

Załatwione ~malarz pl ^PISZ 15:05, 24 gru 2016 (CET)