Wikisłownik:Bar/Dyskusje techniczne

Bar

Stolik techniczny

Przy stoliku technicznym dyskutujemy nad kwestiami technicznymi związanymi z MediaWiki, botami, skryptami i szablonami. Miłych i owocnych dyskusji!

Nowy wątek • Obserwuj stolik • Archiwum

Lista archiwalnych wątków znajduje się tutaj.

Liczniki oraz przekroczenie liczby kosztownych wywołań

Moduł:statystyka nie potrafi obsługiwać więcej niż 500 pozycji na liście Moduł:statystyka/dane z powodu ograniczeń MediaWiki. Tymczasowo zmieniłem kod tak, aby uzyskać niepełny wynik zamiast komunikatu błędu: Specjalna:Diff/6251358. Na chwilę obecną szablony typu {{licznik}} nie pokrywają pełnej listy języków w Wikisłowniku (czyli np. liczniki na stronie głównej oraz na OZ nie będą wskazywały dokładnej liczby haseł); tym samym na WS:STAT zobaczymy więcej zer, niż powinno. Peter Bowman (dyskusja) 14:27, 28 sie 2018 (CEST)

@Peter Bowman A czy byłoby możliwe, żeby Twój bot zapisywał codziennie do jakiejś tablicy w Lua liczbę stron w kategoriach indeksów językowych i wtedy zastąpilibyśmy kosztowne wywoływanie pagesInCategory odczytem z tabeli? Albo w podziale na te mniejsze języki (z tablicy) i języki ze strony głównej (z pagesInCategory). KaMan (dyskusja) 18:32, 1 wrz 2018 (CEST)

Musiałem obniżyć granicę do 495, aby np. licznik eków na OZ mógł nadal działać. Przychodzą mi do głowy trzy opcje:

1. Liczniki opierają się na liście niezautomatyzowanej, okresowo aktualizowanej przez bota. Będą zatem zawsze podawały nieaktualną wartość.
2. Liczniki opierają się na liście półautomatyzowanej, czyli sumują rozmiar rzeczywisty większości indeksów oraz okresowo sprawdzany przez bota rozmiar indeksów odpowiadających rzadko edytowanym językom (mamy takie, które liczą po zero haseł). Tracimy na precyzji, ale znacznie mniej niż w pierwszym przypadku.
3. Liczniki zaokrąglają wyświetlaną wartość, np. „720 200+ haseł”. Nie wiem jednak, jak to sensownie odzwierciedlić w głównej tabelce na stronie WS:STAT.

Większe projekty, np. enwiktionary albo frwiktionary, stosują słowo magiczne NUMBEROFARTICLES, jednak daje to liczbę stron zamiast haseł. Peter Bowman (dyskusja) 01:12, 3 wrz 2018 (CEST)

Może strona na toolserverze prezentująca zliczenia wprost z bazy danych? --Wargo (dyskusja) 12:21, 5 wrz 2018 (CEST)

Można by tak zrobić dla liczników z dodatkiem gadżetu, który pobierałby aktualne dane z serwera i prezentował je np. na stronie głównej. Problem w tym, że każde odwiedziny strony to jedno zapytanie, a na prezentację wyniku trzeba by czekać. Inna opcja to wyświetlanie wartości przybliżonej (odświeżanej okresowo przez bota), a czytelnik otrzymywałby aktualne dane po kliknięciu na przycisk (pobierając licznik z serwera za pośrednictwem owego gadżetu). Co do WS:STAT – musielibyśmy zrezygnować z tej strony i przekierowywać czytelników do serwera. Peter Bowman (dyskusja) 13:39, 5 wrz 2018 (CEST)

Automatyczne opisy zmian

Na Wikipedii mają fajne przyciski pod polem edycji, które dodają automatycznie opisy zmian. My nie mamy - może czas to zmienić? Czy nie ułatwiłoby to Wam edytowania? W Wikipedii gadżet ten (domyślnie włączony dla wszystkich, w tym niezalogowanych) jest tutaj. Oczywiście nie wszystkie przyciski znajdują u nas zastosowania, więc trzeba je dostosować do naszej specyfiki. Moje propozycje są następujące (po lewej opis przycisku, po prawej treść wpisywana w opis edycji):

• dr. red. → drobne redakcyjne
• dr. meryt. → drobne merytoryczne
• dr. tech. → drobne techniczne
• lit. → literówka
• linkfix → poprawa linków
• szablon → szablon
• ilustr. → ilustracja
• przypisy → źródła/przypisy
• sekcja → nowa sekcja językowa
• rew. → przywrócenie poprzedniej wersji
• głos → głos
• komentarz → komentarz
• pytanie → pytanie
• odp. → odpowiedź

Przyznam, że wpisywanie ręczne tych rzeczy jest uciążliwe przy intensywniejszym edytowaniu, dlatego zazwyczaj mi się nie chce nic wpisywać w opis zmian poza + :). Nostrix (dyskusja) 12:56, 15 lis 2018 (CET)

Popieram. Ponadto dodałbym oddzielny przycisk dla każdej sekcji (wymowa, znaczenia, odmiana itd.). PiotrekD^DYSKUSJA 22:14, 17 lis 2018 (CET)

• Skopiowałem póki co skrypt do swojej przestrzeni: tutaj. Niestety działa tylko połowicznie, mianowicie zamiast ładnych przycisków (w postaci tekstu umieszczonego w ramce z zielonym tłem) pojawia się sam tekst (w dodatku bez spacji między kolejnymi "przyciskami"). Czy ktoś ma pomysł co jest nie tak? Wygląda to jak jakiś błąd w CSSie... Nostrix (dyskusja) 22:55, 20 mar 2019 (CET)
  • @Nostrix: w Wikipedii ładują CSS z Common.css, u nas są (ładnie) porozmieszczane w osobnych modułach. Czy po tej zmianie się poprawiło? Peter Bowman (dyskusja) 23:29, 20 mar 2019 (CET)
    • @Peter Bowman - działa! Bardzo dziękuję :). Dokonałem zmiany w samym skrypcie, aby przyciski miały treść związaną z naszym projektem. Chciałbym je teraz trochę potestować (zachęcam do dołączenia) i później włączyć dla wszystkich edytorów (oczywiście będzie potrzebny admin). O ile nie będzie sprzeciwów. Nostrix (dyskusja) 08:38, 21 mar 2019 (CET)

@Nostrix, @Sankoff64: zaimportowałem i przejrzałem MediaWiki:Gadget-edit-summaries.js, dostępny jest jako gadżet – ostatni w sekcji „Edycja stron”. Domyślnie ładuje listę przycisków z wersji Nostriksa – czy tak jest w porządku? Dodatkowe przyciski konfigurujemy na Specjalna:Moja strona/common.js:

mw.loader.using( 'ext.gadget.edit-summaries' ).done( function ( require ) {
	require( 'ext.gadget.edit-summaries' ).addButton( 'skrót', 'dłuższy opis', 'komentarz w polu "Opis zmian"' );
    //require( 'ext.gadget.edit-summaries' ).addButton( ... );
} );

Trzeci parametr można pominąć, jeżeli tekst do dodania w opisie zmian jest też skrótem do wyświetlenia w opisie. Alternatywnie można tu podać funkcję – wywołanie zwrotne, które przyjmuje jako jedyny parametr element jQuery zawierający w sobie wszystkie przyciski. Czwarty parametr, niewymagany, to klasa CSS. Powinno działać w Edytorze Wizualnym. Peter Bowman (dyskusja) 18:29, 15 sie 2019 (CEST)

• Dodanie własnych przycisków wydłuża linijkę z przyciskami, która za nic nie chce się zawijać i wyświetla się w jednym rządku, więc niektóre przyciski z końca tej linijki wychodzą poza ekran. Maitake (dyskusja) 11:27, 9 lis 2019 (CET)

  @Maitake: powinna się już zawijać, dzięki. Peter Bowman (dyskusja) 01:08, 16 lis 2019 (CET)

Pytanie o {{przykłady}}

Dlaczego właściwie pod polem {{przykłady}} MUSI być puste : (1.1)? Nostrix (dyskusja) 22:42, 5 lut 2019 (CET)

Gdzie tak jest napisane? --Wargo (dyskusja) 14:55, 7 lut 2019 (CET)

link. Gdzieś też czytałem jeszcze, że TRZEBA tak robić, ale nie mogę sobie przypomnieć gdzie to było. @Olaf? Nostrix (dyskusja) 15:02, 7 lut 2019 (CET)

@Nostrix: zob. WS:Bar/Archiwum 15#: (1.1) w przykładach oraz WS:Bar/Archiwum 18#(1.1) w przykładach. Peter Bowman (dyskusja) 15:50, 7 lut 2019 (CET)

@Peter Bowman Dzięki za linki. Ta pierwsza dyskusja mnie zdumiała, bo padają w niej argumenty przeciw takiemu rozwiązaniu, wszyscy są właściwie zgodni co do tego, że dodawanie (1.1) na siłę nic nie daje, ale jednak zapada decyzja, że bot to będzie wszędzie dodawał. Ja zapytałem o to dlatego, że bardzo trudno sensownie uargumentować nowicjuszowi dlaczego i po co ma to wstawiać właśnie w tym miejscu (okej, bot to zrobi za niego, ale jednak chcemy, żeby każdy edytował zgodnie z zasadami, zaleceniami i zwyczajami, bez pomocy innych osób, nawet botów), poza tym to kolejna rzecz, którą musi taki nowicjusz zapamiętać, a im więcej zawiłości tego rodzaju, tym łatwiej o zniechęcenie... Nostrix (dyskusja) 19:04, 7 lut 2019 (CET)

@Nostrix Jedyny problem, to to, że jakakolwiek zmiana we wszystkich 750000 artykułów, to jakieś dwa miesiące ciągłej pracy bota, ale da się to zrobić. Może jednak załóż jakieś głosowanie, bo niektórzy zapewne się bardzo przyzwyczaili, a niekoniecznie czytają dyskusje techniczne. Ja będę za, jeśli przejdzie, to przestawię bota na usuwanie. Przy okazji można by się zastanowić nad ewentualnymi innymi zmianami (jakieś nowe pola?), skoro już mamy wszystkie strony zmieniać. Olaf (dyskusja) 22:52, 11 lut 2019 (CET)

@Olaf Zamiast uruchamiać bota we wszystkich hasłach, co z oczywistych względów nie jest wskazane, wystarczyłoby, że: 1) bot mógłby przestać dodawać tę linijkę, 2) bot mógłby - ale tylko przy okazji innych edycji - usuwać tę pustą linijkę. A zamiast głosowania może wystarczyłoby zwrócić uwagę na tę dyskusję na tablicy ogłoszeń i w obserwowanych? No i dać odpowiednio dużo czasu na wyrażenie swojego zdania. Wydaje mi się jednak, że jeśli po długim czasie i odpowiednim nagłośnieniu mojej propozycji nie będzie głosów sprzeciwu, to zmianę należy wprowadzić w życie, bo najwyraźniej dla innych nie jest ta kwestia aż tak istotna, aby zabierać głos :). Nostrix (dyskusja) 21:49, 12 lut 2019 (CET)

Wskazane to w sumie jest. Bot stara się na bieżąco przeglądać ostatnie zmiany, ale na skutek rozmaitych awarii kilka razy w historii zdarzyło się, że jakiegoś dnia nie przejrzał. Czasem też nowe zmiany w algorytmie nie obejmują istniejących artykułów, bo trudno określić które artykuły bot powinien przejrzeć. Więc raz na jakiś czas przejrzenie wszystkich artykułów jak najbardziej jest wskazane. Tylko żmudne. Zostawienie możliwości zarówno wstawiania (1.1) jak i niewstawiania spowoduje, że te (1.1) w przykładach będą pokutować jeszcze przez dziesięciolecia, a nowi edytorzy będą zaskoczeni rozbieżnością zasad i praktyki. Więc ja bym jednak spróbował z wolna pozmieniać wszystkie artykuły. Na początek jednak oczywiście tak to trzeba będzie zrobić, jak piszesz. Olaf (dyskusja) 01:55, 19 lut 2019 (CET)

@Olaf: „Przy okazji można by się zastanowić nad ewentualnymi innymi zmianami (jakieś nowe pola?), skoro już mamy wszystkie strony zmieniać”. O propozycjach zmian we wszystkich stronach nie słyszałem, ale w tych z ręcznie uzupełnianymi – Oboczności w dopełniaczu liczby mnogiej i nie tylko. Moja własna, od miesięcy planuję zrobić głosowanie (z opcjami do wyboru, nie proste za/przeciw) i jakoś ciągle nie zrobiłem, jak to zwykle z moimi tutejszymi planami. To tak na boku. (Głosowania u nas to w ogóle ciekawy temat, to o nazwiskach jest w planach od ponad dwu lat). PiotrekD^DYSKUSJA 20:40, 13 lut 2019 (CET)

Również nie rozumiem sensu obowiązkowości tego fragmentu kodu i jestem za usuwaniem go, gdy nie ma żadnego przykładu, a na pewno za zaprzestaniem dodawania go. PiotrekD^DYSKUSJA 20:40, 13 lut 2019 (CET)

A nie można tego po prostu tego zostawić, żeby przy dodawaniu hasła nie musieć ponownie wpisywać, ale po prostu ukryć, by było niewidoczne dopóki nieuzupełnione? Krokus (dyskusja) 20:41, 14 lut 2019 (CET)

Domyślnie jest niewidoczne, chyba że wyłączyłaś gadżet do ukrywania niewypełnionych pól. Peter Bowman (dyskusja) 22:34, 14 lut 2019 (CET)

Ok, skoro domyślnie jest to ukryte (@Peter Bowman, dzięki za info), to nie widzę większego problemu. Docelowo i tak trzeba uzupełnić przykłady. Czy bot będzie w wersji niekompletnej (tj. bez przykładu) na dzień dobry usuwał, czy dodawał (1.1), to kwestia bez większego znaczenia, chyba, że istnieją jakieś statystki lub logiczne przesłanki, że poprawek bota usuwającego (1.1) będzie znacznie mniej, niż tego dotychczasowego uzupełniającego (1.1). Pozdrawiam Krokus (dyskusja) 10:20, 14 mar 2019 (CET)

• Chyba możemy uznać, że propozycja tej drobnej zmiany uzyskała zgodę społeczności drogą konsensusu :). Mam w takim razie prośbę o wprowadzenie jej w życie. @Olaf, czy możemy na początek wyłączyć automatyczne dodawanie (1.1) do przykładów? Co do reszty, to nie wiem jak postąpić, czy lepiej podłączyć usuwanie (1.1) z kodu przy okazji innych edycji bota, czy przebotować cały Wikisłownik. Osobiście skłaniam się do tej pierwszej wersji. Nostrix (dyskusja) 22:28, 20 mar 2019 (CET)
• Wydaje mi się, że w sprawach "dużej wagi", o zmianach powinno decydować głosowanie, a nie "konsensus" jakiejś dyskusji. Zetzecik (dyskusja) 08:39, 21 mar 2019 (CET)
  • To jest według Ciebie sprawa dużej wagi? Nostrix (dyskusja) 09:43, 21 mar 2019 (CET)
• Wprowadziłem zmiany w formularzu edycji ToStera (Specjalna:Diff/6434521, Specjalna:Diff/6434520) oraz SK (Specjalna:Diff/6434526), te gadżety będą teraz automatycznie usuwać pustą linię „(1.1)” w przykładach. Peter Bowman (dyskusja) 15:37, 2 cze 2019 (CEST)
• Po trzech miesiącach harówki bot skończył przerabiać hasła. Samotne (1.1) w przykładach nie powinno już występować. Olaf (dyskusja) 12:29, 5 wrz 2019 (CEST)

Znaczniki: Z internetu mobilnego, Z wersji mobilnej www

Moi drodzy,

Zdarza mi się edytować czasami na tablecie. Napotkałem jednak (przynajmniej) dwa problemy. Pierwszym jest niemożliwość utworzenia nowej strony poprzez skopiowanie szablonu. Gdy chcę utworzyć nowe słowo na krótko pojawia mi się żółty (a może zielony) kod który mogę skopiować i na jego podstawie pracować dalej. Ale pojawia się on naprawdę na krótką chwilę. Może jedną, może dwie sekundy. W tym czasie oczywiście nie mogę go skopiować. Drugi problem polega na braku strzałki (ani innych znaków specjalnych i niespecjalnych). Czy może temu jakoś zaradzić?

Zwiadowca21 ²¹ 19:09, 1 mar 2019 (CET)

@Zwiadowca21 Ja również edytuję na tablecie ale nie mam takich problemów. Wystarczy zjechać na dowolnej stronie na sam dół i przełączyć się jednym kliknięciem na tryb desktopowy. On lepiej pasuje do tabletów moim zdaniem. KaMan (dyskusja) 12:33, 2 mar 2019 (CET)

To nie jest usunięcie problemu, tylko ominięcie. Zwiadowca21 ²¹ 10:36, 4 mar 2019 (CET)

bot dodający pliki z wymową w hasłach koreańskich

Witam, czy ktoś mógłby napisać bota, który w naszym słowniku do istniejących haseł koreańskich dodawałby pliki audio z wymową, jeżeli takowe zamieszczone zostały w koreańskiej wersji danego hasła lub na Commons (chociaż tam nie mam zielonego pojęcia jak je odnaleźć, bo w kategorii Korean pronunciation [1]) w przeciwieństwie do Polish pronunciation [2] nie ma plików z wymową? Robię to ręcznie, a wydaje mi się, że to zadanie bardziej dla bota. Mamy już bota uzupełniającego nagrania z wymową dla innych języków. Może nie byłoby skomplikowane i czasochłonne rozszerzenie jego funkcji o nagrania z wymową haseł koreańskich. Może wiąże się to z dopisaniem tyko kolejnej zależności. W ręcznym wydaniu wystarczy tylko w koreańskiej wersji w pliku audio zastąpić jego początek zaczynający się od 발음 듣기 słowem audio, by to na naszych stronach funkcjonowało. Pozdrawiam Krokus (dyskusja) 10:57, 14 mar 2019 (CET)

Niemal wszystkie pliki z koreańską wymową znajdują się w podkategorii c:Category:South Korean pronunciation i nie ma ich zbyt wiele (238 plików). Kod beau.bota, który uruchamiam co tydzień, przegląda podkategorie, więc powinien móc wyłówić te pliki bez problemu, jednak nie sądzę, by potrafił rozróżnić akcent północny (na razie brak plików) od południowego – dałoby się, gdyby tę okoliczność zaznaczano w nazwie pliku (vide angielski brytyjski/amerykański/australijski/itd.: En-uk-..., En-us-... itd.). Pozostałbym przy ręcznym uzupełnianiu. Pozdrawiam, Peter Bowman (dyskusja) 11:51, 15 mar 2019 (CET)

Olafbot uzupełnił to kilka dni temu (przykład) i będzie dodawał wymowę do haseł także w przyszłości, gdyby pojawiły się nowe hasła lub nowa wymowa na Commons. Olaf (dyskusja) 22:03, 27 gru 2020 (CET)

Linki w polach

Dlaczego w strukturze hasła akurat słowa kolokacje i odmiana są linkami wewnętrznymi (odsyłającym do zasad projektu)? Skąd takie wyróżnienie tych pól? (Zadałem to pytanie kiedyś na stronach dyskusji szablonów {{kolokacje}} i {{odmiana}}, ale chyba przeszło niezauważone). Czy moglibyśmy usunąć te linki - lub wszystkie pola linkować do stron zasad (ewentualnie w przypadku np. holonimów linkować do haseł wyjaśniających te terminy, bo jakieś 90% czytelników nie wie co to znaczy ;). Nostrix (dyskusja) 12:08, 3 kwi 2019 (CEST)

Pewnie jest tak dlatego, że kolokacje były od początku projektu, natomiast hiperonimy, hiponimy, holonimy i meronimy zostały wprowadzone do szablonu hasła chyba w roku 2013. I wówczas nikomu nie przyszło do głowy tworzyć jakieś linki. Podoba mi się pomysł, żeby pozostałe pola także linkować do zasad. Może też warto byłoby zmienić nazwę „kolokacje” - termin mocno specjalistyczny - na „połączenia” lub „najczęstsze połączenia”. Tak jest np. w WSJP. Pozdrawiam. Sankoff64 (dyskusja) 12:56, 3 kwi 2019 (CEST)

Zmiana nazewnictwa jednego z pól to bardzo duża rzecz ;). Oczywiście można ją dokonać w samym szablonie, ale potem szablon ten wyświetla w każdym haśle inną nazwę, niż jest już w kodzie i nowicjusze mogą czuć się skonfundowani. A botowanie tylu stron... Osobiście nie widzę powodu. Natomiast utworzenie kolejnych linków lub usunięcie tych dwóch nie wiąże się z żadnym masowym działaniem, wystarczy dodać/usunąć odpowiedni parametr w kodzie. Nostrix (dyskusja) 13:10, 3 kwi 2019 (CEST)

Oprócz samego linku można również wyświetlić dymek wyjaśniający przeznaczenie danego pola, najechawszy kursorem na jego tytuł (WS:Bar/Dyskusje ogólne#Hiperonimy i hiponimy oraz femininum. (permalink)). Zauważam, że obecne linki prowadzą do odpowiedniej sekcji na WS:ZTH, strony przeznaczonej dla edytorów (nie dla czytelników). Pozdrawiam, Peter Bowman (dyskusja) 17:37, 5 kwi 2019 (CEST)

Ja bym to widział tak:

wymowa:
znaczenia:
odmiana:
przykłady:
w składnia:
kolokacje:
synonimy:
antonimy:
hiperonimy:
hiponimy:
holonimy:
meronimy:
pokrewne:
związki frazeologiczne:
etymologia:
uwagi:
tłumaczenia:
źródła:
Dymki są świetnym pomysłem, chociaż chyba będą działać tylko w desktopowej przeglądarce. Nostrix (dyskusja) 11:34, 9 kwi 2019 (CEST)

co wyjaśnia link do wymowa czy odmiana chyba nic, linki powinny zostać usunięte w zamian za to może być jedna strona gdzie będą wszystkie słowa wyjaśnione i do tej jednej strony można zalinkować.

To jest dobry pomysł - albo linkujemy wszystko, albo nic ;). Stronę mogę założyć, ale to będzie dalej metastrona Wikisłownika, czyli najpierw czytelnik kliknie w powiedzmy holonimy, następnie przejdzie na metastronę, z której z powrotem przejdzie do hasła w przestrzeni głównej? Nostrix (dyskusja) 17:51, 9 kwi 2019 (CEST)

<references />

Czy jakiś bot mógłby przelecieć wszystkie hasła i dodać <references /> na koniec każdej sekcji językowej? Grzegorz Wysocki (dyskusja) 14:40, 9 sie 2019 (CEST)

Znacznik <references/> niegenerujący listy przypisów zostawia pustą linię na końcu hasła. Lata temu @Olaf próbował umieścić go wewnątrz szablonu z negatywnym rezultatem: Specjalna:Diff/1486838. Peter Bowman (dyskusja) 18:11, 9 sie 2019 (CEST)

1. A może tak zadziała: Wikisłownikarz:Grzegorz Wysocki/test ?
2. Czy można wstawić <references /> jako pseudoelement CSS :after dla całej sekcji? Może to rozwiąże problem.
3. Moim zdaniem pusta linia niczemu nie przeszkadza, zwłaszcza że jest węższa od normalnej.

Grzegorz Wysocki (dyskusja) 10:50, 10 sie 2019 (CEST)

Rozwiązania nr 1 nie znałem i wygląda obiecująco – trzeba jednak sprawdzić, czy cache MW nadal stwarza problem w wyświetlaniu przypisów (zob. opis edycji Olafa). 2. odpada, tym sposobem można najwyżej wyświetlić tekst <references />; parsowanie znacznika i generowanie listy wykonywane są znacznie wcześniej. Chciałbym, by 3. dało się ominąć dzięki CSS, ale ta technologia jeszcze nie istnieje (ref). Zauważ, że odstępu nie ma, gdy pod polem źródeł są przypisy. Najwyżej mogę nauczyć MediaWiki:Gadget-hide-empty-fields.js, aby ukrywał pole wraz z odstępem, ale sprawdźmy najpierw punkt 1. Peter Bowman (dyskusja) 11:41, 10 sie 2019 (CEST)

Sprawdziłem - niestety tak nie działa, references w tym miejscu w ogóle nie jest rozwijane i w efekcie wszystkie refy lądują na końcu artykułu: Wikisłownikarz:Olaf/testref2. Aczkolwiek Olafbot na bieżąco dodaje references każdej nocy tam gdzie tego brakowało, więc nawet jeśli ktoś zapomni, to taka wersja powinna być widoczna tylko przez jedeń dzień. Olaf (dyskusja) 11:54, 10 sie 2019 (CEST)

Myślę, że bot powinien też uwzględniać dodawanie <references /> także przy obecności {{nazwa systematyczna}} ---> diablo de Tasmania. Zan-mir (dyskusja) 09:09, 18 sie 2019 (CEST)

O, nie zauważyłem. Dorobię oczywiście. Olaf (dyskusja) 12:46, 5 wrz 2019 (CEST)

Dyskusja umarła, więc ją odkopię. @Grzegorz Wysocki, @Olaf, @Peter Bowman, @Zan-mir: A może by tak właśnie wstawić owo <references /> do {{przypisy}} i ukrywać gadżetem odstęp pod pustym polem, o czym wspomniał Peter? Dla uproszczenia kodu haseł, który i tak bywa już mocno skomplikowany. Tutaj dodatkowo znacznik ma angielską nazwę, więc osoba nieznająca angielskiego tym bardziej może mieć problem ze zrozumieniem, o co chodzi, wszak wyżej widzi już {{przypisy}}. PiotrekD^DYSKUSJA 23:55, 24 wrz 2019 (CEST)

