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

Z Wikipedii, wolnej encyklopedii
Usunięta treść Dodana treść
Linia 710: Linia 710:
:::: Zgadza się, chodzi mi o <code>.mw-editTools</code> (od '''Najczęstsze''' po '''Symbole'''). Jakich wskazówek dokładnie potrzebujesz? Dodatkowo czy da się zwiększyć odstęp między wierszami? [[Wikipedysta:Eurohunter|Eurohunter]] ([[Dyskusja wikipedysty:Eurohunter|dyskusja]]) 13:28, 26 sty 2017 (CET)
:::: Zgadza się, chodzi mi o <code>.mw-editTools</code> (od '''Najczęstsze''' po '''Symbole'''). Jakich wskazówek dokładnie potrzebujesz? Dodatkowo czy da się zwiększyć odstęp między wierszami? [[Wikipedysta:Eurohunter|Eurohunter]] ([[Dyskusja wikipedysty:Eurohunter|dyskusja]]) 13:28, 26 sty 2017 (CET)
::::: OK, w takim razie mógłbyś zmienić samo <code>.mw-charinsert-item</code>, jak niżej w kodzie Kamila. [[Wikipedysta:Peter Bowman|Peter Bowman]] ([[Dyskusja wikipedysty:Peter Bowman|dyskusja]]) 13:37, 26 sty 2017 (CET)
::::: OK, w takim razie mógłbyś zmienić samo <code>.mw-charinsert-item</code>, jak niżej w kodzie Kamila. [[Wikipedysta:Peter Bowman|Peter Bowman]] ([[Dyskusja wikipedysty:Peter Bowman|dyskusja]]) 13:37, 26 sty 2017 (CET)
:::::: Nie rozumiem dlaczego mam podawać szerokość czcionki, albo pogrubienie jest, albo go nie ma. Tak czy inaczej, to nie działa (działa tak samo jak <code>..mw-editTools</code>). [[Wikipedysta:Eurohunter|Eurohunter]] ([[Dyskusja wikipedysty:Eurohunter|dyskusja]]) 14:25, 26 sty 2017 (CET)
:::::: Problem rozwiązał parametr <code>font-weight: lighter;</code>. [[Wikipedysta:Eurohunter|Eurohunter]] ([[Dyskusja wikipedysty:Eurohunter|dyskusja]]) 14:31, 26 sty 2017 (CET)
::: Takie coś?
::: Takie coś?
::: <syntaxhighlight lang="css">
::: <syntaxhighlight lang="css">

Wersja z 15:31, 26 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
- typowy divitis, czyli tak jak się HTMLa nie powinno stosować. Brakuje jeszcze rozpychania tabeli divami. 164.126.197.33 (dyskusja) 17:18, 23 sty 2017 (CET)[odpowiedz]
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]

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]

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 ([1]). 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]

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]

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: [5]. 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ą [6] 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]
Tak też zrobię, dzięki za pomysł :) Teflon94 (dyskusja) 00:00, 10 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]
@Eurohunter: zerknij do sekcji „Problemy” w Specjalna:Diff/48131709. Pozdrawiam, Peter Bowman (dyskusja) 20:38, 9 sty 2017 (CET)[odpowiedz]
Szkoda, że nie wyjaśniono co powoduje proponowana zmiana. Eurohunter (dyskusja) 23:00, 9 sty 2017 (CET)[odpowiedz]
Jest w podlinkowanym wątku na Phabricatorze. Wprowadzony jest limit wysyłanych ciasteczek, opcja go zwiększa. Wargo (dyskusja) 23: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]
To nie zadziała. Gdy pełna mapa ma prawie 85 MB, to ten mechanizm zabije każdego z komórką i solidnie przymuli tych z kompami. Gżdacz (dyskusja) 21:35, 10 sty 2017 (CET)[odpowiedz]

Automatyczne generowanie przypisów w VE

Ostatnio zdziwiła mnie trochę epidemia dziwnego cytowania artykułów w czasopismach. Jak się okazuje winne jest generowanie przypisów w VE na podstawie linku. Otóż wklejając link do PubMedu dostaję przypis w postaci:

  • D.W. Gaylor, The use of Haber's law in standard setting and risk assessment, „Toxicology”, 1, 2000, s. 17–19, ISSN 0300-483X, PMID10963857 [dostęp 2017-01-10].

A powinienem dostać:

  • D.W. Gaylor, The use of Haber's law in standard setting and risk assessment, „Toxicology”, 149 (1), 2000, s. 17–19, PMID10963857.

Zbędne są ISSN, data dostępu, data dzienna (potrzebny jest tylko rok), URL, a brakuje bardzo ważnego woluminu (i w dodatku błędnie numer podany jest tak jakby był woluminem). Podając w tym generatorze numer DOI na szczęście nic się nie udaje uzyskać. Teraz pytanie: problem jest po stronie generatora VE czy naszego szablonu {{cytuj}}? Jeśli pierwsze – jak można wyłączyć ten generator (bo kto ma to wszystko poprawiać)? Jeśli drugie – bardzo bym prosił o jakieś zmiany, bo takich przypisów do poprawy jest z każdą chwilą więcej. Wostr (dyskusja) 00:08, 11 sty 2017 (CET) PS A, i czemu {{cytuj}} zmienia sobie w tym miejscu kolejność imię–nazwisko, wbrew temu co generują wszystkie inne szablony cytowania? Wostr (dyskusja) 00:09, 11 sty 2017 (CET) PS2 I nawet obcina jeden inicjał... Wostr (dyskusja) 00:10, 11 sty 2017 (CET)[odpowiedz]

