Wikipedia:Kawiarenka/Kwestie techniczne: Różnice pomiędzy wersjami

Z Wikipedii, wolnej encyklopedii
Usunięta treść Dodana treść
Znacznik: Wiadomość MassMessage
Linia 588: Linia 588:
[[Wikipedysta:Gżdacz|Gżdacz]] ([[Dyskusja wikipedysty:Gżdacz|dyskusja]]) 18:57, 9 sty 2017 (CET)
[[Wikipedysta:Gżdacz|Gżdacz]] ([[Dyskusja wikipedysty:Gżdacz|dyskusja]]) 18:57, 9 sty 2017 (CET)
: Jest coś takiego jak [[:en:Template:CSS image crop]], ale to ładuje cały obraz i tylko wyświetla fragment. [[Wikipedysta:Paweł Ziemian|Paweł Ziemian]] ([[Dyskusja wikipedysty:Paweł Ziemian|dyskusja]]) 19:44, 9 sty 2017 (CET)
: Jest coś takiego jak [[:en:Template:CSS image crop]], ale to ładuje cały obraz i tylko wyświetla fragment. [[Wikipedysta:Paweł Ziemian|Paweł Ziemian]] ([[Dyskusja wikipedysty:Paweł Ziemian|dyskusja]]) 19:44, 9 sty 2017 (CET)

== [[m:Special:MyLanguage/Tech/News/2017/02|Tech News: 2017-02]] ==