Nie da się wstawić references do szablonu. Nie działa wtedy poprawnie. Próbował to wstawić do {{źródła}} najpierw Joystick 11 lat temu, potem ja 9 lat temu, sprawdziłem ponownie miesiąc temu (wyżej w tej dyskusji) i nadal nie działa. Olaf (dyskusja) 00:33, 25 wrz 2019 (CEST)

Moja pomyłka, chodziło mi oczywiście o {{źródła}}, nie {{przypisy}}. PiotrekD^DYSKUSJA 13:54, 25 wrz 2019 (CEST)

Za mw:Help:Cite#The <references /> tag:

If a page includes more than one <references /> list, each list includes the <ref> tags defined after the previous references list. If these references lists are produced by templates, each one lists the ref tags defined before the first references list, and there is an error message saying that there is a ref tag but not a references list.

Peter Bowman (dyskusja) 21:57, 24 lut 2020 (CET)

WS:Statystyka

Tabelka główna jest za szeroka. Nie wiem czy u Was też, ale u mnie skutkuje to pojawieniem się poziomego paska przewijania. Zrzut ekranu, na którym widać, jak tabelka wchodzi na szare pole. Zan-mir (dyskusja) 13:17, 22 wrz 2019 (CEST)

@Zan-mir: ustawiłem szerokość tabelki tak, by nie przekraczała szerokości strony: Specjalna:Diff/7112088. Peter Bowman (dyskusja) 16:31, 22 wrz 2019 (CEST)

Teraz zauważyłem, że tabelka w sekcji "Multimedia i źródła" ma ten sam problem. Zan-mir (dyskusja) 16:48, 22 wrz 2019 (CEST)

Ustawiłem poziomy pasek przewijania (Specjalna:Diff/7118254, WS:STAT#Multimedia i źródła). @Zan-mir: czy teraz jest lepiej? Peter Bowman (dyskusja) 03:40, 29 wrz 2019 (CEST)

Wymowa

Odkryłem narzędzie LinguaLibre do nagrywania słów za pomocą komputera z przeglądarką (bez specjalnych narzędzi czy aplikacji) i wysyłania od razu plików na Commons (nazwy plików są tworzone automatycznie) - wpadliśmy na Źródłosłowie na taki pomysł, a okazało się, że już go ktoś zrealizował i to dość dawno temu ;) (ping @Krokus). Widzę też na Commons, że @KaMan nagrał parę tysięcy słów, jednakże wymowa ta nie została automatycznie dodana przez bota do haseł. Zatem dwie prośby:

• Czy bot mógłby automatycznie, np. raz w tygodniu, dodawać wymowę do haseł z kategorii commons:Category:Lingua Libre pronunciation-pol;
• Czy mogę prosić o wygenerowanie listy brakujących nagrań wymowy w polskich hasłach w takiej postaci: #słowo1 #słowo2 #słowo3 #słowo4, ze względu na specyfikę LinguaLibre (vide Record Wizard i dodawanie dużej listy słów).

Będę zobowiązany! Nostrix (dyskusja) 22:51, 24 paź 2019 (CEST)

Nagrałam na próbę kilka wyrazów z pierwszej listy polskich słów, jaką można ww. narzędziu załadować. Dodałam na próbę w czasowniku być wymowę formy był. Pliki, które generuje to narzędzie, trochę inaczej wyglądają (mają rozszerzenie .wav a nie .ogg) i chyba Wikisłownikowe boty dodające wymowę ich nie znajdują. Poza tym nie mogłam zamieścić tych nagrań w kategorii: Polish pronunciation [3] - wyskakiwał jakiś błąd. Samo narzędzie fajne i łatwe w obsłudze :) dlatego może warto na naszej stronie głównej w sekcji: "Praca nad Wikisłownikiem" umieścić hasło typu nagraj hasło dla Wikisłownika i odsyłać do tego narzędzia (jak już będzie wiadomo na ile "nasze boty od wymowy" będą w stanie sprawnie wyszukiwać nagrania tworzone przy pomocy tego narzędzia. Jeżeli chodzi o dodawanie nagrań wymowy, to chyba musimy zastanowić się gdzie zamieszczać nagrania form fleksyjnych. Mi się wydaje, że sensowne jest dodawanie ich w tabelach odmiany, a nie w polu wymowa, w którym to zostawiłabym jedynie nagranie formy zgodnej z nagłówkiem hasła. wszystkie inne formy przeniosłabym do tabel odmiany. Krokus (dyskusja) 12:08, 25 paź 2019 (CEST)

A czy nie da się zrobić, żeby te nagrania miały na Commons standardowy format nazwy, tzn. File:Pl-aktynowy.ogg zamiast File:LL-Q809 (pol)-KaMan-aktynowy.wav i znajdowały się w kategorii Category:Polish pronunciation a nie jej podkategorii? Takie reguły obowiązują we wszystkich językach na commons, dzięki czemu wiele botów się na tym opiera, nagrywający wymowę i admini pracowicie wychowują użytkowników, żeby się tego trzymali, a tu nagle robimy wyłom... W ostateczności można na Commons poprosić o przeniesienie hurtem, tylko nie jestem pewien, jak będzie z formatem (wav zamiast ogg), ale grunt żeby nazwa i kategoria się zgadzały. Bo nawet jak u nas przestawimy bota, to zdaje się są i boty na innych wikisłownikach, które tego korzystają. Olaf (dyskusja) 23:51, 25 paź 2019 (CEST)

@Olaf Ile razy próbuję na ww. urządzeniu ustawić kategorię Polish pronunciation to wyskakuje mi komunikat: "invalidcategory". Ww. urządzeniu do nagrywania nie ma możliwości usunięcia nazwy nagrywającego (Name to display) - jest to nieaktywne okno wypełniane na podstawie wybranej nazwy w polu: "Speaker profile to use", w którym to można jedynie podać inną nazwę, bo w przypadku zostawienia pustego okienka wyświetla się komunikat: "You must choose a name for your speaker." Krokus (dyskusja) 08:25, 26 paź 2019 (CEST)

@Olaf Wyczytałam, że istnieje coś takiego jak Libre Bot, ale aktywnie wspiera tylko francuski Wikisłownik. Krokus (dyskusja) 10:46, 26 paź 2019 (CEST)

Nauczyłem mojego bota korzystania z automatu Beau do wstawiania wymowy, lecz wyłączyłem go całkowicie po tym, jak KaMan zauważył problem z obsługą plików LinguaLibre wynikający z nieco dziwnej kategoryzacji. Planuję go napisać od nowa. Peter Bowman (dyskusja) 01:24, 27 paź 2019 (CEST)

• Prześledziłem, iż najstarsze pliki nagrane za pomocą LinguaLibre mają około roku. Załadowano ich od tamtego czasu dość dużo w różnych językach (obecnie jest to 66 języków), dodatkowo jest to jakoś sprzęgnięte z Wikidanymi, zatem nie wydaje mi się, aby zmiana już teraz była możliwa, albo wymagałaby szerokich konsultacji międzyprojektowych. Będzie lepiej, jeśli to my dostosujemy się do istniejącego standardu. Bardzo chętnie bym tego narzędzia używał i nawet rozważam zakupienie mikrofonu, aby uzyskać lepszą jakość dźwięku :). Prosiłbym więc o wygenerowanie listy brakującej wymowy :). Nostrix (dyskusja) 08:35, 28 paź 2019 (CET)

  @Nostrix: wygenerowałem listę, zob. [4]. Pytanie: co zrobić z hasłami ze spacją? Zignorować czy zamienić na inny znak? Peter Bowman (dyskusja) 15:45, 28 paź 2019 (CET)

  @Peter Bowman - bardzo dziękuję! Co do haseł ze spacjami: jeszcze nie wiem, sprawdzę, czy nie wystarczy wstawić znaku _ między wyrazy i już. Nostrix (dyskusja) 09:58, 29 paź 2019 (CET)

  @Peter Bowman A dałoby się z tej listy wykluczyć dialektyzmy np. Górnego Ślaska (np.: zozwor) i utworzyć dla nich odrębną listę, tak aby ludzie posługujący się tą gwarą mogli nagrać tego typu słowa. Pozdrawiam Krokus (dyskusja) 13:09, 31 paź 2019 (CET)

  @Krokus: jasne; czy tak powinno być dla wszystkich dialektyzmów/regionalizmów, bądź skategoryzować te braki w jeszcze inny sposób? Lista stron jest dość długa i ponadto zmienna w czasie, mogę więc zrobić z tego automat odświeżający ją okresowo i wypluwający gotowe pliki do programu. Możliwoście jest wprawdzie dużo, proszę o opinie. Peter Bowman (dyskusja) 15:10, 31 paź 2019 (CET)

  @Peter Bowman Najlepiej porozdzielać, i raz na jakiś czas automatycznie aktualizować (wszystko może być w jednym pliku - wystarczy, że hasła będą wyraźnie rozdzielone) :). A automatyczne dodawanie botem wymowy do haseł to, jak mniemam, bardziej skomplikowana sprawa? Nostrix (dyskusja) 15:14, 31 paź 2019 (CET)

@Peter Bowman Optowałabym jednak za oddzielną listą dialektyzmów, najlepiej z podkategoriami jaki to dialektyzm. Dialektyzmy posiadają najczęściej swoją regionalną wersję wymowy - sorry ale nawet białostockie śledzikowanie, niby nie trudne, ale powinno być autentyczne. Krokus (dyskusja) 19:50, 1 lis 2019 (CET)

• Nagrałem wczoraj trochę słów w tym narzędziu i jest ono bardzo wygodne w obsłudze. Tyle że faktycznie trzeba odsiać gwarę z listy haseł (pewnie problemem jest to, by pozostawić hasła typu kibol, które oprócz znaczenia regionalnego mają też ogólne), no i fajnie gdyby bot dodawał te nagrania automatycznie, bo ręcznie to trochę udręka ;). Nostrix (dyskusja) 08:57, 15 lis 2019 (CET)

  @Nostrix, @Krokus: odsiałem regionalizmy/dialektyzmy i umieściłem je w osobnych listach, zob. [5]. Te listy będą odświeżane z każdym nowym zrzutem bazy danych Wikisłownika (średnio co parę tygodni). Zbadam kwestię dodawania nagrań przez bota. Pozdrawiam, Peter Bowman (dyskusja) 02:43, 16 lis 2019 (CET)

  @Peter Bowman Ogromnie dziękuję! Już nagrywam :). Nostrix (dyskusja) 08:59, 17 lis 2019 (CET)

Wyłączenie VE

Chciałbym zaproponować zmianę w konfiguracji Wikisłownika polegającą na tym, że domyślnym edytorem stron dla wszystkich użytkowników (zalogowanych i niezalogowanych) będzie edytor wikikodu. Obecnie jest tak, że po otwarciu okna edycji wyskakuje okienko z pytaniem o tryb edycji. Osoby posiadające konto mogą sobie w preferencjach ustawić domyślny tryb i wówczas zawsze będzie się otwierało okno z wikikodem, ale osoby niezalogowane, lub te, które dopiero założyły konto i jeszcze niczego nie zmieniły w preferencjach, mogą wybrać w jakim trybie edytować. I często wybierają VE.
Uzasadnienie zmiany: Edytor wizualny to narzędzie stworzone pod Wikipedię. To przeglądarkowa wersja procesora tekstu na zasadzie WYSIWYG. Doskonale nadaje się do pisania akapitów, budowania tabelek i wstawiania przypisów (np. po numerze ISBN szablon cytuj automatycznie wypełniany jest opisem bibliograficznym). W naszym projekcie jednak nie piszemy długich akapitów. Operujemy szablonami, parametrami, hasła mają stałą strukturę. Nie wiem czy próbowaliście kiedykolwiek edytować za pomocą VE, ale nie jest to po prostu możliwe bez popsucia kodu strony. Tymczasem szybkie przejrzenie OZetów wskazuje, że IPki i osoby nowe próbują tego narzędzia używać do edycji i zawsze źle się to kończy: [6]. Proponuję zatem jak na wstępie: zmienić konfigurację strony tak, aby edytor wikikodu był domyślnie ustawiony dla wszystkich bez pytania o tryb edycji. Jednocześnie pozostanie możliwość włączenia VE w preferencjach konta, o ile ktoś bardzo tego chce. Ponieważ taką zmianę konfiguracji robią technicy WMF i konsensus społeczności musi być dla nich klarowny, zatem proszę o stosowanie szablonów {{za}}, {{przeciw}} i ewentualnie {{komentarz}}.
Dodam, że VE "wyłączył" już francuski Wikisłownik. Być może Wikisłowniki doczekają się kiedyś odrębnego narzędzia WYSIWYG do edycji haseł, napisanego przez WMF, bardzo jednak w to wątpię, bo na ten moment silnie promowane jest Wikidata i tamtejsze leksemy. Nostrix (dyskusja) 09:53, 30 paź 2019 (CET)

•  Za Nostrix (dyskusja) 09:53, 30 paź 2019 (CET)
•  Za Olaf (dyskusja) 10:26, 30 paź 2019 (CET)
•  Za Maitake (dyskusja) 11:35, 30 paź 2019 (CET)
•  Za Okcydent (dyskusja) 12:11, 30 paź 2019 (CET)
•  Za Agnese (dyskusja) 12:46, 30 paź 2019 (CET)
•  Za tsca (dyskusja) 13:00, 30 paź 2019 (CET)
•  Za Peter Bowman (dyskusja) 14:12, 30 paź 2019 (CET)
•  Za Sankoff64 (dyskusja) 17:53, 30 paź 2019 (CET)
•  Za Krokus (dyskusja) 12:52, 31 paź 2019 (CET)
•  Za PiotrekD^DYSKUSJA 00:44, 1 lis 2019 (CET)
•  Za Kroton (dyskusja) 07:28, 1 lis 2019 (CET)
•  Za Paterm (dyskusja) 10:48, 3 lis 2019 (CET)
•  Za Zetzecik (dyskusja) 17:40, 3 lis 2019 (CET)
•  Za --Comp1089 (dyskusja) 14:24, 4 lis 2019 (CET)

Poprosiłem MatmaRexa o pomoc w założeniu odpowiedniego zgłoszenia na Phabricatorze, ale jeszcze tego nie zrobił; po wkładzie widać, że chwilowo jest nieaktywny. Nostrix (dyskusja) 13:55, 26 lis 2019 (CET)

Można samemu założyć. Polecam tę umiejętność, gdyż na przyszłość będzie można łatwiej wprowadzać w życie takie zgłoszenia albo doprowadzić do szybszej naprawy jakiegoś błędu. --Wargo (dyskusja) 00:48, 28 lis 2019 (CET)

• Zgłoszenie na Phabricatorze: [7]. Nostrix (dyskusja) 14:50, 13 sty 2020 (CET)

Powinno być już zrobione. Niezalogowani użytkownicy i nowo założone konta nie mają opcji przełączenia edytora na tryb wizualny. Zalogowani mogą w funkcjach eksperymentalnych (w preferencjach) włączyć możliwość używania edytora wizualnego. Wybaczcie, że chwilę to potrwało. Czy tak miało być? (@Wargo, @Nostrix, @PiotrekD) Matma Rex (dyskusja) 02:32, 3 mar 2020 (CET)

Wylogowałem się, sprawdziłem: domyślnym edytorem (bez możliwości wyboru) jest klasyczny edytor wikikodu, zatem wszystko gra. Dzięki, @Matmo Reksie :). Peter Bowman (dyskusja) 16:33, 14 mar 2020 (CET)

Zdaje się, że Visual Editor jest nadal aktywny – w wersji mobilnej: OZ, Specjalna:Diff/7327236. Obecnie wygląda to tak, że domyślnie otwiera się edytor wikikodu, lecz w każdej chwili można przełączyć na tryb VE. Peter Bowman (dyskusja) 01:57, 27 maj 2020 (CEST)

• Ping @Matma Rex Nostrix (dyskusja) 07:15, 27 maj 2020 (CEST)
  • @Nostrix, @Peter Bowman Faktycznie… Ale moim zdaniem są dwie różnice między tym problemem a tym z wersją standardową: 1) wersja mobilna nie ma tego okienka zachęcającego do przełączenia edytora, więc trudniej przełączyć przez przypadek 2) jeśli w wersji mobilnej ukryjemy tę opcję przełączenia edytora, to w ogóle nie będzie możliwości przywrócenia sobie edytora wizualnego, bo w wersji mobilnej nie są dostępne preferencje użytkownika (chyba, że przełączysz na wersję stand.). Przeglądnąłem ostatnie zmiany z tego linku i moim zdaniem niewiele tam problemów spowodowanych przez edytor, te wycofane to głównie wandalizmy, które identycznie wyglądałyby w edytorze wikitekstu. Zatem moim zdaniem można to tak zostawić… Co na to powiecie? Matma Rex (dyskusja) 00:01, 2 cze 2020 (CEST)
  • @Matma Rex, @Nostrix: zdarzyła nam się dziś taka edycja, wszędzie mnóstwo <nowiki>. Edytor Wizualny to wciąż pułapka dla nowicjuszy (poza Wikipediami). Peter Bowman (dyskusja) 16:07, 14 lip 2020 (CEST)

Szablony edycji w edytorze

Dzień dobry, po pewnym czasie nieobecności dodałem kilka haseł i zauważyłem, że szablony haseł w edytorze automatycznie dodają pusty numer (1.1) do przykładów, po czym bot z każdego utworzonego hasła kasuje ten numer. Może warto by usunąć dodawanie tego numeru przy korzystaniu z szablonów edycji (guzikami w edytorze źródłowym)? Pozdrawiam, Karol Szapsza (dyskusja) 17:17, 13 lis 2019 (CET)

@Karol Szapsza: pousuwałem ten pusty numer, ale mogłem coś pominąć. Jak dokładnie, krok po kroku, tworzysz nowe hasło? Peter Bowman (dyskusja) 18:28, 14 lis 2019 (CET)

Mea culpa, z tego co widzę, to edytor dodaje pełne

(1.1) Przykład zdania.

A ja prawdopodobnie z przyzwyczajenia pozostawiam pusty numerek;) Karol Szapsza (dyskusja) 12:56, 15 lis 2019 (CET)

{{słow}}

Poprzedni wątek

Ponieważ powyższy szablon nie jest jednoznaczny, a przez dwa lata nikt nie zgłosił zastrzeżeń wobec jego dezaktywacji, zastąpiłem jego treść komunikatem proszącym o zastosowanie jednego z innych, bardziej konkretnych szablonów. W razie sprzeciwu w chwili obecnej, wycofać należy następujące dwie zmiany: [8] oraz [9]. Maitake (dyskusja) 11:10, 16 lis 2019 (CET)

• Trzeba ten komunikat wprowadzić jeszcze w jedno miejsce, tak by się pojawiał w razie użycia wewnątrz szablonu {{etym}} (i pokrewnych). Na razie nie umiem tego znaleźć, ale poszukam. — Dziwne jednak, że w przypadku szablonów z Kategoria:Szablony niejednoznacznych skrótów nazw języków komunikat nie pojawia się w razie zastosowania ich samodzielnie, poza szablonem {{etym}} i pokrewnymi (wówczas nic się w ogóle nie pojawia). Maitake (dyskusja) 11:18, 16 lis 2019 (CET)

  @Maitake: wprowadziłem do {{etym/język}}: Specjalna:Diff/7108847/7154714, ujednoliciłem komunikaty błędu, umożliwiłem ich wyświetlanie w razie samodzielnego zastosowania. Przy okazji zauważyłem nieprawidłowe użycie {{turk}} w haśle „Omsk”. Pozdrawiam, Peter Bowman (dyskusja) 12:19, 16 lis 2019 (CET)

  Dziękuję. Omsk poprawiłem za źródłem – tym razem nie chodziło ani o turecki, ani o turkmeński, a o tatarski (a konkretnie o dialekt Tatarów barabińskich). Maitake (dyskusja) 15:40, 16 lis 2019 (CET)

Ukryte kategorie konkursowe

Droga społeczności, przychodzę z prośbą nieśmiałą. Czy wyrażacie zgodę na zamieszczenie haseł z Konkursu Wikisłownika w ukrytej kategorii technicznej "hasła rozbudowane w ramach konkursu Wikisłownika"? Prośba wynika z tego, że Wikimedia Polska rozpoczyna korzystanie z narzędzia EventMetrics do zliczania swoich akcji i projektów. EventMetrics ma sporo wspaniałych funkcji i daje nam sporo danych o naszej działalności, ma niestety jedną wadę: należy podać kategorię, w której są hasła i musi być to kategoria w przestrzeni głównej, nie na stronie dyskusji. Wiem, że Wikisłownik ma zupełnie inny system i podejście do kategorii, niż Wikipedia, ale myślę, że skoro mówimy o kategoriach ukrytych, to nie będzie to tworzyło chaosu, a na pewno nie utrudni życia czytelnikom. Natalia Szafran-Kozakowska (WMPL) (dyskusja) 13:27, 20 gru 2019 (CET)

• Ja nie mam nic przeciwko ;). Jeśli społeczność się zgodzi, to mogę dodać ręcznie, bo botem to chyba nie ma sensu. Nostrix (dyskusja) 14:01, 20 gru 2019 (CET)
• Rozumiem sytuację, ale śmiem wskazać, że u nas po prostu nie wstawia się kategoryj bezpośrednio w kod hasła, jak to się robi na Wikipedii; wszystko robią za nas automatycznie szablony. (Z bodaj jednym wyjątkiem będącym pozostałością dawnych czasów, ale nie mogę sobie go teraz przypomnieć niestety). Dlatego jestem przeciw. Pozdrawiam, PiotrekD^DYSKUSJA 21:09, 26 gru 2019 (CET)

  Kojarzę tylko ręcznie wstawione Kategoria:Polskie neologizmy, Kategoria:Polskie neologizmy literackie, Kategoria:Polskie neologizmy polityczne (dziś wolałbym zautomatyzować {{neol}} za pośrednictwem Wikisłownikarz:Liteman/Beau.bot-indeksy). Peter Bowman (dyskusja) 21:47, 26 gru 2019 (CET)

  A jeśli obiecałabym, że za jakiś czas usunę? Czy to by coś pomogło? Natalia Szafran-Kozakowska (WMPL) (dyskusja) 16:23, 2 sty 2020 (CET)

  Jeśli to za czas jakiś, niezbyt długi, nie będzie potrzebne, to i bot będzie mógł usunąć (o ile zachowa się jednolitość oznaczeń tej kategorii i zadba o jej niepowtarzalność). Gdyby to miało funkcjonować tylko przez jakiś czas, to ja nie widzę przeciwwskazań. Maitake (dyskusja) 17:15, 2 sty 2020 (CET)

  OK, to ja pozwolę sobie je zamieścić na dosłownie tydzień Natalia Szafran-Kozakowska (WMPL) (dyskusja) 14:17, 29 sty 2020 (CET)

  Jasne, dodawaj. W niczym to nie szkodzi, rozwiązanie jest i tak tymczasowe, a skoro to narzędzie ma takie wymagania, no to nie ma nad czym dyskutować.Olaf (dyskusja) 14:50, 29 sty 2020 (CET)

• Podsumowanie konkursu w postaci tabelki zostało wygenerowane. Zatem można już usunąć (np. przy okazji jakiegoś innego botowania) hasła z kategorii Kategoria:Hasła konkursowe. Nostrix (dyskusja) 11:25, 7 lut 2020 (CET)

  Opróżniłem i usunąłem Kategoria:Hasła konkursowe, dla wygody powieliłem listę haseł w Wikisłownikarz:PBbot/hasła konkursowe (2020). Peter Bowman (dyskusja) 22:27, 24 lut 2020 (CET)

{{kończące się na}}

Co sądzicie, żeby po kliknięciu i przejściu do kategorii pokazywały się tylko hasła, które powinny, a nie wszystkie od danego hasła? Czyli: zobacz słowa kończące się na „-fobo” pokazywałoby tylko 5 haseł, nie wszystkie od "-fobo" dalej. Technicznie jest to do zrobienia? Zan-mir (dyskusja) 03:13, 16 sty 2020 (CET)

Gadżet „Obsługa indeksów literowych na stronach kategorii dla usprawnienia nawigacji i wyszukiwania haseł” zlicza hasła ze wskazaną końcówką i oddziela je kreską poziomą od pozostałych 195. Tak przynajmniej powinno być, mnie w tej chwili nie działa – zerknę. Peter Bowman (dyskusja) 14:38, 16 sty 2020 (CET)

Gadżet naprawiłem, choć nadal wymaga przeglądu. W Kategoria:polski (indeks) generuje ikonkę lupy pod indeksem literowym; wyszukanie „baz” prawidłowo przeskakuje do odpowiedniego miejsca na liście i wstawia separator. Niestety, nie zawsze ów separator się pojawia, chyba to wina Dyskusja kategorii:polski (indeks a tergo)#Znaki diakrytyczne. Peter Bowman (dyskusja) 21:18, 24 lut 2020 (CET)

Gadżet do wstawiania szablonów źródeł...

...nie obejmuje Kategoria:Szablony źródeł (polski - gwary). Zan-mir (dyskusja) 18:46, 24 sty 2020 (CET)

• @Zan-mir: Wszystkie źródła dla gwar i dialektów polskich są po prostu pod językiem polskim (bo tak są też skategoryzowane). Brakowało tam szablonów {{Szablon:Wierzba2009}} oraz {{Szablon:Wierzba2013}}, bo nie były one ujęte w odpowiednich kategoriach, ale to właśnie dodałem, więc za krótką chwilę powinno być w porządku. Innych braków tam nie zauważyłem. — Czy wyróżnienie źródeł dla dialektów i gwar w osobną grupę ma sens, nie wiem, nie zastanawiałem się na tym nigdy, choć rzeczywiście źródła dla języka polskiego są obecnie potwornie długie. Maitake (dyskusja) 19:17, 24 sty 2020 (CET)