Wostr, sprawdziłem generowanie z numeru DOI dla publikacji, która ma DOI podany w PubMedzie - szablon Cytuj wygenerował się, choć nieco inny niż uzyskany z PMID-u. Zapisałem testowe wyniki generowanych szablonów. Michał Sobkowski dyskusja 09:17, 11 sty 2017 (CET)[odpowiedz]
Widać od razu, że generator Holka działa najlepiej ze wszystkich (kilka rzeczy wymaga potem ręcznej poprawy, ale wszystko jest). Wostr (dyskusja) 15:28, 11 sty 2017 (CET)[odpowiedz]
No, wszystko jak wszystko - nie ma PMC, które jest o tyle istotne, że wskazuje na dostęp do pełnego tekstu dla każdego. Holek jeszcze jest aktywny, może doda? Michał Sobkowski dyskusja 15:52, 11 sty 2017 (CET)[odpowiedz]
Bardzo przeszkadzają te dodatkowe parametry i pełna data? Co do woluminu to można by go podrasować, np. dodając do Cytuj osobny parametr dla wolumin/wydanie. Wargo (dyskusja) 11:57, 11 sty 2017 (CET)[odpowiedz]
Proponuję przywrócić pierwotną wersję MediaWiki:Visualeditor-cite-tool-definition.json i połączyć z bieżącą aby można było wstawiać szczegółowe szablony cytowania. Wargo (dyskusja) 16:41, 11 sty 2017 (CET)[odpowiedz]
  • Myślę, że największy problem to pole wydanie, które nie działa najlepiej z generatorem przypisów. Narzędzie do cytowania dysponuje w ogólności trzema elementami edition, volume i issue. Wszystkie są podpięte pod jedno nasze „wydanie”. Narzędzie niby jest uniwersalne i działa na wszystkich wiki, a zapomnieli o takim drobiazgu jak tworzenie opisów złożonych. W każdym razie ja nie znam żadnej metody pozwalającej na łączenie pól przekazywanych przez Citoid w celu wygenerowania na przykład volume (issue) albo edition, t. volume. W przypadku {{cytuj}} trzeba by „wydanie” rozpisać na trzy nowe pola jednoznacznie mapowalne z edition, volume i issue. Może je wprowadzić w postaci angielskiej na potrzeby generatora? Z drugiej strony patrząc, nadmiar informacji (pełna data, issn) jest lepszy niż jej brak. Zawsze taki wstępnie wygenerowany szablon cytowania można poprawić ręcznie przez usunięcie zbędnych pól. Z tym narzędziem jest taki problem, że jest ono uniwersalne na wszystkie wiki. Paweł Ziemian (dyskusja) 20:16, 11 sty 2017 (CET)[odpowiedz]
    • Odnośnie woluminu to coś trzeba zrobić, aby był dodawany, bo nie może być tak, że wolumin jest pomijany, a na jego miejsce wchodzi (de facto opcjonalny i w sumie często pomijalny) numer. Odnośnie nadmiarowych pól: niemal tyle samo roboty jest z usuwaniem, ile byłoby z dodawaniem samego roku. W którym miejscu zachodzi to całe mapowanie? Gdzieś u nas, czy gdzieś u nich? Przy cytowaniu artykułów w czasopismach prawie nigdy (a na potrzeby Wikipedii można zaryzykować samo nigdy) nie ma potrzeby podawania daty bardziej dokładnej niż rok. Może przy tym mapowaniu data jest wstępnie rozbita na DD, MM, YYYY i dałoby się usunąć ten niepotrzebny balast? Wostr (dyskusja) 21:23, 11 sty 2017 (CET)[odpowiedz]
    • IMO w tym przypadku należałoby użyć parametr „wolumin” istniejący w szablonie {{cytuj pismo}}. Może warto by było zaimplementować ten parametr w {{#invoke:cytuj}}. Wtedy wywołanie mógłby wyglądać tak:
      D.W. Gaylor, The use of Haber's law in standard setting and risk assessment, „Toxicology”, 1, 149, 2000, s. 17–19, ISSN 0300-483X, PMID10963857 [dostęp 2017-01-10].
@Paweł Ziemian da się zrobić? ~malarz pl PISZ 21:27, 11 sty 2017 (CET)[odpowiedz]
  • @Wargo Mapowanie jest zdefiniowane w templatedata jako "citoid" : { ... }. @malarz pl Dorobię w szablonie cytowania pola wolumin i numer, ale to potrwa i będzie wpływało na książki, bo volume to również nasz tom. Dodanie jedynie woluminu nie pozwoli mi na rozpoznawanie czy cytuję tom książki, czy wolumin czasopisma. Paweł Ziemian (dyskusja) 21:39, 11 sty 2017 (CET)[odpowiedz]
    • Dorobiłem i teraz automat na podstawie pierwszego linku do pubmedu wstawił „D.W. Gaylor, The use of Haber's law in standard setting and risk assessment, „Toxicology”, 149 (1), 2000, s. 17–19, ISSN 0300-483X, PMID10963857 [dostęp 2017-01-11].” Mam nadzieję, że jest trochę lepiej. Wciąż za dużo, ale jest numer woluminu. Paweł Ziemian (dyskusja) 22:19, 11 sty 2017 (CET)[odpowiedz]
      • Okej, to załatwia najważniejszy problem. Ale kurde, rozumiem, że ten Citoid zamierza w taki sposób po prostu działać i wprowadzać dwa razy więcej informacji niż jest potrzebne? I rozumiem, że musimy to naprawiać ręcznie u nas (albo botem)? Wostr (dyskusja) 22:52, 11 sty 2017 (CET)[odpowiedz]
        • Można wykluczać pola. Wargo (dyskusja) 22:55, 11 sty 2017 (CET)[odpowiedz]
        • Usunięcie mapowania ISSN nie wchodzi w rachubę, bo są czasopisma, dla których nie ma doi etc. i wtedy ISSN to jest wartościowa informacja. Zastanawiam się jednak czy nie stworzyć w szablonie cytuj warunków (jeśli podano doi lub pmid, to nie wyświetlaj ISSN itd.). Co o tym sądzicie? KamilK7 (dyskusja) 09:11, 12 sty 2017 (CET)[odpowiedz]
          • {{cytuj}} oparty jest na Lua, więc w grę wchodzą warunki w moduł:cytuj, a do tego potrzebny jest jakiś lua-magik ;) Generalnie ja widziałbym to tak, że jeśli moduł wykrywa, że cytowany jest artykuł to:
            1. jeśli jest DOI, PMID lub PMC – nie wyświetla ISSN
            2. jeśli jest miesiąc lub miesiąc i dzień – wyświetla tylko rok
            3. bot sprawdza: (a) jeśli url dubluje PMID lub PMC (proste, w url-ach będą te same numery, co w parametrach), (b) jeśli url kieruje do tej samej strony co DOI (trudniejsze, nie wiem czy wykonalne) – usuwa url i datę dostępu.
          • Dochodzi więc stała robota dla chętnego bota. Wostr (dyskusja) 14:03, 12 sty 2017 (CET) PS No chyba, że to bardziej sprawa na phabricatora i zmiany w citoidzie. Jeśli tak, to powiedzcie, będę się tam awanturował ;) Wostr (dyskusja) 14:05, 12 sty 2017 (CET)[odpowiedz]
  • Ad 1) Nie chciałbym bezczelnie blokować wyświetlanie niektórych pól bo może to zniechęcać wikipedystów do stosowania szablonów cytowania. Proponuję rozwiązanie, w którym szablon by umieszczał dodatkowe atrybuty w wygenerowanym kodzie pozwalające na selektywne ukrywanie fragmentów za pomocą CSS. Coś na podobieństwo obecnego wyświetlania autorów.
  • Ad 2) Zgoda na zamianę na rok ale pełna lub miesięczna data byłaby w dymku, po wskazaniu roku kursorem myszy.
  • Ad 3) Mógłbym blokować całkowicie linki, które zaczynałyby się tak samo jak ewentualne generowane automatycznie linki na podstawie standardowych identyfikatorów. Na tę okoliczność potrzebna będzie kategoria techniczna, żeby te wywołania sprawdzać i ewentualnie sprzątać botem.