<section begin="technews-2017-W02"/><div class="plainlinks mw-content-ltr" lang="pl" dir="ltr"><div class="plainlinks">
Najnowsze '''[[m:Special:MyLanguage/Tech/News|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ą [[m:Special:MyLanguage/Tech/News/2017/02|tłumaczenia]] na inne języki.

'''Ostatnie zmiany'''
* Możesz teraz korzystać ze [[mw:Special:MyLanguage/Help:Tabular Data|zbiorów danych umieszczanych na Commons]]. Zobacz [[w:en:Template:Graph:Weather monthly history|przykład]] wykorzystujący [[c:Data:Ncei.noaa.gov/weather/New York City.tab|to źródło]]. [https://lists.wikimedia.org/pipermail/wikitech-l/2016-December/087313.html]
* Jest nowa funkcja eksperymentalna, którą można włączyć: [[mw:Special:MyLanguage/2017 wikitext editor|tryb wikitekstu dla edytora wizualnego]]. Możesz [[Special:Preferences#mw-prefsection-betafeatures|go wypróbować]].
* Podczas aktualizacji strony z tłumaczeniami na wiki z [[mw:Special:MyLanguage/Extension:Translate|rozszerzeniem Translate]] istniejące tłumaczenia będą oznaczane jako nieaktualne zamiast usuwane. [https://phabricator.wikimedia.org/T60429]
* [[mw:MediaWiki 1.29/wmf.7|Nowa wersja]] MediaWiki została zainstalowana na wszystkich wiki w zeszłym tygodniu ([[mw:MediaWiki 1.29/Roadmap|kalendarz]]).
* [[mw:MoodBar|MoodBar]] został usunięty ze wszystkich wiki Wikimedia. [https://phabricator.wikimedia.org/T131340]
* <span title="Zaawansowane">[[File:Octicons-tools.svg|15px|link=]] Usunięto opcję <code>live</code> z narzędzia do tworzenia podpowiedzi Tipsy. Gadżety i skrypty użytkowników z tego korzystające muszą zostać zaktualizowane. [https://phabricator.wikimedia.org/T85048]

'''Problemy'''
* Edytujący, którzy korzystają z Firefoxa w wersji 50 mogą być wylogowywani podczas zapisywania edycji lub może się ona nie udać. Jest to spowodowane błędem w przeglądarce. Dopóki nie zostanie to poprawione, możesz wejść w <code>about:config</code> i ustawić network.cookie.maxPerHost na 5000. Firefox 50 jest obecną wersją tej przeglądarki. [https://phabricator.wikimedia.org/T151770]

'''Zmiany w tym tygodniu'''
* Nie będzie instalowana nowa wersja MediaWiki w tym tyodniu z powodu odbywania się [[mw:Wikimedia Developer Summit|Wikimedia Developer Summit]].

'''''[[m:Special:MyLanguage/Tech/News|Wiadomości]]''' przygotowane przez [[m:Special:MyLanguage/Tech/News/Writers|ambasadorów technicznych]] i opublikowane za pomocą systemu [[m:Special:MyLanguage/User:MediaWiki message delivery|komunikatów globalnych]] • [[m:Special:MyLanguage/Tech/News#contribute|Dołącz do zespołu]] • [[m:Special:MyLanguage/Tech/News/2017/02|Przetłumacz na swój język]] • [[m:Tech|Uzyskaj pomoc]] • [[m:Talk:Tech/News|Wyraź swoją opinię]] • [[m:Global message delivery/Targets/Tech ambassadors|Subskrybuj lub zrezygnuj z subskrypcji]].''
</div></div> <section end="technews-2017-W02"/> 20:12, 9 sty 2017 (CET)
<!-- Wiadomość wysłana przez User:Johan (WMF)@metawiki korzystając z listy na https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=16213513 -->

Wersja z 21:12, 9 sty 2017

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


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)[odpowiedz]

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)[odpowiedz]
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)[odpowiedz]
@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)[odpowiedz]
  • Przypominam o Pomoc:Ponadczasowość. Marek Mazurkiewicz (dyskusja) 00:18, 23 lip 2016 (CEST)[odpowiedz]
    • 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) [odpowiedz]
      • 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)[odpowiedz]
        • 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)[odpowiedz]
  • 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)[odpowiedz]
  • 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)[odpowiedz]
  • @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)[odpowiedz]
  • Powstał {{aktualizuj po}}. Wostr (dyskusja) 20:51, 17 gru 2016 (CET)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]
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)[odpowiedz]
@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)[odpowiedz]
@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)[odpowiedz]
@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):
.
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):
.
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)[odpowiedz]
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)[odpowiedz]
@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)[odpowiedz]
z LaTeXem niestety nie pomogę :) masti <dyskusja> 15:06, 2 wrz 2016 (CEST)[odpowiedz]
  • @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)[odpowiedz]
  • @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)[odpowiedz]
  • 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)[odpowiedz]
  • @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)[odpowiedz]
  • 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)[odpowiedz]
@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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]
 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. ~CybularnyNapisz coś ✉ 15:26, 1 lis 2016 (CET)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
 Za u mnie też poprawnie nie działa graficzny. 46.112.52.88 (dyskusja) 17:06, 6 sty 2017 (CET)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]
O, tak tak. To wystarczy, bo ten przycisk myli (gdy się szuka przycisku wikizacji). Hedger z Castleton (dyskusja) 14:43, 5 lis 2016 (CET)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
  • 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)[odpowiedz]
  • 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)[odpowiedz]
    • 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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]
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)'[odpowiedz]

@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)[odpowiedz]

@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)[odpowiedz]
Jaki skrypt? Link poproszę. Paweł Ziemian (dyskusja) 18:39, 12 lis 2016 (CET)[odpowiedz]
Wikipedysta:Matma_Rex/prettyref.js KABEXXXIOR DYSKUSJA 19:12, 12 lis 2016 (CET)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
Również bardzo boleśnie bym odczuł niemożność używania {{r}}. Gżdacz (dyskusja) 10:46, 13 lis 2016 (CET)[odpowiedz]
  • 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)[odpowiedz]
  • 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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
„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)[odpowiedz]
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)[odpowiedz]
  • 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)[odpowiedz]
  • 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)[odpowiedz]
  • 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)[odpowiedz]
  • 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)[odpowiedz]
    • 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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

@Ciacho5 Ekspertem nie jestem, ale wydaje mi się, że mógłbyś wyeksportować stronę z historia edycji przy użyciu Special:Export a potem zaimportować w swojej przestrzeni używając Special:Import i pracować na takiej kopii. pbm (dyskusja) 14:54, 28 gru 2016 (CET)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]
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)[odpowiedz]
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)[odpowiedz]
Tylko, że w artykule Jawor (Góry Hańczowskie) nie ma historii z przed przenosin. Therud (dyskusja) 15:57, 11 gru 2016 (CET)[odpowiedz]
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)[odpowiedz]
Znalazłem jeszcze taki opis mw:Help:Export. Paweł Ziemian (dyskusja) 16:06, 11 gru 2016 (CET)[odpowiedz]
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)[odpowiedz]
  • 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)[odpowiedz]
  • [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)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]
  • 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)[odpowiedz]
  • Kiedyś tak miałem na Chromie przy długim czasie edytowania bez zapisania zmian. Być może to jakiś drobny problem z uwierzytelnianiem. Rozwiązanie, jakie było skuteczne: Aby nie utracić zmian należało wcisnąć przycisk Zmiany i po obejrzeniu zmian działało już poprawnie robienie Zapisz lub Podgląd i potem Zapisz. Daj znać, czy pomaga. --Wiklol (Re:) 14:40, 25 gru 2016 (CET)[odpowiedz]

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)[odpowiedz]

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)[odpowiedz]

Nadgorliwy VE

Kiedy chcę napisać S (duże, shift+s) Visual Editor otwiera okienko zapisu. Bardzo denerwujące, bo okazuje się, że całe zdanie zamiast w tekst poszło w opis zmian. Jak to wyłączyć? Skrótów klawiaturowych mogę nie używać (oprócz CTRL=C, V, A) Ciacho5 (dyskusja) 12:36, 26 gru 2016 (CET)[odpowiedz]

Jaka przeglądarka? --Wargo (dyskusja) 14:57, 26 gru 2016 (CET)[odpowiedz]

Od kiedy to robi? Spróbuj:

  • Na innej przeglądarce
  • Jako niezalogowany
  • Na innej wiki

Wargo (dyskusja) 18:14, 26 gru 2016 (CET)[odpowiedz]

@Ciacho5 Naprawiłeś? Wargo (dyskusja) 20:16, 28 gru 2016 (CET)[odpowiedz]

  • Nieee :(.

W Operze tak robi niezależnie od zalogowania, w Chromie niezależnie od zalogowania działa poprawnie. Ale kiedy pisze mail w Operze, to Shift+s nie włącza zapisywania. Nic to, będę się starał pamiętać. Ha, w nowszej operze też dział poprawnie. Może mnie to zachęci do przeniesienia się na nowszą. Dzięki. Ciacho5 (dyskusja) 23:01, 28 gru 2016 (CET)[odpowiedz]

Winne mogą być dodatki i dlatego na nowej może działać dobrze, ponieważ pewnie używasz ich na różnych komputerach być może z różnymi dodatkami. U mnie dodatki powodują, że VE nie kończy się ładować i nic nie działa, nawet przełączenie w tryb wikikodu, bo to jest ukryte za warstwą z paskiem postępu. 46.112.131.96 (dyskusja) 19:27, 29 gru 2016 (CET)[odpowiedz]

Uciążliwe przemieszczanie się po długich stronach na ekranach dotykowych

Mam problem z korzystaniem z długich stron na tablecie. Kiedy wchodzę w widoku mobilnym np. do hasła Polska to mam zwinięty spis treści i mogę szybko przemieścić się do oczekiwanej sekcji w haśle. Ale nie mam jak do tego spisu treści wrócić. Jest możliwość zwijania sekcji, ale przeładowanie strony analuje zwinięcia. Jeszcze gorzej jest na stronach poza przestrzenią główną, np. na tej stronie gdzie właśnie piszę - kompletny brak w widoku mobilnym spisu treści. Preferuję osobiście widok desktopowy na tablecie, ale przewijanie palcem po to, żeby zmienić widok z jednej sekcji na inną jest baaaardzo długotrwałe. Myślę, że dobrym rozwiązaniem byłoby dodawanie linku "top/góra/spis" obok linku edytuj automatycznie jeśli liczba sekcji na stronie przekracza jakąś wartość. Zarówno w trybie mobilnym, jak i desktopowym. Małe, a bardzo by pomogło w nawigacji po długich stronach. 194.149.88.126 (dyskusja) 18:34, 27 gru 2016 (CET)[odpowiedz]

Pamiętam, że kiedyś w niektórych miejscach dodawano takie szablony przenoszące na górę strony. Ale IMHO obecnie to raczej kwestia, którą należałoby rozwiązać systemowo, a nie poprzez ręczne dodawanie w artykułach. Wostr (dyskusja) 19:21, 27 gru 2016 (CET)[odpowiedz]
W haśle zbiorczym o bootlegach E. Presleya dodałem w dwóch miejscach [[#top|Na górę strony]], co pozwalało na łatwe przewijanie na mobilnych urządzeniach, bo strona jest b. obszerna. Niestety bot @The Polisha postanowił pozbyć się tych "udogodnień". Generalnie powinno być to - tak jak wyżej Wostr napisał - rozwiązane systemowo, ale tak długich haseł w pl.wiki jest garstka, może kilkanaście, tak że można było chyba przymknąć oko na to jedno wywołanie w haśle zbiorczym. --Pit rock (dyskusja) 20:38, 29 gru 2016 (CET)[odpowiedz]
I to jest porażka, że w polskiej Wikipedii jest tylko kilka haseł tak rozległych. Na angielskiej wygląda to całkiem inaczej. Myślę więc, że powinno być to rozwiązane faktycznie systemowo i to na wszystkich Wikipediach. 164.126.216.240 (dyskusja) 21:14, 29 gru 2016 (CET)[odpowiedz]

Dobrą opcją byłoby pozostawianie zwiniętego spisu treści przy górnej części ekranu tableta. Wtedy możnaby było się szybko poruszać pomiędzy sekcjami. Jest to rozwiązanie stosowane na wielu stronach, że menu pozostaje albo statyczne, albo właśnie kończy swoją wędrówkę ku górze, gdy ma uciec poza obszar widoczny. 46.112.131.96 (dyskusja) 19:17, 29 gru 2016 (CET)[odpowiedz]
Dobrą może by i było, ale na razie w widoku mobilnym tej strony (kawiarenka) spis nie pojawia się wcale. Podobnie na stronach dyskusji haseł, czy wikipedystów. Czy pojawia się w ogóle poza przestrzenią główną? 194.149.88.126 (dyskusja) 19:51, 29 gru 2016 (CET)[odpowiedz]
Więc należy zrobić albo bota, który spisy będzie dodawał, abo zrobić tak, że każda strona ma automatycznie spis treści. Co do połowy kolumny - dlaczego Wikipedia i siostrzane do tej pory muszą mieć wersję mobilną? Czy nie można zamiast bazować na User-agent oraz wuwołaniach mobilnych bądź normalnych - bazować na szerokości ekranu, tak, że nawet gdy zmniejszymy okno na przeglądarce na PC pojawi się wersja "mobilna" na małe wyświetlacze? Należy odchodzić od starych zawodnych rozwiązań na rzecz nowych ulepszonych standardów. CSS przewiduje możliwość ładowania różnych stylów zależnie od maksymalnej lub minimalnej szerokości "okna" przeglądarki. Przy okazji prostsze testowanie strony.
Faktycznie to jest aroganckie, ponieważ niektórzy mają potrzebę przeczytać wstęp i 1 lub 2 sekcje szczegółowo, które go zainteresują i ma do tego prawo. Sorry, ale nie każdy czyta w całości każdy artykuł. 164.126.216.240 (dyskusja) 21:54, 29 gru 2016 (CET)[odpowiedz]

Sołectwa w infoboksie

Wnoszę o wstawienie komentu w szablonie, żeby ludzie nie wstawiali tam nazwiska sołtysa.

Czy można botem wyciągnąć listę wsi, gdzie sołectwo opisane jest dwoma wyrazami? Przypuszczam, że większość z tego to imiona i nazwiska sołtysów, zaś nieliczne to dwuwyrazowe nazwy miejscowości. Ciacho5 (dyskusja) 19:43, 28 gru 2016 (CET)[odpowiedz]

Przeglądarka, dodatki a domyślny edytor graficzny

Przy próbie edycji stron nie ma obecnie linka "Edytuj" oraz "Edytuj kod" jak było dawniej. Wtedy, gdy wystąpił błąd podczas ładowania edytora można było zawsze skorzystać z edytora wikikodu (który z resztą preferuję). Efekt na firefoxie (aktualnym) z dodatkami: User Agent Switcher, ublock i Ghostery + standardowy zestaw wtyczek, efekt u mnie jest następujący:

  • Edytor zaczyna się ładować
  • Pasek postępu osiąga 100%
  • Cała strona pozostaje nadal wyszarzona (rozjaśniona)
  • Nie da się w nic kliknąć.

Jakie widzę rozwiązania:

  • Przywrócić 2 linki do edycji - graficzny i kod źródłowy
  • lub czarny ołówek przełączający tryby dać na sam wierzch stylami css: position:relative/absolute, z-index:odpowiednio duża wartość.

Koniecznie opisać do czego służy ów ołówek, ponieważ nowi raczej nie będą wiedzieli do czego on służy.

Obecnie trzeba się nieźle nagimnastykować, by w razie zacięcia się ładowania edytora graficznego przełączyć się w tryb edycji wikikodu. 46.112.131.96 (dyskusja) 18:44, 29 gru 2016 (CET)[odpowiedz]

Też uważam, że domyślnie powinno tak być, ale.. cóż, narazie jak tak nie jest to pozostaje Ci stworzyć konto, przejść do preferencji (Specjalna:Preferencje#mw-prefsection-editing) i (w sekcji Edytor) ustawić tam sam edytor kodu źródłowego lub 2 przyciski. --Kamil-b DYSKUSJA 18:55, 29 gru 2016 (CET)[odpowiedz]
No ale myślę, że ktoś z odpowiednimi uprawnieniami mógłby chociaż te 2 style CSS dopisać. To też by sprawę załatwiło. Ołówek widzę, że jest zatytułowany, a gdy zrobi się ciemniejszy od reszty po dodaniu z-index - zwróci uwagę i po dłuższym oczekiwaniu bez rezultatu użytkownik go w końcu kliknie - jako, że symbol zachęca do edycji. 46.112.131.96 (dyskusja) 19:05, 29 gru 2016 (CET)[odpowiedz]

Można odpiąć szablon:Takson infobox od wikidata?

Napisałem artykuł Peltanthera floribunda i nie umieściłem w nim ilustracji. Najwyraźniej z powodu wikidata obrazek się pojawił. Problem w tym, że obrazek z Commons i wikidata przedstawia opisany gatunek w niewielkiej części i jest nieczytelny. Bardziej wprowadza w błąd niż w czymkolwiek pomaga. Tego typu i co gorsza całkiem błędne ilustracje na Commons zdarzają się nierzadko. Byłoby koszmarem, gdyby ilustracje same wskakiwały nam do infoboksów poza możliwością śledzenia zmian po stronie pl.wiki. Pozostałe dane taksonomiczne w szablonie są jeszcze bardziej wrażliwe. Kenraiz (dyskusja) 01:57, 30 gru 2016 (CET)[odpowiedz]

Ewentualnie doraźnie w przypadku, gdy ilustracja w Commons/Wikidata jest problematyczna, przydałoby się jakoś móc zablokować jej eksponowanie w szablonie w pl.wiki. Samo odlinkowanie w wikidata niewiele da, bo ktoś znów przeniesie. Pilnowanie Wikidata i Commons przekracza moje możliwości, choć na Commons spędzam sporo czasu i co mogę to naprawiam. Kenraiz (dyskusja) 02:18, 30 gru 2016 (CET)[odpowiedz]
@Kenraiz Wystarczy w infoboxie w polu obrazek dodać słowo "nie" i już grafika z commons nie jest pobierana. We wskazanym artykule już to poprawiłem. KamilK7 (dyskusja) 09:19, 30 gru 2016 (CET)[odpowiedz]
Ok, dzięki. Kenraiz (dyskusja) 09:49, 30 gru 2016 (CET)[odpowiedz]

Witajka

Zdaje mi się, że wszyscy nowi dostają z automatu witajkę. Od czasu do czasu trafiam jednak na dyskusje nowicjuszy bez niej (np. Dyskusja wikipedysty:Eliza1977). Coś nie działa czy to jednak przeoczenie żywego człowieka? Ciacho5 (dyskusja) 23:36, 30 gru 2016 (CET)[odpowiedz]

Skrypt na dodatkowe przyciski opisu edycji kontra nowy edytor kodu źródłowego.

Witam, od dłuższego czasu korzystam ze skryptu na dodatkowe opisy edycji Skalee'ego (tak się odmienia jego nick?), ale dziś dowiedziałem się o nowym edytorze kodu źródłowego, który współpracuje/jest wykonany na podstawie VE. No i tak sobie testując go, dochodzę do wniosku, że przy nim zostanę, ale próbując zapisać zmianę, patrzę, a tu tylko domyślne przyciski opisu edycji! Pytanie: czy ktoś podjąłby się zadania zedytowania jego skryptu w taki sposób, aby był kompatybilny z VE? Podpowiem, że jest chyba napisany w CoffeeScript. Pozdrawiam. Kamil-b DYSKUSJA 10:39, 31 gru 2016 (CET)[odpowiedz]

  • @Kamil-b Ja też testuję NWE. Niestety, ma on jeszcze wady, z których poważną jest to, że w razie edytowania sekcji wielosekcyjnego dokumentu w opisach edycji nie udostępnia informacji, która to była sekcja ani linku do niej. Dlatego pinguję Cię, bo z opisu mojej edycji nie zgadniesz, że odpowiadam właśnie Tobie. To jest już zgłoszone deweloperom, ale moim zdaniem ważniejsze, niż dodatkowe dostępne automatycznie opisy. Gżdacz (dyskusja) 10:46, 31 gru 2016 (CET)[odpowiedz]

skad w Sweet Dreams (singel Beyoncé Knowles) pojawia sie Ukryta kategoria: Szablon Władca z indywidualnym opisem

witam; Pytanie mam bo jakos nie moge prosto tego ogarnac... Skad w Sweet Dreams (singel Beyoncé Knowles) pojawia sie Ukryta kategoria: Kategoria:Szablon Władca z indywidualnym opisem --Ignasiak (dyskusja) 20:09, 31 gru 2016 (CET)[odpowiedz]

To przez szablon {{tabela przebojów}}, który czeka w kolejce do zastąpienia navboksami (po Wikipedia:Poczekalnia/kwestie techniczne/2013:08:24:Szablon:Władca). Niestety rąk do pracy brakuje aby zakończyć ich żywot. ~malarz pl PISZ 21:16, 31 gru 2016 (CET)[odpowiedz]

Span

Co robią znaczniki 'span' w artykule Fantasound? Beno @ 22:18, 31 gru 2016 (CET)[odpowiedz]

Śmiecą kod? --WTM (dyskusja) 22:26, 31 gru 2016 (CET)[odpowiedz]
Odnoszę wrażenie, że nic nie robią, że to jest balast importu z jakiejś strony www z inną technologią. Beno @ 00:16, 1 sty 2017 (CET)[odpowiedz]
Standardowe zachowanie narzędzia do tłumaczenia - a ten artykuł jest przetłumaczony, zob. historia edycji--Felis domestica (dyskusja) 00:24, 1 sty 2017 (CET)[odpowiedz]
Standardowe, znaczy dobre czy złe? Usuwać? Beno @ 12:16, 1 sty 2017 (CET)[odpowiedz]
@Beno W tym wypadku standardowe=typowe ;) Usuwać, to śmietnik będący produktem ubocznym niedopracowanego narzędzia. @Halibutt pewnie używa VE i nie zauważył, bo sam by usunął. Narzędzie nie tłumaczy też cytowań, które trzeba dokładać ręcznie :( --Felis domestica (dyskusja) 12:27, 1 sty 2017 (CET)[odpowiedz]
@Felis domestica Już tłumaczy :) A raczej przymierza się do, sprawdź sam. //Halibutt 11:03, 2 sty 2017 (CET)[odpowiedz]

Rejestr oznaczania

Chyba jest jakiś problem. Opisy w rejestrze wyświetlają się w angielskim. Sebek A. (dyskusja) 20:58, 1 sty 2017 (CET)[odpowiedz]

Do czwartku wytrzymasz :) Załatwione Wargo (dyskusja) 22:57, 1 sty 2017 (CET)[odpowiedz]
Ponadto proponuję, aby w rejestrze (nie tylko tym) używać form czasu przeszłego w trzeciej osobie. Już coś takiego proponowałem i przez jakiś czas tak było. @Tar Lócesilion, @Masti, @Sławek Borewicz, co o tym sądzicie? Sebek A. (dyskusja) 13:57, 2 sty 2017 (CET)[odpowiedz]
Mogą być: betawiki:MediaWiki:Logentry-review-approve/pl i betawiki:MediaWiki:Logentry-review-approve-auto/pl ? Wargo (dyskusja) 14:24, 2 sty 2017 (CET)[odpowiedz]
To byłoby odpowiednie. Sebek A. (dyskusja) 14:36, 2 sty 2017 (CET)[odpowiedz]
@Wargo, już jest czwartek. Jeszcze widzę tam angielski. Coś się stało? Sebek A. (dyskusja) 15:32, 5 sty 2017 (CET)[odpowiedz]
Po 21:00 powinno być. Chyba że tłumaczenia publikowane są w innym cyklu. Wargo (dyskusja) 15:36, 5 sty 2017 (CET)[odpowiedz]
Załatwione Już są Wargo (dyskusja) 21:59, 5 sty 2017 (CET)[odpowiedz]

Wykres umarł. Ktoś ma pomysł dlaczego? Therud (dyskusja) 22:12, 1 sty 2017 (CET)[odpowiedz]

Naprawiłem Wargo (dyskusja) 15:16, 2 sty 2017 (CET)[odpowiedz]
Dzięki. A gdzie był problem? Therud (dyskusja) 19:07, 2 sty 2017 (CET)[odpowiedz]
W Szablon:Wykres:Rozbudowa metra w Moskwie/dane może być tylko JSON; dodanie kategorii to zakłóciło. Wargo (dyskusja) 19:34, 2 sty 2017 (CET)[odpowiedz]

Panel boczny

Zmieniła się pozycja panelu bocznego na podstronie obserwowane. Znajduje się on teraz pod listą edycji. Eurohunter (dyskusja) 17:47, 2 sty 2017 (CET)[odpowiedz]

U mnie tak samo. Czyli problem jest od strony Wikipedii. ~CybularnyNapisz coś ✉ 18:42, 2 sty 2017 (CET)[odpowiedz]
W MediaWiki:Watchlist-summary brakuje </div>. Wargo (dyskusja) 18:45, 2 sty 2017 (CET)[odpowiedz]
@Wargo Gdzie brakuje? Na końcu? Powinno być </div></div>? --WTM (dyskusja) 18:51, 2 sty 2017 (CET)[odpowiedz]
Tak Wargo (dyskusja) 18:52, 2 sty 2017 (CET)[odpowiedz]

Załatwione

Nieindeksowanie stron w DNU

Przy stoliku z zasadami mieliśmy krótką dyskusję pt. Ekspresowe kasowanie treści autopromocyjnych. Czy ktoś z technicznych dałby radę wmontować w szablon od DNU opcję nieindeksowania stron w PG, w których jest umieszczony (poza tymi znajdującymi się w naprawie)? Wostr (dyskusja) 02:24, 4 sty 2017 (CET)[odpowiedz]

@Wostr Zrobione: [6]. Matma Rex dyskusja 21:50, 4 sty 2017 (CET)[odpowiedz]

Gadżet CzyWiesz

Gadżet do zgłaszania artykułów robi dziwne rzeczy. Przed chwilą [7] wywalił nowe zgłoszenie na sam koniec listy w postaci technicznie zdefektowanej. Wczoraj, gdy zgłaszałem Ozór, zignorował wskazanie ilustracji i musiałem ją potem wstawiać ręcznie, myląc się zresztą przy tym gęsto.

Czy ktoś miał ostatnio z nim inne problemy?

Gżdacz (dyskusja) 15:29, 4 sty 2017 (CET)[odpowiedz]

U mnie (Wektor, Firefox) zgłaszanie ilustracji nie działa od dawna, myślałem, że to taki urok – odkąd pamiętam dodaję ilustracje ręcznie. Kenraiz (dyskusja) 20:18, 4 sty 2017 (CET)[odpowiedz]
U mnie tak samo, zgłoszenie ilustracji zawsze było ignorowane i trzeba było samemu później wstawiać. Tournasol Słucham :) 20:36, 4 sty 2017 (CET)[odpowiedz]
A u mnie z kolei z ilustracją nie ma problemu i nigdy nie było. Natomiast nie dodaje dodatkowych komentarzy, ale to już było wcześniej sygnalizowane Kaliguli. Torrosbak (dyskusja) 20:37, 4 sty 2017 (CET)[odpowiedz]
@Torrosbak A czego używasz? Gżdacz (dyskusja) 21:05, 4 sty 2017 (CET)[odpowiedz]
Przeglądarka Chrome, skórka - nowoczesna (chociaż nie wiem, czy ona może mieć znaczenie w przypadku tego gadżetu). Na pewno ma znaczenie przy disFixerze. Torrosbak (dyskusja) 21:10, 4 sty 2017 (CET)[odpowiedz]
@Torrosbak  Też mam Chrome i Wektor - i zdjęcia nie działają. disFikser działał, ale teraz testuję nowy edytor wikikodu, który z nim nie współpracuje. Gżdacz (dyskusja) 21:18, 4 sty 2017 (CET)[odpowiedz]

W Chromie na Androidzie działa/ł poprawnie poza dzisiejszym przypadkiem opisanym powyżej przez Gżdacza (notabene moje zgłoszenie). Pewnie zależy od przeglądarki i od aktualizacji. --Jckowal piszże 20:43, 4 sty 2017 (CET)[odpowiedz]

Nowe zgłoszenie Konak księcia Miłosza zaszło bez problemu. Jckowal piszże 21:44, 4 sty 2017 (CET)[odpowiedz]

Jak nas Wikidane anglicyzują

W haśle o chińskim premierze jest infobox. Do infoboxu pobiera się automatycznie wypełnienie z Wikidanych i dowiadujemy się, że pan premier Chin urodził się w jakimś County. A co on był, angielski lord? Hoa binh (dyskusja) 15:44, 4 sty 2017 (CET)[odpowiedz]

  • Acha, a jako nagłówek infoboxu pobiera się tylko nazwisko. Bohater biogramu nazywa się Zhang Shaozeng, ale tytuł infoboxu to samo Zhang. Gratulacje dla gadżeciarzy, jak nas to ubogaca, jak to podnosi poziom haseł wizualnie i merytorycznie! Hoa binh (dyskusja) 15:50, 4 sty 2017 (CET)[odpowiedz]
  • Cieszę się, że Hoa poruszył ten problem. Ja ze swej strony poproszę o informację, co wpisywać w Polityk infobox, aby nie pobierał danych z Wikidanych. Bo np. w całej serii haseł o chińskich politykach są dwa infoboxy (Nazwa wschodnioazjatycka infobox i Polityk) – bo tylko ta kombinacja pozwala ładnie podać wszelkie informacje – i bezsensem totalnym jest aby w tytule infoboxu coś wyskakiwało (W przypadku ZS przykryłem nieszczęsnego Zhanga imieniem i nazwiskiem, ale też to wygląda źle. Drugi problem jest jeszcze poważniejszy. Otóż tworząc liczne hasła o politykach (głównie Izrael, ale w ramach TT różni inni jak choćby chińscy premierzy) opieram się w całości na (czasem ubogich) źródłach, a nie na tłumaczeniu en-wiki, gdzie często-gęsto jest masa informacji bez źródeł). I specjalnie nie umieszczam dat dziennych urodzin czy miejsca śmierci (bo nigdzie nie da się na nie znaleźć źródeł), a potem mi z wikidanych te informacje i tak wchodzą do artykułu. (jak wspomniane przez Hoa "County..."). A wspomniany problem jest zapewne jeszcze w kilkunastu innych hasłach o premierach, które popełniłem. Andrzei111 (dyskusja) 16:12, 4 sty 2017 (CET)[odpowiedz]
  • "County" to "hrabstwo", zamiast usuwać mogłeś dodać polską etykietę na d:Q1156678. Wargo (dyskusja) 16:46, 4 sty 2017 (CET)[odpowiedz]
    • Pierwsze słyszę, żeby w Chinach mieli hrabstwa. Proszę nie zmyślać. Hoa binh (dyskusja) 16:52, 4 sty 2017 (CET)[odpowiedz]
      • Proszę dodać polską etykietę do d:Q1289426. W przeciwnym razie będziemy się posługiwać angielską (county), zamiennie z niemiecką (Kreis) i rosyjską (уезд). --WTM (dyskusja) 17:01, 4 sty 2017 (CET)[odpowiedz]
      • Nie wiem jak tego typu jednostka podziału się tam nazywa. Czy te 2 usunięcia to dlatego że miejsce urodzenia było nieprawdziwe czy dlatego żeby się nie wyświetlało? Wargo (dyskusja) 17:10, 4 sty 2017 (CET)[odpowiedz]
        • Jest wiele jednostek podziału terytorialnego różnych państw i innych "tworów administracynych", które nie ma mają swoich polskich odpowiedników. Nie jest to na zasadzie wpisz coś tam sobie i wszystko będzie super. Niegdyś pisząc tego typu artykuły, chcąc uniknąć kalek językowych, wpisywałem po prostu jednostka administracyjna n-rzędu, dodając w nawiasie jej oryginalny zapis. Problem jest i będzie wracał. Torrosbak (dyskusja) 17:17, 4 sty 2017 (CET)[odpowiedz]
          • W hasłach dot. podziału administracyjnego Chin wszędzie mowa o powiatach. Taka jest nazwa, czy ktoś sobie spolszczył? Wostr (dyskusja) 17:18, 4 sty 2017 (CET)[odpowiedz]
            • Moje źródła milczą na temat powiatów i gmin. Wyróżnione są: region autonomiczny, prefektura, prefektura autonomiczna, prefektura miejska. Ten powiat czy county to xian (nie wiem czy zapis odpowiedni, nie jestem specjalistą w tym zakresie). Torrosbak (dyskusja) 18:06, 4 sty 2017 (CET) O, właściwe podejście do tematu wykazują Francuzi. Mają opisaną jednostkę fr:Xian (subdivision administrative) i w artykułach dot. jednostek tego podziału do niej linkują. Torrosbak (dyskusja) 18:09, 4 sty 2017 (CET)[odpowiedz]
              • Xian to powiat i tak się to tłumaczy, również na Wiki. Tylko teraz pytanie: powiatów w Chinach jest coś circa półtora tysiąca, każdy ma swoją stronę na wikidanych. Będziemy teraz wszystkich szukać i w każdym wpisywać, że to powiat? Bo inaczej cudowna maszynka zaimportuje nam nazewnictwo anglojęzyczne? Toż to absurd do potęgi n-tej. Hoa binh (dyskusja) 18:53, 4 sty 2017 (CET)[odpowiedz]
                • Teoretycznie możliwe jest po prostu wyszukanie wszystkich przypadków, w których element w Wikidanych jest oznaczony jako chiński powiat i odpowiednie przypisanie mu nazwy (wszystko automatycznie nie ręcznie). W taki sposób właśnie przeprowadzane są cały czas różne operacje na dziesiątkach tysięcy elementów na raz. Tylko trzeba by było znaleźć kogoś w WD kto by to botem zrobił + skądś wziąć nazwy tych powiatów (stwierdzić, czy np. nazwy z en-wiki będą takie same jak potrzebujemy w pl-wiki, czy nie itd.). Wostr (dyskusja) 19:29, 4 sty 2017 (CET)[odpowiedz]
Wykorzystując treść hasła Langfang ustawiłem polski opis elemtu WD na „Dachang”, który potem @Wostr zmienił na Dacheng. Nie wiem, która z nich jest prawidłowa więc nie będę rewertował. Dodanie tego wpisu wraz ze znalezieniem nazwy na pl.wiki zajęło mi mniej czasu, niż poświęciłeś na założenie tego wątku. ~malarz pl PISZ 20:02, 4 sty 2017 (CET)[odpowiedz]
  • Bardzo smuci mnie ta dyskusja, bo to kolejny przykład jakiegoś zupełnie niezrozumiałego dla mnie oporu przed Wikidanymi, które naprawdę, jestem o tym głęboko przekonany, są najlepszym, co Wikimediom przydarzyło się od ładnych paru lat. Nie ma odwrotu od importu danych z WD, z wielu powodów. Jeden z nich jest taki, że Wikipedia, np. po polsku, liczy coraz więcej artykułów, a społeczność wcale się nie powiększa, raczej przeciwnie. Tym samym coraz więcej haseł jest mocno nieaktualnych, a np. import danych liczbowych z WD pozwala aktualizować statystyki w różnych wersjach językowych równocześnie, w dodatku automatycznie. Do tego WD wymuszają większy porządek w strukturze wiedzy w Wikipedii czy w faktografii. Podsumowując, naprawdę, Andrzeju czy Hoa, i tak nie zatrzymacie pewnych procesów, nie zawrócicie kijem Wisły, bo tendencja opierania się na WD jest absolutnie globalna, w tę stronę idą technikalia itd. Należy po prostu uczyć się WD (co naprawdę nie jest trudne) i część swoich edycji wykonywać tam. Np. ja już od dobrego roku tylko tam dodaję współrzędne geograficzne, choć wcześniej robiłem to na plWiki. Naprawdę szkoda czasu, żeby wznosić okrzyki typu "Łolaboga, biją nas (tudzież anglicyzują)", po prostu trzeba rozwijać się i uczyć nowych rzeczy, jak to w życiu. Powerek38 (dyskusja) 17:11, 5 sty 2017 (CET)[odpowiedz]
    • Generalnie się z Tobą zgadzam, co do Wikidanych i ich potencjalnej roli w internecie, a nawet całym świecie, ale co innego założenia, co innego praktyka np. kwestia źródeł, w chwili obecnej to kompletna masakra. Nie ma się więc co dziwić, że na tę chwilę opór jest spory i nie ma się co smucić, tylko trzeba jasno wskazywać na kłopoty i niedociągnięcia, aby pierwotne założenia faktycznie działały. Emptywords (dyskusja) 18:36, 5 sty 2017 (CET)[odpowiedz]
      • Zgoda, ale np. problem braku polskich etykiet wielu elementów (który chyba leży u podstaw akurat tej dyskusji) wynika wyłącznie z niedostatecznej liczby polskojęzycznych edytorów WD, którzy wstawiają te etykiety. Więc to zależy tylko od nas. I jasne, Wikidane rozwijają się szybko, ale może nie aż tak szybko, jak wszyscy byśmy chcieli. Ale jest tam bardzo wielu zaangażowanych deweloperów i edytorów, jest dużo pieniędzy (fundacyjnych, ale też z zewnętrznych grantów) i dużo chęci współpracy z lokalnymi społecznościami, jak nasza. Daleko nie szukając, od tego tygodnia można na WD podawać nr obiektu w polskim rejestrze zabytków. Powerek38 (dyskusja) 18:40, 5 sty 2017 (CET)[odpowiedz]
  • Struktura wikidanych jest neutralna językowo. Więc to że gdzieś się wyświetla anglojęzyczna nazwa jest błędnym wypełnieniem wikidanych. Jak tu już zaznaczono nie należy wobec tego wyłączać wyświetlania z wikidanych lecz porawiać wikidane. Jeżeli zdjęcie jest niewłaściwe to należy w wikidanych zmienić wartość właściwości P18 a nie blokować wyświetlanie na pl.wiki. Tak samo z każdą inną kwestią. Oburzanie się że w wikidanych mogą być złe wartości jest tym samym co oburzanie się że każdy może edytować Wikipedię. Marek Mazurkiewicz (dyskusja) 18:02, 5 sty 2017 (CET)[odpowiedz]
    Jako mało techniczny zapytam, czy jeśli infobox x zasysa dane z elementu Y na wikidanych, a ten element jest opisany wyłącznie po birmańsku, to się będzie nam pokazywał po birmańsku, czy się nie będzie pokazywał?--Felis domestica (dyskusja) 18:07, 5 sty 2017 (CET)[odpowiedz]
  • @Powerek38, @Marek Mazurkiewicz Wszystko pięknie wspaniale tylko.... nieco nijak ma się to do mojego pytania. Więc temat raz jeszcze napiszę, na razie jeden wątek, by nie dawać opcji do offtopu:) Otóż. Kiedy tworzyłem Zhang Shaozeng wstawiłem tam 2 infoboxy, jeden by wpisać poprawnie imię w różnych wariantach, drugi by poprawnie podać następstwo stanowisk i dane biograficzne. I specjalnie zostawiałem pole "polityk =" puste, bo bez sensu wyglądają powtórzone dwa razy personalia, a do tej pory po prostu oba infoboxy ładnie się uzupełniały i tworzyły spójną całość. Teraz tak nie jest. Przyznacie chyba, że fajnie byłoby móc wpisywać coś co zablokuje wyświetlanie elementu z wikidanych, bo będzie ładniej. I tak jak kiedyś ktoś pomyślał, by dało się blokować podwójne wyświetlanie się ilustracji w infoboxach – wspomniane przez Ciacho5 nie – to zdecydowanie przydałoby się i tutaj takie rozwiązanie. Wiecie jak to zrobić? A może potraficie podpowiedzieć do kogo się z tym zwrócić? Andrzei111 (dyskusja) 18:50, 5 sty 2017 (CET)[odpowiedz]
  • Tutaj →Åseda inny przykład. W infoboksie miejscowości pojawił się automatycznie w miejscu parametru „herb” herb gminy Uppvidinge (tak też wisi w en:Åseda). Jest to błąd merytoryczny razy dwa – szw. miejscowości (tätorty) nie mają własnych herbów, a jeśli chodzi konkretnie o Åsede to do 1970 r. obowiązywał herb sv:Åseda köping. Oczywiście coat of arms image można łatwo usunąć z WD (co zrobię), ale ktoś to tam wprowadził i może nie wszyscy wiedzą co należy w takiej sytuacji zrobić. Zurbanski (dyskusja) 13:37, 7 sty 2017 (CET)[odpowiedz]
    • Bot wstawił tam te CoA na podstawie en.wiki. To jest jeden z botów, który przenosił różne rzeczy z infoboksów różnych wiki bez opamiętania. ~malarz pl PISZ 14:12, 7 sty 2017 (CET)[odpowiedz]
    • Niestety na samym początku WD były uzupełniane przez boty na postawie różnych wersji językowych Wikipedii. Do czego to doprowadziło chyba nie muszę pisać. Obecnie jednak praktyka jest raczej taka (przynajmniej w dziedzinach, które obserwuję), że dane zasysane są z zewnętrznych baz danych, przy czym muszą być wstępnie porównane (np. porównuje się szereg identyfikatorów związku chemicznego i dopiero zasysa dane, jeśli wszystko się zgadza). Więc, o ile początki były trudne, to wszystko idzie jednak w dobrym kierunku. Wostr (dyskusja) 17:02, 7 sty 2017 (CET)[odpowiedz]
    • Dziękuję za odpowiedź; CoA usunięty Zurbanski (dyskusja) 17:48, 7 sty 2017 (CET)[odpowiedz]
  • Jeszcze raz, bo wyżej umknęło (zaznaczam, że pytam serio). Jako mało techniczny zapytam, czy jeśli infobox x zasysa dane z elementu Y na wikidanych, a ten element jest opisany wyłącznie po birmańsku, to się będzie nam pokazywał po birmańsku, czy się nie będzie pokazywał? --Felis domestica (dyskusja) 02:30, 8 sty 2017 (CET)[odpowiedz]
    • Nie ma prostej odpowiedzi. Jeśli chodzi o nazwy to wszystko zależy od metody wyciągania danych. Inaczej działa #property niż jeszcze nie używany #statements. Pełna dowolność może być w Lua. Dodatkowo proces zaburza automatyczne podsuwanie przez MediaWiki wyników z innych języków, jeśli naszego tam nie ma (zdaje się, że dla polskiego jest to angielski). Należy też pamiętać o tym, że niektóre cechy są definiowane w języku oryginalnym i jako takie zawsze będą mogły być nieczytelne jeśli pismo owego języka nie będzie stosowało alfabetu łacińskiego. Po polsku zaś powinny zawsze być wyświetlane cechy o wartościach numerycznych lub daty. Identyfikatory jako proste teksty też w większości mogą być czytelne bo zwykle wszelakie bazy danych ograniczają się do cyfr tudzież znaków ASCII. Aczkolwiek mogą być wyjątki bo widywałem tam cyrylicę, więc nic nie stoi na przeszkodzie by były to również znaki sanskrytu lub arabskie. Paweł Ziemian (dyskusja) 09:31, 8 sty 2017 (CET)[odpowiedz]
      • @Paweł Ziemian Bardzo dziękuję - nie wprost odpowiedziałeś na pytanie, którego nie zadałem, bo nie wiedziałem, o co zapytać :D W pierwotnym pytaniu nie chodziło mi tak bardzo o pismo, tylko o sytuację - nie ma polskiego terminu, co wtedy? Czy będzie "jedyny, jaki jest?" Nie pomyślałem, by zapytać "Który termin zostanie wybrany, jeśli naszego nie ma, a jest kilka" - a to w sumie pytanie ważniejsze. Jak rozumiem jest jakaś ogólna hierarchia - jeśli nie polski to 1. angielski 2. litewski 3. białoruski itp. A czy jest możliwość by ustawić ją w zależności od hasła? Czyli np. hasło o Czechach ma kolejność: termin polski, jeśli nie to 1. czeski, a potem cała reszta. --Felis domestica (dyskusja) 10:38, 8 sty 2017 (CET)[odpowiedz]
  • Podzielam opinie Hoa na temat Wikidanych. Mam o nich równie złe zdanie wynikające z kilku kontaktów z tym projektem. Masa błędów zaciągnięta z en. wiki. bezrefleksyjne wpisywanie danych, powtórzenia, dublujące kategorie. Nie wiem czy jest dobrze, by niezweryfikowane informacje pobierać z projektu który dopiero się kształtuje, i przesyłać automatycznie do Wikipedii. To psuje nieco nerwy osobom które poświęciły lata na podniesienie poziomu w swojej działce a tu nagle pojawiają się ponownie błędne informacje które znów trzeba poprawiać.--Adamt rzeknij słowo 11:11, 8 sty 2017 (CET)[odpowiedz]
  • Dopóki WD są niedopracowane, powinny być wyłącznie uzupełnieniem drobnych elementów. WD ograniczają nam możliwość kontrolowania wandalizmów w projekcie, a wandalizmy i zwykła niekompetencja są tam po prostu częste (nawet w tak banalnych kwestiach jak dodawanie fotografii). WD to świetny projekt w wielu kwestiach, ale zasysanie u nas w podstawowych infoboksach różnych elementów było za szybkie. Elfhelm (dyskusja) 11:56, 8 sty 2017 (CET)[odpowiedz]
  • Mamy nieprzerobiony temat WD – osoby techniczne widzą potencjał, reszta przyzwyczajona jest do tego, że inne wikipedie nie mogą być źródłem danych, nie wiedzą jak działać w WD, wpływać na powstające konstrukcje baz danych i ich zawartość, nie wiedzą kiedy i co zacznie wpadać do naszych infoboksów. Potrzebujemy otwartej, rzeczowej dyskusji. Mam nadzieję, że choćby przy zlocie będzie ktoś zorientowany na tyle, by zrobić pogaduchę na ten temat. Trzeba by było i tu popracować nad zmianą nastawienia, bo pewnie nie uda nam się tamy przed WD postawić... Kenraiz (dyskusja) 22:30, 8 sty 2017 (CET)[odpowiedz]

Potrzebna pomoc z css (i lua?)

Zauważyłem, że mamy na wiki kulawy dość szablon {{Listen}}, oparty o wersję szablonu na en.wiki z bodaj 2008 roku. Działać działa, ale tak sobie, nie akceptuje więcej niż jednego pliku i w ogóle przydałoby mu się odświeżenie. W tej chwili "nasz" Listen korzysta z parametrów po angielsku, co chyba nie jest przesadnie dużym problemem, bo szablon działa na setkach stron i jakoś nikt nie narzeka[1].

Pomyślałem, że dobrze byłoby zaimportować do nas nowszą wersję szablonu z en.wiki, opartą o Moduł:Side box, Moduł:Listen i Moduł:File link. Kłopot w tym, że w MediaWiki:common.css nie mamy odpowiednich klas dodanych, do których odwołuje się Moduł:Side box (konkretnie, o ile dobrze patrzę, mbox-small, mbox-small-left, plainlist, może coś przeoczyłem). Przez co {{Side box}} się wykrzacza, co z kolei powoduje, że pudełko zamiast mieć odpowiednią szerokość rozciąga się na cały ekran, o tak:

Polonez Op.53 Chopina w wykonaniu Giorgia Lacabidzego

Czy jakaś dobra dusza z uprawnieniami mogła by przekopiować odpowiednie wpisy z angielskiego w:en:MediaWiki:Common.css do naszego MediaWiki:Common.css? Z góry dziękuję. //Halibutt 11:01, 5 sty 2017 (CET)[odpowiedz]

Na marginesie
  1. Pytałem na IRC-u Sapera czy da się w lua ustawić aliasy tak, by moduł i szablon akceptowały zarówno angielskie terminy (jak obecnie), jak i ich polskie odpowiedniki, ale najwyraźniej się nie da i już

Ktoś, kto by zechciał zająć się dodawaniem źródeł z interesującej go tematyki, szybko by zrezygnował, bo poruszanie się po tych kategoriach jest okropne – ciężko coś odnaleźć w gąszczu dat. Czy nie lepiej rozłożyć hasła po ukrytych kategoriach, wykorzystując nazewnictwo obecnych kategorii, w których się znajdują artykuły? Np., 7 Brygada Piechoty UHA zamiast Kategoria:Artykuły wymagające uzupełnienia źródeł od 2016-03 (po co tak długa nazwa?) do kategorii: 1. Kategoria:Brygady piechoty Ukraińskiej Armii Halickiej/brak źródeł i 2. Kategoria:Wojsko we Lwowie/brak źródeł.

Na pewno przydałaby się symulacja lub wstępne oszacowanie, czy liczba tych ukrytych kategorii nie przekroczy liczby nieuźródłowionych haseł i nie trzeba by pomyśleć o uogólnieniu do nadrzędnych kategorii tematycznych. Farary (dyskusja) 22:56, 5 sty 2017 (CET)[odpowiedz]

Na życzenie. A co, gdyby to było dostępne w miejsce „brak źródeł” ileś tam poziomów w dół z kategorii głównych? Farary (dyskusja) 23:25, 5 sty 2017 (CET)[odpowiedz]
  • No ale chyba po to są te kategorie, aby sobie CatScanem wylistować te, które nas interesują? Po co robić jakieś dziwne zabiegi z milionem kategorii? Wostr (dyskusja) 03:36, 6 sty 2017 (CET)[odpowiedz]
  • Zgadzam się z Wostrem. Kategorie techniczne są bardzo ważne, ale ich nadmierne mnożenie jedynie skomplikuje ich utrzymanie. Lepiej poświęcić czas na kategoryzację main wg encyklopedycznych cech, bo z tego co widzę, to brakuje nam tysięcy potrzebnych kategorii. Natomiast na stronie Wikipedia:CatScan przydałby się nieco dokładniejszy opis, np. jak w wersji niemieckiej. Wiklol (Re:) 09:29, 6 sty 2017 (CET)[odpowiedz]

Infobox dla kuchni

Przydałby się infobox dla haseł o kuchniach. Gdyby ktoś miał chęci, czas i możliwości zrobić taki infobox, to bardzo proszę. Potrzebne są następujące rubryki: nazwa kuchni, miejsce na zdjęcie jakiejś reprezentatywnej potrawy i jej opis, występowanie, wpływy religijne (opcjonalnie), obce wpływy (opcjonalnie), podstawowe surowce, rodzaj chleba, przyprawy, potrawy (ewentualnie z podziałem na zupy, dania mięsne lub rybne, desery), napoje alkoholowe, napoje bezalkoholowe, link do Commonsu. Najlepiej, gdyby w infoboxie ukazywały się jedynie te rubryki, które zostały wypełnione. Hortensja (dyskusja) 19:28, 6 sty 2017 (CET)[odpowiedz]

Serio potrzebujemy czegoś takiego? Wydaje mi się, że dane do wpisywania w taki infoboks byłyby bardzo uznaniowe. PuchaczTrado (dyskusja) 11:12, 7 sty 2017 (CET)[odpowiedz]
A jest coś takiego na angielskiej wiki? Chętnie zobaczyłbym przykład. Sidevar (dyskusja) 11:28, 7 sty 2017 (CET)[odpowiedz]
Dane wpisywane do infoboksu pochodziłyby z testu, czyli z materiałów źródłowych, na pewno nie "uznaniowe". Nie ma jeszcze, a przynajmniej ja nie spotkałam się z takim infoboksen na en.wp. Co IMO nie znaczy, że musimy czekać aż Oni zrobią, przecież możemy być pierwsi, no chyba że nie chcemy. W infoboksie byłyby podane w pigułce najważniejsze informacje, podobnie jak w artykułach-biografiach. Hortensja (dyskusja) 11:42, 7 sty 2017 (CET)[odpowiedz]
@Hortensja Bukietowa, w infoboksach umieszczamy „metadane”, czyli to, co da się łatwo określić w sposób pełny, wyczerpujący, jedyny: nazwa, lokalizacja, data, liczba. Natomiast jeżeli jest to coś abstrakcyjnego, o którego „skład” można się kłócić (tradycyjne granice, wpływy, główne składniki), to nie jest to dobre pojęcie do włożenia do infoboksu. Z wyliczonych przez Ciebie łatwo weszłyby: nazwa, zdjęcie przykładowej potrawy i Commons. Mało. Występowanie można by (bardzo słabe „można by”) zamienić na coś jak „powiązanie z kulturą”, gdzie kultura przynależy grupie etnicznej, narodowej lub grupie obywateli danego państwa. I wtedy w kuchni USA mógłby być indyk. Ale widzisz, jak szeroka i niesamodzielna to definicja. W razie wątpliwości zapraszam do dyskusji na dyskusja wikiprojektu:Infoboksy. Tar Lócesilion (queta) 12:28, 7 sty 2017 (CET)[odpowiedz]
Przykładowa potrawa dla kuchni polskiej to pewnie by były pierogi, o które kłócą się (ale zgodnie jadają) wszyscy od Odry do Pacyfiku :D Kuchnie przechodzą tak płynnie jedna w drugą, że próba podsumowania ich w tabelce z 20 pojęciami jest nierealna: albo wszystkie będą wyglądać tak samo, albo będą dziwnie wybiórcze :( Niestety, kuchnie trzeba opisywać kompleksowo, by taki opis miał sens - i to akurat Hortensja robi świetnie :D --Felis domestica (dyskusja) 01:03, 8 sty 2017 (CET)[odpowiedz]
  • Podstawowe surowce dla kuchni polskiej, nie mówiąc o chińskiej to albo lista na pół strony (zza której nie byłoby widać infoboksu), albo bardzo POViasty i dyskusyjny wybór. Ciacho5 (dyskusja) 12:36, 7 sty 2017 (CET)[odpowiedz]
    • Wbrew pozorom można wypełnić podane przeze mnie rubryki, oczywiście kuchnie słowiańskie będą miały podobne dane w infoboksach, ale jakże różne od kuchni azjatyckich czy afrykańskich, a nawet kuchnia holenderska nie będzie miała zbyt wielu wspólnych danych z kuchnią polską, ani z francuską czy niemiecką, jeżeli skupimy się na różnicach i unikalności. Podam dwa przykłady dla zilustrowania:
Infoboks kuchnia tradycyjna
kuchnia holenderska kuchnia rosyjska
Występowanie: europejska część Królestwa Niderlandów część Federacji Rosyjskiej do Wołgi, oraz Moskwa i Sankt Petersburg
Wpływy religijne: protestantyzm prawosławie
Obce wpływy:indonezyjskie, surinamskie francuskie, radzieckie
Surowce: ziemniaki, warzywa kasze, gryka, kapusta
Rodzaj chleba: chleb pszenny na drożdżach żytni na zakwasie
Przyprawy: korzenne (pieprz, cynamon, goździki, gałka muszkatołowa) cebula, czosnek, chrzan, koperek, pietruszka
Potrawy: stamppoty szczi, pi(e)rogi, ucha
Napoje bezalkoholowe: deszczówka, mleko; kawa, herbata kwas chlebowy, herbata
Napoje alkoholowe: piwo, wino, jenever piwo, wódka

Oczywiście taki infobox to olbrzymie uproszczenie, czy ma sens czy nie, to sprawa dyskusyjna. Może więc skrócony infobox miałby rację bytu? Rubryki tj. nazwa kuchni narodowej, zasięg występowania, zdjęcie potrawy tradycyjnej z opisem, wymienienie kilku tradycyjnych potraw tych naj, naj- i link do Commonsu raczej nie powinny budzić zastrzeżeń. Hortensja (dyskusja) 15:32, 8 sty 2017 (CET)[odpowiedz]

  • A jaka będzie data dla "tradycyjnej" kuchni? Bo jak dalej jak 300 lat temu, to wszystkie półnoeuropejskie będą takie same, a południoeuropejskie też, a jak blisko współczesności, to nam się globalizacja włączy... --Felis domestica (dyskusja) 17:50, 8 sty 2017 (CET)[odpowiedz]
  • Całkowicie się zgadzam z Puchaczem, Tarem, Felisem i Ciachem. Większość zaproponowanych pól się nie nadaje do infoboksu. Są po prostu zbyt płynne, uznaniowe albo obszerne. Dodtkowym problemem jest tematyka, w której każdy z nas czuje się ekspertem od rodzimej kuchni. O ile nie chcę się takim "ekspertom" poprawiać tekst o tyle poprawianie infoboksu jest proste i zaraz będą coś w nim zmieniali. Zaraz by ktoś w kuchni rosyjskiej dodał w infoboksie samogon. Istotna jest też uwaga Felisa dot. wieku, od którego traktujemy coś za tradycyjne. Można się zastanawiać nad "podstawowym" infoboksem. Wtedy trzeba by go tak przygotować, aby mógł być używany w wielu miejscach (nie tylko kuchnie), ale przede wszystkim aby nie zawierał pól mogących wywoływać kontrowersje w jakimkolwiek z tematów. Z zaproponowanych pól problematyczny może być zasięg, szczególnie w przypadku kuchni narodowych. Regionalne są dużo prostsze i łatwe do dobrego zapisania. Ale jaki jest zasięg tradycyjnej kuchni polskiej? To nie jest proste do zapisania w trzech słowach. ~malarz pl PISZ 15:23, 9 sty 2017 (CET)[odpowiedz]

Serwer na pliki

Cześć, Przygotowuje artykuły o starych zawodach skoków narciarskich kobiet. Dostane trochę wyników w formie pdfów, zdjęć, itp., jednak nie mam serwera żeby to umieścić. A innej możliwości uźródłowienia tego nie widzę. Czy jest jakiś sposób żeby umieścić to na jakimś serwerze wiki ? Albo może ktoś ma pomysł na jakiś inny "trwały", i pewny sposób żeby to nie zniknęło za chwilę ? Teflon94 (dyskusja) 13:01, 8 sty 2017 (CET)[odpowiedz]

Sprawdź czy prawa autorskie zezwalały by umieścić to na Commons. Wargo (dyskusja) 13:33, 8 sty 2017 (CET)[odpowiedz]
Na razie dostałem jednego pdfa (skany lub zdjęcia złożone w pdfa), ale z czasem pewnie będzie tego trochę więcej (kilkanaście, kilkadziesiąt plików). Nie wiem też na ile commons przyjmuje pdfy, nigdy się tym nie interesowałem nawet. Czy znasz może jakiegoś speca od tego projektu, żeby mógł udzielić mi jakichś rad ? Teflon94 (dyskusja) 13:49, 8 sty 2017 (CET)[odpowiedz]
Pdfy można. A co jest w tych pdfach? Tak sobie myślę, czy Wikiźródła byłyby też dobre? Myślę, że w sprawie Commons będzie mógł wypowiedzieć się Masur Wargo (dyskusja) 15:18, 8 sty 2017 (CET)[odpowiedz]
W tych pdfach są wyniki takie same jak np. te z ostatniego konkursu w którym wygrał Stoch, tylko że z przed ponad 20 lat. Dzięki za kontakt :) Teflon94 (dyskusja) 16:18, 8 sty 2017 (CET)[odpowiedz]
A gdy już sprawdzisz i prawa autorskie jednak nie będą pozwalać na publikację na Commons, to proponuję wrzucić te pliki na jakikolwiek hosting, a następnie zarchiwizować i używać zarchiwizowanych linków. Muri (dyskusja) 13:41, 8 sty 2017 (CET)[odpowiedz]

Gadżet Zgłoś do usunięcia

Lista wikiprojektów do powiadomienia jest niepełna (na pewno brakuje Wikiprojekt:Transport) oraz ich kolejność jest zła (na pewno [[Wikiprojekt:Transport szynowy]) jest w złym miejscu). Czy ktoś wie gdzie to można poprawić? Therud (dyskusja) 19:46, 8 sty 2017 (CET)[odpowiedz]

Pisałem o tym wyżej. Z gadżet Czy Wiesz jest podobnie. Eurohunter (dyskusja) 19:48, 8 sty 2017 (CET)[odpowiedz]
  • Jednak gadżet CzyWieszowy ma tych projektów więcej, a DNUwy bardzo mało. Tłucze mi się jednak po głowie, że poszczególne Wikiprojekty były pytane, czy chcą otrzymywać informacje o DNU i wstawiono tylko zainteresowane. Ponieważ obsada się zmieniła, może warto uzupełnić. Ciacho5 (dyskusja) 22:35, 8 sty 2017 (CET)[odpowiedz]
  • Wygląda na zaszyte na sztywno w kodzie gadżetu. IOIOI2 23:48, 8 sty 2017 (CET)[odpowiedz]
  • Te dwa gadżety całkowicie inaczej wczytują listę wikiprojektów. IMO należy to przy okazji ujednolicić. Tylko, że dobrze by było najpierw opracować listę wikiprojektów, która powinna się w nich znajdować. W przestrzeni Wikiprojekt znajdują się 634 strony bez znaku „/” (nie licząc 43 przekierowań) IMO jest to zdecydowanie zbyt długa lista dla gadżetów. ~malarz pl PISZ 00:05, 9 sty 2017 (CET)[odpowiedz]

Wylogowywanie

Nadal występuje problem z edytowaniem lub przełączaniem się pomiędzy wieloma wersjami Wikipedii. Raz jestem zalogowany, raz nie. Pomaga usunięcie ciasteczek w przeglądarce. Eurohunter (dyskusja) 23:40, 8 sty 2017 (CET)[odpowiedz]

Czy korzystasz z przeglądarki Firefox? Vide Specjalna:Diff/47967495. Peter Bowman (dyskusja) 00:01, 9 sty 2017 (CET)[odpowiedz]
Tak. Dzięki. Eurohunter (dyskusja) 08:25, 9 sty 2017 (CET)[odpowiedz]

Fragmenty map

Zniszczenia
Zniszczenia Warszawy, fragment Pragi

Mam skłonność do ilustrowania artykułów mapami. Niestety, jeśli nie chcę pokazywać czytelnikowi całej mapy od razu, muszę, oprócz pełnego arkusza, wgrać na commons także wybrany fragment jako osobny plik: na przykład pełna (u góry) i fragment (u dołu) mapa zniszczeń Warszawy w II w.ś. To bez sensu, bo z tej mapy pewnie można wyciąć dziesiątki albo setki fragmentów, żeby użyć ich w artykułach o poszczególnych ulicach, uźródławiając informacje o losie zabudowy w czasie wojny.

Pytanie: czy dałoby się jakoś wskazać w commons plik i (opcjami linku? opcjami szablonu?) kazać w arcie wyświetlić tylko jego wybrany fragment. Żeby to miało sens, powinno być wykonywane po stronie serwera, żeby uniknąć transferu całości (w przykładowym pliku całość to jpg o wymiarze 18,588 × 23,976 pikseli, 84.64 MB).

Gżdacz (dyskusja) 18:57, 9 sty 2017 (CET)[odpowiedz]

Jest coś takiego jak en:Template:CSS image crop, ale to ładuje cały obraz i tylko wyświetla fragment. Paweł Ziemian (dyskusja) 19:44, 9 sty 2017 (CET)[odpowiedz]

20:12, 9 sty 2017 (CET)