Additional interface for edit conflicts on talk pages

Sorry, for writing this text in English. If you could help to translate it, it would be appreciated.

You might know the new interface for edit conflicts (currently a beta feature). Now, Wikimedia Germany is designing an additional interface to solve edit conflicts on talk pages. This interface is shown to you when you write on a discussion page and another person writes a discussion post in the same line and saves it before you do. With this additional editing conflict interface you can adjust the order of the comments and edit your comment. We are inviting everyone to have a look at the planned feature. Let us know what you think on our central feedback page! -- For the Technical Wishes Team: Max Klemm (WMDE) 15:15, 26 lut 2020 (CET)

Strona główna w wersji mobilnej

Obecnie mobilna strona główna wygląda tak. Od kwietnia będzie wyglądać tak. Czyli o ile nie zostaną wprowadzone lokalnie jakieś zmiany będzie renderowana jak na wersji desktopowej, ale bez braków (te najprawdopodobniej można było też poprawić w dotychczasowej wersji, ale już nie warto). Warto też sprawdzić czy strona główna jest i będzie przyjazna do oglądania na różnych ekranach. --Wargo (dyskusja) 18:55, 29 lut 2020 (CET)

Dzięki, @Wargo. Podlinkuję do strony pomocy: mw:Mobile Gateway/Mobile homepage formatting. Dodałem klasę "nomobile" (Specjalna:Diff/7219568), ale w naszym przypadku to niewystarczające. Trzeba przejrzeć strukturę elementów na SG od nowa. Peter Bowman (dyskusja) 15:55, 1 mar 2020 (CET)

Dlaczego indeks tematyczny ukrywamy? --Wargo (dyskusja) 17:48, 1 mar 2020 (CET)

To ja może od razu zgłoszę drobny problem. Mianowicie w nowym widoku tytuły wyświetlają się poza swoimi „liniami” zarówno w układzie pionowym jak i poziomym strony. (Wersja mobilna, wyświetlanie również mobilne, Android, ekran 1080 x 1920 px (5.50") 401 ppi) Pozwolę sobie zamieścić LINK DO ZRZUTU EKRANU --ThelmOSO (dyskusja) 19:49, 5 mar 2020 (CET)

Dzięki, @ThelmOSO. Nasz obecny design nie sprzyja urządzeniom mobilnym z tego powodu, że dzielimy zawartość SG na kolumny. Do tej pory wybieraliśmy, które poszczególne „bloki” wyświetlać na mobilnej bez uwagi na ów podział. Nowy system będzie polegał na odwrotnym procesie: wybór elementów, które należy wykluczyć z wersji mobilnej. Ponieważ pożądane bloki są zagnieżdżone w elementach, które nas nie interesują (w tym kolorowe ramki z ikonkami, które widać na Twoim zrzucie), a należą do różnych kolumn, tego podziału nie da się uniknąć i w rezultacie na wąskim mobilnym ekranie widzimy ściśnięte tytuły. Peter Bowman (dyskusja) 19:59, 5 mar 2020 (CET)

Datę wprowadzenia zmian, o których pisał na początku Wargo, przesunięto na 13 lipca (phab:T254287). Nieco się przeliczyłem ze złożonością problemu, w przypadku Wikisłownika układ kolumn został dobrze zaprojektowany i przez to wymagane zmiany ograniczyły się do Specjalna:Diff/7333622 + Specjalna:Diff/7333623. Teraz widzimy dwie kolumny na szerszych ekranach (ekran komputera, tablet, komórka w ustawieniu poziomym), zaś tylko jedną na węższych (komórka w ustawieniu pionowym); to powinno rozwiązać problem zgłoszony przez @ThelmOSO. Ponieważ utworzył się pusty obszar po lewej, odkryłem rubrukę słowników tematycznych (poprzednio niewidoczną w wersji mobilnej): obecny wygląd. Peter Bowman (dyskusja) 02:33, 5 cze 2020 (CEST)

W następstwie Specjalna:Diff/7333629 kończy się u nas okres przejściowy (inaczej zostałby przymusowo wprowadzony za kilka tygodni), SG w wersji mobilnej wygląda tak samo jak w standardowej (z uwzględnieniem ukrywania niektórych elementów, tak jak do tej pory), nie trzeba już dopisywać ?mfnolegacytransform=1&debug=1 do adresu (wynik jest ten sam). Peter Bowman (dyskusja) 02:44, 5 cze 2020 (CEST)

Wygląd szablonu audio

W tej chwili szablon {{audio}} ma w sobie słowo "wymowa'. Jest ono nadmiarowe, bo i tak jest używany wyłącznie w polu 'wymowa'. W przypadku, gdy nagrań jest sporo, nie wygląda to dobrze:

wymowa

IPA: [ɑ̃] ​

​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​

Wydaje mi się, że można to słowo wyrzucić, jako nadmiarowe. Wyglądałoby to podobnie do szablonu {{audio-A}} tylko również z linkiem do pomocy, jakoś tak:

wymowa

IPA: [ɑ̃] ​

​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​

Wydaje mi się to nieco lepsze wizualnie. Nawet gdyby w haśle była tylko jedna wymowa, nadal nie wygląda to chyba źle:

wymowa

​

Czy macie coś przeciwko temu, żeby zmienić szablon {{audio}} w ten sposób?

Ewentualnie jakieś inne koncepcje... na francuskim wikisłowniku używają wbudowanego gadżetu, umieszczając hasła jedno pod drugim: fr:an#Prononciation. To ma dodatkowe zalety – jest miejsce na podanie regionu z którego pochodzi dana wymowa i pliki wav z LinguaLibre odtwarzają się bezpośrednio w przeglądarce (co trzeba będzie zrobić i u nas). Wymagałoby to jednak znaczącego przeformatowania haseł i prawdopodobnie umieszczenia tych odtwarzaczy w kolejnych linijkach, co może mocno zaburzyć wygląd haseł, bo często te linki do wymowy są ustawione obok wymowy zapisanej międzynarodowym alfabetem fonetycznym. Olaf (dyskusja) 11:23, 5 mar 2020 (CET)

• To nie jest ich gadżet, lecz rozszerzenie mw:Extension:TimedMediaHandler, które jest włączone i u nas: oraz Indeks:Angielski - Jedzenie. Zdaje się, że po wielu latach odtwarzanie bez opuszczania strony wreszcie działa na wszystkich głównych przeglądarkach i w wersji mobilnej. Można zmniejszyć pasek do samego przycisku odtwarzania poprzez CSS. Może czas zastanowić się nad zmianą struktury tego pola? Zob. Dyskusja szablonu:audio. Peter Bowman (dyskusja) 12:33, 5 mar 2020 (CET)
  • O, widzę w dyskusja szablonu:audio, że już 10 lat temu było właściwie uzgodnione usunięcie tego słowa "wymowa", tylko nikt tego nie zrobił. Zmiana struktury to poważniejsza sprawa, trzeba tu uważnie podejść do rzeczy, są hasła z bardzo rozbudowanymi opisami wymowy w różnych wariantach (np. that, gęś), tego się nie uda zrobić botem, a obróbka ręczna nawet tych nietypowych sytuacji może być ponad nasze możliwości. Olaf (dyskusja) 13:35, 5 mar 2020 (CET)
    • Jest pewien detal: pozycja szablonu audio względem IPA w tej samej linii oraz oddzielanie ich przecinkiem. Widziałem różne konfiguracje, jedni edytorzy wstawiają przecinek, a inni – usuwają. Może to warto uściślić w Zasadach przy okazji tych zmian. Peter Bowman (dyskusja) 19:32, 5 mar 2020 (CET)
• Rzeczywiście nie wygląda to najlepiej. Wersja druga, bez powtarzającego się słowa "wymowa" jest lepsza. Jednak zmieniłbym ikonkę głośniczka na ikonkę play, np. lub lub lub . Przed ciągiem takich ikonek (z linkami w indeksach górnych) dodałbym jednak jakieś słowne wyjaśnienie, typu: "nagrania wymowy:". Szablon {{audio}} z kolei wypełniałoby się dodając kolejne linki do nagrań, tzn. {{audio|nagranie1|nagranie2|nagranie3}}
  Nie mogę tej mojej koncepcji zaprezentować tak jak to zrobił Olaf, bo ikonka głośniczka jest w naszym css, a nie w szablonie. Nostrix (dyskusja) 12:50, 5 mar 2020 (CET)
  • Słowne wyjaśnienie wymaga edycji botem każdego artykułu, co jest wykonalne, ale może być problem przy nietypowych hasłach, gdzie te ciągi przeplatają się ze słownymi opisami. Olaf (dyskusja) 13:35, 5 mar 2020 (CET)
  • Chociaż w sumie można to zrobić w ten sposób, że wszędzie gdzie są dwa szablony audio jeden za drugim, zamienić na to nowe audio. To musiałby być oddzielny szablon, bo obecny ma już drugi argument, z innym znaczeniem. Ok, to jest do zrobienia botem. Z tym że jeśli już to wolałbym "nagrania:" a nie "nagrania wymowy:". Olaf (dyskusja) 13:54, 5 mar 2020 (CET)
• A może dałoby radę wziąć to rozszerzenie, o którym pisał wyżej Peter, i ostylować CSS-ami tak, żeby została sama ikonka, z ewentualną zmianą jej wyglądu na wersję Nostrixa. Gdyby to się udało, mielibyśmy względnie nienajgorszy wygląd i dodatkowo funkcjonalność odtwarzania Wav w przeglądarce. Olaf (dyskusja) 13:35, 5 mar 2020 (CET)
  • To ostatnie to moim zdaniem najlepsze wyjście. (Kiedyś nawet czytałem na jakimś portalu recenzję różnych słowników online, był tam też Wikisłownik i jako wadę wymieniono to, że nagrania nie odtwarzają się w przeglądarce, tylko w trybie do pobrania.) Obecny wygląd odtwarzacza mediawiki wygląda dość topornie (tak old-schoolowo), więc fajnie byłoby go nieco uwspółcześnić cssem. Nostrix (dyskusja) 14:14, 5 mar 2020 (CET)
    • @Nostrix: czy odtwarzacz to u Ciebie taki szary, paskudny pasek? Nie zauważyłem, że mam włączoną funkcję eksperymentalną „Nowy odtwarzacz filmów” w preferencjach, więc u mnie (i za jakiś czas także u niezalogowanych czytelników) wygląda to nieco inaczej: mw:Extension:TimedMediaHandler/VideoJS Player, https://video-testing.wmflabs.org. Jest to produkt niedokończony – teoretycznie szerokość paska da się prosto zmienić, ale coś jeszcze nie do końca działa, jak powinno: mw:Topic:Vgsd2hel129tsy81. Peter Bowman (dyskusja) 16:44, 5 mar 2020 (CET)
    • Po włączeniu funkcji eksperymentalnej przejdź do Wikisłownikarz:Peter Bowman/test audio. Skróciłem pasek, mimo to nie komponuje się z tekstem zbyt dobrze. Peter Bowman (dyskusja) 17:00, 5 mar 2020 (CET)
      • No faktycznie nie wiedziałem, że jest taka funkcja eksperymentalna :). Włączyłem ją sobie i to, co zrobiłeś na stronie wygląda nieźle, ale czy nie można tych kwadracików play pozmniejszać? Wydaje mi się, że nie komponują się z tekstem dlatego, że są za duże :). Nostrix (dyskusja) 19:18, 5 mar 2020 (CET)
        • Owszem, obecny przycisk play to prosta grafika wektorowa ustawiona przez CSS. Trzeba się trochę pobawić z formatem SVG, żeby było dobrze – dla doświadczonego pewnie chwila roboty, ja (jeszcze) tego nie potrafię :). Problem: póki Fundacja nie włączy tej funkcji eksperymentalnej, trzeba będzie również dopasować rozmiar starego (szarego) paska. Ponadto funkcja powinna zostać dopracowana, gdyż nie ma chyba sensu, by odtwarzanie nagrania otwierało okienko (ktoś zgłaszał podobną uwagę w mw:Extension talk:TimedMediaHandler/VideoJS Player). Peter Bowman (dyskusja) 19:29, 5 mar 2020 (CET)
          • Być może warto byłoby w jakiś sposób zachować przy tym odnośniki „?” do pomocy (oraz ewentualnie „i” - informacji o pliku). Co prawda nie mam pojęcia czy ktoś z tego korzysta, może też nieco kłócić się z ogólną estetyką zwłaszcza biorąc pod uwagę powyżej przedstawioną wersję w widoku eksperymentalnym. Pozdrawiam, ThelmOSO (dyskusja) 20:07, 5 mar 2020 (CET)
            • Tak, zdaje się, że jesteśmy nawet zobowiązani warunkami licencji CC-BY-SA do umieszczenia informacji o pliku - wykorzystując czyjeś nagranie powinniśmy do niego linkować, żeby dało się zobaczyć licencję i autora. Przy linku do pomocy bym się nie upierał, bo jest ona raczej nieaktualna i zbędna - każe instalować Windows Media Playera, który w nowej wersji nie będzie potrzebny. Olaf (dyskusja) 20:41, 5 mar 2020 (CET)
              • Ten link już jest zawarty w odtwarzaczu. Nowy player otwiera okienko, a w jego prawym dolnym rogu jest odnośnik do pliku w Commons. Może stąd wymuszenie nowego okienka zamiast bezpośrednie odtwarzanie pliku po naciśnięciu na play. Stary player, o ile nie skrócono paska, udostępnia przycisk MENU z informacją o pliku. Peter Bowman (dyskusja) 21:13, 5 mar 2020 (CET)
• Jestem za ikonką bez słowa "wymowa". Pozdrawiam serdecznie --EdytaT (dyskusja) 19:39, 5 mar 2020 (CET)
• No dobrze, póki funkcja eksperymentalna nie jest włączona i nikt nie zrobił porządnie tego szablonu, jako tymczasowe rozwiązanie wyrzucam napis "wymowa" z obecnego szablonu. To rozwiązanie tymczasowe, bo nie rozwiązuje problemu plików WAV nie odtwarzających się w przeglądarce. Spróbuję może coś z tym zrobić, gdy będę mieć trochę czasu, ewentualnie może Peter albo ktoś inny mnie ubiegnie. Jeśli będziemy ostatecznie potrzebować szablonu zbiorczego dla kilku nagrań, np. żeby dodać im tekst na początku, to zawsze można to zrobić, stron istniejących u nas, z dwiema wymowami w Commons (dodanymi do pl-wikt lub nie) obecnie jest 9973, w razie potrzeby ogarnę to botem w jedną dobę. Olaf (dyskusja) 15:28, 7 mar 2020 (CET)
  • Funkcja eksperymentalna zaczyna być stopniowo włączana domyślnie dla wszystkich użytkowników: phab:T248418. Peter Bowman (dyskusja) 19:39, 30 mar 2020 (CEST)
• Przy okazji może poruszę temat. W dawnych czasach ktoś zaproponował, by do szablonów odmiany dodawać również nagrania. Jeśli dobrze pamiętam com widział, to propozycja upadła wtedy z racji m.in. estetyki / przeciążenia tabelki. Przy zminimalizowanych ikonach wygląda to już lepiej:
   

  przypadek	liczba pojedyncza	liczba mnoga
  mianownik	zamek ​	zamki
  dopełniacz	zamku ​	zamków
  celownik	zamkowi	zamkom ​
  biernik	zamek	zamki
  narzędnik	zamkiem ​	zamkami
  miejscownik	zamku	zamkach
  wołacz	zamku	zamki

  Problemem wciąż pozostaje oczywiście kwestia czy jest to estetyczne, (nie)obecności zapisu IPA/AS, faktu że wymowa przesuwa się w dużej części poza własne pole (do tabeli odmiany… może wtedy w wymowie pozostawić tylko zapis?) i przede wszystkim faktu, że tych nagrań w bliskim czasie raczej się nie uświadczy… Osobiście niezbyt mnie ten pomysł przekonuje, ale zamieszczam w ramach przypomnienia, a nuż się czemuś przysłuży. Pozdrawiam serdecznie, ThelmOSO (dyskusja) 21:51, 15 mar 2020 (CET)
  • Mnie nie razi, tylko nie wiem dlaczego zamiana ikonki głośniczka na ikonkę play się Olafowi nie udała? Co poszło nie tak, ktoś ma jakiś pomysł? Nostrix (dyskusja) 17:36, 16 mar 2020 (CET)

ukrywanie nagrań

Co sądzicie, żeby ukryć nagrania, gdy jest ich więcej niż... nie wiem... 3? 4? Nie używam wersji mobilnej, ale ciekawi mnie jak wyglądają hasła arbre, quatre albo dent.

Niech te wszystkie nagrania będą w haśle, ale niech wyświetla się tylko kilka pierwszych, a dalej napis "pokaż więcej" albo może jakaś ikonka. Zan-mir (dyskusja) 17:51, 5 kwi 2020 (CEST)

• Można spróbować tak zrobić i zobaczyć jak to będzie wyglądać w wersji mobilnej (bo to obecnie ponad połowa wejść na Wikisłownik obecnie). Nostrix (dyskusja) 12:14, 23 kwi 2020 (CEST)
• Drobna uwaga: zdaje się, że w niektórych hasłach nagrania są podzielone na kilka linijek np. arbre, patro (przypuszczalnie boty wstawiają odnalezione nagrania w nowy wiersz, ale chyba nie tylko one), czasem znajdują się też bezpośrednio obok zapisu IPA. Nie mam pojęcia czy stanowi to problem, ale jakby co zaznaczam, --ThelmOSO (dyskusja) 16:37, 28 kwi 2020 (CEST)

Nagrywanie przykładów

• Natrafiłem na ciekawą rzecz w haśle po angielsku - nagrania całych przykładów. Kiedyś rozmawialiśmy (na Źródłosłowie i Słowotoku), aby coś takiego wprowadzić (tzn. umocować w zasadach - że jest to dozwolone). Co sądzicie? Nostrix (dyskusja) 12:14, 23 kwi 2020 (CEST)
  • Może to być faktycznie przydatne, bo jest więcej takich przypadków: „ 것 ”. Tymczasem przesunąłem tam audio na początek, by było jakoś ujednolicone, ale odnoszę wrażenie, że nie jest to najlepsze miejsce na nagranie (może lepiej po?…). Pozdrawiam ThelmOSO (dyskusja) 04:01, 1 maj 2020 (CEST)
    • Umiejscowienie jest ok, ale ta ikonka słabo pasuje, powinno być coś takiego: ▶, jako powszechnie stosowany piktogram odtwarzania (wideo/audio). Nostrix (dyskusja) 12:14, 1 maj 2020 (CEST)

Nowa wersja szablonu

Zrobiłem nową wersję szablonu audio, testowo umieszczoną jako {{audio2}}. Różnice są dwie:

• inna ikonka
• odtwarza zarówno nagrania ogg jak i wav w okienku - obecna wersja przy odtwarzaniu ogg wychodziła ze strony, a przy wav ściągała plik i kazała odtwarzać poza przeglądarką. Najchętniej w ogóle wyrzuciłbym to okienko, żeby to odtwarzało się jak na angielskiej wikipedii, ale na razie nie odkryłem jak.

Efekt można oglądać w haśle la#fr. Dla porównania obecna wersja: [10]. Jeśli nie macie żadnych zastrzeżeń, zmienię obecną postać szablonów audio w ten sposób. Pozdrawiam, Olaf (dyskusja) 13:20, 21 sty 2021 (CET)

• Ja jestem zadowolony z obecnego kształtu - nie mam problemów z odtwarzaniem wav w obecnej konfiguracji, zarówno wav, jak i ogg działają tak samo, nic się nie ściąga - Chrome, Windows. Mi się zaproponowana wersja zwyczajnie nie podoba graficznie (mam szerokie paski z serią przycisków, nie ikonki, jeden pod drugim https://i.ibb.co/K9bpyz8/wymowa-paski.jpg ) nie pasuje mi do tekstowego układu strony. Słowo "wymowa paryska" powinno być klikalne i powodować odtworzenie dźwięku. Ale moja główna wątpliwość dotyczy tego czy ta nowa wersja jest przystosowana do obsługi przez osoby niewidome/niedowidzące z czytnikami ekranu. Sprawdzę w najbliższych dniach z takimi osobami. Niemniej jeśli będzie decyzja o wdrożeniu nowej wersji to błagam, nie jednym przelotem przez wszystkie użycia audio. Jak już to stopniowo przez te 3 miesiące obiegu bota. Bo mi obserwowane zwariują od tysięcy haseł ;) KaMan (dyskusja) 13:33, 21 sty 2021 (CET)
  • No to mi się ściąga, ciężko odtworzyć cokolwiek z Lingua Libre. Może dlatego, że jestem teraz na Macu, sprawdzę potem na Windows. Będzie nie tylko jednym przelotem, ale jednym ruchem - po prostu zmienię szablon, bot nie będzie musiał nic robić, nic się nie zmieni w obserwowanych. Ja to włożyłem pod inną nazwę tylko tymczasowo, szablony się będą nadal tak samo nazywać. Ok, u mnie są eleganckie ikonki, czyli u Ciebie wygląda tak jak gdy się wyloguję. Błąd do poprawienia. Olaf (dyskusja) 14:06, 21 sty 2021 (CET)
• Na FF i nowym Edge'u mam ikonki i otwierane okienko; po wylogowaniu mam szerokie paski (każdy w osobnej linii) i odtwarzanie bezpośrednio na stronie. Pewnie ma to związek z funkcją eksperymentalną „Nowy odtwarzacz filmów”, wyżej chyba była o tym wzmianka. Dwie dodatkowe uwagi: 1. może by usunąć znak „?/i”? przynajmniej ten drugi, ponieważ obie wersje odtwarzacza już eksponują podobny link; 2. to jest dobry moment na przemyślenie struktury pola wymowy, tekstu towarzyszącego plikom itp.; nowy szablon mógłby przyjmować kilka plików jednocześnie. Przy okazji @Olaf, na jakiej stronie enwiki można wypróbować ich wersję szablonu? Pozdrawiam, Peter Bowman (dyskusja) 13:45, 21 sty 2021 (CET)
  • Ach, to pewnie dlatego to działa inaczej na en-wiki (sprawdzałem tutaj). Pewnie kwestia tego odtwarzacza. Ok, znaki i/? usunąłem. Powalczę jezcze z wyglądem u niezalogowanch, dzięki za zauważenie tego buga. Co do struktury pola wymowy, to możemy próbować coś zmieniać, choć na zmiany stu tysięcy haseł z wymową, z których wiele ma rozmaite nietypowe użycie szablonów audio, już mogę nie znaleźć dość sił. Olaf (dyskusja) 14:06, 21 sty 2021 (CET)

A może dałoby się odtwarzać te nagrania po najechaniu myszką na ikonkę głośniczka, bez żadnego klikania ani otwierania dodatkowych okienek? U mnie część nagrań tak działa dzięki któremuś z rozszerzeń FF, to bardzo wygodne. tsca (dyskusja) 13:54, 21 sty 2021 (CET)

• Chciałbym, tylko nie wiem na razie jak. Olaf (dyskusja) 14:06, 21 sty 2021 (CET)

Również byłbym za tym, aby uporządkować pole wymowy. Wydaje mi się, że guzik nagrania powinien być stosunkowo niezbyt duży, natomiast zaproponowane długie paski zajmujące całą linijkę sprawiają, że pole wymowy przytłacza całą resztę hasła, w tym haśle testowym na jednym ekranie widać tylko wymowę i nawet znaczenie się już nie załapuje, trzeba zjechać na dół. — Moja propozycja byłaby taka: nagrania lepiej stawiać przed zapisem IPA, bo nagranie odtworzy i usłyszy (niemal) każdy, a zapis IPA jest dla wielu całkiem nieczytelny. Nagranie powinno mieć stosunkowo mały guzik (np. taki, jak do tej pory). Jeśli jest jedno nagranie (albo maksymalnie trzy), to wszystkie powinny stać po kolei na początku linijki (nieoddzielone żadnym znakiem poza spacją), a po nich zapis IPA w tej samej linijce. Jeśli nagrań jest więcej niż trzy (czy to się poza francuskim zdarza?), to układ taki sam, ale zapis IPA od nowej linijki. (Pod zapisem IPA rozumiem każdy zapis wymowy w postaci symboli: IPA, alfabet słowiański, angielskie SAMPA itd.). Maitake (dyskusja) 13:57, 21 sty 2021 (CET)

Ech, nie u mnie nie ma pasków zajmujących całą linijkę. To jakiś błąd, muszę poprawić. Olaf (dyskusja) 14:07, 21 sty 2021 (CET)

U mnie to wygląda tak: [11] i coś takiego chciałem zaproponować. Chyba faktycznie to wygląda w ten sposób tylko przy włączonym eksperymentalnym odtwarzaczu, zobaczę czy mi się to uda poprawić. Olaf (dyskusja) 14:18, 21 sty 2021 (CET)

Co czeka na przejrzenie?

Co dokładnie czeka na przejrzenie w takich hasłach, jak np. עסן? U góry wyświetla się komunikat: „Na przejrzenie oczekują zmiany w szablonach lub plikach użytych na tej stronie”, ale nie udało mi się dojść, co by to miało być. Takie komunikaty pojawiają się wcale nierzadko. Maitake (dyskusja) 23:37, 23 mar 2020 (CET)

@Maitake: może to być dowolna strona (nie tylko szablon albo plik, jak wskazuje komunikat) transkludowana w tym haśle, pośrednio lub bezpośrednio. Oprogramowanie zwykle wskazuje, o który szablon lub plik chodzi – po wejściu na stronę hasła, kliknij na link w zdaniu „Na przejrzenie oczekują zmiany w szablonach lub plikach użytych na tej stronie.” Potem zauważysz „Niektóre szablony lub pliki zostały uaktualnione (nieprzejrzane strony są wytłuszczone): Wikisłownikarz:Joystick/yi-czas1”. O tę pogrubioną podstronę Joysticka się rozchodzi, wykorzystujemy ją w szablonie odmiany jidysz. Wydaje się dziwne, ponieważ ostatnią zmianę wykonałem ja w 2018, ale niewykluczone, że baza danych nie została odświeżona. Zdarza się, że zmiany w szablonie dopiero po jakimś czasie są przetwarzane przez system wersji przejrzanych (stąd częstotliwość występowania komunikatu). Może też być, że ta strona znajduje się w przestrzeni użytkownika, a powinna pod Szablon:. Jeżeli częściej będziesz zauważał prośbę o przejrzenie kierującą ponownie na tę samą stronę, daj znać, to przeniosę ją w inne miejsce. Peter Bowman (dyskusja) 02:06, 24 mar 2020 (CET)

• Dziękuję za wyjaśnienie, ale to w ogóle dziwne, bo strony Wikisłownikarz:Joystick/yi-czas1 nie można przejrzeć (w sensie: zaakceptować zmiany), jej wersje przejrzane nie dotyczą. Wydaje mi się też, że widywałem taki komunikat w hasłach bez odmiany czasownika, ale w tej chwili nie pamiętam. W każdym razie jak na coś jeszcze trafię, to zgłoszę. Maitake (dyskusja) 10:19, 24 mar 2020 (CET)
• Strona זײַן rzekomo czeka na przejrzenie, z tego samego powodu: zmiany w szablonie odmiany czasownika jidyszowego (Wikisłownikarz:Joystick/yi-czas1). Maitake (dyskusja) 18:03, 9 kwi 2020 (CEST)
• Przeniosłem kod szablonu do {{yi-czas}}, czyli w miejsce dawnego przekierowania. Zobaczymy, czy poskutkuje. Peter Bowman (dyskusja) 18:48, 10 kwi 2020 (CEST)

Ikony kłódek wskazujące rodzaj dostępu

W Wikipedii zmieniono kolory kłódek oznaczające rodzaj dostępu do jakiegoś źródła internetowego, argumentując m.in., że pomarańczowa kłódka oznacza bardzo określony typ dostępu, nie po prostu bezpłatność, a poza tym działa dość ostrzegawczo (w przeciwieństwie np. do zielonej), bo jest bliska czerwieni. Poza tym rozróżnia się tam więcej typów dostępu, czego w Wikisłowniku nie ma (np. „dostępne po bezpłatnej rejestracji”). Nie wiem, czy ta kwestia kogokolwiek interesuje, bo chyba kłódki zostały wprowadzone w ogóle na zasadzie milczącej zgody, ale na wszelki wypadek sygnalizuję. Wydaje mi się, że w Wikisłowniku kłódki są na tyle zautomatyzowane, że ewentualna zmiana nie wymagałaby wiele zachodu. Maitake (dyskusja) 13:39, 25 mar 2020 (CET)

O ile się nie mylę, za kłódki odpowiadają u nas wyłącznie „szablon:otwarty dostęp”, który następnie jest użytkowany przez ok. 100 różnych szablonów źródeł (choć wydaje mi się, że teoretycznie mógłby być również w innych (np. przy PIVonline - ponoć istnieją plany zastosowania tam licencji CC, acz do tej pory… wiadomo że posiadaczem praw jest SAT) oraz „Szablon:paywall” wykorzystywany przez 3. Zdaje się, że sama podmiana + utworzenie nowych kategorii zajęłaby względnie niewiele czasu i osobiście byłbym tutaj na tak. Gorzej natomiast z ich zastosowaniem. Co do źródeł o dostępie zamkniętym z głowy byłbym gotowy wymienić USJP, dostępny niegdyś dzięki wikigrantom. Nie mam natomiast najmniejszego pojęcia czy posiadamy w szablonach cokolwiek o innym stopniu dostępu, ani czy niektóre z już obecnych nie powinny zostać oznaczone jako wolnodostępne (większość na ten moment jest „bez-ikonowa”). Podsumowując: jak dla mnie brzmi dobrze, acz może to być rzadko użytkowane :) Pozdrawiam ThelmOSO (dyskusja) 22:34, 28 mar 2020 (CET)

Dodałbym jeszcze (nawiązując do wspomnianej dyskusji Wikipedian), że nie jestem całkiem przekonany co do użycia ikon opartych o logo utworzone przez PLoS (). Skoro nie będziemy w pełni oddawać znaczenia różnych kategorii dostępu (golden, green etc.) to może lepiej, by ikony się z nimi zbytnio nie kojarzyły? Zamiast tego np. kłódki wypełnione jak ? Niestety wymagałoby to ich przygotowania… ThelmOSO (dyskusja) 23:09, 28 mar 2020 (CET)

W sumie przygotowanie tych ikon nie było specjalnie skomplikowane :)