Poniżej prezentuję wynik ze swojego brudnopisu demonstrujący 1. i 2. przypadek:

D. W.D. W. Gaylor D. W.D. W., The use of Haber's law in standard setting and risk assessment, „Toxicology”, 149 (1), 2000, s. 17–19, ISSN 0300-483X, PMID10963857 [dostęp 2017-01-11].

Proponuję umieścić sobie w Specjalna:Moja strona/common.css następujący kod:

.citation.pmid .issn, .citation.doi .issn, .citation.pmc .issn {
	background: yellow;
}

Podświetli on w przykładzie fragment z numerem ISSN na żółto. Zamieniając wpis background: yellow; na display: none; spowodujemy jego ukrycie.

Jakby się dobrze przyłożyć i umiejętnie oznaczyć każdy kluczowy fragment to zmiana prezentacji mogłaby się odbywać tylko w CSS. Pozwoliłoby to unikać modyfikacji kodu generującego treść przypisu skutkującego odświerzaniem zawartości stron. Paweł Ziemian (dyskusja) 21:31, 12 sty 2017 (CET)[odpowiedz]

Ale jaki jest cel pokazywania czytelnikowi numeru ISSN czasopisma, jeśli ma linki prowadzące bezpośrednio do artykułu? Zupełnie nie widzę dlaczego brak bezsensownego parametru na ekranie miałby kogoś zniechęcać do stosowania szablonu. Korzystający z generatora szablonu w VE zapewne i tak w znakomitej większości w ogóle nic nie zauważą, a ci, którzy wiedzą, jak wygląda poprawne cytowanie artykułu naukowego, nie będą mieli nic przeciwko jego brakowi. Nie wierzę, że ktokolwiek zarzuci korzystanie z szablonu, bo mu się ISSN nie wyświetla! :-) Oczywiście trzeba w opisie szablonu poinformować, kiedy ISBN należy wpisywać i kiedy nie jest prezentowany. Pozostawienie tak jak jest może z kolei prowadzić do tworzenia niewłaściwego mniemania, że ISSN należy zawsze podawać. Michał Sobkowski dyskusja 22:52, 12 sty 2017 (CET)[odpowiedz]
D.W. Gaylor, The use of Haber's law in standard setting and risk assessment, „Toxicology”, 149 (1), 2000, s. 17–19, ISSN 0300-483X, PMID10963857 [dostęp 2017-01-11].
Na razie chyba wystarczy. Paweł Ziemian (dyskusja) 23:12, 12 sty 2017 (CET)[odpowiedz]
  • @Paweł Ziemian Okej, wygląda dobrze. I może nawet lepiej, bo można sobie w css-ie ustawić widoczność tych parametrów i odpowiednie podświetlenie, aby łatwo znaleźć i potem usunąć. Jest jakaś opcja, aby tak samo ustawić sobie, aby np. takie czerwone 'url' się pokazywało obok przypisu w przestrzeni głównej (bo np. otwieram z kategorii art lewodopa i muszę szukać, który przypis ma podany url do PubMedu)? Wostr (dyskusja) 00:51, 13 sty 2017 (CET)[odpowiedz]
  • @Paweł Ziemian, super, wielkie dzięki za szybką akcję! Czy jednak ten czerwony url jest wyświetlany (poza PG) intencjonalnie? Jeśli tak, to obawiam się, że mało kto będzie wiedział o co chodzi. Jest jeszcze problem z url-em, gdy szablon generowany jest z DOI, a nie z PMID-u - tu poprawki nic nie zmieniły, zob. testowe wyniki generowanych szablonów. Strzelam, że mieszać może http (DOI) vs https (PMID). Michał Sobkowski dyskusja 15:45, 13 sty 2017 (CET)[odpowiedz]
    • @Michał Sobkowski Właśnie z moich obserwacji wynika, że ten czerwony url się nie wyświetla. Dodałem sobie w css-ie formułkę
      .citation.pmid .issn, .citation.doi .issn, .citation.pmc .issn, .citation.nourl .accessdate { 
      	display : inline !important;
      	background : yellow !important;
      }
      i mi podświetla to, co trzeba usunąć ręcznie, ale właśnie chciałbym sobie coś dodać, aby ten czerwony 'url' też się wyświetlał ;). Odnośnie DOI sądzę, że jest to niewykonalne na takim samym poziomie co PMID. W PMID (i PMC) masz numer podany w linku, a w przypadku DOI podawany jest url wygenerowany przez stronę http://dx.doi.org (a więc nie ma jak porównać DOI z szablonu z linkiem). To chyba musiałby już być bot, który by otwierał link generowany przez numer DOI i porównywał go z URL-em. Wostr (dyskusja) 16:45, 13 sty 2017 (CET)[odpowiedz]
$(document).ready(function()
{
	$(".problemy-w-cytuj")
		.show("slow")
		.css("display", "inline")
		.css("color", "red");
});

