Wikipedia:Kawiarenka/Kwestie techniczne dyskusja/Archiwum/2017-styczeń

Z Wikipedii, wolnej encyklopedii

Panel boczny[edytuj | edytuj kod]

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

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

Załatwione

Rejestr oznaczania[edytuj | edytuj kod]

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

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

20:12, 9 sty 2017 (CET)

Załatwione, ~Cybularny Napisz coś ✉ 20:40, 9 sty 2017 (CET)[odpowiedz]

Moduł:Listen[edytuj | edytuj kod]

Moduł:Listen wstawia Kategoria:Articles with hAudio microformats, co pewnie trzeba by jakoś poprawić. IOIOI2 23:58, 9 sty 2017 (CET)[odpowiedz]

Zrobione. Chyba poprawiłem. Jeśli coś popsułem, proszę krzyczeć. IOIOI2 02:19, 10 sty 2017 (CET)[odpowiedz]

W sekcji Statystyki indywidualne część nazw państw jest na szarym, a część na białym tle. W innych artykułach z serii problem nie występuje. Czy ktoś wie, jak to naprawić? Barcival (dyskusja) 15:19, 11 sty 2017 (CET)[odpowiedz]

Trzeba jako nagłówek w tabeli, wtedy domyślnie koloruje. Załatwione Wargo (dyskusja) 16:12, 11 sty 2017 (CET)[odpowiedz]

Dyskusja wikiprojektu[edytuj | edytuj kod]

Prosiłbym tą stronę przenieść do dyskusji tego wikiprojektu. Próbowałem sam, ale jeszcze bardziej zagmatwałem... Tournasol Słucham :) 18:41, 11 sty 2017 (CET)[odpowiedz]

Załatwione Torrosbak (dyskusja) 18:49, 11 sty 2017 (CET)[odpowiedz]
Nie wiem jak to zrobiłeś, ale dzięki :) Tournasol Słucham :) 18:50, 11 sty 2017 (CET)[odpowiedz]

Wyświetlanie przypisu[edytuj | edytuj kod]

Czy może ktoś mi powiedzieć...jaka jest przyczyna tego, że po wskazaniu danej literki/cyferki przypisu zamiast treści...wyświetla się "zębatka" ? Kamil.ryy (dyskusja) 10:46, 15 sty 2017 (CET).[odpowiedz]

Powinien wyświetlać się podgląd przypisu z gadżetu "Reference Tooltips" Wargo (dyskusja) 11:13, 15 sty 2017 (CET)[odpowiedz]
@Wargo Właśnie, w niektórych prawidłowo się wyświetlają...a tutaj już nie Kamil.ryy (dyskusja) 11:19, 15 sty 2017 (CET).[odpowiedz]
Tylko w konkretnych miejscach? Gdzie? Wargo (dyskusja) 11:22, 15 sty 2017 (CET)[odpowiedz]
Załatwione Kamil.ryy (dyskusja) 16:28, 15 sty 2017 (CET).[odpowiedz]

Łączenie szablonów[edytuj | edytuj kod]

Witajcie. Mam prośbę czy ktoś mógłby pomóc w połączeniu szablonów (infobox)

  • 1. Szablon areszt - dotyczący obozu w latach 1940-1945
  • 2. Szablon UNESCO - dotyczący obozu, a raczej już muzeum w latach 1979-nadal

W artykule są problemy z współrzędnymi i np. tworzy się mapa III Rzeszy do roku 1938. Tutaj wygląda to tak jak mogłoby wyglądać w artykule, ale problemu z tymi współrzędnymi i wyskakującą mapą, nie potrafię ogarnąć. --Swd (dyskusja) 09:06, 16 sty 2017 (CET)[odpowiedz]

Skopiuj aktualny wariant do artykułu i napisz czy o to chodziło? ~malarz pl PISZ 09:43, 16 sty 2017 (CET)[odpowiedz]
Tak wielkie dzięki :)--Swd (dyskusja) 10:03, 16 sty 2017 (CET)[odpowiedz]

Załatwione ~malarz pl PISZ 13:15, 16 sty 2017 (CET)[odpowiedz]

00:24, 17 sty 2017 (CET)

Załatwione, ~Cybularny Napisz coś ✉ 00:33, 17 sty 2017 (CET)[odpowiedz]

21:14, 23 sty 2017 (CET)

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

Masowe usuwanie/odtwarzanie[edytuj | edytuj kod]