Ikony

Obecnie	Propozycja	Wikipedia (i propozycje)
		(, , , , , )
–	/ /	(, , , , , )
–	/ /	(, , , , , )
		(, )
–	, ,

Podsumowanie propozycji. Osobiście promowałbym wersję „pełnych ikon” (by uniknąć nadmiernych skojarzeń z logiem PLoS i otwartego dostępu w ścisłym znaczeniu i rozróżnieniu) w tym czerwonej i zielonej (barwy bardziej intuicyjne). Ewentualnie dowolnych przy zachowaniu tych kolorów, lub chociaż zieleni dla publikacji bezpłatnych. Co do pozostałych to powiedziałbym, że są potrzebne raczej średnio, choć w teorii zawsze mogą się przydać. Szczerze wątpię natomiast czy ktokolwiek miałby czas i siły na weryfikowanie „klas wolnego dostępu” danych źródeł, zdaje się to być dość uciążliwe i niezbyt proste… Czy jest to potrzebna zmiana pozostawię innym do rozważenia :) --ThelmOSO (dyskusja) 21:28, 1 maj 2020 (CEST)

na:tsik'o

"na:tsik'o" to słowo z języka zuni oznaczające "jelonka, młodego jelenia", ale jest problem z jego zapisaniem w Wikisłowniku, ponieważ na: przekierowuje na stronę wiki nauruańską, niby na hasło "tsik'o"; jak utworzyć żeby było dobrze? bo taka jest pisownia zuni--Stanko6 (dyskusja) 15:56, 13 kwi 2020 (CEST)

• Podlinkuję tylko zgłoszenie, które nie zostało wówczas (sześć lat temu) załatwione, a dotyczyło podobnej sprawy, mianowicie c:. Maitake (dyskusja) 17:02, 13 kwi 2020 (CEST)

• Typowy dwukropek (U+003A, „:”) jest znakiem przestankowym. Oprogramowanie MediaWiki interpretuje przekierowanie do innego projektu w zapisie „na:tsik'o”, jak wskazano wyżej. Z drugiej strony istnieje znak literowy drukropka (U+A789, „꞉”), który nie stwarza takiego problemu: „na꞉tsik'o”. W w:en:Colon (letter) opisano jego zastosowanie w różnych językach, w tym zuni. @Stanko6: czy takie rozwiązanie będzie odpowiednie? Jeżeli tak, dla spójności trzeba by przenieść hasła w Kategoria:zuni (indeks) z postaci zwykłego dwukropka na ten drugi. Ciekawe, czy inne projekty wiki postąpiły w ten sposób. Peter Bowman (dyskusja) 19:56, 13 kwi 2020 (CEST)

• Z tego co widać na ten moment pozostaje utworzyć listę haseł niedozwolonych z przyczyn technicznych… Ale może wprowadzić rozwiązanie mocno prowizoryczne? Np. zastosować „inny dwukropek” z kilku zapewnianych przez unicode (na꞉tsik'o - ten wariant jak widzę wybrał użytkownik Stanko6, na׃tsik'o, naːtsik'o). Oczywiście służą one do skrajnie innych rzeczy i zapewne spowoduje to rozliczne problemy z kodowaniem, kolejnością sortowania itp.… Jednak haseł takich przypuszczalnie nie byłoby wiele. Ponadto zakładam, że normy języka zuni nie określają iż ich dwukropek jest zapisywany konkretnie przez znak U+003A (podchodzi to raczej pod normy typograficzne, u nas łamane powszechnie względem cudzysłowu „” czy też wielokropka …). Co więcej wyszukiwarka, w tym przypadku, zdaje się znajdować tego typu wyniki (chyba?) jak należy, co jest w miare pomyślnym znakiem. Propozycja może nieco niepoważna, ale a nuż jest to jakieś rozwiązanie? Pozostaje również możliwość użycia rozwiązań zza granicy (przykład) czyli jeśli dobrze rozumiem, zabawę szablonami i nową przestrzenią nazw. Pozdrawiam, ThelmOSO (dyskusja) 20:24, 13 kwi 2020 (CEST) Oj, wybacz @Peter Bowman, konflikt edycji i chyba trochę zdublowałem twą wypowiedź ;)

• Jakby co, hasło "na:tsik'o" pokazuje się w podpowiedziach pod polem wyszukiwarki, gdy wpisujemy zwykły dwukropek, więc rozwiązanie się sprawdza (przynajmniej w wyszukiwaniu). Zan-mir (dyskusja) 11:37, 14 kwi 2020 (CEST)

• @Zan-mir: u mnie działa tak np. w przypadku „dome:da”, które jest teraz przekierowanien do hasła „dome꞉da”. Jeżeli wpiszę „dome:” w polu wyszukiwania, ukazuje się przekierowanie w podpowiedziach, a po kliknięciu trafiam na właściwą stronę. Gdy natomiast wpisuję „na:tsik'o” (zwykły dwukropek), podpowiedzi brak. Czy ustawiłeś inny tryb podpowiedzi w Specjalna:Preferencje#mw-prefsection-searchoptions (ja mam domyślny)? Peter Bowman (dyskusja) 14:10, 14 kwi 2020 (CEST)

http://pokazywarka.pl/3428fg/. W preferencjach mam "domyślne, zalecane". Zan-mir (dyskusja) 14:52, 14 kwi 2020 (CEST)

Dzięki, już widzę problem. Wyszukiwarka na stronie Specjalna:Szukaj domyślnie uwzględnia wyniki z przestrzeni głównej, ja jednak miałem wszystkie przestrzenie odznaczone – lista wyników jest w takim układzie mocno okrojona. Ten sam wybór wpływa na wyniki wyszukiwania w pasku górnym. Wybrałem „Szykaj w: Domyślne” (tu pojawia się „Główna”), potem „Zapamiętaj wybor (...)” i uruchomiłem wyszukiwanie, po czym ustawienie zostało zapisane w systemie. Peter Bowman (dyskusja) 15:12, 14 kwi 2020 (CEST)

Propozycja dodania pola "akcent" w hasłach

Zastanawiam, się nad tym, czy nie należy dorobić w hasłach pola dotyczącego akcentu. To by w szczególności się przydało w hasłach rosyjskich, gdzie akcent zaznacza się za pomocą kreseczek. Superjurek (dyskusja) 09:47, 24 kwi 2020 (CEST)

Akcent jest już od dawna podawany w sekcji odmiany. PiotrekD^DYSKUSJA 15:56, 24 kwi 2020 (CEST)

Porównanie zmian

Dlaczego od dzisiaj, gdzieś od wczesnego popołudnia, podczas porównywania zmian (to tzw. Różnice pomiędzy wersjami) czcionka wyświetlająca zmieniony fragment jest szeryfowa (to akurat nie jest złe), a przy tym dużo mniejsza niż wcześniej (to jest fatalne, dla mnie praktycznie nieczytelne). Maitake (dyskusja) 18:15, 29 kwi 2020 (CEST)

• (phab:T250393) Chyba deweloperom chodziło o użycie tej samej czcionki co w oknie edycji, tę można sobie zmienić w Specjalna:Preferencje#mw-prefsection-editing (Edytor > Styl czcionki w polu edycyjnym). Jutro zmiana zostanie wprowadzona w Wikipediach, przeczuwam protest i powrót do poprzedniego stanu. Peter Bowman (dyskusja) 19:41, 29 kwi 2020 (CEST)

  „Protest” Francuzów mnie rozbawił :). Podzielę się: C'est la fin du monde. Peter Bowman (dyskusja) 21:32, 30 kwi 2020 (CEST)

• Dziękuję. To by się zgadzało w odniesieniu do czcionki szeryfowej, bo taką mam ustawioną w polu edycji (nie lubię bezszeryfowej, bo niektórych znaków nie rozróżnia). Ale w polu edycji nie jest ona wcale taka maluśka, bez problemu ją czytam, a tu potrzebuję lupy. Zobaczymy, czy się to nieszczęście cofnie. Maitake (dyskusja) 20:15, 29 kwi 2020 (CEST)

  @Maitake: możesz dopasować wielkość czcionki wedle gustu, wstawiając poniższy kod do swojego common.css:

  .diff-editfont-serif .diff-addedline,
  .diff-editfont-serif .diff-deletedline,
  .diff-editfont-serif .diff-context {
  	font-size: 100%;
  }
  

  Domyślna wartość (taką przynajmniej widzę u siebie) to 88%, przy 100% wzwyż diff wygląda nieco lepiej. Peter Bowman (dyskusja) 03:45, 30 kwi 2020 (CEST)

• Dziękuję ogromnie, pomogło doskonale. Maitake (dyskusja) 12:36, 30 kwi 2020 (CEST)

Sposób wprowadzania tłumaczeń haseł

Czy istnieją jakieś plany odnośnie do wprowadzenia nowego sposobu dodawania tłumaczeń danego hasła, na wzór Wikisłowników niemieckiego, angielskiego i rosyjskiego? Przykładowo [12]. Prawdopodobnie odpowiada za to szablon Template:trans-top.

Szczecinolog (dyskusja) 15:24, 3 maj 2020 (CEST)

• @Szczecinolog: jeżeli chodzi o mechanizm wprowadzania (nie mówię o wizualizacji w zwijanych blokach), odpowiada za to kod napisany w języku JavaScript. Dobre kilka lat temu powstał u nas podobny gadżet (zob. „Dodaje formularz edycyjny pod polem tłumaczenia, umożliwiając edytowanie tłumaczeń bez konieczności przełączania na tryb edycji strony” w preferencjach, sekcja „Edycja”) niezależnie od rozwiązań przyjętych we wspomnianych projektach. Nie jest włączony domyślnie. Peter Bowman (dyskusja) 16:26, 3 maj 2020 (CEST)
• Oficjalnie wnioskuję o domyślne włączenie gadżetu dodawania tłumaczeń dla wszystkich, w tym niezalogowanych. To pozwala uniknąć wielu błędów technicznych i redakcyjnych, które zdarzają się podczas edycji, a absolutnie w niczym nie przeszkadza (jak ktoś nie chce, nie musi korzystać). Gadżet działa bez zarzutu, nie pojawiają się z nim żadne problemy, od dawna chyba żadne poprawki nie są też do niego wprowadzane. Maitake (dyskusja) 17:00, 3 maj 2020 (CEST)
  • Popieram powyższy wniosek :). Nostrix (dyskusja) 21:05, 3 maj 2020 (CEST)
  • Również popieram. PiotrekD^DYSKUSJA 19:36, 4 maj 2020 (CEST)
• Zajmuję się rozwojem i konserwacją tego narzędzia. Od czasu do czasu wprowadzam kolejne ulepszenia (przy czym serdecznie dziękuję zgłaszającym, którzy wykrywają problemy i dzielą się ze mną ich uwagami), aczkolwiek gadżet uzyskał już najważniejsze funkcje podstawowe. Przytaczam inne pomysły do wdrożenia: przycisk wyświetlający podgląd zmian (diff); oznaczenie pozycji na liście tłumaczeń, które ulegną modyfikacji po zapisaniu zmian (myślę o nowej ikonce w lewym marginesie obok nazwy języka); możliwość wprowadzenia dowolnego opisu zmian. W kontekście domyślnego włączenia narzędzia ta ostatnia pozycja wydaje się wręcz pożądana. Warto też zauważyć, że może wzrosnąć liczba stron oczekujących na przejrzenie. Peter Bowman (dyskusja) 04:18, 4 maj 2020 (CEST)
  • Testowanie narzędzia a jego rozbudowa to dwie różne rzeczy. Według mnie gadżet został przetestowany na wszelkie możliwe sposoby i wszystkie jego ewentualne błędy zostały poprawione, więc nie ma przeszkód, by go włączyć domyślnie. A udoskonalać można go nadal, tak jak i każde narzędzie w wikiprojektach. — Czy zachęcenie łatwiejszą edycją tłumaczeń dodatkowych osób do zaangażowania się w projekt to dobrze, czy źle, każdy sam sobie musi odpowiedzieć. Wandale ułatwień nie potrzebują, a utrudnienia ich nie zniechęcą. Natomiast zmniejszy się na pewno ilość wadliwych edycji wykonywanych w dobrej wierze, może przynajmniej odrobinę. Oczekiwanie na przejrzenie to problem nie do rozwiązania w żadnym wikiprojekcie, Wikipedia ma zaległości idące w tysiące i mimo różnych akcji raczej się one zwiększają, niż maleją. Z tym że tłumaczenia dodane gadżetem przejrzeć łatwiej (i szybciej), bo nie trzeba się skupiać nad detalami technicznymi (literówki w nazwie języka, dwukropek po nazwie, poprawne umiejscowienie na liście alfabetycznej, dwa nawiasy z przodu i z tyłu, numeracja znaczeń itp. itd.). Maitake (dyskusja) 17:19, 4 maj 2020 (CEST)
    O, choćby taka edycja, właśnie wykonana, z niepotrzebnym średnikiem na końcu. Nie wystarczy przejrzeć i zaakcpetować, trzeba wejść w edycję i usunąć. Maitake (dyskusja) 17:24, 4 maj 2020 (CEST)

Popieram wniosek @Maitake o domyślne włączenie gadżetu dodawania tłumaczeń dla wszystkich. Sama ze szkoleń wiem, jak pomocne jest to narzędzie - szczególnie dla początkujących, którzy przede wszystkim nie wiedzą o tym gadżecie, a nawet jak się dowiedzą, to nie od razu radzą sobie z jego odnalezieniem i uruchomieniem. Gadżet w działa sprawnie. Dodatkowe funkcje i ulepszenia oczywiście mile widziane, ale i w obecnej formie już bardzo dobrze spełnia swoje podstawowe funkcje. Pozdrawiam Krokus (dyskusja) 11:59, 5 maj 2020 (CEST)

• Skorzystałem z okazji, by przejrzeć kod i zrealizować zaległe pomysły, w tym te, o których pisałem wyżej. Większych zmian nie przewiduję – oprócz odświeżenia szaty graficznej na coś bardziej przyjaznego dla oka i bliższego w funkcjach i stylu interfejsowi wiki, jednak na razie zostawiam to na przyszłość. W najbliższych dniach włączę gadżet domyślnie dla wszystkich, więc jeżeli korzystacie z niego – @Maitake, @Nostrix, @PiotrekD, @Krokus – będę wdzięczny za wykonywanie edycji i sprawdzenie, czy po ostatnich zmianach wszystko jest w porządku. Następnie umieszczę opis narzędzia z prostą instrukcją w przestrzeni Wikisłownik. Peter Bowman (dyskusja) 19:28, 8 maj 2020 (CEST)

Hm…, był bardzo dobry gadżet do szybkiego dodawania tłumaczeń. Ale już nie jest. Jeszcze dodanie +/m/× na lewym marginesie jest jakoś tam pożyteczne, a w każdym razie nie przeszkadza, ale reszta zmian jest na gorsze:

1. Schowanie „przejdź / usuń / zmień” pod symbolem „(…)” jest bardzo nieintuicyjne, bo sugeruje, że dla każdego języka są jeszcze dodane jakieś dalsze tłumaczenia, które się nie wyświetlają („(…)” oznacza opuszczenie części tekstu). A już nieustające wyświetlanie się tych poleceń i chowanie, kiedy przejeżdża się myszką (a przy dłuższych listach nie sposób nie przejeżdżać), przyprawia o oczopląsy.
2. Różnica między „Zatwierdź” a „Zapisz” jest niezrozumiała, nieintuicyjna, wprowadza w błąd. Sam przy pierwszej edycji nie wiedziałem, co wcisnąć: „Zatwierdź” czy „Zapisz”, w przyszłości też się pewnie będę głowił.
3. Po wciśnięciu „Zapisz” pojawia się wielkie okno, w którym nie wiadomo, co wpisać (bo niby co można wpisać w opisie edycji poza tym, co bot sam wcześniej generował), no i znowu są trzy przyciski do wyboru i jeszcze jakiś tekst do czytania.

Przedtem był to mały, sprawny gadżet dodający w mgnieniu oka tłumaczenia, pozwalający uniknąć błędów technicznych. Teraz jest wielka, rozbudowana maszyneria, atakująca mnóstwem komunikatów, odstręczająca od używania (bo trzeba się tego bardzo długo uczyć), a nie wiem, czy nie szybciej jest wejść w edycję i dodać tłumaczenie ręcznie niż się przez to przedzierać. Takiego gadżetu to bym już domyślnie nikomu nie włączał, wnioskowałem o włączenie poprzedniej wersji. Lepsze jest wrogiem dobrego. Maitake (dyskusja) 13:34, 10 maj 2020 (CEST)

Dzięki, @Maitake. Omówię zmiany:

• Schowanie „przejdź / usuń / zmień” pod symbolem „(…)”: wydaje mi się, że ten element niepotrzebnie przeciążał obszar podglądu i odwracał uwagę od tłumaczeń, szczególnie w przypadku tych krótszych. Przygotowałem zestawienie: [13]. W pierwszym zrzucie widzimy stan obecny (swoją drogą symbol „(…)” nie powinien mieć taką samą wielkość czcionki jak tłumaczenia – to przeoczenie). W drugim mamy stary wygląd bez opuszczania tych trzech słów, stanowiących w ten sposób niemal połowę tekstu w obszarze podglądu. W trzecim proponuję zmianę symbolu „(…)” na „(edycja)” (wolałbym coś zbliżonego do ang. „actions”, lecz „akcje” nie brzmi dobrze). Wyświetlanie i chowanie można uruchamiać nie wskutek najechania kursorem na dowolne miejsce w wierszu tłumaczenia, lecz na ten element wyłącznie.
• Przycisk „Zatwierdź” brzmiał poprzednio „Pokaż zmiany”. Zmieniłem to, by wyrazić, że wpisanie tłumaczenia nie jest wystarczającym krokiem – narzędzie musi otrzymać polecenie, by zawartość pól została wprowadzona do wewnętrznej listy roboczej, która potem jest składana w całość i, w postaci wikikodu, zapisywana na serwerze. W tej myśli wydaje mi się teraz, że „Wprowadź” jest celniejszym sformułowaniem. Z drugiej strony naciśnięcie przycisku zawsze powoduje wygenerowanie podglądu – z punktu widzenia użytkownika nie ma znaczenia, jak działa gadżet wewnętrznie, więc chyba się wycofam z pierwotnego pomysłu. Rozważyłbym jednak formę „Pokaż podgląd” zamiast „Pokaż zmiany”, ponieważ taki przycisk widzimy w normalnym trybie edycji i jesteśmy do niego przyzwyczajeni, natomiast druga forma może przywoływać na myśl (nową) funkcję porównania zmian (tzw. diff). Propozycje: „Pokaż podgląd” (ku tej się skłaniam), „Pokaż zmiany” (jak dawniej), „Wprowadź”, inne.
• Komentarz do powyższego: zamierzam wprowadzić dymki do wszystkich przycisków, zwięźle opisując ich przeznaczenie. Chodzi o takie same dymki, jakie widzimy m.in. po najechaniu kursorem na przycisk zapisywania zmian w trakcie normalnej edycji; w interfejsie MediaWiki jest tego pełno.
• Dodanie +/m/× na lewym marginesie ułatwia stwierdzenie na pierwszy rzut oka, które pozycje na liście tłumaczeń zostały zmienione w trakcie korzystania z narzędzia. Będąc przy tym, poszedłem o krok dalej, umożliwiając wygenerowanie porównania zmian przed/po – notabene nie da się inaczej wyróżnić zmian na językach, które już były na tej liście (co innego języki dodane lub usunięte). Ponadto narzędzie automatycznie wykonuje mniejsze poprawki, w tym prawidłowe umiejscowienie odstępów i sortowanie języków.
• Opis zmian jest podstawowym elementem normalnego trybu edycji, mimo że nie wymaga się jego wypełnienia. Ja odczułem brak tej możliwości szczególnie w następstwie wprowadzenia funkcji modyfikowania i usuwania tłumaczeń, więc przypuszczam, że taka potrzeba mogła zaistnieć u dowolnego użytkownika – w takiej sytuacji narzędzie zawiodło tłumacza, zmuszając go do zaniechania tej czynności albo przejścia na normalny tryb edycji. Uzasadnienie zmian jest pożądane, nawet gdy w większości przypadków to pole pozostaje puste. Gdy początkujący lub anonimowy edytor wprowadzi niepewną zmianę, co do której chcielibyśmy poznać uzasadnienie, wolałbym, żeby taka opcja istniała. W przewodniku wyraziłem zachętę do korzystania z tego pola, w duchu uzasadniania zmian na podstawie źródeł. Zmieniłbym obecny nagłówek „Opis zmian” na „Opis zmian (opcjonalny, wprowadzony tekst zostanie dołączony do wygenerowanego opisu)” czy coś w tym kierunku.
• Najważniejsze zostawiłem na koniec, uzasadnione zamiarem domyślnego włączenia narzędzia: interfejs powinien informować o warunkach użytkowania wkładu, czyli o licencji oraz zgodzie na wykorzystanie – wyrażonej przy zapisywaniu zmian. Tekst, o którym mowa, jest wyświetlany w normalnym trybie edycji tuż nad przyciskiem „Opublikuj zmiany”. Rozważyłem umieszczenie go w głównym interfejsie edytora tłumaczeń, tuż nad obszarem podglądu zmian, lecz domyślnie ukrytego ze względu na miejsce, które zajmowałby na ekranie. Tu pojawił się pomysł dwuetapowego zapisania zmian: pierwsze kliknięcie powoduje wyświetlenie pola do wprowadzenia opisu zmian oraz tekst z warunkami prawnymi, drugie zaś ostatecznie zapisuje zmiany. Alternatywnie nowy przycisk miałby powielać funkcje pozostawionego po staremu „Zapisz”, dodatkowo otwierając okienko do podania opisu zmian, a warunki prawne wymagałyby jednorazowego zaakceptowania. W zamyśle tak działa dziś wiele stron, uporczywie domagając się zaakceptowania ciasteczek. Ponieważ mogłyby się pojawić wątpliwości natury prawnej, a w praktyce nie wystarczy zaakceptować tylko raz ze względu na sposób działania ciasteczek, wdrożyłem nowe okienko dialogowe. Upiekłem trzy pieczenie na jednym ogniu (warunki, opis zmian i dostęp do podglądu) i uniknąłem przeciążania głównego interfejsu. Funkcje okienka przypominają tryb zapisywania zmian w Edytorze Wizualnym; przy okazji: w przyszłości chcę, by edytor tłumaczeń powielił jego wygląd.