Takich źródeł problemów jest więcej. Ja mam u siebie .problemy-w-infobox, .problemy-w-odn, .problemy-w-cytuj, .problemy-w-mapa-lokalizacyjna, .problemy-we-współrzędne, .problemy-w-cytuj-strone. Już sam nie pamiętam co one tam wypisują. Na pewno jedną z funkcji jest wykrywanie nieobsługiwanych pól, jeśli w szablonie jest wywołanie {{#invoke:Sprawdź|Parametry}}.

  • @Michał Sobkowski Z DOI się nie da, bo linki są przekierowaniem. Tutaj trzeba każdy link sprawdzić jakimś botem. Może @Masti mógłby coś dorobić, gdyż jego bot ciągle przeczesuje całą wiki w poszukiwaniu martwych linków. Algorytm jest w sumie prosty. Jeśli szablon cytowania ma niepuste pole {{{doi}}} i zamieniane jest ono w docelowy url zgodny z polem {{{url}}}, to pole {{{url}}} jest do wyczyszczenia.
  • Jeśli chodzi o niezrozumiały czerwony opis doklejany na końcu, to pierwotnie był to mój prywatny mechanizm diagnostyczny. Ale nic nie stoi na przeszkodzie, aby zamienić go na jakieś inne kody błędów. Trzeba by to również opisać w dokumentacji szablonu w sekcji technicznej. Zresztą nie dopisałem tam jeszcze informacji o obecnie dodanych funkcjach.
  • Po ostatnie, ja bym z szablonu nie usuwał ISSN jeśli jest on prawidłowy, ani nie redukował daty do roku. Szablon te pola przekazuje do wewnętrznie generowanego znacznika w formacie en:COinS. To, że czegoś na oczy nie widać, nie znaczy, że tego nie ma, albo nikt lub nic z tego nie korzysta. Paweł Ziemian (dyskusja) 18:44, 13 sty 2017 (CET)[odpowiedz]
  • Zauważyłem, że mamy taki szablon {{JSTOR}}, bardzo mało popularny, ale jednak jest. Dorabiam jego obsługę do szablonu cytowania i mam pytanie czy byłoby nadużyciem gdyby to pole tworzyć również wirtualnie na podstawie DOI. Taki przykład pierwszy z brzegu:
P. H.P. H. Oehser P. H.P. H., Another New Generic Name for a South American Marsupial, „Journal of Mammalogy”, 15 (3), 1934, s. 240, DOI10.2307/1373858, JSTOR1373858 (ang.).
@Wostr, @Michał Sobkowski Okazuje się bowiem, że nie zawsze link DOI i link JSTOR to to samo. W drugą stronę to na pewno nie zawsze działa, bo znalazłem kontrprzykład, ale w tę stronę wpisałem kilka i linki zawsze działały. Paweł Ziemian (dyskusja) 21:03, 15 sty 2017 (CET)[odpowiedz]
@Paweł Ziemian, odnośnie dodania obsługi JSTOR to jak najbardziej. Odnośnie automatycznego tworzenia numeru JSTOR do DOI nie widzę większych problemów, o ile jesteś pewien, że te automatyczne identyfikatory będą poprawne? W każdym razie: imho można zrobić takie automatyczne generowanie i jednocześnie włączyć w tym przypadku to samo, co przy PMID i PMC – jeśli url dubluje JSTOR to nie jest wyświetlany. JSTOR i DOI nie zawsze będą tym samym, bo z tego co pamiętam, w bazie Crossrefu (DOI) można dodać więcej niż jeden stable URL (tzw. secondary URL czy coś takiego) i wtedy URL wydawcy jest jako pierwszy, a drugi np. ten JSTOR. Wostr (dyskusja) 22:38, 15 sty 2017 (CET)[odpowiedz]
Z Jstor korzystam sporadycznie, więc trudno mi się wypowiadać. Ale jeśli automatyczny link nie prowadzi na drzewo, to warto go podać. Michał Sobkowski dyskusja 23:08, 15 sty 2017 (CET)[odpowiedz]

Czy ktoś może poprawić tę grafikę (albo ją usunąć)?

Od 2008 roku załadowana jest na Commons taka oto grafika. Za piękna to ona może nie jest, ale ok, niech zostanie. Niestety, wymaga ona rychłej poprawy, bo w tej chwili są to jakieś kocopoły i serwowanie Czytelnikom bzdur. Chodzi przede wszystkim o dwie rzeczy:

  • Macedonia podpisana jest jako Makedonia, a w legendzie zamiast języka macedońskiego jest język makedoński
  • Co to jest napaćkane na północ od Kotliny Kłodzkiej? W kolorze to jest chyba języka rusińskiego. Tam są jacyś Łemkowie? Chyba raczej mniejszość niemiecka, ale zaznaczanie niemieckiego na mapie języków słowiańskich jest bezzasadne. Trzeba by to nieporozumienie zamalować.

Ewentualnie można to usunąć, jeśli nie ma widoków ma poprawę, bo nie możemy ilustrować haseł mapami zawierającymi błędy rzeczowe i ortograficzne. Hoa binh (dyskusja) 11:09, 11 sty 2017 (CET)[odpowiedz]

Zobacz też Wikipedia:Kawiarenka/Artykuły dyskusja/Archiwum/2013-czerwiec#Języki słowiańskie - mapa --WTM (dyskusja) 11:33, 11 sty 2017 (CET)[odpowiedz]
  • Poprawki zgłoszone przez Hoa binha zrobiłem (co prawda w dwóch etapach, bo się zamotałem). Biorąc pod uwagę dyskusję podlinkowaną przez WTM, najlepiej zrobić podobną mapę z podaniem konkretnego źródła, ale to dla mnie za trudne. Wiklol (Re:) 12:37, 11 sty 2017 (CET)[odpowiedz]
    Tyle, że zrobienie mapy na podstawie jednego źródła (najlepiej opracowania naukowego), byłoby jednak naruszeniem praw autorskich, gdyż byłaby to tylko zmiana graficzna formy z jakiegoś tekstu na mapę. Tu mogłyby być rożne źródła, np. spisowe, jednak należałoby ustalić zasady przedstawiania języków mniejszościowych, bo teraz np. jest kreskowanie dla Rusińskiego, którym mówiący stanowią co najwyżej po kilka procent oznaczonych obszarów (np. na terenie Ukrainy jest zaledwie 32 tys. Rusinów/Hucułów/Łemków/Bojków), a brak kreskowania dla rosyjskiego w środkowowschodniej Ukrainie, którym posługuje się po 20-30% mieszkańców. Aotearoa dyskusja 13:23, 11 sty 2017 (CET)[odpowiedz]
    Dane bądź wyniki badań są wyłączone z zakresu ochrony prawnoautorskiej. Chroniona jest forma ich wyrażenia, np. mapa. IOIOI2 14:52, 11 sty 2017 (CET)[odpowiedz]
    To dość oryginalna interpretacja, zważywszy, że w art. 1 ust. 2 ustawy o prawie autorskim utwory naukowe są wymienione wprost. Idąc tym tokiem rozumowania każdą publikację będącą wynikiem badań naukowych należałoby uznać za część domeny publicznej. Aotearoa dyskusja 17:33, 11 sty 2017 (CET)[odpowiedz]
    Nie moja. Należy odróznić utwór od wyników badań czy danych. IOIOI2 17:35, 11 sty 2017 (CET)[odpowiedz]

Alfabetyczne sortowanie przypisów

Szablon {{Przypisy}} powoduje standardowe dla Wikipedii wyświetlanie przypisów w kolejności pojawiania się po raz pierwszy odnośnika do danej pozycji. Czy istniałaby techniczna możliwość dodania czytelnikowi możliwości wyświetlenia przypisów w kolejności alfabetycznej ('autor', 'nazwisko', 'tytuł') i w ten sposób uczynienia z pełnych wykazów źródeł podanych w formie przypisów bibliograficznych – bibliografii alfabetycznej. Idealnie byłoby, gdyby obok tytułu na wzór dotychczasowych linków w standardowych nagłówkach [edytuj | edytuj kod] wyświetlało się obok nagłówka "Przypisy" przemiennie [sortuj wg odnośników] i [sortuj alfabetycznie]. Kenraiz (dyskusja) 12:39, 16 sty 2017 (CET)[odpowiedz]

  • Obecnie nie ma takiej możliwości. To musiałby być jakiś skrypt, lecz z powodu nagminnego unikania szablonów cytowania nie widzę możliwości automatycznego odszukania pól do sortowania (na przykład nazwiska autora). Żeby to miało jakiekolwiek szanse na realizacje wymagane byłoby jakieś „mikrootagowanie” wszystkich cytowanych źródeł. Paweł Ziemian (dyskusja) 22:37, 17 sty 2017 (CET)[odpowiedz]
    • Podrzucę pomysł: a gdyby potraktować parametry "name" w tagu "ref" jako klucz sortowania? Jakby ktoś chciał mieć posortowaną listę przypisów, po prostu musiałby używać nazwisk autorów w roli "name". Gżdacz (dyskusja) 23:42, 17 sty 2017 (CET)[odpowiedz]
      • Można by sortować najpierw według kolejności standardowych pól w szablonach cytowania ('autor', 'nazwisko', 'tytuł'), następnie (w przypadku braku powyższych) według 'name' i na końcu według tego co jest za wywołaniem '<ref>'. Tam gdzie jest bałagan w przypisach sortowanie nie będzie działało sensownie, ale to mogłaby być motywacja dla edytorów do zadbania o odpowiednie formatowanie przypisów. Ważne, że dla dobrze zredagowanych artykułów, zwłaszcza wzorcowych, zwykle z bardzo licznymi przypisami – mogłoby to działać poprawnie, a przy tym byłoby w ich wypadku szczególnie użyteczne. Kenraiz (dyskusja) 13:12, 18 sty 2017 (CET)[odpowiedz]

A gdyby szablon {{s:Przypisy|przypisy=}} po prostu respektowal kolejnosc przypisow podanych mu na liscie, zamiast je przestawiac wedle kolejnosci pierwszych wystapien w tekscie? Gżdacz (dyskusja) 23:24, 17 sty 2017 (CET)[odpowiedz]

  • To w tedy w niektórych artykułach byłoby posortowane w takiej kolejności w jakiej podali autorzy artykułu - często nie jest to kolejność alfabetyczna, niekiedy przypadkowa, wynikająca z tego kiedy dany przypis został dodany (na dodatek niektórzy dopisują na końcu, inni na początku), natomiast w innych artykułach, gdzie zastosowano szablon {{Przypisy}} bez parametru, byłaby to kolejność występowania odnośników w tekście. Niezły bałagan by się zrobił. KamilK7 09:09, 18 sty 2017 (CET)[odpowiedz]
    • Każdy mechanizm tak można skrytykować, że jedni go włączą a inni nie i będzie bałagan. Zakładam, że w uzasadnionych przypadkach autor mógłby sam posortować przypisy i wstawić parametr każący ten porządek respektować przy generowaniu przypisów. To, że coś można będzie zrobić lepiej i sensowniej i niektórzy z tego skorzystają nie oznacza, że zwiększy się poziom bałaganu. Gżdacz (dyskusja) 14:56, 18 sty 2017 (CET)[odpowiedz]

Content Translation

Jak wyłączyć komunikat przy dodawaniu nowego hasła poprzez kliknięcie w czerwony link Tworzenie nowych stron poprzez tłumaczenie jest teraz prostsze! Czy chcesz wypróbować narzędzie Tłumaczenie Treści (beta)? z wyborem opcji Nie, dziękuję i Spróbuj Content Translation? Farary (dyskusja) 19:12, 18 sty 2017 (CET)[odpowiedz]

Klikasz opcję nie, dziękuję i od tej pory okienko nie powinno się już pokazywać (oczywiście dopóki nie wyczyścisz cache'u/historii przeglądarki). Sir Lothar (dyskusja) 14:51, 23 sty 2017 (CET)[odpowiedz]

Zmiany ikon w szablonach w całej Wiki

Właśnie wszędzie pozmieniały mi się ikony w szablonach, bardzo wielu szablonach. Nawet tam, gdzie ustawione jest „pomarańczowe ostrzeżenie” to i tak jest już „czarne ostrzeżenie”. Chciałem się już kogoś zacząć czepiać, ale... w szablonach nie ma śladu, w {{ikona}} nie, w odpowiednim module też nie. Czy ktoś mógłby się przyznać i przede wszystkim... nie zmieniać takich rzeczy według własnego widzimisię? (a jakoś nie widziałem dyskusji o tym; przegapiłem?) Wostr (dyskusja) 23:22, 18 sty 2017 (CET)[odpowiedz]

Zaczął gdzieniegdzie jakiś bot, a @Karol Szapsza kontynuuje. Paweł Ziemian (dyskusja) 23:28, 18 sty 2017 (CET)[odpowiedz]
Z tego, co widzę, są to ikony z „centralnej biblioteki”, czyli te, które są/mają być używane we wszystkich funkcjach pisanych przez Wikimedia Foundation (np. VE, nowy wikikod, Flow, nowy wgląd stron specjalnych, interaktywne mapy) oraz które są zalecane do używania przez wszystkich innych (np. Wikimedia Deutschland: Wikidane, suwak wersji). Generalnie one są „legitne”, żaden OR czy POV. Jeżeli w danym miejscu kolor jest zły, można załadować odpowiednio pokolorowaną (na podstawie palety kolorów z ww. „centralnej biblioteki”). Oczywiście kolorowy wariant powinien trafić do modułu ikona. Tar Lócesilion (queta) 23:35, 18 sty 2017 (CET)[odpowiedz]
/konflikt/ A, podszablon. W każdym razie: skoro bot zmienia nazwy, to czemu np. {{Przekierowanie}} ma nową ikonkę i w dodatku tak koszmarną, że.... Może najpierw jakieś info chociaż, dyskusyjka, a nie frontalny atak na wszystkie ikony? Wostr (dyskusja) 23:37, 18 sty 2017 (CET)[odpowiedz]
Zielony listek stał się czarnym... czymś (), wszystkie kolorowe znaczki ostrzeżeń są teraz zawsze czarne, reuse to zawsze była... drukarka? Fajnie, że ktoś sobie coś zaleca gdzieś tam, ale co to ma wspólnego z rzeczywistością? Niech sobie te zalecenia wdraża we własnym brudnopisie, nie przypominam sobie choćby informacji, że dobrze znane, dopasowane kolorystycznie ikonki nagle, nocą, zmienią się w czarne potworki. Wostr (dyskusja) 23:45, 18 sty 2017 (CET)[odpowiedz]
No to napisz do Szapszy i już, ale może bez wrażenia osaczenia i nocnych zmian. Nikt nikogo do żadnej Berezy nie chce wysyłać. Po prostu część zmian mogła być nieprzemyślana czy błędna, wielkie mi novum. Tar Lócesilion (queta) 23:53, 18 sty 2017 (CET)[odpowiedz]
Dobrze, nawet jakbym bardzo chciał (a nie chcę) zmieniać te ikonki na jakiekolwiek z tej „centralnej biblioteki” to i tak mam do wyboru: czarną, niebieską i pomarańczową (znaczki ostrzeżeń; czerwonej nie ma), a w niektórych przypadkach nawet czarną, czarną lub czarną. Sorry, nie zamierzam nikogo „osaczać”, ale czasami to już ręce opadają, skoro kolejny raz trzeba się prosić chociażby o informację o takich zmianach. Wostr (dyskusja) 00:10, 19 sty 2017 (CET)[odpowiedz]
  • Każde zauważalne zmiany bez wcześniejszego uzgodnienia ze społecznością wzbudzają odruch oporu i protesty. Udało się coś w ten sposób wprowadzić, że ta metoda jest co pewien czas ponawiana? Nawet najlepszy zamysł szlag trafi, jeśli zostanie wprowadzony bez konsultacji. Kenraiz (dyskusja) 23:59, 18 sty 2017 (CET)[odpowiedz]
  • /konflikt/ Kolejny raz zabawa ikonkami, ale najwyraźniej tylko mi to przeszkadza i wychodzi na to, że się znowu czepiam. @Karol Szapsza, mógłbyś jakoś wyjaśnić te zmiany i podać jakieś argumenty, np. za obecną ikonką w {{Przekierowanie}}? Wostr (dyskusja) 00:00, 19 sty 2017 (CET)[odpowiedz]
    • Nie tylko Tobie, ja też uważam, że niektóre zmiany są niewłaściwe. To wszystko powinno jak najściślej wynikać z funkcji ikonek określonych w OOjs UI, żeby potem nie było zaskoczenia, że to, co tu zrobiliśmy, to OR i #niespójność. Np. drukarkę na reuse wymyśliłem ja, dawno temu, ale umieściłem ją chyba tylko w jednym miejscu. Dopóki OOjs UI nie mają ikonek pasujących do danej funkcji, to powinno się je stosować, no... bardzo ostrożnie. Tar Lócesilion (queta) 00:13, 19 sty 2017 (CET)[odpowiedz]
  • Moim zdaniem wygląda gorzej. Prośba o przywrócenie do stanu pierwotnego. Boston9 (dyskusja) 00:03, 19 sty 2017 (CET)[odpowiedz]
  • Nie ma tu za wiele do uzasadniania: po prostu dotychczasowe ikony nie są spójne z aktualnymi zaleceniami layoutu WMF. Dlatego tam, gdzie pojawiły nowe, aktualne odpowiedniki, wprowadziłem odpowiednie zmiany (korzystając z katalogu standardowych ikon bieżącego layoutu w Commons). Ikony z założenia powinny być czarne, bo ostrzeżenie stanowi już sam kolor marginesu {{Ambox}} lub podobnego szablonu – i to jest w zupełności wystarczające. Swoją drogą, nie tak dawno, również bez podejmowania zbędnej lokalnej dyskusji zmieniliśmy także odcień kolorów w szablonach mbox – te zmiany po prostu uwarunkowane są zaleceniami layoutu WMF, nie zaś lokalną opinią użytkowników, przez którą przemawiają przyzwyczajenia do dotychczasowych (niespójnych) elementów designu… Dyskusja nt. wprowadzanych zmian layoutu nie powinna się odbywać tutaj, ale gdzieś na githubie lub na stronach projektantów, a my powinniśmy za wszelką cenę dążyć do ustandaryzowania naszego designu z przyjętymi zaleceniami odgórnymi… Proszę o przywrócenie naniesionych zmian… ping @Tar Lócesilion Karol Szapsza (dyskusja) 14:28, 19 sty 2017 (CET)[odpowiedz]
    • Akurat te zmiany w kolorach były tak niewielkie, że nikt na to nie zwrócił uwagi. A zmiany w ikonach były już nie tylko łatwo zauważalne, ale też czasem błędne. Tar Lócesilion (queta) 14:51, 19 sty 2017 (CET)[odpowiedz]
    • @Karol Szapsza, rozumiem, że nie żartujesz? Jeśli nie, to wolę nie komentować tego pochylonego zdania/cytatu, bo mógłbym zaraz oberwać blokiem po uszach. A zmiany można przywrócić PO DYSKUSJI! Wostr (dyskusja) 20:06, 19 sty 2017 (CET)[odpowiedz]
      • Ja wpisałem komentarz, ale usunąłem przeczytawszy jak groźnie zabrzmiały w mojej wizji skutki opisanego przez Karola podejścia. Przed Wikipedią spędziłem parę lat w innym społecznym projekcie internetowym, którego społeczność została rozproszona i zniechęcona z powodu jednego błędu technicznego administracji... Kenraiz (dyskusja) 00:00, 20 sty 2017 (CET)[odpowiedz]
  • Również ja zdecydowanie proszę o niewprowadzanie rewolucyjnych zmian w wyglądzie polskojęzycznej Wikipedii, która jakby nie było ma wiele swoich lokalnych ustaleń, ustawień (tu wpisz lepsze ujęcie tematu), a nie bez dyskusji i bez informowania Społeczności. Wiele z tych grafik osobiście wcale mi się nie podoba. Wiklol (Re:) 21:45, 19 sty 2017 (CET)[odpowiedz]

46.112.77.245 (dyskusja) 20:35, 22 sty 2017 (CET)[odpowiedz]

Spolszczenie nazw szablonów

Taka drobnostka: swego czasu spolszczono nazwy niektórych szablonów, np. {{Disambig}} na {{Ujednoznacznienie}}. Czy są plany, aby w ten sposób potraktować wszystkie szablony? Np. {{Mainsec}}? 195.150.184.74 (dyskusja) 13:09, 20 sty 2017 (CET)[odpowiedz]

  • Nie ma takich planów, co nie znaczy, że to się nie stanie. A coś jeszcze oprócz mainsec trzeba by spolszczyć? Tar Lócesilion (queta) 04:45, 21 sty 2017 (CET)[odpowiedz]
    • To może jeszcze spolszczmy <ref> do <przyp> oraz {{nbsp}} do {{twarda_spacja}}, bo czemu nie. Jestem przeciwniczką spolszczania szablonów, szczególnie bez pozostawienia ich odpowiedników angielskich. Efekt teraz mamy taki, że spolszczać trzeba szablony cytowań, gdy można by (po weryfikacji treści źródeł dostępnych online) przekopiować szablon cytowania. Dobrze, że jest narzędzie do tłumaczenia tych szablonów, jednak prawie nikt o nim nie wie. 46.112.77.245 (dyskusja) 20:14, 22 sty 2017 (CET)[odpowiedz]
    • Pani powyżej odpowiadam, że moje pytanie nie ma związku z toczącą się równolegle dyskusją nt. szablonów cytowań. To czysty przypadek i inne zagadnienie. Nie nawołuję również do kasowania przekierowań ze starych nazw (zresztą nie ma takiej praktyki, czego przykładem {{Disambig}}, {{Łac.}} itd.), nie nawołuję też do zmian w nazwach szablonów, które mają nazwę dziwną, ale praktyczną ({{Nbsp}}, {{Fd}}, {{Źd}} itd.). Natomiast @Tar Lócesilionowi odpowiadam: np. {{Clear}} i inne szablony z wywołaniem {{Wysokie ryzyko}} w dokumentacji (nie więcej niż 202 sztuki klik, nie umiem zmusić żeby wyświetliło je wszystkie), w prawie każdej kategorii by się coś znalazło. 195.150.184.74 (dyskusja) 15:04, 24 sty 2017 (CET)[odpowiedz]

Tydzień Kolumbijski

Prosiłbym o przeniesienie tego do dyskusji tego :) Z góry dziękuję. Tournasol Słucham :) 23:11, 20 sty 2017 (CET)[odpowiedz]

Przeniosłem (zostawiając redirect – linkujące), nie bardzo wiem w czym problem :) Nedops (dyskusja) 23:24, 20 sty 2017 (CET)[odpowiedz]
Raz próbowałem i jeszcze więcej nagmatwałem, więc wolę zostawić to innym :) Tournasol Słucham :) 23:31, 20 sty 2017 (CET)[odpowiedz]