Wiem, że mamy takie narzędzie, ale nie korzystałem nigdy :) Trzeba przywrócić i posprzątać błędnie usunięte [16] Nie obrażę się, jak ktoś mnie wyręczy w tym odtwarzaniu, ale i instrukcja co i jak nie zaszkodzi :P Nedops (dyskusja) 16:08, 26 sty 2017 (CET)[odpowiedz]

Pewnie chodzi Ci o Specjalna:Masowe usuwanie. Obawiam się, że nic w stylu Specjalna:Masowe odtwarzanie nie istnieje. Michał Sobkowski dyskusja 16:46, 26 sty 2017 (CET)[odpowiedz]
Dużo tego jest? --Wargo (dyskusja) 18:37, 26 sty 2017 (CET)[odpowiedz]
Było bodaj 255, ostatnie 5 zrobiłem ręcznie od razu, więc 250. Nedops (dyskusja) 22:07, 26 sty 2017 (CET)[odpowiedz]
@Nedops: przerobiłem jeden ze swoich skryptów, aby teraz masowo odtwarzał listę stron (w razie potrzeby można go wykorzystać także do innych czynności, zmieniając kilka linii). Wystarczy utworzyć podstronę swojej strony użytkownika o nazwie "undelete-list" (w Twoim przypadku – Wikipedysta:Nedops/undelete-list) i umieścić w niej linki do wszystkich stron, które mają zostać odtworzone. Format jest obojętny, skrypt rozpoznaje wszystkie linki w postaci [[strona_która_zostanie_odtworzona]], resztę ignoruje. W nagłówku podstrony zostanie wygenerowany przycisk, który rozpocznie proces odtwarzania stron, pozwalając na wpisanie powodu. Instalacja: wklej poniższy kod do swojego common.js.
importScript( 'Wikipedysta:Peter Bowman/undelete.js' );
(link do strony skryptu) Pozdrawiam, Peter Bowman (dyskusja) 19:33, 26 sty 2017 (CET)[odpowiedz]
Super :) Trzeba gdzieś (nie mam pojęcia gdzie) magazynować takie tricki i skrypty koniecznie. Dla bota Załatwione Nedops (dyskusja) 22:07, 26 sty 2017 (CET)[odpowiedz]
Wikipedia:Narzędzia --Wargo (dyskusja) 22:18, 26 sty 2017 (CET)[odpowiedz]

Legenda pod mapą[edytuj | edytuj kod]

Na Commons jest taka mapa a pod nią legenda (w różnych językach). Można wstawić do artykułu mapę z którąś z legend ? IOIOI2 23:34, 28 sty 2017 (CET)[odpowiedz]

Zobacz sobie w Pendolino#Eksploatacja jak można w artykule zrobić legendę do ilustracji. Therud (dyskusja) 10:45, 29 sty 2017 (CET)[odpowiedz]
Jakby była w samej grafice (SVG to umożliwia) to można by było łatwo wstawić z wyborem języka. --Wargo (dyskusja) 11:31, 29 sty 2017 (CET)[odpowiedz]
Wielkie Wam dzięki ! Załatwione, IOIOI2 12:38, 29 sty 2017 (CET)[odpowiedz]

19:45, 30 sty 2017 (CET)

Załatwione ~malarz pl PISZ 20:09, 30 sty 2017 (CET)[odpowiedz]

Witam wszystkich, potrzebujemy pomocy. Henry39 ma w swoim brudnopisie hasło "Robert Cena", tu jest brudnopis Wikipedysta:Henry39/brudnopis, jednak gdy chce utworzyć hasło w przestrzeni głównej, otwiera okno edycji, wkleja skopiowany z brudnopisu tekst, chce go zapisać i...system mówi "Filtr nadużyć zidentyfikował Twoja edycję jako szkodliwą". Mnie się pomysły skończyły. Wie ktoś co z tym można zrobić?--Tokyotown8 (dyskusja) 21:16, 30 sty 2017 (CET)[odpowiedz]

od autora notki (Henry39) : Udało się ! Zrobiłem tak jak radził Thraen, czyli po kawałku. Infobox zostawiłem na koniec, bo miałem podejrzenia. Ale udało się. Bardzo prosze, abyscie Koledzy przejrzeli te notke (Robert Cena) i sprawdzili, czy rzeczywiscie istnieje :-) Dziekuję Henry39 (dyskusja) 21:38, 30 sty 2017 (CET)[odpowiedz]