Piszę przewodnik (WS:Narzędzia/Edytor tłumaczeń) dla korzystających z narzędzia; dzięki temu oraz dymkom z trzeciego punktu mam nadzieję, że jednak nie trzeba będzie się długo uczyć (?). Jeżeli coś nie jest jasne – proszę wskazać, to położę większy nacisk na udokumentowanie tego. Interfejs można tak napisać (tekst w nim wyświetlany), by elementy same wyrażały ich właściwe przeznaczenie. Dostosuję narzędzie do potrzeb, jednak proszę zauważyć, że uwzględniając wymogi oraz nowe funkcje, obecne rozwiązanie wydało mi się najsensowniejsze. W mojej opinii gadżet nadal działa sprawniej niż zwykły tryb edycji. W tym trybie należy zlokalizować odpowiedni fragment w wikikodzie, uważać na błędy techniczne i przejrzeć dokonane zmiany. Sumienny użytkownik zawsze sprawdza podgląd, więc ta ostatnia czynność wymaga przeładowywania i przewijania strony – prawdopodobnie wiele razy. Gadżet, kosztem dodatkowego kliknięcia względem poprzedniej wersji, podaje to wszystko użytkownikowi na ekranie. Proszę o opinie. Peter Bowman (dyskusja) 19:23, 10 maj 2020 (CEST)

• • W takim razie wnioskuję, aby absolutnie nie włączać gadżetu domyślnie, a za to cofnąć go do wersji z 3 maja 2020 roku. Wtedy działał doskonale, a teraz jest tylko przeładowaną zabawką, wcale nie przyspieszającą edycji. Kichał pies niezalogowanych, i tak więcej edycji wykonują osoby mające konto, a te mogą sobie włączyć gadżet w preferencjach (i wtedy zaświadczyć własną krwią, że cośtam-cośtam-cośtam, czego wymagają jakieśtam przepisy – raz i na zawsze, a nie przy każdej edycji). W takiej formie się to do niczego nie nadaje, jest co najwyżej podręcznikowym przykładem, jak spieprzyć coś bardzo dobrego, ulepszając to na siłę. Maitake (dyskusja) 19:44, 10 maj 2020 (CEST)

• Zgadzam się, teraz jest przekombinowane. Jeśli przy każdym dodanym tłumaczeniu mam wyrażać nieodwołalną zgodę na przetwarzanie mojego wkładu, to lepiej niech to będzie jako gadżet tylko dla niektórych. Przekombinowane. Dramat. Nie. Sorry. To miało uprościć dodawanie tłumaczeń. Zan-mir (dyskusja) 19:56, 10 maj 2020 (CEST)
• Pod względem użytkowym jest trochę gorzej niż było. Mnie osobiście przeszkadza użycie dodatkowego ekranu do potwierdzania zmiany. To spowalnia cały proces dodawania tłumaczenia. Chciałbym dodawać tłumaczenia w obrębie jednego formularza. PS. Jeśli akcje nie brzmi za dobrze, bo nie brzmi, to można to nazwać "działania". Okcydent (dyskusja) 20:12, 10 maj 2020 (CEST)

  Dziękuję bardzo za konstruktywną opinię, @Okcydent. Przywróciłem możliwość wysłania zmian po bezpośrednim kliknięciu na „Zapisz”. Zachowałem na razie ten niechciany tryb okienkowy, dla porównania. Domyślnie powinien się załadować tryb bezpośredni, w przeciwnym wypadku przycisk koła zębatego obok „Zapisz” steruje wyborem pomiędzy trybami. Peter Bowman (dyskusja) 05:56, 12 maj 2020 (CEST)

O ile dodanie jakiegoś małego okienka opisu u dołu wydałoby mi się sensowne, o tyle obecna forma tego gadżetu z tym dużym oknem potwierdzenia wydaje mi się faktycznie mocno przekombinowana. @Peter Bowman: Bardzo cenię sobie to, że chce Ci się wspierać Wikisłownik swoją pracą nad technikaliami (czymś, czym mnie się nie chce zajmować), ale jeśli za najważniejszy element tego gadżetu mamy uważać zgodę prawną na przetwarzanie danych, to może faktycznie lepiej, by tego gadżetu nie było. Ja wiem, że żyjemy w czasach prawniczej biurokracji, ale czy ten element jest naprawdę konieczny? Celem tego gadżetu jest dodawanie jednego słowa lub kilku słów na podstawie relacji występującej miedzy dwoma językami w świecie rzeczywistym, prawdopodobnie opisanej już w słownikach. Jakie wątpliwości natury prawnej mogłyby się tu pojawić? A jeśli ta klauzula jest konieczna, to niech będzie w formie jednego krótkiego zdania zapisanego malutką czcionką u dołu formularza, nie w formie wyskakującego okienka. (Tyle dobrze, że nie ma tam jeszcze checkboxa „zapoznałem się z warunkami licencji i akceptuję jej postanowienia”… albo całego kwizu ze znajomości licencji). PiotrekD^DYSKUSJA 21:58, 11 maj 2020 (CEST)

@PiotrekD: zgodnie z moją wiedzą i zdrowym rozsądkiem ten element naprawdę jest konieczny, a pominięcie go byłoby nieostrożne, nielegalne i nieetyczne. Pisałem wyżej: ten sam tekst wyświetlany jest w trakcie normalnego trybu edycji zaraz nad przyciskiem „Opublikuj zmiany” i jest wprost mało prawdopodobne, że kiedykolwiek uświadczyłeś jego braku w trakcie zapisywania nawet najdrobniejszej zmiany w jakimkolwiek projekcie Wikimedia, w tej lub innej formie (np. Wikidane korzystają z licencji CC0). Pomijam fakt, że bez tej klauzuli takie projekty nie mogą istnieć. Zauważ następnie, że zmianę wprowadzam w kontekście domyślnego włączenia gadżetu dla wszystkich odwiedzających Wikisłownik. Po pierwsze, byłoby wysoce nieodpowiedzialne, gdybym zwrócił uwagę Wikimedia Legal z tego powodu. Po drugie, nie zwalnia to od wszechobecnej możliwości spersonalizowania wyglądu/zachowania elementów interfejsu. Kto nie chce oglądać komunikatu, niech sobie wpisze poniższy kod do swojego common.css:

.editpage-copywarn { display: none; }

W zasadzie taka prosta czynność powinna rozwiązać sprawę (?). Zarówno tu, jak i w stoliku technicznym Wikipedii czasem proponuję podobne rozwiązania i zapewniam, że nie mam zamiaru siłowo uderzać po oczach niechcianym elementem interfejsu. Mogę zrozumieć, że kwestie prawne budzą animozje (przeświadczenie o życiu w świecie „prawniczej biurokracji” oraz ironia o kwizie), lecz ja proszę o zrozumienie, że nie jest to wymysł, lecz ostrożność i w sumie raczej dobrze, że ktoś dba o ten aspekt.

Wydaje mi się sprzeczne, że w tym samym zdaniu zestawiasz uznanie za moją pracę (dziękuję) oraz stwierdzenie, że to narzędzie nie powinno istnieć z tak prozaicznego powodu. W 2014 napisałem prosty skrypt, by ułatwić sobie dodawanie tłumaczeń. Odkąd podzieliłem się nim, przestałem go pisać „dla siebie” i w rezultacie kod rozrósł się dziesięciokrotnie. Nie wiem, czemu odpowiedzią na moje przygotowania do zrealizowania powyższych wniosków ma być, w pierwszym ogniu, spisanie gadżetu na straty. W takim układzie szkoda pracy. Peter Bowman (dyskusja) 22:55, 12 maj 2020 (CEST)

• Nadal jest fatalnie. Przy przesuwaniu myszką można dostać oczopląsu od wyświetlających się i chowających poleceń przy każdym tłumaczeniu (poprzednia wersja z trzema poleceniami wyświetlającymi się na stałe była o niebo lepsza, nic tu niczego nie przeciążało). Komunikat wyświetlający się przy najechaniu na Zapisz jest całkowicie zbędny (zwłaszcza w tym miejscu), za duży, za agresywny, kolejny atakujący edytora element. Jeśli ten głupkowaty tekst koniecznie musi się gdzieś wyświetlać, niech się wyświetla na stałe albo u samej góry (nad polem edycji tłumaczeń), albo u samego dołu (pod listą tłumaczeń), ale niech niech skacze jak poparzony w najważniejszym miejscu. No i przede wszystkim powinien się wyświetlać petitem, a nie taką wielką czcionką. (Na podstawie tego rozwiązania można powoli diagnozować zarażenie wirusem dymkozy – wszędzie dymki, wszędzie coś się musi ruszać, wyskakiwać i chować.) Zapisywanie tłumaczenia też trwa znacząco dłużej niż poprzednio, nie mam wątpliwości, że to przez zupełnie niepotrzebną, a wręcz szkodliwą rozbudowę gadżetu. Podtrzymuję sprzeciw wobec włączania domyślnego tej wersji gadżetu, ta z początku maja było nieporównanie lepsza. Maitake (dyskusja) 11:40, 12 maj 2020 (CEST)

  @Maitake: pisząc kod, mam dobre powody, by uznać wybrane rozwiązanie za lepsze od innych. Znam kilka sposobów, by kwestię wyświetlania i chowania poleceń złagodzić lub obejść i bardzo chętnie je przedstawię i przedyskutuję. Podstawą dyskusji jest skonfrontowanie opinii programista vs. użytkownik; zwykle mówi się na to feedback. Jeżeli natomiast odpowiedzią na moje propozycje ma być opryskliwa skarga na aktualny stan rzeczy bez konkretnych odniesień do tego, co jako autor narzędzia mam do powiedzenia, stawia mnie to w sytuacji bez wyjścia – po prostu zrobię, co uznam za stosowne. O zmianach uczciwie uprzedzałem i w odpowiedzi (początkowo) okazałeś zrozumienie. Poprosiłem o opinię już po wprowadzeniu zmian i otrzymałem konstruktywną krytykę od Okcydenta, która szybko przełożyłem na konkretne rozwiązanie. Sorry, dla mnie Twój wybuch i rzekome „spieprzenie zabawki” nie jest przyczynkiem do zaniechania wszystkich zmian, bo tak nie posuwamy się do przodu – zresztą nie wiesz, ile rzeczy w niej przy okazji poprawiłem i usprawniłem. A konkretnie gdybym dostał normalną odpowiedź co do tego ukrywania i chowania elementów, już wczoraj mógłbym wdrożyć rozwiązanie (skoro uważasz, że nie przeciąża, to OK).

  Co do „głupkowatego tekstu” zob. moją powyższą odpowiedź dla Piotrka. Nie wiem, co odpowiedzieć na temat dymków, sam odnosiłeś się raczej pozytywnie w WS:Bar/Dyskusje ogólne#Nowy gadżet – szybki podgląd definicji. Dla mnie to kolejny środek dostępny w razie potrzeby, lecz nie jedyny. O zapisywaniu mogę powiedzieć, że kod jest niemal taki sam względem wersji poprzedniej i nie ma prawa wydłużać czasu oczekiwania, chyba że wliczamy w to czas przeładowywania strony (zależny od komputera, łącza itp.). Zmieniło się tylko to, że wcześniej tekst przycisku „Zapisz” zmieniał się na „Zapisywanie” oraz „Przeładowywanie”, mogąc sprawiać wrażenie, że proces posuwał się szybciej (taki był zresztą zamiar).

  Na razie nie ma uzasadnienia, by nie włączać gadżetu domyślnie zgodnie z oryginalnym wnioskiem. Chcę zauważyć, że atutem miało być „uniknięcie wielu błędów technicznych i redakcyjnych”, przy czym „zmniejszy się na pewno ilość wadliwych edycji wykonywanych w dobrej wierze”, a „jak ktoś nie chce, nie musi korzystać” – obecna wersja nadal spełnia te założenia, nawet radząc sobie lepiej z błędami technicznymi. Teraz wniosek odwrotny można by odczytać: nie podoba mi się, że gadżet przestał działać po mojej myśli, więc nie chcę, by kto inny mógł z niego korzystać, a ponadto nagle „kichał pies niezalogowanych”. Proszę mnie poprawić. Peter Bowman (dyskusja) 00:09, 13 maj 2020 (CEST)

Szanowny Panie, gdy składałem wniosek, gadżet wyglądał zupełnie inaczej i funkcjonował znacznie lepiej. Wszystkie zarzuty wobec jego obecnej wersji wymieniłem powyżej, nie wiem, po co miałbym je znowu powtarzać. To, że je Pan ignoruje, to Pański problem, nie mój. Nie uważa Pan moich uwag za konstruktywne, bo Pan zwyczajnie nie chce, a w moich wpisach jest najwięcej konkretów ze wszystkich wypowiadających się w tej dyskusji. — Mógł Pan zaraz po moim wniosku napisać, że włączenie domyślne będzie wymagało sporych zmian, w tym znacznie utrudniających korzystanie, a wtedy natychmiast bym wniosek wycofał, bo gadżet był ogromnie pomocny. Ale Pan wolał wprowadzać kolejne zmiany, w tym tak negatywnie wpływające na stronę wizualną, że trudno to inaczej opisać, niż ja to zrobiłem. Naprawdę mam kolejny raz pisać o tych migających napisach, o nadmiarze dymków (nie mam nic przeciwko dymkom, chodzi o ich ilość i rzeczywistą potrzebę ich użycia – a nie stosowanie tylko dlatego, że można)? Jeśli uważa Pan, że wniosek złożony w sprawie wersji diametralnie różnej od obecnej nadal można uznać za ważny, to jest to ogromna manipulacja, choć nie sądzę, żebym był w stanie Pana przekonać. Pisze Pan, że teraz to Pan może przedyskutować – a dlaczego Pan tego nie przedyskutował, zanim Pan zaczął zmiany wprowadzać. Wtedy uważał Pan, że wie Pan lepiej i nie ma się co zdaniem innych przejmować. A teraz po wprowadzeniu zmian, które należałoby po prostu wycofać, nagle nawołuje Pan do dyskusji. Ja nie wspominałem początkowo o niczym poza poprawą błędów i ewentualnym wprowadzaniu nowych funkcjonalności. Ale Pan wolał funkcjonalność obniżać, stawiać kolejne przeszkody podczas korzystania z gadżetu (kolejne okienka, kolejne przyciski – zresztą niezgadzające się nazwą: wciskam Zapisz, wcale nie zapisuje, tylko otwiera nowe okno; dalej chcę zapisać, ale nie ma już przycisku Zapisz, tylko Wyślij; po wciśnięciu Wyślij, pojawia się na krótko komunikat Zapisywanie, a dlaczego nie Wysyłanie? itd. itd.). — I jakoś nie widzę nikogo, kto by był z wprowadzonych przez Pana zmian zadowolony, natomiast trzy osoby wypowiedziały się negatywnie. Jeśli Pan chce zepsuć gadżet do końca, śmiało. Proszę tylko, żeby dało się go w swoich ustawieniach wyłączyć. Mnie się płakać chce, jak widzę, jak to teraz wygląda… Maitake (dyskusja) 00:35, 13 maj 2020 (CEST)

Odniosłem się do zarzutów (opisując szerzej co, jak i dlaczego) 19:23, 10 maj 2020 (CEST) i wyraziłem, że dostosuję narzędzie do potrzeb użytkowników. W odpowiedzi dostałem tylko stwierdzenie, że wszystko zostało „spieprzone” i trzeba rewertować. Owe zarzuty pojawiły się po tym, jak 19:28, 8 maj 2020 (CEST) otwarcie prosiłem o wyrażenie zdania (co ponownie zrobiłem w odpowiedzi na nie). Zmiany, co do których uprzedzałem jako pożądany dodatek w obliczu domyślnego włączenia gadżetu, były wprowadzane ze świadomością, że może trzeba będzie je jeszcze (mocno) dopracować. Obecnie uwagi o dodatkowym okienku, przycisku „Wyślij” itd. są od wczoraj nieaktualne. Z listy zarzutów pozostają migające napisy, które wkrótce przestaną migać (choć szkoda, że nie możemy rozważyć innych opcji), i dymek, który może być, jak piszesz, notką przed lub pod szarym polem edytora. Po zmianach całość może wyglądać tak (jeszcze to pole do edycji opisu zmian mogłoby być domyślnie widoczne, żeby zachęcać do wskazania źródeł). Zapodziało mi się pole wyboru „Obserwuj”, dawniej pod „Zapisz”, jednak wydaje mi się, że i tak niepotrzebnie powielał funkcję gwiazdki obok „Wyświetl historię”. Oprócz tego nie widzę obniżenia funkcjonalności; czy coś mi umyka? Peter Bowman (dyskusja) 05:56, 13 maj 2020 (CEST)

Co z tego, że Pan wyraził, że się Pan dostosuje, skoro trzy komunikaty ukryte teraz pod + koło każdego tłumaczenia nadal migają. Zgłosiłem to w swoim pierwszym wpisie (13:34, 10 maj 2020) i potem jeszcze raz (11:40, 12 maj 2020), ale Pan to zignorował i nadal Pan ignoruje, bo cały czas miga. Zamienił Pan wielokropek na działania, potem działania na +, byle tylko nie poprawić tego, co ja zgłaszałem, czyli nieustającego migania. — Dodany głupkowaty tekst (proszę się zastanowić, co naprawdę znaczy Wyrażasz zgodę na wykorzystanie Twojego wkładu w dowolnej formie, pod warunkiem podania przynajmniej hiperłącza lub adresu URL do strony, na której powstała treść. w kontekście przykładów w Wikisłowniku zaczerpniętych ze stron internetowych – jaki to adres trzeba podać? gdzie treść powstała?) proponowałem wyświetlać u samej góry lub u samego dołu i do tego dużo mniejszą czcionką (11:40, 12 maj 2020), ale nadal dymkuje i nadal wielką czcionką. No ale ta uwaga przecież „nie jest konstruktywna”. Poza tym analogiczne urządzenie w niemieckim Wikisłowniku obywa się doskonale bez takiego tekstu (nawet dla niezalogowanych, i to od ładnych paru lat), więc usiłuje Pan być świętszy od papieża. — Jedna uwaga Okcydenta (dotycząca dodatkowego okienka) jest konstruktywna, a moich siedem (miganie, nieintuicyjne nazwy przycisków, dodatkowe okno, zwolnienie edycji, położenie wiadomego komunikatu, wielkość czcionki tegoż, zbyt wiele dymków) to „tylko stwierdzenie, że wszystko zostało „spieprzone” i trzeba rewertować”. No, zaiste, bo to moje uwagi… Maitake (dyskusja) 10:47, 13 maj 2020 (CEST)

Odwracanie kota ogonem: blisko 7 kB tekstu to nie jest ignorowanie Ciebie, okazałem Ci uwagę i odpowiedziałem rzeczowo, w zamian zaprzepaściłeś dalszą rozmowę stwierdzeniem o „spieprzeniu”, nie dopuszczając innej drogi niż rewert. Zacytowany tekst licencji oznacza, że osoba wykorzystująca treść Wikisłownika powinna podać bezpośredni URL do strony, gdzie dana treść się znajduje; cytowanie przykładów wewnątrz Wikisłownika to odwrotna sytuacja. W enwiktionary również zastanawiano się, czy komunikat powinien tam być. Ustalono (2010), że w przypadku narzędzi JS jesteśmy w szarej strefie, lecz wskazanie warunków licencji to „good practice”. Umacnia to moje zastrzeżenia i tak też chcę postąpić – przezornie, zanim ktoś przyjrzy się dokładniej i stwierdzi, że brakuje takiego komunikatu. Narzędzie w dewiktionary jest adaptacją tamtego. Za pomysł przeniesienia tesktu na gorę lub dół dziękuję, wyżej wstawiłem link do zrzutu z możliwym wynikiem takiego rozwiązania plus migających (już nie) elementów i zamierzam te zmiany wprowadzić – czy są zatem jakieś dalsze uwagi? Peter Bowman (dyskusja) 15:12, 13 maj 2020 (CEST)

Nie, nie ma żadnych uwag. Poza smutną konstatacją, że robi Pan dokładnie to, o co wnosiłem na początku: rewertuje Pan wygląd gadżetu i sposób korzystania z niego do wersji z początku maja. Czyli przyznaje Pan, że pierwsza „poprawiona” wersja była zwyczajnie spieprzona. — A o uwadze mi poświęcanej miałem się okazję przekonywać przez cztery lata. Dziękuję uprzejmie za taką uwagę. Maitake (dyskusja) 15:19, 13 maj 2020 (CEST)

Wprowadziłem zmiany; te dwa konkretne elementy przypominają teraz wersję z początku maja, reszta zmian zachowana. Dokończę pisanie przewodnika i włączę gadżet domyślnie, jeżeli nie będzie więcej zastrzeżeń. Peter Bowman (dyskusja) 05:01, 14 maj 2020 (CEST)

W tym momencie powinniśmy dopiero zacząć zbieranie uwag na temat zmian i propozycje ewentualnych poprawek wyglądu bądź funkcjonalności gadżetu, bo pewne rzeczy ja na przykład dopiero teraz widzę (przestały wreszcie migać). Ale rozumiem, że Pan zadecydował inaczej, więc proszę robić wszystko na własną odpowiedzialność. Ja nadal jestem przeciwny włączeniu, ale tym się Pan nie zamierza przejmować, jak Pan napisał wyżej. Władze polskie przyzwyczajają nas do takiego trybu działania już od pięciu lat, więc nie sądzę, żeby ktoś jeszcze protestował. Maitake (dyskusja) 11:02, 14 maj 2020 (CEST)

Ależ ja tylko informuję o zamiarach, żeby istniała możliwość reakcji i odniesienia się do moich zmian, a od zeszłego piątku zbieram oraz realizuję krytyczne uwagi. Nie wiem, co robią władze polskie, ja wręcz zachęcam do protestowania (teraz, nie po fakcie). Jeżeli w moim trybie pracy jest coś naprawdę nieodpowiedniego, a mogłem temu dać wyraz w tym wątku – przepraszam. Peter Bowman (dyskusja) 14:39, 14 maj 2020 (CEST)

Swoje dalsze uwagi wpisałem w nowym wątku poniżej. Ten wydaje mi się z kilku względów (m.in. długości) wart zakończenia. Na wszelki wypadek: sprzeciw wobec włączenia domyślnego wycofuję. Maitake (dyskusja) 10:45, 15 maj 2020 (CEST)

Gadżet został włączony domyślnie. Utworzyłem stronę opisu narzędzia, w tym przewodnik oraz stronę do zgłaszania błędów i uwag. Pozdrawiam, Peter Bowman (dyskusja) 05:08, 26 maj 2020 (CEST)

Komunikat MediaWiki

Komunikat "validationpage" ma od grudnia 2009 r. już przestarzałą wartość, gdyż strona Pomoc:Wersje oznaczone jest już w przestrzeni nazw "Wikisłownik". --Keyacom (💬 | 🖊) 21:33, 9 maj 2020 (CEST)

@Keyacom: można nadpisać wartość domyślną komunikatu albo utworzyć przekierowanie (strona Pomoc:Wersje oznaczone prowadzi do Wikisłownik:Wersje oznaczone), w 2009 wybrano właśnie drugie rozwiązanie. Chyba nie trzeba nic zmieniać, linki działają. Peter Bowman (dyskusja) 21:52, 9 maj 2020 (CEST)

@Peter Bowman: Wiem, że działa. --Keyacom (💬 | 🖊) 12:59, 10 maj 2020 (CEST)

Nie rozumiem zgłoszenia. Niekiedy projekty wiki wprowadzają własne wersje komunikatów systemowych, tworząc odpowiednią stronę w przestrzeni MediaWiki. Po latach lokalna wersja komunikatu może stać się przestarzała względem pierwotnego komunikatu, więc ten pierwszy należy usunąć, aby nie przesłaniał domyślnego. W ten sposób posprzątałem kiedyś wybrane komunikaty wyszczególnione na tej stronie (zaznacz „zmodyfikowane”). Wartość MediaWiki:Validationpage nie może być w tym sensie przestarzała, ponieważ ten komunikat nigdy lokalnie nie istniał. Peter Bowman (dyskusja) 19:36, 10 maj 2020 (CEST)