Developer Wishlist Survey: propose your ideas

Wątek założony przed: 21:04, 21 sty 2017 (CET)

At the Wikimedia Developer Summit, we decided to organize a Developer Wishlist Survey, and here we go:

https://www.mediawiki.org/wiki/Developer_Wishlist

The Wikimedia technical community seeks input from developers for developers, to create a high-profile list of desired improvements. The scope of the survey includes the MediaWiki platform (core software, APIs, developer environment, enablers for extensions, gadgets, templates, bots, dumps), the Wikimedia server infrastructure, the contribution process, and documentation.

The best part: we want to have the results published by Wednesday, February 15. Yes, in a month, to have a higher chance to influence the Wikimedia Foundation annual plan FY 2017-18.

There's no time to lose. Propose your ideas before the end of January, either by pushing existing tasks in Phabricator or by creating new ones. You can find instructions on the wiki page. Questions and feedback are welcome especially on the related Talk page.

The voting phase is expected to start on February 6 (tentative). Watch this space (or even better, the wiki page) - SSethi_(WMF) January 21st, 2017 3:07 AM (UTC)

Szablony {{Cite web}} itp.

Przydałyby się szablony wspomniane w tytule również w wersji polskiej Wikipedii. ułatwiłoby to tłumaczenie. Większość książek i stron ma jedną wersję językową, więc nie widzę potrzeby zmuszania wikipedystów do tłumaczenia tych szablonów, skoro autor, tytuł, wydawca itp. pozostają bez zmiany. Zmienianie szablonów niestety utrudnia pracę z wiki-tekstem. Chodzi tylko o szablony związane z cytowaniem, źródłami itp. Czyli to co W. od nas wymaga. 46.112.77.245 (dyskusja) 14:13, 22 sty 2017 (CET)[odpowiedz]