Załatwione. ~malarz pl PISZ 23:08, 30 sty 2017 (CET)[odpowiedz]

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]

Gadżet CzyWiesz[edytuj | edytuj kod]

Gadżet do zgłaszania artykułów robi dziwne rzeczy. Przed chwilą [21] 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]

Nieindeksowanie stron w DNU[edytuj | edytuj kod]

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: [22]. Matma Rex dyskusja 21:50, 4 sty 2017 (CET)[odpowiedz]

Skrypt na dodatkowe przyciski opisu edycji kontra nowy edytor kodu źródłowego.[edytuj | edytuj kod]

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]

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:PetScan przydałby się nieco dokładniejszy opis, np. jak w wersji niemieckiej. Wiklol (Re:) 09:29, 6 sty 2017 (CET)[odpowiedz]

Potrzebna pomoc z css (i lua?)[edytuj | edytuj kod]

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ż

Jak nas Wikidane anglicyzują[edytuj | edytuj kod]

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]

Gadżet Zgłoś do usunięcia[edytuj | edytuj kod]

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]

Infobox dla kuchni[edytuj | edytuj kod]

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]

Wylogowywanie[edytuj | edytuj kod]

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]

Serwer na pliki[edytuj | edytuj kod]

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]

Fragmenty map[edytuj | edytuj kod]

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]

Czy ktoś może poprawić tę grafikę (albo ją usunąć)?[edytuj | edytuj kod]

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]

Automatyczne generowanie przypisów w VE[edytuj | edytuj kod]

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]

Tydzień Kolumbijski[edytuj | edytuj kod]

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[edytuj | edytuj kod]

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)

Zmiany ikon w szablonach w całej Wiki[edytuj | edytuj kod]

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]

Szablony {{Cite web}} itp.[edytuj | edytuj kod]

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]

30 września 2016; 4 miesiące temu[edytuj | edytuj kod]

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[edytuj | edytuj kod]

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]

Polska Rada Ekumeniczna, pomożecie?[edytuj | edytuj kod]

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]

Content Translation[edytuj | edytuj kod]

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]

Oznaczanie fragmentów dezaktualizujących się[edytuj | edytuj kod]

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]

Obrazki importowane via Wikidata[edytuj | edytuj kod]

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]

Spolszczenie nazw szablonów[edytuj | edytuj kod]