Propozycje niewielkich zmian redakcyjnych w gadżecie tłumaczeniowym

… do rozważenia po domyślnym włączeniu go dla wszystkich użytkowników.

1. Wydaje mi się, że pewne przyciski w gadżecie mogłyby mieć nazwy bardziej intuicyjne, obecnie nie są zrozumiałe na pierwszy rzut oka (choć wystarczy ich raz użyć, żeby się ich funkcji nauczyć). Obok każdego tłumaczenia wyświetlają się trzy przyciski: (przejdź) (usuń) (zmień), z których chyba tylko usuń jest jasny od początku. Zamiast przejdź (domyślnie chyba: przejdź do pola edycji, ale samo z siebie niejasne) proponowałbym edytuj, bo to jest to, co użytkownik może chcieć zrobić, a i tak po kliknięciu jest przenoszony automatycznie do pola edycji, więc to przejście jest jakby w jednym pakiecie z zamiarem edytowania. Dalej, zmień jest niejasne, bo nie wiadomo, co się chce zmienić, można pomyśleć, że zmienia to tłumaczenia już dodane, a chodzi o zmianę nazwy języka, gdy jest ona błędna. Całkiem jasne byłoby tylko zmień nazwę języka, ale jest za długie. Może lepsze byłoby samo język? Przynajmniej byłoby wiadomo, czego się ta zmiana tyczy.
2. Autor gadżetu uważa, że te trzy przyciski (przejdź) (usuń) (zmień) są ogółem zbyt długie i warto by je ukryć. To zależy na pewno od szerokości ekranu, mnie nie przeszkadza, ale na tablecie ustawionym w pionie bądź na telefonie może tak być (sam nie korzystam). Ukrycie tych przycisków pod jakimś wspólnym nagłówkiem mogłoby pomóc, ale ja jestem przeciwny automatycznemu rozwijaniu i chowaniu się tych poleceń podczas przejeżdżania myszką. Autor gadżetu wspomniał o możliwości rozwijania trzech poleceń po najechaniu na to coś, co nazwałem nagłówkiem, ale nigdy nie pokazał, jak by to miało funkcjonować, może byłoby akceptowalne. Niełatwo też ustalić wygląd takiego nagłówka: (…) sugeruje, że coś opuszczono, w tym kontekście opuszczono dalsze tłumaczenia, więc jest bardzo mylące; (działania)/(akcje) nie jest jasne, poza tym nadal długie; (+) może się mylić z plusem na lewym marginesie, więc też nie jest najlepsze. Ostatnio takie ukryte dalsze działania chowają się w różnych systemach i urządzeniach pod pionowym wielokropkiem, np. (⁞) lub (⋮), ale nie wiem, na ile to rozpowszechnione i zrozumiałe, poza tym może być zbyt wąskie dla klikającego. — Z drugiej strony, skoro może być koło zębate ustawień (było, teraz go nie ma, może będzie), to użytkownik byłby w stanie sobie ustawić, czy chce to mieć ukryte pod jakimkolwiek symbolem, czy też na stałe rozwinięte. Ale obecnie koła zębatego nie ma, więc to komplikuje sprawę.
3. Mnie osobiście przycisk Zapisz całkowicie odpowiada, ale podczas normalnej edycji strony nazywa się on teraz Opublikuj zmiany i wyświetla na niebiesko. Tu należałoby zebrać opinie, czy lepiej zostawić całkowicie jasne Zapisz, czy lepsze jest ujednolicenie obu sposobów edycji.

Poza tymi drobnymi propozycjami zmian uważam, że gadżet jest rewelacyjnym ułatwieniem pracy redakcyjnej i dziękuję ogromnie Autorowi za jego stworzenie. Maitake (dyskusja) 14:18, 14 maj 2020 (CEST)

Serdecznie dziękuję za zebranie tej listy, @Maitake, i za słowa uznania. Moje własne spostrzeżenia zostały trafnie przedstawione powyżej. Odpowiem na propozycje, wspomagając się zrzutami ekranu zebranymi na tej stronie (zrzut 1, 2), i na końcu proponując alternatywne podejście. Zrzut 1 odzwierciedla interfejs narzędzia przed napisaniem tego komentarza.

W pełni popieram zamianę przycisku (przejdź) na (edytuj) oraz (zmień) na (język). Przyznaję, że moje wyczucie w kwestii doboru słów i sformułowań odnośnie tesktu dla elementów interfejsu może czasem być dalekie od idealnego, dlatego mam znacznie wyższe zaufanie do opinii użytkowników narzędzia niż do mojej własnej. Ogólnie staram się oddać zbliżony sens tego, co dany element ma przedstawiać, wiedząc, że można go doszlifować w dowolnym momencie. Z tego powodu skłaniam się, by wykonać tę zmianę już teraz. W momencie pisania tego komentarza interfejs powinien wyglądać jak w zrzucie 2.

We wcześniejszym wątku wspomniałem pobieżnie kwestię dymków generowanych przez przeglądarkę – przykładowo powinien taki się pokazać po najechaniu kursorem tutaj. Należy odróżnić tego typu dymek (ang. tooltip) od wielkich dymków-okien (ang. pop-up), które wyświetlają się po najechaniu na dowolny numer znaczenia (również przez krótki czas z okazji ostatnich, wycofanych już przeróbek narzędzia, na przycisk „Zapisz”). Nawiązując do kwestii przejrzystości interfejsu podniesionej z okazji propozycji zmiany nazwy przycisku (przejdź) i temu podobnych, za pośrednictwem tych pierwszych dymków można dyskretnie podpowiadać użytkownikowi, do czego elementy tego interfejsu są właściwie przeznaczone. Wydaje mi się, że zmiana nie jest inwazyjna i tak będzie najprościej pokazać jej efekty, dlatego również wprowadziłem ją do narzędzia, na próbę (łatwo wycofać, więc proszę zgłosić, jeżeli nie jest dobrze). Odymkowane zostały wszystkie przyciski interfejsu głównego, czyli wykluczając okna dialogowe (np. przy zapamiętywaniu języka).

Rozwijanie przycisków (przejdź) (usuń) (zmień) było wywoływane za każdym razem, gdy użytkownik najeżdżał na wiersz tłumaczenia – co ważne, wliczając w to jego pusty obszar aż do prawego marginesu – zaś zwijanie następowało natychmiast po jego opuszczeniu. Alternatywnie można ograniczyć pole działania do samego nagłówka, czyli wymagając najechania na ten konkretny element, w ten sposób zmniejszając szansę na niezamierzone wywołanie efektu zwijania i rozwijania. Problem tego rozwiązania stanowią sytuacje, kiedy elementy (przejdź) (usuń) (zmień) łamią się na końcu wiersza tłumaczenia: kursor musiałby na krótką chwilę opuścić nagłówek, by zmienić pozycję, co jednak skutkowałoby niepożądanym zwinięciem przycisków. To z kolei można obejść na dwa sposoby: 1. wprowadzając drobne opóźnienie przed uruchomieniem zwijania, które byłoby wstrzymywane w razie powrócenia kursorem na owe przyciski; 2. rezygnując z mechanizmu automatycznego zwijania i rozwijania na rzecz metody pokaż/ukryj wywołanej przez kliknięcie (zamiast poprzez sam ruch kursora). Drugi pomysł odrzuciłem, bo to już w moim odczuciu za dużo klikania.

Skłaniam się ku tymczasowym zaniechaniu starań w tym kierunku, ponieważ w przyszłej iteracji narzędzia chciałbym skorzystać z biblioteki OOUI. Jest to zbiór ustandaryzowanych elementów interfejsu MediaWiki takich jak przyciski, okna dialogowe, pola wprowadzania tekstu itd. (pełna lista). Dla przykładu, obecne przyciski (przejdź) (usuń) (zmień) można by zamienić na zajmujące mniej miejsca i łatwe do rozpoznania ikony, natomiast ten niebieski przycisk „Opublikuj zmiany” widoczny w normalnym trybie edycji byłoby dość łatwo powielić w interfejsie edytora tłumaczeń. Gdy implementacja będzie gotowa, udostępnię chętnym osobny skrypt do testowania i poddam zmiany pod dyskusję.

Odnośnie przycisku „Opublikuj zmiany” chcę zauważyć, że dawniej brzmiał „Zapisz”, stąd inna możliwość to ujednolicenie w drugą stronę i powrót do poprzedniego status quo. W Wikipedii zresztą zdecydowano przywrócić stary przycisk po dyskusji (w:MediaWiki:Publishchanges).

Pozdrawiam, Peter Bowman (dyskusja) 22:10, 20 maj 2020 (CEST)

• @Peter Bowman: Bardzo dużo tego, trudno się do wszystkiego odnieść. Na razie mam tylko następujące propozycje co do małych dymków:
  1. Dla przycisku „Pokaż podgląd” jest Wprowadź tłumaczenia i wygeneruj podgląd na poniższej liście, a proponowałbym np. Wygeneruj podgląd wprowadzonych tłumaczeń na poniższej liście – formy rozkazujące w dymkach są poleceniami dla systemu, a tutaj Wprowadź… było chyba skierowane wyjątkowo do użytkownika. Ale to moje odczucie.
  2. Dla przycisku „Podgląd zmian” jest Wygeneruj diff dotychczasowych zmian względem pierwotnego stanu tłumaczeń, ale diff jest elementem wikislangu. Proponowałbym np. Porównaj dotychczasową wersję tłumaczeń z wprowadzonymi właśnie zmianami.
  3. A może by tak zamiast (edytuj) (usuń) (język) spróbować (e) (u) (j), skoro są małe dymki? Widziałem coś takiego przy szablonach nawigacyjnych w Wikipedii. Byłoby krótkie, nie trzeba by ukrywać, dymki wyjaśniają. Ale to wyłącznie luźna myśl, sam nie wiem, czy dobra, bo to jednak nieintuicyjne.
  Poza tym jestem za przyciskiem „Zapisz” wszędzie, gdzie to możliwe. Dla mnie to jest najbardziej intuicyjne. Ale niech pozostanie niebieski, to mi się podoba. (W Wikipedii był też ten problem, że można zmiany zapisać, lecz nie opublikować / upublicznić, bo jeśli zrobi to nieredaktor, bo nieprzejrzane strony są domyślnie niewidoczne. W Wikisłowniku to nie zachodzi.) — Wszelkie pozostałe zmiany w gadżecie wydają mi się dobre, na pewno pomagają, małe dymki w tej ilości nie rażą, bardzo dobre jest zwłaszcza leciutkie opóźnienie w ich wyświetlaniu. Nawet nie wiem, czy takie samo opóźnienie nie byłoby dobre także przy dużych dymkach, wyświetlających definicję słowa po najechaniu na numerek (a może ja za dużo jeżdżę myszką po ekranie?). Jednak postaram się jeszcze potestować, jeśli czas pozwoli. (Aaa, i sam się rozpisałem…) Pozdrawiam serdecznie, Maitake (dyskusja) 00:21, 21 maj 2020 (CEST)

  @Maitake: te uwagi są dla mnie nadzwyczaj pomocne, dziękuję ponownie. Wprowadziłem zmiany do obu dymków, po czym wracam jeszcze na chwilę do pierwszego. Wprawdzie ten Wprowadź tłumaczenia... miał być poleceniem dla systemu, jednak przyznaję, że efekt końcowy okazał się niejasny i w pewnej mierze przedobrzony. Polecenie miało się odnosić do wewnętrznej listy tłumaczeń (w formacie właściwym dla wygodnego odczytu przez maszynę), na podstawie której w tym samym kroku jest generowany podgląd na liście – stąd ten dwuczęściowy komunikat. Wagi pierwszej części miał nadać fakt, że póki użytkownik nie naciśnie na „Pokaż podgląd”, system nawet nie odczyta zawartości pól – nie wprowadzi tych tłumaczeń. Rozważałem też nad słowem zatwierdź, jednak brzmi zbyt finalnie, może przywołać na myśl ostateczne zapisanie zmian. Tak czy inaczej, wolałbym nie oczekiwać od użytkownika, że uważnie doczyta treść dymku i zrozumie ten niuans, lecz samo narzędzie zabezpieczy przed niechcianym wynikiem zapisania. Z jednej strony ostatni dodatek – opis zmian – wyraźnie podpowiada rezultat wysłania formularza. Z drugiej przycisk „Zapisz” i dwa sąsiadujące z nim są wyszarzone i nieaktywne do chwili, gdy pierwszy podgląd zostaje wymuszony przez użytkownika, więc przypadkowe zapisanie zmian w pierwszym podejściu jest niemożliwe. Za drugim, czyli po rozpoczęciu edycji kolejnego języka – owszem. Tę dziurę chcę załatać, wymuszając wstrzymanie akcji zapisywania i ostrzegając użytkownika przed niewprowadzoną zawartością w polach tłumaczeń – tu mam zamiar napisać w nowym komunikacie wprost, że należy kliknąć „Pokaż podgląd” i spróbować ponownie, a format ostrzeżenia podobny do wyświetlanego wskutek próby opuszczenia strony bez zapisania zmian.

  W kwestii skrócenia (edytuj) (usuń) (język) przygotowałem nowe zestawienie; podoba mi się przejrzystość listy tłumaczeń, lecz również nie mam pewności. Trzeba uwzględnić, że po kliknięciu na (usuń) pojawia się na jego miejscu (przywróć), zaś po kliknięciu na „Pokaż podgląd” na krótko miga opcja (wstrzymaj) (dostępna na wypadek zawieszenia się połączenia z serwerem). Może pojawią się inne głosy, w każdym razie pełna forma może zostać.

  Pokombinuję trochę przy przyciskach, więc do niebieskości „Zapisz” jeszcze wrócę. Opóźnienie w wyświetlaniu (małych) dymków jest całkowicie zależne od przeglądarki, zresztą podobnie jak ich wygląd; w każdym razie są identyczne do dymków, które wyświetlają się po najechaniu kursorem na dowolny link. Temat opóźnienia w przypadku dużych dymków poruszę chyba w osobnym wątku.

  Pozdrawiam serdecznie, Peter Bowman (dyskusja) 03:45, 21 maj 2020 (CEST)

  Wdrożyłem mechanizm, o którym wspominałem w pierwszym akapicie. Gdy wykonamy zmianę na pierwszym języku, wprowadzając ją do owej wewnętrznej listy poprzez kliknięcie na „Pokaż podgląd”, wtedy aktywuje się przycisk „Zapisz”. Jeżeli wpiszemy cokolwiek do pól tłumaczeń, po kliknięciu nań wyświetli się komunikat Ostatnie zmiany w tłumaczeniach na „nazwa_języka” nie zostaną zapisane. Wróć i przyciśnij „Pokaż podgląd”, aby je uwzględnić. Jest to proste zabezpieczenie, nakierowujące użytkownika w ramach przyjętego workflow narzędzia, nie mącąc poprzez objaśnianie w dymkach lub nazwach przycisków, co, jak i kiedy jest zatwierdzane. Peter Bowman (dyskusja) 17:47, 23 maj 2020 (CEST)

Ja tylko zaproponuję zmianę tekstów przycisku „Podgląd zmian” na zestawienie zmian lub lista zmian. Pokaż podgląd mogłoby być, choć nie musi, skrócone do samego podgląd. Okcydent (dyskusja) 14:45, 21 maj 2020 (CEST)

Dzięki, @Okcydent. Przycisk „Pokaż podgląd” jest nieco problematyczny w kontekście tego narzędzia, ponieważ wykonuje dodatkowe działania (zob. powyższe komentarze). Żeby było jasno, czego można oczekiwać, dobrałem nazwę z uwagi na podobny przycisk w interfejsie normalnego trybu edycji. Użycie formy rozkazującej stanowiło kryterium drugorzędne, dlatego w drodze wyjątku zdecydowałem się na „Podgląd zmian” – w tym przypadku robi dokładnie to samo, co podczas zwykłej edycji strony. „Zestawienie zmian” jest (odrobinę) długie, wraz z „Lista zmian” odbiega od kryterium form rozkazujących, a zestawienie nie jest listą – prędzej dwukolumnową tablicą. Dla porównania w edytorze wizualnym użyto „Skontroluj swoje zmiany”, jednak rozmieszczenie przycisku pozwala na dłuższe opisy. Peter Bowman (dyskusja) 17:47, 23 maj 2020 (CEST)

@Peter Bowman Zestawienie jest oczywiście dość długie. Rozkazujące „zestaw zmiany” jest ciut krótsze. Teraz mamy w dwóch kolejnych liniach „podgląd”, co utrudnia w rozeznaniu się na pierwszy rzut oka. Skoro nie lista, to może wykaz/spis zmian albo po prostu zmiany? Okcydent (dyskusja) 09:16, 24 maj 2020 (CEST)

O, o wykazie nie pomyślałem, dzięki. Moim pierwszym skojarzeniem dla wyrazu „zestaw” jest odczytanie go w kategorii rzeczownika jako „zestaw zmian”, jednak w otoczeniu pozostałych przycisków chyba można odruchowo wywnioskować polecenie. W nowym zestawieniu przedstawiam opcje: „Podgląd zmian” (obecnie), „Wykaz zmian”, „Zestawienie zmian”, „Spis zmian”, „Lista zmian”, „Zestaw zmiany”, „Pokaż zmiany”, „Wskaż zmiany”, „Pokaż różnice”. Moim „ale” względem „Zestawienie zmian” jest to, że w obliczu innych opcji ta niepotrzebnie dokłada pikseli w poziomie, więc w niektórych ustawieniach rozdzielczości ekranu czy powiększenia elementów na stronie może stanowić różnicę pomiędzy optymalnym rozmieszczeniem przycisków a ich przeskokiem na dół (wystarczy dostatecznie zmniejszyć szerokość okna przeglądarki, aby zauważyć ten efekt). Ponieważ wpływ dodatkowych pikseli tego jednego przycisku jest tylko jednym z wielu czynników składających się na osiągnięcie niepożądanego wyniku, który opisałem, ostatecznie uwzględniłem tę opcję w zestawieniu.

@Okcydent, @Maitake, czy macie szczególne upodobanie względem którejś lub którychś z tych opcji? Osobiście skłaniałbym się ku „Pokaż zmiany” lub „Pokaż różnice” (tryb rozkazujący, unika dwuznaczności słowa „podgląd”), jednak wszystkie uważam za akceptowalne. Peter Bowman (dyskusja) 15:11, 24 maj 2020 (CEST)

@Peter Bowman Akurat ten jeden przycisk jest o tyle ciekawy, gdyż nie powoduje zmian i działań na podglądzie tłumaczeń. Może nie być w trybie rozkazującym. Nie pasuje mi powielenie słowa podgląd w dwóch kolejnych liniach. Tak samo nie pasuje mi rozpoczynanie od słowa pokaż – wydaje się wtedy, że można je bez żadnej szkody opuścić. W związku z tym, że i tak otwieramy kolejne okienko z zestawieniem/porównaniem zmian to moje upodobania leżą w wykazie/liście i spisie zmian. Są dość jasne i dostatecznie różne od otaczających je przycisków. Okcydent (dyskusja) 15:25, 24 maj 2020 (CEST)

Wobec tego zmieniłem „Podgląd zmian” na „Wykaz zmian”. Dokończę pisanie przewodnika i w takiej formie włączę gadżet dla niezalogowanych (dalsze uwagi i propozycje są oczywiście mile widziane). Pozdrawiam, Peter Bowman (dyskusja) 16:07, 25 maj 2020 (CEST)

podgląd zmian

Czy poprawnie Wam działa przycisk podglądu zmian? Zan-mir (dyskusja) 07:32, 23 maj 2020 (CEST)

• @Zan-mir: U mnie w tej chwili działa bez zarzutu. Maitake (dyskusja) 10:40, 23 maj 2020 (CEST)
• @Zan-mir: czy chodzi o to, że zawartość okna edycji jest usuwana po przyciśnięciu na „Pokaż podgląd”? Zgłoszono podobny problem w w:WP:KT#Czyszczenie okna edytora przy włączaniu podglądu, nie mogłem ustalić przyczyny. Peter Bowman (dyskusja) 13:16, 23 maj 2020 (CEST)

  Chyba to samo w w:en:WP:VPT#Preview and Firefox. Ostatni komentarz sugeruje włączenie opcji „Pokazuj podgląd bez przeładowywania strony” w preferencjach edycji. Peter Bowman (dyskusja) 13:19, 23 maj 2020 (CEST)

Faviconka Wikisłownika w wersji mobilnej

W przeglądarkach mobilnych faviconka Wikisłownika wygląda dość dziwnie (po prawej). Pojawia się w przypadku dodania strony do zakładek, ulubionych lub stron startowych (w zależności od przeglądarki mobilnej). Testowałem rzecz na Androidzie, w przeglądarce Samsung Internet, Chrome i Opera ([14], [15], [16], [17]). Oczywiście w przeglądarkach desktopowych pojawia się prawidłowa favikonka. Szukałem odwołania do tego pliku na Commons u nas w MediaWiki, ale bez rezultatu. Czy problem jest gdzieś głębiej ukryty i należy zgłosić bug na Phabricator? Nostrix (dyskusja) 09:58, 27 maj 2020 (CEST)

Mam to samo na Androidzie+FF. Konfiguracja faviconek wersji mobilnej znajduje się w InitialiseSettings.php, zob. zmienną „wgAppleTouchIcon”. Społeczność angielskojęzycznego Wikisłownika zmieniła ją na c:File:Wiktionary-icon.png (phab:T48431), zaś w niemieckojęzycznym Wikisłowniku zarówno w wersji standardowej, jak i mobilnej mają tę samą ikonkę kafelki: [18] (phab:T202902). Peter Bowman (dyskusja) 16:57, 27 maj 2020 (CEST)

sortowanie w indeksach

Może ustawić bota do sortowania alfabetycznego w indeksach? Na razie brałbym pod uwagę tylko indeksy frazeologizmów. Niech bot po modyfikacji indeksu np. do 18:00 wieczorem sprawdza i sortuje pozycje. Zan-mir (dyskusja) 19:40, 27 cze 2020 (CEST)

@Zan-mir: bot może nie być najlepszym rozwiązaniem ze względu na niską częstotliwość edycji, ponadto takie zmiany powinny być sprawdzane. W zamian napisałem skrypt JS. Przejdź w tryb edycji wybranego indeksu, otwórz konsolę deweloperską (zwykle F12) i wklej ten kod:

importScript( 'Wikisłownikarz:Peter Bowman/sort-indexes.js' );

Pozdrawiam, Peter Bowman (dyskusja) 18:22, 16 lip 2020 (CEST)

Gadżet RTRC

Chciałem zaproponować dodanie do gadżetów w preferencjach narzędzia RTRC, służącego do patrolowania zmian w czasie rzeczywistym - strona z opisem na meta. Co ciekawe, narzędzie działa bez zarzutu u nas bez konieczności dostosowywania go do Wikisłownika, wystarczy więc w przestrzeni MediaWiki wstawić wywołanie do skryptu na meta, tak jak ja to zrobiłem w swoim js [19]. Nostrix (dyskusja) 09:16, 29 lip 2020 (CEST)

Narzędzie wydaje się w dużej mierze skupione wokół mechanizmu patrolowania, który u nas jest marginalny względem WS:WO (tylko administratorzy mają uprawnienei patrol) – stąd chyba integracja z CVN oraz ORES (u nas niedostępne). Zgłoszono brak obsługi wersji przejrzanych tutaj. W kwestii odświeżania listy zmian w czasie rzeczywistym warto wspomnieć, że klasyczne OZ zostały rozbudowane i teraz również wspierają tę funkcję, łącznie z filtrowaniem i podświetlaniem pozycji. Peter Bowman (dyskusja) 13:16, 6 sie 2020 (CEST)

Technical Wishes: FileExporter and FileImporter become default features on all Wikis

FileExporter i FileImporter staną się funkcjami standardowymi na wszystkich stronach wiki do 7 sierpnia 2020 r. Mają one pomóc autorom przenieść pliki z lokalnej wiki do Wikimedia Commons, zachowując jednocześnie wszystkie oryginalne informacje o pliku (Opis, Źródło, Data, Autor, Historia) nienaruszone. Dodatkowo przeniesienie jest udokumentowane w historii pliku. Jak to działa?

1. krok: Jeśli użytkownik jest automatycznie zatwierdzony, na stronie pliku lokalnego zobaczy link.

2. krok: po kliknięciu na ten link FileImporter sprawdza, czy plik można rzeczywiście przenieść do Wikimedia Commons. Te kontrole są wykonywane na podstawie pliku konfiguracyjnego, który jest tworzony i utrzymywany przez każdą lokalną społeczność wiki.

krok: Jeśli plik jest zgodny z Wikimedia Commons, nastąpi przejście do strony importu, na której można zaktualizować lub dodać informacje dotyczące pliku, takie jak opis. Można również dodać szablon “Now Commons” do pliku na lokalnej wiki, klikając odpowiednie pole wyboru w formularzu importu. Administratorzy mogą usunąć plik z lokalnej Wiki, zaznaczając pole wyboru. Kliknięcie przycisku na końcu strony powoduje import pliku do Wikimedia Commons.

Jeśli chcesz dowiedzieć się więcej o rozszerzeniu FileImporter lub o projekcie “Życzenia Techniczne”, kliknij na linki. --W imieniu zespołu “Życzenia Techniczne”:

Max Klemm (WMDE) 11:14, 6 sie 2020 (CEST)

nazwy indeksów