Nie, trzeba by było mieć także wszystkie angielskie parametry. I potem będą wisieć takie potworki w kodzie. Są chyba jakieś gadżety do tłumaczenia szablonów cytowania, więc można z nich korzystać. Poza tym – powinniśmy w końcu skończyć z możliwością tłumaczenia artykułów z innych wersji językowych, o ile autor nie zagląda nawet do tych źródeł. A jak zagląda, to w wielu przypadkach i tak trzeba te przypisy poprawiać z innych wersji językowych. Więc tak czy siak, przypisy trzeba poprawiać, aby nie przenosić jakiejś kaszany z en.wiki itp. Wostr (dyskusja) 14:41, 22 sty 2017 (CET)[odpowiedz]
Problem, w tym, że ta "kaszana" na angielskiej wiki jest dużo lepszej jakości niż nasza polska. Wiem to z codziennego życia, gdy w pracy korzystam z wiki. Niestety opisy na polskiej wiki szczegolnie w aspektach technicznych są dużo gorszej jakości, a często nawet błędne, w przeciwieństwie do tych na angielskiej. Tam czasem też znajdzie się błąd, ale rzadko. Niestety ale poprawiać tego z pracy nie mogę, ponieważ mamy zakaz edycji Wikipedii w czasie pracy. Wspomnieć też należy, że na en.wiki jest dużo więcej treści niż na polskiej (mimo, że język angielski bardziej skompresowany niż polski) i nie jest to efekt pustosłowia. Na polskiej wiki, gdy trafimy na długi artyuł - to zazwyczaj jest to albo twórczość własna albo pustosłowie. 46.112.77.245 (dyskusja) 20:01, 22 sty 2017 (CET)[odpowiedz]
Oczywiście, na en.wiki jest dużo więcej. Ale czy na pewno lepszej jakości? Śmiem wątpić. A już na pewno nie powinno być zgody na tłumaczenie tego, co tam jest bez jakiejkolwiek próby weryfikacji. Tak samo z kopiowaniem stamtąd źródeł (a tym bardziej automatycznie), bo często zupełnie nie przystają do naszych standardów edycyjnych i wymagają poprawek. Wostr (dyskusja) 20:27, 22 sty 2017 (CET)[odpowiedz]
Bezmyślnie nie kopiuję/tłumaczę, dlatego też przy edycji art. o Windows 10 wypowiedzi blogerów zostały usunięte, jako nie spełniające tych standardów. Co do zdania o jakości niestety śmiem się nie zgodzić z Wostr. Pierwsze lepsze hasło z dziedziny technicznej: HDLC - proszę sam porównaj jakość. Ile się dowiedziałeś z polskiej wersji, a ile z angielskiej? 164.126.193.81 (dyskusja) 22:15, 22 sty 2017 (CET)[odpowiedz]
Obce szablony należy przerabiać na polskie, ponieważ polskie szablony cytowań są oparte na zasadach polskiej pisowni, co chyba wszystko wyjaśnia. Beno @ 14:49, 22 sty 2017 (CET)[odpowiedz]