Taka drobnostka: swego czasu spolszczono nazwy niektórych szablonów, np. {{Ujednoznacznienie}} 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 {{Ujednoznacznienie}}, {{Ł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]

Przed powstaniem infoboksu książka dodawaliśmy link do książki na Wikiźródłach poprzez Szablon:Wikiźródła. Odkąd na stronach książek wstawiamy infobox, szablon Wikiźródła zaczęliśmy usuwać, więc link do tekstu danej książki został "zwinięty" jedynie do infoboksu. Niestety, w wersji mobilnej infobox jest domyślnie schowany, co oznacza, że przeciętny użytkownik po przeczytaniu całego artykułu (jeśli nie wpadnie na pomysł rozwinięcia informacji szczegółowych) nie ma możliwości dowiedzenia się, że cała książka została przepisana i jest w całości bezpłatnie dostępna w projekcie siostrzanym. Aby link do Wikiźródeł był widoczny, musimy albo zrezygnować ze wstawiania infoboxu (który do tej pory często wstawiałam, jak się okazuje, z uszczerbkiem dla Wikiźródeł), albo duplikować link poprzez użycie zarówno infoboxu, jak i szablonu... Podobnie zresztą jest na stronach autorów. Moim zdaniem jest to krok wstecz... Mam w związku z tym pytanie: czy możliwe jest wyłączenie domyślnego "zwijania się" tych infoboxów? Wieralee (dyskusja) 17:02, 28 sty 2017 (CET)[odpowiedz]

  • Mówisz zapewne o aplikacji mobilnej ? Nadal jest ona w wersji beta, pewnie gdzieś można zgłosić taka uwagę. A jeśli chodzi o mobilną wersję strony w przeglądarkach to u mnie infoboksy sa domyślnie rozwinięte. IOIOI2 17:24, 28 sty 2017 (CET)[odpowiedz]

Symbole pod oknem edycji[edytuj | edytuj kod]

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? 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]
Specjalna:Diff/48337156 – dlatego prośba o staranniejsze opisy zgłoszeń. Nie wiadomo, co na co nachodzi, czy (i jakie) pogrubienie trzeba całkiem usunąć albo zredukować wskutek wdrożenia proponowanego CSS, które znaki należy powiększyć (jest grupa o nazwie „Znaki i symbole”). W każdym razie chyba załatwione. Pozdrawiam, Peter Bowman (dyskusja) 16:08, 26 sty 2017 (CET)[odpowiedz]
Btw. wiesz czy da się zwiększyć odstęp między wierszami? Eurohunter (dyskusja) 14:32, 26 sty 2017 (CET)[odpowiedz]
Ustaw właściwość line-height. Wargo (dyskusja) 15:12, 26 sty 2017 (CET)[odpowiedz]
Da się określić wartość? Eurohunter (dyskusja) 17:53, 29 sty 2017 (CET)[odpowiedz]
Trzeba. --Wargo (dyskusja) 18:09, 29 sty 2017 (CET)[odpowiedz]
W jaki sposób? Przykład? Eurohunter (dyskusja) 18:12, 29 sty 2017 (CET)[odpowiedz]
line-height: 2em. Można też w pikselach. --Wargo (dyskusja) 18:29, 29 sty 2017 (CET)[odpowiedz]
Musiałem coś źle zrobić. Działa, dzięki. Eurohunter (dyskusja) 18:32, 29 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]
Ale czy font-weight: lighter; rozwiązało problem? Bo tam jest więcej możliwości (na przykład wartości 100,200 (normal to 400, bold to 700) do 900 o ile dobrze pamiętam. KamilK7 16:11, 26 sty 2017 (CET)[odpowiedz]
Tak, "font-weight: lighter;" rozwiązało problem. Eurohunter (dyskusja) 17:53, 29 sty 2017 (CET)[odpowiedz]

Alfabetyczne sortowanie przypisów[edytuj | edytuj kod]

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]
  • Przez jakiś czas sprawdzałem co jest w polu "autor" i ze względu na częste wpisywanie tam danych w kolejności 'imię nazwisko' sortowanie wg tego parametru odpada. Zdecydowanie pomysł Gżdacza jest najbardziej sensowny. Możliwość sortowania alfabetycznego musiałaby być włączana ({{Przypisy|sort}}) po uporządkowaniu (według nazwisk autorów) parametrów 'name' w odnośnikach. Możliwość sortowania alfabetycznego zwłaszcza w rozbudowanych artykułach przydała by się okrutnie (vide np. korzeń ze 148 przypisami). Kenraiz (dyskusja) 18:28, 29 sty 2017 (CET)[odpowiedz]
  • Pewnie masz rację, ale aktualny sposób (wedle kolejności pojawiania się odwołań w tekście) produkuje mniej-więcej losową listę. Więc nawet jak ktoś da zły znacznik i lista przestanie się sortować alfabetycznie, nie będzie dużo gorzej niż teraz. A czasem będzie dużo lepiej. Czyli jest sporo do wygrania i niewiele do przegrania. Gżdacz (dyskusja) 19:32, 29 sty 2017 (CET)[odpowiedz]
  • Ja mam tylko jeden warunek: obecne standardowe sortowanie powinno pozostać jako domyślne. Ewentualne inne sortowanie powinno być jedynie dodatkową możliwością, do włączenia w preferencjach lub za pomocą przełącznika w artykule. Michał Sobkowski dyskusja 13:00, 30 sty 2017 (CET)[odpowiedz]
  • Popsute sortowanie łatwo byłoby naprawić albo wyłączyć. Artykuły z b. licznymi refami są na ogół sporadycznie edytowane, w każdym razie moich wyróżnionych i obserwowanych w ciągu kilku dobrych lat nikt nie ruszył, jeśli dobrze pamiętam... Kenraiz (dyskusja) 20:59, 29 sty 2017 (CET)[odpowiedz]
    • @Kenraiz Tak na prawdę naprawdę, to powinno być wszędzie imię i nazwisko (aby wyświetlało się tak samo, jak w przypatku podania nazwisko= i imię=), jednak w dokumentacji szablonów błędnie (moim zdaniem) dano przykłady cytowania typu Ferreira KN. i efekt jest, jaki jest, jedni robią wg przykładu w dokumentacji, a inni na intuicję tak, jak być powinno. W każdym razie, jeśliby zaprowadzić tu porządek, to kolejność Imiona i nazwisko w niczym by nie przeszkadzała, sortowałoby się według ostatniego słowa w polu autor (jeśli ostatnie 2 słowa miałyby tworzyć nazwisko, to wstawiałoby się pomiędzy nie spację nierozdzielającą). KamilK7 13:04, 30 sty 2017 (CET)[odpowiedz]
      • Może i tak, ale rzeczywistość jest inna i nie widać sposobu na zmianę tego stanu rzeczy. W dodatku to nie takie proste, bo oprócz książek cytujemy wszelkiego rodzaju dzieła anonimowe, strony internetowe bez jasno wskazanego autora, bazy danych, spisy urzędowe, statystyki, mapy, itp. System sortowania automatycznego musiałby być zbudowany w oparciu o ekstremalnie rozbuchane szablony cytowania, w kórych zawsze dałoby się jednoznacznie określić, po którym polu sortujemy. A i tak zawsze by się pojawiły jakieś wyjątki. To najprościej uznać, że klucz sortowania jest poza szablonem, w polu tagu "ref" i autor artu sam na swój rozum wybiera, co tam wpisać. Jest to nieporównanie mniej upierdliwe, a tę nazwę i tak trzeba tam podać. Dostaniesz 80% funkcjonalności za cenę 20% wysiłku i kosztów. Gżdacz (dyskusja) 13:24, 30 sty 2017 (CET)[odpowiedz]
        • Problem polega na tym, że rzeczywistość jest taka, jaka jest również w zakresie sortowania "ręcznego" i naprawienie tego stanu rzeczy, to chyba więcej pracy. Jeśli wprowadzimy przycisk do sortowania, to powiedzmy ty poprawisz kilka artykułów wstecz, ja też pewnie kilka, w nowych będziemy stosować (w jakiejś części, nowi edytorzy raczej nie), a wszelkie stoliki typu "Zgłoś błąd" zarzucone zostaną zgłoszeniami, że komuś przycisk sortuj dziwnie działa. Brak czegokolwiek w polu autor i w polach imię / nazwisko akurat łatwo rozwiązać np. dając takie artykuły na końcu. Być może dobrym rozwiązaniem byłoby dodanie do szablonu parametru posortowane (brak parametru, stara się sortować wg pół, a dodany parametr oznaczałby, że zostało posortowane ręcznie). KamilK7 14:08, 30 sty 2017 (CET)[odpowiedz]