Chciałbym poruszyć może i poboczny, i drobny problem. Chodzi mianowicie o nazwy naszych indeksów. Wikisłownik powinien przejawiać dużą staranność zarówno w zakresie typografii, jak i ortografii. Tymczasem chyba od początku istnienia mamy dość dziwne nazwy indeksów. Bezpośrednio po wyrazie „Indeks” mamy dwukropek, a potem bez spacji dalszą część nazwy. Zgodnie z zasadami typografii po znaku przestankowym zawsze powinna być spacja. U nas w nazwach indeksów, nie wiedzieć czemu, jej nie ma. Po dwukropku mamy nazwę języka z wielkiej litery (bez wyrazu język), myślnik i znowu wielką literą nazwa indeksu. Te wielkie litery muszą być? Tak jest poprawnie? Może coś należałoby w tym zakresie zmodyfikować. Sankoff64 (dyskusja) 18:22, 8 sie 2020 (CEST)

Dwukropek oddziela przestrzeń nazw od tytułu. Pełni nieco inną (techniczną) funkcję niż dwukropek językowy, chociaż podobną. Nazwa indeksu to tak naprawdę to co po dwukropku. Wargo (dyskusja) 23:22, 8 sie 2020 (CEST)

Nie chodzi mi o wikikod, tylko o to, co widzi nasz Czytelnik. Mamy nagłówki indeksów i odesłania do indeksów w samych hasłach (w uwagach). Może to wyglądać tak, jak w haśle: górnik albo w sposób nieco zmodyfikowany, jak w haśle: на кожным кроку. Sankoff64 (dyskusja) 12:19, 9 sie 2020 (CEST)

Skrót w edytorze tłumaczeń (zapisywanie zmian)

Dziś dodałem obsługę skrótu klawiaturowego Ctrl+Enter, wywołującego zapisywanie zmian (i równoważnego kliknięciu na aktywny przycisk „Zapisz”). Pomysł zaczerpnąłem z Edytora Wizualnego. Jeżeli skrót jest nieodpowiedni lub kłóci się z innymi funkcjami przeglądarki bądź MW, proszę dać znać. Pozdrawiam, Peter Bowman (dyskusja) 16:16, 28 wrz 2020 (CEST)

ледено вино

Mechanizm wiki nie skleja znaków cyrylicy do wikilinku. Przykład w nagłówku tego hasła. Myślałem, że takie archaiczne problemy techniczne już nie występują, a tu niespodzianka. Grzegorz Wysocki (dyskusja) 23:34, 6 paź 2020 (CEST)

@Grzegorz Wysocki: to zależy od projektu, gdyż ustawienia są zazwyczaj dopasowane do języka. W polskojęzycznym Wikisłowniku skleja wyłącznie litery z alfabetu polskiego, w rosyjskojęzycznym i innych skleja cyrylicę itd. Tamto hasło poprawiłem. Pozdrawiam, Peter Bowman (dyskusja) 01:11, 7 paź 2020 (CEST)

Składające znaki diakrytyczne w nagłówkach

Czy da się poprawić wygląd nagłówków w takich hasłach jak "chax̂sax̂si-x̂"? Znaki składające nie składają się. Grzegorz Wysocki (dyskusja) 21:58, 7 paź 2020 (CEST)

Dodam, że w odróżnieniu od skórki Vector, czcionka skórki Timeless wspiera takie znaki (przynajmniej na Windowsie): [20]. Peter Bowman (dyskusja) 22:28, 7 paź 2020 (CEST)

Która skórka jest otwierana domyślnie? Którą skórkę widzą internauci? Grzegorz Wysocki (dyskusja) 23:44, 7 paź 2020 (CEST)

Łatwo sobie samemu odpowiedzieć na to pytanie. Wystarczy, że się wylogujesz, otworzysz okno w trybie incognito przeglądarki albo sprawdzisz w Specjalna:Preferencje#mw-prefsection-rendering – domyślną skórką jest Vector. Peter Bowman (dyskusja) 23:53, 7 paź 2020 (CEST)

AbuseFilter notice: rmspecials() will no longer remove whitespace when used in filters

Cześć,

Apologies if you are not reading this message in your native language. Pomóż przetłumaczyć na Twój język.

We are making a change to the AbuseFilter extension, which may impact the behavior of some existing filters. The rmspecials() function currently removes spaces in addition to special characters. We will change it such that it will only remove special characters. The existing rmwhitespace() can be used to remove spaces whenever applicable.

As reported on https://phabricator.wikimedia.org/P12854 we believe at least one filter on your wiki has been identified to use the rmspecials() function. Please consider updating these filters by wrapping rmspecials() inside rmwhitespace() like this: rmwhitespace(rmspecials(....))

We need you to update the relevant filters within 2 weeks of this notice. If one of the community members with proper access is volunteering to take this on, we ask them to please respond below and notify User:Huji in their response or in the edit summary. If we don't hear back from you within 2 weeks, Huji will edit the relevant filters on your wiki per the global abuse filter maintainer policy, to ensure the filters won't break once the change is implemented. Thank you for your consideration!

Best regards,

--User:Huji (dyskusja) 00:48, 27 paź 2020 (CET), sent via MediaWiki message delivery

PONS

Czy ktoś wie może, jak używać szablonu {{pons}}? Skategoryzowany jest on jako szablon źródeł dla angielskiego, niemieckiego, francuskiego, włoskiego, hiszpańskiego i rosyjskiego, i rzeczywiście wszystkie te języki strona internetowa PONS obsługuje. Jednak po użyciu w haśle odsyła tylko do słownika angielskiego i też w kodzie szablonu widzę wyłącznie „en”. Będę wdzięczny za pomoc. Pozdrawiam, Maitake (dyskusja) 17:16, 27 paź 2020 (CET)

@Maitake chyba zmienił się adres do wywołania poszczególnych języków w tym słowniku. Spróbuję pomóc niedługo jeśli wcześniej nikt się nie zgłosi, ale nie gwarantuję, że mi się uda. KaMan (dyskusja) 12:39, 28 paź 2020 (CET)

@KaMan, @Maitake Może coś takiego?

{{źródło
|tytuł=PONS.eu – Portal językowy
|hasło=[http://pl.pons.eu/tłumaczenie/{{{1|{{{1|angielski}}}}}}-{{{2|{{{2|polski}}}}}}/{{{hasło|{{PAGENAME}}}}} {{{hasło|{{PAGENAME}}}}}]
}}

Rozwiązałoby to problem, „hasło” byłoby nadal automatycznie pobierane z nazwy strony, chyba że uzupełniłby „hasło=” (domyślnie jako 3. argument). Argument 1 byłby automatycznie wypełniany jako „angielski”, a 2 jako „polski” a więc (mniej więcej) tak jak dotychczas. Nie jestem jednak pewien czy nie zostały gdzieś hasła które mogłyby w wyniku tej zmiany ucierpieć. Przykłady:

• {{pons|angielski|polski|castle}} i {{pons|castle}} daje nam: Hasło castle w: PONS.eu – Portal językowy.
• {{pons|polski|angielski|zamek}} daje nam: Hasło zamek w: PONS.eu – Portal językowy.
• {{pons|2=hiszpański|castle}} daje nam: Hasło castle w: PONS.eu – Portal językowy. Pozdrawiam, ThelmOSO (dyskusja) 20:36, 2 lis 2020 (CET)

Po jakimś konflikcie edycji:

• @ThelmOSO: Już chyba wiem, jak to działa. W obecnej wersji są już parametry, które można wskazywać, z tym że należy wpisywać kody ISO (en dla angielskiego jest domyślny, de dla niemieckiego, fr dla francuskiego itd.). Rezultat będzie taki sam, jak opisany wyżej z nazwami polskimi języków. Postaram się to opisać jako instrukcję w szablonie. Pozdrawiam, Maitake (dyskusja) 21:06, 2 lis 2020 (CET)

@Maitake: A działa w tym przypadku odsyłacz właściwie? Bo sprawdzałem też taką wersję, ale w wtedy w każdym przypadku poza „en” „pl”, link przenosił na główną stronę słownika (np. {{pons|1=pl|2=en|hasło=dom}} ->  Hasło „dom” w: PONS.eu – Portal językowy.), nie zaś do hasła i nie rozumiem zbytnio z czego to wynika. Może to jednak jakiś problem z mojej strony po prostu. Pozdrawiam, ThelmOSO (dyskusja) 00:22, 3 lis 2020 (CET)

• Dałem opis w szablonie {{pons}} wraz z przykładem dla słownika niemiecko-hiszpańskiego i tam bezpośredni link do hasła działa bez zarzutu. Wstawiłem też szablon do hasła Bevölkerung (wskazany tylko parametr 1 jako niemiecki) i też bez problemu tworzy się link do słownika niemiecko-polskiego. Dlaczego słownik polsko-angielski nie działa z tymi parametrami, co powyżej – nie wiem, przerasta mnie to. Maitake (dyskusja) 00:35, 3 lis 2020 (CET)

• @Maitake, @KaMan, @ThelmOSO: porzuciłem stary schemat URL opierający się na kodach ISO, przyjmując teraz krótką nazwę języka (czyli mniej więcej jak proponował @ThelmOSO, Specjalna:Diff/7518139). Według starego adresu kombinacja en-pl prowadzi do słownika polsko-angielskiego, lecz pl-en już nie działa – słownik polsko-angielski jest osiągalny też jako en-pl, o ile w URL wskażemy dodatkowy parametr określający kierunek tłumaczenia. Teraz szablon {{pons}} udostępnia cały wachlarz możliwości (także tłumaczenia chińskie, bułgarskie, duńskie...), wciąż obsługując zestaw sześciu udokumentowanych kodów ISO funkcjonujących jako aliasy dla nazw języków. Pozdrawiam, Peter Bowman (dyskusja) 21:21, 23 gru 2020 (CET)

  @Peter Bowman Ojej! Są święta, elfy pomagają Mikołajom, a Ty nie dodałeś wsparcia dla elfickiego ;) ;) ;) Dobra robota! KaMan (dyskusja) 02:59, 24 gru 2020 (CET)

• Ogromne podziękowania! Słownik nie jest bardzo duży, ale przydatny i wiarygodny, a obsługuje wiele języków. Przyda się na pewno. Pozdrawiam, Maitake (dyskusja) 21:43, 23 gru 2020 (CET)
• Dołączam się do podziękowań. Wesołych Świąt! ;) --ThelmOSO (dyskusja) 17:08, 24 gru 2020 (CET)

Dwie klawiatury

Czy ktoś z was może pracuje z dwoma klawiaturami pod Windowsem? Ja tak pracuję od wielu miesięcy, mam klawiaturę polską w laptopie i klawiaturę ukraińską na USB. Ale strasznie mnie denerwuje że muszę za każdym razem przełączać tryb pracy, obie mogą być jednocześnie ukraińskie, albo obie polskie. Nie mogę wymyślić sposobu by jedna była na stałe polska, a druga na stałe ukraińska. To niby prosta kombinacja klawiszy, tylko Alt+Shift. Ale jak się w jednym haśle kilkanaście razy zmienia alfabet to jest to naprawdę męczące. Ma ktoś może patent jak pracować z dwoma klawiaturami, w różnych alfabetach, bez używania za każdym razem kombinacji klawiszy do zmiany? @Sankoff64, @PiotrekD bo chyba wy pracujecie z cyrylicą i @Richiski bo grecki. KaMan (dyskusja) 12:35, 28 paź 2020 (CET)

• @KaMan. Ja w trybie edycji wybieram cyrylicę z dolnego menu, poza tym przy korzystaniu z gadżetu do dodawania tłumaczeń uruchamiam wbudowaną w nim klawiaturę ekranową. Oczywiście korzystam też z opcji kopiuj/wklej. Sankoff64 (dyskusja) 12:43, 28 paź 2020 (CET)
• Kiedyś częściej wypełniałem IPA w wymowie, więc dodałem sobie sekcję potrzebnych mi znaków w edytorze (w preferencjach: „edytor wikikodu 2010”): Wikisłownikarz:Peter Bowman/customizeToolbar.js. Mam tam też w osobnej zakładce często używane szablony, znaki typograficzne i, przy okazji, znaki polskiego alfabetu (czasem prościej mi tak zamiast korzystania z kombinacji klawiszy). Peter Bowman (dyskusja) 13:29, 28 paź 2020 (CET)
• @KaMan Z greckim jest o tyle łatwiej, że prawie wszystkie znaki greckie odpowiadają łacińskim (oprócz Θ, Ξ, ς) i są umiejscowione na tych samych klawiszach. Z cyrylicą sprawa jest bardzej skomplikowana, ale ja jej używam bardzo rzadko. Z polskim - w moim przypadku - mylą mi się litery Z i Y, bo jak raz odpowiadają odwrotnie klawiszom w klawiaturze ES. Ogonki to już inna sprawa. --Richiski (dyskusja) 14:43, 28 paź 2020 (CET)
• @KaMan: Ja nie używam Windowsa, więc nie wiem, jak dokładnie sprawy się tam mają, a ponadto podczas codziennego edytowania używam jednej klawiatury (muszę w ogóle jej zdjęcie wrzucić na Commons, bo to specyficzny sprzęt).
  Po prostu przełączam się między układami kombinacją windows+spacja. Do cyrylicy używam układu pseudo-QWERTY – litery cyrylickie mam w miejscu liter łacińskich (z kilkoma uwagami oczywiście). Domyślam się, że dwu klawiatur używasz właśnie ze względu na to, iż nie pamiętasz układu ЙЦУКЕНГ, więc polecam Ci, byś również skorzystał z tego rozwiązania. Na Linuksie taka możliwość jest zazwyczaj dostępna od razu, trzeba tylko włączyć, na Windowsie trzeba skorzystać z rozwiązań zewnętrznych. Jam korzystał niegdyś dokładnie z tego, ale ono jest przeznaczone do języka rosyjskiego. Pozdrawiam, PiotrekD^DYSKUSJA 14:53, 28 paź 2020 (CET)
• @KaMan: Akurat zdarza mi się używać dwóch klawiatur na raz. Przy czym jedna to klawa od Razera, gdzie mogę przestroić sobie jak chcę działanie klawiszy. Więc to nie jest ten sam rodzaj problemu. Drugie rozwiązanie "połowiczne" jakie znam z własnego doświadczenia to własny układ klawiatury:[odnośnik do strony Microsoftu] Pozwala to na utworzenie własnego układu klawiatury, jakiegoś zmodyfikowanego "polski-programisty". Jest jeszcze ostatnia opcja. Jeśli potrafisz programować to z tego co widzę możliwe jest użycie dość 'niskopoziomowych' funkcji z Api Windowsa: (odnośnik). Sam nie byłbym taki zdesperowany. Prędzej wstawiłbym krótki kod JavaScriptu, który zamieniałby mi zaznaczony tekst z łacinki na cyrylicę (powiedzmy), czy coś podobnego. Okcydent (dyskusja) 17:16, 28 paź 2020 (CET)

Navigation popups

Pierwszy na liście gadżetów do włączenia jest Navigation popups. Czy komuś udało się zmusić ten gadżet żeby dobrze pokazywał miniaturkę haseł u nas? Nie oczekuję że będzie mi pokazywał tylko ulubioną, ukraińską sekcję, ale ten gadżet pokazuje mi tylko szablony hasła, żadnej treści. Jest jakiś sposób żeby po najechaniu na link np. w kategoriach widzieć w popupie hasło? Przejrzałem dokumentację gadżetu ale nie wiem jak sobie z nim poradzić. KaMan (dyskusja) 11:21, 15 lis 2020 (CET)

Przewiduję rozszerzenie (a właściwie przywrócenie lokalnych modyfikacji) narzędzia mw:Page Previews, zob. końcowe komentarze w wątku „Nowy gadżet – szybki podgląd definicji”. To może rozwiązać problem, jeżeli wystarczy podgląd pola znaczeń danej sekcji językowej bez dodatkowych przycisków i funkcji, które oferuje Navigation popups. Peter Bowman (dyskusja) 12:22, 15 lis 2020 (CET)

Brzmi obiecująco! Podgląd pola znaczeń w zupełności by mi wystarczył. KaMan (dyskusja) 15:34, 15 lis 2020 (CET)

Wikisłownik:Zgłoś błąd w haśle

Nie wiem, jak były dotychczas traktowane załatwione zgłoszenia na powyższej stronie, czy były po prostu kasowane, czy też przenoszone w inne miejsce (do jakiegoś archiwum? na stronę dyskusji danego hasła?), ale miałbym propozycję zautomatyzowanego czyszczenia tej strony: można wykorzystać do tego szablon {{załatwione}} i jeśli ostatnia edycja w danej sekcji zawierałaby ten szablon, a od tej edycji upłynęło np. 30 (albo 60 dni), jakiś bot przenosiłby zgłoszenie w inne miejsce lub je kasował. W ten sposób strona nie rozrastałaby się ponad miarę. Podobną procedurę można by też zastosować np. do stron Baru. Pozdrawiam, Maitake (dyskusja) 22:01, 6 gru 2020 (CET)

Jak najbardziej zgadzam się; być może należy ten wątek przenieść na stronę Wikisłownik:Zadania dla botów?

Dodam jeszcze, że proponuję jednak przenoszenie tych treści do archiwum, a nie usuwanie, gdyż zgodnie z licencją GFDL należy zachowywać informacje o wkładzie/autorstwie. // tsca (dyskusja) 22:56, 6 gru 2020 (CET)

Zanim stanie się to zadaniem dla botów, warto poczekać na inne opinie (i inne, być może lepsze pomysły), a przede wszystkim ustalić czas karencji dla załatwionego zgłoszenia. Maitake (dyskusja) 23:53, 6 gru 2020 (CET)

Możemy skorzystać ze sprawdzonego od lat rozwiązania z analogicznej strony w Wikipedii: Osoby obsługujące zgłoszenia powinny odpowiednio wypełnić szablon „Status zgłoszenia” (w opisie szablonu podane są parametry, których można użyć). Po 48 godzinach bot automatycznie usuwa z listy zgłoszenia o statusie „wykonane”, „odrzucone”, „błędne”, „poczekalnia” lub „kawiarenka”. // tsca (dyskusja) 23:59, 6 gru 2020 (CET)

• 48 godzin to zdecydowanie za krótko przy tak niewielu regularnie edytujących użytkownikach. Ktoś może oznaczyć zgłoszenie jako załatwione, a ono zniknie, zanim ktokolwiek zdąży zaprotestować. Dlatego zaproponowałem wyżej 30 albo 60 dni, co według mnie powinno wystarczyć. No i na pewno aż tylu różnych rodzajów statusu nie potrzebujemy (poczekalnia / kawiarenka są zbędne, różnica między odrzuconym a błędnym często niejasna itp.). Maitake (dyskusja) 00:12, 7 gru 2020 (CET)
• Ponieważ przez dwa tygodnie nikt nie zabrał głosu, proponuję następujące rozwiązanie:
  1. Wszelkie zgłoszenia, które zostały rozpatrzone i wykonane (tzn. albo hasło zostało poprawione, albo zgłoszenie zostało odrzucone jako błędne) opatruje się szablonem {{załatwione}}.
  2. Jeśli ostatnia edycja w zgłoszeniu zawiera ten szablon, a od jego wstawienia upłynęło 30 dni, bot przenosi zgłoszenie na stronę dyskusji hasła (bez względu na to, czy zgłoszenie zostało rozparzone pozytywnie, czy też odrzucone; nie dotyczy to wandalizmów i trolingu – takie zgłoszenia są od razu kasowane i ich ta procedura nie dotyczy).
  3. Zgłoszenia nierozpatrzone (bez szablonu {{załatwione}}) zostają na stronie zgłoszeń, nie są ani kasowane, ani przenoszone gdzie indziej.

  Jeśli do 15 stycznia 2021 roku nie pojawią się żadnego głosy, rozwiązanie proponuję uznać za przyjęte. — Podobną procedurę proponuję zastosować do wszystkich trzech podstron Baru, po ustaleniu tylko, dokąd dyskusje miałyby być przenoszone (byłoby to zapewne Archiwum, ale należałoby je stworzyć zawczasu). Pozdrawiam serdecznie, Maitake (dyskusja) 20:15, 25 gru 2020 (CET)

Przydałby się jeszcze jakiś opiekun, który by tej strony i tej procedury systematycznie pilnował. Zan-mir (dyskusja) 20:22, 25 gru 2020 (CET)

Po to bot, żeby tego nikt ręcznie robić nie musiał. A karencja 30 dni po to, aby każdy edytor mógł zakwestionować załatwienie zgłoszenia i wstrzymać automatyczną archiwizację. Nie wydaje mi się, aby jeszcze ktoś był potrzebny, tym bardziej że tego typu działania w Wikisłowniku zwykle nie są przez konkretną osobę nadzorowane (bo i rąk do pracy nie starcza). Maitake (dyskusja) 23:11, 25 gru 2020 (CET)

No dobrze, ale bot to tylko wsparcie. Bot nie kiwnie palcem w bucie, póki Ty czy ja nie klikniemy tego czy owego, więc automatyka tu właściwie żadna, bo przenieść wątek to ja sam se moge. I to 10 na raz, raz na pół roku. A druga sprawa: co jest złego w procedurze: zgłoszenie błędu, poprawienie błędu, usunięcie zgłoszenia z widoku? Przecież żadnego wkładu z historii nie usuwamy. Zan-mir (dyskusja) 23:21, 25 gru 2020 (CET)

Jest rzeczą oczywistą, że po ustaleniu procedury działania musi się znaleźć operator bota, który to zautomatyzuje (wyżej jest przecież mowa o wpisaniu tego do Zadań dla botów). A że zgłoszenie błędu to też jakiś wkład w Wikisłownik, również wyżej już stoi napisane. Nie bardzo rozumiem, czego dotyczy ten wątek dyskusji (o tonie wypowiedzi nie wspominając: „to ja sam se moge”? – nie wiem, z kim Pan by chciał w ten sposób rozmawiać). Maitake (dyskusja) 00:10, 26 gru 2020 (CET)

Nie mam innych argumentów. Czekamy do 15 stycznia. Zan-mir (dyskusja) 00:21, 26 gru 2020 (CET)

@Maitake, @Tsca, @Zan-mir: zacząłem pisać kod bota, na chwilę obecną potrafiłby obsługiwać załatwione zgłoszenia na WS:ZB. Algorytm:

1. Filtruje sekcje, w których wstawiono {{załatwione}}, a ostatni znacznik czasu (bez względu na umiejscowienie, czyli edycje następujące po {{załatwione}} również będą brane pod uwagę) wskazuje na datę wcześniejszą niż miesiąc do chwili uruchomienia programu.
2. Na podstawie nagłówka sekcji odzyskuje tytuł strony będącej podmiotem zgłoszenia. Musi to być pojedynczy, osamotniony link.
3. Przenosi zgłoszenie na powiązaną stronę dyskusji strony z poprzedniego punktu, o ile sama nie jest stroną dyskusji. Ten krok zostanie pominięty, jeżeli strona nie istnieje (dla uniknięcia osieroconych stron dyskusji).