Polska Rada Ekumeniczna, pomożecie?

Artykuł Polska Rada Ekumeniczna. Nagłówek sekcji "Bibliografia" jest mniejszą czcionką niż powinien; również pierwsza pozycja w bibliografii jest pomniejszona. W kodzie źródłowym strony jest coś, czego nie rozumiem. --WTM (dyskusja) 15:40, 22 sty 2017 (CET)[odpowiedz]

30 września 2016; 4 miesiące temu

Czy szablon {{zabytek}} musi do wyświetlania daty korzystać z zagnieżdżonego drugiego szablonu {{Data wydania}}? Nie wiem jak wasza opinia, ale wg mnie, tak średnio ładnie wygląda to: „Narodowy Instytut Dziedzictwa: Rejestr zabytków nieruchomych – województwo opolskie. 30 września 2016; 4 miesiące temu” [podkreślenie moje] w artykułach, w których pisze się o zabytkach (przykład Biskupin (powiat żniński)). Jeśli dobrze patrzę, to Szablon:Data wydania był stworzony z myślą tylko o pokazywaniu daty wydania oprogramowania. --WTM (dyskusja) 22:11, 22 sty 2017 (CET)[odpowiedz]

Zapis „jakiś czas temu” sprawia problemy natury techniczno-aktualizacyjnej z ponadczasowością. Jest poprawny tylko w momencie zapisywania edycji strony. Potem, jeśli strona jest umieszczona w jakiejś pamięci podręcznej nie jest modyfikowany, a czytelnik dostaje stan wygenerowany w momencie zapisu jeszcze później. Jeśli w szablon wygenerował dla przykładu „wczoraj”, a czytamy to trzy dni później to tworzymy „bzdury”. Paweł Ziemian (dyskusja) 22:28, 22 sty 2017 (CET)[odpowiedz]