Interwiki[edytuj | edytuj kod]

Czy da się wprowadzić wyświetlanie się interwników podczas edycji? Wyświetlają się po naciśnięciu przycisku "Nowy wątek" lub podczas podglądu edycji, ale nie bezpośrednio podczas edycji. Eurohunter (dyskusja) 18:34, 29 sty 2017 (CET)[odpowiedz]

DOI w 'cytuj stronę' i 'cytuj'[edytuj | edytuj kod]

Czy mógłbym prosić o dwie rzeczy:

  • aby {{cytuj stronę}} obsługiwał parametr doi – niektóre strony internetowe również korzystają z DOI, a dzięki podaniu go, można uniknąć ewentualnego wygaśnięcia linku;
  • aby {{cytuj}} nie rozumował DOI = czasopismo.

Próbowałem wstawić DOI przy cytowaniu strony. W pierwszym szablonie się nie da, w drugim wychodzi tak, jakby cytowane było czasopismo – i tak źle, i tak niedobrze. Wostr (dyskusja) 17:12, 30 sty 2017 (CET)[odpowiedz]

Dodatkowe przyciski opisu edycji[edytuj | edytuj kod]

Dodatkowe przyciski opisu edycji ładują się z opóźnieniem. Jest na to jakieś rozwiązanie? Eurohunter (dyskusja) 21:00, 31 sty 2017 (CET)[odpowiedz]

Pusta przestrzeń w edytorze[edytuj | edytuj kod]

Czy da się zniwelować pustą przestrzeń pomiędzy ramką opisu edycji, a dodatkowymi przyciskami opisu edycji i między dodatkowymi przyciskami opisu edycji, a przyciskani "Zapisz zmiany", "Pokaż podgląd" i "Podgląd zmian"? Eurohunter (dyskusja) 21:00, 31 sty 2017 (CET)[odpowiedz]

Znaki i symbole[edytuj | edytuj kod]

Czy da się usuwać i dodawać elementy z ramki zawierającej symbole i znaki z edytora? Eurohunter (dyskusja) 21:14, 31 sty 2017 (CET)[odpowiedz]