Algorytm nie jest jeszcze ukończony, ponieważ nie uwzględnia takich sekcji jak „nowy indeks językowy – X”, „Szablon odmiana-przymiotnik-polski”, „Phnom Penh”, „[[née#en|née]], [[nee#en|nee]]”... Gdzieniegdzie można samemu wstawić brakujące nawiasy kwadratowe, ręcznie kompletując link w nagłówku w trakcie oznaczania sekcji jako załatwioną („[[Phnom Penh]]”). Jestem skłonny dopuścić obecność innych elementów w nagłówku, np. „bład na stronie [[test]]” – automat sam zidentyfikuje link do strony „test”. Jeżeli linków jest kilka, bot mógłby powielać archiwizowany wątek na wszystkich stronach dyskusji – czy to jest pożądane?

Jak postępować z resztą wpisów: kasować (jak do tej pory) czy przenosić do (nieutworzonego jeszcze) archiwum? Nie bardzo rozumiem argumentu o licencji GFDL; wkład zgłaszającego nie ginie, a gdyby treść zgłoszenia została gdzieś wykorzystana, zgodnie z CC-BY SA można po prostu podlinkować do konkretnej wersji WS:ZB. Peter Bowman (dyskusja) 20:56, 17 sty 2021 (CET)

• @Peter Bowman, dziękuję ogromnie za zajęcie się sprawą. Mam jedną uwagę techniczną: to oczywiście nie musi być bezwarunkowo szablon {{załatwione}}, równie dobrze może być wspomniany wyżej szablon {{status zgłoszenia}} (używany już choćby na stronie Zadań dla botów) – cokolwiek będzie łatwiejsze technicznie (o ile byłaby jakaś różnica). W przypadku kilku linków do istniejących haseł byłbym za przenoszeniem zgłoszenia na stronę dyskusji każdego takiego hasła (czyli powielanie), bo zgłaszający ma zapewne jakiś cel w podawaniu kilku linków. Zgłoszenia nieprzypisane do konkretnego hasła (czy haseł) wolałbym archiwizować, bo w ten sposób każdy będzie mógł później znaleźć, np. kto indeks językowy zgłosił, kto to skomentował i czy zgłoszenie zostało wprowadzone, czy też nie (i dlaczego nie). Szukanie w dawnych wersjach strony jest chyba gorszym rozwiązaniem niż szukanie w archiwum. — Jedno pytanie: jaki byłby najlepszy sposób na wstrzymanie archiwizacji / przenoszenia do dyskusji, w przypadku gdy jakiś użytkownik nie zgadza się, że zgłoszenie zostało załatwione? Kasowanie szablonu {{załatwione}} to nie najlepszy pomysł. Wstawienie {{s| do tego szablonu? Użycie znaczników <nowiki>? Jeszcze coś innego? Pozdrawiam, Maitake (dyskusja) 21:26, 17 sty 2021 (CET)

Link do WS:AUTOLINK

Czy udałoby się umieścić gdzieś w obrębie okna Wikisłownika link do strony Wikisłownik:Narzędzia/Linkowanie automatyczne? Przydaje się podczas edycji, ale trudno się go szuka. Może gdzieś w okienku narzędziowym nad polem edycji, np. obok guzika do dodawania źródeł? Maitake (dyskusja) 17:12, 11 gru 2020 (CET)

Ja mam link do tej strony w zakładkach. Też się sprawdza. tsca (dyskusja) 18:09, 11 gru 2020 (CET)

• To jest jakieś rozwiązanie, ale ja zakładek mam już tak dużo, że się mi nie mieszczą (dla samego Wikisłownika mam dwa foldery, w których grupuję zakładki). Poza tym nowi edytorzy nie będą o narzędziu pewnie nawet wiedzieć, jak go nie zobaczą podczas edycji. Maitake (dyskusja) 18:14, 11 gru 2020 (CET)
  • Jeśli już dodawać to narzędzie do okna edycji, to może nie tyle w formie linka, ile funkcji zastępującej tekst zaznaczony tekstem wstępnie podlinkowanym? To byłoby naprawdę wygodne. tsca (dyskusja) 18:20, 11 gru 2020 (CET)

Szablon odmiany czasowników niemieckich

Cześć, planuję opublikować w przestrzeni głównej szablon odmiany czasowników niemieckich. Póki co na próbę wstawiłem go dla czasownika brennen. W wersji podstawowej zamieściłem narazie jako {{Wikisłownikarz:Superjurek/odmiana-czasownik-niemiecki3}}, natomiast zamierzam docelowo stworzyć szablon z rozróżnieniem na tryb oznajmujący Indikativ i tryb przypuszczający Konjunktiv I i Konjunktiv II, który wykluwa się pod tym linkiem {{Wikisłownikarz:Superjurek/odmiana-czasownik-niemiecki2}} (nie ma jeszcze rubryk w trybach przypuszczających, bo tu trzeba będzie wstawić wszystkie czasy, które występowały w trybie oznajmującym, a na to na razie nie mam zdrowia). Czy w takim stanie {{Wikisłownikarz:Superjurek/odmiana-czasownik-niemiecki3}} może już iść do przestrzeni głównej? Superjurek (dyskusja) 01:13, 13 gru 2020 (CET)

@Superjurek:

• Szablon był już kilkakrotnie przenoszony z powrotem do brudnopisu, ponieważ wymaga dopracowania. Szczegóły w Specjalna:Diff/6088584.
• Pierwsze, co rzuca się w oczy, to długa lista argumentów: Specjalna:Diff/7499429. Na pewno da się ją znacznie skrócić, jako że większość z nich się powtarza albo mogą być ponownie wykorzystane (np. cały Präteritum to w zasadzie jedna forma, do której doklejamy różne sufiksy).
• W trakcie selekcji parametrów należy uwzględnić wszystkie możliwe warianty użycia szablonu: czy ten sam zestaw parametrów jest wystarczający dla czasowników koniugacji słabej, mocnej i mieszanej? Jakie można spotkać wyjątki?
• Tabela zajmuje dużo miejsca, a i tak sporo jej brakuje. Podpowiedziałem Ci, że masz do dyspozycji wersję skondensowaną – może być z kolei zbyt obszerna po pełnym rozwinięciu, ale wydaje mi się dobrym punktem startowym.
• Zastrzeżenia i konsensus: przeczytaj WS:Bar/Archiwum 16#Szablon:odmiana-czasownik-niemiecki-test, proszę.

Peter Bowman (dyskusja) 12:49, 13 gru 2020 (CET)

Szablon odmiany czeskich przymiotników

Chciałbym zgłosić dwie sprawy związane z tym szablonem:

• Szablon błędnie uzupełnia formy mianownika i wołacza liczby mnogiej męskich żywotnych w przypadku przymiotników, w których zachodzi wymiana:

• k na c (měkký → *měkkí zamiast měkcí)

• r na ř (modrý → *modrí zamiast modří)

• ch na š (suchý → *suchí zamiast suší)

• h na z (drahý → *drahí zamiast drazí)

• sk na št (polský → *polskí zamiast polští)

• ck na čt (německý → *německí zamiast němečtí)

• Szablon nie daje możliwości podania form obocznych. Na przykład przymiotnik tlustý ma dwie równorzędne formy stopnia wyższego: tlustší oraz tlustější, a trzeba podać z nich jedną. Rovaniemmi (dyskusja) 13:39, 17 gru 2020 (CET)

Dziękuję za zgłoszenie, @Rovaniemmi. Czy wymiana zachodzi w każdym czeskim przymiotniku zakończonym na -ký, -rý, -chý, -hý, -ský, -cký (odmiana „twarda”)? Podlinkuję szablon: {{odmiana-przymiotnik-czeski}}. Peter Bowman (dyskusja) 14:23, 17 gru 2020 (CET)

Tak, wymiana zachodzi w każdym takim przymiotniku. Dziękuję za rozpatrzenie zgłoszenia. Rovaniemmi (dyskusja) 14:37, 17 gru 2020 (CET)

@Rovaniemmi: zrobione (Specjalna:Diff/7503855 + Specjalna:Diff/7503867). Oboczność w stopniu wyższym podajemy w drugim parametrze, zob. dokumentację. Przykłady wywołań znajdują się na stronie testowej. Pozdrawiam, Peter Bowman (dyskusja) 23:12, 17 gru 2020 (CET)

Kategorie dla odmian rzeczowników greckich

Mam propozycję ze swojej strony taką, żeby stworzyć kategorie o nazwach poszczególnych modeli deklinacji. Sam bym chętnie się podjął. Np. w przypadku tego rzeczownika: γιαγιά przypisałbym do (jeszcze nie utworzonej) kategorii: Kategoria:Język nowogrecki - odmiana F23. Kategoria ta byłaby podkategorią w kategorii Kategoria:Język nowogrecki - rzeczowniki rodzaju żeńskiego. Analogicznie postąpiłbym z pozostałymi rzeczownikami. Superjurek (dyskusja) 21:51, 18 gru 2020 (CET)

Rozumiem, że proponujesz rozbudowę szablonu {{odmiana-rzeczownik-nowogrecki}}, żeby wskazywał model odmiany i przy okazji kategoryzował stronę wywołującą. Nowy parametr umożliwiłby automatyczne generowanie tekstu [[Aneks:Język grecki - Modele deklinacji rzeczowników#F23|F23]] przez szablon na podstawie wartości F23. Co do kategorii: wydaje mi się, że żaden szablon nie kategoryzuje względem modelu odmiany/koniugacji, tym samym chyba ta klasyfikacja nic istotnego nie wnosi. Tak czy inaczej najpierw należy wprowadzić parametr i zaplanować ujednolicenie wywołań, ewentualną kategoryzację można włączyć w następnej kolejności. Pozdrawiam, Peter Bowman (dyskusja) 22:59, 18 gru 2020 (CET)

@Peter Bowman Oto moja propozycja szablonu {{Wikisłownikarz:Superjurek/brudnopis/odmiana-rzeczownik-nowogrecki}}, z automatycznym kategoryzowaniem. Z miłą chęcią go wdrożę, jeśli uzyskam na to zgodę. Pozdrawiam Superjurek (dyskusja) 23:56, 18 gru 2020 (CET)

@Superjurek: pośpiech jest niewskazany, szablony trzeba testować. Zobacz, co się stanie, jeżeli podmienisz kod istniejącego szablonu: Specjalna:Rozwijanie szablonów. Ja nadal mam wątpliwości, czy chcemy tworzyć 70 kategorii w tym celu i czy będzie z tego jakaś korzyść. Pomysł jest świeży, w dwie godziny nie da się tego uzgodnić; wypada poczekać na ewentualne opinie, szczególnie od użytkowników szablonu (@Richiski?). Peter Bowman (dyskusja) 01:46, 19 gru 2020 (CET)

@Peter Bowman, @Richiski Moim zdaniem będzie z tego korzyść, bo to jest strukturyzowanie wiedzy na Wikisłowniku. Szablon testowałem i działa. W zastosowaniu różni się od aktualnie obowiązującego tym, że jest w nim parametr {{{model}}}. Parametr ten generuje (zgodnie z dotychczasowym wzorcem) przed tabelką link do aneksu z modelem odmian oraz generuje przypisanie do kategorii [[Kategoria:Język nowogrecki - odmiana {{{model}}}]]. Co do użyteczności, to strukturyzacja zasobów jest bardzo ważnym aspektem Wikisłownika. „Nawet” jeśli, a wręcz „przede wszystkim” jeśli tych podkategorii będzie 70, to lista rzeczowników w języku greckim nie jest zamknięta. Będzie ich przybywać sukcesywnie wraz z rozwojem języka w jego współczesnej formie, a więc same te kategorie będą się proporcjonalnie zapełniać. Może to być przydatne na przykład dla lingwistów, którzy w ramach prac naukowych będą porównywać ilościowo zbiory rzeczowników pogrupowane na podstawie modelu odmiany. Oczywiście Wikisłownik nie może być źródłem na które powołujemy się wprost, ale pozostaje bezcenną inspiracją przy tego typu dociekaniach. Ze swojej strony zaś widzę w tym cenną inicjatywę, bo inicjatywa którą tu postuluję (zmodyfikowanie szablonu i utworzenie tych 70 kategorii) jest zadaniem żmudnym, które jednak jest inwestycją w strukturę Wikisłownika. Nie wiem jak inaczej uargumentować moją inicjatywę... wiem że na panelu technicznym nie powinno się odwoływać do emocji, tylko do merytoryki, lecz momentami jestem sfrustrowany tym, że gdy próbuję wyjść z inicjatywą twórczą, jak tylko przyjdzie mi poddać to pod dyskusję w Barze, to mocno obawiam się że zostanę w swoim zapale zgaszony bo „jest lekka szansa, że ta inicjatywa może okazać się mało przydatna”. Ta obawa bardzo demotywuje do własnych inicjatyw, co kłóci mi się z ideą Wikisłownika jako projektu otwartego i tworzonego oddolnie przez internautów. W tym miejscu mam przy okazji pytanie „gdzie mogę znaleźć na Wikisłowniku odpowiednik 5 filarów, które obowiązują na Wikipedii?”. Piątym filarem na Wikipedii jest „Brak sztywnych reguł”, tu zauważam że ten filar nie obowiązuje, bo jakakolwiek inicjatywa oddolna przechodzi przez bardzo cienkie sito selekcyjne (co mocno gasi zapał) :( Superjurek (dyskusja) 11:22, 19 gru 2020 (CET)

@Superjurek: nie zrozum mnie źle, nie próbuję Cię zdemotywować. W tym momencie jest po prostu jeszcze za wcześnie na masowe wdrażanie, którego się domagasz. Należy być ostrożnym i zainwestować inicjatywę przede wszystkim w testowanie szablonu i pozyskanie opinii społeczności, który ten szablon ma docelowo używać, również pod kątem pożyteczności dla czytelnika-internauty. Już pierwszy punkt naprawdę mocno kuleje... Wyżej wskazałem jedno narzędzie, innym jest Specjalna:TemplateSandbox (mw:Help:Extension:TemplateSandbox). Gdybyśmy wdrożyli Twoją propozycję, należałoby ją jak najprędzej wycofać – czy to nie jest demotywujące? Peter Bowman (dyskusja) 12:43, 19 gru 2020 (CET)

Umieściłem wpis na tablicy ogłoszeń. Peter Bowman (dyskusja) 12:55, 19 gru 2020 (CET)

Mam mieszane uczucia. Z jednej strony uważam, że za mało kategoryzujemy. Wiele indeksów mogłoby być zastąpionych sprawnie budowanymi kategoriami. Z drugiej strony... Jeśli dobrze liczę mamy w tej chwili ten szablon na jakichś 330 stronach rzeczowników nowogreckich. Na 70 kategorii to będzie chyba jakieś 4-5 haseł w kategorii zakładając mniej więcej równomierny rozkład. Czy z 4-5 rzeczowników można wysnuć jakąś wiedzę o języku? Nie bardzo. Czy jest szansa, że będzie tych rzeczowników z szablonem odmiany więcej? Ile lat zabrało nam uzbieranie 330 rzeczowników? Czy pojawienie się Superjurka i jego dotychczasowy wkład gwarantuje, że tych szablonów nam gwałtownie przybędzie? Odpowiedzi na te pytania według mnie sugerują, że pomysł jest przerostem formy nad treścią. Wobec tych wątpliwości zastanowiłbym się raczej, bo przecież nie jesteśmy sami we wszechświecie, czy jakikolwiek inny (a w szczególności greckojęzyczny i anglojęzyczny) Wikisłownik wpadł na pomysł takiej kategoryzacji przed Superjurkiem i czy w ten sposób moglibyśmy utworzyć interwiki w tych kategoriach, żeby użytkownik po sznurku mógł dojść do bardziej obszernej treści i rzeczywiście wyciągnąć jakieś wnioski o języku nowogreckim. No i kluczowa jest opinia Richiskiego czy gdziekolwiek w literaturze stosuje się taką kategoryzację w celach praktycznych (jakich?). KaMan (dyskusja) 14:21, 19 gru 2020 (CET)

• Ja również jestem zdania, że indeksy (jako słabo weryfikowalne) ustępują kategoriom, ale to temat na inną dyskusję. Natomiast kategoryzowanie wyrazów według wzorca odmiany może być jak najbardziej przydatne, tak robi np. „Słownik gramatyczny języka polskiego”, który przy haśle, dajmy na to słup, podaje link B4 odsyłający do strony, na której jest wzorzec odmiany, liczba leksemów w ten sposób odmienianych, dalej podtypy, liczba leksemów w podtypach, a poszczególne liczby stanowią linki do spisów wyrazów odmieniających się w określony sposób. Narzędzie rzadkie i przydatne, choć pewnie niezbyt wielu osobom. No i oczywiście jego przydatność zależy od liczby skategoryzowanych wyrazów. Warunkiem wprowadzenia takiej kategoryzacji w Wikisłowniku jest jednak rozwiązanie problemów technicznych i brak kolizji z innymi technikaliami, a na ten temat nie mogę się wypowiedzieć, bo się nie znam. Jeśli konflikt występuje, to trzeba rozważyć, co jest tak naprawdę bardziej przydatne i czy warta skórka wyprawki. Pozdrawiam, Maitake (dyskusja) 15:25, 19 gru 2020 (CET)

Nie do końca zgadzam się z argumentem, że nie warto robić kategorii dla kilku rzeczowników, bo nie istnieje coś takiego jak kryterium encyklopedyczności/słownikowości kategorii. Ważne że zbiera hasła o wspólnej cesze i tym samym można je łatwo odnaleźć. Superjurek (dyskusja) 13:45, 15 sty 2021 (CET)

symetryzacja homofonów

Może bot mógłby lustrzanie pouzupełniać homofony? Np. w rok jest rock, ale w rock już nie ma rok. Zan-mir (dyskusja) 06:41, 22 gru 2020 (CET)

Tylko trzeba uważać na takie i podobne sytuacje. Zan-mir (dyskusja) 06:52, 22 gru 2020 (CET)

• Homofony są bodaj zawsze symetryczne, więc można by to wprowadzić (i tak w niewielu hasłach szablon homofonów widziałem, więc to dużo roboty pewnie nie będzie). Nawet jeśli homofon jest ograniczony do jednego typu wymowy (np. te wskazane dialekty z utożsamieniem wine-whine), to homofonia też jest w ramach tej właśnie wymowy symetryczna. Nie widzę zatem przeciwwskazań. Pozdrawiam, Maitake (dyskusja) 18:48, 28 gru 2020 (CET)

@Zan-mir Zrobione, było ich całkiem sporo, wszystkich ok. 1700, bot dodał jeszcze ok. 400. Będzie odświeżał homofony raz w tygodniu. Symetryzacja obejmuje tylko przypadki, gdzie źródłowy (i ewentualnie docelowy) szablon "homofony" był dodany bez żadnych dodatkowych uwag, szablon jest tylko jeden w danej sekcji językowej, nie jest dopisany do jednej konkretnej wersji wymowy, ma samodzielną linijkę zaczynającą się od ": {{homofony|", za szablonem nic nie jest dopisane, homofon nie dotyczy formy odmienionej, itp.. Chodzi o to, żeby zminimalizować ryzyko, że dopiszemy ten homofon do innej wersji wymowy, niż powinniśmy albo bez koniecznego kwalifikatora jakiegoś dialektu czy innej oboczności. Olaf (dyskusja) 13:20, 15 sty 2021 (CET)

@Olaf nie znam się na homofonach ale wolę zapytać, skoro jest jeden szablon na hasło, a w haśle mogą być dwie wymowy w zależności od akcentu, to bycie homofonem tyczy się obu wersji akcentowych? Jeszcze nie przerabiałem homofonów w ukraińskim ale wolę być przygotowanym jakby mi się w jakimś źródle pojawiły. KaMan (dyskusja) 13:43, 15 sty 2021 (CET)

@KaMan Nie sądzę, żeby było ściśle ustalone, co to dokładnie jest homofon i jak się to ma do akcentów w ukraińskim. Szablonów z homofonami może być więcej na hasło, tylko bot w takim przypadku boi się ich dotykać, bo wymagałoby to rozumienia struktury sekcji "wymowa". Ale ludzie jak najbardziej powinni, i czasem, gdy wymowa w różnych znaczeniach jest różna, jest potrzebne dodanie kilku szablonów. Olaf (dyskusja) 14:34, 15 sty 2021 (CET)

@KaMan Jeszcze drobiazg, jakbyś dokładał homofony, to jako osobną linię (inaczej ta symetryzacja nie zadziała) i chyba lepiej dokładać je przed nagraniami wymowy dodawanymi przez bota. Bot zawsze dokłada wymowę z LinguaLibre w ostatniej linijce pola "wymowa", jeśli na koniec tego pola dołożysz homofon, to doda kolejne nagranie linijkę niżej. Więc jeśli już jakieś nagrania są na końcu, to lepiej dokładać homofony wiersz przed nimi a nie za. Olaf (dyskusja) 16:38, 15 sty 2021 (CET)

Ja zazwyczaj umieszczam {{homofony}} w nowym wierszu, ale czasem hasło wymawia się różnie i należy doprecyzować, do której wymowy się odnoszę – w Specjalna:Diff/7550814 wymowa alternatywna i towarzyszący jej homofon są w tej samej linii. Jeżeli w danym haśle ukraińskim wyróżnia się dwa sposoby akcentowania, uważam, że homofon może dotyczyć tylko jednego z nich (chyba że wyjątkowo ten sam homofon ma również dwie wymowy pokrywające się z omawianym hasłem). Peter Bowman (dyskusja) 17:41, 15 sty 2021 (CET)

Dokładnie tak. Jeśli jest potrzeba doprecyzowania, to homofon oczywiście powinien być przy odpowiadającej mu wymowie. I wtedy bot ani takiego homofonu nigdzie nie użyje (bo być może musiałby dodać o jaki wariant wymowy chodzi, czego nie potrafi), ani nic do tego szablonu nie dopisze (bo nie wie, czy nowy homofon pasuje akurat do tego szczególnego przypadku). Olaf (dyskusja) 17:48, 15 sty 2021 (CET)

Problemy ze skórką Timeless

Wczoraj wieczorem w skórce Timeless znikły zielone guziki umożliwiające automatyczne dodanie opisu edycji oraz całkowicie guzik pozwalający dodawać źródła. W skórce Wektor są one widoczne, innych skórek nie sprawdzałem. Maitake (dyskusja) 11:43, 11 sty 2021 (CET)

U mnie działa (jedno i drugie). Może naciśnij Ctrl+F5? tsca (dyskusja) 11:53, 11 sty 2021 (CET)

• Nie, nic nie pomaga. W Wektorze problemu nie ma, w Timeless znikły te przyciski bez śladu. Maitake (dyskusja) 12:32, 11 sty 2021 (CET)

  @Maitake: proszę przeładować stronę i otworzyć konsolę deweloperską (klawisz F12, ewentualnie zob. [21]). W zakładce „Console”/„Konsola” mogą pojawić się błędy – proszę tu przekleić. U mnie również działają oba narzędzia zarówno w skórce Wektor, jak i Timeless. Podejrzewam konflikt z którymś gadżetem. Peter Bowman (dyskusja) 14:00, 11 sty 2021 (CET)

• Zrobiłem tak, jednak pojawia się tam bardzo wiele różnych rzeczy w wielu zakładkach (Inspektor, Konsola, Debuger, Sieć itd.) i nie wiem, które tu mam przekleić. W zakładce Konsola pojawia się taki tekst (dla mnie oczywiście niezrozumiały):

JQMIGRATE: Migrate is installed with logging active, version 3.1.0 load.php:247:171
This page is using the deprecated ResourceLoader module "jquery.tipsy". load.php:299:369
This page is using the deprecated ResourceLoader module "jquery.ui".
Please use OOUI instead. load.php:1:80
JQMIGRATE: jQuery.fn.delegate() is deprecated load.php:247:746
JQMIGRATE: jQuery.fn.bind() is deprecated load.php:247:746
JQMIGRATE: jQuery.fn.unbind() is deprecated load.php:247:746

Maitake (dyskusja) 17:01, 11 sty 2021 (CET)

W tej chwili właśnie przyciski wróciły, więc zgłoszenie mógłbym zamknąć, gdyby nie to, że nie wiem, co się stało, a więc i nie wiem, czy problem nie wróci. Maitake (dyskusja) 17:39, 11 sty 2021 (CET)

• Dziękuję, dokładnie o to mi chodziło, ale tym razem niestety na niewiele się zda – to są zwykłe ostrzeżenia. Ponoć od czwartku nie było zmian w oprogramowaniu, lecz właśnie podczas tej ostatniej aktualizacji wprowadzono kilka zmian specyficznych dla skórki Timeless. Mogę jedynie przypuszczać problem z cache'owaniem po stronie serwerów Fundacji, a te zwykle ustępują z czasem. Peter Bowman (dyskusja) 19:38, 11 sty 2021 (CET)
• Niestety, zbyt późno przyszło mi do głowy, że to F12 mogłem wcisnąć w trybie edycji, a nie po prostu w trybie czytania strony. Teraz już tego nie zrobię, ale jak znowu się ten problem pojawi, to będę oczywiście zgłaszał. @Peter Bowman, dziękuję tak czy owak. Maitake (dyskusja) 19:53, 11 sty 2021 (CET)

Znowu zniknął guzik do wstawiania źródeł oraz automatyczne opisy edycji. Jeszcze godzinę temu były. Wszedłem na dowolne hasło, rozpocząłem edycję, wcisnąłem F12 i dostałem coś takiego:

JQMIGRATE: Migrate is installed with logging active, version 3.1.0 load.php:288:171
This page is using the deprecated ResourceLoader module "jquery.throttle-debounce".
Please use OO.ui.throttle/debounce instead. See https://phabricator.wikimedia.org/T213426 load.php:773:381
This page is using the deprecated ResourceLoader module "jquery.tipsy". load.php:774:363
This page is using the deprecated ResourceLoader module "jquery.ui".
Please use OOUI instead. load.php:780:985
JQMIGRATE: jQuery.fn.delegate() is deprecated load.php:288:746
Uncaught SyntaxError: illegal character U+001F
load.php:1
Niektóre ciasteczka niewłaściwie wykorzystują zalecany atrybut „SameSite” 7

Maitake (dyskusja) 21:53, 13 sty 2021 (CET)

• Nie zapytałem, więc na razie będę przypuszczał, że użyta przeglądarka to Firefox. Proszę kliknąć link, który powinien się znajdować pod fragmentem „load.php:1” sąsiadującym z napisem „Uncaught SyntaxError: illegal character U+001F”. Kliknięcie powinno otworzyć zakładkę Debugger – próbowałem u siebie i czasem strona ukazuje się pusta, trzeba wtedy przeładować stronę i spróbować ponownie. U mnie wygląda to w ten sposób. W lewym panelu będzie kilka elementów zaczynających się na „load.php”, w tym jeden wyróżniony (wskutek kliknięcia na wcześniejszy link). Proszę kliknąć na niego prawym przyciskiem, skopiować i przekleić tu adres URI (będzie podobny do zawartości dymku na moim zrzucie ekranu). Peter Bowman (dyskusja) 00:32, 14 sty 2021 (CET)
• Niestety, nie mogę tego zrobić, bo w tej chwili przyciski właśnie wróciły i Konsola pokazuje inny komunikat (żadnego linku nie ma, nie ma w ogóle load.php:1. Po powyższym wpisie z 21:53 wykonałem jeszcze kilka edycji (przycisków cały czas nie było), po czym zmieniłem skórkę na Wektor, gdzie przyciski są. Ich powrót w skórce Timeless zauważyłem dopiero teraz po ponownym przełączeniu skórki. A przeglądarka rzeczywiście Firefox. Maitake (dyskusja) 00:45, 14 sty 2021 (CET)

  @Maitake: gdyby się powtórzyło i link wrócił (sam napis load.php:1 powinien być linkiem), po kliknięciu na niego proszę przy okazji rzucić okiem na centralny panel w zakładce Debugger, czyli tam, gdzie na moim zrzucie jest ściana kodu na pół ekranu. Wprawdzie zapytawszy na kanale IRC zasugerowano mi, że może chodzić o konkretny, niedziałający gadżet (typowa przyczyna), jednak stawiałbym na sporadyczny błąd po stronie MW bądź przeglądarki. Jeżeli mam rację, w tym panelu pojawi się coś nietypowego. Byłbym wdzięczny za przesłanie mi jego zawartości w formie pliku (prawy guzik > Pobierz plik). Peter Bowman (dyskusja) 01:35, 14 sty 2021 (CET)

[22] to nie jest intuicyjne... i nie ma narzędzi by rozwijać tę sekcję