Wątek poboczny - jakiś czas temu a szablony

Ze względu na częstość tego typu błędów powinno się dodać do szablonu Dopracować parametr "czas". Jest wiele sformułowań typu "Obecnie", "jakiś czas temu", "od jakiegoś czasu", "miesiąc temu", które trudno zakwalifikować jako łasiczki czy pustosłowie. Często wręcz może to być przepisane wprost ze źródeł... 164.126.193.81 (dyskusja) 22:41, 22 sty 2017 (CET)[odpowiedz]
Ja dodaję bezpośrednio przy takim sformułowaniu szablon {{kiedy}}: «Obecnie[kiedy?] pracuje nad swoim drugim solowym albumem...», bądź szablon {{od kiedy}}: «Od kilkunastu lat[od kiedy?] mieszka w...», które wrzucają do kategorii Artykuły z wyrażeniami zwodniczymi. --WTM (dyskusja) 22:56, 22 sty 2017 (CET)[odpowiedz]
To w sumie rozwiązuje sprawę, tylko jeżeli artykuł jest długi i napisany w taki sposób cały to tymi szablonami zaśmiecimy artykuł. W przypadku potrzeby wstawienia dużej ilości szablonów "fakt" - wstawia się jeden szablon co należy dopracować, zaś fakt, tylko tam gdzie jest mocna kontrowersja - jako dodatkowe wskazanie co w pierwszej kolejności razi w oczy.
Szablon fakt ma być wszędzie tam, gdzie brakuje przypisu. Eurohunter (dyskusja) 07:56, 23 sty 2017 (CET)[odpowiedz]

21:14, 23 sty 2017 (CET)

Załatwione The Polish (query) 21:15, 23 sty 2017 (CET)[odpowiedz]

Obrazki importowane via Wikidata

Można zrobić listę artykułów stanowiących część wspólną kategorii Kategoria:Brak grafiki załadowanej lokalnie, załadowano grafikę z serwisu Wikidata i drzewa kategorii Kategoria:Rośliny? Niedawno przypadkowo trafiłem na błąd, teraz zacząłem sprawdzać ww. kategorię i od razu w pierwszym wypatrzonym przypadku (Acaciella) też załadowana była grafika innego taksonu (w tym wypadku usunąłem już podlinkowanie w Wikidata). Jeśli grafika jest trafiona to i tak wymaga podpisania w infoboksie. Kenraiz (dyskusja) 09:55, 24 sty 2017 (CET)[odpowiedz]

Użyj Petscana. --Wargo (dyskusja) 11:27, 24 sty 2017 (CET)[odpowiedz]
@Kenraiz Proszę :) Emptywords (dyskusja) 11:42, 24 sty 2017 (CET)[odpowiedz]
Och, dzięki. Dużo tego... Kenraiz (dyskusja) 11:58, 24 sty 2017 (CET)[odpowiedz]
177 sztuk :) Emptywords (dyskusja) 12:02, 24 sty 2017 (CET)[odpowiedz]

Symbole pod oknem edycji

Czy da się powiększyć znaki i symbole pod oknem edycji? Eurohunter (dyskusja) 22:43, 25 sty 2017 (CET)[odpowiedz]

Może wystarczy taki kod w swoim common.css, wartość font-size wedle gustu:
.mw-editTools {
	font-size: 1.5em;
}
Pozdrawiam, Peter Bowman (dyskusja) 23:16, 25 sty 2017 (CET)[odpowiedz]
Przydałoby się 2.5, ale jedno na drugie nachodzi. Można uzyskać ignorowanie pogrubienia? Eurohunter (dyskusja) 10:12, 26 sty 2017 (CET)[odpowiedz]
Może źle zrozumiałem. Chodziło konkretnie o pojedynczą podgrupę „Znaki i symbole”, między „Najczęstsze” a „Podpis w dyskusji”? Wpisz .plwiki-edittools-section:first-child .mw-charinsert-item zamiast .mw-editTools, to chociaż ograniczy zmiany do „klikalnych” elementów w pierwszym wierszu/grupie (albo zostaw samo .mw-charinsert-item, to obejmie wszystkie elementy). Pogrubienie chyba też da się wykluczyć, ale prosiłbym o dokładniejsze wskazówki. Pozdrawiam, Peter Bowman (dyskusja) 12:06, 26 sty 2017 (CET)[odpowiedz]
Zgadza się, chodzi mi o .mw-editTools (od Najczęstsze po Symbole). Jakich wskazówek dokładnie potrzebujesz? Dodatkowo czy da się zwiększyć odstęp między wierszami? Eurohunter (dyskusja) 13:28, 26 sty 2017 (CET)[odpowiedz]
OK, w takim razie mógłbyś zmienić samo .mw-charinsert-item, jak niżej w kodzie Kamila. Peter Bowman (dyskusja) 13:37, 26 sty 2017 (CET)[odpowiedz]
Problem rozwiązał parametr font-weight: lighter;. Eurohunter (dyskusja) 14:31, 26 sty 2017 (CET)[odpowiedz]
Takie coś?
.mw-editTools {
	font-size: 2.5em;
	font-weight: lighter;
}
Po co wam to takie wielkie? :-) KamilK7 12:19, 26 sty 2017 (CET)[odpowiedz]
Taki przykład:
.mw-editTools {
	font-size: 1.2em;
	font-weight: lighter;
}
.mw-charinsert-item {
	font-size: 1.25em;
}
pozwala ustawiać jedno inaczej, drugie inaczej, ale wartości musisz sobie dobrać takie, jakie ci pasują. KamilK7 12:39, 26 sty 2017 (CET)[odpowiedz]
Zgadza się, chodzi mi o .mw-editTools. Eurohunter (dyskusja) 13:28, 26 sty 2017 (CET)[odpowiedz]