Wikiźródła:Skryptorium/Pulpit techniczny
Przy pulpicie technicznym dyskutuje się nad kwestiami technicznymi związanymi z MediaWiki, botami, skryptami i szablonami.
Miłych i owocnych dyskusji!
Nowy gadżet Popraw tekst OCR
Witam,
w preferencjach w sekcji Gadżety dodany został w wersji testowej nowy Gadżet Popraw tekst OCR, służący do wstępnego "czyszczenia", formatowania oraz poprawy typowych błędów surowego tekstu OCR w oknie edycji proofread. W chwili obecnej Gadżet realizuje następujące poprawki:
- usuwa łączniki opcjonalne,
- usuwa zbędne podziały wiersza,
- usuwa zbędne odstępy przed i po akapicie,
- zamienia
"tekst"
na„tekst“
, - zamienia
-
na—
(jeżeli znak "-" nie łączy wyrazów), - usuwa zbędne odstępy przy znakach
„“
,,
,.
, - zamienia
tern
natem
.
W zamierzeniach Gadżet ten, w przeciwieństwie do skomplikowanego gadżetu "Sprzątanie kodu" ma być "lekkim" i prostym w stosowaniu narzędziem pomagającym początkującym skrybom w "wykrywaniu" najczęstszych defektów tekstów OCR. Mam także nadzieję, iż będzie przydatnym narzędziem dla doświadczonych Skrybów, których tak jak mnie, irytuje usuwanie niewidocznych łączników opcjonalnych :)
Gadżetu należy używać jedynie na początku pracy z tekstem, gdy przystępujemy do tworzenia strony, korzystając z surowego tekstu OCR.
Proszę Użytkowników o testy, uwagi donośnie do ewentualnych problemów w funkcjonowaniu testowego gadżetu oraz sugestie zmian.
Zdzislaw (dyskusja) 22:55, 15 lut 2015 (CET)
Proszę o dopisanie do podmianek następujących opcji (zazwyczaj wykonuję te zamiany, kiedy przygotowuję OCR):
- poprawka zamiany
_tern
na_tem
(z uwagi na wyrazy "filuterny" i "czternaście"; w środku wyrazów występują takie sekwencje liter, ale na początku wyrazów — nie) - zamiana
/.
naz
- zamiana
cbc
nachc
- zamiana
_icb
na_ich
- zamiana
cli
nach
- zamiana
cłi
nach
- zamiana
_źe
na_że
- zamiana
_źa
na_ża
- zamiana
_źo
na_żo
- zamiana
_iź
na_iż
- zamiana
_teź
na_też
- zamiana
_byl_
na_był_
- zamiana
°
nao
- ale może zrobić
litera°
literao ?
- ale może zrobić
- zamiana
_!
na!
- zamiana
_?
na?
- zamiana
_.
na.
- zamiana
_,
na,
- zamiana
_:
na:
- zamiana
_;
na;
- zamiana
'
na’
- zamiana
i t._
nai t.
(i t. ) - zamiana
n. p.
nan. p.
(n. p.) - zamiana dwóch spacji na jedną.
I to by było na razie na tyle ;-) Wieralee (dyskusja) 00:30, 11 sie 2015 (CEST)
I jeszcze koniecznie:
- @Wieralee: Dziękuję za pomoc i cenne propozycje. Propozycje oznaczone zostały zaimplementowane w kodzie gadżetu, pozostałe wymagają dyskusji:
- zamiana
cli
nach
- może niekorzystnie wpłynąć na poprawne wyrazyclić, oclić, precli, strucli
... - zamiana
°
nao
-°
występuje często w wypunktowaniu1°, 2°...
, być może ze spacjami na początku_°
na_o
? - zamiana
i t.
nai t.
- w jakim celu ta niełamliwa spacja dodatkowo na końcu?
- zamiana
- Zdzislaw (dyskusja) 17:50, 13 sie 2015 (CEST)
- @Wieralee: Dziękuję za pomoc i cenne propozycje. Propozycje oznaczone zostały zaimplementowane w kodzie gadżetu, pozostałe wymagają dyskusji:
- Co do "cli" — tak, gadżet na pewno popsuje te wyrazy. Tyle, że takowa zamiana na początku, w surowym OCR wg mojego doświadczenia i tak się opłaca -- statystyka występowania źle zczytanego "ch" a występowania wyrazów "clić" i "precli" jest jak może 100:1. Gadżet z natury nie jest dedykowany do uruchamiania po przeczytaniu tekstu i poprawieniu literówek, więc tych kilka przypadków można potem poprawić ręcznie... Co do praktyki -- do tej pory zawsze taką podmianę robiłam... Jeśli chcesz, by jednak taki błąd nie występował, wpisz choć zamianę "icli" na "ich" (większość błędów "cli" to błędy "icli"). Ale nie upieram się, priorytety gadżetu nie są jeszcze ustalone ;-)
- Co do
i t.
, sprawa jest prosta... Mamyi t. p.
ii t. d.
. Tym sposobem zamienia się obydwa skróty, a samego skrótui t.
bez trzeciej literki jeszcze nie widziałam? - Dzięki za podmianki. Wieralee (dyskusja) 18:15, 13 sie 2015 (CEST)
- czy zatem nie powinno być zamiany
i_t._
nai t.
? czy jednaki_t.
nai t.
? Zdzislaw (dyskusja) 18:30, 13 sie 2015 (CEST)
- czy zatem nie powinno być zamiany
- Zaiste :-) Proszę jeszcze o spację przed "tern", czyli "_tern" na "_tem" . I jeszcze "tab_" na "tab" i "_br" na "br" .
- Martwi mnie natomiast coś innego: kolejność zamianek. Ostatnimi zamianami powinny być te z wieloma spacjami, a potem ta ze spacją po tabulatorze i ta ze spacją przed br-em. Wieralee (dyskusja) 18:45, 13 sie 2015 (CEST)
- zrobione Zdzislaw (dyskusja) 19:47, 13 sie 2015 (CEST)
- Wielkie dzięki! Ale jeszcze mała poprawka — spacje wokół myślników nie redukują się. Wypróbuj tutaj. Wieralee (dyskusja) 20:25, 13 sie 2015 (CEST)
- Zrobione Zdzislaw (dyskusja) 20:47, 13 sie 2015 (CEST)
- Przychodzi mi do głowy jeszcze:
- zamiana
-—
na—
, ale to musiałoby być gdzieś na samym początku zamian, żeby potem ten myślnik także miał dodane spacje wokół siebie - usunięcie
■
- usunięcie
•
- i nie wiem, co zrobić z zamknięciem cudzysłowu
"
, czy lepiej go domyślnie zmienić na“
, czy lepiej zostawić... Wieralee (dyskusja) 23:42, 13 sie 2015 (CEST) - cudzysłów zdecydowanie domyślnie zamienić na
“
, - powstał jakiś błąd prawdopodobnie dotyczący tego fragmentu * zamiana
—
na_—_
jak jest tab przed—
to kasuje się jeden nawias } Załatwione
Nawider (dyskusja) 08:25, 14 sie 2015 (CEST)
- @Nawider: tak, niepoprawny regexp usuwał znak przed lub po —, poprawiłem kod i przetestowałem przed północą; proszę przeloguj się, odśwież stronę kilka razy (a jeżeli to nie pomoże wyczyść pliki tymczasowe), powinno być już ok. Dziękuje za czujność, pozdrawiam, Zdzislaw (dyskusja) 10:10, 14 sie 2015 (CEST)
- Proszę jeszcze o
- zamiana
_iv_
na_w_
- zamiana
_vv_
na_w_
- zamiana
cb_
nach_
- zamiana
cb.
nach.
- zamiana
cb,
nach,
- zamiana
cb:
nach:
- zamiana
cb;
nach;
- zamiana
cb?
nach?
- zamiana
cb!
nach!
Żaden słownikowy wyraz w j. polskim nie kończy się na "cb". Wieralee (dyskusja) 19:50, 15 sie 2015 (CEST)
- A może w ogóle zamienić
_cb
i_Cb
na_ch
i_Ch
. Przecież żaden wyraz w języku polskim nie zaczyna się "cb"? Vearthy (dyskusja) 11:25, 21 sie 2015 (CEST)
- A może w ogóle zamienić
Nawider (dyskusja) 21:27, 15 sie 2015 (CEST)
- kolejne zmiany wprowadzone, dziękuję @Wieralee, @Nawider: za pomoc. Zdzislaw (dyskusja) 21:41, 20 sie 2015 (CEST)
To ja się jeszcze dopiszę:
Ankry (dyskusja) 21:57, 20 sie 2015 (CEST)
- Proszę jeszcze o
- zamiana
_aui_
na_ani_
- zamiana
_sią_
na_się_
- zamiana
_sio_
na_się_
- zamiana
_juz_
na_już_
- zamiana
ó_
nać_
- zamiana
ćj
naéj
- zamiana
tć
naté
- zamiana
t. zw.
nat. zw.
Wieralee (dyskusja) 22:10, 20 sie 2015 (CEST)
Póki co to "popraw tekst OCR" jest dla prozy, a nie poezji, która jest przecież istotną częścią naszych zbiorów. Czy mógłbyś udostępnić oddzielny przycisk dla poprawy tekstów wierszowanych? Wystarczyłoby tylko wyłączyć opcję usuwania przejść do nowej linii. Pozdrawiam, Vearthy (dyskusja) 00:49, 21 sie 2015 (CEST)
- @Vearthy: dobry pomysł, postaram się w najbliższych dniach przygotować wersję testową. Zdzislaw (dyskusja) 12:16, 21 sie 2015 (CEST)
Moje propozycje:
Vearthy (dyskusja) 11:25, 21 sie 2015 (CEST)
Vearthy (dyskusja) 20:09, 26 sie 2015 (CEST)
- Dzięki sugestii Vearthy, Gadżet został wzbogacony o opcję poprawy tekstów wierszowanych (
<poem>
). Aby zmienić sposób działania Gadżetu należy w swoich Preferencjach zaznaczyć opcję opisaną: "Popraw tekst OCR dla poezji – dodaje przycisk ( w starym pasku narzędzi edycyjnych), który poprawia format tekstu dla poezji oraz typowe błędy OCR w oknie edycji proofread.
". @Vearthy: - czy było by pożądane aby jednocześnie z poprawą, gadżet dodawał na początku i końcu strony, znaczniki<poem></poem>
? Zdzislaw (dyskusja) 19:49, 26 sie 2015 (CEST) - @Zdzislaw: myślę, że raczej nie... tytuł zazwyczaj jest centrowany - i nie objęty "poemem". To samo, gdy są oznaczenia strof. Nie mówiąc już o sytuacjach, kiedy używamy "poem" do formatowania dramatów... Wieralee (dyskusja) 19:59, 26 sie 2015 (CEST)
- Mnie by odpowiadało mimo uwag Wieralee. Vearthy (dyskusja) 20:09, 26 sie 2015 (CEST)
- dodałem dodawanie znaczników
<poem></poem>
dla Poezji. Jeżeli nie będzie to komuś odpowiadało, będzie możliwość dezaktywacji dodawania znaczników, poprzez umieszczenie odpowiedniego kodu na swojej własnej stronie js (szczegóły zamieszczę na stronie opisu Popraw tekst OCR. Zdzislaw (dyskusja) 21:42, 26 sie 2015 (CEST
- dodałem dodawanie znaczników
- Proszę jeszcze o:
- usunięcie spacji przed
…
- zamiana
\v
naw
- zamiana
v/
naw
- myślałam jeszcze o zamianie
cb
nach
-- z wyjątkiem kombinacji "nicby", o ile takie zastrzeżenie jest możliwe... Wieralee (dyskusja) 18:40, 13 gru 2015 (CET)
- @Zdzislaw: bardzo dziękuję. Ale myślę o tym ostatnim przypadku... Znalazłam jeszcze na Wikiźródłach wyraz "więcby"... Ta partykuła "-by" może się zjawić w niespodziewanym użyciu, więc warunek musiałby brzmieć -- z pominięciem końcówki "-cby", o ile to w ogóle jest możliwe... A jeśli nie jest możliwe, to lepiej, żeby zostało w tej formie, bo występowanie "cb" zamiast "ch" jest 100 razy częstsze niż takie archaiczne zwroty... Wieralee (dyskusja) 22:40, 13 gru 2015 (CET)
- Proszę jeszcze o:
- zamiana
·
na spację — ale to by musiało być umiejscowione gdzieś na początku zmian, żeby potem w razie dwóch spacji załapało się na zamianę wielu spacji na jedną. Wieralee (dyskusja) 13:17, 20 gru 2015 (CET) - Zastanawiam się, czy nie byłoby wygodniej, gdyby była możliwość dodania do paska narzędzi opcji Popraw tekst OCR w poezji, tak aby można było w razie potrzeby przełączać się pomiędzy prozą a poezją, bez konieczności każdorazowego zaznaczania/odznaczania w preferencjach. Druga sprawa: czy możnaby dodać automatycznie <br /><br /><br /> po </poem>? Cafemoloko (dyskusja) 20:46, 9 sty 2016 (CET)
- Zrobione Zdzislaw (dyskusja) 22:25, 23 kwi 2016 (CEST)
- @Cafemoloko: ja już prosiłam Zdzislawa, żeby mi włączył obydwie opcje naraz, bo to bieganie po preferencjach było uciążliwe. Jestem jak najbardziej za dwoma, niezależnymi od siebie przyciskami ( Zrobione Zdzislaw (dyskusja) 22:25, 23 kwi 2016 (CEST)), nawet kosztem spowolnienia wczytywania się stron. Natomiast dodawanie automatem trzech br-ów po poemie to, wg mnie, zły pomysł. Bardzo często strona kończy się w połowie wiersza -- i wtedy te 3 b-ry są błędem, który nie zawsze może być wyłapany przez korektorów, którzy skupiają się bardziej na tekście. W ten sposób w przestrzeni głównej na stronach wierszy porobią się dziwne podziały wierszy na dziwne zwrotki. Wieralee (dyskusja) 22:34, 9 sty 2016 (CET)
Od dzisiaj, zgodnie z sugestiami, gadżet Popraw tekst OCR dla poezji, który dodaje przycisk ( w standardowym pasku narzędzi edycyjnych), jest niezależnym gadżetem. Dzięki temu można włączyć obie wersje (dla prozy i poezji) lub jedną wybraną, niezależnie od drugiej. Zdzislaw (dyskusja) 22:25, 23 kwi 2016 (CEST)
- Proszę jeszcze o:
- zamiana
(B|b)vł
na(B|b)ył
- zamiana
_ai_
na_aż_
- zamiana
_żc_
na_że_
- zamiana
\\’
naw
- zamiana
{{tab}}—_1_
na{{tab}}—_I_
- Bardzo proszę o wyłączenie domyślnego dodawania <poem> przy używaniu Popraw OCR dla poezji. Problem w tym, że żeby gadżet popoprawiał myślniki jak jest myślnik bez spacji, np. "oto-robotą", trzeba pododawać spacje i potem kliknąć gadżet jeszcze raz, a potem nieraz jeszcze raz... No i jak strona rozpoczyna się od wycentrowanego tytułu, to też kod się psuje... Ogółem chyba częściej usuwam te dodatkowe poemy, niż je dodaję. Dobrze by było, by była to opcja możliwa do włączenia przez usera w lokalnym css-ie, a nie odgórnie włączona dla wszystkich (niestety, lokalne wyłączenie po ostatnich aktualizacjach przestało działać). Wieralee (dyskusja) 23:15, 12 sty 2017 (CET)
- Zrobione Zdzislaw (dyskusja) 23:59, 12 sty 2017 (CET)
- Proszę jeszcze o:
_Bię_
na_się_
—_1_
na—_I_
źa
naża
źą
nażą
źe
naże
źę
nażę
źi
nażi
źo
nażo
źó
nażó
źu
nażu
źy
naży
_dła_
na_dla_
czvm
naczym
moźn
namożn
róźn
naróżn
iź_
naiż_
ćh
nach
to może jeszcze to:
- _011_ na _on_ Nawider (dyskusja) 20:35, 10 mar 2017 (CET)
- @Wieralee: tu:
_Bię_
na_się_
—_1_
na—_I_
mam wątpliwości... warto? Zdzislaw (dyskusja) 20:36, 4 cze 2017 (CEST)
- @Zdzislaw: warto. Ale jak bardzo nie chcesz, to chociaż propozycja nr 2 => ten błąd występuje w co drugim indeksie. Wieralee (dyskusja) 21:50, 4 cze 2017 (CEST)
- @Zdzislaw: czy można by dodać:
_c’_
na_ć_
_s’_
na_ś_
_z’_
na_ź_
--Fallaner (dyskusja) 07:31, 8 gru 2017 (CET)
albo bardziej ogólnie
c’
nać
s’
naś
z’
naź
n’
nań
o’
naó
_e,_
na_ę_
_a,_
na_ą_
i kolejne
_`
na_,
_7
na_,
--Fallaner (dyskusja) 22:22, 13 gru 2017 (CET)
ñ
nafi
--Fallaner (dyskusja) 15:30, 6 sty 2018 (CET)
si,
nasię
--Fallaner (dyskusja) 22:57, 7 mar 2018 (CET)
Identyfikator do adresowania
Mam taką propozycję na przyszłość, by do wszystkich szablonów używanych w kodzie stron, i skutkujących kodem html w tekstach dodać parametr id
przypisywany wewnątrz szablonu pierwszemu (nadrzędnemu) w kolejności elementowi html jaki będzie efektem działania szablonu. Chodzi o to by zamiast robić taką konstrukcję można było napisać {{tab|id=R}}
, natomiast zamiast robić takie kodowanie, można było napisać {{C|id=Starołęka|'''Starołęka.'''}}
. Umożliwiłoby to, w zależności od potrzeb, adresowanie z różnych innych miejsc tekstów, przypisów, dyskusji w skryptorium i z zewnątrz bezpośrednio do dowolnego miejsca tekstów bez zmiany wyglądu stron i komplikowania kodu. Tak na przyszłość, nic pilnego. 194.149.88.126 (dyskusja) 06:45, 22 sty 2017 (CET)
- Przeciw dodawaniu czegokolwiek, co nie jest absolutnie niezbędne do intensywnie (na dziesiątkach/setkach tysięcy stron) używanych szablonów Ankry (dyskusja) 09:59, 22 sty 2017 (CET)
- Przeciw poza powyższym, musisz wziąć pod uwagę specyfikę projektu ws, w którym teksty w przestrzeni głównej tworzone są głownie przez transkludowanie treści z przestrzeni Strona. Powoduje to, iż każdy znak (także style, dodatkowy kod html...) umieszczony w przestrzeni Strona doliczony jest do twardych limitów (Post-expand include size) parsera narzucanych nam przez oprogramowanie mediawiki. Dodawanie czegokolwiek, na wyrost, bo się przydać może... spowodować może, iż taki tekst zamiast pojawić się w przestrzeni głównej, w końcu zostanie zablokowany przez oprogramowanie z powodu przekroczenia limitów. Dlatego nie dodajemy niczego do tekstów, co nie jest niezbędne - pamiętaj, że naszym celem jest zamieszczenie treści, a nie tworzenie portali tematycznych, linkowanie z zewnątrz do kotwic z Page jest także niewskazane - pamiętaj że kolejny Skryba nie będzie miał możliwości powzięcia takiej wiedzy i może zmienić kod, a link pozostanie martwy. Zdaję sobie oczywiście sprawę, iż jako nowy Skryba, mogłeś nie zdawać sobie sprawy z obowiązujących nas limitów i dlatego takie pomysły. Ze względu na powyższe, proszę abyś niezwłocznie usunął ostatnio masowo wprowadzone przez Ciebie edycje kotwicowe (które dodajemy tylko gdy są niezbędne, a których przykłady podajesz), typu:
<a name="Z">{{tab}}</a>
,<span id="B">{{tab}}</span>
, a które nie są wykorzystywane, i ich mnożenie w mojej opinii jest działaniem na szkodę projektu. Poza powyższym, takie adresowanie identyfikatorów, które transkludowane będą do przestrzeni głównej z wielu stron, może spowodować iż id się zdublują, a to jest typowym błędem składni html (zdajesz sobie sprawę, że musimy dbać o stabilność naszych stron). Możesz oczywiście zwrócić się do programistów mediawiki o zwiększenie tych limitów (co będzie trudne, ponieważ są one jednolite dla wszystkich wiki) i wtedy zastanowimy się nad jakimś innym mechanizmem kotwicowania automatycznego w tekstach - mw próbowała już to automatyzować lecz na razie szybko wycofała się z tego pomysłu. Możesz także tego typu działania przenieść na inne portale literaturowe działające na otwartym oprogramowaniu mw, a prowadzone przez osoby prywatne, czy inne organizacje. Zdzislaw (dyskusja) 12:15, 22 sty 2017 (CET)
- Przeciw limity są naprawdę niskie, już niejednokrotnie musieliśmy "kombinować" poprzez "odchudzanie szablonów" i inne manewry, żeby móc dla niektórych książek zrobić stronę całości. Może to wpłynąć także na zawieszanie się w renderowaniu WS Eksportera. Dopóki nie dostaniemy nowego oprogramowania do proofreadu, wstrzymajmy się może z wynalazkami. Wieralee (dyskusja) 13:34, 22 sty 2017 (CET)
Załatwione KaMan (dyskusja) 07:55, 4 maj 2017 (CEST)
- Otóż drogi KaMan, nic nie jest załatwione. Twój powyższy komentarz pokazuje jedynie, iż wykonałeś pewne działania pomimo całkowitego sprzeciwu społeczności. Poza tym, takie podsumowanie tego wątku przez ciebie wprowadza społeczność w błąd, odnośnie do przyjęcia zwyczaju dodawania identyfikatora do każdego szablonu i miejsca w tekście gdzie on powinien występować. Jak widać po powyższych głosach, propozycja dodania wszędzie ip spotkała się ze sprzeciwem społeczności. Ty jako jej kontynuator (i nie tylko), tym razem w dyskusjach z administratorami, pomimo tutejszego sprzeciwu, nalegałeś na wprowadzenie mechanizmów identyfikacji treści. W odpowiedzi, został zaproponowany prosty sposób umieszczania kotwic w tekście, nie obciążający limitami żadnych innych szablonów oraz w pełni zgodny ze standardami html i silnikiem mw (szablon ze spaem z id bez treści). Odrzuciłeś, bez żadnych rzeczowych argumentów tą propozycję. Aby pójść Ci na rękę po Twojej deklaracji No to spróbuję na tej kucharce którą wybrałem do testu dodaliśmy na próbę dodatkowe parametry id do bardzo obciążonych limitami szablonów F, C.
- Niestety, chciałoby się powiedzieć jak zwykle, zamiast wykorzystując dostępne możliwości (które były wystarczające) do pokazania sensowności obciążania kolejnych szablonów dodatkowym kodem, zanim w połowie skończyłeś Kucharkę i moglibyśmy chociaż w części zaznajomić się z twoimi pomysłami... rozpocząłeś realizację działań, które właśnie w powyższym wątku spotkały się ze stanowczym sprzeciwem: dodałeś parametr id do kolejnych 28. szablonów, rozpocząłeś masowe dodawanie lub zamianę szablonów na parametr id na stronach, także w innych indeksach, (co ciekawe, nawet w takich których nie tworzyłeś) w większości, wstawiając id tam gdzie potencjalnie się przyda, bo potem, tak lub nie, będzie linkować z indeksu lub spisu treści. Wielokrotnie uczulaliśmy, aby zwracać uwagę na limity i ograniczenia projektu, tak aby, po pozostawieniu przez Ciebie rozpoczętych wielu indeksów i prac, można było w sposób przystępny i prosty kontynuować pracę. Jaki jest tego efekt? Przez ostatnie dni m.in. przybyło nam ok. 50 szablonów...
- Reasumując, w związku z powyższym, proponuję usunięcie wywołań id ze stron, w których one nie są wykorzystywane, oraz rozważenie wprowadzenia zasady sposobu realizacji kotwic w postaci neutralnego wywołania - jedynie w postaci "pustego" wywołania span z id
<span id="identyfikator"></span>
, który w postaci szablonu mógłby być dodany przed jakimkolwiek obiektem, nie obciążałby innych szablonów, oraz ułatwił i ujednolicił pracę w przyszłości. Który to już raz realizujesz swoje działania, jedynie po to, aby metodą faktów dokonanych (np. masowe zmiany w nietworzonym przez ciebie indeksie przed pokazaniem zasadności tych zmian u siebie) wprowadzić swój porządek, bez jakiejkolwiek konsultacji czy uzyskania konsensusu? Zdzislaw (dyskusja) 12:00, 4 maj 2017 (CEST)
Nowy sposób realizacji podpowiedzi w wyszukiwarce
W związku z wprowadzeniem, na prośbę międzynarodowej społeczności Wikiźródeł, nowego sposobu realizacji podpowiedzi w wyszukiwarce, proszę o jego przetestowanie. Należy tym celu zmienić domyślny sposobu wyszukiwania w Wikiźródłach. W zakładce preferencji wyszukiwania należy wybrać opcję:
Tryb przekierowań z dopasowywaniem podfraz (zaawansowane)
.
To ustawienie pozwoli na uzyskiwanie podpowiedzi wyszukiwania także z uwzględnieniem podstron i przekierowań.
W Wikiźródłach wiele utworów znajduje się na podstronach głównej pozycji książkowej. Są to między innymi wiersze, eseje, opowiadania, nowele, artykuły biograficzne itp. Z tego powodu podpowiedzi wyszukiwana mogą nie być poprawnie wyświetlane dla domyślnego sposobu wyszukiwania lub mogą być traktowane mniej priorytetowo. Proszę o Wasze uwagi i spostrzeżenia. Zdzislaw (dyskusja) 23:07, 30 kwi 2017 (CEST)
- @Zdzislaw: Niestety, zaawansowany tryb wyszukiwania przy kliknięciu "Przejdź", a nie "Szukaj" ssie. Konieczność przewijania całego ekranu (pół ekranu zajmują "wskazówki", drugie pół lista przestrzeni nazw wyszukiwania zaawansowanego) lub nawet więcej (na małym ekranie) gdy się chce utworzyć kilka nowych stron, jest dość uciążliwa. Jak wyłączyć zaawansowane opcje wyszukiwania? Ankry (dyskusja) 13:40, 17 cze 2017 (CEST)
- @Ankry: obawiam się (a właściwie już mam pewność :) ), iż tryb zaawansowany to problem po stronie Twoich osobistych ustawień :) Zdzislaw (dyskusja) 22:26, 17 cze 2017 (CEST)
- Tak, do tego już doszedłem :) Dzięki za "odchudzenie" komunikatu. Ankry (dyskusja) 22:43, 17 cze 2017 (CEST)
- @Ankry: obawiam się (a właściwie już mam pewność :) ), iż tryb zaawansowany to problem po stronie Twoich osobistych ustawień :) Zdzislaw (dyskusja) 22:26, 17 cze 2017 (CEST)
Zmiany/Sprzątanie kodów js - wycofywanie wsparcia starych skryptów ##
Witam, w środowisku mw realizowane jest sukcesywne wycofywanie wsparcia starych funkcji i skryptów js. Niesie to za sobą konieczność wprowadzania zmian w naszych skryptach i gadżetach. Wyłączenie bezpośredniego wsparcia mw dla niektórych funkcji js, między innymi w ostatnich dniach, było przyczyną zniknięcia menu pobierania naszych utworów w zewnętrznych formatach. Proszę o zgłaszanie pojawiających się nieprawidłowości. Jakoby przy okazji zaistniała także potrzeba zinwentaryzowania naszych skryptów, które w ciągu lat powiększały nasz lokalny common.js. Wiele z nich zastąpione zostały już lata temu natywnymi bliźniaczymi skryptami mediwiki, i ich utrzymywanie i konserwacja lokalna, w mojej ocenie, stała się zbędna. Postanowiłem zatem niespiesznie zacząć sprzątać nasze zasoby.
- Na pierwszy ogień biorę lokalną obsługę galerii, której skrypty wspomagają {{Szablon:Galeria}} - wykorzystywany jest on właściwie zaledwie na dwóch stronach i w mojej ocenie może zostać zastąpiony natywnymi skryptami galerii oferowanymi przez nasze oprogramowanie mw:Help:Images#Rendering_a_gallery_of_images - proszę o ewentualne głosy przeciwne takiej zamianie w tym wątku.
- Zrobione, [1], [2] Zdzislaw (dyskusja) 18:30, 4 cze 2017 (CEST)
- Kolejny skrypt to dynamiczne ukrywanie bloków i tabelek w:en:Wikipedia:NavFrame, które już od 2007 posiadają swój natywny odpowiednik w oprogramowaniu mediawiki. Ich (lokalnych skryptów) wykorzystanie jest u nas także dosyć ograniczone. Poza kilkoma stronami użytkowników, jest on używany przez {{Szablon:Navbox}} oraz kilka stron. Zamierzam zastąpić te wywołania natywnym mechanizmem mw:Manual:Collapsible_elements. Proszę także o ewentualne uwagi i wnioski przeciwne.
- @Zdzislaw: wielkie dzięki! Wieralee (dyskusja) 19:10, 4 cze 2017 (CEST)
kolorowanie stron
Zauważyłem dzisiaj, że MediaWiki pozwala mi na wprowadzenie strony od razu uwierzytelnionej (na zielono). Kilka dni temu na pewno tego efektu nie było. Nie wiem, czy jest to wynik jakichś moich zmian w konfiguracji, czy efekt nowej wersji MediaWiki; nie wiem też jeszcze, czy dotyczy tylko administratorów, wszystkich użytkowników, czy również niezalogowanych.
W każdym razie zmiana wydaje mi się niepożądana. Ankry (dyskusja) 14:46, 9 cze 2017 (CEST)
- potwierdzam zmianę, dotyczy ona jedynie administratorów, dla innych jest po staremu. nie wiem skąd ona wynika, lecz nie wydaje mi się aby admini jej nadużywali. inna sprawa to przyzwyczajenie Zdzislaw (dyskusja) 15:37, 9 cze 2017 (CEST)
- I już jasne: phab:T167491, nowe uprawnienie domyślnie dodane do grupy adminow, nie wiem tylko czy świadomie dla wszystkich ws Zdzislaw (dyskusja) 16:04, 9 cze 2017 (CEST)
- Widzę, że zmiana została wycofana. Ankry (dyskusja) 22:14, 9 cze 2017 (CEST)
Filtry "nadużyć"
W ostatnich dniach wprowadziłem następujące zmiany w filtrach:
- Poprawiłem nieznacznie filtr wykrywający błędne edycje wykonane przy użyciu VE.
- Włączyłem blokadę zapisu dla filtru wykrywającego pomyłki pp/pk.
- Utworzyłem filtr blokujący możliwość tworzenia żółtych stron od razu w pierwszej edycji.
- Utworzyłem filtr blokujący możliwość zmiany statusu czerwony -> żółty przez użytkownika, który ostatnio nadał stronie status czerwony (może nie działać prawidłowo w przypadku edycji przy użyciu VE).
Niestety, nie jest wykonalne na poziomie filtrów zablokowanie możliwości zazielenienia strony przez użytkownika, który ją wprowadził.
Proszę o ewentualne opinie. Ankry (dyskusja) 09:58, 18 cze 2017 (CEST)
- pozostaje jedynie podziękować, to rozwiązuje problem ułomności konfiguracyjnej rozszerzenia proofread i odciąża nas wszystkich od potrzeby sprawdzania edycji pod tym kątem (szczególnie początkujących). Co do zablokowania zazielenienia przez wprowadzającego, pozostaje js, lecz rzecz jest do przedyskutowania pod względem przewagi korzyści nad dodatkowym obciążaniem ładowania poprzednich edycji przez skrypt, przygotuję takie rozwiązanie w js do testów, na razie jako opcjonalny gadżet, Zdzislaw (dyskusja) 17:48, 18 cze 2017 (CEST)
- @Ankry: ten skrypt załatwia powyższy problem, jeżeli masz ochotę dodaj do swojego js, potestuj, jeżeli ocenisz, iż nie obciąża zbytnio, i gra jest warta świeczki, można dodać do naszego common-a. Zdzislaw (dyskusja) 22:48, 24 cze 2017 (CEST)
Improvements coming soon to Recent Changes
Hello
Sorry to use English. Pomóż przetłumaczyć na Twój język! Dziękuję.
In short: starting on 26 September, New Filters for Edit Review (now in Beta) will become standard on Recent Changes. They provide an array of new tools and an improved interface. If you prefer the current page you will be able to opt out. Learn more about the New Filters.
What is this feature again?
This feature improves Special:RecentChanges and Special:RecentChangesLinked (and soon, Special:Watchlist – see below).
Based on a new design, it adds new features that ease vandalism tracking and support of newcomers:
- Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
- Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
- Bookmarking to keep your favorite configurations of filters ready to be used.
- Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help. They are not available on all wikis.
You can know more about this project by visiting the quick tour help page.
Concerning RecentChanges
Starting on 26 September, New Filters for Edit Review will become standard on Recent Changes. We have decided to do this release because of a long and successful Beta test phase, positive feedback from various users and positive user testing.
Some features will remain as Beta features and will be added later. Learn more about those different features.
If your community has specific concerns about this deployment or internal discussion, it can request to have the deployment to their wikis delayed to October 1, if they have sensible, consistent with the project, actionable, realistic feedback to oppose (at the development team's appreciation).
You will also be able to opt-out this change in your preferences.
Concerning Watchlists
Starting on September 19, the Beta feature will have a new option. Watchlists will have all filters available now on the Beta Recent Changes improvements.
If you have already activated the Beta feature "⧼eri-rcfilters-beta-label⧽", you have no action to take. If you haven't activated the Beta feature "⧼eri-rcfilters-beta-label⧽" and you want to try the filters on Watchlists, please go to your Beta preferences on September 19.
How to be ready
Please share this announcement!
Do you use Gadgets that change things on your RecentChanges or Watchlist pages, or have you customized them with scripts or CSS? You may have to make some changes to your configuration. Despite the fact that we have tried to take most cases into consideration, some configurations may break. The Beta phase is a great opportunity to have a look at local scripts and gadgets: some of them may be replaced by native features from the Beta feature.
Please ping me if you have questions.
On behalf of the Global Collaboration team, Trizek (WMF) 17:27, 14 wrz 2017 (CEST)
HTML5, xHTML i br-y
W związku ze stopniowym zarzucaniem przez MediaWiki porzuconego standardu xHTML (patrz T150172), zdecydowaliśmy nie promować jego używania również u nas i nie zalecać używania <br /> lecz raczej sugerować standardowy, zgodny z HTML5, <br>. Co to oznacza? Oznacza to, że standardowe narzędzia, takie jak np. SK, nie będą już zamieniać <br> na <br /> a będą sugerować raczej używanie <br>. Podobna zmiana dotyczy przybornika. Jednakże, stary <br /> nadal działa poprawnie i nie zanosi się, by w najbliższym czasie miało być inaczej. W związku z tym, nie planujemy masowego botowania strych tekstów (chociaż mogą być w nich wykonywane zmiany <br /> na <br > przy okazji innych edycji).
Dzięki Zdzislawowi narzędzia automatyzacji słowników są już niewrażliwe na użyty format br-a (oba są traktowane jako prawidłowe i równoprawne)
Przy okazji, dodatkową korzyścią może być nieznaczne odchudzenie tekstów, które być może pozwoli nam odrobinę rzadziej natrafiać na problem limitów MediaWiki.
Szablon {{---}} po lewej stronie
Czy istnieje jakiś sposób na zrobienie takiej kreski:
, ale żeby nie była na środku, ale po lewej, jak np. tu? Grawiton (dyskusja) 21:15, 13 gru 2017 (CET)
- Jest: np. umieścić ją w div-ie z display=table. O tak:
- Ale tu wg mnie jest inny problem: to jest przypis, a przypisy zwykliśmy umieszczać w stopce strony (razem z np. numeracją stron, jeśli ktoś ją wprowadza), żeby po scaleniu umożliwić umieszczenie wszystkich na końcu. W tekście mogą się pojawić przypisy, których nie ma w książce. W tym przypadku, bez pocięcia książki na strony nie da się tego dobrze odwzorować. Ankry (dyskusja) 21:30, 13 gru 2017 (CET)
- @Grawiton: nie ma takiej potrzeby w miejscu, które wskazałeś. Ze względu na sposób tworzenia stron w przestrzeni głównej oraz wykorzystywane rozszerzenie Proofread do tworzenia stron w przestrzeni Page, nie umieszczamy w treści strony tagów <references/>, są one automatycznie dodawane do stopki ( w takich przypadkach rezygnujemy z dokładnego odwzorowania formy ze strony. Poprawiłem przywołaną stronę. Zdzislaw (dyskusja) 21:35, 13 gru 2017 (CET)
- Dziękuję, tak czy siak się przyda. Grawiton (dyskusja) 11:32, 14 gru 2017 (CET)
Domena Wikiźródła.pl
Może ktoś jeszcze pamięta, że kilka lat temu zarejestrowałem na siebie taką domenę. Były kiedyś plany zrobienia tam wyszukiwarki i bloga, ani jedno ani drugie nie wypaliło. Technicznie zawiadywał stroną @Beau:. Obecnie jest tam głównie przekierowanie do pl.wikisource.org i resztki bloga. Ponieważ chciałbym się pozbyć konta na OVH i domeny (tudzież opłat z tym związanych), informuję tutaj - jeżeli ktoś ze Społeczności jest chętny, mogę to oddać (jeżeli ktoś dokładnie mi powie jak). Jeżeli chętnych nie będzie, poproszę Beau o usunięcie wszystkiego. --Teukros (dyskusja) 22:21, 17 gru 2017 (CET)
- @Teukros: Dzięki za to powiadomienie i za poświęcenie prywatnych pieniędzy na rzecz społeczności przez tych 8 lat. Bardzo przykro byłoby tracić taką cenną domenę, a ponieważ Wikimedia Polska w przeszłości zdecydowało, że nie chce opłacać domen, które nie są znakami towarowymi, ja ofiaruję się przejąć domenę i opłacać ją przez kilka lat (i oczywiście przekazać WMPL/WMF, jeśli takie będzie ich życzenie). Domena, jak widzę, jest ważna do 11 maja 2018, więc spokojnie powinniśmy zdążyć z wszystkimi formalnościami. Czy możemy założyć, że jeśli do nowego roku nikt nie zgłosi chęci zaopiekowania się domeną, wówczas domyślnie przejmę ją ja? Dzięki, odder (dyskusja) 23:31, 19 gru 2017 (CET)
- @Odder:, oczywiście. Do tej pory nikt inny ze mną się nie skontaktował, więc zaraz po nowym roku możemy dokonać przekazania. Mam nadzieję, że przeprowadzisz sprawę od strony technicznej, bo ja nie mam pojęcia jak to zrobić. --Teukros (dyskusja) 18:46, 30 gru 2017 (CET)
- @Teukros: Jakieś wieści w tej kwestii? odder (dyskusja) 01:47, 16 sty 2018 (CET)
- Załatwione i przesłane na maila. Przepraszam za opóźnienie. --Teukros (dyskusja) 18:19, 16 sty 2018 (CET)
- Domena jest już moją własnością i została opłacona na kolejnych 5 lat, więc temat możemy zamknąć. Podziękowania dla @Teukrosa za pomoc w tej sprawie. odder (dyskusja) 15:43, 15 lut 2018 (CET)
- Załatwione i przesłane na maila. Przepraszam za opóźnienie. --Teukros (dyskusja) 18:19, 16 sty 2018 (CET)
- @Teukros: Jakieś wieści w tej kwestii? odder (dyskusja) 01:47, 16 sty 2018 (CET)
- @Odder:, oczywiście. Do tej pory nikt inny ze mną się nie skontaktował, więc zaraz po nowym roku możemy dokonać przekazania. Mam nadzieję, że przeprowadzisz sprawę od strony technicznej, bo ja nie mam pojęcia jak to zrobić. --Teukros (dyskusja) 18:46, 30 gru 2017 (CET)
- Również dziękuję Ci @Teukros: za to, że opłacałeś tę domenę z własnych środków. Decyzji Stowarzyszenia nie rozumiem i uważam ją za żenującą. Nostrix (dyskusja) 23:54, 20 mar 2018 (CET)
Proofread a OOui
Trwa właśnie przeprojektowywanie interfejsu ProofreadPage na nowy layout. Jeśli macie jakieś uwagi w tej kwestii, to może warto je przekazać Tpt lub Samowi W. tutaj... Ankry (dyskusja) 10:14, 28 sty 2018 (CET)
@Ankry: czyli te wszystkie problemy z tworzeniem stron (dodawanie noinclude, wyrzucaniem tekstu itp.) związane są z przeprojektowywaniem interfejsu? Nawider (dyskusja) 22:27, 15 lut 2018 (CET)
Nie wiem, o jakie konkretnie problemy chodzi, ale nie wydaje mi się. Zmieniają jego wygląd przede wszystkim. Ankry (dyskusja) 22:31, 15 lut 2018 (CET)
- Problemy obejmują pasek narzędzi, przybornik oraz gadżety skrótów klawiszowych. Są związane z innymi zmianami w mw phab:T187454 - powinny zostać rozwiązane dziś w nocy. Zdzislaw (dyskusja) 22:37, 15 lut 2018 (CET)
- Też natrafiłem na te same problemy, co
jaNawider. Repro: w przestrzeni Strona podczas edycji użyj dowolnego skrótu klawiaturowego ze swojego common.js Dokleja się mnóstwo śmieci, które powinny trafić albo do stopki (references itp.) albo być niewidoczne (pagequality). Wtedy Pokaż podgląd unaocznia skalę zniszczenia. Mieliśmy już taki problem parę miesięcy temu :-/ Bonvol (dyskusja) 22:40, 15 lut 2018 (CET) - @Zdzislaw:thx Nawider (dyskusja) 23:02, 15 lut 2018 (CET)
- Nocne wdrożenie pomogło — działa już poprawnie. Bonvol (dyskusja) 07:22, 16 lut 2018 (CET)
- Też natrafiłem na te same problemy, co
Global preferences available for testing
Apologies for writing in English. Pomóż przetłumaczyć na Twój język.
Greetings,
Global preferences, a highly request feature in the 2016 Community Wishlist, is available for testing.
- Read over the help page, it is brief and has screenshots
- Login or register an account on Beta English Wikipedia
- Visit Global Preferences and try enabling and disabling some settings
- Visit some other language and project test wikis such as English Wikivoyage, the Hebrew Wikipedia and test the settings
- Report your findings, experience, bugs, and other observations
Once the team has feedback on design issues, bugs, and other things that might need worked out, the problems will be addressed and global preferences will be sent to the wikis.
Please let me know if you have any questions. Thanks! --Keegan (WMF) (talk) 01:24, 27 lut 2018 (CET)
Notification from edit summary
Greetings,
The ability to notify other users in edit summaries will be available later this week, on 15 March 2018. Other users can be notified if a link to their user page is provided in an edit summary. Some user-made gadgets and scripts that automatically put user names in edit summaries may need to be changed to put a colon in the link, such as [[:User:Example]]. You can change how you receive these mention notifications in your preferences. This feature was highly requested in the 2017 Community Wishlist survey, and feedback is welcome.
Thanks, happy editing to you. -Keegan (WMF) (talk) 22:09, 12 mar 2018 (CET)
We need your feedback to improve Lua functions
Hello,
(I’m sorry for writing in English. Pomóż przetłumaczyć na Twój język)
If you’re regularly using Lua modules, creating and improving some of them, we need your feedback!
The Wikidata development team would like to provide more Lua functions, in order to improve the experience of people who write Lua scripts to reuse Wikidata's data on the Wikimedia projects. Our goals are to help harmonizing the existing modules across the Wikimedia projects, to make coding in Lua easier for the communities, and to improve the performance of the modules.
We would like to know more about your habits, your needs, and what could help you. We have a few questions for you on this page. Note that if you don’t feel comfortable with writing in English, you can answer in your preferred language.
Dziękujemy! Lea Lacroix (WMDE) 10:56, 27 mar 2018 (CEST)
Wikitext highlighting out of beta
Wikitext syntax highlighting, also known as CodeMirror, has been moved out of Beta Features and is available in the 2017 Wikitext Editor on all wikis. Syntax highlighting helps you see problems in your wikitext before previewing or publishing text. Please try out the tool if you did not do so while it was being developed, and feedback is welcome. - Keegan (WMF) (talk)
20:56, 4 maj 2018 (CEST)
W Biblii Wujka występuje taki szablon {{BW problem}}
na przykład na np. stronie 274:
<ref> Eccl. 46, 21. ({{BW problem|Księgi Mądrości Syracha}}) </ref>
co daje efekt:
Eccl. 46, 21. (Błąd w druku; odsyłacz do Księgi Mądrości Syracha, nie występującej w tym wydaniu Biblii.)
proponuję zmianę wyniku działania szablonu na:
Eccl. 46, 21. (Odsyłacz do Księgi Mądrości Syracha, nie występującej w tym wydaniu Biblii.)
Uzasadnienie: Fakt, iż w tym konkretnym wydaniu Biblii nie ma danego rozdziału, odniesienie do niego nie jest w żadnym wypadku błędem i taki przypis może być mylący dla czytelnika. --Fallaner (dyskusja) 11:07, 27 maj 2018 (CEST)
- Wydaje mi się jednak, że jest to błąd (może nie tyle drukarza, co wydawcy):
- jeśli jest to odsyłacz, to powinien on odsyłać do czegoś co jest w danej książce, a nie do czegoś, czego w niej nie ma
- jeśli jest to adnotacja, to OK.
- Za tym, że pozostawienie odsyłaczy do niezamieszczonych ksiąg niekoniecznie było intencją wydawcy przemawia do mnie fakt, usunięcia przez niego oryginalnych komentarzy Wujka (zgodnie zresztą z duchem protestanckim).
- Być może, gdyby się okazało, że pozostawił wszystkie oryginalne odsyłacze do wszystkich niezamieszczonych ksiąg, byłby to argument za tym, że jest to celowe działanie a nie błąd. Nie podejmuję się jednak tego na tym etapie zweryfikować (chyba trzeba by najpierw dokończyć starsze wydanie, żeby było z czym porównać). Ankry (dyskusja) 13:33, 27 maj 2018 (CEST)
Update on page issues on mobile web
Update on page issues on mobile web
Pomóż przetłumaczyć na Twój język Hi everyone. The Readers web team has recently begun working on exposing issue templates on the mobile website. Currently, details about issues with page content are generally hidden on the mobile website. This leaves readers unaware of the reliability of the pages they are reading. The goal of this project is to improve awareness of particular issues within an article on the mobile web. We will do this by changing the visual styling of page issues.
So far, we have drafted a proposal on the design and implementation of the project. We were also able to run user testing on the proposed designs. The tests so far have positive results. Here is a quick summary of what we learned:
- The new treatment increases awareness of page issues among participants. This is true particularly when they are in a more evaluative/critical mode.
- Page issues make sense to readers and they understand how they work
- Readers care about page issues and consider them important
- Readers had overwhelmingly positive sentiments towards Wikipedia associated with learning about page issues
Our next step would be to start implementing these changes. We wanted to reach out to you for any concerns, thoughts, and suggestions you might have before beginning development. Please visit the project page where we have more information and mockups of how this may look. Please leave feedback on the talk page.
Kolorowanie stron w indeksie
Może niektórzy zauważyli, a może nie, że wczoraj przestało działać kolorowanie niektórych stron, zwłaszcza w starszych indeksach, (przykład). Jak wynika z phab:T198470 jest to związane z zeszłoroczną zmianą struktury stron. Wydaje się, że jedynym sensownym rozwiązaniem jest masowa edycja stron przez bota (w postaci "pustych" edycji, które de facto pustymi nie są). Bot już nad tym pracuje. To może być nawet kilkaset tysięcy edycji. Ankry (dyskusja) 10:36, 30 cze 2018 (CEST)
Consultation on the creation of a separate user group for editing sitewide CSS/JS
(Pomóż przetłumaczyć na Twój język)
Hi all,
I'm preparing a change in who can edit sitewide CSS/JS pages. (These are pages like MediaWiki:Common.css
and MediaWiki:Vector.js
which are executed in the browser of all readers and editors.) Currently all administrators are able to edit these pages, which poses a serious and unnecessary security risk. Soon, a dedicated, smaller user group will take over this task. Your community will be able to decide who belongs in this group, so this should mean very little change for you. You can find out more and provide feedback at the consultation page on Meta. If you are involved in maintaining CSS/JS code, or policymaking around adminship requests, please give it a look!
Thanks!
Tgr (talk) 12:50, 9 lip 2018 (CEST) (via global message delivery)