Wikiźródła:Skryptorium/Pulpit techniczny/Archiwum

Ta strona ma charakter historyczny bądź archiwalny. Prosimy nie modyfikować tej strony.

Sprzątanie kodu

"Przeniosłem" z Wikipedii skrypt Nuxa sprzątający kod w artykule, tzn. doprowadzający go do pewnych określonych standardów (takich jak np. Plik: zamiast starego Grafika:, sortowanie interwiki, przerzucanie interwiki pod kategorię, spacje w nagłówkach sekcji itd.). Skrypt nie jest obecnie dostępny w "gadżetach" na stronie preferencji. Aby go sobie uruchomić, należy we własnym monobooku dodać następujące linijki kodu:

var wp_sk_show_as_button = true; // pokazuj przycisk
importScript('Wikiskryba:Awersowy/wp_sk.js')

a następnie odświeżyć cache przeglądarki. Dokładne informacje na temat działania skryptu znajdują się na stronie Wikipedii: Wikiprojekt:Sprzątanie kodu. Przykładowe użycie skryptu na Wikiźródłach: [1]. awersowy # 20:21, 9 maj 2009 (CEST)

Dla wygody dodałem do gadżetów. sp5uhe ^{dyskusja edycje} 00:08, 14 maj 2009 (CEST)

• W sprawie innych skryptów: w przestrzeni wikiskryby obecnie testuję działanie skryptu wyświetlającego pod nazwą artykułu np. taki komunikat:

Ostatnio edytowany przez Awersowy (wkład, dyskusja, zablokuj) (1x). Wcześniej edytował Teukros (wkład, dyskusja, zablokuj).

Gadżet oczywiście pochodzi z Wikipedii: EditHysteria. Do działania potrzebuje jednak jeszcze tego skryptu. Chciałbym przy okazji poddać pod rozwagę wprowadzenie następnych gadżetów: QuickEditCounter, Odpowiedzi z linkami i HotCat. awersowy # 00:52, 21 maj 2009 (CEST)

Zmiany techniczne w wikiźródłach

W związku z moją kandydaturą chciałbym przedyskutować zmiany, które będę chciał wprowadzić o ile otrzymam uprawnienia.

Zaadaptowanie rozwiązań z Wikipedii

Ogólnie ma to polegać na tym, że będę chciał upodobnić mechanizmy działające w tym projekcie do tych z Wikipedii. Mam tu na myśli sposób działania niektórych szablonów i gadżetów. Jaki jest cel tego działania? Chodzi mi o zmniejszanie różnic, tak aby bariera przechodzenia między projektami była jak najmniejsza - umożliwi sprawne edytowanie kilku projektów (nie trzeba będzie się zastanawiać, a jak to działa tutaj itp.).

Standaryzacja szablonów

Chciałbym zmigrować szablony problemów na wykorzystanie {{ambox}} (szablon używany na wielu innych projektach), aby komunikaty miały jednakowy wygląd. Chciałbym też poprzenosić szablony (z zachowaniem starych nazw jeśli to tylko możliwe) pod nazwy podobnych szablonów z Wikipedii (patrz #Zaadaptowanie rozwiązań z Wikipedii).

Zauważyłem też problem z marnowaniem miejsca. Dużo szablonów prezentuje sobą pustkę - chociażby nagłówek na tej stronie. Mam rozdzielczość 1024x768 i monitor 17 calowy - często na różnych stronach muszę używać suwaka, chciałbym szablony przerobić na bardziej kompaktowe.

Gadżety

• Chciałbym dodać możliwość wybrania wyszukiwarki na stronie Specjalna:Szukaj (patrz w:Specjalna:Szukaj, w:Mediawiki:Common-Search.js)
• Dodać kilka ułatwień dla sysopów (patrz w:MediaWiki:Common-Sysop.js)
• Dodać nowe elementy interfejsu na stronie wkładu itp. (patrz w:MediaWiki:Sp-contributions-footer-anon, w:MediaWiki:Sp-contributions-footer)
• Dodać domyślnie włączony gadżet umożliwiający wstawianie automatycznych opisów zmian

Uruchomienie bota

Chciałbym włączyć realizowanie kilku zadań przez mojego bota

• Wstawianie na nowe strony szablonów {{kategoria}} oraz Kategoria:? (czy co tu jest lokalnie), {{linki}} na wzór Wikipedii
• sprawdzanie przez stron użytkowników i usuwanie ich z kategorii (stworzyć listę wyjątków dla kategorii społecznościowych itp.)
• okresowe resetowanie brudnopisu
• poprawka przekierowań do innych projektów poprzez wstawianie szablonu {{softredirect}}
• naprawianie podwójnych przekierowań

To na razie tyle. Jak mi coś więcej przyjdzie do głowy, to będę dodawał w nowych sekcjach. Beau 12:53, 23 wrz 2009 (CEST)

Modyfikacja standardowych podpisów

Zrobione
Aby wymiana wiadomości pomiędzy wszystkimi uczestnikami przebiegała łatwiej, proszę o zmianę domyślnego wzoru podpisu:

• MediaWiki:Signature-anon

[[{{#special:Contributions}}/$1|$2]] ([[{{ns:user_talk}}:$1|dyskusja]])

• MediaWiki:Signature

[[{{ns:user}}:$1|$2]] ([[{{ns:user_talk}}:$1|dyskusja]])

Osoby z niezdefiniowanym podpisem będą miały od momentu wprowadzenia zmiany dodawany automatycznie link do strony dyskusji. Beau 18:11, 24 wrz 2009 (CEST)

Przenosiny strony głównej

Zrobione
Chciałbym przenieść Stronę główną pod nazwę Wikiźródła:Strona główna, ponieważ nie jest to tekst, a meta strona. W starym miejscu pozostanie przekierowanie. Beau (dyskusja) 12:13, 3 paź 2009 (CEST)

Zmiany w przestrzeniach nazw

Załatwione

• Nowy alias dla przestrzeni Wikiźródła <- WS, obecne przekierowania siedzą niepotrzebnie w przestrzeni głównej.
• Zmiana za Wikipedią Dyskusja Wikiskryby na Dyskusja wikiskryby, a pozostawienie starej nazwy jako alias.

Potrzebuję kilka podpisów z  Za lub  Przeciw, żeby uwiarygodnić zgłoszenie na bugzilli. :-) Beau (dyskusja) 12:10, 3 paź 2009 (CEST)

•  Za Oczywiście, "Wikiskryba" pisany wielką literą to ort. ;). awersowy # 12:01, 5 paź 2009 (CEST)
•  Za --Teukros (dyskusja) 14:11, 7 paź 2009 (CEST)

Wysłałem zgłoszenie - bugzilla:21034. Beau (dyskusja) 14:06, 7 paź 2009 (CEST)

Nowe źródła do importu stron

Załatwione Obecnie na projekt można importować strony z Wikipedii, Wikibooks oraz Wikicytatów. Chciałbym dodać do tego Wikinews, Wikisłownik oraz wikisources.org, z którego trzeba przy pomocy transwiki zaimportować historie haseł, które wcześniej zostały niepotrzebnie przeniesione przez bota.

'plwikisource' => array( 'w', 'b', 'q', 'n', 'wikt', 'oldwikisource' ),

Potrzebuję kilka podpisów z  Za lub  Przeciw, żeby uwiarygodnić zgłoszenie na bugzilli. Beau (dyskusja) 21:57, 3 paź 2009 (CEST)

1. Zdecydowanie  Za. Taki mechanizm z pewnością się przyda. --Teukros (dyskusja) 22:15, 3 paź 2009 (CEST)
2.  Za Mechanizm bardzo przydatny. Patrol110 (dyskusja) 22:17, 3 paź 2009 (CEST)
3.  Za --Pablo000 (dyskusja) 22:23, 3 paź 2009 (CEST)
4.  Za -Masti (dyskusja) 22:21, 3 paź 2009 (CEST)
5.  Za Jasne. awersowy # 22:22, 3 paź 2009 (CEST)

Wysłałem zgłoszenie - bugzilla:20996. Beau (dyskusja) 11:38, 5 paź 2009 (CEST)

Automatyczne kolorowanie kont z uprawnieniami

Zrobione

• Pytanie do Beau: czy istnieje możliwość automatycznego kolorowania kont z uprawnieniami? Chodzi oczywiście o boty i adminów. Dotychczas trzeba było ich ręcznie dopisywać do MediaWiki:Gadget-colored-nicknames.js, a tymczasem na Wikipedii dzieje się to chyba automatycznie. awersowy # 12:14, 5 paź 2009 (CEST)

Po to staram się o uprawnienia, żeby m.in. zaktualizować gadżety :-) Beau (dyskusja) 13:45, 5 paź 2009 (CEST)

Strona główna

Zrobione
Witam. Mamy pewien problem ze stroną główną, u mnie wyświetla się ona w ten sposób. Trochę się rozjeżdża, a przecież nie mam najmniejszej rozdzielczości. W moim brudnopisie kombinuję nad poprawką, tylko nie mam pomysłu jak zmieścić te cztery kolumny linków. Sugeruję dorobienie drugiego, poziomego paska z linkami. Jakieś pomysły? Beau (dyskusja) 19:09, 26 wrz 2009 (CEST)

Z tą częścią miałem największy problem; na dosyć ograniczonej przestrzeni musiałem upchać dosyć znaczną ilość linków. Owszem, dodatkowy pasek (np. nad napisem "Witamy w serwisie Wikiźródła"), mógłby zaradzić sprawie. Można by znowu coś zapożyczyć z innych stron głównych Wikipedii. Przy okazji, tu toczyła się dyskusja nad zmianą SG na obecną. --Teukros (dyskusja) 19:29, 26 wrz 2009 (CEST)

Może zróbmy inaczej. Tą kreskę i W polskich Wikiźródłach jest obecnie 445 autorów oraz 13809 tekstów. wrzućmy pod linki, a same linki przesuńmy bardziej w lewo. Wtedy się zmieszczą, tylko, że będą prawie na środku. Beau (dyskusja) 19:51, 26 wrz 2009 (CEST)

Można spróbować. Może wprowadź tę zmianę w brudnopisie, i zobaczymy jak to będzie wyglądać? --Teukros (dyskusja) 20:01, 26 wrz 2009 (CEST)

Moim zdaniem cztery kolumny linków wyglądają dobrze, ale rozpraszające są te dwa pogrubione linki pod nimi, bo psują układ. Można by je gdzieś przesunąć albo przenieść? Jos. (dyskusja) 20:02, 27 wrz 2009 (CEST)

Nie ma za bardzo gdzie ich przenieść, chyba, że całkiem poza nagłówek. Można też usunąć im pogrubienie, wtedy nie będą aż tak odstawać. Beau (dyskusja) 20:10, 27 wrz 2009 (CEST)

Usnąć pogrubienie i dać zwykłą gwiazdkę zamiast loga Źródeł. Albo przenieść pod kreskę i wyśrodkować, ale nie jestem pewna, czy to będzie dobrze wyglądać. Jos. (dyskusja) 20:15, 27 wrz 2009 (CEST)

Ja tam bym jednak zostawił to "Witamy w serwisie Wikiźródła" pisane "wikiźródlycą" bo to nasza tradycja. Jak za duże to można je trochę zmniejszyć... Electron ^<Odpisz> 09:07, 28 wrz 2009 (CEST)

W brudnopisie ukryłem pogrubienie, wygląda lepiej, szkoda, że tak mało osób chce się wypowiedzieć na ten temat :( Beau (dyskusja) 20:23, 27 wrz 2009 (CEST)

Moim zdaniem teraz jest dobrze i już mi nawet w IE6.0 się nie rozjeżdża (sprawdzałem także w FF3.0, w rozdzielczości 1024X768 i w panoramie 1440x900). Dobra robota :) Electron ^<Odpisz> 09:07, 28 wrz 2009 (CEST)

Kategoria:Ekspresowe kasowanko -> Kategoria:Ekspresowe kasowanie

Zrobione

Wydaje mi się, że póki projekt jest mały to warto wyprostować takie rzeczy. Beau (dyskusja) 15:08, 5 paź 2009 (CEST)

Popieram, sam o tym myślałem, jak wstawiałem interwiki. --Teukros (dyskusja) 15:17, 5 paź 2009 (CEST)

Byłem konsekwentnie za zmianą na plwiki, więc i tutaj jestem za zmianą nazwy na bardziej neutralną. Przy okazji myślałem o tym, aby przenieść z Wikipedii i dostosować do tego projektu zasady ekspresowego kasowania i stronę nt. wandalizmu, aby po dyskusji i korektach wikiskrybów przyjąć te strony jako obowiązujące zasady. Ale to za jakiś czas. — Awersowy <talk> 15:41, 5 paź 2009 (CEST)

Boty

Załatwione Chciałbym zapoczątkować dyskusję o botach Wikiźródeł. Na bazie Wikipedii utworzyłem stronę Wikiźródła:Boty oraz Wikiźródła:Boty/Zgłoszenia. Na pierwszej z tych stron znajdują się zasady przyznawania i odbierania flagi bota przez biurokratów. Są prawie identyczne jak na plwiki, zmodyfikowałem tylko minimalną liczbę edycji, jaką powinien mieć posiadacz konta (z 1000 do 100 - analogicznie do regulaminu PU) oraz czas posiadania konta w tym projekcie. Czy są jakieś uwagi? PS. Do całości brakuje jeszcze strony z zadaniami dla bota - w bardziej profesjonalnej wersji niż Kategoria:Zadania dla bota. Zrobię to na dniach. — Awersowy <talk> 18:34, 15 paź 2009 (CEST)

Cóż, trudno tu cokolwiek dodać. Jedyne, nad czym należy się poważnie zastanowić, to ewentualne wprowadzenie standard bot policy, ale w tej kwestii dobrze by było, gdyby wypowiedział się ktoś o większej wiedzy technicznej. --Teukros (dyskusja) 19:30, 15 paź 2009 (CEST)

Moim zdaniem trzeba wprowadzić standard bot policy, bo ciężko jest z interwiki na wikiźródłach i lepiej ułatwiać tego typu działalność, zamiast utrudniać ;). Jeśli chodzi o kryteria przyznawania flagi, to je trzeba poprawić, później to zrobię. Beau (dyskusja) 19:34, 15 paź 2009 (CEST)

Będę bardzo wdzięczny za pomoc i wprowadzenie poprawek :-). A tak przy okazji: zrobiłem Wikiźródła:Zadania dla bota. Opisywanie zadania w kategorii jest IMHO niepraktyczne - jak np. takie dyskusje później archiwizować? — Awersowy <talk> 19:47, 15 paź 2009 (CEST)

Przez blanking, jedyne słuszne rozwiązanie ;-). Tak działa mój bot, najpierw robi spis, a później blankuje. Beau (dyskusja) 20:48, 19 paź 2009 (CEST)

Podobnie jak Beau myślę, że wprowadzenie standard bot policy jest potrzebne w Wikiźródłach. Interwiki są ważnym elementem projektu, podobnie zresztą jak w Wikipedii. sp5uhe ^{dyskusja edycje} 21:37, 19 paź 2009 (CEST)

Boty globalne

Największym utrudnieniem dla operatorów botów jest zdobywanie uprawnień na obcojęzycznych projektach. Ponieważ mamy zaległości w linkach interwiki warto ułatwić innym operatorom pracę. Można to zrobić na dwa sposoby:

• meta:Bot policy#Global bots - poprzez zezwolenie globalnym botom na edycję w naszym projekcie
• meta:Bot policy#Automatic approval - wyrażenie zgody na nadawanie uprawnienia bota przez stewardów

Uprawnienia zdobyte w powyższy sposób mogą być wykorzystane do aktualizacji linków interwiki oraz naprawiania podwójnych przekierowań, czyli mało kontrowersyjna działalność. Beau (dyskusja) 21:43, 7 lis 2009 (CET)

 Za Myślę, że najlepiej będzie skorzystać z obu możliwości; z tego co jest mi wiadome, to standardowa praktyka na innych projektach. --Teukros (dyskusja) 22:01, 7 lis 2009 (CET)

 Za - dla obu propozycji. — Awersowy <talk> 22:01, 7 lis 2009 (CET)

Minął prawie tydzień od ogłoszenia propozycji. Modyfikuję stronę Wikiźródła:Boty i robię zgłoszenie na meta. Beau (dyskusja) 11:14, 12 lis 2009 (CET)

Proofread

Trafiłem ostatnio na dokumentację rozszerzenia Proofread i zauważyłem, że oferuje ono wiele funkcji, które realizujemy dość prymitywnie przy pomocy szablonów. Zachęcam do porównania wizualnego Poezye Adama Mickiewicza oraz Poezye (test), a następnie do wskazania jednej różnicy w kodzie tych stron :-).

Użyte magiczne słowo <pages> pozwala na zbiorowe dołączenie treści stron. Oferuje on także numerację podobną do tej z z szablonu {{StronaPR}} (odpowiednik to MediaWiki:Proofreadpage pagenum template).

Wydaje mi się, że powinniśmy przedyskutować sposób w jaki będziemy tworzyć nowe strony i wypracować jakieś zalecenia w tej sprawie. Moim zdaniem tam gdzie jest to możliwe należy zlikwidować szablony dublujące funkcjonalność rozszerzenia i korzystać z jego natywnych funkcji (skasowałem dzisiaj {{PageQuality}}, które zostało zastąpione przez <pagequality>). Tam gdzie nie jest to możliwe (bo czegoś brakuje, np. nazwy pliku dla <pagelist> - bugzilla:21398) trzeba zgłaszać uwagi autorowi.

Aktualna dokumentacja w języku angielskim znajduje się na stronie oldwikisource:Wikisource:ProofreadPage. Można tam znaleźć informacje na temat sposobu działania rozszerzenia. Ciekawą rzeczą jest automatyczne wstawianie nagłówków - patrz kod strony fr:La_Petite_Dorrit_-_Tome_2_-_Chapitre_5.

Nie przyswoiłem jeszcze całej dokumentacji, ale te funkcje wydają się godne uwagi. Co o tym sądzicie? Beau (dyskusja) 20:23, 3 lis 2009 (CET)

• Coś takiego jak <pages> widziałem już na ensource; nie wiedziałem tylko, czy u nas można to stosować. Jestem za tym, aby to wprowadzić w proofread już teraz, póki takich stron nie mamy dużo. Oczywiście nie zawsze będzie to możliwe: gdy strona zawiera <section>, to już trzeba przejść na szablony {{StronaPR}} (Chyba, że istnieje sposób na obejście tego i nie stosowanie szablonu StronaPR w ogóle?)
  Bardzo przydałyby się jakieś zalecenia edycyjne odnośnie tworzenia stron proofread. Mamy już w tym nieco praktyki, teraz pozostaje nam spisać to doświadczenie na jakieś metastrony i oznaczyć jako obowiązujące. Niestety, na sprawach technicznych znam się słabo, dlatego w tym zakresie zaufałbym bardziej doświadczonym (w proofread) użytkownikom: Beau, Trevasowi czy Sp5uhe. Aha, a ta strona z frsource, służąca jako przykład, została na tamtym projekcie usunięta, stąd też prosiłbym o jakiś inny link. — Awersowy <talk> 17:45, 7 lis 2009 (CET)

A patrzyłeś w log? :)

• 20:54, 5 lis 2009 YannBot (dyskusja | edycje) usunął La Petite Dorrit - Tome 2 - Chapitre 5 (Nettoyage après correction des liens)
• 17:22, 5 lis 2009 Phe-bot (dyskusja | edycje) stronę fr:La Petite Dorrit - Tome 2 - Chapitre 5 przeniósł do fr:La Petite Dorrit/Tome 2/Chapitre 5 (Conventions sur les titres) (cofnij)

Beau (dyskusja) 17:48, 7 lis 2009 (CET)

• O przepraszam, miałem interfejs nie w języku polskim ;). Teraz już widzę jak to wygląda - bombowo:

<div class='lefttext'>
<pages index="Dickens - La Petite Dorrit - Tome 2.djvu" from=39 fromsection=chap5 to=54 tosection=chap5 header=1 />
</div>

Automatyczne dodawanie nagłówka to świetna rzecz, powstaje jednak pytanie jak w takim razie ma u nas nagłówek wyglądać? Czy mają to być {{Dane tekstu}}, {{nagłówek}}, czy coś specjalnego (tak jak chyba na frsource - zrobili sobie specjalną ramkę do takich stron). Widzę też, że jest tam parametr "fromsection" i "tosection", a to oznacza, że szablon {{StronaPR}} (do inkludowania tylko części przepisanego tekstu) zupełnie przestanie być potrzebny. — Awersowy <talk> 17:55, 7 lis 2009 (CET)

Co do samego wyglądu i możliwości jakie daje nagłówek to muszę jeszcze doczytać. Co do fromsection i tosection próbowałem to na szybko zrobić z Strona:PL Modrzewski-O naprawie Rzeczypospolitej 042.jpg, ale coś mi nie wyszło. Beau (dyskusja) 17:59, 7 lis 2009 (CET)

działa :) (porównaj z kodem strony O naprawie Rzeczypospolitej/I-7). Nagłówek dla proofread znajduje się tutaj: MediaWiki:Proofreadpage header template (zob. fr:MediaWiki:Proofreadpage header template). — Awersowy <talk> 18:25, 7 lis 2009 (CET)

Poszerzyłem stronę Pomoc:Proofread o wyjaśnienie, w jaki sposób inkludować strony. Dość trudno to wyjaśnić prostymi słowami, dlatego prosiłbym o poprawki. — Awersowy <talk> 19:33, 7 lis 2009 (CET)

Hm. Sprawdzałem jak zastąpienie {{StronaPR}} wpłynie na wyświetlany tekst. Zauważyłem dwa problemy:

1. Kolejne strony są sklejane bezpośrednio, nie jest pomiędzy nie wstawiany odstęp. Ma to zaletę w przypadku przedzielonych słów, ale wadą jest sklejanie ostatniego i pierwszego słowa z następnej strony. Trzeba poprawić strony tak, aby tą spację zawierały.
2. Zauważyłem, że niekiedy pomiędzy wywołaniami szablonu jest umieszczany dodatkowy odstęp. Trzeba ten odstęp przenieść do stron jako <br/>.

Beau (dyskusja) 11:33, 12 lis 2009 (CET)

• Francuzi i Anglicy mają na końcu swojego MediaWiki:Proofreadpage pagenum template takie coś:

</span></span> <!-- -->
              ↑

Czy wskazana strzałką spacja (z późniejszym komentarzem) to nie jest przypadkiem ta spacja, której nam brakuje pomiędzy kolejnymi stronami? Spojrzałem tylko tak pobieżnie, więc być może gadam głupoty :) — EMeczKa dyskusja 03:02, 15 sty 2010 (CET)

Całkiem możliwe. Zaobserwowałem ten problem kilka razy, rozwiązywałem go przez wstawienie w tekst  . Dam znać Sp5uhe, zna to zagadnienie lepiej ode mnie.--Teukros (dyskusja) 10:10, 15 sty 2010 (CET)

Osobiście wolę, aby odstęp znajdował się na danej stronie, a nie w szablonie. Dzięki temu nie będzie problemów z łączeniem przedzielonych wyrazów. Tymczasowo można go jednak umieścić w szablonie. Beau (dyskusja) 09:34, 16 sty 2010 (CET)

Ja bym raczej wstawił poniższy kod, bo mniej bajtów, a powinien identycznie zadziałać

</span></span>&#32;

Niemniej po zastosowaniu obu metod skutek powinien być dokładnie taki jak piszecie - strony zostaną rozdzielone pojedynczą, łamalną spacją. sp5uhe ^{dyskusja edycje} 17:26, 16 sty 2010 (CET)

Być może rozwiązanie Beau jest praktyczniejsze, niemniej trzeba się na coś zdecydować i konsekwentnie stosować w tekstach oraz opisać w pomocy. Ja, po tych kilku edycjach, nie mam jeszcze zdania w tej sprawie :) — EMeczKa dyskusja 19:30, 16 sty 2010 (CET)

Jak stworzyc dwie kolumny

Strona z dwoma kolumnami. Czy jest prostsze rozwiazanie poza tabela? PS. PS. Czy mamy odpowiedniki en:Template:Larger? --Piotrus (dyskusja) 22:18, 8 lis 2009 (CET)

Do tworzenia kolumny można spróbować użyć szablonu {{zoryginału}}. W zasadzie służy do czegoś innego, ale może się nada. Co do powiększacza - nie wiem, obawiam się, że nie. --Teukros (dyskusja) 22:27, 8 lis 2009 (CET)

Hmm, cos sie na podstawie tego szablonu powinno dac zrobic, od biedy dziala... --Piotrus (dyskusja) 22:42, 8 lis 2009 (CET)

Meh, zbyt skomplikowana :) Przeniosłem za to z en Szablon:Kolumny. Wydaje sie działac :) PS. Tylko nie da się kontrolowac punktu rozbicia na kolumny :( Wydaje sie dostosowywac do ekranu, co jest na nasze potrzeby chyba "za mądre". --Piotrus (dyskusja) 22:54, 8 lis 2009 (CET)

Kilka nowych szablonów do rozmiarów czcionki

Przeniosłem z en-wiki - przyzwyczaiłem się tam do

• {{XX-mniejszy}}
• {{X-mniejszy}}
• {{mniejszy}}
• {{większy}}
• {{X-większy}}
• {{XX-większy}}
• {{rozmiar-czcionki}}

--Piotrus (dyskusja) 01:07, 30 lis 2009 (CET)

Przenosic inne? Nie wiem, czy to przydatne tylko mi, czy innym...? --Piotrus (dyskusja) 00:24, 15 gru 2009 (CET)

Zależy co masz na myśli. O ile szablony zwiększające rozmiar czcionki są jeszcze dobre, to wszystko co utrudnia czytanie tekstu (pstrokate kolorowanie, zmniejszanie wielkości czcionki) powinno być raczej używane jednorazowo, w wyjątkowych przepadkach. Ale to tylko moja opinia. Beau (dyskusja) 16:28, 15 gru 2009 (CET)

Z powodzeniem użyłem powiększaczy, są rzeczywiście przydatne. Pomniejszać nic mi się nie zdarzyło - sytuacja, że w tekście coś trzeba pomniejszyć jest dosyć rzadka, i na razie zawsze wystarczało <small>.--Teukros (dyskusja) 18:36, 15 gru 2009 (CET)

Szablony

Mam propozycję aby uporządkować kwestię wykorzystywanych w projekcie szablonów, tak by ich użycie było konsekwentne w tekstach. Spis szablonów wraz z ich opisem teoretycznie znajduje się na stronie Wikiźródła:Szablony, lecz brak tam bardzo wielu wykorzystywanych szablonów. Niedługo osiągniemy w tym zakresie poziom bałaganu podobny do tego, który jest na Wikipedii. Dodanie nowego szablonu, a tym bardziej wykorzystywanie go powinno mieć uzasadnienie merytoryczne. Teksty naszpikowane karkołomnymi, unikalnymi rozwiązaniami staną się trudne do wykorzystania jako źródło, a tym samym zatracimy podstawowy sens projektu. sp5uhe ^{dyskusja edycje} 17:44, 16 sty 2010 (CET)

Znaczy, właściwie to nie ma tam większości szablonów. No nic, jedyne co mi przychodzi do głowy, to inwentaryzacja szablonów, i ewentualne usunięcie dubli i nieużywanych. Mogę się tym zająć, aczkolwiek chyba by było lepiej, gdyby zrobiła to jakaś osoba "techniczna". --Teukros (dyskusja) 19:58, 16 sty 2010 (CET)

Lista szablonów znajduje się na stronie Wikiskryba:Beau.bot/listy/szablony. Beau (dyskusja) 16:47, 8 mar 2010 (CET)

Usprawnienia pod Linuksem

Nie wiem ilu z wikiskrybów używa Linuksa, ale na wszelki wypadek podzielę się sposobem jakim ułatwiłem sobie wprowadzanie pauz i é (bo nawet korzystanie z X-owego schowka było tu męczące). Nic odkrywczego pewnie nie napiszę, ale może komuś się przyda :-)

$ xmodmap -e "keycode 20 = minus underscore emdash endash emdash endash"

Tym sposobem wciskając znak dywizu/minusa z altem (alt+-) otrzymamy pauzę "—", a z altem i shiftem półpauzę"–".

$ xmodmap -e "keycode 25 = w W w W eacute eacute"

Aby otrzymać é wystarczy teraz wcisnąć alt+w (lub alt+shift+w - duże é nie będzie nam potrzebne). Alt+w dlatego, że alt+e jest zajęte z oczywistych względów, a alt+w dawało w domyślnej konfiguracji mało przydatne ł/Ł ;-)

Pewnie można tę listę jeszcze rozszerzyć/zmienić co też proszę czynić :-) — EMeczKa dyskusja 21:17, 23 sty 2010 (CET)

Ja często pojawiające się znaki, których nie ma w naszej klawiaturze, wpisuję zawsze za pomocą lewego klawisza Alt i klawiatury numeracyjnej – zapamiętanie kilku kodów, których używa się często, nie sprawia problemów, a dzięki temu nie trzeba korzystać z przycisków pod polem edycji. Pauza "—" = Alt + 0151; półpauza "–" = Alt + 0150; é = Alt + 130; « = Alt + 174; » = Alt + 175; „ = Alt + 0132; ” = Alt + 0148. Remedios44 (dyskusja) 07:03, 24 sty 2010 (CET)

Gadżet OCR

Dodałem gadżet, który może przyspieszyć pracę z tekstami proofread. Po włączeniu gadżetu nad polem edycji w przestrzeni Strona pojawi się guziczek z napisem OCR. Po wciśnięciu treść strony zostanie zastąpiona tekstem wytworzonym na podstawie obrazka. Jeśli tekst zostanie wstawiony do edytora - guziczek zniknie - dwukrotne OCRowanie nie ma sensu, a pomyłkowe wciśnięcie guzika spowodowałoby zastąpienie tekstu. Gadżet jest ustawiony na sztywno dla języka polskiego i korzysta z serwera tools Stowarzyszenia Wikimedia Polska. OCRowanie jest realizowane przy pomocy convert z imagemagic i tesseract. sp5uhe ^{dyskusja edycje} 17:50, 4 lut 2010 (CET)

Niestety, przynajmniej u mnie nie działa. Po kliknięciu na "OCR", widać że są pobierane jakieś dane z toolserwera, ale zaraz potem pojawia się okienko z napisem: Komunikat ze strony http://pl.wikisource.org: błąd nierozpoznany, i na tym koniec. --Teukros (dyskusja) 18:22, 4 lut 2010 (CET)

U mnie przycisk działa. Remedios44 (dyskusja) 19:32, 4 lut 2010 (CET)

To działa na pewno poprawnie dla obrazków które są w formacie JPG. Dla DJVU nie sprawdzałem, ale jak widać nie działa. Postaram się poprawić w najbliższym czasie. Niestety jakość OCRowania pozostawia sporo do życzenia. To podobno najlepsze otwarte oprogramowanie. sp5uhe ^{dyskusja edycje} 22:39, 4 lut 2010 (CET)

Problemem jest rozdzielczość - jeśli jest zbyt duża to tesseract nie OCR-uje. Wymyślę na to jakieś obejście. sp5uhe ^{dyskusja edycje} 22:58, 4 lut 2010 (CET)

Poprawiłem nieco OCR, ale nadal jest niskiej jakości. Powinien już przetwarzać dowolne obrazki. Będę się starał doprowadzić to do stanu użyteczności poprzez wymianę oprogramowania na lepsze, ale z pewnością to potrwa. sp5uhe ^{dyskusja edycje} 21:37, 22 lut 2010 (CET)

Zmiany w MediaWiki:Edittools

Wprowadziłem pewne zmiany w MediaWiki:Edittools. Powiększyłem wszystkie znaki (szukanie małych znaczków było niekiedy dla mnie bardzo uciążliwe), zaktualizowałem niektóre licencje i wyrzuciłem kilka nieużywanych szablonów. Zobaczcie, czy może być - jeżeli się nie spodoba, zrevertuję. --Teukros (dyskusja) 09:55, 18 lut 2010 (CET)

Dla mnie jest OK. Btw. Od dłuższego czasu tak sobię myślę, czy nie dodać do tego sekcję typowych opisów edycji. Można by też je umieścić na stronie edycji tak jak to ma ru-wikisource lub chociażby nasza wikipedia. Przydatna rzecz. Electron ^<Odpisz> 10:59, 18 lut 2010 (CET)

Ale przecież już mamy opisy edycji, od dawna? Trzeba tylko włączyć w preferencjach gadżet "Opisy zmian" (w sekcji "Ułatwienia edycji"). --Teukros (dyskusja) 13:03, 18 lut 2010 (CET)

A faktycznie - już dawno tam nie zaglądałem i widać jestem zapóźniony w nowinkach - być może, że to kiedyś wyłączyłem jak jeszcze miałem stary komputer, który nie nadążał za nowymi czasami. Dzięki za namiary. Electron ^<Odpisz> 14:51, 18 lut 2010 (CET)

Psalmodia

Strona:PL Kochowski-Psalmodia polska 039.jpg - w polu edycji nie wyświetla mi się ostatnie zdanie, podobne problemy z obcinaniem końcówek pojawiają mi się w innych stronach Psalmodii. Nie wiem, czy to może tylko u mnie są jakieś problemy z przeglądarką? Żadnych błędów w kodzie strony nie widzę. Remedios44 (dyskusja) 12:58, 3 kwi 2010 (CEST)

Z tego co widzę, to problem z przeglądarką. Pamiętam że używasz Opery, i rzeczywiście, pod Operą 10.50 nie widać ostatniego zdania. Pod Firefoxem wszystko jest w porządku.--Teukros (dyskusja) 13:10, 3 kwi 2010 (CEST)

No tak, niedawno zainstalowałam nową Operę 10.51, do tej pory byłam z niej zadowolona, ale okazuje się, że ma buga :( Remedios44 (dyskusja) 13:13, 3 kwi 2010 (CEST)

Jak zmniejszę powiększenie w przeglądarce i otworzę edycję, to już nie ucina. Po otwarciu edycji mogę stronę powiększać i jest w porządku. Czyli da się to jakoś przechytrzyć. Ale i tak najlepszym rozwiązaniem jest powrót do wcześniejszej Opery. Remedios44 (dyskusja) 13:34, 3 kwi 2010 (CEST)

http://img44.imageshack.us/img44/8758/operaoverflowproblem.png skan po prawej jest przy wczytaniu strony wyższy niż widoczna część - reszta jest ukryta, zawartość textarea została potraktowana przez Operę tak samo, mimo że DragonFly (na screenie na dole) pokazuje że obliczona dla tego elementu wysokość jest 661px (czyli powinien być cały widoczny); właśnie kombinuję jak zmusić Operę do poprawnego przeskalowania tego elementu (jak ręcznie przypiszę na nowo tą obliczoną wysokość, to potem wyświetla się już normalnie) CzarnyZajaczek (dyskusja) 14:21, 3 kwi 2010 (CEST)

działa zmniejszenie i powiększenie na nowo strony (np. Ctrl+rolka), czyli nie trzeba nawet zmniejszać przed otwarciem do edycji tylko można po; czy jest prawidłowo łatwo sprawdzić bo można kursorem zejść do tego ukrytego tekstu CzarnyZajaczek (dyskusja) 14:26, 3 kwi 2010 (CEST)

Ja już zrezygnowałam z zabawy i odinstalowałam Operę 10.51. Nie wiem czy warto się z nią męczyć. Może w nowszych wersjach naprawią błędy, na razie wracam do starszej. Nie mogę się jakoś przekonać do edytowania wiki spod Firefoxa :( Remedios44 (dyskusja) 14:32, 3 kwi 2010 (CEST) A w ogóle to witaj na Wikiźródłach xD

Wróciłam do Opery 10.10 (taką miałam przed aktualizacją) i jest wszystko OK. Remedios44 (dyskusja) 14:45, 3 kwi 2010 (CEST)

Google

Załatwione Po wpisaniu w wyszukiwarkę słowa Wikipedia internauta otrzymuje następujący wynik: [2] Encyklopedia powszechna, pisana i redagowana przez internautów.. Gdy wpisze wikiźródła: [3] dostaje coś takiego: Wikitomiki — projekt mający na celu tworzenie zbiorów dostępnych na Wikiźródłach materiałów źródłowych, które są zebrane według konkretnego klucza. .... Natomiast wpisanie Wikisource da [4] - Źródło „http://pl.wikisource.org/wiki/Wiki%C5%BAr%C3%B3d%C5%82a:Strona_g%C5%82%C3%B3wna”. Kategoria: Strona główna. Widok .... Dlaczego tak jest i jak to można zmienić? — Awersowy <talk> 11:51, 9 kwi 2010 (CEST)

To jest bardzo dobre pytanie :-). Odpowiedź znajduje się w faq. Google szuka zdania, które może opisywać daną stronę. My takiego tekstu na stronie głównej nie mamy, więc nie ma co się dziwić, że są bzdury. Jeśli chodzi o Wikipedię, to pewnie jest to opis jakiegoś "moderatora". Beau (dyskusja) 14:02, 9 kwi 2010 (CEST)

W tej chwili wyświetla się już sensowna notka. Beau (dyskusja) 21:27, 26 kwi 2010 (CEST)

Nowa przestrzeń nazw 'Autor'

Załatwione Naśladując inne projekty proponuję wprowadzenie nowej przestrzeni nazw Autor: (wraz ze stroną dyskusji Dyskusja autora:) oraz objęcie jej działaniem rozszerzenia Wersje oznaczone. Pozwoli to na rozdzielenie tekstów od stron ich autorów, jednocześnie odejdzie jeden z czynników zakłócających pracę licznika tekstów. Beau (dyskusja) 21:44, 9 kwi 2010 (CEST)

•  Za Rzecz dla mnie oczywista - już od dawna myślałem, czy aby nie zaproponować tej zmiany. Krótko pisząc, strony autorów nie są materiałami źródłowymi, więc nie powinny być w przestrzeni głównej. — Awersowy <talk> 23:07, 9 kwi 2010 (CEST)
•  Za Gwoli uporządkowania. --Teukros (dyskusja) 23:12, 9 kwi 2010 (CEST)
•  Za Dlaczego by nie? Akira (dyskusja) 21:46, 10 kwi 2010 (CEST)
•  Za Remedios44 (dyskusja) 07:39, 11 kwi 2010 (CEST)
•  Za sp5uhe ^{dyskusja edycje} 20:00, 13 kwi 2010 (CEST)

Zgłoszenie wysłane - bugzilla:23166. Beau (dyskusja) 09:48, 12 kwi 2010 (CEST)

Też nie jestem przeciwny bo propozycja jest logiczna i na innych źródłach tak już zrobili ale po zmianie należało by poprawić wszystkie linki (nasze wewnętrzne i z innych projektów) a także interwiki do tych stron. Najlepiej by było aby to zrobił jakiś bot bo jest tego sporo i ręcznie to dość upierdliwa praca... Electron ^<Odpisz> 11:57, 13 kwi 2010 (CEST)

Od wczoraj jest przestrzeń Autor. sp5uhe ^{dyskusja edycje} 16:52, 17 kwi 2010 (CEST)

Formatowanie w Tumorze Mózgowiczu

Prośba do kogoś znającego się na rzeczy o opracowanie jakiejś ludzkiej metody poprawnego formatowania tekstu na tej i 2 następnych stronach. Niestety chyba nie mamy żadnego szablonu na tę okazję, a sposób przeze mnie zastosowany jest koszmarny w edytowaniu (nie znam się na tym za bardzo) — EMeczKa dyskusja 17:35, 12 kwi 2010 (CEST)

Trochę to uprościłem. Moje zmiany. Trochę to karkołomne rozwiązanie, ale skuteczne. sp5uhe ^{dyskusja edycje} 19:58, 13 kwi 2010 (CEST)

Teraz jest znacznie lepiej. Dzięki — EMeczKa dyskusja 12:41, 14 kwi 2010 (CEST)

Kolory w indeksie

Po zalogowaniu nie wyświetlają mi się w indeksach kolory oznaczeń proofread - dopiero po wejściu na poszczególne strony widzę, czy są one skorygowane, czy nie. Nie edytowałam jakiś czas, a wiem że w tym czasie było sporo zmian, może powinnam zmienić jakieś ustawienia w preferencjach? Gdy wchodzę jako niezalogowany użytkownik, wszystko jest OK. Hmm, przyjrzałam się uważniej i widzę że w niektórych indeksach kolory mi się wyświetlają - ale tylko w niektórych, w większości nie. Remedios44 (dyskusja) 09:49, 14 kwi 2010 (CEST)

Też mam ten problem, sprawdzałem pod Operą i Chrome, na monobooku i na vectorze, nie pomogło też odznaczenie wszystkich gadżetów — EMeczKa dyskusja 12:46, 14 kwi 2010 (CEST)

Ten problem pojawił się z włączeniem wersji przejrzanych. Zgłosiłem go pod koniec marca - bugzilla:22981. Beau (dyskusja) 13:02, 14 kwi 2010 (CEST)

Można to obejść - należy wejść w edycję indeksu, i nacisnąć "pokaż podgląd". Na podglądzie kolory oznaczeń się pokazują. --Teukros (dyskusja) 13:20, 14 kwi 2010 (CEST)

U mnie działa odświeżenie strony, tzn. np. kliknięcie jeszcze raz na zakładkę "indeks". Używam FF. — Awersowy <talk> 17:06, 16 kwi 2010 (CEST)

W preferencjach zakładka Gadżety można w sekcji Ułatwienia przeglądania włączyć ostatni gadżet, który doraźnie rozwiązuje problem. Gadżet przygotował Beau. Piszę, bo może nie wszyscy go zauważyli. sp5uhe ^{dyskusja edycje} 22:58, 19 maj 2010 (CEST)

Dostałem informację z Bugzilli, że bug został już załatwiony. Poszła też poprawka. --Teukros (dyskusja) 19:56, 14 cze 2010 (CEST)

Brak paru stron

Zauważyłem dzisiaj, że w encyklopedii kościelnej nie ma zeskanowanych paru stron. Niestety okazało się, że to nie mój błąd przy pobieraniu skanów, a osoby skanującej. Mam plan, aby poszukać tej pozycji w bibliotece i doskanować brakujące strony. Czy mogę je jakoś łatwo dodać do indeksu i czy to nie zaburzy struktury książki? Akira (dyskusja) 23:04, 14 kwi 2010 (CEST)

Była taka sytuacja przy okazji Pana Tadeusza i po dodaniu dodatkowych stron z literkami (518 519a 519b 519 - zob. Indeks:Pan Tadeusz (Adam Mickiewicz) i kod strony Pan Tadeusz (wyd. 1834)/Księga dwunasta) obyło się bez problemów :) — EMeczKa dyskusja 00:52, 15 kwi 2010 (CEST)

Poprawiłem indeksy. Wystarczy wgrać brakujące pliki pod odpowiednimi nazwami. Aby było łatwiej odnaleźć brakujące strony, dodałem do nich podkreślnik w indeksie. sp5uhe ^{dyskusja edycje} 22:52, 19 maj 2010 (CEST)

Przypisy

Nie widzę przypisów na stronie Manifest Tymczasowego Rządu Narodowego. Nie bardzo wiem dlaczego. Może ktoś z Was dojdzie. sp5uhe ^{dyskusja edycje} 13:05, 15 kwi 2010 (CEST)

Szablon {{references}} nie działa. Do naprawienia lub usunięcia. Zamieniłem na {{przypisy}}. --Teukros (dyskusja) 13:16, 15 kwi 2010 (CEST)

Zostało jeszcze kilkadziesiąt miejsc użycia tego szablonu w przestrzeni głównej. Może to ktoś botem posprząta? Doraźnie można zrobić zaciągnięcie jednego szablonu drugim. sp5uhe ^{dyskusja edycje} 16:48, 17 kwi 2010 (CEST)

U mnie szablon {{references}} działa. Beau (dyskusja) 16:55, 17 kwi 2010 (CEST)

Gryzło się z gadżetem MediaWiki:Gadget-newHelp.css. Usunąłem wydaje mi się zbędną klasę z DIV w szablonie {{references}} i problem ustąpił. Niemniej ja optuję za ujednoliceniem szablonu do przypisów. Mamy szablon {{przypiswiki}} do opisywania pojedynczych przypisów jako własnych Wikiskrybów. Wydaje mi się wygodniejszy i czytelniejszy niż stosowanie {{references}}. Trzeba by w tekstach gdzie jest {{references}} botem do wszystkich wystąpień <ref>xxx</ref> dodać <ref>{{Przypiswiki|xxx}}</ref>. A następnie wymienić {{references}} na {{przypisy}}. sp5uhe ^{dyskusja edycje} 17:37, 17 kwi 2010 (CEST)

Dodałem jako zadanie dla bota. sp5uhe ^{dyskusja edycje} 19:40, 17 kwi 2010 (CEST)

Kategorie

Dodałem w kategoriach w nawiasie liczbę stron, podkategorii i plików. Wydaje mi się to o wiele wygodniejsze. Dotychczas w nawiasie wyświetlana była tylko liczba podkategorii, co sugerowało, że kategoria jest pusta gdy tymczasem było w niej wiele pozycji. sp5uhe ^{dyskusja edycje} 20:03, 27 kwi 2010 (CEST)

Ustawianie strony jako okładki w .djvu

Jak przekazać szablonowi {{Dane tekstu}} parametr |page=7, tak aby jako okładka była wyświetlana siódma strona .djvu? Wydaje mi się że trzeba nieco przerobić wywołanie szablonu {{infobox grafika}} ale może się mylę, więc nie chcę grzebać bez potrzeby. — EMeczKa dyskusja 13:25, 2 maj 2010 (CEST)

Dodałem do szablonu parametr strona z okładką. Beau (dyskusja) 17:08, 2 maj 2010 (CEST)

Dzięki, o to chodziło — EMeczKa dyskusja 19:40, 2 maj 2010 (CEST)

Wersje przejrzane

Nie umiem przejrzeć zmian na stronie, która pojawia się po przejściu (kliknięciu przejrzyj) ze strony zdezaktualizowanych. Nie mogę odnaleźć jakiegokolwiek linku służącego do przeglądania. sp5uhe ^{dyskusja edycje} 09:18, 10 maj 2010 (CEST)

Przejrzałem bez żadnego problemu?--Teukros (dyskusja) 09:34, 10 maj 2010 (CEST)

Skoro problem dotyczy tylko mnie to znaczy, że musiałem sobie nagrzebać w CSS, bo nie mam linków do przeglądania w interfejsie. sp5uhe ^{dyskusja edycje} 11:18, 10 maj 2010 (CEST)

Problem wystąpił dlatego, że nie miałeś uprawnień redaktora. Każdy admin ma ustawienia podobne do bota, to znaczy jego edycje są automatycznie oznaczane przejrzane, ale tylko wtedy, gdy poprzednia wersja strony była przejrzana. Jednak bez włączonych uprawnień admin nie może oznaczać stron po raz pierwszy oraz oznaczać czyichś edycji. Uff, mam nadzieję, że to zrozumiałe :). — Awersowy <talk> 17:38, 10 maj 2010 (CEST) PS. Włączyłem Ci uprawnienia :).

Ukrywanie wersji

Dzisiaj zauważyłem, że w historii każdej strony, oraz przy porównywaniu zmian pojawił się przycisk (pokaż/ukryj), znany adminom Wikipedii. Oznacza to, że mamy techniczną możliwość ukrywania wersji (w tym także ukrywania nazwy użytkownika danej edycji). Czy była gdzieś na ten temat jakaś dyskusja, czy tak po prostu deweloperzy włączyli to uprawnienie wszystkim projektom? :). Przypuszczam, że to drugie, bo dyskusji nie kojarzę. Jeśli więc postawiono nas przed faktem dokonanym, to wypada zdecydować, czy chcemy to, czy mamy zgłosić na Bugzillę wyłączenie. Jeśli zechcemy utrzymać to narzędzie, to wówczas należałoby "uchwalić" jakąś zasadę lub zalecenie dotyczące ukrywania (pewną pomocą, czy nawet wzorem może być zasada na Wikipedii). IMHO to bardzo ważna sprawa, bo ukrywanie wersji stwarza ogromne pole do nadużyć, a poza tym nie mam pewności, czy jest coś takiego w ogóle potrzebne na małym i niekonfliktogennym projekcie. Sam na Wikipedii chyba ani razu nie ukryłem wersji, bo nie czułem takiej potrzeby (a widziałem jak inni stosowali to narzędzie nawet przy "zwyczajnych" wandalizmach). — Awersowy <talk> 18:18, 18 maj 2010 (CEST)

Skoro już mamy, proponuję zachować. Tego rodzaju edycje, które powinny zostać dodatkowo usunięte z historii, mogą pojawiać się niezależnie od wielkości projektu. U nas przydałoby się zastosowanie nr 1, tj. ukrywanie edycji w całości naruszającej prawa autorskie. Zdarzyło mi się kilka razy (pamiętam tylko Pochwała demokracji ateńskiej), że usuwałem stary tekst, aby na jego miejsce wrzucić nowy, już nie naruszajacy praw autorskich. Praktycznie rzecz biorąc, ukryłem poprzednią wersję. To już chyba lepiej wykorzystać ten nowy mechanizm. --Teukros (dyskusja) 18:52, 18 maj 2010 (CEST)

Tak jak pisze Teukros, funkcja ta może być przydatna, zarówno do ukrywania edycji łamiących prawo autorskie, jak i grubych wandalizmów. Konieczne jest jednak ustalenie jasnych zasad co do jej stosowania, tak jak na Wikipedii. Remedios44 (dyskusja) 19:47, 18 maj 2010 (CEST)

Jak już jest to niech będzie - może się przydać (uzasadnienie jak u poprzedników). Oczywiście zasady używania można dostosować do naszych warunków na podstawie tych z Wikipedii. Electron ^<Odpisz> 23:46, 18 maj 2010 (CEST)

Czasem zdarzają się naruszenia prywatności. Oczywiście w Wikipedii są o wiele bardziej prawdopodobne, ale tutaj też są możliwe. Ukrywanie wersji jest naturalnym mechanizmem usuwania takich wpisów pozostawiającym czytelny ślad w historii. Jestem za pozostawieniem tej funkcjonalności. sp5uhe ^{dyskusja edycje} 22:49, 19 maj 2010 (CEST)

• W takim razie utworzyłem stronę Wikiźródła:Usuwanie wersji - treść została skopiowana z Wikipedii. Nie wiem, czy zachodzi konieczność zmiany jej treści, dopisania czegoś albo zmodyfikowania - według mnie nie, ale może komuś przyjdzie coś do głowy :). — Awersowy <talk> 15:04, 22 maj 2010 (CEST)

  Mam zastrzeżenie do tego punktu: 1. Edycji w całości naruszającej prawa autorskie. Nie dotyczy późniejszych wersji, które zostały dokonane w dobrej wierze i jedynie zawierały wcześniejszą, naruszającą prawo autorskie wersję.. Z naszego (i prawnego) punktu widzenia, nie ma żadnej różnicy pomiędzy np. NPA niesformatowanym i NPA w dobrej wierze sformatowanym. I jednego i drugiego należy się pozbyć z projektu. O ile na Wikipedii po wycięciu NPA może zostać coś wartościowego, to u nas zostałby chyba tylko nagłówek. --Teukros (dyskusja) 15:12, 22 maj 2010 (CEST)

  NPA może dotyczyć nie samego tekstu, a na przykład przypisów spisanych ze współczesnego wydania. Wyobraźmy sobie schemat - X dodał kilka przypisów naruszając prawa autorskie, a później Y i Z dodali prawidłowe przypisy. Ukrywamy edycję X, a następnie usuwamy z końcowego tekstu treści naruszające prawa autorskie dodane przez X. Jednak zmiany wprowadzone przez Y i Z są widoczne i dostępne w historii edycji. Dlatego punkt 1. wydaje mi się potrzebny.

  Dodałem do treści, że wnioskować można bezpośrednio do dowolnego administratora. Wydaje mi się to sensowne, bo umieszczanie publicznie uzasadnienia spowoduje powstanie śladu, który ukrywanie miało właśnie utajnić. sp5uhe ^{dyskusja edycje} 19:30, 22 maj 2010 (CEST)

Wygląda na to, że wszystkie uwagi i zastrzeżenia zostały uwzględnione lub wyjaśnione. Jeżeli nie będzie dalszych uwag, za 7 dni zamykam dyskusję, a zasada zostaje wprowadzona w obecnej postaci. --Teukros (dyskusja) 21:59, 21 cze 2010 (CEST) PS. Z uwagi na aktywność administratorów w projekcie (wiadomo, nie zawsze jesteśmy) w projekcie zasady dokonana została drobna zmiana - wnioski o usunięcie kierowane będą domyślnie na Wikiźródła:Prośby do administratorów. --Teukros (dyskusja) 22:06, 21 cze 2010 (CEST)

Dalszych uwag brak, uznaję zasadę za wprowadzoną na mocy konsensusu. --Teukros (dyskusja) 18:33, 29 cze 2010 (CEST)

Spacje w proofread

Zauważyłem, że czasem w treści przetwarzanych przez nas przy pomocy proofread tekstów pojawia się „&#32;”, a czasem „&nbsp;”. To są pozornie te same znaki odstępu, lecz jednak różne! Znak „&#32;” jest niczym więcej niż zwykłą spacją. Jest to taki sam znak jak ten uzyskany poprzez wciśnięcie spacji na klawiaturze. To właśnie znak „&#32;” należy wstawiać na koniec strony proofread, aby spowodować powstanie odstępu pomiędzy wyrazami znajdującymi się na różnych stronach. Znak „&nbsp;” jest również spacją, ale niełamalną. Oznacza to, że na tym znaku nigdy nie zostanie złamany wiersz oraz, że w przypadku justowania ta spacja nie będzie poszerzana aby treść wypełniła cały wiersz. Ten znak w niektórych czcionkach wyświetlany jest jako węższy niż standardowy odstęp. Wykorzystuje się go zazwyczaj do formatowania liczb (rozdzielanie milionów, tysięcy itd), aby uniemożliwić złamanie w środku liczby. Tego znaku należy unikać w tekstach proofread, bo zazwyczaj powinno się użyć „&#32;”. sp5uhe ^{dyskusja edycje} 22:45, 19 maj 2010 (CEST)

{{Rozstrzelony}}

Zastanawiam się, czy szablon ten nie rozstrzeliwuje trochę za nadto. W tej chwili wygląda to tak:

Chrząszcz brzmi w trzcinie w Szczebrzeszynie.

Może czytelniej (szczególnie przy dłuższych fragmentach rozstrzelenia) byłoby nieco zmniejszyć odstęp pomiędzy kolejnymi literami, np. tak:

Chrząszcz brzmi w trzcinie w Szczebrzeszynie.

Nie wiem też, czy nie przydałby się dodatkowy odstęp na początku rozstrzeliwanego tekstu, np. spacja &#8202;, choć to wymaga większej rozwagi, ze względu na możliwość popsucia już istniejącego formatowania:

Chrząszcz  brzmi w trzcinie w Szczebrzeszynie. — EMeczKa dyskusja 14:56, 5 cze 2010 (CEST)

Popieram propozycję. Już raz zmniejszałam rozstrzelenie w szablonie, ale nadal jest chyba trochę za duże. Remedios44 (dyskusja) 18:01, 5 cze 2010 (CEST)

Zmniejszyłem, nawet chyba nie trzeba nic kombinować z dodatkowym odstępem — EMeczKa dyskusja 18:21, 6 cze 2010 (CEST)

O żołnierzu tułaczu (bajka dla dzieci)

Mam problem z umieszczeniem w przestrzeni głównej tekstu bajki O żołnierzu tułaczu. Ewidentnie jest jakiś problem ze stroną Indeks:O żołnierzu tułaczu (bajka dla dzieci), bo w spisie indeksów z postępem prac wyświetla się od jakiegoś czasu jako pusta (Specjalna:IndexPages - druga 50-tka). Myślałam, że chodzi o dwukropek w nazwie strony indeksu, ale po przeniesieniu strony pod obecną jej nazwę nic się nie zmieniło. Czy ktoś jest w stanie to rozwiązać? Nutaj (dyskusja) 19:56, 15 cze 2010 (CEST)

Należy w wywołaniu znacznika pages podawać dokładnie takie same nazwy stron jakie są podlinkowane na stronie indeksu. Beau (dyskusja) 21:12, 15 cze 2010 (CEST)

Wektor

Jak właśnie przeczytałem na stronie usability.wikimedia.org, do końca miesiąca na Wikiźródłach (i innych projektach) ma zostać wprowadzona skórka Wektor i nowy pasek edycyjny. W związku z tym wypadałoby zrobić jakąś stronę pomocy, faq, miejsce do uwag itp. Przykład można brać z polskiej Wikipedii. Więcej szczegółów spróbuję wybadać za dnia. Viatoro (dyskusja) 03:37, 18 lip 2010 (CEST) P.S. Mam nadzieję, że nie powielam tematu, ale nie znalazłem przy żadnym innym stoliku informacji o tym.

Do innych skórek nie mamy osobnych stron pomocy. Można zaktualizować informacje, które już mamy (a ich jest raczej nie wiele). Jak ktoś ma większe zapotrzebowanie na informacje to zawsze można kierować na strony Wikipedii. Beau (dyskusja) 08:22, 18 lip 2010 (CEST)

Inne skórki nie staną się domyślne:) Viatoro (dyskusja) 18:27, 18 lip 2010 (CEST)

• Termin wprowadzenia Vectora został przesunięty na 1 września. Viatoro (dyskusja) 22:58, 19 sie 2010 (CEST)

Prawdę powiedziawszy wszędzie gdzie się dało mam ustawiony monobook ale jak wiadomo o gustach się nie dyskutuje... Electron  ^<Odpisz> 12:30, 20 sie 2010 (CEST)

Komunikaty systemowe

Poprzeglądałem sobie komunikaty systemowe, które mamy lokalnie zmodyfikowane i widzę, że kilka wymaga pewnych poprawek. Przede wszystkim chodzi mi o MediaWiki:Cite text i niepotrzebne odniesienie do Wikipedii w pierwszym akapicie. Dalej: MediaWiki:Copyright i MediaWiki:Copyrightwarning odnoszą się jeszcze do GNU GFDL – nie wiem czy te komunikaty są gdzieś wykorzystywane, ale na pewno bezpieczniej je poprawić.

Zastanowiłbym się jeszcze nad informacją, obecną pod każdym tekstem Wikiźródeł (MediaWiki:wikimedia-copyright), która szczególnie dziwnie wygląda na wydruku, zwłaszcza jeśli tekst jest w domenie publicznej, co wzajemnie sobie przeczy. Może warto zrobić jak Niemcy?

W MediaWiki:Cite text usunąłem cały tekst odnoszący się do cytowania z Wikipedii. U nas sytuacja jest inna, teoretycznie można od nas cytować teksty bez problemu (że ponad 70% jest niezweryfikowana i pełna błędów, to inna sprawa). W MediaWiki:Copyright i MediaWiki:Copyrightwarning zaktualizowałem na Creative Commons. Natomiast MediaWiki:wikimedia-copyright nie ruszałem - w zasadzie, na upartego, są u nas na każdej stronie elementy na CC (grafiki, czasami układ tekstu). Sądzę, że ta kwestia wymaga dalszej dyskusji. --Teukros (dyskusja) 14:30, 21 lip 2010 (CEST)

"Wikiźródła się zmienia"

A propo zmian - da się ten napis gdzieś zmienić? Bo brzmi głupawo... Nie jestem obyty na Mecie więc jeśli ktoś zna tamtejsze obyczaje i miejsce gdzie można to przetłumaczyć poprawnie to fajnie by było aby to zmienił... Electron ^<Odpisz> 09:53, 22 lip 2010 (CEST)

A gdzie ten napis jest? --Teukros (dyskusja) 10:00, 22 lip 2010 (CEST)

Na każdej stronie, na jej początku od lewej: Wikiźródła się zmienia. Help us find bugs and complete user interface translations. Ma link prowadzący na stronę Mety. Można go ukryć. To zdaje się jest jeden z komunikatów systemowych. Electron ^<Odpisz> 10:09, 22 lip 2010 (CEST)

Ha, to nic dziwnego że go nie widzę, już dawno wyłączyłem sobie wszystkie te komunikaty. Leinad najprędzej coś poradzi, poproszę go dzisiaj na IRCu o pomoc. --Teukros (dyskusja) 10:14, 22 lip 2010 (CEST)

To podobno jest przekład automatyczny więc nic dziwnego, że jakiś taki strasznie polskawy wychodzi. Jeśli nie jest się zalogowanym to jest na pewno widoczny. I niezbyt dobrze o nas może świadczyć. Bo nie każdy wie, że to nie Źródła go generują. Widać go już od jakiegoś czasu ale myślałem, że ktoś to w końcu zmieni. A tu wisi i wisi. Pewno większość adminów wyłączyła te komunikaty to i nikt z mogących pomóc go nie zauważył. Electron ^<Odpisz> 10:42, 22 lip 2010 (CEST)

Gadżet newHelp

Mam prośbę o dodanie do tego gadżetu, ukrywania również tego szablonu. Pozwoli to oszczędzić dodatkowe, cenne miejsce w pionie, w oknie edycji — EMeczKa dyskusja 22:30, 4 sie 2010 (CEST)

Niewątpliwie byłoby to bardzo pomocne w edytowaniu. --Teukros (dyskusja) 15:15, 5 sie 2010 (CEST)

Wyłączenie komentarzy

Chciałem zaproponować wyłączenie możliwości komentowania przy oznaczaniu wersji strony jako przejrzanej. Chodzi o pole "komentarz" obok przycisku "przejrzyj" na dole strony. Nikt z tego nie korzysta, na Wikipedii też to było i niedawno zostało wyłączone jako zbędne. Dodatkowym argumentem jest fakt, że zajmuje miejsce na ekranie (niepotrzebnie rozpycha ramkę), co jest szczególnie widoczne na stronach proofread. Na szczęście nie trzeba zgłaszać niczego na bugzillę :-), wystarczy dodać do MediaWiki:Common.css następującą linijkę:

/* W oknie oznaczania wersji jako przejrzana ukrycie pola komentarza */
#mw-fr-commentbox {
	display: none;
}

Proszę o opinie. — Awersowy <talk> 20:59, 17 sie 2010 (CEST)

Dobry pomysł — EMeczKa dyskusja 21:00, 17 sie 2010 (CEST)

Oczywiście, że można wyłączyć. Jeszcze nigdy z tego nie korzystałem. --Teukros (dyskusja) 21:28, 17 sie 2010 (CEST)

Zrobione — Awersowy <talk> 15:11, 21 sie 2010 (CEST)

Długie s

Proszę o dodanie do polskiego zestawu znaków (pod oknem edycji) "ſ" — EMeczKa dyskusja 15:07, 20 sie 2010 (CEST)

Znak dodany. Znajduje się w sekcji "Polskie znaki" przed "é". --Teukros (dyskusja) 15:27, 20 sie 2010 (CEST)

Dzięki! — EMeczKa dyskusja 16:39, 20 sie 2010 (CEST)

Problem z proofreadem „Pisma wybrane” Josepha Conrada

W części II artykułu występuje niezrozumiałe pogrubienie. Po wywołaniu wyświetlanie numerów stron skanów w tekście widać ponadto, że brakuje fragmentu tekstu, wyświetlanego wtedy na szaro. Czy ktoś potrafi to naprawić? Nutaj (dyskusja) 00:14, 5 paź 2010 (CEST)

Zielonego pojęcia nie mam, czemu to tak dziwnie działało, ale poprawiłam tą edycją Remedios44 (dyskusja) 09:24, 5 paź 2010 (CEST)

Problem z alfabetycznym spisem utworów z tomików

Wraz z rozszerzeniem proofread pojawił się problem z alfabetycznym spisem utworów poszczególnych autorów. W infoboksie każdego autora mamy link nazwany "Alfabetyczny spis tekstów tego autora" (np. Maria Konopnicka). Odnosi on do kategorii ze wszystkimi podstronami danego autora. Problem pojawił się wraz z wprowadzeniem całych tomów poezji, np. Poezye. Serya druga. Wszystkie wiersze mają adres Poezye. Serya druga/XXX i pod takim tytułem znajdują się też w Kategorii. W tym wypadku Alfabetyczny spis... traci sens, gdyż np. wiersz U okienka znajduje się pod literą P, czyli Poezye. Serya druga/Obrazki/U okienka. Proponuję poprzenosić strony pod adres będący tytułem utworu, tak jak: Noce letnie, ale pozostawić redir Poezye. Serya druga/Noce letnie. W przypadku kiedy jeden utwór znajdowałby się w dwóch lub więcej tomikach na stronie z tytułem tego utworu robilibyśmy taki disambig z linkami do poszczególnych tomików. Kubaro (dyskusja) 11:45, 7 paź 2010 (CEST)

Sortować utwory w kategorii, niezależnie od pierwszej litery nazwy strony, można w taki sam sposób, jak np. hasła o osobach – sortowane są według pierwszej litery nazwiska, mimo że zaczynają się od imienia. Przykłady: [[Kategoria:Polscy pisarze|Konopnicka, Maria]], [[Kategoria:Maria Konopnicka|Noce letnie]]. Remedios44 (dyskusja) 12:12, 7 paź 2010 (CEST)

Z tego co widzę, problem ten występuje wyłącznie w Poezye. Serya druga, albowiem w zbiorze tym (tworzonym jako pierwszy, pewnie dlatego) poszczególne wiersze znalazły się w kategorii Maria Konopnicka. Na domiar złego, niektóre trafiły jeszcze do kategorii Public domain... Pozostałe zbiory (tak Konopnickiej, jak i innych autorów) tworzone są już w inny sposób, utwory trafiają tam do kategorii odpowiedniego tomu, vide Anioł milczenia albo O wiosno!. Rozkładanie na kawałki wszystkich pozostałych tomów, przenoszenie 270 stron (samej Konopnickiej - a przecież jeszcze dzieła innych autorów były w podobny sposób publikowane, np. Mickiewicza) chyba nie jest dobrym pomysłem - lepiej naprawić Poezye. Serya druga.

Natomiast bardziej ogólnie, odnośnie "Alfabetyczny spis tekstów tego autora" - wydaje się, że obecnie jest to przeżytek, jeszcze z czasów gdy publikowaliśmy konkretne utwory, a nie wydania tak jak teraz. Proponuję zamienić na "Spis tekstów tego autora". --Teukros (dyskusja) 12:20, 7 paź 2010 (CEST)

PS. Sprawdziłem dokładnie - rzeczywiście, ze wszystkich zbiorów wierszy opublikowanych u nas w proofread problem dotyczy wyłącznie Poezye. Serya druga. I jeszcze druga uwaga - w kategorii i na stronie autora Konopnickiej jest potworny bałagan, lepiej nie brać tego za jakikolwiek wzór. Naprawiam to od jakiegoś czasu, jestem mniej więcej w połowie pracy. --Teukros (dyskusja) 12:27, 7 paź 2010 (CEST)

Szablon ogólnoformatujący

Na Sabacie zadeklarowałem zrobienie czegoś z szablonami formatującymi tekst. Obecne kilkanaście szablonów to raczej przesada, tym bardziej, że da się to wszytko upchać do jednego "kombajnu". Dlatego pobawiłem się na szybko na testowej Wiki i tutaj efekt. Obsługuje rozmiar czcionki, rozstrzelenie, kapitaliki, pozycję oraz dekorację. Przykłady i krótki opis na stronie z powyższego linku. Oczywiście wszystkie parametry są opcjonalne. Yarl ✉ 20:05, 25 lis 2010 (CET)

Niezły pomysł i wykonanie. Nie wiem tylko czy w prosty sposób da się do niego przekierować te nasze dotychczasowe. Można je też po prostu zostawić "as they are" i po prostu dalej już ich nie stosować... Electron  ^<Odpisz> 14:27, 26 lis 2010 (CET)

Proste przypadki można poprawić bez problemu botem. Te bardziej egzotyczne poprawię ręcznie. O ile oczywiście będzie co do szablonu zgoda. Yarl ✉ 19:38, 26 lis 2010 (CET)

Jak dla mnie, ten rozbudowany szablon tylko będzie komplikował, zamiast ułatwiać, formatowanie tekstu. Remedios44 (dyskusja) 23:28, 29 lis 2010 (CET)

Według złym pomysłem jest tworzenie szablonów do formatowania tekstu. Już lepiej, żeby użytkownicy uczyli się wikikodu oraz prostych znaczników HTMLa, te przynajmniej są uniwersalne i można je stosować na wielu projektach. Beau (dyskusja) 17:23, 8 gru 2010 (CET)

Wydaje mi się, że w większości przypadków byłaby to nauka styli a nie wikikodu/prostych znaczników HTML. Niemniej zgadzam się z Remedios44, że taki szablon będzie niezbyt wygodny w użyciu. Ankry (dyskusja) 20:11, 8 gru 2010 (CET)

Błędy drukarskie w przypisach

Ma ktoś koncepcję jak koszernie poprawiać błędy drukarskie w przypisach? Przypis do przypisu nie wydaje się działać jak należy. Ankry (dyskusja) 08:56, 17 gru 2010 (CET)

Trochę namieszałem, nadal nie działa jak powinno, ale nie pojawiają się komunikaty błędów, więc wyjaśniam o co chodzi:

1. Na stronie z przypisami do tekstu jest błąd; więc dodany tam został {{Przypiswiki}} poprawiający go.
2. Przypis (w którym poprawiamy błąd) jest inkludowany jako <ref> na stronie z tekstem; w efekcie:
   1. jeśli <ref> z {{Przypiswiki}} jest bez nazwy pojawia się komunikat błędu o refie bez nazwy
   2. jeśli <ref> z {{Przypiswiki}} ma nazwę pojawia się komunikat błędu, że przypis o tej nazwie nie został nigdzie w tekście użyty
   3. jeśli <ref> z {{Przypiswiki}} obłożę <noinclude>, to pół strony tekstu jest wrzucane do stopki
3. Obszedłem to mało koszernie, dodając drugi {{Przypiswiki}} o tej samej treści i nazwie, inkludowany osobno na stronie z tekstem (inkludować łącznie mi się nie udało, bo przecinające się znaczniki <ref><section> </ref><ref> </section></ref> też nie działają); w efekcie mamy brak komunikatów o błędach + bezsensowny przypis nie tam, gdzie jego miejsce.

Pytanie jest: jak inkludować pomiędzy znacznikami <ref></ref> treść przypisu, która sama zawiera <ref> z {{Przypiswiki}} a nie można używać <noinclude>; ewentualnie jak używać <noinclude> wewnątrz stron przestrzeni Strona:

Ankry (dyskusja) 11:12, 17 gru 2010 (CET)

A może bez technicznego kombinowania zapisać przypis w postaci: "Tym Limuzyńczykinm (błąd w druku, powinno być Limuzyńczykiem - przyp. red.) był inny poeta prowansalski — Gerault de Beoneil de Limoges."? Tommy J. (pisz) 19:31, 17 gru 2010 (CET)

Wydaje mi się, że powinniśmy pozostawić tak jak zostało to wydrukowane. Dopisek błąd w druku, powinno być Limuzyńczykiem - przyp. red. według mnie za bardzo ingeruje w tekst oryginału. Natomiast nie zawsze jest jest 100% pewność czy faktycznie jest to błąd czy zamierzony zabieg autora. Obawiam się nadużyć i wojen edycyjnych. Kubaro (dyskusja) 19:44, 18 gru 2010 (CET)

Też byłbym za pozostawieniem zgodności z oryginałem, ale skoro jednak przeszkadza (mi nie), to proponuję najmniej inwazyjne technicznie rozwiązanie. Poniekąd dokonujemy tu redakcji źródeł. Tommy J. (pisz) 19:54, 18 gru 2010 (CET)

Zdaję sobie sprawę, że kwestia zgodności tekstu z oryginałem jest bardzo ważna, jednak tekst z błędami jest mniej użyteczny dla odbiorcy, nawet jeśli pozostawienie tych błędów jest z pewnych względów ważne. Oprócz proponowanych rozwiązań jest jeszcze jedno, ale nie wiem czy spodoba się społeczności. Można zostawić tekst takim, jakim jest (bez przypisów o błędzie w druku) i opracować dla każdego tekstu stronę ze sprostowaniami. Będzie przy tym trochę więcej zachodu, ale pozwoli zebrać to wszystko w jednym miejscu i zapobiegnie wojnom edycyjnym (lub pozwoli łatwiej je skończyć). Poza tym jest to chyba najdalej posunięty kompromis, który powinien zadowolić obie strony.

Pozdrawiam wszystkich i załączam świąteczne życzenia, Waćpan (dyskusja) 22:28, 18 gru 2010 (CET)

Szablony do tworzenia wielokolumnowych tabel

Utworzyłam (a ściślej skopiowałam z Wikipedii) trzy szablony, ułatwiające tworzenie wielokolumnowych tabel: {{col-begin}}, {{col-break}} i {{col-end}}. Sposób ich stosowania jest opisany na stronie Szablon:Col-begin/opis. Myślę, że mogą być przydatne. Remedios44 (dyskusja) 01:08, 27 sty 2011 (CET)

Problem z plikami .jpeg w proofreadzie

Witam, nie wiem czy to tylko u mnie po aktualizacji oprogramowania MediaWiki w przestrzeni Strona nie ładują się żadne obrazy w formacie .jpeg, a jedynie .djvu. Czy da się to naprawić i w czym jest problem? Nutaj (dyskusja) 13:41, 17 lut 2011 (CET)

U mnie z Indeks:Chata za wsią (Józef Ignacy Kraszewski) się ładują. Może problem z jakimiś plikami na commons? Ankry (dyskusja) 13:52, 17 lut 2011 (CET)

Na commons nie bo tam wszystkie pliki się wyświetlają, co dziwne, w Indeks:Ziemia obiecana (Władysław Stanisław Reymont) pliki wyświetlają się wybiórczo, częśc widać, część można pomarzyć. Tommy J. (pisz) 18:57, 17 lut 2011 (CET)

Poprawka - nie wszystkie .jpg, bo np. Chata za wsią ładuje się przy edycji, ale spróbuj np. Indeks:Ziemia obiecana (Władysław Stanisław Reymont), Indeks:Zamek kaniowski (Seweryn Goszczyński), Indeks:Ogólna charakterystyka powstania w 1863 (Giller), Indeks:Królowa Śniegu (Andersen, przekł. Niewiadomska) i Indeks:Nowelle (Helena Janina Pajzderska). U mnie w przestrzeni strona zostaje puste miejsce, a w edycji czarny prostokąt zamiast skanu. Po kliknięciu zakładki Grafika u góry strony pojawia się komunikat "Error generating thumbnail Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?". Nie mam pojęcia, co to może być? Wcześniej zdarzało mi się czasem, że skan nie ładował się na stronie, ale w edycji już wchodził. Nutaj (dyskusja) 15:52, 17 lut 2011 (CET)

Chyba widzę, na czym polega problem: z jakiegoś powodu proofread próbuje przeskalować obrazki do rozdzielczości o jeden piksel większej niż oryginał. Np. dla strony Strona:PL Helena Pajzderska-Nowelle 049.jpeg generuje [5], podczas gdy działa [6]. Nie znajdę sam przyczyny; może Beau pomoże? Dla obrazków o szerokości ponad 1000px jest OK.

Ankry (dyskusja) 19:03, 17 lut 2011 (CET)

Niestety obawiam się, że to może siedzieć za głęboko i powinno być poprawione w samym rozszerzeniu, czyli nie wiadomo kiedy. Viatoro (dyskusja) 03:27, 19 lut 2011 (CET)

Zgłoszenie na bugzilli Ankry (dyskusja) 12:36, 19 lut 2011 (CET)

Jakby ktoś nie zauważył, to obrazki od wczorajszego wieczora już działają. Ikonki na razie nie. I chyba nikt jeszcze nie wie dlaczego. Ankry (dyskusja) 10:13, 21 lut 2011 (CET)

Błędy czekające na naprawę

Poniżej przedstawiam dla zainteresowany listę moich zgłoszeń dotyczących tego projektu, które czekają na rozwiązanie.

• bugzilla:18861 - wyszukiwarka nie indeksuje prawidłowo stron z wywołaniami szablonów
• bugzilla:23049 - problem z dołączaniem sekcji zawartej na wielu stronach przy pomocy taga <pages>
• bugzilla:23331 - zmiana zmiennej konfiguracyjnej $wgCategoryPrefixedDefaultSortkey
• bugzilla:26028 - dodatkowy pusty wiersz na końcu każdej strony (w przestrzeni Strona): psuje łączenie stron
• bugzilla:27637 - białe znaki pomiędzy stronami dołączanymi tagiem <pages>
• bugzilla:27640 - brak paska narzędziowego do obsługi powiększania obrazków
• bugzilla:32372 - ograniczona szerokość paska narzędziowego

Beau (dyskusja) 19:50, 22 lut 2011 (CET)

Wygląda na to, że będziemy mieli przepychankę ze zgłoszeniem bugzilla:27637, osoby znające angielski zapraszam do dyskusji na bugzilli. Beau (dyskusja) 17:13, 23 lut 2011 (CET)

Wyglada na to, ze bedziemy musieli zaimplementowac en:Template:Hyphenated word start + drugi odpowiednik i przeleciec strony botem. Jak na razie jestesmy chyba osamotnieni przy oczekiwaniu starego zachowania. Jakis inne wikisource nas popra? Ankry (dyskusja) 18:10, 23 lut 2011 (CET)

Właśnie mam jakies wrażenie z dyskusji na bugzilli, że nie tyle nie ma jakiejś innej możliwości, co szukanie innego prostszego sposobu jest "nieopłacalne" dla małego projektu polskiego. Tyko skoro z jednej strony na wikipedii dąży się lub myśli o uproszczeniu odstraszającego wikikodu, to szablony hws i hwe dodają pracy i dodatkowej znajomości wikikodu, zwłaszcza nowym użytkownikom, których często było trzeba informować o stosowaniu "#32;". Czegoś tu nie rozumiem. W ostateczności faktycznie francuski szablon jest łatwiejszy, byle bez kolorowania literek. Tommy J. (pisz) 00:28, 24 lut 2011 (CET)

To samo wrażenie z dyskusji na ircu. Stąd, jeżeli inne projekty nas nie poprą, nie widzę szans na pozostanie przy starym rozwiązaniu.

Pozostaje kwestia nazwania szablonu. Może {{Przeniesienie początek}} i {{Przeniesienie koniec}} ze skrótami {{Pp}} i {{Pk}}? Czy pozostajemy przy angielskich nazwach? Ankry (dyskusja) 07:37, 24 lut 2011 (CET)

Może jednak francuski Tiret, jeden, łatwiejszy, tylko trzebaby wyciąć styl powodujący kolorowanie przenoszonego wyrazu. Tommy J. (pisz) 09:29, 24 lut 2011 (CET)

Ale czemu nazywać po francusku? Też są dwa. Francuzi mają fr:Modèle:Tiret i fr:Modèle:Tiret2; funkcjonalnie podobne do angielskich, tylko bardziej naturalna składnia. Z angielskiego warto wziąć sygnalizowanie błędnego użycia. Ankry (dyskusja) 09:48, 24 lut 2011 (CET)

{{Pp}} i {{Pk}} do przetestowania i ew. zmiany nazwy. Ankry (dyskusja) 10:03, 24 lut 2011 (CET)

the syntax of fr:Modèle:Tiret is actually better than the English template ; it keeps word order. ThomasV (dyskusja) 19:12, 23 lut 2011 (CET)

Dorzucę jeszcze pełną lista błędów w rozszerzeniu Proofread. Beau (dyskusja) 20:22, 6 sie 2011 (CEST)

Zabrałem się za poprawianie rozszerzenia Proofread i 8 moich łatek zostało zaaplikowane. Niestety zanim nowy kod zostanie wdrożony na Wikiźródła może to zająć kilka miesięcy... Beau (dyskusja) 17:48, 24 sie 2011 (CEST)

{{Rozstrzelony}}

Szablon najwyrazniej zle dziala w przypadku tekstow wielowyrazowych. Do poprawienia, czy do udokumentowania z sugestia obejscia. IP-ek zaproponowal cos takiego. Ankry (dyskusja) 06:08, 26 lut 2011 (CET)

przecież dobrze działa? Tommy J. (pisz) 08:59, 26 lut 2011 (CET)

Rzeczywiście. Miałem jakieś chwilowe zaćmienie. Nie ma tematu. Ankry (dyskusja) 11:21, 26 lut 2011 (CET)

Przyciski do wstawiania opisu zmian

Obecnie przyciski umożliwiające szybkie wstawienie opisu zmian są dostępne jako gadżet. Wydaje mi się, że warto je włączyć domyślnie dla wszystkich, tak jak jest to na Wikipedii. Beau (dyskusja) 20:17, 11 mar 2011 (CET)

 Za Ankry (dyskusja) 21:09, 11 mar 2011 (CET)

 Za Jeżeli Beau sądzi, że tak będzie lepiej, to pewnie tak jest. --Teukros (dyskusja) 18:43, 12 mar 2011 (CET)

 Za Owszem, przyda się. Remedios44 (dyskusja) 20:23, 12 mar 2011 (CET)

Możliwe problemy techniczne

Dzisiaj pozmieniałem dużo kodu JavaScript na Wikiźródłach, żeby nie używać przestarzałych mechanizmów MediaWiki. W związku z tym proszę o niezwłoczne zgłaszanie wszystkich zauważonych usterek. Beau (dyskusja) 18:36, 12 mar 2011 (CET)

Narzędzia usprawniające

Często zdarza się podczas edycji wykonywać zestaw tych samych czynności, co po pewnym czasie zaczyna być nużące. Stąd moje pytanie, czy jest w tej chwili zapotrzebowanie na proste gadżety, które ułatwiłyby pracę na wikiźródłach? Prawdopodobieństwo szybkiego wykonania gadżetu przeze mnie wzrasta jeśli: przyda się kilku osobom, pozwala w znaczący sposób zaoszczędzić czas, pomysł jest prosty. Beau (dyskusja) 20:35, 13 mar 2011 (CET)

Pierwsze narzędzie to Wikiźródła:Narzędzia/Skróty klawiszowe. Proszę o zgłaszanie ewentualnych propozycji innych skrótów, bo inaczej trzeba będzie zmienić nazwę gadżetowi... :-) Beau (dyskusja) 17:55, 14 mar 2011 (CET)

Dlaczego Alt+Ctrl+e, a nie Ctrl+. (lub inny znak interpunkcyjny), jak było proponowane? Alt+Ctrl+e również koliduje ze skrótami w Operze, nie mówiąc o tym, że to trzy przyciski zamiast dwóch :( Remedios44 (dyskusja) 18:51, 14 mar 2011 (CET)

Zostawiłem na razie tak jak było i czekam na propozycje. Osoby niebędące na ircu też mogą mieć zdanie na ten temat :-). Beau (dyskusja) 18:57, 14 mar 2011 (CET)

Alt+Ctrl+e otwiera w Operze zarządzanie notatkami. Remedios44 (dyskusja) 19:14, 14 mar 2011 (CET)

Obawiam się, że wybranie skrótów nie będzie proste, ze względu na takie właśnie problemy. Niemniej należy się na coś zdecydować. Wprowadzam zmianę, którą zasugerowałaś, nadal czekam na inne propozycje. Beau (dyskusja) 20:14, 14 mar 2011 (CET)

Usunięcie Edittools

Podejście numer dwa. Proponuję usunięcie linków wstawiających różności spod pola edycyjnego i przeniesienie ich do gadżetu. Gadżet będzie się rozwijał po naciśnięciu guzika, tak jak menu 'Znaki specjalne' na nowym pasku narzędziowym. Obrazek wersji roboczej jest dostępny pod adresem http://img600.imageshack.us/i/screen2pk.png/. Dzięki temu tylko w jednym miejscu będą guziki do wstawiania elementów - na górze strony, zaoszczędzi to ustawicznego przewijania góra-dół dla osób o mniejszych ekranach. Jakieś komentarze? Beau (dyskusja) 20:54, 18 kwi 2011 (CEST)

W zasadzie nie powinno być tym razem problemów. Ze znaków specjalnych korzystałem głównie z "é", nowe - znakomite - rozwiązanie sprawiło, że niemal przestałem z nich korzystać. Używam czasami liter greckich, ale wszystko mi jedno, gdzie są. --Teukros (dyskusja) 20:57, 18 kwi 2011 (CEST)

Dodałem do gadżetów skrypt Edittools, który działa podobnie do rozwijanego panelu 'Znaki specjalne'. Czy ktoś ma jakieś uwagi? Chciałbym usunąć linki z wikikodem i symbolami pod polem edycji i włączyć dla wszystkich ten właśnie skrypt. Beau (dyskusja) 22:14, 21 kwi 2011 (CEST)

Przetestowałam – moim zdaniem rewelacja! Dużo wygodniejsze od obecnej formy. Remedios44 (dyskusja) 22:25, 21 kwi 2011 (CEST)

Działa jak należy. Tommy J. (pisz) 22:46, 21 kwi 2011 (CEST)

Skoro nie ma sprzeciwów, ani innych uwag to włączę ten gadżet dla wszystkich. Guzik na pasku póki co będzie wyglądał tak: . Muszę znaleźć jakąś inną ikonę na nowy pasek. Beau (dyskusja) 18:59, 25 kwi 2011 (CEST)

Póki co, obrazek na starym pasku to , natomiast na nowym . Przy doborze kierowałem się istnieniem pary podobnych obrazków. Beau (dyskusja) 17:40, 26 kwi 2011 (CEST)

Wstrzymam się na razie z włączaniem tego narzędzia wszystkim. Najnowsza wersja rozszerzenia gadżety umożliwia domyślne włączanie pojedynczych gadżetów wszystkim, dodatkowo zarejestrowane osoby mają możliwość ich wyłączenia. Nie wiem jednak kiedy najnowsza wersja tego rozszerzenia, która posiada taką funkcję zostanie zainstalowana. Beau (dyskusja) 18:27, 28 kwi 2011 (CEST)

Używać spacji przy pauzie w starych tekstach, czy nie?

Jak wszyscy wiemy spacja przed pauzą (—) i po niej, to jest "nowinka" edytorska, która w XIX wieku w zasadzie nie występowała. Mamy zaś na Wikiźródłach ścierające się (chociaż mało intensywnie) dwa odmienne poglądy dotyczące odwzorowywania tej sytuacji:

1. Nie wstawiamy spacji przed/po pauzie (tekst jest wtedy wierniej odwzorowywany)
2. Wstawiamy spacje przed/po pauzie (tekst jest wtedy bardziej przyjazny dla współczesnego czytelnika i przeglądarka lepiej sobie radzi z jego łamaniem w okolicach pauzy - nie traktuje pauzy jako fragmentu jednego ze słów).

W sytuacji, gdy dostosowujemy teksty do płynnej zmiany ich szerokości, argument dotyczący problemów z łamaniem wydaje mi się istotny. Można ten problem jednak obejść korzystając z pewnych znaków specjalnych Unicode (ZERO WIDTH SPACE, HAIR SPACE). Tutaj można znaleźć test, a tutaj (en) opis zastosowań w/w znaków. Sugeruję jedynie dopuszczenie a nie zalecenie jednego z testowanych rozwiązań. Pozostają pytania:

1. Które?
2. Czy warto?
3. Jak są te znaki obsługiwane przez przeglądarki, zwłaszcza starsze?
4. Czy takie zastosowanie byłoby zgodne z Unicode?
5. Jak rozwiązać wprowadzanie specjalnych spacji?

Proszę o opinie. Ankry (dyskusja) 11:07, 28 kwi 2011 (CEST)

Proponuję wstawiać spacje. Wiernie układu i tak nie odtworzymy, więc niech chociaż ładnie wygląda. --Teukros (dyskusja) 22:11, 2 maj 2011 (CEST)

Automatyczne pobieranie historii weryfikacji

Załatwione

Dyskutowałem ostatnio na IRC-u z Beau o pomyśle dotyczącym nowego gadżetu, który byłby dla mnie dosyć przydatny; a może także dla innych?

Chodzi o to, że podczas weryfikacji/uwierzytelniania stron (zwłaszcza w takich indeksach, które były weryfikowane w sposób "zrandomizowany") często trudno jest odfiltrować strony, w procesie weryfikacji których brało się udział. Pamięć bywa zawodna, a klikanie po historii jest mało wygodne. Pomyślałem zatem o gadżecie, który by automatycznie pobierał historię strony (niekoniecznie całą, w 99,9% przypadków wystarczy kilka/kilkanaście ostatnich edycji) i w osobnym okienku wyświetlał kto i w jaki sposób weryfikował stronę. Oczywiście gadżet byłby przydatny na pewno nie wszystkim i na pewno nie zawsze, więc powinien dawać możliwość łatwego wyłączenia/włączenia go w razie potrzeby (zwłaszcza, że działający gadżet powodowałby pobieranie z sieci dodatkowej strony).

Beau stwierdził, że to jest wykonalne. Pozostaje pytanie, czy dla kogoś poza mną byłoby to przydatne? Ankry (dyskusja) 11:22, 28 kwi 2011 (CEST)

Na Wikipedii jest gadżet QuickHistory, dzięki któremu po samym najechaniu na zakładkę "historia i autorzy" (bez klikania) wyświetla się okienko z historią ostatnich 15 zmian. Również chętnie zobaczyłabym go na WIkiźródłach. :) Remedios44 (dyskusja) 12:39, 28 kwi 2011 (CEST)

O! To też mogłoby być ciekawe, a mało kosztowne rozwiązanie. Ankry (dyskusja) 12:52, 28 kwi 2011 (CEST)

Gadżet QuickHistory dodany. W zasadzie napisany od nowa. Beau (dyskusja) 18:25, 28 kwi 2011 (CEST)

Dodałem nowy gadżet Historia korekty. Testowałem go na stronie Strona:PL Stanisław Eljasz Radzikowski-Skarby zaklęte w Tatrach 22.jpeg. Muszę tylko poprawić sposób wyświetlania tej listy, żeby była bardziej czytelna i żeby czas zmiany był pokazywany z uwzględnieniem strefy czasowej. Beau (dyskusja) 13:13, 30 kwi 2011 (CEST)

Gadżet śliczny :) Dzięki! Remedios44 (dyskusja) 09:20, 1 maj 2011 (CEST)

Gadżet Historia korekty wydaje się kłócić z gadżetem skrótów klawiszowych – przy włączonej w preferencjach historii korekty nie działają mi skróty – ale, co ciekawe, tylko w nowo tworzonych stronach, przy edytowaniu już istniejących stron działają. Gdy wyłączę gadżet historia korekty, skróty działają wszędzie. Remedios44 (dyskusja) 21:41, 2 maj 2011 (CEST)

I w nowo tworzonych stronach nie widzę żółtej łapki Edittools :( Remedios44 (dyskusja) 21:45, 2 maj 2011 (CEST)

Powinno już działać. Beau (dyskusja) 22:40, 2 maj 2011 (CEST)

Działa. :) Dzięki raz jeszcze! Remedios44 (dyskusja) 22:42, 2 maj 2011 (CEST)

Nowe rozszerzenie

Załatwione

Na wszystkich projektach wikisource zostało uruchomione rozszerzenie DynamicPageList. Pozwala ono na dynamiczne listowanie zawartości kategorii. Przykładowy kod:

<DynamicPageList>
category             = User admin
category             = User en
count                = 10
ordermethod          = sortkey
order                = ascending
</DynamicPageList>

Rezultatem tego wywołania będzie utworzenie listy maksymalnie 10 stron (count=10) administratorów (category=User admin), którzy znają język angielski (category=User en). Dodatkowo lista będzie uporządkowana rosnąco (order=ascending) według klucza sortowania (ordermethod=sortkey). Efekt:

• Wikiskryba:Ankry
• Wikiskryba:Bonvol
• Wikiskryba:Draco flavus
• Wikiskryba:Electron
• Wikiskryba:Fallaner
• Wikiskryba:Joanna Le
• Wikiskryba:Masti
• Wikiskryba:Salicyna
• Wikiskryba:Wieralee

Beau (dyskusja) 15:53, 16 maj 2011 (CEST)

Powiększenie i inne znaki

Mam dwa pytania:

1. Obecnie przy sprawdzaniu tekstu mam taki widok. Czy można w jakiś sposób szybko powiększyć przepisany tekst do takiego rozmiaru, żeby układem mniej więcej przypominał tekst na skanie? Na przykład jakieś przyciski +/- obok?
2. Czy można pod oknem edycji wyświetlić naraz wszystkie sekcje (Polskie litery, Inne znaki, Cyrylica... ), żeby nie trzeba było przeskakiwać pomiędzy nimi wybierając je z listy? Kociak (dyskusja) 02:12, 22 cze 2011 (CEST)

Na życzenie, zmieniłam wyświetlanie Edittools, czyli tego, co jest pod polem edycji — faktycznie było to niewygodne. Polecam jednak również korzystanie z przycisku na pasku edycji (żółta łapka) – jest znacznie wygodniejszy imho. Co do wielkości tekstu – hmmm... U mnie takiej wielkiej różnicy między tekstem a skanem, na stronie którą podałeś jako przykład, nie ma – to raczej zależy pewnie od przeglądarki albo używanej skórki. Spróbuj może na skórce Monobook zamiast Vectora, albo po prostu powiększać tekst w przeglądarce (Ctrl +)? Remedios44 (dyskusja) 06:40, 22 cze 2011 (CEST)

P. S. Po wejściu w edycję, na pasku edycji są przyciski do powiększania lub zmniejszania skanu. Jednak kto wie, może rzeczywiście przydałby się gadżet umożliwiający, w przestrzeni Strona, zmniejszanie i powiększanie przepisanego tekstu. Jeżeli faktycznie byłoby to przydatne, można spytać naszego magika, czy dałoby się coś takiego zrobić. Remedios44 (dyskusja) 13:07, 22 cze 2011 (CEST)

Mam rozdzielczość 1440x900, Google Chrome. Ctrl+ powiększa wszystko, łącznie ze skanem. Dodanie takiej zmiany wielkości tekstu nie powinno być trudne, a przynajmniej dla mnie byłoby wygodne przy korygowaniu lub uwierzytelnianiu. Kociak (dyskusja) 14:31, 22 cze 2011 (CEST)

Zastanawiam się czy rzeczywiście jest sens robić gadżet. Inne przeglądarki np. Mozilla Firefox posiadają tę funkcjonalność. Spróbuj poszukać rozszerzenia do Chrome, które posiada umożliwia manipulowanie wyłącznie rozmiarem tekstu. Chrome ma w preferencjach możliwość zmiany domyślnej wielkości czcionki, ale niestety to ustawienie dotyczy wszystkich stron, przez co przełączanie jest dość niewygodne. Beau (dyskusja) 20:04, 22 cze 2011 (CEST)

Poszukam, ale prawdopodobnie będą tylko takie, które zwiększają cały tekst na stronie, a nie wybraną część (w tym przypadku jedynie tekst z <div class="pagetext">) Kociak (dyskusja) 20:27, 22 cze 2011 (CEST)

Please, create some templates

Sorry for English. Please, create some templates - wikibooks, wikisłownik, commons, commonscat. --Averaver (dyskusja) 20:28, 13 lip 2011 (CEST)

OK. There's no problem... We can create these templates, but what for? Electron  ^<Odpisz> 23:38, 13 lip 2011 (CEST)

You may go to my Page Wikiskryba:Averaver and view some examples of these templates. I schedule to place these templates on some Pages - Kategoria:Przekłady z języka angielskiego, etc. --Averaver (dyskusja) 04:46, 14 lip 2011 (CEST)

OK. I see. I'll try to create them today for you. Electron  ^<Odpisz> 09:16, 14 lip 2011 (CEST)

Done -> Szablon:wikibooks, Szablon:wikisłownik, Szablon:commons, Szablon:commonscat & Szablon:commonsall. Regards Electron  ^<Odpisz> 11:15, 14 lip 2011 (CEST)

Thanks. --Averaver (dyskusja) 17:29, 14 lip 2011 (CEST)

Template similar as the w:Szablon:Siostrzane projekty

Please create a new group link template similar as in the PL Wikipedia - w:Szablon:Siostrzane projekty. See example on my page - Wikiskryba:Averaver. --Averaver (dyskusja) 12:25, 30 lip 2011 (CEST)

OK. I'll try it add tomorrow. Regards :) Electron  ^<Odpisz> 23:54, 31 lip 2011 (CEST)

Wydaje się, że był taki szablon ale został skasowany -> Szablon:Siostrzane projekty. Może dobrze by było go odkasować? Nie chciałbym wyważać otwartych drzwi. Electron  ^<Odpisz> 10:07, 1 sie 2011 (CEST)

To był zupełnie inny szablon, tylko nazwę miał taką samą. Odnośnie w:Szablon:Siostrzane projekty - gdzie właściwie mielibyśmy ten szablon wstawiać? W tekstach linki do siostrzanych wstawiamy w szablonie nagłówek lub dane tekstu. --Teukros (dyskusja) 12:01, 1 sie 2011 (CEST)

Szablon jest potrzebny k. Averaver, chyba wie co robi ale oczywiście nie wadzi się spytać...Electron  ^<Odpisz> 12:17, 1 sie 2011 (CEST)

Could you explain the main purpose of this template using? Teukros has doubts what it would be for? Electron  ^<Odpisz> 12:17, 1 sie 2011 (CEST)

How many pages do you intend insert this template to? I don't think there is a point in creating such template for only one page. Beau (dyskusja) 17:39, 1 sie 2011 (CEST)

For example - Kategoria:Sztuka, Kategoria:Literatura and other main categories. --Averaver (dyskusja) 18:07, 1 sie 2011 (CEST)

OK. There were no more objections so I've done the template -> Szablon:Siostrzane projekty. Regards Electron  ^<Odpisz> 10:36, 3 sie 2011 (CEST)

Thank you. I updated both these categories. --Averaver (dyskusja) 18:51, 3 sie 2011 (CEST)

Utworzenie "połączenia" pomiędzy stroną z przestrzeni Strona i stroną z przestrzeni File: na commons

Załatwione

Na prośbę Beau, przypominajka:). Przydałaby się (w każdym razie mi) możliwość przechodzenia pomiędzy "proofreadowaną" stroną a jej odpowiedniczką na commons. Obecnie zakładka grafika przenosi od razu do skanu, z którego nie ma możliwości (a w każdym razie ja jej nie znam) na przejście do strony na commons. Tyle.:) — Paelius (dyskusja) 22:27, 8 sie 2011 (CEST)

Wydało mi się to na tyle proste, że zrobiłem gadżet "Opis pliku" od razu. Jest na tyle mało widoczny, że chyba można go włączyć wszystkim użytkownikom. Beau (dyskusja) 22:38, 8 sie 2011 (CEST)

Ale on opisuje plik na Wikisource którego nie ma ale mogę przesłać :) Tommy J. (pisz) 23:05, 8 sie 2011 (CEST)

Hm? Możesz podać konkretny przykład, gdzie występuje problem? W tej chwili skrypt pokazuje lokalną stronę - jeśli wpis lokalnie nie istnieje, to jest pokazywany ten z commons. Beau (dyskusja) 19:31, 9 sie 2011 (CEST)

Chyba nie ma żadnego problemu, po prostu nie zauważyłem i kliknąłem na podstronie pliku djvu, stąd mi pokazało że taki plik nie istnieje, przy jpg działa bez zarzutu. Przepraszam :) Tommy J. (pisz) 21:06, 9 sie 2011 (CEST)

Masz rację, o przypadkach z plikami, które mają wiele stron nie pomyślałem. W tym wypadku powinno przenosić na stronę z opisem całego djvu. Poprawię. Beau (dyskusja) 21:08, 9 sie 2011 (CEST)

Masowa zmiana nazw - Listy Annibala z Kapui

Załatwione

Nazwy plików dla tego utworu nie są najszczęśliwsze, w związku z czym zaproponowana została ich zmiana. Poniżej przestawiam wycinek listy zmian:

• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-1.jpg -> File:Listy Annibala z Kapui 001.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-2.jpg -> File:Listy Annibala z Kapui 002.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-3.jpg -> File:Listy Annibala z Kapui 003.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-4.jpg -> File:Listy Annibala z Kapui 004.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-55.jpg -> File:Listy Annibala z Kapui 055.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-56.jpg -> File:Listy Annibala z Kapui 056.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-264.jpg -> File:Listy Annibala z Kapui 264.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-265.jpg -> File:Listy Annibala z Kapui 265.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-266.jpg -> File:Listy Annibala z Kapui 266.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300-pdf-267.jpg -> File:Listy Annibala z Kapui 267.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-295.jpg -> File:Listy Annibala z Kapui 295.jpg
• File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-296.jpg -> File:Listy Annibala z Kapui 296.jpg

Pełna lista na stronie Wikiskryba:Beau/brudnopis. Po przenosinach na commons, zostaną wykonane przenosiny stron w przestrzeni strona, aktualizacja indeksu, a na końcu poprawienie linkujących o ile takowe istnieją. Beau (dyskusja) 19:25, 9 sie 2011 (CEST)

Jak dla mnie OK. Ankry (dyskusja) 21:13, 9 sie 2011 (CEST)

Na IRCu padła jeszcze propozycja Paeliusa: File:Listy Annibala z Kapui Arcy Biskupa Nea -Pages 5 - 300--pdf-1.jpg -> File:Listy Annibala z Kapui (Przezdziecki) 001.jpg. Jak nie będzie innych uwag, to zastosuję tą drugą wersję. Beau (dyskusja) 21:06, 10 sie 2011 (CEST)

Przenosiny zostały wykonane. Beau (dyskusja) 18:17, 11 sie 2011 (CEST)

Linkujące z innych projektów

Załatwione

Dodałem testowo nowy gadżet o nazwie Linkujące interwiki, który pozwala na wylistowanie stron na innych polskojęzycznych projektach, które się odwołują do bieżącej. Gadżet nie obsługuje w tej chwili linków z innych przestrzeni nazw niż główna. Jakieś sugestie na jego temat? Beau (dyskusja) 21:39, 11 sie 2011 (CEST)

A gdyby przed sprawdzeniem mozna było opjonalnie wybrać poszczególne projekty w któych chce się dokonać sprawdzenia? Bo mi tak sprawdza sprawdza... i jeszcze nie sprawdziło (testowane na hasłach słownika etymologicznego) Tommy J. (pisz) 20:38, 12 sie 2011 (CEST)

Gadżet działa, jednak tylko dla użytkowników https://secure.wikimedia.org. Muszę go poprawić, żeby działał wszystkim. Beau (dyskusja) 13:21, 13 sie 2011 (CEST)

Poprawiłem. Linki z innych przestrzeni nazw powinny się już wyświetlać poprawnie. Beau (dyskusja) 18:24, 13 sie 2011 (CEST)

Działa, sprawdzałem w przestrzeni głównej i Autor, teraz będzie wiadomo na jakich projektach trzeba nas zalinkować :) Tommy J. (pisz) 18:45, 13 sie 2011 (CEST)

Centrowanie tytułów w wierszach

Z centrowaniem tytułów wierszy jest generalnie problem, gdyż używany zazwyczaj w tym celu tag <center> centruje w obrębie całego dostępnego pola. W przestrzeni Strona to specjalnie nie przeszkadza, natomiast po zainkludowaniu tekstów do przestrzeni głównej może wyglądać dziwnie, zwłaszcza, gdy wiersz jest wyświetlany z lewej strony okna. Pytanie, czy coś z tym robimy, czy nie? Bo chciałem przedyskutować propozycje globalnego rozwiązania tego problemu na przyszłość.

Mam następujące pomysły:

1. Używanie {{tab|szerokość}} (z parametrem); upierdliwe, bo parametr trzeba dobierać osobno dla każdego tytułu i lepiej podawać wartość w em-ach lub ex-ach niż w pikselach (żeby efekt nie był zależny od wybranej skórki, czy rozmiaru fontu w ustawieniach przeglądarki)
2. Umieszczanie końcowego wyniku (czyli tekstu zainkludowanego do przestrzeni głównej) w wycentrowanej tabelce (jak robią to np. na enwikisource za pomocą szablonu {{block center}}. Trzeba wtedy robić to konsekwentnie.
3. Umieszczenie centrowanego tytułu w sekcji <div> z odpowiednim stytlem, np. style="text-align:center; max-width:XXXem;" (gdzie XXX byłoby liczbowym parametrm szablonu implementującego tego div-a. (Np. {{center|centrowany tekst|XXX}}).

Inne pomysły? Komentarze?

Moim zdaniem rozwiązanie numer dwa jest najlepsze. Beau (dyskusja) 13:50, 14 sie 2011 (CEST)

Skrypt linków interwiki do Oldwikisource

Załatwione

Mógłby ktoś wkleić skrypt, który umożliwia wstawianie linków interwiki do Oldwikisource -> [7]? Należy go przekopiować do -> MediaWiki:Common.js. By się przydał. Mam tam do zlinkowania kilka tekstów. Electron  ^<Odpisz> 11:17, 19 sie 2011 (CEST)

Chodzi o ten skrypt -> [8], można go też zaimportować wstawiając link:

importScriptURI('http://wikisource.org/w/index.php?title=MediaWiki:OldwikisourceInterwiki.js&action=raw&ctype=text/javascript');

Ten sposób byłby chyba lepszy (bo mielibyśmy ewentualną "zdalną" aktualizację skryptu). Electron  ^<Odpisz> 11:46, 19 sie 2011 (CEST)

Ten skrypt ma jedną wadę - głupieje przy linkach w tekście. Podaj listę prefiksów, które chcesz wykorzystać, a zrobię skrypt, który będzie poprawiał wszystkie linki do tych wersji językowych i kierował je na oldwikisource. Beau (dyskusja) 16:15, 19 sie 2011 (CEST)

Na razie interesują mnie tylko prefixy "be:" i "be-x-old:" ale może lepiej by zrobić tak (jak tam jest proponowane), prefix "mul:" aby kierował do Oldwikisource - nie kłóciło by się to z obecnymi linkami a działało by dla wszystkich tekstów tam zgromadzonych. Było by to bardziej uniwersalne. Można też by pomyśleć, żeby np. złożony prefix: "mul:be:" kierował już do konkretnego języka ale to drobiazgi. Jeszcze jedna uwaga: dobrze by było aby to także działało w Monobooku, bo to uniwersalna skórka (bywa zwykle na każdej serwisie typu wiki) i głównie z niego korzystam. Nie wiem czy da się to wszystko zrobić ale dzięki za chęć pomocy. Electron  ^<Odpisz> 01:27, 21 sie 2011 (CEST)

Włącz sobie gadżet Linki do wikisource.org i sprawdź, gdzie prowadzą linki z tych prefiksów. Jeśli nie będzie żadnych problemów, to włączę ten skrypt wszystkim. Beau (dyskusja) 08:45, 21 sie 2011 (CEST)

Włączyłem i sprawdziłem-> Wikiskryba:Electron/Test ale dalej likuje w krzaki, tzn. daje linki -> http://be.wikisource.org/wiki/xyz i http://be-x-old.wikisource.org/wiki/xyz do strony z komunikatem: "Welcome to Wikimedia Unfortunately, this wiki does not exist yet, or it has been closed. You may be looking for one of our other projects below. If you would like to request that this wiki be created, see the requests for new languages page on Meta-Wiki." Sprawdzałem w monobooku i vectorze, przeglądarka FF6.0, odświeżałem strony (CTRL-F5 i purge). Spróbuję jeszcze jutro na innym kompie. Electron  ^<Odpisz> 00:06, 22 sie 2011 (CEST)

Na innym kompie (inna sieć) jest dokładnie to samo... Electron  ^<Odpisz> 13:55, 22 sie 2011 (CEST)

Poprawiłem skrypt odrobinę, zobacz teraz. Testowałem na FF5.0 i działa. Linki ulegną zmianie dopiero jak się w całości załaduje strona. Beau (dyskusja) 21:29, 22 sie 2011 (CEST)

Tak, teraz chodzi jak należy. Dzięki. W najbliższym czasie przejżę mój wkład pod kątem białoruskich interwików... Electron  ^<Odpisz> 10:19, 23 sie 2011 (CEST)

Ja w takim razie włączę wszystkim ten skrypt. Beau (dyskusja) 18:35, 23 sie 2011 (CEST)

skróty klawiszowe

Załatwione

Nie działają mi obecnie skróty klawiaturowe, które ustawiłem sobie tutaj. Czy wie ktoś może z jakiej to przyczyny? Z góry dzięki za pomoc. Vearthy (dyskusja) 15:01, 9 wrz 2011 (CEST)

Spróbuj sobie wyczyścić pamięć podręczną w przeglądarce internetowej. Zmieniałem coś ostatnio w gadżetach, więc twoja przeglądarka mogła nie odświeżyć wszystkiego. Jeśli to nie pomoże zamień kod na wskazanej stronie na poniższy:

jQuery(document).ready(function() {
	shortcutsGadget.addTextShortcut('ctrl+,', 'É', '', '');
	shortcutsGadget.addTextShortcut('ctrl+q', '—', '', '');
	shortcutsGadget.addTextShortcut('ctrl+m', '[[Słownik etymologiczny języka polskiego/', ']]', 'hasło');
});

Beau (dyskusja) 18:03, 9 wrz 2011 (CEST)

Dzięki za pomoc. Nadal jednak mam mały problem. Wygląda na to, że jeszcze skrót "ctrl + ." z tej strony już nie działa, nawet jeśli go wklepię sobie do common.js. Vearthy (dyskusja) 20:00, 9 wrz 2011 (CEST)

Czy ten skrót działał wcześniej? Jaką masz przeglądarkę internetową? Beau (dyskusja) 11:16, 10 wrz 2011 (CEST)

Tak, działał. Mam Firefoksa, ale tego skrótu nie ma w wykazie skrótów na stronie programu. Vearthy (dyskusja) 11:22, 10 wrz 2011 (CEST)

Sprawdziłem to na przeglądarce Mozilla Firefox 6.0 i u mnie działa bez problemów. Umieszczenie drugi raz tego samego skrótu skutkowało wstawianiem znaku é dwa razy. Beau (dyskusja) 13:22, 17 wrz 2011 (CEST)

No nareszcie działa. Wczoraj jeszcze był z tym problem... Dzięki ogromne za pomoc. Vearthy (dyskusja) 14:33, 17 wrz 2011 (CEST)

Tak, działa... ale jedynie w przestrzeniach różnych od "strona". Czy tylko ja mam ten problem? Sprawdzałem na losowych stronach z problemami, nie- i skorygowanych oraz na uwierzytelnionych. Nie działa. Za to tutaj i w przestrzeni użytkownika wszystko jest jak należy. Vearthy (dyskusja) 18:34, 17 wrz 2011 (CEST)

U mnie tak samo – tu skróty działają, w przestrzeni Strona: nie. Nie mam pojęcia, w którym momencie ten problem się pojawił, bo przez jakiś czas nie miałam potrzeby używać skrótów (w Vol. legum te znaki nie występują), dopiero dziś musiałam użyć więc dziś zauważyłam. Remedios44 (dyskusja) 13:05, 18 wrz 2011 (CEST)

Problem wynika z tego, że proofread usuwa pole edycyjne i wstawia nowe. Skóry były związane z usuwanym polem edycji. Teraz przypisałem je do całej strony, a nie do pola edycyjnego. Skutkiem ubocznym tego będzie działanie skrótów we wszystkich polach, np. opisu zmian. Beau (dyskusja) 19:09, 18 wrz 2011 (CEST)

Forma żeńska dla przestrzeni nazw użytkownika

Załatwione

Witajcie! Zdaje się, że Wikiźródła są najbardziej kłopotliwe pod tym względem... Już niedługo projekty Wikimedia przechodzą na oprogramowanie MediaWiki 1.18 i jedną z nowości jest stworzenie przestrzeni nazw użytkownika dedykowanej kobietom. Od strony technicznej nie jest to utworzenie osobnej przestrzeni nazw, ale rozwiązanie polegające na umożliwieniu stworzenia wariantu nazwy przestrzeni nazw zależnego od płci. Domyślnie dla instalacji MediaWiki w języku polskim jest to "Użytkownik" i "Użytkowniczka". Natomiast obecnie w Wikiźródłach jest zdefiniowana lokalna przestrzeń nazw użytkownika, czyli "Wikiskryba". Gdy zostanie włączona wersja MW 1.18, to osoby, które mają w preferencjach ustawioną płeć "kobieta", to ich przestrzeń nazw przejmie nazwę domyślną instalacji, czyli "Użytkowniczka", a w pozostałych przypadkach pozostanie "Wikiskryba". W celu uniknięcia tych rozbieżności, należy zawczasu zdefiniować przestrzeń nazw użytkownika dla kobiet. I tutaj jest pytanie do społeczności, jaka to ma być nazwa:

1. Wikiskrybka
2. Wikiskryba - czyli taka sama jak dla mężczyzn uznając ją jako genderowo neutralną
3. inna propozycja?

W związku z tym, że niezbyt często odwiedzam ten projekt, to w razie pytań proszę dawać mi znać o ich pojawieniu się poprzez e-mail. Za około tydzień postaram się tu wrócić i zgłosić na Bugzilli odpowiednie konfiguracje dla wszystkich polskojęzycznych projektów Wikimedia. LeinaD dyskusja 01:12, 17 wrz 2011 (CEST)

Najlepiej jakby wypowiedziały się osoby, których zmiana dotyczy. Moim zdaniem na wszystkich projektach mogłoby być Użytkownik i Użytkowniczka. Beau (dyskusja) 12:38, 17 wrz 2011 (CEST)

Wikiskryba to nazwa z wieloletnią już tradycją a tradycję należy szanować. Zresztą jest to nazwa, który w ładny sposób odróżnia Wkiźródła na tle innych projektów. Co do formy żeńskiej to chyba, rzeczywiście najlepiej by było aby wypowiedział się na ten temat nasz jedyny aktywny (ostatnimi czasy jakby trochę mniej) rodzynek... Jednak moim zdaniem wikiskrybka to brzmi dumnie ;) Electron  ^<Odpisz> 01:13, 18 wrz 2011 (CEST)

Rodzynków jest u nas więcej niż jeden. Jednak jeśli o mnie chodzi, to optowałabym za wersją nr 2, czyli pozostaniem przy "Wikiskryba". Remedios44 (dyskusja) 11:31, 18 wrz 2011 (CEST)

Fakt, szkoda, że tak mało się wypowiadają... Electron  ^<Odpisz> 00:31, 19 wrz 2011 (CEST)

Ja jestem z tych co wypowiadają się być może zbyt często... Zachodzę tylko w głowę, cóż takiego brzydkiego mogłem palnąć powyżej? Stwierdziłem tylko fakt, że "dziewczyny" są mniej widoczne na forum niż "chłopaki"... więc mniej znam ich zdanie. Co mnie smuci. Bo jestem z tych ciekawych. Electron  ^<Odpisz> 09:08, 19 wrz 2011 (CEST)

Dla mnie również opcja nr 2 jest najlepsza (Wikiskrybka brzmi sztucznie i raczej na siłę), z kolei przejście na ogólną przestrzeń "Użytkownik i Użytkowniczka" może i jest praktyczne, ale obecna nazwa Wikiskryba pozytywnie wyróżnia projekt (tak jak Wikireporter na Wikinews - tyle, że w tym przypadku forma żeńska brzmi dość naturalnie). Poza tym zadeklarowanie płci w preferencjach zmienia odpowiednio formy szablonów babel (redaktorka, użytkowniczka). Mnie wystarczy. :) Nutaj (dyskusja) 14:30, 19 wrz 2011 (CEST)

przejście na ogólną przestrzeń "Użytkownik i Użytkowniczka" może i jest praktyczne - jak rozumiem to ja to te nazwy będą domyślne jak ktoś będzie chciał postawić wiki w języku polskim. Natomiast na wikiźródłach ta nazwa nie będzie się wyświetlała wprost (acz będzie można jej używać tak samo jak dotychczas USER). PMG (dyskusja) 22:09, 19 wrz 2011 (CEST)

OK. Nie będę się upierał przy "Wikiskrybce" jeśli głównym zainteresowanym ta nazwa nie leży. Może faktycznie brzmi trochę sztucznie (w dawnych czasach tą działalnością zajmowali się głównie panowie i to należący zwykle do stanu duchownego, więc nazwa Wikiskrybki się jeszcze nie upowszechniła i nie "osłuchała"). Chociaż moim zdaniem jest to nazwa dość sympatyczna.

Niech będzie więc Wikiskryba. Pewnie będzie z tym mniej roboty przy zmianach. Electron  ^<Odpisz> 11:02, 20 wrz 2011 (CEST)

:::Och dzięki Ci za Twą łaskę że nasze dziewczynki będą mogły pozostać Wikiskrybami, naprawdę wielkie dzięki. Ciebie naprawdę nie nudzi już własne gadanie od rzeczy? Tommy J. (pisz) 18:40, 20 wrz 2011 (CEST) Troling skreślił --Teukros (dyskusja) 19:58, 20 wrz 2011 (CEST)

używanie ligatur

Pojawiła sie dziś różnica poglądów w tej materii, więc przenoszę dyskusję tutaj. Pytanie brzmi: w jaki sposób przepisując tekst powinniśmy odwzorowywać ligatury drukarskie typu "fi":

• literalnie (jeden znak "fi")
• dwa znaki "fi".

W chwili obecnej jest "każdy sobie rzepkę skrobie" (czyli każdy wikiskryba robi po swojemu).

Gdyby chodziło tylko o jak najwierniejsze odwzorowanie w przestrzeni Strona, to byłbym za pierwszym rozwiązaniem. Jednakże przestrzeń Strona jest przestrzenią czysto techniczną. Tekst z przestrzeni Strona jest inkludowany do przestrzeni głównej, gdzie wg mnie nie powinno być takich "naleciałości" składu drukarskiego, a ewentualnym wyświetlaniem "fi" jako "fi" powinien się zająć program renderujący tekst. Ligatury są to znaki drukarskie, służące do prezentacji tekstu, jednakże sam tekst (słowa) powinien sie wg mnie składać z liter, a nie ligatur. Inne problemy, które widzę w przypadku używania ligatur, to:

• potencjalne problemy z kopiowaniem do formatu tekstowego, zwłaszcza, gdy docelowo używane jest inne kodowanie niż Unicode.
• Problemy z wyszukiwaniem (Zofia i Zofia to są dwa różne słowa dla wyszukiwarki)

Wg mnie pogarszają one w tym przypadku jakość tekstu w porownaniu do wersji nie-proofread (nie zawierającej ligatur).

Z drugiej strony każdy tekst drukowany powinien zawierać ligatury typu "fi", a nie rozdzielone litery "fi". Jeśli jest inaczej, to drukarnia ma (miała) kiepskiego zecera...

Może warto w tej kwestii wypracować jakieś ogólne zalecenie? Ankry (dyskusja) 18:16, 18 wrz 2011 (CEST)

fi jest li tylko ligaturą graficzną występującą w określonych fontach, natomiast w przypadkach znaków, takich jak e ścieśnione, czy długie s są to jednak głoski o określonym wydźwięku (używane w tamtych czasach). — Paelius (dyskusja) 18:25, 18 wrz 2011 (CEST)

Czyli, jeśli w tekście odczytuję na skanie „&” to mógłbym swobodnie wpisywać „et”, tak? I, no cóż, jeśli wyszukiwarka „nie wie”, że „fi” można było zapisywać (drukować) niegdyś jako „fi”, to, to zła wyszukiwarka jest... DrPZ (dyskusja) 20:10, 18 wrz 2011 (CEST)

No, znów nie do końca :) Ligatura & może zostać oddana nie tylko jako et, ale również jako and, a nawet jako i. W tym wypadku z kolei ligatura zaczęła żyć niejako własnym życiem i znak & stał się niejako synonimem wyrazu i. — Paelius (dyskusja) 21:06, 18 wrz 2011 (CEST)

PS. A co do przeglądarek: Firefox nie rozróżnia, nie wiem jak inne. I, o ile & od et da się nawet odróżnić, to fi od fi to już wyższa szkoła jazdy. — Paelius (dyskusja) 21:10, 18 wrz 2011 (CEST) A nawet nie wyższa... u mnie wyświetlają się identycznie (chyba, że na 800% powiększeniu — wtedy może z pół milimetra różnicy jest. — Paelius (dyskusja) 21:16, 18 wrz 2011 (CEST)

I tak powinno być: przy renderingu zawsze powinna być używana ligatura. Natomiast jeśli spróbujesz myszką zaznaczyć samo "f" lub samo "i", to w przypadku znaku ligatury w treści dokumentu - zdecydowanie się to nie uda :)

MZ znak ligatury powinien być używany tylko i wyłącznie w przypadkach, gdy piszemy o typografii omawiając tę konkretną ligaturę. Ankry (dyskusja) 21:22, 18 wrz 2011 (CEST)

Ligatury miały sens w druku, gdy książka była niezmienna. Tu natomiast to zupełnie zbędna robota, która i tak będzie niewidoczna dla czytelnika używającego różnych przeglądarek, fotów, rozdzielczości itp. --Teukros (dyskusja) 21:42, 18 wrz 2011 (CEST)

Podsumowując, dla ligatur, które bez większych problemów i dylematów można rozdzielić na poszczególne litery (fi, fl, ffi, ffl) zasadne wydaje się zalecenie wpisywania poszczególnych liter; a ligatury bardziej zniekształcające litery? (np. æ, ŋ) DrPZ (dyskusja) 23:57, 18 wrz 2011 (CEST)

Jeśli się istotnie różnią od sekwencji liter składowych (np. "ae" != "æ", "maestro" != "mæstro" itp.) należałoby używać tej formy, która jest w tekście. Jak widać nie są to ligatury typowo typograficzne. Ankry (dyskusja) 00:06, 19 wrz 2011 (CEST)

Wyświetlanie stron z innych projektów

Ankry wspomniał na IRCu o włączeniu u nas skryptu JavaScript, który umożliwiałby wyświetlanie stron pobranych z innych projektów. Aktualnie nie ma zapotrzebowania na taką funkcję, a obecna implementacja ma swoje ograniczenia. Moim zdaniem jeśli ktoś chce czytać pracę napisaną w innym języku to powinien zajrzeć do projektu w tym języku. Beau (dyskusja) 19:27, 19 wrz 2011 (CEST)

Chodziło akurat o prace wielojęzyczne, których fragmenty funkcjonują na innych Wikisource. Ale to rzeczywiście nic pilnego. Ankry (dyskusja) 20:43, 19 wrz 2011 (CEST)

Wikiźródła przez https://

Załatwione

W zasadzie to pytanie do Beau, ale dotyczy na pewno części edytujących. W związku z przejściem wikipedii na zwykły https:// z pominięciem secure'a powstała kwestia konieczności każdorazowego logowania się na oba projekty. Czy projekty siostrzane także są przewidziane do tej zmiany? Pozdrawiam. — Paelius (dyskusja) 10:26, 4 paź 2011 (CEST)

Nie rozumiem pytania. Jeżeli korzystasz z wersji bezpiecznej (czyli https) to nie powinieneś logować, czy też używać serwisów Wikimedia dostępnych bez szyfrowania (czyli http). W przeciwnym razie nie ma sensu używać wersji bezpiecznej. Beau (dyskusja) 19:47, 4 paź 2011 (CEST)

Sprawa nieaktualna. Przepraszam za zamieszanie. — Paelius (dyskusja) 11:55, 5 paź 2011 (CEST)

Statystyki odwiedzin

Załatwione

Witajcie! Nie śledzę już wszystkich dyskusji na Wikiźródłach tak jak kiedyś, więc wybaczcie, jeśli informuję o czymś, o czym już od dawna wiecie :). Otóż można oglądać statystyki odwiedzin każdej strony w tym projekcie za pomocą narzędzia znanego dobrze wszystkim z Wikipedii. Problem polega tylko na tym, że aby wyświetlić statystyki, to trzeba odpowiednio przeformatować adres w przeglądarce, bo interfejs (formularz) nie uwzględnia projektów siostrzanych (poza Commons). Rzecz wygląda tak: [9]. Przede wszystkim po "grok.se" musi być "pl.s", co identyfikuje projekt, potem data (rok-miesiąc-dzień), a na końcu nazwa strony z podkreślnikami zamiast spacji. I tyle :-). Myślę, że warto dodać link do statystyk odwiedzin na każdej stronie historii zmian (analogicznie jak na Wikipedii). Awersowy (dyskusja) 08:29, 5 paź 2011 (CEST)

Dzięki za info, ja przynajmniej o tym do tej pory nie wiedziałam. Eksperymentując z urlem, znalazłam też listę 1000 najczęściej odwiedzanych stron, niestety tylko z grudnia 2010. Jako że to był grudzień, dominują kolędy, ale i tak lista bardzo interesująca. Remedios44 (dyskusja) 13:04, 6 paź 2011 (CEST)

Dodałem pasek z narzędziami taki sam, jak jest na Wikipedii. Beau (dyskusja) 19:14, 21 paź 2011 (CEST)

Szablon:Autorinfo bez zdjęcia

Załatwione

Ten szablon coś źle działa jeśli nie ma zdjęcia, np. produkuje coś jak tutaj -> Autor:Ludwik Kropiński. Daje niepotrzebny wpis: [ [Grafika:|208px] ] co nie jest zbyt estetyczne. U mnie w OP mam go trochę przerobionego i jest wszystko OK (patrz, np. tutaj-> [10]) ale w tej chwili nie pamiętam już co w nim zmieniałem. Jakby ktoś miał czas i chęci to byłbym wdzięczny za doszlifowanie szablonu też tutaj. Nie chciałbym eksperymentować na nie swoim terenie ;) Electron  ^<Odpisz> 23:33, 10 paź 2011 (CEST)

Może teraz będzie nieco lepiej? Ankry (dyskusja) 23:54, 10 paź 2011 (CEST)

Dzięki :) Praca boi się mistrza (z ros.: Rabota mastiera baitsa ;) Electron  ^<Odpisz> 00:15, 11 paź 2011 (CEST)

Problem(ik) przy edycji

Załatwione

Właśnie zauważyłem, że ilekroć edytując stronę wywołam przycisk Pokaż podgląd lub Pokaż zmiany, tylekroć przed sekcją <references/></div></noinclude> edytowanej strony „dopisuje się” dodatkowy znak wersu/akapitu (np. tu), a zmiana jedynie <pagequalitylevel=> dopisuje jeden taki znak (np. tu). Jest to o tyle denerwujące, że w okienku edycji „nie widzę” tych dodatkowych znaków i nie jestem w stanie ich wykasować, nawet jeśli je zauważę. Dzieje się tak zarówno pod FF jak i IE. Być może zależne od ustawień preferencji, ale nie wyśledziłem których. Jest jakiś sposób, aby to obejść? DrPZ (dyskusja) 10:39, 11 paź 2011 (CEST)

Możesz je pousuwać wchodząc w edycją nagłówka/stopki (ikonka [+]). Ale jeden i tak się doda...

Najwyrażniej jakaś pluskwa w ProofreadPage lub naszych skryptach; ale może Beau to zlokalizuje. Ankry (dyskusja) 10:47, 11 paź 2011 (CEST)

Ciekawa ta ikonka... Nigdy jej nie zauważyłem :) Dzięki. DrPZ (dyskusja) 10:57, 11 paź 2011 (CEST)

Problem występuje też na enwikisource, więc to jakaś bardziej globalna pluskwa. Ankry (dyskusja) 13:52, 11 paź 2011 (CEST)

A poprawka jest na bugzilli... Ankry (dyskusja) 14:09, 11 paź 2011 (CEST)

Czyżby naprawione? DrPZ (dyskusja) 13:42, 29 paź 2011 (CEST)

Na to wygląda. Długo trwao. Ankry (dyskusja) 18:16, 29 paź 2011 (CEST)

Jak eksportować...

Można w jakiś prosty sposób eksportować tekst z wikiźródeł? Chciałbym chociażby tekst Notatki myśliwskie z Indyi czy Rękopis Znaleziony w Saragossie, ale chciałbym to jakoś przekopiować na czytnik.. Da radę? Bartekfm (dyskusja) 16:55, 25 lis 2011 (CET)

Eksportować w formacie Mediawiki może każdy ze strony: Specjalna:Eksport ale do czytnika to to raczej mało przydatne... Natomiast można skorzystać z Tworzenie książki, postępując jak tam jest napisane, można wybrać strony i stworzyć z nich plik pdf lub odf. Nie zawsze wychodzi idealnie ale czytać można. Inne opcje znajdziesz w sidebarze (po lewej stronie, zakładka -> Drukuj lub eksportuj). Electron  ^<Odpisz> 17:48, 25 lis 2011 (CET)

No właśnie eksport do PDF był kompletną porażką, plik .pdf zawierał jedynie nazwy plików .jpg :( Eksportowanie zawartości tworzy pliki .html, które w czytniku są kompletnie nieużyteczne. Trzeba popracować nad udostepnianiem tych tekstów bo przecież trudno sobie wyobrazić, że ktoś siedzi z otwartym laptopem i czyta bezpośrednio z wiki... już nie wspominając że potrzebny jest do tego internet. Bartekfm (dyskusja) 18:03, 25 lis 2011 (CET)

Zainstaluj sobie drukarkę plików PDF i wydrukuj stronę z wiki do PDFa. Beau (dyskusja) 18:31, 25 lis 2011 (CET)

Rozszerzenie Proofread

Ostatnio wziąłem się za poprawianie błędów w tym oprogramowaniu, w związku z czym liczba otwartych zgłoszeń na bugzilli spadła. Jeśli macie jakieś sugestie na temat działania tego rozszerzenia to mogę spróbować coś poprawić/ulepszyć. Beau (dyskusja) 09:45, 27 sie 2011 (CEST)

1. Chciałbym, aby w spisie stron tekstu - na stronach z przestrzeni indeks oznaczone były strony, które mogę sprawdzić, czyli takie którym nie zmieniałem poziomu sprawdzenia. Wyobrażam to sobie tak, że po wejściu na stronę na przykład Indeks:Poezye T. 2 (Maria Konopnicka) wciskam klawisz (lub zakładkę), co powoduje oznaczenie na przykład migotaniem strony, które powinienem sprawdzać, niewarte sprawdzenia, bo już im status zmieniałem kiedyś, można przekreślić. Oczywiście stron nieistniejących nie ma sensu przekreślać, a przekreślić trzeba wszystkie zielone. Wracam do niektórych tekstów po roku i niestety nie wiem co mam jeszcze w nich do zrobienia. Optymalnie byłoby gdyby przekreślenia były generowane w czasie tworzenia strony, ale to raczej nie przejdzie przez cache. Nie każdy potrzebuje takiego bajeru, więc powinno to chyba być włączane jako gadżet. sp5uhe ^{dyskusja edycje} 21:32, 13 lis 2011 (CET)

   Może pomoże ci szybki podgląd historii (gdy przeglądając stronę najedziesz na zakładkę "historia" powinna pokazać się historia edycji tej strony). Może nie tak wygodne, jak to co proponujesz, ale ja z tego korzystam. Ankry (dyskusja) 23:25, 13 lis 2011 (CET)

   Rozwiązanie które proponuje sp5uhe jest niezwykle wygodne, szczególnie dla osób które wracają do danego indeksu po długiej przerwie. Owszem, można badać tak, jak proponuje Ankry - ale to jest pracochłonne (trzeba wczytać każdą stronę indeksu). --Teukros (dyskusja) 11:28, 14 lis 2011 (CET)

   Korzystam z historii oznaczania, ale muszę wtedy każdą stronę wczytać. Bardzo to uciążliwe. sp5uhe ^{dyskusja edycje} 13:16, 14 lis 2011 (CET)

   W tej chwili rozszerzenie Proofread przechowuje informacje o statusie strony w jej treści. Proste sprawdzenie czy status strony X został zmieniony przez użytkownika Y wymaga pobrania tekstu każdej edycji dokonanej przez Y na stronie Y. Mogę zrobić gadżet, zastanawiam się tylko jak długo będzie takie sprawdzanie trwało. Beau (dyskusja) 22:05, 20 lis 2011 (CET)

   Dodałem nowy gadżet o nazwie Oznaczaj skorygowane przeze mnie strony.. Strony do skorygowania zostają pogrubione, strony skorygowane zostają oznaczone kursywą. Gadżet działa dość powoli, bo dla każdej strony musi wysłać jedno zapytanie do API, więc jeśli indeks ma 200 stron, to API zostanie odpytane 201 razy. Ze względu na sposób działania Proofread, utworzenie pierwszej wersji strony nie jest traktowane jako korekta i gadżet ją oznaczy jako do "skorygowania". Spróbuję to jakoś obejść. Mam nadziej, że nawet w takiej, dalekiej od ideału wersji gadżet okaże się przydatny. Beau (dyskusja) 20:46, 24 lis 2011 (CET)

   Poprawiłem odrobinę gadżet tak, aby Popups mu nie przeszkadzał. Ograniczyłem także sprawdzanie tylko do stron ze statusem 'nieskorygowana' lub 'skorygowana'. Beau (dyskusja) 20:22, 3 maj 2012 (CEST)

2. Społeczność polskich Wikiźródeł ustaliła kiedyś, że jedna osoba nie powinna wykonywać dwóch czynności w trakcie oznaczania. Jednak oprogramowanie pilnuje wyłącznie ostatniej operacji. Może warto w nagłówku strony trzymać wszystkich trzech, którzy jako pierwsi zmienili status tekstu. Oczywiście trzeba to przemyśleć - czy zmiana statusu na "problemy" ma powodować czyszczenie tej listy; czy zmiana statusu na niższy ma usuwać oznaczających statusy wyższe. Warto również, aby sposób działania rozszerzenia był definiowalny na przykład w MediaWiki:Common.js, jeśli projekty w innych językach mają w tym zakresie inne ustalenia. sp5uhe ^{dyskusja edycje} 13:16, 14 lis 2011 (CET)

   Ja najchętniej usunąłbym tą informację z treści strony i umieścił ją w osobnej tabeli bazy danych. Przy pomocy API łatwo dałoby się wtedy zrealizować funkcję z punktu pierwszego. Nie rozumiem o co chodzi z MediaWiki:Common.js, kod który kontroluje czy daną edycję można wykonać jest napisany w PHP i wykonuje się po stronie serwera, a nie w przeglądarce użytkownika. Beau (dyskusja) 22:05, 20 lis 2011 (CET)

3. Jest trzecia rzecz, która mi doskwiera i to szczególnie na Wikiźródłach, choć nie jest bezpośrednio związana z Proofread to właśnie gdy z niego korzystam brak mi najbardziej tej funkcji. Mam na myśli skróty klawiaturowe. Część z nich jest umieszczona w kodzie html, część siedzi gdzieś chyba w JavaScript. Nigdzie nie znalazłem do nich sensowego spisu. Chciałbym też móc wygodnie je dodawać w odniesieniu do wstawiania znaków. Na przykład bardzo często na Wikiźródłach wstawiam e z kreseczką, dywiz, cudzysłowy polskie i francuskie. Skoro mamy rozbudowaną belkę edycyjną, to nie wiem czemu brak zakładki ze skrótami w Zaawansowanych. Bot mógłby analizować treść stron serwowanych użytkownikom i dopisywać na jakiejś stronie aktualnie wykorzystywane przez oprogramowanie skróty. Użytkownicy uzupełnialiby ich opisy, a całość widoczna byłaby jako zakładka w belce edycyjnej. Mogłoby tam również znaleźć się tabelka do edytowania skrótów. Zapisywałaby specjalną stronę w przestrzeni użytkownika wczytywaną przez skrypt dodający skróty. sp5uhe ^{dyskusja edycje} 18:50, 14 lis 2011 (CET)

   Mamy w tej chwili proste narzędzie opisane na stronie Wikiźródła:Narzędzia/Skróty klawiszowe, do wstawiania znaków i prostych tekstów się nadaje. Konfiguracja nie jest prosta, ale da się dodawać nowe kombinacje klawiszowe. Beau (dyskusja) 22:05, 20 lis 2011 (CET)

4. Używając Proofread dokucza mi fakt, że chcąc zobaczyć podgląd strony, trzeba przeładować cały dokument, włącznie ze skanem. Generuje to niepotrzebny ruch, skoro można by użyć javascriptu do osadzenia tekstu w stronę. Myślę, że nietrudno byłoby coś takiego wprowadzić. Dodatkowo, tu już trudniejszy przypadek, podgląd zmian można by zrealizować również bez potrzeby przeładowywania przy pomocy AJAXu. Fenuks (dyskusja) 17:57, 12 cze 2012 (CEST)

   Ustaw sobie w opcjach (Specjalna:Preferencje, zakładka "Edycja") Używaj dynamicznego podglądu (JavaScript; eksperymentalny). Beau (dyskusja) 17:58, 12 cze 2012 (CEST)

   Dzięki! O to mi chodziło. Czy istnieje jakiś sposób na podgląd zmian bez przeładowywania? Nie jest to tak istotne jak sam podgląd, ale wciąż mile widziane. Fenuks (dyskusja) 18:15, 12 cze 2012 (CEST)

   W tej chwili ta funkcja ma status eksperymentalny i jest wyłączona. Co więcej nawet jeśli byłaby wyłączona, to niestety i tak nie działa z rozszerzeniem Proofread Page. Beau (dyskusja) 09:00, 13 cze 2012 (CEST)

Czytelnia rok później...

Niezałatwione

Po dłuuuższej przerwie chciałbym zrobić porządek z bałaganem jakiego narobiłem rok temu. Na początek: {{Dane tekstu}} i nowe wywołanie, które wtedy zaproponowałem, które jest opisane w instrukcji szablonu i którego nikt, oprócz mnie, nigdy nie stosował /choć nadal uważam że to był niegłupi pomysł ;)/ . Sądzę, że należałoby to uporządkować - skoro rozwiązanie nie przyjęło się w praktyce, to nie ma sensu zachowywać dokumentacji wprowadzającej w błąd i należy przywrócić poprzednią wersję szablonu oraz jego dokumentacji. Jeśli nie będzie żadnych sprzeciwów, to za tydzień zabiorę się za to, łącznie z zamianą wywołań szablonu z „nową” na „starą” modłę w tych kilkunastu tekstach w których zastosowałem przerobioną wersję szablonu (link do dyskusji rok temu: Wikiźródła:Skryptorium/Pulpit propozycji#Zmiana szablonu Dane tekstu). Pozdrawiam — EMeczKa dyskusja 23:38, 21 lis 2011 (CET)

Przystosowanie wydruku do czytników e-book - inne formaty

Dyskusja przeniesiona ze strony dyskusji Strony głównej:

Witam, mam propozycję, aby można było pobrać tekst, lub wydrukować w innym formacie np. mobi, ePub, txt, rtf.

czytanie w takiej formie na czytnikach i telefonach jest utrudnione. Inną mozliwościa powinno byc pobranie całego tekstu, a nie rozdziału

Odpowiedź: ostatnio pracujemy już nad udostępnianiem pełnych wydań tekstów na osobnej stronie. Można ją znaleźć w infoboksie po linkiem całość. Co do eksportu do ePUB-a jest on również możliwy poprzez [11]. Niedługo być może zaimplementujemy to narzędzie bezpośrednio do menu. Pozdrawiam. — Paelius (dyskusja) 15:30, 25 sty 2012 (CET) EDIT: Tylko tak naprawdę nie wiem po co panu/pani ePUB, skoro to i tak HTML...] — Paelius (dyskusja) 15:32, 25 sty 2012 (CET)

Formaty jak powyżej można pobierać bezpośrednio na czytniki lub telefon. Ich oprogramowanie umożliwia robienie zakładek, zmianę czcionki itp. Nie każdy nosi komputer przy sobie, aby bawić się w konwersję lub sklejanie rozdziałów - chodzi o wygodę.

Nie przewidujemy takiej możliwości - ePUB jest niestety plikiem zamkniętym, nie ma możliwości edycji z poziomu strony, więc jako taki, nie może być plikiem jednorazowo utworzonym. Wikiźródła są stroną, a nie hostingiem plików. — Paelius (dyskusja) 10:06, 26 sty 2012 (CET)

Witam, pozwolę sobie odświeżyć temat. Moim zdaniem podany przez Ciebie wyżej powód nie jest przeszkodą. Jak sam zauważyłeś plik ePub jest jedną lub kilkoma stronami (X)HTML spakowanych w archiwum zip. Wygenerowanie HTMLa nie jest problemem, szczególnie po stronie serwera, gdzie jest możliwość wysyłania zapytań bezpośrednio do bazy. Zewnętrzny skrypt musiałby parsować stronę, co nie jest łatwe ze względu na to, że kod Wikiźródeł nie jest zbytnio opisany klasami i nie ma jednego wspólnego szablonu strony utworu. Mając plik(i) HTML z treścią mamy w zasadzie ePuba, wystarczy tylko dodatkowo utworzyć plik metadanych na podstawie danych utworu i ew. spis treści, jeżeli utwór w jakiś sposób podzielony, spakować to do pliku .epub i wysłać rezultat użytkownikowi. Myślę, że jest to bardzo wykonalne. Sama generacja ePuba powinna trwać dosłownie chwilę. Fenuks (dyskusja) 09:17, 31 maj 2012 (CEST)

Wystarczy txt, html ale cały tekst, a nie rozdziały. Z resztą poradzą sobie ludziska.

Tutaj lub tutaj w infoboksie jest odnośnik do całego tekstu. W wielu innych przypadkach również. — Paelius (dyskusja) 13:32, 26 sty 2012 (CET)

Proofread ma już taką wrodzoną "zaletę", że trudno dostać się do całości czystego tekstu, bo go praktycznie nie ma, to jest zawsze jakoś dziwnie sformatowane, a to co jest nazywane całością składa się po prostu z inkludowanych pojedynczych stron. Zamienić coś takiego na "plain text" to nie jest prosta i szybka praca... Można próbować metodą "kopiuj wklej" ale to wymaga też zachodu i zostają po tym zwykle niechciane pozostałości formatowania (chociażby niepotrzebne wcięcia). Można próbować usunąć je za pomocą funkcji "znajdź i zamień" np. Worda, ale to już jest dłuższa zabawa. Pewnie przydało by się jakieś "automagiczne" narzędzie do konwersji... Ale póki co jest z tym ciężko. Electron  ^<Odpisz> 15:18, 26 sty 2012 (CET)

:Btw. Niektóre teksty nie-proofread mają wersję "do druku", np. Pan Tadeusz, która produkuje ładny czysty html -> [12]. Ale tego jest mało i zgodnie z obecną polityką wikiźródeł będzie jeszcze mniej, bo są one cały czas wycinane i zamieniane na proofread. Tak, że jak chcesz z nich korzystać to trzeba się śpieszyć. Tu masz co jeszcze się zdołało uchować -> Kategoria:Teksty przystosowane do druku. Electron  ^<Odpisz> 15:34, 26 sty 2012 (CET) — wypowiedź nie na temat, w dodatku nieprawdziwa. — Paelius (dyskusja) 16:06, 26 sty 2012 (CET)

Electronie, nie pisz nieprawdy w duchu jedynej właściwej dla Ciebie tezy. — Paelius (dyskusja) 15:42, 26 sty 2012 (CET)

Nie piszę nieprawdy - spróbuj zamienić teksty z proofread na plain text (bez żadnych formatowań), to się przekonasz ile pozostaje po tym śmiecia. A czysty tekst jest to jest czasami to na czym najbardziej zależy czytelnikom. Bo trawi go każdy czytnik... Electron  ^<Odpisz> 16:07, 26 sty 2012 (CET)

Tekst z nieproofread zamienia się dokładnie identycznie. Nie widzę co mają teksty nieproofread, co daje im wyższość przy zamianie ctrl-c + ctrl-v na txt. Z chęcią się tego dowiem. — Paelius (dyskusja) 17:25, 26 sty 2012 (CET)

Piszesz nieprawdę bo nawet nie zajrzałeś ze w podanej przez ciebie kategorii znakomita większość tekstów to teksty sproofreadowane. Może jak nie znasz projektu to nie udzielaj błędnych informacji pytającym? A jak już masz czas jak widzę, i inwencja Cię twórcza ponosi, to może w końcu coś zadziałasz na bugzilli żeby się zajęli tym narzędziem bo gdy było to zgłaszane w skryptorium nie widziałem Ciebie w roli tak ochoczo się udzielającego? Tommy J. (pisz) 22:07, 26 sty 2012 (CET)

Bezpośrednie kopiowanie z proofread niepotrzebne wcięcia robi (zwykle pochodzące od taba). Upierdliwe do usunięcia jak to powieść jest i jest tego kilka tysięcy. Electron  ^<Odpisz> 17:35, 26 sty 2012 (CET)

Nie Electronie, mylisz się. To nie są wcięcia od Taba tylko pięć niełamliwych spacji. I nie rozumiem: przez 200 lat zaznaczało się w ten sposób nowy akapit, a teraz to jest niepotrzebne... Jednym pasuje przerwa, innym wcięcie akapitowe. Ja wolę wcięcie, ty przerwę. Ale znowu, to nie ma nic wspólnego z proofreadem, tylko z typografią jako taką. — Paelius (dyskusja) 17:49, 26 sty 2012 (CET)

Jeśli chcemy aby tekst był jak najbardziej kompatybilny z kompatybilnych to takim jest poczciwy format txt. Jak mamy tekst w czystym formacie txt to bardzo łatwo jest go sformatować w sposób jaki nam odpowiada. Więc nie powinien zawierać żadnych dodatkowych formatowań, które mogą w tym przeszkadzać. I dobrze by było mieć narzędzie, które by na taki podstawowy format przede wszystkim zamieniało. Oczywiście nie wadzą też inne, ale one nie powinny być tymi podstawowymi. Bo potem czytelnicy mogą mieć problemy. A przecież chyba głównie dla nich się to robi. Electron  ^<Odpisz> 18:19, 26 sty 2012 (CET)

Tekst txt z zasady nie zawiera prawie żadnych formatowań (spacja i koniec wiersza to chyba jedyne, ale mogę się mylić). Na pewno niełamliwa spacja nie jest znakiem przeszkadzającym w konwersji/ponownym formatowaniu. To znaczy jest, ale w takim samym stopniu przeszkadza znak końca wiersza, jak i zwykła spacja. — Paelius (dyskusja) 18:51, 26 sty 2012 (CET)

[13] eksport do xhtml-a również jest. — Paelius (dyskusja) 15:36, 26 sty 2012 (CET)

A tutaj http://pl.wikisource.org/wiki/20.000_mil_podmorskiej_%C5%BCeglugi nie ma możliwości przejrzenia całej książki. Próbowałem stworzyć przez waszą stronę książkę, ale wychodzi niepełna i mocno naśmiecona. Można by zrobić podgląd całego tekstu "ciurkiem". Resztę każdy zrobi sobie sam.

20.000 mil podmorskiej żeglugi/całość. — Paelius (dyskusja) 12:16, 27 sty 2012 (CET)

Będziemy wdzięczni za zgłoszenia również innych tekstów, gdzie pełnej wersji ("ciurkiem") nie ma, a byłaby przydatna. Ankry (dyskusja) 17:56, 27 sty 2012 (CET)

Podziękowania za 20.000 mil podmorskiej żeglugi jeszcze to http://pl.wikisource.org/wiki/Podr%C3%B3%C5%BC_do_wn%C4%99trza_Ziemi, http://pl.wikisource.org/wiki/Micha%C5%82_Strogow. http://pl.wikisource.org/wiki/Dzieci_kapitana_Granta, http://pl.wikisource.org/wiki/Na_oko%C5%82o_Ksi%C4%99%C5%BCyca, http://pl.wikisource.org/wiki/Pi%C4%99tnastoletni_kapitan, http://pl.wikisource.org/wiki/Keraban_Uparty - następne później ....

Granta nie będzie:(. Jeszcze nie skończyłem go przepisywać. I w najbliższym czasie nie przewiduję, że się za niego zabiorę. — Paelius (dyskusja) 14:44, 30 sty 2012 (CET)

Jest problem z renderowaniem książki w pobieraniu pliku PDF. Próbowałem pobrać książkę i wyskakuje komunikat, o Błędzie serwera w renderowaniu - jakichś RuntimeError (??) co to jest, bo się z tym wcześniej nie zetknąłęm? Superjurek (dyskusja) 10:32, 23 kwi 2013 (CEST)

ilustracje i cięcie tekstu

Czy dałoby się wyeliminować cięcie tekstu, gdy pojawia się przy nim grafika? Myślę o sytuacji takiej, jak tutaj. Vearthy (dyskusja) 23:59, 17 lut 2012 (CET)

Problem z wyświetlaniem strony

Załatwione

Czy u was również grafika na tej stronie wyświetla się tylko częściowo? Sprawdzałam pod dwiema przeglądarkami (Firefox i Chrome) w ich najnowszych wersjach i za każdym razem problem się ponawia. Sprawdziłam, grafika na Commons znajduje się w całości, więc nie w tym problem. Jak to wygląda u was? Macie jakieś pomysły w czym może tkwić kłopot? Magalia (dyskusja) 15:03, 19 lut 2012 (CET)

Pod Operą tak samo, zaledwie kawałek Tommy J. (pisz) 15:17, 19 lut 2012 (CET)

Miałem ostatnio podobny problem na innej stronie. Wróciło do normy po zapisaniu strony. ∼Wostr (dyskusja) 16:58, 19 lut 2012 (CET)

Chyba nie tym razem, zapisalem jako strone z problemem, potem jako nieskorygowaną, grafika w trakcie edycji nadal się nie wyświetla. Tommy J. (pisz) 17:17, 19 lut 2012 (CET)

Jakby co — u mnie nie ma problemu. — Paelius (dyskusja) 18:19, 19 lut 2012 (CET)

Mi zwykle pomaga (za sugestią Remedios44) zrobienie purge tej konkretnej strony na commons. Ankry (dyskusja) 19:31, 19 lut 2012 (CET)

Teraz już jest normalnie i działa. Być może dlatego, że Tommy bohatersko przepisał i zapisał? Ktokolwiek to spowodował i jakkolwiek to zrobił - moje ogromne dzięki. Podobnie jak za wszystkie rady, które zapamiętam na ewentualne przyszłe problemy tego typu. Dzięki za szybki ratunek :) Magalia (dyskusja) 21:58, 19 lut 2012 (CET)

Nowości po aktualizacji 24 lutego

Załatwione

Ja na razie zauważyłam jedną trochę zabawną, trochę bardziej niepotrzebną imho rzecz – kolorowanie linków do stron (przestrzeń Strona, kolor stopnia korekty) poza przestrzenią Indeks, na przykład tu: Dyskusja_wikiskryby:Remedios44#Strona:Pisma_VI_.28Aleksander_.C5.9Awi.C4.99tochowski.29.djvu.2F004. Remedios44 (dyskusja) 16:18, 24 lut 2012 (CET)

U mnie nie działa css. — Paelius (dyskusja) 16:45, 24 lut 2012 (CET) — zadziałało. — Paelius (dyskusja) 16:53, 24 lut 2012 (CET)

U mnie nie działa commons.js a na podglądzie nie wyświetla się w ogóle skan. Tommy J. (pisz) 16:48, 24 lut 2012 (CET)

Najpoważniejszy problem to chyba bugzilla:34542 - część skryptów i gadżetów się nie ładuje. Beau (dyskusja) 20:26, 24 lut 2012 (CET)

Nie wiem czy coś to pomoże, da się edytować spod Mozilli Firefox 3.6.24, kompletnie nic nie działa pod Operą 11.61, ani nie wyświetla skanów ani nie działają skrypty, edytować się nie da. Tommy J. (pisz) 15:20, 26 lut 2012 (CET)

"Kompletnie nic nie działa" to trochę mało precyzyjne określenie. U mnie pod Operą 11.61 faktycznie na podglądzie skany się nie wyświetlają, ale poza tym – przy czytaniu lub edycji wyświetlają się normalnie, edytować się da, nie rozumiem paniki. Remedios44 (dyskusja) 16:00, 26 lut 2012 (CET)

Które skrypty? Skany nie wyświetlają się nigdy i nigdzie? 16:08, 26 lut 2012 (CET)

Zrobić zrzut ekranu? Bardzo chętnie zrobię zrzut ekranu przy pierwszym wyświetleniu strony jak i po wciśnięciu przycisku "podgląd" zarówno spod opery ja i FF. Tak, czyściłem historię i cookies przeglądarki, używałem polecenia purge i tym podobnych tricków. Skany nie wyświetlają się w ogóle. Nie działają ani gadżety ani commons.js. Jeszcze coś uściślić? Tommy J. (pisz) 16:16, 26 lut 2012 (CET)

Nie o to mi chodzi, że ci nie wierzę, ani że chcę żebyś się złościł, tylko o to że przy zgłaszaniu problemu należy to robić trochę ściślej (teraz już było lepiej, ale poprzedniego twojego wpisu zupełnie nie rozumiałam). "Nic nie działa, nie da się edytować" to żadna wskazówka, zwłaszcza że widać na OZ, że chyba coś działa i chyba coś się da edytować. Remedios44 (dyskusja) 16:21, 26 lut 2012 (CET)

Bo edytuję spod FF a nie lubie tej przeglądarki, bo mi muli, i z samego tego powodu jestem wściekły. I wiem że Beau pewnikiem szaleje żeby działało i jestem wściekły na imbecyli programistów którzy wrzucają usprawnienia nie testując ich chyba, tylko po raz kolejny mam wrażenie, że jest to wrzucone na "czuja". Na Operze mam po prostu czysty ekran z czarnym miejscem zamiast skany i jedynie najprostszym zestawem przycisków "usprawniających". Zero przycisków gadżetów ani możliwości skorzystania z commons.js. Pod FF natomiast pełna funkcjonalność, oprócz dyskomfortu. Sorry, Remedios, ale nosi mnie już od momentu wprowadzenia tych "usprawnień". Tommy J. (pisz) 16:28, 26 lut 2012 (CET)

Zamiast się wściekać mogłeś postąpić według instrukcji, którą podałem na WS:TO, a która dokładnie wyjaśnia jak należy zgłaszać błędy. Nie napisałem jej bez powodu. Ciężko jest rozwiązywać problem, jak sam zainteresowany nie chce pomagać. Zgłoszenie bugzilla:34732. Beau (dyskusja) 16:34, 26 lut 2012 (CET)

Wiem Beau, tylko ja na postepowaniu wg powyższej instrukcji straciłem juz w sobotę kilka godzin, przy któryms z kolejnych punktów i kolejnych przeładowywań przeglądarki, testach z przyciskami gadżetów i kasowaniem i przywracaniem commons, szczerze? Zdążyłem się zmęczyć znudzić zniechęcić i kompletnie rozkojarzyć. I po tej całej procedurze to miałem ochote jedynie napisać "proszę mnie łaskawie poinformować kiedy zacznie wszysktko działać bo to nie ja schrzaniłem", a nie napisałem tak jedynie dlatego że na OZ widziałem w nocy jak szalejesz pracując nad usprawnieniem. A edycja wygląda dokładnie tak jak w Twoim zrzucie, tylko wygląd przeglądarki masz ładniejszy od mojego. Tommy J. (pisz) 16:45, 26 lut 2012 (CET)

Poprawiłem wstawianie guzików do paska narzędziowego. Poprawka dotyczy głównie użytkowników Opery. Proszę o potwierdzenie, czy brakujące przyciski z gadżetów są już dostępne (oczywiście po wyczyszczeniu pamięci podręcznej). Beau (dyskusja) 17:45, 1 mar 2012 (CET)

Ja już nic nie wiem, rano jeszcze czasem losowo pokazywały mi się pod Operą skany, ale nie miałem własnych guzików na pasku ani pod Operą ani pod Google Chrome. Teraz pod Operą nie mam juz ani skanów ani nadal guzików. Nie wiem, może u mnie coś nie gra w common.js. Pod FF mam i skany i przyciski, pod GChrome tylko skany bez przycisków. Tommy J. (pisz) 02:10, 2 mar 2012 (CET)

Przerobiłem dwa twoje guziki, żeby korzystały z mojej biblioteki do obsługi paska narzędziowego. Dalej chyba sobie analogicznie przerobisz resztę. Beau (dyskusja) 23:05, 2 mar 2012 (CET)

Przyciski już działają pod każdą przeglądarką, dziękuje bardzo. Ze skanami pod Operą dziwnie się to zachowuje, przy pierwszej edycji skan się ładuje, po wciśnięciu podglądu zmian już nie, ale jeśli otworzę w nowym oknie grafikę skanu to po ponownym podglądzie znów pokazuje w oknie edycji skan. Następne wciśniecie podglądu nadal nie daje efektu chyba że ponownie zajrzę na niezamknięte okno samej grafiki. Czasem tez losowo przy jednym z kolejnych podglądów naraz pokaże skan. Czy wina nie leży po mojej stronie? Bo szczerze sam juz nie wiem. Tommy J. (pisz) 01:15, 3 mar 2012 (CET)

Odnośnie wyświetlania skanów pisałem już wcześniej. Otworzyłem zgłoszenie bugzilla:34732 na ten problem. Beau (dyskusja) 09:15, 3 mar 2012 (CET)

Remedios44, to kolorowanie można wyłączyć po odpowiednim spreparowaniu stylów. Co inne osoby na ten temat sądzą? Beau (dyskusja) 18:24, 8 mar 2012 (CET)

Mi to kolorowanie jest obojętne: ani razi, ani pomaga. Ankry (dyskusja) 18:50, 8 mar 2012 (CET)

Zgłosiłem 35634. Beau (dyskusja) 09:58, 1 kwi 2012 (CEST)

Nie działają do końca poprawnie skróty klawiszowe, to znaczy funkcjonują wpisane domyślne, ale chyba nie działa instrukcja "removeAll" ani przypisywanie własnych skrótów, bo mimo wstawienia nadal skrót wprowadza tylko domyślny znak. Tommy J. (pisz) 01:56, 16 mar 2012 (CET)

Mi również. Vearthy (dyskusja) 11:14, 16 mar 2012 (CET)

Zaktualizowałem instrukcję Wikiźródła:Narzędzia/Skróty klawiszowe. Beau (dyskusja) 20:58, 16 mar 2012 (CET)

Dziękuję Tommy J. (pisz) 22:29, 16 mar 2012 (CET)

Nie włączają się linki do niektórych stron

Załatwione

W przypadku stron w przestrzeni głównej zawierających sproofreadowaną wielostronicową tabelkę (np. Encyklopedja Kościelna (tom II)) po kliknięciu na zakładkę nie pokazują się numery stron zawierające dalsze strony tabelki, poza pierwszą.

Przed upgrejdem, linki do nich pokazywały się wszystkie nad tabelką; teraz pokazuje się tylko link do pierwszej strony tabelki - pozostałych nie ma w ogóle. Ankry (dyskusja) 21:07, 2 mar 2012 (CET)

Wygląda na to, że sposób parsowania tabelek przez parser MediaWiki uległ zmianie, dlatego ten tekst się już nie pojawia. Jedyne co udało mi się wymyślić to takie zmiany: 1 oraz 2, które dodają dodatkowy, pusty wiersz w tabeli. Numer się wtedy pokazuje nawet w odpowiednim miejscu. Wadą tego rozwiązania jest minimalny, ale zauważalny odstęp pomiędzy wierszami tabeli, kiedy numery są ukryte... Beau (dyskusja) 18:23, 8 mar 2012 (CET)

gadżet przełączenia domyślnego widoku proofread na poziomy.

Załatwione

Przestał działać gadżet przełączenia domyślnego widoku proofread w czasie edycji na poziomy. Nie wiem czy to chwilowe czy na stałe. Tommy J. (pisz) 09:14, 27 cze 2012 (CEST)

W firefoksie i IE9 wszystko działa. Ankry (dyskusja) 16:22, 27 cze 2012 (CEST)

W Operze 11.64 i Google Chrome niestety nie. Tommy J. (pisz) 20:44, 27 cze 2012 (CEST)

Jeśli się wyłączy rozszerzony pasek narzędzi edycyjnych, wtedy pojawia się przycisk umozliwiający przełączenie widoku strony, ale automatycznie gadżet nie działa, i znika pasek narzędzi użytkownika. Tommy J. (pisz) 04:06, 28 cze 2012 (CEST)

Gadżet został skasowany. W preferencjach, w zakładce jest dostępna nowa opcja. Beau (dyskusja) 12:21, 6 paź 2012 (CEST)

Polskie Wikiźródła a Cunningham & Cunningham, Inc.

Przez przypadek w linku mającym kierować do polskiej Wiki użyłem "wiki:" zamiast "w:". Konkretnie: Dwukropek w informatyce zamiast: Dwukropek w informatyce. Proszę zerknąć, jaki adres generuje pierwszy link (z "wiki:"). c2.com? Co wspólnego mają polskie Wikiźródła z "a small consultancy that has specialized in object-oriented programming" (Cunningham & Cunningham, Inc.)? Czy to nie jakiś błąd / spam / przekręt?

Dziwna sprawa. Przetestowałam, że na Wikipedii działa to tak samo, zarówno polskiej, jak i angielskiej. Przydałoby się rzucić ten temat w kawiarence Wikipedii, tam zagląda znacznie więcej osób, które mogą się orientować, skąd się to wzięło. Remedios44 (dyskusja) 12:38, 24 lip 2012 (CEST)

OK, to postaram się wrzucić. Thx! Trejder (dyskusja) 13:16, 24 lip 2012 (CEST)

Sama miałam to zrobić, ale zajęłam się najpierw grzebaniem w nadziei, że sama coś znajdę. Przypuszczam, że jest to jakiś prehistoryczny zabytek z początków działania Wikipedii (pierwsze wiki jest to właśnie c2.com (w:WikiWikiWeb)). W każdym razie nie pojawiło się to teraz, na angielskiej Wikipedii w 2009 roku ktoś to zauważył i spytał o to, ale nikt mu nie odpowiedział. Remedios44 (dyskusja) 13:37, 24 lip 2012 (CEST)

Znalazłam: meta:Interwiki map. Tylko faktycznie ten przedrostek wiki: jest mylący i może powodować błędne linkowanie w przypadkach, gdy się chce linkować po prostu do Wikipedii... Remedios44 (dyskusja) 13:51, 24 lip 2012 (CEST)

Jeśli ktoś chce zająć stanowisko, to akurat obecnie toczy się dyskusja nad usunięciem tego niefortunnego linku. sp5uhe ^{dyskusja edycje} 03:28, 29 gru 2012 (CET)

Nazewnictwo kategorii językowych dla użytkowników

Załatwione

Sytuacja jest następująca: użytkownicy którzy używają szablonu {{Babel}} dla określenia swoich umiejętności językowych są automatycznie umieszczani przez ten szablon w odpowiednich kategoriach. Jak dotąd, podobnie jak w polskiej wikipedii kategorie te nazywały się Kategoria:User de, Kategoria:User pl itp. Jednakże w przypadku użycia nowszego rozwiązania, {{#babel}}, użytkownicy nie są automatycznie umiwszczani w odpowiednich kategoriach. Aby były, wymagane jest ustawienie prefiksu kategorii w konfiguracji Mediawiki. Administratorzy techniczni oczekują od nas (zob. bugzilla:39225) decyzji społeczności, jaki powinien to być prefiks, sugerując, że angielskie "User" nie jest właściwe dla polskich wikiżródeł. Stąd niniejszy wniosek o przegłosowanie, jakie powinny być nazwy tych kategorii.

Za prefiksem "User"

1.  Za Remedios44 (dyskusja) 21:29, 3 sty 2013 (CET)
2. Ankry (dyskusja) 21:35, 3 sty 2013 (CET)
3.  Za Beau (dyskusja) 21:16, 16 mar 2013 (CET)

Dyskusja

Na polskiej wikipedii jest to "User"; por. w:User:Psubhashish i User:Psubhashish.

Zmiana konfiguracji została wprowadzona. Matma Rex (dyskusja) 10:10, 19 mar 2013 (CET)

Zmiana konfiguracji – włączenie poprawnego sortowania artykułów na stronach kategorii

Obecnie na stronach kategorii polskie znaki sortują się na samym końcu (np. Kategoria:Polscy aktorzy filmowi).

Od wczoraj jest mozliwe włączenie poprawnego sortowania dla 67 języków, w tym polskiego – jest to kwestia jednej zmiany w konfiguracji. Niniejszym oficjalnie proponuję ustawienie zmiennej $wgCategoryCollation na uca-pl, co rozwiąże ten problem.

Oprócz poprawy sortowania polskich znaków sprawi to, że nie-polskie litery z akcentami lub innymi znakami diakrytycznymi będą sortowane „równo” z podstawowymi (i pod jednym nagłówkiem) – na przykład „Ä” i „Á” będą sortowane razem z „A”.

Przetestować nowe zachowanie można na testowej wiki (edycja możliwa bez logowania się; zignorujcie spamboty).

Proszę o wyrażanie opinii z szablonami {{za}} / {{przeciw}}, aby technicy WMF widzieli zgodę społeczności na tę zmianę (lub ewentualny jej brak) bez znajomości języka. --Teukros (dyskusja) 21:02, 27 lut 2013 (CET)

•  Za. Zdecydowanie. Ankry (dyskusja) 22:38, 27 lut 2013 (CET)
•  Za Paelius (dyskusja) 22:43, 27 lut 2013 (CET)
•  Za --Teukros (dyskusja) 11:04, 28 lut 2013 (CET)
•  Za Beau (dyskusja) 21:21, 16 mar 2013 (CET)
•  Za Zdzislaw (dyskusja) 20:23, 14 sty 2015 (CET)
•  Za Wieralee (dyskusja) 22:05, 14 sty 2015 (CET)
•  Za Nawider (dyskusja) 22:12, 14 sty 2015 (CET)

Zgodnie z wolą społeczności złożyłem wniosek na phabricatorze: https://phabricator.wikimedia.org/T86821 Zdzislaw (dyskusja) 22:10, 14 sty 2015 (CET)

Zrobione! Miło mi poinformować, iż po prawie dwóch latach od pierwszej wypowiedzi dziś od wczoraj od godz. "22:57 Reedy: updateCollation.php for plwikisource complete" elementy w kategoriach na pl źródłach sortowane są zgodnie z polskim alfabetem :) np. w Kategoria:Abecadlnik w wierszykach Ł występuje po L :)))) Zdzislaw (dyskusja) 22:12, 24 sty 2015 (CET)

Nieciągłe sekcje

Zauważyłem, że od pewnego czasu ProofreadPage nie wymaga, by sekcja na stronie była ciągła. Można by to wykorzystać do zmiany struktury tekstu przy inkludowaniu go go przestrzeni głównej, np. do tworzenia jednokolumnowych spisów treści, gdy na stronie jest dwukolumnowy. Przykład:

Strona:PL Stęczyński-Tatry w dwudziestu czterech obrazach.djvu/258 i Tatry w dwudziestu czterech obrazach/Spis przedmiotów w 24ch pieśniach

Muszę sie tylko upewnić, czy takie zachowanie ProofreadPage jest zamierzone i nie zniknie w którejś z przyszłych wersji (a jeżeli nie jest, warto by powalczyć, żeby było). Ankry (dyskusja) 08:35, 5 mar 2013 (CET)

A takie zachowanie nie jest już od ponad dwóch lat? Strona:PL Dzieła Krasickiego 024.png i Wilk pokutujący. Tommy J. (pisz) 08:45, 5 mar 2013 (CET)

A, jeśli tak, to tym lepiej. Większa szansa, że działać nagle nie przestanie. Niemniej wiedza o nim nie była zbyt powszechna. Wczoraj temat był poruszony na IRC-u, stąd moja uwaga. Ankry (dyskusja) 09:30, 5 mar 2013 (CET)

Kategoria:Szablony z kropkami

Na prośbę Paeliusa przygotowałem szablon {{Wiersz...}} i pokrewne do wstawiania "wykropkowanych" spisów treści i danych do tabel. Wykaz szablonów i dokumentacja na stronie Kategoria:Szablony z kropkami.  « Saper // @wikiźródła »  12:28, 5 mar 2013 (CET)

Nowe strony

Załatwione

Witam, mam pytanie: jak to się robi, aby gdy otwieram na stronie indexu nieistniejącą jeszcze stronę książki, był tam już jakiś tekst? Za każdym razem jak chcę wpisać tekst z OCR'a, i zapisać to z automatu zaznacza jako nieskorygowane, a ja chcę żeby strony jeszcze "nie było", ale jak otworzę to by pojawił się już surowy tekst to obrobienia.
wiem że się tak da, chociażby tutaj

z góry dzięki Superjurek (dyskusja) 04:38, 6 mar 2013 (CET)

Trzeba użyć dokumentu (DjVu lub PDF), który ma zapisany w sobie OCR (przez tego, kto dany dokument utworzył). Ankry (dyskusja) 06:55, 6 mar 2013 (CET)

Zagadka

Co zmieniłam w tej edycji? Remedios44 (dyskusja) 10:33, 9 mar 2013 (CET)

Usuwałaś normalnie niewidoczne łączniki służące do przenoszenia wyrazów. Zalecałbym ich nie usuwanie, a może nawet dodawał, gdyby nie przeszkadzały wyszukiwarce... Ankry (dyskusja) 11:15, 9 mar 2013 (CET)

Dodawał? Gdzie? We wszystkich wyrazach pomiędzy wszystkimi sylabami? Łączniki te pojawiają się tylko w tekstach zamieszczonych przy pomocy OCRu, w miejscach, gdzie na skanie jest wyraz przeniesiony. Wszystkie inne wyrazy, i te same wyrazy, ale w innych miejscach pomiędzy sylabami nie mają łączników. Efekt jest taki, że w wyjustowanym tekście ogromna większość wyrazów jest w całości wyjustowana do brzegów, a gdzieniegdzie trafiają się, ni stąd ni zowąd, przeniesione rodzynki (sparaliżo-wał). Więc albo usuwać te nieliczne, które się pojawiają, albo dodawać je wszędzie. Remedios44 (dyskusja) 12:09, 9 mar 2013 (CET)

Wszędzie dodawać ich nie ma większego sensu. Jednak czasami trafiają się, zwłaszcza dłuższe wyrazy, które po przeniesieniu dałyby ładniejsze wyjustowanie tekstu. Nie zastanawiałem się na razie, gdzie i wg jakich reguł można je dodawać, a najlepiej by było, gdyby łamanie wyrazów odbywało się automatycznie bez dodawania czegokolwiek.

Jednak jest to raczej temat na bardziej odległą przyszłość. Na dzień dzisiejszy, nie radzi sobie z tak "łamalnymi" wyrazami wyszukiwarka, więc póki to nie zostanie rozwiązane, zagadnienie jest nieaktualne. Ankry (dyskusja) 12:47, 9 mar 2013 (CET)

A usuwać je można stosunkowo łatwo botem. Już to w niektórych "swoich" tekstach robiłem. Ankry (dyskusja) 12:48, 9 mar 2013 (CET)

Serwery mediawiki

Witam, może głupio pytam, ale wyjaśnijcie mi (no bo nie wiem). Zawsze zastanawiałem się jak Fundacja Wikimedia załatwia problem wolnego miejsca? Kiedy wchodzę na Commons, zaglądam do Recent changes i klikam klawisz <F5>, <F5>, <F5>, <F5>... oglądam i wychodzi prędkość 1 plik/sekundę, jak to widzę to dostaję zawrotów głowy. Nawet nie wiem jak administratorzy radzą sobie z weryfikacją tych wszystkich plików? I skąd jest prąd oraz miejsce na te wszystkie serwery, skoro nawet po „usunięciu” pliku przez administratora plik zostaje dalej w bazie danych. Jak to działa(?), bo nikt ze znajomych nie potrafi mi odpowiedzieć (tylko drapią się po głowie i wzruszają ramionami).

Pozdrawiam Superjurek Dyskusja 21:38, 11 maj 2013 (CEST)

Poczytaj sobie tutaj - to jest o Wikii, ale ona też należy do wielkiego Jimbo ;) W skrócie - wszystko polega na wielkich bazach danych (Mediawiki już sama w sobie jest przecież bazą danych) składających się z tysięcy dysków, które są połączone w macierze np. RAID, a te dalej w klastry. Oczywiście wszystko jest zwykle kilka razy buforowane... Pozdrawiam Electron  ^<Odpisz> 00:14, 12 maj 2013 (CEST)

Problem ze stroną Specjalna:Książka

Jest jeden problem, mianowicie, kiedy próbuję wygenerować PDF-a, to po kilku sekundach wyświetla się:

Błąd serwera w renderowaniu
W serwerze renderującym wystąpił błąd RuntimeError: command failed with returncode 256: ['mw-render', '-w',
'rl', '-c', 'cache/18/18697e1eb77d17b9/collection.zip', '-o', 'cache/18/18697e1eb77d17b9/output.rl', '--status',
'qserve://localhost:14311/18697e1eb77d17b9:render-rl', '--template-blacklist', 'MediaWiki:PDF Template
Blacklist', '--template-exclusion-category', u'Omi\u0144 w druku', '--print-template-prefix', 'Drukuj',
'--print-template-pattern', '$1/Wydruk', '--language', 'pl'] Last Output: 2013-05-24T17:07:33
[...]

Czy tylko u mnie pojawia się ten problem?
Superjurek Dyskusja 19:11, 24 maj 2013 (CEST)

• Superjurku, rzecz jest już zgłoszona programistom... Wychodzi na to, że naprawa tego błędu może jeszcze długo potrwać :( Wieralee (dyskusja) 19:28, 24 maj 2013 (CEST)

  Nie umiem znaleźć na bugzilli wpisu opisującego zgłoszenie programistom. Mogę prosić o bezpośredni link? Ten brak PDF jest bardzo doskwierający. Na Wikibooks bez problemu wygenerowałem PDF. Liteman (dyskusja) 17:39, 26 lip 2013 (CEST)

  • Może nie jest jeszcze zgłoszona? Możesz zgłosić. Jeśli by się zdublowało, to na pewno ktoś tam zauważy i skojarzy zdublowane zgłoszenia. Ankry (dyskusja) 18:54, 26 lip 2013 (CEST)

    Proszę bardzo, można oddawać głosy bądź komentować: bugzilla:52108. Liteman (dyskusja) 10:10, 30 lip 2013 (CEST)

• Zapomniałam dodać, że tak od miesiąca renderują się bez problemu wszystkie książki w formacie epub - i ja, jak na razie korzystam z tego. Wieralee (dyskusja) 16:28, 30 lip 2013 (CEST)

Pod lipą - Problem z szatą graficzną

Witam, czy dałoby radę, żeby na pojedynczych stronach książki robić oprawkę, jaką widać na skanach, ale w trakcie zlepiania stron szablonem <page index> te oprawki były niewidoczne?
Superjurek Dyskusja 15:58, 23 cze 2013 (CEST)

Tak, technicznie jest możliwość, tylko pytanie po co? Ta oprawka to tylko układ książki dokonany przez drukarnię, równie dobrze mogliby ustalić postrzępienie kartki na brzechach w kształcie fal. Czy to istotne? Tommy J. (pisz) 16:01, 23 cze 2013 (CEST)

Ramke możesz zrobić za pomocą tabeli, w której znajdzie się tekst w znacznikach <section>, które umożliwią wstawienie samego tekstu do przestrzeni głównej. Jeśli chcesz wstawić ramke dokłądnie za pomocą grafiki, zrobisz to, ale nie uda Ci się tak rozmieścić tekstu wewnątrz, zeby każda przeglądarka wyświetlała tak samo, tekst wewnątrz grafiki całkiem inaczej się rozmieszcza w Operze, Chrome FF czy IE. Wiec wg mnie szkoda zachodu w oddawaniu układu graficznego wydawcy. Tommy J. (pisz) 16:08, 23 cze 2013 (CEST)

• Do tej pory nie robiliśmy ramek, chyba, że były na stronie głównej czy tytułowej. Tutaj też ramka nie jest specjalnie ozdobna. Myślę, że książka tylko zyska, gdy się z tej ramki zrezygnuje (weź pod uwagę, że niektórzy czytają nasze książki na komórkach, a wszelkie ramki i tabele niweczą automatyczne dopasowanie tekstu do wielkości ekranu). Ale, naturalnie, decyzja należy do Ciebie :-) Wieralee (dyskusja) 17:00, 23 cze 2013 (CEST)

Niezałatwione

Problem z Proofread

Słuchajcie mam problem z proofread, kiedy przeglądam strony indeksu (dowolnej książki), to nie ma ani strzałek naprowadzających na stronę poprzednią i następną, ani strzałki do indeksu, ani pól wyboru "Brak treści", "Problemy"
To nie może być błąd w kodzie źródłowym, bo wcześniej działało na każdym indeksie, a teraz odmawia posłuszeństwa w ogóle.Superjurek Dyskusja 21:15, 24 cze 2013 (CEST)

Dziś wprowadzili na Wikiźródłach nową wersję oprogramowania MediaWiki 1.22wmf8 i stąd zapewne te problemy. Podejrzewam, że przyczyną problemów jest ta zmiana. Remedios44 (dyskusja) 21:19, 24 cze 2013 (CEST)

Załatwione

Raczej nie załatwione, skoro nie działa, przynajmniej kilku osobom. U innych (np. u Ankrego czy u mnie) wszystko działa prawidłowo, może więc mogłoby pomóc odświeżenie cache albo wylogowanie się i zalogowanie ponowne? W najbliższych tygodniach planowane są kolejne aktualizacje oprogramowania, więc może być trochę zamieszania w technikaliach. Remedios44 (dyskusja) 23:36, 24 cze 2013 (CEST)

• Remedios44: u mnie nie działało, a teraz już działa :-) Czy ktoś jeszcze ma problemy z wyświetlaniem się skanów? Wieralee (dyskusja) 23:55, 24 cze 2013 (CEST)

Brak brudnopisu

Czy u Was też nie ma brudnopisu na górnym pasku?
Rzuciłem okiem i trochę się zdziwiłem :)
Wykasowali brudnopisy? Superjurek Dyskusja 21:36, 24 cze 2013 (CEST)

U mnie wszystko jest po staremu, tylko jakby trochę wolniej działało. Nightly 23.0a1 (64-bitowy FF). Pod IE też chodzi. Ankry (dyskusja) 21:40, 24 cze 2013 (CEST)

• Superjurek: wejdź w ustawienia (Preferencje, zakładka "Gadżety", sekcja "Edycja stron", "Pokazuj link do brudnopisu w menu osobistym.") i przywróć sobie link do brudnopisu. Zawsze też możesz wejść bezpośrednio wyszukując Wikiskryba:Superjurek/brudnopis Wieralee (dyskusja) 21:43, 24 cze 2013 (CEST)

Załatwione

Wikidata

Wygląda na to, że wsparcie Wikidata dla Wikisource się rozwija: [14]. Może warto się włączyć w ten projekt? 188.124.168.187 (dyskusja) 02:26, 25 lip 2013 (CEST)

Uciążliwe poprawianie "błędów" w Proofread

Mam problem, taki że gdy przepisuję strony w proofread na piechotę, włącza się uciążliwe oprogramowanie, które "poprawia" mi é na e, przez to muszę się wracać do tego słowa i jeszcze raz poprawiać. Sugeruję, żeby ten gadżet dla niektórych przydatny, a dla niektórych nie zamieścić w preferencjach. Jeżeli ktoś potrzebuje tego udogodnienia, to będzie mógł sobie go włączyć.  Superjurek   (PISZ ŚMIAŁO) 18:03, 27 sie 2013 (CEST)

• U mnie nic takiego się nie dzieje. Nie wiem, czy to zależy jednak od ustawień w preferencjach, czy od wersji przeglądarki... W każdym bądź razie, kiedy coś takiego dzieje się w innym programie tekstowym, po prostu włączam kombinację Ctrl+Z - wtedy ta ostatnia, automatyczna zmiana jest cofnięta, a program nie proponuje mi już więcej tego rodzaju "poprawki". Wieralee (dyskusja) 18:27, 27 sie 2013 (CEST)

class="tytul"

Hi! Ostatnio obserwuję, że coś się chyba zmieniło z interpretacją tej klasy przez nowsze wersje Mediawiki - teraz ramka się kurczy i dostosowuje do szerokości napisów, co wygląda nie najlepiej, np. tak jak tutaj -> Podróż do środka Ziemi, w starszej wersji Mediawiki jest wszystko ok (tzn. ramka wypełnia całą przestrzeń strony), np. tak jak tutaj -> 500 miljonów Begumy. Zapis dotyczący klasy tytul umieszczony jest w MediaWiki:Common.css. Moje przeglądarki to FF 24.0 i IE 8.0. Wie może ktoś, co tam trzeba zmienić aby działało jak przedtem? Pozdrawiam Electron  ^<Odpisz> 17:41, 23 paź 2013 (CEST)

• Odkąd ja tu jestem, to ramka się kurczy... Jesli wygląda to nie najlepiej, to w jednym z wierszy dokładam sobie tabulatory na początku i na końcu wiersza, np.
  {{Tytuł|nazwa={{tab|35}}Podróż do środka Ziemi{{tab|35}}<br> :<small>(Voyage au centre de la Terre)</small>|autor=Juliusz Verne|inne=''Przekład: [[Autor:Anonim|Anonim]]''}}
  

i wtedy mam ramkę szeroką na tyle, na ile chcę. Trzeba jednak pamiętać, że zbyt szeroka ramka na wyświetlaczu smartfona to kłopot - zawartość ramek nie dostosowuje się do wielkości wyświetlacza nawet w formacie epub - trzeba przesuwać kursorem w prawo, żeby dostać się do tekstu, więc chyba dlatego to zmienili.

A trzeba przyznać, że nasze książki pobrane w formacie epub wyświetlają się na smartfonach bardzo, bardzo ładnie :-) Gorzej z pdf, bo te właśnie są sztywne. Epuby reagują inteligentnie - gdy zwiekszymy powiększenie, tekst się przeformatuje i w wyświetlanej książce zwiększa się wtedy liczba stron. Pdf-y są sztywne - przy zwiększaniu czcionki strona pozostaje stroną - i trzeba sobie non stop przesuwać tekst w prawo i w lewo. Ale to już off-topic :-) Wieralee (dyskusja) 17:55, 23 paź 2013 (CEST)

Dziękuję za odpowiedź. Ale chyba nie było to działanie intencjonalne, tylko jakoś tak wyszło. Za moich czasów ramka działała tak jak teraz w Wikilivres, też dopasowywała się do szerokości okna ale na jego obrzeżach. Definicja tej klasy nie była zmieniana od co najmniej 2009 i jeszcze chyba ze 2 lata temu działało inaczej. Ale jeśli wam to pasuje... Electron  ^<Odpisz> 10:04, 24 paź 2013 (CEST)

Fragment Nocy listopadowej Wyspiańskiego

Mam pytanie: w scenie V "Nocy listopadowej" Wyspiańskiego jest piosenka po francusku, której tekst jest pozbawiony francuskich znaków diakrytycznych i akcentów. Czy mogę je uzupełnić zgodnie ze współczesnymi zasadami ortograficznymi, nie znając francuskiej ortografii stosowanej przez Wyspiańskiego? Paterm (dyskusja) 23:15, 2 lis 2013 (CET)

• Możesz. Ale tylko jako przypiswiki. Wieralee (dyskusja) 23:17, 2 lis 2013 (CET)

  Przede wszystkim ta Noc listopadowa nie ma źródła, więc nie wiadomo, czy brak kreseczek jest błędem autora, czy (dużo bardziej prawdopodobne) OCRu z Polskiego Bałaganu Internetowego lub podobnej strony. Remedios44 (dyskusja) 23:44, 2 lis 2013 (CET)

Załatwione

Problem z podglądem strony

Mam dziś problem z podglądem skanu przy edycji tej strony. Sprawdzałem w trzech różnych przeglądarkach i w każdej z nich będąc zalogowanym, nie mam podglądu skanu a kiedy się wyloguję, to skan widzę. Czy znane są może przyczyny tego zjawiska? Liteman (dyskusja) 14:55, 5 lis 2013 (CET)

• Mam to samo we wszystkich stronach. Nie działają też "ptaszki" przechodzenia o stronę w przód i w tył. Coś się popsuło wczoraj około północy. Na razie edytuję w dwóch pół-oknach :-) Wieralee (dyskusja) 15:23, 5 lis 2013 (CET)

  Tak jak kilka sekcji wyżej – aktualizacja MediaWiki, ze zmianą w rozszerzeniu Proofread. Stąd pewnie chwilowe zamieszanie, które sądzę, że powinno się niedługo samo wyprostować. Remedios44 (dyskusja) 16:07, 5 lis 2013 (CET)

Po wprowadzeniu nowej wersji oprogramowania przestały poprawnie działać skrypty korzystające z niektórych funkcji opisanych na tej stronie. Na Wikisłowniku żauważyliśmy m.in. błąd w również używanym tutaj MediaWiki:Gadget-lib-toolbar.js, który sprawiał, że nie ładowały się określone przyciski w pasku edycji. Ta zmiana pomogła. Peter Bowman (dyskusja) 20:17, 6 lis 2013 (CET)

• No i zadziałało. Peter Bowman, wieeeeeeelkie dzięki!!!! :-) Wieralee (dyskusja) 20:38, 6 lis 2013 (CET)

Załatwione

Lokalne ładowanie plików

Szykuje się zmiana dotycząca możliwości ładowania plików lokalnie (na pl.wikisource). O szczegółach można przeczytać tu i tu. Kto śledził OZ pewnie o tym wie, a skoro nikt nie podjął wątku zgłaszam temat tutaj dla porządku (na wypadek, gdyby jacyś nieuświadomieni mieli być zdziwieni, że się coś zmieniło). Musimy podjąć decyzję (i to raczej szybko), czy coś z tym robimy. Jeśli nie zgłosimy żadnego wniosku, zastosowany zostanie pkt. 2. Proszę o poparcie wariantów (może być kilka), które wam odpowiadają, poniżej. Ankry (dyskusja) 15:22, 2 lip 2014 (CEST)

Możliwości są takie:

1. Zostaje jak dotąd, każdy może ładować pliki lokalnie, link po lewej stronie kieruje do lokalnego uploadera

• Electron  ^<Odpisz> 11:19, 4 lip 2014 (CEST) Najlepsza opcja. Wielkich problemów z tym raczej do tej pory nie było...

2. Lokalnie mogą ładować pliki tylko administratorzy. Link po lewej kieruje do ładowarki na commons. (Wariant przyjęty na meta jako domyślny)

• Ankry (dyskusja) 15:33, 2 lip 2014 (CEST)
• Wieralee (dyskusja) 18:19, 2 lip 2014 (CEST)

3. Link z lewej kieruje na commons, pliki lokalnie mogą ładować wszyscy poprzez tę stronę specjalną

• Ankry (dyskusja) 15:33, 2 lip 2014 (CEST)
• Wieralee (dyskusja) 18:19, 2 lip 2014 (CEST)
• Tommy J. (pisz) 18:28, 2 lip 2014 (CEST)
• Electron  ^<Odpisz> 11:19, 4 lip 2014 (CEST) Lepszy rydz niż nic.

4. Link z lewej kieruje na commons, pliki lokalnie mogą ładować tylko użytkownicy z określonymi uprawnieniami (trzeba wystąpić o utworzenie nowej grupy uprawnień i podjąć decyzję, na jakich zasadach będą nadawane); tak mają na ruwiki

• Ankry (dyskusja) 15:33, 2 lip 2014 (CEST)

5. Inne pomysły/propozycje?

Podsumowanie

Jak widać większość jest za wersją 3, czyli aby nie zmieniać uprawnień do uploadu, a tylko przestawić link w bocznym panelu na commons.

Zgłosiłem wniosek o zmianę konfiguracji MediaWiki: bugzilla:68191. Ankry (dyskusja) 23:41, 17 lip 2014 (CEST)

...i link w panelu bocznym został już przestawiony. Wskazuje na commons. Ankry (dyskusja) 22:54, 21 lip 2014 (CEST)

Dyskusja

• Osobiście uważam, że "ukrycie" możliwości ładowania plików lokalnych poprzez przekierowanie linku w panelu po lewej na commons jest dobrym pomysłem (nowym użytkownikom czasem myliło się i ładowali pliki lokalnie). Co do pozostawienia możliwości lokalnego ładowania plików, uważam, że powinna taka istnieć na wypadek problemów z commons, lub gdy nie chcemy, żeby plik tam trafił z jakichś powodów. Natomiast kwestia kto powinien mieć prawo ładować takie pliki jest mi obojętna. Ankry (dyskusja) 15:33, 2 lip 2014 (CEST)
• Było już wałkowane; stara dyskusja -> [15] Electron  ^<Odpisz> 15:44, 2 lip 2014 (CEST)

• Wtedy można było sobie podyskutować. A teraz słowo staje się ciałem i potrzebna jest decyzja. Lub pozwalamy decydować innym; nasz wybór. Ankry (dyskusja) 15:59, 2 lip 2014 (CEST)

• Jeśli załadowałam coś kiedyś lokalnie, to tylko przez pomyłkę. Myślę, że przekierowanie od razu do Commons jest ułatwieniem, przynajmniej dla mnie, ale nie namawiam, to nie jest dla mnie zbyt istotna kwestia. Wieralee (dyskusja) 18:19, 2 lip 2014 (CEST)

Załatwione

Przypis "błąd w druku" a przypis ze źródła - problem z numeracją

https://pl.wikisource.org/w/index.php?title=Strona:Historya_Stefana_na_Czarncy_Czarnieckiego.pdf/58&action=submit Na stronie pojawiają się dwa przypisy - jeden przypis dodany przeze mnie o błędzie w druku, drugi występujący w źródle z cyfrą "1". Użycie szablonu bwd powoduje jednak, że ten przypis widniejący w źródle zostaje oznaczony cyfrą "2". --Alcesalces123 (dyskusja) 10:22, 13 lip 2014 (CEST)

Nie odzwierciedlamy oryginalnego podziału na strony, a w związku z tym nie jesteśmy w stanie odzwierciedlić numeru przypisu na danej stronie. Będzie on zresztą inny na stronie jednego rozdziału, a inny na stronie całości książki. Nie wiemy też, ile przypisów ostatecznie będzie w jednym rozdziale. Dlatego w ogóle nie przejmujemy się ich numeracją. W tym przypadku system zadziała automatycznie i dostosuje ich numery do strony w przestrzeni głównej. Wieralee (dyskusja) 11:01, 13 lip 2014 (CEST)

@Alcesalces123: zobacz teraz => Historya Stefana na Czarncy Czarnieckiego. Wieralee (dyskusja) 12:59, 13 lip 2014 (CEST)

Przydatność opracowywanych tekstów na Proofread

Moje wątpliwości dotyczą właśnie przydatności mozolnej pracy wkładanej podczas edycji oraz opracowywania tekstów z użyciem Profread. Co otrzymujemy po utworzeniu pozycji w obszarze wykorzystania pozycji w formie e-booka - możliwości korzystania z opracowanej pozycji jako lektury na czytniku, tablecie... innym mobilnym urządzeniu. Otóż otrzymujemy następujące możliwości na stronie pozycji "Drukuj lub eksportuj":

Utwórz książkę

Mamy tutaj dostępne dwa popularne formaty:

• e-book (PDF)

wrzucam więc pozycję Matematyka_i_rzeczywistość klikam "pobierz" i ...

Proszę czekać, trwa generowanie dokumentu. i otrzymuję:

Book rendering failed; There was an error while attempting to render your book.

• e-book (E_PUB)

wrzucam więc pozycję Matematyka_i_rzeczywistość klikam "pobierz" i ...

Pobieram plik na komputer... otwieram i otrzymuję całkiem ładny e-PUB, lecz... brak w nim przypisów (wszystkich) - zniknęły!

Pobierz jako PDF

ta sama pozycja Matematyka_i_rzeczywistość

Book rendering failed - There was an error while attempting to render your book.

Pobierz jako EPUB

Podobny efekt jak w przypadku książki - brak w nim przypisów (wszystkich) - zniknęły!'

Wersja do druku

tu jest wszystko co trzeba i wzory i przypisy, mogę użyć PDF-creatora do wydruku, lecz nie nadaje się jako źródło do przyjaznego czytania na czytniku, m.in. dlatego, iż "gubią" się aktywna linki do przypisów...

Czy te funkcje są rozwijane i jest szansa, że będą działać poprawnie? Po co komu " społeczny projekt, którego celem jest utworzenie wolnego repozytorium tekstów", jeżeli "przydatność" tych tekstów jest dyskusyjna.

Zdzislaw (dyskusja) 20:52, 17 lip 2014 (CEST)

 Po pierwsze: czy próbowałeś bezpośredniego linku "Pobierz EPUB"? Przy pomocy bezpośredniego linku zazwyczaj, jeżeli nawet nie da się pobrać pozycji z jej strony głównej, to ze strony jej całości się udaje.

 Po drugie: opcja tworzenia książek była aktywna, po zmianach oprogramowania się jednak zepsuła. Zgłosiliśmy ten błąd na bugzilli, czekamy, aż coś zrobią. Nie zapominaj jednak, że ten błąd może być także poprawiony przez każdego z nas, jeżeli ktoś ma odpowiednie zdolności. Wszyscy jesteśmy wolontariuszami — i wszyscy mamy taką samą możliwość inicjatywy. I Ty także możesz się zabrać za naprawę tej opcji :-)

 Po trzecie: IMO myślisz starymi kryteriami... Przyszłością nie jest pobieranie czegokolwiek na tablet, tylko czytanie w trybie online. Nie pamiętam, kiedy ostatnio cokolwiek pobierałam... Większość komórek z większym wyświetlaczem ma dostęp do internetu.

 Po czwarte: skany w Bibliotekach cyfrowych nie są przepisane, to tylko zdjęcia. Aby ich treść pojawiła się w wyszukiwarce, trzeba je przepisać. Wikiźródła są projektem siostrzanym Wikipedii i jako takie mają wysokie pozycjonowanie w wyszukiwarkach.

 Po piąte... każdy z nas sam decyduje, czy warto ;-) Wieralee (dyskusja) 21:10, 17 lip 2014 (CEST)

epub pobrany z bezpośredniego linku, tak jak w przypadku "książki", nie zawiera żadnych przypisów, których w Matematyka_i_rzeczywistość jest wiele.

nie zgadzam się zupełnie ze "starymi kryteriami" - czytanie powieści na komórce lub tablecie w formie ciągłego tekstu to udręka - jedyna akceptowalna "forma" to czytnik z dobrym e-papierem.

... po piąte...

Zdzislaw (dyskusja) 21:46, 17 lip 2014 (CEST)

Po Twoim pierwszym poście sprawdzałam właśnie "Matematykę". U mnie przypisy są, wystarczy dotknąć strzałki — i od razu przenosi mnie do przypisu. Wieralee (dyskusja) 22:01, 17 lip 2014 (CEST)

przepraszam, zbyt podobne nazwy plików e-pub (bezpośredni ma _ a książkowy " ") - epub bezpośredni posiada odnośniki i przypisy w przeciwieństwie do wygenerowanego "książkowo" :)Zdzislaw (dyskusja) 22:17, 17 lip 2014 (CEST)

To wersja testowa, uruchomiona dopiero kilka dni temu. Mam nadzieję, że po testach epuby będą się układały ładniej. Z układem poziomym w sumie nie ma już problemów, ale odstępy pionowe pomiędzy stronami jeszcze nie zawsze układają się dobrze. Wieralee (dyskusja) 22:22, 17 lip 2014 (CEST)

patrolowanie nowych stron

Ostatnio wyszło, że pomimo włączonych wersji przejrzanych, mamy nie do końca wyłączone patrolowanie. Włączone jest patrolowanie nowych stron i dotyczy głównie przestrzeni innych niż "przeglądane": (czyli m.in.: Wikiskryba i wszystkie przestrzenie dyskusji). Nie było by w tym nic złego, gdyby nie pewna dokuczliwość: okazuje się, że uprawnienia do patrolowania mają wyłącznie administratorzy (swoich i nie swoich stron) i boty (tylko edytowanych przez siebie). Szczegóły tutaj. Dlatego proponuję:

• włączenie uprawnień "patrol" i "autopatrol" oraz wyłącznie zbędnego w tej sytuacji zbędnego "patrolmarks" dla grupy redaktorów.

Zakładam, że tworzenie osobnej grupy w tym celu, to przerost formy nad treścią. Uwagi? Komentarze? Ankry (dyskusja) 22:53, 4 wrz 2014 (CEST)

 Za Jestem za rozszerzeniem uprawnień dla wszystkich redaktorów. Niepotrzebne nam dodatkowe grupy mniej czy bardziej uprzywilejowane. Wieralee (dyskusja) 23:04, 4 wrz 2014 (CEST)

 Za Także za rozszerzeniem uprawnień dla wszystkich redaktorów. Irytują mnie te "!" podczas tworzenia stron m.in. w przestrzeni swojego brudnopisu. Zdzislaw (dyskusja) 23:35, 4 wrz 2014 (CEST)

Zgłosiłem wniosek na bugzilli. Ankry (dyskusja) 22:16, 5 wrz 2014 (CEST)

Bug został zamknięty, czyli uprawnienia zostały nadane. Ankry (dyskusja) 07:01, 12 wrz 2014 (CEST)

Załatwione

Szablony licencji - TekstPD, TłumaczPD, MixPD i inne...

Cześć! Co sądzisz o pomyśle, aby zamiast stosować dwa szablony (np. w Z chmur rodzi się grad... {{TekstPD|Solon}} i {{TłumaczPD|Bruno Kiciński}}), stosować dwa zagnieżdżone w jednym, np. {{Licencja-tłumaczenie|oryginał={{TekstPD|Solon}}|tłumaczenie={{TłumaczPD|Bruno Kiciński}}}}? Wydaje się, że wizualnie daje to lepszy efekt. --Teukros (dyskusja) 22:01, 24 wrz 2014 (CEST)

@Teukros: dzięki za pomoc i za to, że chcesz mi pomóc, ale co do szczegółów technicznych... szczerze mówiąc, w ogóle mi się nie podoba, wygląda to fatalnie. Część centrowana, część nie, pogrubiona czcionka przy oryginale i przekładzie bije po oczach i sugeruje coś ważniejszego niż sam tekst; nie mówiąc już o tym, że wprowadza chaos informacyjny (wydaje mi się, że szary zjadacz chleba i tak nie wie, o co chodzi, a ten, który wie, nie potrzebuje tego nagłówka)... Natomiast sama idea jednego szablonu to bardzo dobry pomysł. Mamy "podwójny" szablon {{TekstPD|Solon|Bruno Kiciński}}, ale pasuje on do współautorów, natomiast tutaj przydałby się nowy, "kombinowany", np. {{TekstPD-TłumaczPD|Solon|Bruno Kiciński}}, który miałby w tekście:

Tekst jest własnością publiczną (public domain). Szczegóły licencji na stronie [[autora]] i [[tłumacza]].

Już dawno o tym myślałam... Ale nie umiem zrobić szablonu z dwoma parametrami ;-( Wieralee (dyskusja) 22:25, 24 wrz 2014 (CEST)

P.S. Chodzi mi o łączny szablon w przypadku, gdy obydwie licencje da się wyrazić w {{PD-old}}. Bo w przypadku {{PD-old}} tekstu i {{C-c-3}} tłumaczenia, tego już raczej się nie da pogodzić w łącznym szablonie?... Wieralee (dyskusja) 22:34, 24 wrz 2014 (CEST)

W przypadku {{PD-old}} tekstu i {{C-c-3}} tłumaczenia mamy w efekcie tekst na licencji {{C-c-3}} i ja bym w ogóle o {{PD-old}} nie wspominał, żeby ludziom w głowach nie mącić sugerując inną licencję. Gorzej, jakby była sytuacja odwrotna... Ankry (dyskusja) 22:48, 24 wrz 2014 (CEST)

Niestety, krótkiego szablonu licencji z dwoma licencjami (autora i tłumacza) też nie potrafię stworzyć. A z pewnością byłby lepszy od tego, co ja zaproponowałem. --Teukros (dyskusja) 12:02, 25 wrz 2014 (CEST)

@Wieralee, @Teukros, @Ankry: Przygotowałem szablon {{MixPD}} dla nieograniczonej liczby Autorów i Tłumaczy. Szczegóły w dokumentacji. Zapraszam do stosowania. Pozdrawiam z drogi Zdzislaw (dyskusja) 23:40, 25 wrz 2014 (CEST) :)

@Zdzislaw: dzięki, Szablozębny :-) Wieralee (dyskusja) 23:43, 25 wrz 2014 (CEST)

@Zdzislaw: Dobrze jest. Na razie. Bo prawdopodobnie czeka nas niedługo większa rewolucja: trzeba będzie zająć się licencjami naszych tekstów w USA. Temat poruszył @Teukros: jakiś czas temu. Tych licencji nie da się, niestety, określić na stronach autora (zależą głównie od daty publikacji, zobaczcie tutaj). Ankry (dyskusja) 01:39, 26 wrz 2014 (CEST)

@Ankry: Rewolucja, może być :) szablon jest gotowy, dzięki wywołaniu moduł bez określonej liczby i typu parametrów pobieranych przez getParent z Szablonu... wystarczy aby Twój bot dodał dodatkowy parametr typu lub rok publikacji... albo Lua sobie sama "sczyta" rok z Danych tekstu... albo...; modyfikacja kodu i wygeneruje Ci co tylko sobie zażyczysz :) Poza tym cały kod przerzucę do Lua i zmapuję pozostałe szablony aby w przypadku wymaganych zmian, wystarczyło zmienić tylko w jednym miejscu... Zdzislaw (dyskusja) 11:31, 26 wrz 2014 (CEST)

Bardzo dobry ten nowy szablon. Wypróbowałem go na stronie Z chmur rodzi się grad..., i sądzę że można by go wdrożyć do stosowania. Może przebotować wszystkie te strony, na których wcześniej były dwa szablony {{tekstPD}}? --Teukros (dyskusja) 09:01, 26 wrz 2014 (CEST)

• @Teukros: bardzo dobry pomysł :-) Też tak myślę. Porozmawiam jeszcze z operatorem bota ;) na ile to jest możliwe technicznie (na niektórych stronach te szablony nie są w jednym miejscu, rozdzielają je nieraz kategorie). Wieralee (dyskusja) 13:27, 26 wrz 2014 (CEST)
  • Sugeruję ---> Wikiźródła:Zadania dla botów Ankry (dyskusja) 18:44, 26 wrz 2014 (CEST)

Zmiana domyślnej wartości pola "Opis zmian" w edytorze

Proponuję (w celu poprawienia czytelności OZ) usunąć z domyślnej treści "Opisu zmian" podczas tworzenia/edycji strony (wzorem np. oldwiki), wypełnianej jedynie w przypadku, gdy skryba pozostawi to pole puste, dodawanego automatycznie początku (200znaków) wprowadzonego tekstu strony. Dzisiaj taki "domyślny opis" wygląda tak:
(→Nieskorygowana: Utworzono nową stronę "to wiem". W oczach jego błyska jakaś zatajona złośliwość: wie, że to zła wiadomość, rozumie moje położenie prawie bez wyjścia. Co więcej, już koło połud...")
po zmianach, które chcę wprowadzić wyglądał by następująco:
(→Nieskorygowana: Utworzono nową stronę bez opisu zmian.)

Zdzislaw (dyskusja) 21:37, 16 lis 2014 (CET)

Wystarczy?:

(→Nieskorygowana: Utworzono stronę bez opisu.) :)

@Sp5uhe: nie potrzeba pisać do obsługi, niczego zmieniać w php, ani dodawać JS - wystarczy zmiana komunikatu MW. Zdzislaw (dyskusja) 10:23, 18 lis 2014 (CET)

@Zdzislaw: a którego? sp5uhe ^{dyskusja edycje} 19:38, 18 lis 2014 (CET)

@Sp5uhe: MediaWiki:Autosumm-new - wywał cototo tam jest i zostaw jedynie Bez opisu. - tyle wystarczy, będzie krótko i zwięźle :) Zdzislaw (dyskusja) 19:44, 18 lis 2014 (CET)

@Zdzislaw: pomogło :) Wygląda, że wszyscy są zgodni co do tego żeby usunąć ten koszmarnie długi opis, więc zostawię. sp5uhe ^{dyskusja edycje} 19:49, 18 lis 2014 (CET)

• podpisuję się  Za, nawet obydwiema rękami. Myślę tylko, żeby jeszcze jakoś ten domyślny opis skrócić (na małych ekranach dłuższe opisy rozstrzelają OZ-ty) Wieralee (dyskusja) 21:48, 16 lis 2014 (CET)
• Zdecydowanie  Za. Wszystko jedno co, byle krótko. Ankry (dyskusja) 22:33, 16 lis 2014 (CET)
•  Za Remedios44 (dyskusja) 22:34, 16 lis 2014 (CET)
•  Za Nie jestem pewien, ale chyba będzie to wymagało napisania do obsługi serwerów. Jest co prawda komunikat MediaWiki:Autosumm-new, ale on zawiera tylko pierwszą część treści, która trafia na OZ. Reszta chyba jest dodawana w kodzie PHP. najprościej będzie dodać jakiś JavaScript. Ja sobie dopisałem taki kod. sp5uhe ^{dyskusja edycje} 00:54, 18 lis 2014 (CET)
•  Za --Teukros (dyskusja) 09:25, 18 lis 2014 (CET)
•  Za Starczy "Utworzono nową stronę". Vearthy (dyskusja) 10:14, 18 lis 2014 (CET)

Załatwione Zdzislaw (dyskusja) 19:55, 18 lis 2014 (CET) (@Sp5uhe: ewentualnie można dać '''n'''owa strona - będą się wizualnie wyróżniać "puste" tym n "nowa strona" :)

@Zdzislaw:Całkiem usunąłem i wtedy jest wyłącznie (→Nieskorygowana) w opisie na końcu, a o tym, że to jest nowa strona informuje literka N na początku wiersza. Mi się tak najbardziej podoba, ale jeśli wolicie jakiś opis to mogę dodać. sp5uhe ^{dyskusja edycje} 20:01, 18 lis 2014 (CET)

@Sp5uhe: to, że ona jest nowa mamy N, a jakiś krótki "odznaczający" się komunikat oznaczał by, że utworzoną ją nie wpisując nic w pole opis ani nie wybierając statusu - może być jedna literka  p. Zdzislaw (dyskusja) 20:04, 18 lis 2014 (CET)

@Zdzislaw:Gdyby ktoś dodał opis zmian to by był jakiś opis, a skoro nie ma opisu to znaczy, że go nie wpisał. Jeśli chcesz żeby się takie zmiany bez opisu wyróżniały, to może dodać w opisie znak „—”, bo literka „p” chyba jest mało intuicyjna w tym kontekście. sp5uhe ^{dyskusja edycje} 20:10, 18 lis 2014 (CET)

@Sp5uhe:nie masz racji - jeżeli ktoś wybierze status przy tworzeniu (tak jak do tej pory) będzie sam status, jeżeli utworzy ją nie wpisując nic w pole opis ani nie wybierając statusu byłoby to co wpiszemy w MW - może być "—" Zdzislaw (dyskusja) 20:13, 18 lis 2014 (CET)

@Zdzislaw:Nie klikałem zmiany statusu, a zobacz na OZ jak wyglądają utworzone przeze mnie strony przed zmianą na "—" i po. Znaczek mi nie przeszkadza, ale wydaje mi się, że nic nie wnosi. sp5uhe ^{dyskusja edycje} 20:27, 18 lis 2014 (CET)

@Sp5uhe: wnosi - nie chodzi o zmianę statusu a o jego wybranie przy tworzeniu nowej strony - zobacz twoje utw. na OZ oraz Wieralee, która z przyzwyczajenia "wybiera " status "Nieskorygowana" pomimo, że jest on wybrany domyślnie. Zdzislaw (dyskusja) 20:33, 18 lis 2014 (CET) - poza tym, pamiętaj @Sp5uhe:, iż ten komunikat także jest pobierany przez parsera w innych przestrzeniach (głowna, sandbox, moduł, szablon...) przy tworzeniu nowych stron. Zdzislaw (dyskusja) 20:39, 18 lis 2014 (CET)

@Zdzislaw:Przekonałeś mnie do kreseczki. Miejsca zajmuje niewiele, a przynajmniej widać na OZ co się dzieje. sp5uhe ^{dyskusja edycje} 22:58, 18 lis 2014 (CET)

Strona główna w wersji dla urządzeń mobilnych

Uprzejmie donoszę, że strona główna w wersji dla urządzeń mobilnych (http://pl.m.wikisource.org/w/index.php?title=Wiki%C5%BAr%C3%B3d%C5%82a:Strona_g%C5%82%C3%B3wna&mobileaction=toggle_view_mobile) zawiera tylko pierwszy akapit strony głównej standardowej (a więc "Przyłącz się do nas!" już nie ma). Tak przynajmniej jest u mnie (Firefox 33, Ubuntu). Bardzo utrudnia to dalszą nawigację. Może znajdziecie przyczynę - w kodzie źródłowym zwraca uwagę nieotwarty znacznik "</big>". Rafał 31.61.131.197 (dyskusja) 23:00, 19 lis 2014 (CET)

Rafale - dziękujemy za informacje! Dodałem "przyłącz", "Indeksy" oraz "Nowe teksty" do mobile - myślę, że w wersji mobilnej tyle wystarczy. Zdzislaw (dyskusja) 23:42, 19 lis 2014 (CET)

Szybkie formatowanie po OCR

Do niedawna, nie wiedzieć czemu, nie działało mi automatyczne OCR w Proofread. Po niedługim użytkowaniu tej funkcjonalności rzuciła mi się w oczy jedna rzecz. OCR zwraca tekst ze sztywnym, książkowym formatowaniem i to jest jak najbardziej zrozumiałe. Myślę, że można by dodać kilka przycisków w edytorze (może już stosowne opcje istnieją, ale je przeoczyłem), które korzystając z wyrażeń regularnych usunęłyby niepotrzebne przełamania wiersza, scaliły podzielone wyrazy między wierszami, wstawiły tabulacje na początku akapitu itp. Oczywiście, nie sposób napisać uniwersalnego wyrażenia, które będzie bezbłędne, ale te najprostsze przypadki, które stanowią przeważającą większość, powinny być obsługiwane poprawnie.
W preferencjach można sobie włączyć wyszukiwanie i zamianę, ale korzystanie z tego narzędzia jest za wolne, z racji tego, że za każdym razem trzeba od nowa wpisywać regex. Bardzo proste wyrażenie usuwające niepotrzebne przełamania wiersza może wyglądać tak: ([^\n ]) ?\n([^A-Z]) (pole znajdź), \$1 (pole zamień na). Działa przyzwoicie. Fenuks (dyskusja) 20:31, 19 lut 2013 (CET)

Nie mam nic przeciwko temu. Znajdziesz może kogoś, kto będzie umiał to zaimplementować? Ankry (dyskusja) 20:34, 19 lut 2013 (CET)

Dodam tylko, że u mnie gadżet OCR nadal nie działa (nie robi nic poza zablokowaniem okna edycji). Ankry (dyskusja) 20:42, 19 lut 2013 (CET)

Miałem nadzieję, że któryś z Wikiskrybów byłby skłonny w wolnym czasie się tym zająć. Nie wydaje się to być skomplikowane ani w założeniach, ani w implementacji, więc jeżeli nakierowałbyś mnie na stronę opisującą z dobrą dokumentacją sam nawet się za to zabiorę, gdyż mieści się to w obrębie moich zainteresowań.

Nie wiem czy Ci to cokolwiek pomoże, ale mi ten gadżet zaczął działać, gdy wyłączyłem wszystkie dodatki (nie działa), uruchomiłem ponownie Firefoksa z dodatkami (dalej nie działa), sprawdziłem czy działa w Operze (działa). Włączyłem Windowsa, żeby sprawdzić czy tam działa pod Firefoksem i okazało się, że tak. Restart. Załadowałem Linuksa, uruchomiłem przeglądarkę i zaczęło działać samo z siebie. Nie mam pojęcia dlaczego tak się stało. Fenuks (dyskusja) 20:56, 19 lut 2013 (CET)

Lista zdefiniowanych gadżetów (i nazwy ich plików definicji są tutaj: MediaWiki:Gadgets-definition. Gadżet od OCR będzie pewnie tu: MediaWiki:Gadget-ocr.js. Jak wiesz co i gdzie zmienić, to daj znać mi lub któremuś z pozostałych adminów. W kwestii przedyskutowania szczegółów zapraszam na IRC-a. Ankry (dyskusja) 21:08, 19 lut 2013 (CET)

Załatwione? Czy coś trzeba poprawić? Beau (dyskusja) 21:15, 16 mar 2013 (CET)

No nie wiem... Mi nie działa nadal, a próbowałem w FF21 i IE8.0 (na WinXP; poza wyszarzeniem tekstu w polu edycji i blokadzie edycji). Fakt, że programy to dość wiekowe, ale wszystko inne nadal chodzi, a ten gadżet sprawdzałem tak ze dwa lata temu i też nie chodził. Dziwny jakiś. Gniewko, syn rybaka (dyskusja) 02:56, 19 lis 2014 (CET)

• Odkąd ja tu jestem, ten gadżet nie działa :-( Trochę go zastępuje gadżet sprzątanie kodu, który zamienia pustą linię pomiędzy tekstem na {{tab}} i <br />, ale to wszystko. Mówiło się o rozmowach pomiędzy znaną firmą dostarczającą programy OCR-ujące a WMF, ale nie słyszałam, by cokolwiek z tego wyniknęło... Wieralee (dyskusja) 10:13, 19 lis 2014 (CET)

• podmieniłem kod gadżetu na "działający" :) korzystający z narzędzi PheTools. Działa całkiem dobrze dla tekstów pl, polecam potestować na stronach bez "wbudowanego" OCR-u, np. na Indeks:Kronika miasta Leszna (Karwowski). W kolejnym kroku dodam kilka funkcji "sprzątania kodu". Zdzislaw (dyskusja) 22:44, 12 lut 2015 (CET)

• po włączeniu gadżetu przycisk do OCR wskakuje w zakładkę "Narzędzia proofread". Wieralee (dyskusja) 23:09, 12 lut 2015 (CET)

Nuty, nuty, nuty...

Chciałam wyrazić specjalne podziękowania
dla
Viatoro, Vearthy'ego i Ankry'ego,

dzięki którym nutki zostały wprowadzone na Wikiźródła :)))

 W związku z nowymi możliwościami rozwoju, które dał nam dodatek LilyPond zapraszam wszystkich chętnych do przepisywania nut - i do dzielenia się nowymi doświadczeniami :-)

 Podręcznik obsługi dodatku LilyPond - dodatku do przepisywania nut: [16]. Przyda się też [17].

 Wyłoniły się też pierwsze problemy...
 W melodiach zamieszczonych w książkach Boya wystąpiły błędy metryczne. Do tej pory trzymaliśmy się zasady, iż przepisujemy teksty źródłowe bez poprawiana. Sęk jednak w tym, że dodatek nie chce zaakceptować błędnego zapisu - próbuje automatycznie naprawić błąd. W przepisywanych przeze mnie nutach w oryginale w metrum ²/₄ w jednym takcie wystąpiła półnuta i pauza ósemkowa. gdy próbowałam zapisać to z błędem - LilyPond sam zamykał takt po półnucie i przerzucał pauzę do następnego taktu. Gdy spróbowałam zmienić metrum dla feralnego taktu - wyświetla się zapis nowego metrum ⁵/₈, co sprawia wrażenie, iż zmiana metrum była zamierzona przez kompozytora, na co nic nie wskazuje... Najprawdopodobniej był to albo błąd w druku - albo luźne podejście autora do zapisu nutowego.
 Poprawiłam więc zapis i dodałam przypis o wartości nut, które były zamieszczone w oryginalnym wydruku. Zobacz tutaj
 No i nie umiem jeszcze ładnie dzielić linijek - gdy je podzielę komendą /break - długość linijki pozostaje taka sama, tyle, że odległości pomiędzy nutami się bardzo powiększają, pozostawiam więc zapis nutowy nie podzielony...

 Czy w związku z tym ktoś z Was ma może jakieś pomysły/uwagi/wnioski/propozycje? Wieralee (dyskusja) 21:49, 26 kwi 2013 (CEST)

Rozszerzenie oferuje nam możliwość wydłużenia lub skrócenia wartości nuty bez zmiany zapisu: wystarczy dodać po nucie np. "*7/8" (mnożymy wartość: tutaj zamiast przykładowej półnuty, która nadal jest w zapisie, mielibyśmy metrycznie wypełniającą takt ćwierćnutę z dwiema kropkami — tak też byłby wykonany dźwięk). Stosowałem tę praktykę na początku, ale potem uznałem, że w notacji muzycznej, inaczej niż w tekście zwykłym, warto jednak zastosować prawidłowy zapis dla laika, by mu dodatkowo nie mieszać w głowie (inny zapis, inne wykonanie) i wypisać błędy w przypisach. Nadal mam wątpliwości, ale póki co trzymam się tej zasady. Vearthy (dyskusja) 12:40, 27 kwi 2013 (CEST)

W przypadku brakującej nuty można dodawać "spacje" (s2, s4 s6, s16 itp.), aby wypełnić takt do wartości metrum.

Ponadto w przypadku bardziej złożonych (choć niekoniecznie długich) partytur rozszerzenie zgłasza błąd, prawdopodobnie wynikający z ograniczeń dostępnej dla niego pamięci na serwerze. Lilypond jest dość wymagający pod tym względem. Ankry (dyskusja) 18:35, 2 maj 2013 (CEST)

tylko te "spacje" tworzą dziury, które psują nie tylko wygląd, ale i wprowadzają do pliku midi pauzy (są faktycznie niewidocznymi pauzami). Vearthy (dyskusja) 19:01, 2 maj 2013 (CEST)

Podwojne ru iwiki psuja iwiki

Odechcialo mi sie recznie naprawiac po kilku. Przyklad: Bajdary. Dwa ru interwiki powoduja, ze i tak pojawia sie tylko jeden, a system nie laczy z innymi (en:Sonnets from the Crimea/Baydary, prawidlowo podaje pl i jeden ru, choc tez tam sa dwa iwiki do ru). --Piotrus (dyskusja) 10:24, 30 maj 2013 (CEST)

Jeszcze niedawno wielokrotne interwiki do jednej wiki działały. Służyły możliwości wyboru przez użytkownika tłumaczenia/wydania do porównania za pomocą doublewiki. Od paru wersji Mediawiki nie działają i czekamy na rozwiązanie problemu (wyboru tekstu do porównania). Ankry (dyskusja) 11:52, 30 maj 2013 (CEST)

Niezałatwione

Licznik na stronie głównej

Licznik ten zlicza tzw. "dobre artykuły" w przestrzeniach nazw:

• głównej
• Strona
• Indeks
• Autor.

Dobrymi artykułami są wg przyjętych kryteriów takie, które:

• nie są przekierowaniami do innej strony
• zawierają w treści przynajmniej jeden wikilink do innej strony Wikiźródeł (może być ślepy); nie są tu uwzględniane kategorie ani pliki.

Wygląda na to, że dotychczas takie wikilinki zapewniało nam rozszerzenie ProofreadPage (podejrzewam, że był to link do indeksu). Albowiem do liczby artykułów zliczały się nawet puste strony. Obecnie, po zmianie zasad działania ProofreadPage (w przypadku starych stron: po wykonaniu na nich jakiejś niepustej edycji), zliczają się tylko te strony, które do czegoś linkują (np. niektóre strony tytułowe tomów, czy strony spisu treści). Na niektórych innych wiki (np. na dewikisource), do struktury strony dodawany jest automatycznie szablon linkujący do strony głównej książki: takie strony nadal są i będą tam zliczane.

Wg mnie, jako że przestrzeń Strona jest przestrzenią czysto techniczną, zliczanie poszczególnych stron do liczby artykułów (tekstów) jest sztucznym zawyżaniem ich liczby i jako takie nie ma sensu. Optuję za całkowitym usunięciem przestrzeni Strona spośród przestrzeni nazw, które obejmuje wspomniany licznik (zmiana konfiguracji MediaWiki poprzez zgłoszenie na bugzilli, wymaga konsensusu społeczności).

Jeżeli z kolei większość z Was uważa, że zliczanie stron ma sens, możemy dodać do treści lub nagłówka wszystkich stron szablon (ukryty lub nie), który do czegoś (do czego?) będzie linkował.

Pozostawienie status quo jest najmniej sensownym rozwiązaniem, gdyż spowoduje to, że licznik będzie zliczał jednocześnie:

• w dół w miarę korekty starych stron oraz
• w górę przy tworzeniu spisów treści, stron autorów i artykułów w przestrzeni głównej.

To, czy dana strona będzie zliczana, czy nie, będzie zależało przede wszystkim od czasu jej ostatniej edycji, nie zaś od jej treści. Taki licznik nie ma wg mnie większego sensu.

Proszę o opinie. Ankry (dyskusja) 10:56, 9 gru 2013 (CET)

---

• Myślę, że najlepszy dla nas byłby licznik kompatybilny ze statystykami międzynarodowymi, tzn. taki, gdzie byłoby rozdzielenie:
   Mamy 118 477 stron w indeksach i 33 412 artykułów. Wieralee (dyskusja) 15:56, 9 gru 2013 (CET)

• W frwikisource mają coś podobnego, ale na zasadzie codziennej aktualizacji liczby przez zliczającego artykuły/strony bota. Automatycznie i na bieżąco działającego licznika tego typu raczej się nie da zrobić przy obecnych ustawieniach MediaWiki. Ankry (dyskusja) 23:40, 9 gru 2013 (CET)

Usterka rendera plików PDF

Zgłaszam usterkę, to jest jej przykład.
A tak wygląda , gdyby się Wam nie wyświetliło: Jak rozwiążemy problem, to usunę ten obrazek, żeby nie spamować Commons. Superjurek   (Dyskusja) 20:02, 29 lip 2014 (CEST)

Usterki oprogramowania zgłasza się na bugzilli, nie tutaj. Tyle, że, o ile mi wiadomo, renderer PDF to fragment oprogramowania Mediawiki, który aktualnie nie ma "opiekuna" (nikt nie poprawia w nim błędów). Czekają na chętnego lub autora nowego renderera. Ankry (dyskusja) 20:06, 29 lip 2014 (CEST)

@Superjurek:Nie mogłeś zerknąć na sekcję powyżej Wikiźródła:Skryptorium/Pulpit techniczny#Przydatność opracowywanych tekstów na Proofread?? - to ten sam problem... Zdzislaw (dyskusja) 20:10, 29 lip 2014 (CEST)

Te błędy są zgłoszone na bugzilli: tutaj i tutaj. Byłoby miło, gdybyście zaczęli subskrybować strony tych błędów (należy dopisać się do listy CC — zaznaczyć "Add me to CC list", kliknąć na "edit", dopisać swój mail — i zapisać "Save Changes". Może, gdy zobaczą, że sprawą jest zainteresowanych więcej, niż dotychczasowych 5 osób, ich chęć wzięcia się do naprawy tego błędu wzrośnie. Wieralee (dyskusja) 21:10, 29 lip 2014 (CEST)

numery stron

Witajcie! Cytując z Wikiźródeł zauważyłem, że numery stron na stronie dzieła przeważnie nie zgadzają się z numerami stron skanu, n.p. strona [12] na Pani Hańska odpowiada stonie [6] książki. Przyczyną jest numeracja na stronie indeksu. Teraz pytanie: Czy istnieje jakiś sposób, żeby botem poprawić numeracje w istniejących indeksach? --Trevas (dyskusja) 16:49, 25 lis 2014 (CET)

• Nie możesz zmienić numeru strony w pliku djvu. Możesz jedynie nadać jej inny numer w indeksie (niektóre stare indeksy są w ten sposób skonstruowane), co prowadzi do jeszcze większego zamieszania, bo link do strony 312 w książce prowadzi np. do strony 323 w pliku djvu i taki numer pojawia się u góry strony... Tworzenie stron w przestrzeni głównej staje się wtedy nieprzewidywalne, nie można się w tym przypadku posługiwać numeracją w indeksie, tylko trzeba robić odręczne notatki. Zasadniczo też nie linkujemy do stron w indeksach, to jest przestrzeń robocza, tylko dla Wikiskrybów — i staramy się nie kierować do niej czytelników. Dla czytelników przeznaczona jest przestrzeń główna, gdzie stroną jest np. rozdział książki. I tak właśnie linkujemy, do strony rozdziału, bądź też wstawiamy w tekst rozdziału w konkretnym miejscu znacznik, do którego linkujemy, prowadząc czytelnika w dane miejsce w przestrzeni głównej, a nie do przestrzeni roboczej.
  

Czy możesz podać konkretny przykład? Na razie do Pani Hańskiej nic nie linkuje. Łatwiej wtedy znaleźć bardziej satysfakcjonujące rozwiązanie. Wieralee (dyskusja) 17:05, 25 lis 2014 (CET)

Chodzi mi głównie o funkcję „pokaż/ukryj numery stron”. Pokazane numery stron nie zgadzają się z numerami stron książki. Na de.wikisource natomiast nie ma takiej różnicy, n.p. de:Madonna della Sedia. Nach Raphael: strona książki [9] = wyświetlona strona [9] ≠ plik 52. Tu rozwiązano ten problem szablonem de:Vorlage:SeitePR. Czy <pages> pozwala zmianę numeracji? --Trevas (dyskusja) 17:29, 25 lis 2014 (CET)

• @Trevas: nie edytuję na de.wiki. Zastanawiam się, jak rozwiązali tam numerację okładek, stron tytułowych i przedmów (czasami nie są one numerowane w ogóle)... Jeśli rozwiązali to w logiczny sposób, być może warto porozmawiać o wprowadzeniu podobnego systemu u nas.
  

 Tyle, że najpierw musiałaby to przegłosować cała społeczność, to raz, a dwa — musiałyby znaleźć się osoby, które miałyby czas i chęć poprawiać te ponad 1000 indeksów, które mamy... Bot oczywiście wchodzi w grę, sęk w tym, że strony trzeba by było potem ręcznie sprawdzić, bo czasami indeksy nie uwzględniają pustych stron — niektóre Biblioteki Cyfrowe nie zamieszczają skanów pustych stron i w plikach djvu ich po prostu nie ma. Proste przesunięcie, np. +6 w takich przypadkach nie zadziała...

 Często zdarza się, że pojawiają się osoby, które chciałyby, żeby zaszły u nas zmiany, na których wprowadzenie potrzebne są dziesiątki bądź setki godzin pracy — ale chciałyby, żeby to zrobił "jakoś" "ktoś", a w naszej szczupłej gromadce nikt się do tego pomysłu nie pali. Dlatego jeżeli razem z wnioskiem o zmiany pojawia się także deklaracja realizacji danego pomysłu, społeczność częściej takie wnioski popiera. Wieralee (dyskusja) 17:59, 25 lis 2014 (CET)

@Wieralee:, taki sposób myślenia, jaki zaprezentowałaś powyżej, może być zniechęcający do inicjowania jakichkolwiek zmian. Gdyby Trevas wiedział dokładnie, w jaki sposób to można u nas technicznie rozwiązać, lub wiedział że będzie potrafił to sam zrobić, na pewno by to od razu napisał. Nie każdy (a wręcz mało kto) ma dostateczną wiedzę i doświadczenie w technikaliach, by takie zmiany potrafić sam "wymyślić" i zrealizować - czy to znaczy, że jeżeli zobaczy na innym projekcie jakieś ciekawe rozwiązanie, ułatwienie czy udoskonalenie, które być może przydałoby się i u nas, a nie wie, jak to zrobić, to ma się nie odzywać? Moim zdaniem jak najbardziej pozytywnym zjawiskiem jest, gdy ktoś rzuci uwagę "patrzcie, u nich jest coś fajnego, czego u nas nie ma! czy u nas da się coś takiego zrobić? ktoś wie, jak to zrobić?", nawet jeżeli przez długi czas nie znajdzie się osoba, która będzie w stanie u nas to zaprowadzić. Remedios44 (dyskusja) 18:10, 25 lis 2014 (CET)

@Remedios44: odnośnie Twoich słów "sposób myślenia" — w mojej wypowiedzi nie zawarłam żadnego sposobu myślenia, po prostu napisałam prawdę na temat procedury wdrażania zmian;

odnośnie "Gdyby Trevas wiedział" — nigdzie nie napisałam, że ma to zrobić sam, napisałam: "gdy pojawia się deklaracja realizacji". I jak widać pojawiły się już trzy deklaracje, czyli o ten wniosek możemy być spokojni;

nigdzie nie napisałam, ani nawet nie zasugerowałam, że ktoś "ma się nie odzywać", przeciwnie, napisałam, że jeżeli Niemcy rozwiązali w logiczny sposób numerację stron nie numerowanych, to być może warto porozmawiać o wprowadzeniu podobnego systemu u nas.

Nie wiem więc, dlaczego zaatakowałaś moją wypowiedź. Żadnej z zarzucanych mi przez Ciebie rzeczy nie napisałam. Cóż, jeśli chciałaś zrobić mi przykrość, to osiągnęłaś pełny sukces. Gratuluję. Wieralee (dyskusja) 01:48, 26 lis 2014 (CET)

@Wieralee: Nie miałam zamiaru nikogo urazić. Ostatni akapit twojej wypowiedzi (tej, do której się odniosłam) zdawał się (i wciąż wywiera na mnie takie wrażenie) krytykować sposób zgłoszenia przez Trevasa propozycji, jego rzekomą chęć, żeby "zrobił to jakoś ktoś" i brak razem z sugestią zmiany podanej od razu deklaracji jego samodziejnej realizacji. Dla mnie początek tej dyskusji wygląda tak: użytkownik pisze "Słuchajcie, u nich jest coś takiego, czego u nas nie ma, może warto u nas coś takiego zrobić? Da się to zrobić?" - na co otrzymuje odpowiedź: "Może warto i u nas coś takiego wprowadzić, ale to wymaga strasznie dużo pracy; znowu ktoś zgłasza pomysł, którego sam nie będzie robił, inni się będą za niego męczyć; jak już zgłaszasz propozycję, to od razu deklaruj że ją sam będziesz realizował". Tak to niestety brzmi. Dla mnie osobiście byłoby (i jest) to mocno zniechęcające. Remedios44 (dyskusja) 11:15, 26 lis 2014 (CET)

• @Trevas, @Wieralee, @Remedios44: Witam, problem numerowania stron problem, który podobnie ja w de był także dyskutowany w innych źródłach. Podobnie jak w de, system "oryginalnych" numerów stron funkcjonuje w fr i en. Rozwiązanie jest "proste" i nie wymaga przenumerowywania stron w plikach djvu czy pdf, a polega w skrócie na tym, iż funkcjonują tam dwie niezależne numeracje:
  • zgodna z plikiem djvu czy pdf "wyświetlana" w tekście dokładnie tak jak u nas
  • zgodna w indeksem (w którym są one zgodne z ksiązkowymi - wykorzystując standardowe mechanizmy, o których pisze Wieralee) - te z kolei wyświetlane są dyskretnie po lewej stronie tekstu w przestrzeni głównej.

Przykłady można zobaczyć tutaj en lub tutaj fr. Te dwie numeracje funkcjonują razem w wersji en (można włączać i wyświetlać je niezależnie korzystając z menu po lewej w en i opcji Show/Hide page links oraz Page links within/beside text. W wersji fr obecnie wyświetlane są już (po decyzji społeczności) jedynie te po lewej stronie tekstu (zgodne z indeksem) a te zgodne z plikiem djvu pozostały, lecz jedynie jako znaczniki w html (nie widać ich, lecz można poprzez #.... do nich linkować). Oczywiście, jeżeli w Indkesie są strony zgodne ze skanem to po "lewej" są także takie, lecz oczywiście zalecenie (nie reguła ani zasada) jest taka aby w nowych tekstach numery w indeksach wprowadzać zgodne z książką.

Takie rozwiązanie jest możliwe do wprowadzenia i pozostaje jako jedna z moich pozycji "todo" jako część usprawnień związanych z techniczną "stroną" czytnikową. Zdzislaw (dyskusja) 20:13, 25 lis 2014 (CET)

Dodanie numerów stron jest bardzo atrakcyjną funkcją. Zacząłem pisać stronę pomocy na ten temat. Warto ustalić priorytety rozwojowe, żebyśmy robili zmiany w zespole, a nie równolegle do siebie. Może spiszmy pomysły i wspólnie wybierzemy, w jakiej kolejności je zrealizujemy. sp5uhe ^{dyskusja edycje} 23:12, 25 lis 2014 (CET)

@Sp5uhe: wykorzystanie lokalnego js-a, a którym piszesz w przygotowywanej pomocy nie jest najlepszym rozwiązaniem, lepiej użyć na bieżąco rozwijanego przez fr i en (Phe nad nimi czuwa :) ) PageNumbers.js-a z "Shared Scripts" (i tak musimy zacząć od implementacji Base.js), (już wykorzystywanego na źródłach ca, de, es, fr, no, pt, vi), który to Pagenumber da nam także inne funkcje, takie jak zmienne layou-ty.

A i tak trzeba by zacząć od wprowadzenia "zwyczaju" i zaleceń aby numeracja stron w Indeksie realizowana była w zgodzie z numeracją w książce "ręcznie" lub lepiej przez mechanizm pagelist <pagelist 1to9=- 10=1 10to20=roman 21=1 /> i to należałoby uwypuklić w pomocy.Zdzislaw (dyskusja) 23:37, 25 lis 2014 (CET)

@Zdzislaw:Mechanizm <pagelist> wymaga sporej rewolucji w przyjętym podejściu, że nasze indeksy są raczej związane z wydaniami książki niż z jej podziałem na pliki djvu. <pagelist> można stosować wyłącznie przy filozofii indeks = plik djvu, co u nas często nie ma n=miejsca (patrz większość powieści, biblie, czy Staropolska). Poza tym uniemożliwia dostawianie stron spoza pliku djvu, co czasem czynimy w ramach poprawek, by nie robić renumeracji stron w djvu. Spróbuj zastosować mechanizm <pagelist> do Winnetou, gdzie plik djvu się kończy w śródku zdania (kontynuowanego w następnym pliku). Commons ma ograniczenia na rozmiar pliku djvu; poza tym korzystanie z dużych djvu i pdf (tych ostatnich w szczególności) jest koszmarnie wolne. Owszem, <pagelist> ma swoje zalety; m.in pozwala korzystać z dodatkowych funkcji, jak pomijanie stron czy zmiana kolejności logicznej. Ankry (dyskusja) 09:23, 26 lis 2014 (CET)

@Ankry: zgadzam się! dlatego pisałem także o sposobie "ręcznym" - tak jak wprowadzamy numery stron obecnie - nic nie staje na przeszkodzie aby zamiast 004 wpisać VI lub wartość tożsamą z książką. pagelist można wykorzystywać tam gdzie to jest "łatwo" stosowalne - nie mam zamiaru "forsować" obowiązku stosowania pagelist w żadnym razie. Wtedy dodatkowe numery stron (te po lewej w głównej) byłyby tożsame z nr-ami pliku djvu lub pdf (tak jak te w tekście - podobnie jest w innych źródłach - nie ma wymogu zgodności z książką), a jeżeli skryba wprowadzający Indeks miałby chęć i "zapał" mógłby "ręcznie" lub poprzez "pagelist" wprowadzić numerację zgodną z "papierem". Ja również nie wyobrażam sobie, ani zamiany istniejących, ani wprowadzania wymogu "zgodności". Numeracja "po lewej" to raczej "gadżet" zwiększający czytelność i komfort niż funkcja "zgodności z papierem", tak jak zmiany layotów realizowane przez ten sam skrypt - patrz w lewym menu opcje "Options d’affichage: Maquette 1/2/3..." na tej stronie. Zdzislaw (dyskusja) 13:24, 26 lis 2014 (CET)

@Zdzislaw:I w niektórych starszych indeksach tak jest; patrz tu, tu albo tu. Jednak po narzekaniach użytkowników (nie podobało im się, że nr strony w indeksie nie zgadza się z numerem widocznym jako tytuł strony w przestrzeni Strona) zarzuciliśmy ten mechanizm. Jeśli mamy do niego wrócić, to trzeba to dokładnie przemyśleć (narzekali głównie "zwykli" edytorzy, którzy nie angażowali się z żadne dyskusje wcześniej). Ankry (dyskusja) 17:14, 26 lis 2014 (CET)

@Zdzislaw:Zacząłem od pisania pomocy na podstawie strony en:Help:Page_numbers. Zacząć trzeba i tak od czegokolwiek, a później to rozwijać, poprawiać i uwypuklać. Z importowaniem skryptów trzeba być ostrożnym, bo czasem coś magicznie przestaje działać. Warto przyjąć rozwiązanie, które w razie czego pozwala łatwo odpalić kopię lokalną. Jednak obecnie według mnie o wiele ważniejsze jest spisanie różnych pomysłów i potrzeb, tak aby nie okazało się, że kosztem ogromnego nakładu pracy powstanie rozwiązanie z którego większość nie będzie chciała korzystać. sp5uhe ^{dyskusja edycje} 01:38, 26 lis 2014 (CET)

@Sp5uhe: Zgadzam się odnośnie do pomysłów oraz możliwości odpalenia wykonywania kopii lokalnej. Lepiej jednakże chyba używać narzędzi rozwijanych i optymalizowanych przez lata, na bieżąco dostosowywanych do nowych wersji MediaWiki i wykorzystywanych przez wszystkie źródła (nie obawiał bym się zatem o ich "zniknięcie") niż pisać swoje rozwiązania od podstaw. Apropopo kopi zapasowej lokalnej - obecnie importujemy z Shared Scripts już m.in. InterWikiTransclusion.js - czy któryś admin ma u siebie kopie lokalne? :))) Zdzislaw (dyskusja) 08:29, 26 lis 2014 (CET)

Powinny być w backupach przestrzeni MediaWiki dla oldwikisource. Mam kopie takich backupów. Ankry (dyskusja) 09:25, 26 lis 2014 (CET)

Coś tak czułem... :))Zdzislaw (dyskusja) 13:24, 26 lis 2014 (CET)

Linkujące także z siostrzanych projektów

Witam,
w preferencjach w sekcji Gadżety dodany został w wersji testowej nowy Gadżet, będący modyfikacją istniejącego Gadżetu "Linkujące z siostrzanych projektów". Gadżet Linkujące także z siostrzanych projektów integruje się ze stroną specjalną Linkujące i automatycznie pokazuje strony linkujące także z siostrzanych projektów.
W tej wersji Gadżetu nie ma potrzeby dodatkowego "klikania" w przycisk Pokaż linkujące z siostrzanych projektów - lista stron ze wszystkich projektów pokazuje się automatycznie.
Proszę Użytkowników wykorzystujących tę funkcję o uwagi donośnie do ewentualnych problemów w funkcjonowaniu testowego gadżetu.
Zdzislaw (dyskusja) 17:51, 29 lis 2014 (CET)

• Może ja się wypowiem, bo najwięcej tego używam ;-) Gadżet działa rewelacyjnie i bezbłędnie. Wnioskuję o zamianę dotychczasowego gadżetu (pokazującego linkujące z naszego projektu po pierwszym kliknięciu, a z siostrzanych dopiero w drugim podejściu) nowym gadżetem, który pokazuje wszystko od razu po jednym kliknięciu. Uzasadnienie: daje to oszczędność czasu i eliminuje błąd polegający na tym, że się zapomni w linkujące z siostrzanych kliknąć. Wieralee (dyskusja) 19:33, 13 gru 2014 (CET)

Mikroformat dla eksportera plików epub

Witam, zakończyłem pierwszy etap implementacji Microformatu dla ekportera epub, w szablonie {{Dane tekstu}} dla przestrzeni głównej. Dzięki temu generowane pliki z naszymi tekstami w formacie epub zostały wzbogacone o dane o tekstach bezpośrednio we właściwościach pliku epub oraz o skan oryginalnej okładki (pod warunkiem, że taka została zamieszczona w Szablonie "Dane Tekstu").
Z tego względu polecam dodawać skan okładki także w szablonie "Dane Tekstu" na stromach "/Całość" z tekstem całego dzieła.
Proszę o ewentualne uwagi odnośnie do zauważonych nieprawidłowości (w szczególności dla plików źródłowych ze skanami w formacie pdf) na mojej stronie dyskusji. Pozdrawiam Zdzislaw (dyskusja) 18:42, 13 gru 2014 (CET)

Podsumowując :) błędów nie stwierdzono. Dodam tylko, iż w styczniu 2015 pobierano pozycje z naszych źródeł poprzez Pobierz jako EPUB już 1138 razy. Zdzislaw (dyskusja) 22:10, 11 sty 2015 (CET)

Zmiany w szablonach {{Dane tekstu}} oraz {{całość}}

Witam, informuję, iż szablon {{Dane tekstu}} został uzupełniony o opcjonalne pole ilustrator, w którym można podać informacje o autorach ilustracji dla danej pozycji.

Ponadto uzupełniony został także szablon {{całość}}, służący do podawania informacji w szablonie {{Dane tekstu}} o stronie zawierającej cały tekst utworu (także tomu, rozdziału,...), o wyświetlanie informacji z linkiem do pobrania pliku z tekstem w formacie ePub.
Teraz informacja wyświetlana przez ten szablon wygląda następująco (np dla {{całość|Niedrukowany rozdział Opisu obyczajów Kitowicza/Całość}}:

Cały tekst

Pobierz jako: EPUB  • PDF  • MOBI 

Zobacz także na Niedrukowany rozdział Opisu obyczajów Kitowicza.

Zmiana ta ułatwi znacznie odszukanie wersji "przyjaznej" dla czytników dla danej pozycji oraz (co ma niebagatelne znaczenie zwłaszcza w chwili kiedy m.in. na tzw. mediach społecznościowych Fundacja prowadzi akcję informacyjną mającą przyciągnąć do źródeł coraz więcej użytkowników i edytorów) sprawi iż "obsługa" naszych źródeł będzie łatwiejsza a same teksty bardziej dostępne. Problemy odnośnie do pobierania naszych tekstów w formatach epub sygnalizował ostatnio m.in. Halibutt - rzeczniki prasowy Stowarzyszenia Wikimedia Polska.
Oczywiście dodatkowy link do pliku ePub z całością nie zostanie wyświetlony dopóki (np. podczas trwających prac nad pozycją) link do strony z całością jest "czerwony".

Zachęcam zatem bardzo, aby w polu inne szablonu {{Dane tekstu}} podawać link do strony z całością tekstu używając szablonu {{całość}}.
Zdzislaw (dyskusja) 16:41, 18 sty 2015 (CET)

Statystyki

Informacyjnie dla zainteresowanych tematem:

https://phabricator.wikimedia.org/T89689

Ankry (dyskusja) 02:16, 17 lut 2015 (CET)

Zdzislaw added a subscriber: Zdzislaw. :) Zdzislaw (dyskusja) 10:28, 17 lut 2015 (CET)

A mnie 10 razy wysyłają mail na potwierdzenie maila — i nic. mail nie przychodzi. Ani w spamie, ani nigdzie... A cofnąć się i podać inny mail się nie da :-( Wieralee (dyskusja) 11:19, 17 lut 2015 (CET)

Wygląda na to, że "Step one it to fix the data"został zrealizowany.
"Difference between Mon Feb 23 2015 and Tue Feb 24 2015" -> "with scan +478" Zdzislaw (dyskusja) 12:52, 24 lut 2015 (CET)

Na to wygląda. Zmieniłem licznik na stronie głównej na bardziej wiarygodny. Ankry (dyskusja) 13:47, 24 lut 2015 (CET)

Zestawienia stron na podstawie danych z baz Wikimedia

witam,
W związku z tym, iż zostały udostępnione publicznie repliki bazy danych Wikimedia Wiki, otrzymujemy potężne narzędzie Quarry, dzięki któremu możemy pozyskać właściwie dowolne dane dotyczące zawartości naszych Źródeł. Odpowiednio przygotowane zapytania umożliwiają, m.in. wygenerowanie danych dla zestawień stron w oparciu o dowolne kryteria, niedostępnych do tej pory z wykorzystaniem stron specjalnych.
Wykorzystując narzędzie Quarry wygenerowane zostały dane do listy tekstów "nieuźródłowionych" skanami:
Wikiskryba:Zdzislaw/Strony bez skanów
Jeżeli zaistnieje potrzeba wygenerowania interesującego Was zestawienia stron lub pozyskania danych, proszę o informację na mojej stronie dyskusji, w miarę możliwości postaram się pomóc. Zdzislaw (dyskusja) 23:41, 10 kwi 2015 (CEST)

Import

Wystąpiłem z wnioskiem o tymczasowe uprawnienia do importu stron z historią z innych wiki. Ankry (dyskusja) 22:09, 3 maj 2015 (CEST)

do zaimportowania

• en:Template:Img float
• en:Help:Contents (do podkatalogu, jako baza do rozwoju naszego Help-u)

Szablon:Img float

... został zaimportowany (@Zdzislaw: dzięki za znalezienie). Jest też dokumentacja opisująca jego użycie. A tutaj można zobaczyć jak wygląda w praktyce.

Możliwości ma większe, niż standardowa opcja "thumb" przy załączaniu obrazków. Polecam w szczególności wszystkim (@Wieralee:), których rażą ramki (nieobecne w oryginalnym źródle).

Proszę o ewentualne sugestie zmiany nazw samego szablonu, jak też wewnętrznych opcji jego. Na razie wszystko jak w angielskim oryginale. Ankry (dyskusja) 15:07, 4 maj 2015 (CEST)

Zmiany w szablonie {{Autorinfo}}

witam,
szablon {{Autorinfo}} został częściowo zautomatyzowany — od "teraz" parametry:
Biogram=, Cytat=, Commons=, Źródła=, Cytat1=,
odpowiedzialne za umieszczanie linków do siostrzanych projektów ma stronie autora są pobierane automatycznie z danych zapisanych na Wikidata. Nie należy zatem wypełniać tych pól "ręcznie".
Jeżeli strona, do której powinien odwoływać się projekt siostrzany nie jest dodawana automatycznie (a istnieje), w pierwszej kolejności należy dodać ją do danych na Wikidata, a dopiero gdy jest to z jakiś względów niemożliwe wypełnij powyższe parametry ręcznie.
Aby widoczne były linki do siostrzanych projektów w języku oryginalnym twórcy, koniecznie należy wypełnić parametry kod= oraz język= wskazujące na język twórcy.

Serdecznie proszę o ewentualne informacje o zauważonych nieprawidłowościach po zmianach na mojej stronie dyskusji lub w tym wątku.
Pozdrawiam, Zdzislaw (dyskusja) 20:44, 6 sie 2015 (CEST)

• Zautomatyzowane zostały kolejne parametry, dla których dane pobierane są z Wikidata:
  data urodzenia=, miejsce urodzenia=, data śmierci= oraz miejsce śmierci=.
  Proszę o ewentualne informacje o zauważonych nieprawidłowościach po zmianach. Pozdrawiam, Zdzislaw (dyskusja) 19:00, 8 sie 2015 (CEST)

• Czy jest szansa, by w braku strony autora na Commons, brał wartość z d:Property:P373 ?

tak też się dzieje :) Zdzislaw (dyskusja) 17:09, 13 sie 2015 (CEST)

Ujednolicenie parametrów w szablonach {{Centruj}}, {{---}} oraz {{===}}

witam,
informuję, iż ujednolicone zostały parametry odpowiedzialne za generowanie odstępu "przed" i "po" (margines górny i dolny) dla szablonów {{Centruj}}, {{---}} oraz {{===}}. Od teraz wielkości odstępu można podawać jedynie jako jawny parametr przed= oraz po=, tak jak można to było robić dotychczas opcjonalnie, co jest także zgodne z wywołaniem w szablonach {{F}} oraz {{F*}}. Oczywiście podstawowe wywołanie szablonów (bez tych parametrów) pozostaje bez żadnych zmian. Szczegóły znajdują się z dokumentacji szablonów.
Istniejące już w tekstach wywołania parametrów bez nazw (starym "sposobem"), odpowiedzialnych za generowanie odstępu "przed" i "po", zostały we wszystkich miejscach zamienione na wywołanie z nazwami przed= lub po= (szczególne podziękowania za pomoc dla Ankry-ego!).
pozdrawiam, Zdzislaw (dyskusja) 21:40, 10 sie 2015 (CEST)

Zmiana konfiguracji – wyłączenie domyślnego pokazywania zmian w kategoriach na stronie Specjalna:Ostatnie_zmiany

witam,
w ostanim tygodniu zaimplementowano nowe funkcje w oprogramowaniu mw, które miały na celu umożliwienie śledzenie zmian w zawartości Kategorii (gdy strona jest dodawana lub usuwana z kategorii). Funkcja ta została zaimplementowana na prośbę społeczności niemieckiej Wikipedii i byłą częścią Top 20 technical wishlist. Funkcja została wdrożona na wszystkich Wiki od czwartku 20.08. Funkcja została wprowadzona poprzez umieszczenie wszystkich zmian w Kategoriach na stronie Ostatnie zmiany (domyślnie - ponieważ można oczywiście wyłączyć widok "Kategorii" - także w preferencjach Użytkownika, lecz to nie daje efektu kiedy zaglądamy na OZ niezalogowani).

Niestety, ze względu na specyfikę rozszerzenia Proofread, używanego na Wikiźródłach, powyższe zmiany powodują jedynie, iż na stronie Ostatnich zmian - dla każdej zmiany statusu strony z przestrzeni "Strona", na OZ pojawiają się trzy wpisy o zmianie w Kategoriach: Kategoria:Nieskorygowana, Kategoria:Skorygowana, Kategoria:Uwierzytelniona, ponieważ każda zmiana statusu Strony automatycznie zmienia jej "umieszczenie" w tych Kategoriach.

W mojej ocenie taka zmiana spowodowała, że strona Ostatnie zmiany jest całkowicie nieczytelna i niepraktyczna. Wydaje mi się, iż dla WS ta opcja powinna być domyślnie wyłączona - można to zrobić, lecz wymagana jest zgoda społeczności na domyślne wyłączenie opcji pokazywania zmian w Kategoriach na stronie Ostatnie zmiany.

Proszę zatem o głosy {{za}} domyślnym wyłączeniem opcji pokazywania zmian w Kategoriach lub {{przeciw}}, aby technicy WMF widzieli zgodę społeczności na tę zmianę (lub ewentualny jej brak) bez znajomości języka. Zdzislaw (dyskusja) 23:00, 19 sie 2015 (CEST)

•  Za Zdzislaw (dyskusja) 23:01, 19 sie 2015 (CEST)
•  Za wyłączeniem tej opcji Wieralee (dyskusja) 23:02, 19 sie 2015 (CEST)
•  Za możliwością zmiany domyślnego zachowania w całym projekcie, nie tylko per użytkownik. Ankry (dyskusja) 23:25, 19 sie 2015 (CEST)
•  Za Vearthy (dyskusja) 00:59, 20 sie 2015 (CEST)
•  Za Salicyna (dyskusja) 01:02, 20 sie 2015 (CEST)
•  Za Wro. (dyskusja) 02:22, 20 sie 2015 (CEST)
•  Za Też mnie to zdenerwowało. Domyślnie niech będzie "nie pokazuj", definiowane per projekt, z możliwością zmiany per użytkownik. Bonvol (dyskusja) 08:01, 20 sie 2015 (CEST)
•  Za Btw. Na większych projektach (typu Commons) większość co mieści się w 1000 stron na ostatnich zmianach to te nieszczęsne kategorie. Chore to. Standardowo powinno być wyłączone, a włączane tylko przez użytkownika (a nie na odwrót). Electron  ^<Odpisz> 11:03, 20 sie 2015 (CEST)
•  Za JKW (dyskusja) 13:27, 20 sie 2015 (CEST)
•  Za Wiola (dyskusja) 19:02, 20 sie 2015 (CEST)
•  Za Cafemoloko (dyskusja) 19:40, 20 sie 2015 (CEST)
•  Za Ashaio (dyskusja) 17:29, 21 sie 2015 (CEST)

Dyskusja

IMO, powinna być w każdym projekcie możliwość decyzji:

1. czy funkcja ma być domyślnie włączona, a użytkownik może ją sobie wyłączyć (tak jest teraz)
2. czy funkcja ma być domyślnie wyłączona, a użytkownik może ją sobie włączyć.

Ankry (dyskusja) 23:25, 19 sie 2015 (CEST)

powinna :)) programiści mw nie przewidzieli, że "to" może się nie spodobać w jakimkolwiek projekcie:) Zdzislaw (dyskusja) 23:40, 19 sie 2015 (CEST)

Nowa wersja eksportera plików ePub, PDF, MOBI

witam,
Po trwających od maja testach nowej wersji eksportera plików dla Wikisource WSexport, która powstawała głównie podczas tegorocznego Wikimedia Hackathon 2015, obecnie trwają prace nad migracja naszych źródeł na nową wersję.
Główne zmiany (te zauważalne) po stronie przeglądającego teksty, to:

• przejście na najnowszą wersję formatu ePub 3 - nowe możliwości szczególnie na nowych czytnikach,
• możliwość pobierania dzieł poprzez WSexport bezpośrednio w formacie PDF (działający także se spisami treści!)
• możliwość pobierania dzieł (nareszcie!) bezpośrednio, w formacie "mobi", na czytniki Kindle - liczę, że kolega Rdrozd napisze o tym na swoim blogu :)

Przez najbliższe kilkanaście godzin powyższe zmiany będę implementował na naszych źródłach, w tym czasie mogą występować przejściowe problemy z pobieraniem plików, za co z góry przepraszam! Będę tutaj informował o zakończeniu prac. Zdzislaw (dyskusja) 19:14, 2 wrz 2015 (CEST)

• Ze względów technicznych testy potrwają jeszcze jakiś czas, proszę o wyrozumiałość (i o powstrzymanie się od zmian wywołań szablonu {{epub}} na stronach utworów, nawet jeżeli w chwili obecnej wyglądają (linki do pobrań) trochę "koślawo"). Dziękuję. Zdzislaw (dyskusja) 12:28, 4 wrz 2015 (CEST)

∗
∗             ∗

Przepraszam, za "zapomnienie" tego wpisu (dotyczy one jedynie wpisu, nie zmian)... prace z przejściem na nowy serwer eksportu zakończyły się z powodzeniem 7. września, i od tego dnia nasze teksty mogą być pobierane w 3 formatach epub, pdf oraz mobi (np. Antologja literatury francuskiej ).
Statystyki pobrań świadczą o tym, iż dodanie nowych formatów było dobrym krokiem - w październiku teksty nasze pobierano 1360 razy jako epub, 1004(!) razy jako mobi oraz 1610 razy jako pdf.
Tym bardziej jest mi miło, iż nasz pomysł z "trójcą" formatów został od początku października zaimplementowany także w tej formie na źródłach francuskich (od których do tej pory głównie my przejmowaliśmy nowe rozwiązania :) ). Zdzislaw (dyskusja) 21:52, 24 paź 2015 (CEST)

• Gratulacje @Zdzislaw:!!! Widzę, że przejęli nawet Twoje rozwiązania graficzne, łącznie z kolejnością formatów i Twoją ikonką mobi w wersji Beta :-) Wieralee (dyskusja) 22:45, 24 paź 2015 (CEST)
• Może link "Pobierz jako MOBI" warto dodać do lewej kolumny - gdzie są linki do EPUB i PDF. Zwiększy to zauważalność tej opcji. rdrozd (dysk.) 11:03, 13 lis 2015 (CET)
  • @Zdzislaw: co o tym myslisz? Ankry (dyskusja) 12:29, 13 lis 2015 (CET)

@Ankry, @Rdrozd: bardzo dobry pomysł, dodam linki do mobi oraz pdf-a (A4), sam jestem ciekawy jak wpłynie to na statystyki pobrań naszych utworów. Zdzislaw (dyskusja) 20:32, 13 lis 2015 (CET)

@Zdzislaw: W menu po lewej jest literówka - PFD zamiast PDF. Poprawić mogą tylko administratorzy. Bonvol (dyskusja) 22:06, 13 lis 2015 (CET)

@Rdrozd: Dziękuję za wpis na blogu, pozdrawiam, Zdzislaw (dyskusja) 21:54, 13 lis 2015 (CET)

• • minęła doba od zamieszczenia wpisu na blogu Roberta, a teksty ze Źródeł pobierane były 800(!) razy - to ~5 razy więcej niż w "zwykły" dzień (pomimo potwornych zdarzeń). Mam nadzieję, że Robert o nas nie zapomni, i za jakiś czas ponownie przypomni "Czytnikowcom" o Źródłach. Zdzislaw (dyskusja) 23:09, 14 lis 2015 (CET)
    • Nie zapomnę. :) Szykuję jeszcze taki zbiorczy artykuł o tym skąd brać "darmowe e-booki" i oczywiście Wikiźródła też tam będą. rdrozd (dysk.) 13:48, 15 lis 2015 (CET)

wielostronicowe przypisy

@Wieralee, @Zdzislaw, @Ashaio, @Salicyna, @Vearthy: Macie może pomysł jak rozwiązać kwestię przypisów w Obrazach natury Humboldta, np. na tej stronie? Są to kilkustronicowe (nawet do 10) przypisy, wymienione jako osobne pozycje w spisie treści. Ankry (dyskusja) 18:25, 21 paź 2015 (CEST)

w tym szczególnym przypadku, zostawiłbym ten tekst literalnie tak jak jest, tzn. objaśnienia i przypisy zostawiłbym jako cześć tekstu, podobnie jak odwołania (zwykły tekst 1), ewentualnie podlinkowane ¹) od odpowiedniej części tekstu) , nie stosowałbym tutaj rozszerzenia "Cite" do oznaczania przypisów. Zdzislaw (dyskusja) 18:46, 21 paź 2015 (CEST)

• Tutaj akurat zrobiłabym link do odpowiedniego podrozdziału sekcji Umiejętne objaśnienia i dopisy, np. "<ref>Zob. [[Umiejętne objaśnienia i dopisy/Jezioro Ticarigua]].</ref>" Wieralee (dyskusja) 21:00, 21 paź 2015 (CEST)

• @Wieralee: Ba. Ale cały problem w tym, żeby w epubie z całym tekstem (i na stronie całości) taki przypis nie kierował "w kosmos", tylko do odpowiedniej sekcji w bieżącym pliku. @Zdzislaw: ?

Na razie jedynym sposobem zapewnienia tego jest umieszczenie przypisów zawsze na tej samej stronie co główny artykuł (nie mogą być na osobnych stronach) i zrobienie linków wewnętrznych. Dokąd będziemy kierować z przestrzeni Strona, jest mniej istotne. Ankry (dyskusja) 22:03, 21 paź 2015 (CEST)

Czy problem polega na tym, że jeśli przypisy będą tradycyjnie zrobione przy użyciu <ref>-ów, to nie ma jak linkować do nich ze spisu treści? A jeśli wg propozycji Zdzislawa (ku której na razie skłaniam się najbardziej) przypisy będą zwykłym tekstem, to i z tekstu i ze spisu treści będą do nich prowadzić tak samo "ręcznie" zrobione linki? (W tym rozwiązaniu nie widzę żadnego problemu poza tym, że zwykle tak nie robimy; ale książka jest pod tym względem wybitnie nietypowa). @Zdzislaw: próbowałam zorientować się jak działają takie "ręczne" linki w epubach, ale coś musiałam zrobić nie tak bo tu w epubie wszystkie linki (ze spisu treści i pomiędzy tekstami, np. z Różańca do Zdrowaś Marya) wskazują na nieistniejące strony w serwisie wiki.com... Natomiast epub ze strony Śpiewnik kościelny działa dobrze, mimo że nie wykonywałam żadnych specjalnych zabiegów ze spisem treści. Czy ktoś już miał podobny problem? Ashaio (dyskusja) 14:12, 22 paź 2015 (CEST)

@Ashaio:tak, linki lokalne (nie-iterwik), jeżeli nie wchodzą do epubowego spisu treści, czy to poprzez "ws-summary", czy też poprzez to iż są podstronami dokumentu głównego (tak jak w Śpiewnik kościelny), w chwili obecnej nie są nadpisywane w epubie, więc linkują "lokalnie" do http://wiki/..., a więc poza naszym serwisem (także w epubach) wskazują, tak jak zauważyłaś... w "kosmos" - prace na tym "problemem" trwają (m.in. po to na razie istnieje strona Epub_Test na naszym serwisie), aby linkowały w epubie na http://pl.wikisource.org/wiki/wiki/..., lecz zw względu na to, iż zmiany te dotyczą ws globalnie, pewnie trochę to zajmie:)
Wracając do pozycji, która jest tematem tego wątku - na razie "ręczne" linki nie zadziałają w epubie (działają lokalnie), lecz kiedy pozycja będzie skończona i będzie posiadać spis treści, to dostosuję go do obsługi linkowań epubowych - ten przypadek jest szczególny, a "materia" zawiła :) Zdzislaw (dyskusja) 16:40, 22 paź 2015 (CEST)

@Zdzislaw: chodzi mi o epuba zrobionego ze strony całości, a nie ze strony spisu treści. Powinny być wtedy linki wewnętrzne, a nie linki do innych stron. Ankry (dyskusja) 17:30, 22 paź 2015 (CEST)

@Ankry: takie linki "ręczne", dla stron całości, z samym [[#link_wewnętrzny_do_id]] działają bez problemu, np. Obrazy natury/O stepach i pustyniach jest poprawnie linkowana w epubie, i o takie linkowanie chodziło mi w pierwszej mojej wypowiedzi ^z) :) Zdzislaw (dyskusja) 17:47, 22 paź 2015 (CEST)

Duże pliki DjVu

Wątek dla śledzenia problemu.

1. Special:Upload ma limit 100MB (T115984)
2. Mediawiki próbuje wyciągnąć "na siłę" informacje tekstowe z pliku jako metadane, przekraczając limit miejsca na to (T94562, T32906, T101400)
3. inne problemy (T116004)

Prawdopodobnie łatwiej byłoby załadować DjVu bez warstwy tekstowej (choć pewności nie mam). Narzędzie, które może się przydać:

• http://tools.wmflabs.org/url2commons/index.html
• c:User talk:Rillke/bigChunkedUpload.js

Ankry (dyskusja) 20:56, 22 paź 2015 (CEST)

Jak się cytuje wikiżródła na polskiej PL Wikipedii?

Chciałbym zacytować wikiżróła na polskiej Wikipedii ale nie ma tam odpowiednika szablonu "cite wikisource" jaki istnieje na angielskiej wersji WP. Nie rozumiem też dlaczego na polskich wikiźródłach przycisk z prawej strony "cytowanie tego artykułu" produkuje tylko referencje w Bibtex'u a nie ma stylu "cytuj książkę" czy też "cytuj wikiżródło". 22:59, 12 lis 2015 (CET)~

• @Puncinus: wydaje mi się, że ujęcie sprawy jako "cytowanie Wikiźródeł" to trochę postawienie sprawy na głowie... Czy można cytować bibliotekę? Zamieszczamy u nas wszelakie publikacje — i to dowolną z nich możesz cytować, tworząc odpowiedni przypis z linkiem, np.

Rodzina Lamów pochodziła ze Szkocyi, skąd pradziad Jana przesiedlił się do Hesyi.^[1]

lub:

Rodzina Lamów pochodziła ze Szkocyi, skąd pradziad Jana przesiedlił się do Hesyi.^[2]

Przypisy

1. Album biograficzne zasłużonych Polaków i Polek wieku XIX, nakładem Marii Chełmońskiej, Warszawa 1901.
2. Album biograficzne zasłużonych Polaków i Polek wieku XIX, nakładem Marii Chełmońskiej, Warszawa 1901.

czyli w kodzie źródłowym:

Rodzina Lamów pochodziła ze Szkocyi, skąd pradziad Jana przesiedlił się do Hesyi.<ref name="Album">[[:s:pl:Album biograficzne zasłużonych Polaków i Polek wieku XIX/Jan Lam|Album biograficzne zasłużonych Polaków i Polek wieku XIX, nakładem Marii Chełmońskiej, Warszawa 1901]].</ref>

Rodzina Lamów pochodziła ze Szkocyi, skąd pradziad Jana przesiedlił się do Hesyi.<ref name="Album2">[https://pl.wikisource.org/wiki/Album_biograficzne_zas%C5%82u%C5%BConych_Polak%C3%B3w_i_Polek_wieku_XIX/Jan_Lam Album biograficzne zasłużonych Polaków i Polek wieku XIX, nakładem Marii Chełmońskiej, Warszawa 1901].</ref>

Naturalnie, można zrobić szablon, ale chyba raczej na wiki? Rzadko tam edytuję, może jakiś szablon już istnieje? Wieralee (dyskusja) 23:25, 12 lis 2015 (CET)

• • Dzięki. Nie wiedziałem, że można napisać :s:pl, to bardzo mi uprościło sprawę cytowania wierszy Sępa Szarzyńskiego w haśle na Wikipedii. Moim zdaniem nie ma szablonu cytuj wikiżródła na polskiej Wikipedii, ale przypuszczam, że to się robi przez "cytuj książkę". W każdym razie Twoja odpowiedź mi bardzo pomogła. 02:35, 13 lis 2015 (CET)

Kwestia twardej spacji

Na przykład tutaj aż roi się od niej. Z kolei w innych indeksach występuje zazwyczaj wyłącznie przy wyrażeniach typu i t. p. Jak się powinno z nimi postępować:

• "zaczerwieniając" stronę?
• "zażółcając" stronę, która roi się od niej: usuwać czy zostawiać?

@Matlin: ten temat ma długą historię i w zasadzie... nie ma zasad. Była to jedna z kwestii, którą poruszyłem jako początkujący wikiskryba w okolicach 2009 roku (a może wcześniej? - trzeba by w archiwum poszukać). Propozycja dodawania jej po jednoliterowych wyrazach botem spotkała się ze zdecydowanym sprzeciwem. Głównym argumentem było, że zostawianie jednoliterowych spójników i przyimków na końcu krótkiego wiersza (do 40 znaków) jest zgodne z zasadami polskiej typografii (wprawdzie dla bota to nie problem, ale niektórzy wikiskrybowie nie tolerują automatyzacji zmian). Także okazało się, że w niektórych starszych tekstach, takie jednoliterówki na końcu wiersza zecerzy czasem zostawiali. Stanęło na tym, że jak ktoś chce, to może dodawać w trakcie edycji ręcznie. Sam uważam, że dodawanie &nbsp; po każdej "jednoliterówce" ręcznie to bezsensowna robota. Ale zacząłem dodawać w skrótach zawierających jednoliterówki i spacje. I tak się jakoś przyjęło.

Zasadniczo warto dodawać tak, gdzie nie chcemy złamać wiersza, np. dodając przypis oddzielony od poprzedzającego wyrazu spacją (wtedy: twardą), czy odsuwając znak interpunkcyjny na końcu akapitu, np. —?

Podsumowując: jak chcesz, to dodawaj, jak nie chcesz nie dodawaj, a usuwaj, jeśli masz poważne argumenty za usunięciem. Albo zaproponuj wprowadzenie jakiejś zasady w tej kwestii (najpierw poddając pod dyskusję).

Przy okazji, wyjaśnię dzisiejszy nocno-poranny zalew operacji bota. Związane to było z faktem, że Francuzi jakiś czas temu wprowadzili do MediaWiki mechanizm zastępowania zwykłej spacji przed: » i po: « spację twardą. Przyczyną było częste występowanie w starszych francuskich tekstach « takich cytatów ». I niestety bezmyślnie wprowadzili to na stałe do kodu, zamiast zrobić konfigurowalną opcję. Powoduje to usztywnienie otoczenia naszych »takich cytatów« i problemy z łamaniem wierszy w ich otoczeniu. Obejściem problemu jest zastąpienie spacji przez encję &#32; (oznaczającą zwykłą spację właśnie). Od dziś ta zamiana jest stałym, cotygodniowym zadaniem bota. Gdyby były z jego edycjami jakieś problemy, proszę o sygnał. Jeśli « cudzysłowy » miałyby się gdzieś jednak zachowywać po francusku, a bot nie rozpoznał tego, proponuję wstawić sztywne spacje ręcznie. Nie spotkałem na razie takiego tekstu. Ankry (dyskusja) 20:23, 21 lis 2015 (CET)

• @Matlin: zasadniczo największy wpływ na wygląd książki i przyjęte rozwiązania ma pierwsza osoba nad nią pracująca, ta, która książkę "przepisuje". Grzecznościowo nie poprawia się zbyt wielu rzeczy, które błędami nie są -- i w niczym nie przeszkadzają. Ale przy ciągłych zmianach html-a jesteśmy często zmuszeni zmieniać zawartość stron dość drastycznie... Często też zmiany mają konkretny cel -- coś tam w przestrzeni głównej wyświetla się błędnie, albo bardzo nieładnie, czego nie widać na stronie z indeksu... Są wikiskrybowie, którzy ze zmianami wyglądu redakcyjnego się godzą -- i tacy, którzy o swoją wizję walczą do końca ;-) Jak mi się coś nie podoba, bądź też widzę, że coś się psuje lub źle wyświetla, to zmieniam -- ale jeśli pierwszy edytor anuluje moją decyzję -- to widocznie mu się nie podobała. I z szacunku dla jej/jego pracy muszę to anulowanie uznać ;-) Mówię oczywiście o edytorach już wdrożonych w projekt, bo edycje nowych użytkowników są poprawiane zgodnie z aktualną w danym momencie tendencją graficzną ;-) Wieralee (dyskusja) 20:43, 21 lis 2015 (CET)
• Uważam, że wstawianie twardej spacji (ts) po każdej "jednoliterówce" jest nie potrzebne i niewskazane w tekstach ciągłych, których "wyświetlanie" zależeć będzie od wielu czynników - tak jak to widzimy w przestrzeni strona w większości wypadków nie będzie wykorzystywane (nie wspominając o różnych formatach), wstawianie ts ma sens jedynie w trakcie przygotowania konkretnego tekstu w konkretnym formacie i składzie do druku. "Zabezpieczanie" się na wypadek każdego formatowania wstawiając ts po każdej jednoliterówce, może powodować kiepskie wyświetlanie tekstu (np. wyjustowanego) w programach, które dla twardej spacji ustawiają stały odstęp. Taki "lepszy..." sposób formatowania w moim odczuciu jest "...wrogiem dobrego". Nie polecam, poza skrótami i szczególnymi wypadkami. Zdzislaw (dyskusja) 20:54, 21 lis 2015 (CET)

linkowanie do kategorii.

@Zdzislaw, @Wieralee: Bot skończył w nocy, ale mamy nowe przypadki. Zgłosiłem, w phab:T117332, jak sugerowali i proszę o niepoprawianie. Ankry (dyskusja) 10:52, 13 gru 2015 (CET)

Znikające sekcje po wstawieniu summary

Wstawiłem znacznik summary w spis treści książki Psychologia tłumu, w tym spisie są odnośniki, które prowadzą do mini-spisów poszczególnych ksiąg, np. Psychologia tłumu/Księga pierwsza. Po wstawieniu znacznika summary przestają działać sekcje w tych mini-spisach. Czy ja coś robię źle, czy to summary celowo powoduje? --Matlin (dyskusja) 22:29, 8 lut 2016 (CET)

sekcje nie zadziałają wewnątrz szablonu (jakiegokolwiek, nie jest to problem summary), wstawiłem div-a w Psychologia tłumu. Zdzislaw (dyskusja) 22:45, 8 lut 2016 (CET)

Zmiana konfiguracji - definicja "dobrej" zawartości dla Statystyk

witam,
tym razem proszę o głosy w sprawie zamiany konfiguracji mw dla naszych Wikiźródeł związanej z określaniem tzw. "wartościowej zawartości", czyli stron, które liczone są do meta:Wikimedia_News#Wikisources statystyk jako "GoodPages". Aby nie zanudzić postaram się krótko o tym, skąd bierze się dziwna liczba 116 344 dla pl ws. Dla Wikiźródeł, zgodnie z obecną konfiguracją, jako tzw. "zawartość" (ContentNamespace) dla Statystyk są liczone strony z przestrzeni Główna, Strona, Autor oraz Index.
Takich stron w naszych źródłach mamy na dzień dzisiejszy 366 382. Powstaje wiec pytanie dlaczego w statystykach uwzględniono jedynie ~117 000. Otóż, to czy dana strona jest "dobra" (i liczy się do tych statystyk), czy jest "zła" decyduje wartość zmiennej konfiguracyjnej mw:Manual:$wgArticleCountMethod. W tym momencie dla naszych i wszystkich ws brana jest ona z wartości "domyślnej" - 'link', co oznacza, że strona jest "dobra" jeżeli w swojej zawartości wikikodu posiada jakikolwiek wikilink. Ma to sens dla stron opisujących jakieś zagadnienia, w których kodzie zazwyczaj występuje przynajmniej link do jakiejkolwiek kategorii ([[Kategoria:jakakolwiek]]. Jednakże dla naszych wikiźródeł, dla których większość zawartości znajduje się w przestrzeni Strona taka definicja nie ma sensu, ponieważ jeżeli dla przestrzeni głównej większość stron i tak ma przynajmniej jeden link, to dla Strona jedynie ułamek procenta, innymi słowy taka definicja powoduje, że do Statystyk jest brana ta Strona:Chopin-_człowiek_i_artysta.djvu/009 strona (ponieważ zawiera w kodzie link), lecz już ta Strona:Chopin- człowiek i artysta.djvu/024 strona nie jest brana pod uwagę (a takich jest 99,9%). Jak widać taka definicja związana z linkiem wewnątrz strony nijak ma się do "zawartości" tworzonych na wikiźródłach w rozszerzeniu proofread, które automatycznie dodaje odpowiednie kategorie, i w samym wikikodzie linki do kategorii nie występują.
Proponuję zatem zmianę w konfiguracji (podobnie jak kilka innych wiki, np sc wikinews) w taki sposób aby zmienić wartość zmiennej mw:Manual:$wgArticleCountMethod na wartość 'any': all pages are considered as valid articles, dla której dla Statystyk oraz definicji "zawartości" będą brane wszystkie strony w danej przestrzeni nazw (Główna, Strona, Autor oraz Index).
Proszę zatem o głosy {{za}} proponowaną zmianą lub {{przeciw}}, aby technicy WMF widzieli zgodę społeczności na tę zmianę (lub ewentualny jej brak) bez znajomości języka. Zdzislaw (dyskusja) 22:03, 25 lut 2016 (CET)

Dyskusja

• @Ankry: no, ale nie jest liczone jednakowo, my mamy liczone artykuły, Francuzi strony książek z indeksów, a Niemcy strony książek z indeksów + artykuły. I na to za bardzo nie mamy wpływu. Ale podejrzewam, że jak my zmienimy, to inne WS pójdą naszym śladem. Więc może jednak warto zagłosować za? Tym bardziej, że skoro jest Ci wszystko jedno, to dlaczego nie? ;-) Wieralee (dyskusja) 09:57, 26 lut 2016 (CET)
• @Ankry: muszę odnieść się Twojego głosu "neutralnego" (i poprosić o ponowna analizę stanu obecnego), który zawiera jednakowoż dosyć ostry warunek "byle było spójnie dla różnych wikisource.". Otóż tego nie mogę tego ani zagwarantować ani obiecać z prostego powodu. W chwili obecnej żadne statystyki ani "zwykłe wikimediowe" (zaszyte w kod mw) ani realizowane w projekcie Wikistat nie są spójne(!). Pierwsze, właśnie ze względu na to iż w zależności do przyjętych sposobów opracowywania stron, czy wręcz sposobu wykorzystywania (czy nie) danych przestrzeni (link w kodzie strony) wyniki nie obrazują rzeczywistego wkładu ( w czym jest gorsza nasza strona w Page bez linków o takiej która ma linki?). W drugich o spójności nie może być nawet mowy!
  Podam jedne tylko przykład - wystarczy zerknąć na tą tabelkę oraz tą.- dla fr ws mamy 1,849,695 stron (Articles) co stanowi ich całkowitą sumę w ichniejszych przestrzeniach Main ~190 000, Page ~1 600 000 oraz Index i Author (w sumie prawie 2mln), a teraz my pl ws 98,610 Articles, co stanowi właściwie jedynie to co mamy w przestrzeni Main (to samo it ws). Cóż za niefart... de facto powinno być 190k fr vs 100k pl lub fr 2mln vs 350k pl, ale 2mln vs 100k wygląda lepiej, "nieprawdaż":)? kompletny brak spójności i możliwości porównywania. Dlaczego inni "zadbali" o to aby do ich statystyk wliczały się (w drugim przypadku) wszystkie (!) strony z Page a dla nas żadna(!)? Oczywiście... to czysty przypadek oraz "błedy" w kodzie i logice Statystyk.
  Reasumując, nie jestem w stanie zagwarantować spójności, albowiem teraz jej nie ma! To co robię (i jak wiesz działam także na oldwiki oraz na Phabrikatorze) robię aby wytyczyć spójny kierunek i pokazać "logiczna" konfigurację źródeł odnośnie do definicji "contentu" - dokładnie taką samą propozycję zgłosiłem na oldwiki, lecz nie zagwarantuję, że wszystkie źródła dostosują się do zmian, szczególnie te, które ustaliły sobie "własną" konfigurację w samym kodzie skryptów mw i sposobie tworzenia stron - moja propozycja jest jedynie drogowskazem, który definitywnie (poprzez właśnie liczenie "all" w przestrzeniach "contents") wyeliminować może taki stan jaki mamy obecnie (jedne strony (z linkiem) liczymy a inne nie, lub jedne ws liczą sobie Page a inne nie). Tak więc jeżeli neutralność warunkujesz spójnością, której i tak nie ma, to właściwie w tym momencie należałoby się zatrzymać. Zdzislaw (dyskusja) 10:20, 26 lut 2016 (CET)
• doprecyzuję jedną informację, aby nie było wątpliwości - zmiana powyższa NIE wpływa na zbiór przestrzeni, z których liczone są strony do Statystyk - w dalszym ciągu (to się nie zmienia) będą liczone jedynie zdefiniowane w zmiennej mw:Manual:$wgContentNamespaces (jak napisałem powyżej)"strony z przestrzeni Główna, Strona, Autor oraz Index".

Głosy

•  Za Zdzislaw (dyskusja) 22:03, 25 lut 2016 (CET)
•  Za Bonvol (dyskusja) 22:12, 25 lut 2016 (CET) (na marginesie: bardzo przystępnie napisane wyjaśnienie!)
•  Za Wieralee (dyskusja) 22:43, 25 lut 2016 (CET)
•  Za Nawider (dyskusja) 22:45, 25 lut 2016 (CET)
•  Wstrzymuję się jest mi wszystko jedno jak to będzie liczone, byle było spójnie dla różnych wikisource.  Za Ankry (dyskusja) 22:15, 29 lut 2016 (CET)
•  Za Alenutka (dyskusja) 22:24, 26 lut 2016 (CET)
•  Za Ashaio (dyskusja) 20:31, 1 mar 2016 (CET)

---

• wniosek na Phabrikatorze złożony, Zdzislaw (dyskusja) 22:29, 11 kwi 2016 (CEST)

Załatwione Zmiana została wdrożona. Zdzislaw (dyskusja) 18:24, 14 kwi 2016 (CEST)

Import z innych wiki - zmiana konfiguracji

Skoro dyskutujemy o zmianach konfiguracji MediaWiki dla plwikisource, chciałem zaproponować jeszcze jedną zmianę, umożliwiającą administratorom import stron (przeniesienie całej historii strony) z innych wiki do plwikisource.

Lista wiki, z których możliwy jest taki import, jest zawarta w zmiennej konfiguracyjnej wgImportSources (aktualna konfiguracja). W chwili obecnej import jest możliwy z następujących wiki:

'w', 'b', 'q', 'n', 'wikt', 'oldwikisource'

Proponuję dodanie do tej listy kilku bardziej aktywnych wikisource używających alfabetu łacińskiego ('de', 'en', 'es', 'fr', 'it', 'pt', 'sv') oraz zastąpienie 'oldwikisource' przez 'mul'. Nie proponuję dodawania wszystkich wikisource do listy (mają tak Francuzi), gdyż według mnie import czegokolwiek z innych wiki niż wymienione wyżej jest mało prawdopodobny a zbyt długa lista utrudnia wybór.

W chwili obecnej import z innych wiki niż wymienione w wgImportSources jest możliwy wyłącznie przez użytkowników posiadających uprawnienia importera (nadawane na wniosek użytkownika tymczasowo przez stewardów) i odbywa się za pośrednictwem pliku XML. Jest on znacznie mniej wygodny niż import bezpośredni.

W ostatnim czasie niestandardowy import (poprzez przesłanie pliku XML, lista odbywał się głównie z enwikisource; niewykluczone, że będzie przydatny również z innych *wikisource, zwłaszcza, gdy dostęp do tej funkcji będzie miało więcej osób. Podejrzewam, że import z *wikisource będzie dotyczył głównie technikaliów (szablony, moduły, gadżety).

Zmiana konfiguracji MediaWiki wymaga zgody społeczności, o którą niniejszym wnioskuję. Ankry (dyskusja) 02:39, 29 lut 2016 (CET)

Za/Przeciw

1.  Za jako wnioskodawca Ankry (dyskusja) 02:39, 29 lut 2016 (CET)
2.  Za Wieralee (dyskusja) 22:22, 29 lut 2016 (CET)
3.  Za Ashaio (dyskusja) 20:31, 1 mar 2016 (CET)
4.  Za Zdzislaw (dyskusja) 21:14, 1 mar 2016 (CET)
5.  Za Nawider (dyskusja) 11:05, 3 mar 2016 (CET)
6.  Za Cafemoloko (dyskusja) 08:19, 6 mar 2016 (CET)

Dyskusja

Złożyłem wniosek o zmianę konfiguracji. Ankry (dyskusja) 11:39, 6 mar 2016 (CET)

Załatwione Zmiana została wdrożona. Ankry (dyskusja) 07:21, 9 mar 2016 (CET)

Problemy z wypunktowaniami zaszytymi w tabele w aktach prawnych

Dlaczego tu działa, a tu nie działa? — Paelius (dyskusja) 21:00, 22 mar 2016 (CET)

{{Dane tekstu}} "Remont"

witam,
temat tego szablonu pojawia się czasami w dyskusjach... problem na chwilę obecną polega na tym, iż rozwój tego szablonu w obecnym stanie jest niemożliwy lub bardzo utrudniony - wynika to z tego, iż "dawno, dawno temu" został on przerobiony i "przystosowany" do idei "każda opracowywana książka mogłaby mieć swoją, już wypełnioną podstronę szablonu", która jak wiemy nie przyjęła się w wikiźródłach. Po roku od tych zmian w 2011, ich autor porzucił swój pomysł i skwitował iż to nie ma sensu zachowywać dokumentacji wprowadzającej w błąd i należy przywrócić poprzednią wersję szablonu oraz jego dokumentacji (...) za tydzień zabiorę się za to, łącznie z zamianą wywołań szablonu z „nową” na „starą” modłę..., co niestety nie nastąpiło.
W związku z powyższym, aby umożliwić dalszy rozwój szablonu oraz przywrócić klarowność opisu i sposobu stosowania, zabieram się za "wielkie sprzątanie". Nie wpłynie to w żaden sposób na obecny sposób stosowania i funkcjonowania szablonu, gdyby jednak pojawiły się jakieś problemy proszę o poinformowanie o nich w tym miejscu. Jest to także dobry moment, na zgłaszanie pomysłów na zmiany, braków czy innych skargi i wniosków:) Zdzislaw (dyskusja) 20:29, 27 mar 2016 (CEST)

"Nowa" konfiguracja stron w przestrzeni Indeks

witam,
to znowu ja:) dzisiaj kolejna odsłona zmian, których nie można już dłużej odkładać. Otóż w 2012 roku twórcy rozszerzenia Proofread, które jest "sercem" wikiźródeł, wprowadzili całkowicie nową konfigurację parametrów, z których "składane" są nasze strony w przestrzeni Indeks. Nowa konfiguracja pozwala na bardziej elastyczne definiowane parametrów Indeksów, dodanie pomocy kontekstowej, kilka technicznych zmian, m.in. możliwość wykorzystania mechanizmów "OAI-PMH" do dostępu do danych o naszych utworach (co umożliwić moze w przyszłości "udostępnianie" danych do zewnętrznych wirtualnych/cyfrowych bibliotek, tutaj przykład pobrania danych przez api no oldwiki.), a co najważniejsze, umożliwi dalszy rozwój i stosowanie tych samych narzędzi na wszystkich ws (pl ws jako jedna z nielicznych społeczności nie wprowadziła zmian jeszcze u siebie).
Konsultowałem się dzisiaj z autorami rozszerzenia Proofread, z naszymi kolegami z fr ws, i po omówieniu wszystkich kwestii technicznych, jak i zabezpieczeń na wypadek problemów jestem gotowy na wprowadzenie tych zmian u nas. W teorii, zmiana ta powinna odbyć się w taki sposób, iż nikt z Was nie powinien nic zauważyć (szczególnie, że układ jak i sposób definiowania Indeksów nie zmieni się z punktu widzenia użytkownika - poza pomocą kontekstową), lecz w trakcie samych zmian prosił będę o wstrzymanie się z edycjami w przestrzeni Indeks, co umieszczę w widocznym komunikacie na OZ-ach (pracę prowadzić będę bardzo późną nocą). Proszę o wyrozumiałość, i zgłaszanie tutaj ewentualnych problemów. Zdzislaw (dyskusja) 22:13, 28 mar 2016 (CEST)

---

Zrobione Zakończyła się zmiana konfiguracji dla stron w przestrzeni Indeks - jeżeli widzisz błędy na stronach Indeksów, proszę poinformuj o tym w tym wątku. Zdzislaw (dyskusja) 02:11, 29 mar 2016 (CEST)

nie wiem czy to jest ze sobą związane, ale strony ujednoznaczniające wyświetlają się na czerwno — Lord Jim i inne Nawider (dyskusja) 16:39, 29 mar 2016 (CEST)

@Nawider: takie "objawy" daje gadżet "Kolorowanie linków wewnętrznych do stron ujednoznaczniających.", najprawdopodobniej masz włączony w swoich Preferencjach. Zdzislaw (dyskusja) 01:19, 30 mar 2016 (CEST)

@Zdzislaw: Jest problem z wymogiem numerycznej wartości roku.

W wielu indeksach mamy przed/po/około albo zakres lat (poszczególne części wydawane w różnych latach).

Poza tym dla wielu indeksów podana jest w tym polu dokładna data dzienna (np. wszystkie ustawy i zarządzenia).

Warto by tych informacji nie zgubić. Ankry (dyskusja) 18:22, 1 kwi 2016 (CEST)

Tu właśnie się "zgubiła" :( Ankry (dyskusja) 18:27, 1 kwi 2016 (CEST)

@Ankry:tak, zdawałem sobie z tego sprawę, lecz uspokoiła mnie informacja w dokumentacji, iż for compatibility reasons the values have not to be of this type; "na szczęście" zguba powstaje jedynie podczas edycji, więc nie będzie problemu z pozbieraniem "zgub" - zajmę się tym problemem dzisiaj, przed zmianą chcę jeszcze zajrzeć w kod źródłowy rozszerzenia (w dokumentację szkoda czasu :) ), dziękuje za czujność, Zdzislaw (dyskusja) 18:55, 1 kwi 2016 (CEST)

Statystyka oglądalności strony

Proponuję, żeby uaktualnić link do licznika oglądalności strony. Teraz jest nowy, który można znaleźć na Wikipedii. Superjurek   (Dyskusja) 23:51, 2 lip 2016 (CEST)

• @Superjurek: jeśli możesz, to uaktualnij, proszę. Ja nie potrafię. Wieralee (dyskusja) 23:21, 3 lip 2016 (CEST)
• uaktualnione Zdzislaw (dyskusja) 20:44, 5 lip 2016 (CEST)

"Znikające" pole edycji strony

Przy włączeniu edycji strony pojawia się po lewej edytor. Czasem on jednak złośliwie się chowa, tak że nie mogę pracować nad daną stroną. Odkryłem jedynie tę powtarzalność, że edytor tekstu znika, gdy otwieramy edycję strony w nowym oknie/karcie, ale nie przechodzimy do niego. Od jakiegoś czasu znika on nawet wtedy, gdy nie przełączamy okien/kart - na jednych stronach płata figle, na drugich nie. Mam w preferencjach włączony ten zaawansowany edytor, a we wszystkich przeglądarkach wyłączone dodatki blokujące reklamy. Jako że jest to problem występujący w moich wszystkich używanych przeglądarkach (Chrome, Chromium, Firefox) jak i systemach (Windows 8, Ubuntu-linux), to być może oznacza jakąś błędną konfigurację w moich preferencjach? Może fakt używania zaawansowanego edytora? Załączam jako odnośnik zewnętrzny zrzut ekranu: http://screenshot.sh/m3iHhIcvYswb8 --Matlin (dyskusja) 00:23, 19 lip 2016 (CEST)

• @Matlin: nie miałam nigdy takich problemów, a okien/zakładek mam czasami otwartych ponad 20, w szczytach do 40. Ale fakt - nigdy zaawansowanego edytora nie włączam, bo strony wczytują się dużo wolniej. Wieralee (dyskusja) 01:08, 19 lip 2016 (CEST)

@Wieralee: no właśnie, w tradycyjnym edytorze wszystko śmiga (i nie znika). :-) --Matlin (dyskusja) 17:25, 24 lip 2016 (CEST)

Błędy w biogramach

Jak naprawiać błędy tego typu co tutaj i tutaj? --Matlin (dyskusja) 19:58, 8 wrz 2016 (CEST)

Trzeba zdebuggować kod LUA. Przypuszczam, że coś zmienili w Wikidata. Patrz też tutaj. Ankry (dyskusja) 21:08, 8 wrz 2016 (CEST)

Automagia, wcześniej czy później, wykazuje tendencję do autonarowów. Pewnie wystarczy wstawić ręcznie parametry miejsce urodzenia i miejsce śmierci, jak to drzewiej bywało... i wszystko będzie działać jak należy. Electron  ^<Odpisz> 21:21, 8 wrz 2016 (CEST)

Doraźnie wystarczy. Ale to ukryje problem z automagią. Ankry (dyskusja) 21:26, 8 wrz 2016 (CEST)

No, ba... Niestety czasami trzeba użyć też ręcznych argumentów. Btw. Usuwanie zastanych już argumentów nie było chyba przemyślanym posunięciem. Jako naprawiacz z wieloletnią praktyką stosuję zasadę: nigdy nie naprawiaj tego co działa, bo po takiej udanej naprawie działać już nie musi ;) Electron  ^<Odpisz> 21:35, 8 wrz 2016 (CEST)

To jest tradycyjna kwestia priorytetów. Zależy co ważniejsze: poprawne wyświetlanie w dwóch biogramach, czy naprawienie błędu w LUA. Bo błędy ukryte, których nie widać mają to do siebie, że zwykle nikt ich nie naprawia... Ankry (dyskusja) 22:06, 8 wrz 2016 (CEST)

Pewnie masz rację. Tym niemniej jako człowiek starej daty wybieram zawsze pewność działania, która radykalnie maleje jeśli opieramy się na jakimś mechanizmie, na który nie mamy większego wpływu, przy którymś ktoś tam zawsze majstruje i nie ma szerszego pojęcia jak on jest wykorzystywany w innych projektach - to wcześniej czy później generuje problemy. Korzystanie z takiego mechanizmu być może jest wygodne, ale nie jest pewne. Oczywiście nie zachęcam do powrotu do epoki kamienia łupanego ale z postępem należy ostrożnie - to zwierze narowiste i dobrze jak ma założony kaganiec. Electron  ^<Odpisz> 22:25, 8 wrz 2016 (CEST)

Nie da się zrobić indeksu

Nie da się utworzyć indeksu. :( --Matlin (dyskusja) 18:38, 5 paź 2016 (CEST)

Na globalny filtr antyspamowy trafiło; nazwa zawiera coś podobnego do numeru telefonicznego. Jeśli edytowalne jest też tylko dla adminów, to sugerowałbym zmienić nazwę tak, by nie było w niej trzech trzycyfrowych bloków pod rząd. Ankry (dyskusja) 19:00, 5 paź 2016 (CEST)

Dziękuję za wyjaśnienie i naprawienie problemu :) Ten plik nie był wrzucony przeze mnie - ale przez jakąś organizację. Jeszcze raz dziękuję i miłego wieczoru. --Matlin (dyskusja) 19:20, 5 paź 2016 (CEST)

Zmianę nazw właśnie zaproponowałem tutaj. Ankry (dyskusja) 19:45, 5 paź 2016 (CEST)

The Wikimedia Developer Summit wants you

The Wikimedia Developer Summit is the annual meeting to push the evolution of MediaWiki and other technologies supporting the Wikimedia movement. The next edition will be held in San Francisco on January 9–11, 2017.

We welcome all Wikimedia technical contributors, third party developers, and users of MediaWiki and the Wikimedia APIs. We specifically want to increase the participation of volunteer developers and other contributors dealing with extensions, apps, tools, bots, gadgets, and templates.

Important deadlines:

• Monday, October 24: last day to request travel sponsorship. Applying takes less than five minutes.
• Monday, October 31: last day to propose an activity. Bring the topics you care about!

More information: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit

Subscribe to weekly updates: https://www.mediawiki.org/wiki/Topic:Td5wfd70vptn8eu4

MKramer (WMF) (talk) 21:07, 14 paź 2016 (CEST)

Separator - - -

Na stronie Strona:Gabrjela Zapolska-I Sfinks przemówi.djvu/012 napotkałem taki separator, dla którego chyba nie ma jeszcze szablonu {{- - -}} analogicznego do {{---}}, {{===}} itp. Czy się mylę? Ten separator jest użyty więcej razy w tym tekście więc wolałbym go oszablonować. Jeśli jeszcze szablonu nie ma, to jakimi parametrami, poza całkowitą szerokością, powinien on być kontrolowany? Moja propozycja to

{{- - -|opcjonalnie szerokość|przed=...|po=...|kreska=...px|przerwa=...px}}

przy czym parametry kreska i przerwa miałyby domyślną wartość 20, szerokość domyślnie 300 (osiem kresek). Natomiast w przypadku podania szerokości, kreski lub przerwy jako parametr szerokość byłaby największą krotnością wskazanych szerokości kresek i przerw mieszczącą się w podanej lub domyślnej szerokości. Sensownie? 生きる (dyskusja) 17:08, 28 paź 2016 (CEST)

• @生きる: zazwyczaj robimy to poprzez szablon {{kreski-hr}} lub {{separator}} zobacz tutaj. Wygląd tego separatora jest zależny od szerokości ekranu, a na to właśnie nie mamy wpływu: nasi czytelnicy używają zarówno starych komórek, jak i monitorów panoramicznych... Naszym nadrzędnym celem jest udostępnianie tekstu, przy układzie graficznym siłą rzeczy wprowadzamy zazwyczaj uproszczenia. Pamiętaj, że strony trzeba potem skorygować i uwierzytelnić, a przeciętni Wikiskrybowie nie są informatykami: mamy wśród nas i gimnazjalistów i emerytów. Dlatego cieszę się zawsze wtedy, gdy tekst nie jest przesadnie najeżony kodem html. Szablony to zazwyczaj lepsze rozwiązanie.

Do rzeczy ;-) Każdy może wprowadzić nowy szablon: jeśli chcesz, zawsze możesz dodać kolejny. Jeśli będzie on intuicyjny i łatwy do zapamiętania, to inni Wikiskrybowie będą go używać i na pewno będą Ci wdzięczni (ja też ;-)). Wieralee (dyskusja) 17:31, 28 paź 2016 (CEST)

• Jestem za takim szablonem — "nazwa" jest intuicyjna i sam czułem potrzebę parę razy użycia czegoś takiego. Grunt by niezależnie od wielkości ekranu był zachowany duch takiego wiersza, czyli by była to linijka z rozstrzelonymi kreskami. Samych kresek nikt nie będzie liczył. Bonvol (dyskusja) 18:45, 28 paź 2016 (CEST)
• @Bonvol: jak już pisałam powyżej: mamy już takie dwa szablony. Ale i trzeci może się przyjąć, jeśli będzie lepszy. Z tego, co pamiętam, największą trudnością był brak "opływowości" tego szablonu w przestrzeni głównej, w sytuacji, gdy używany był na początku rozdziału, w tej sekcji, gdzie tekst jest węższy z powodu szablonu "Dane tekstu" po prawej. Nie pamiętam już dokładnie, o co chodziło, ale były z tym problemy: szablon przesuwał tekst w dół. Zdzislaw to jakoś rozwiązał, ale nie znam się na tym :-) @生きる: jeśli będziesz robić trzeci szablon, dobrze by było od razu to przetestować. Wieralee (dyskusja) 18:59, 28 paź 2016 (CEST)

  Lubię kombajny jeśli chodzi o tekst, bo tylko w ten sposób możemy opanować różnorodność zabiegów drukarzy. Jednak typowe, proste szablony przydają się, a idea kresek oddzielających sekcje tekstu jest na tyle prosta i powtarzalna, że widzę z niego korzyść. Alternatywą byłoby dopasowanie szablonu {{kreski-hr}} do wąskich ekranów tak, by zamiast zwężać spacje, a w końcu przestać zwężać — po prostu oddzielał rozstrzelonymi kreskami wiersz niezależnie od jego szerokości (a zdarza mi się zaglądać na Wikiźródła na komórce i pewnie nie tylko mi). Dlatego napisałem o duchu a nie literze szablonu i jeśli ktoś chce za to zabrać, to popieram. Grunt, by szablon nie działał na zasadzie "ma być 15 kresek", tylko "ma być tyle kresek przedzielonych spacjami by wypełniły szerokość strony, chyba że ktoś wprost zażąda marginesu". Bonvol (dyskusja) 19:13, 28 paź 2016 (CEST)

  Wydaje mi się, że nie ma możliwości, aby "szablon" wiedział jaka jest szerokość ekranu w chwili generowania kodu HTML dla przeglądarki. Krótko mówiąc: co ma być wyświetlone (np. ilość kresek) i sposób prezentacji musi być niezależne od szerokości okna; można tylko "poinformować" przeglądarkę jak ma te kreski wyświetlać za pomocą dostępnych w HTML mechanizmów. To, co proponujesz (responsywność wyświetlanych elementów) można uzyskać jedynie za pomocą javascriptu. Czyli mógłby to robić albo gadżet albo kod zaszyty w mediawiki (np. w skórce). Chyba, że o czymś nie wiem... Ankry (dyskusja) 19:29, 28 paź 2016 (CEST)

  Miałem na myśli np. wariantowanie szablonu w zależności od urządzenia z użyciem @media, a by liczbę kresek ograniczyć na wąskich ekranach - można założyć "wykrawanie" tylko środkowej części większej, na stałe ustalonej liczby kresek (by boczne kreski były po prostu obcięte). Ale nie próbowałem. Podsuwam pomysł do sprawdzenia. Bonvol (dyskusja) 22:39, 28 paź 2016 (CEST)

  @Bonvol: A możesz doprecyzować, o czym dokładnie mówisz? Jakiś przykład? Ankry (dyskusja) 23:24, 28 paź 2016 (CEST)

  @Ankry: Postaram się w tym tygodniu zweryfikować pomysły w praktyce. Bonvol (dyskusja) 14:51, 1 lis 2016 (CET)

• @生きる: Mógłbyś doprecyzować jakiego mechanizmu sugerujesz użyć do "tworzenia" kreski (znak pauzy, tag <hr>, podkreślenie, ramka, ...)?
  • rozmiar znaku pauzy zależy wyłącznie od użytego fontu; o ile wiem nie da się powiązać rozmiaru fontu z szerokością ekranu
  • we wszystkich pozostałych przypadkach trzeba określić "grubość" kreski w pikselach (w odróżnieniu od długości czy przerwy nie da się jej powiązać z szerokością ekranu)
  • użycie tutaj czegoś innego niż znak graficzny (np. pauza) spowoduje, że przy C&P treści te elementy "zginą" (czasami radzimy sobie z tym "ficzerem" używając {{Ukryty}}
  • treść powinna się możliwie sensownie wyświetlać zarówno na bardzo wąskich ekranach (ekran smartfonu z "zoomem" - 100-200px) jak i bardzo szerokich (monitor panoramiczny - ~3000-4000px); ideał jest nieosiągalny ale poprawiając jedno nie psujmy drugiego
  • bardziej skomplikowany kod szablonu -> większy jego rozmiar -> problemy przy dużych tekstach (MediaWiki ma tu ograniczenie do 2MB transkludowanego - m.in. przez ProofreadPage - kodu HTML)

Ankry (dyskusja) 19:57, 28 paź 2016 (CEST)

@Ankry: szczerze mówiąc nie myślałem jeszcze jak to zrobić. W chwili rozpoczynania tego wątku widziałem tylko potrzebę użycia szablonu, myślałem też że trzeba odwzorować wygląd tekstu jeden do jeden, czyli zarówno liczbę kresek, jak i to, że w oryginale nie wypełniają one szerokości na 100%. Ale jeśli przyjęło się tu robienie tego w przybliżeniu szablonem kreski-hr to nie mam z tym problemu. Tym bardziej w obliczu zagadnień technicznych opisanych wyżej. Jako nowy użytkownik jedynie zwracam uwagę, że dużo intuicyjniejszym rozwiązaniem, zmniejsząjącym próg wejścia, byłoby nazwanie szablonu "kreski-hr" jakoś bardziej zbieżnie z innymi separatorami, np. właśnie "- - -". 生きる (dyskusja) 07:13, 29 paź 2016 (CEST)

@生きる: Zasadniczo staramy się możliwie wiernie odwzorować tekst. Jednak nie to jest głównym priorytetem. Głównym priorytetem jest sensowna prezentacja przepisanego tekstu w przestrzeni głównej i w razie "kolizji interesów" ma ona priorytet. Z tego względu nie koncentrujemy się na stronach, które nie są transkludowane do przestrzeni głównej. Z tego też względu zdecydowaliśmy kiedyś stworzyć szablony {{Kreski-hr}} czy {{Kropki-hr}} aby przy istniejących ograniczeniach techniczny w sposób w miarę sensowny prezentować separatory w przestrzeni głównej. Oczywiście, nie wykluczamy, że ktoś kiedyś wymyśli coś lepszego, ale jeśli by to miał być bardzo skomplikowany mechanizm, to czy warto puszczać dużo pary w ten gwizdek? Zwłaszcza, że w szablonie tym, tak naprawdę, żadnego tekstu nie ma... Ankry (dyskusja) 12:37, 29 paź 2016 (CEST)

Jeszcze wracając do tego zagadnienia - w szablonie {{kreski-hr}} zmieniłem domyślny kolor na taki jaki widzę w szablonie {{---}} czy {{===}} ponieważ na stronie I Sfinks przemówi.../Premjera w Teatrze Miejskim czarne kreski przeciążały widok odciągając od tekstu. Dodałem też wsparcie dla parametru style, żeby można było zmienić kolor na inny jeśli to konieczne. 生きる (dyskusja) 18:59, 8 lis 2016 (CET)

@生きる: Zmiana domyślnego zachowania szablonu to nie jest dobry pomysł, gdyż ingeruje mocno w utworzone wcześniej teksty. Jeżeli chcesz dodać dodatkowe opcje, nie ma sprawy. Ale zmiana zachowania ingerująca w dotychczasowe użycie nie powinna mieć miejsca bez szerokiej dyskusji. Osobiście jestem  Przeciw takiej zmianie. Ankry (dyskusja) 19:14, 8 lis 2016 (CET)

@Ankry: Właśnie w związku z podejrzeniem wystąpienia takich obiekcji czułem się w obowiązku tutaj o tym poinformować. Gdzie mogę przeczytać o tym jak przegłosowano ustalenie, że pojawiające się w tekście czarne kreski separatorów ustalono by prezentować jako szare szablony {{---}} i {{===}}? 生きる (dyskusja) 19:28, 8 lis 2016 (CET)

@生きる: Gdyby był wcześniejszy konsensus w tej materii, to bym po prostu wycofał twoją zmianę zamiast wdawać się w dyskusję. A o ewentualnym ustaleniu, być może poczytamy tutaj, jeśli trochę poczekamy. Ankry (dyskusja) 19:43, 8 lis 2016 (CET)

zgadzam się, zmiana domyślnego zachowania szablonu to nie jest dobry pomysł - modyfikując szablon zawsze staramy się nie zmieniać dotychczasowego sposobu "działania" - ewentualne dodatkowe opcje powinny być opcjonalne, jestem także  Przeciw takiej zmianie. Zdzislaw (dyskusja) 23:34, 8 lis 2016 (CET)

A mi się ta zmiana podoba, nie widzę też niczego nagannego w ujednoliceniu wyglądu separatorów, tym bardziej że mam nieodparte wrażenie, że gdyby podobna zmiana była "przedyskutowana" na IRCu przez dwoje-troje administratorów, bez możliwości wypowiedzi czy nawet przeczytania dyskusji przez pozostałych użytkowników nie korzystających z IRCa, wtedy zostałaby uznana za uprawnioną i dokonana w glorii i chwale. Salicyna (dyskusja) 05:49, 9 lis 2016 (CET) Przepraszam za drugą część mojej wypowiedzi, przez cały dzień zastanawiałam się nad jej sensem (a właściwie jego brakiem) i nad tym, skąd mi się wzięła, nic mnie nie usprawiedliwia poza może tym, że całą noc nie spałam, jestem chora i rozdrażniona. W każdym razie była niesprawiedliwa i niepotrzebna. :( Salicyna (dyskusja) 17:01, 9 lis 2016 (CET)

@Salicyna: nie nazwał bym tego ujednoliceniem, bardziej zróżnicowaniem, szablony {{---}} oraz {{===}} od wielu lat bazują na tagu hr, i pomimo wielu zmian które w nich dokonywano (ja również), każda z nich nie zmieniała ich wcześniejszego sposobu "wyświetlania". Samo hr zaś, a właściwie widzialny przez użytkownika odcień szarości, zależny jest nie od definicji standardu a od konkretnego browsera, który jest używany ( w większości przypadków (lecz nie wszędzie) jest to pochodna stylu inset) - tak więc fiksowanie szarości do {{kreski-hr}} nie da ujednolicenia w dosłownym tego znaczeniu.
Wracając do sedna (i pomijając Twoje nieodparte wrażenia, które, mam nieodparte wrażenie, iż ma służyć jedynie podgrzaniu atmosfery), wszystkie szablony oparte na {{Separator}} (kreski, kropki, znaki, ...) były zdefiniowane przez autora jako wyświetlane w domyślnym kolorze "czcionki" przeglądarki - zwykle czarnej jak wyngiel. Jeżeli użytkownicy stosowali je, widząc taki ich sposób wyświetlania, to w moim odczuciu nie powinno się teraz narzucać całkiem innego ich koloru (domyślnie) (nie mam nic na przeciwko aby dowolny kolor można było ustawić w użyciu dla danych przypadków), ktoś kto ma specyficzne ustawienia browsera... i podtrzymuję swoje zdanie  Przeciw tej zmianie, Zdzislaw (dyskusja) 12:42, 9 lis 2016 (CET)

@Salicyna: "przedyskutowanie" na IRC-u ma zwykle charakter rozpoznawczy; i jeśli nawet jakieś zmiany są wprowadzane w oparciu o takie dyskusje, nic nie stoi na przeszkodzie by je przedyskutować tutaj i ewentualnie wycofać, jeśli nie ma konsensusu. Dlatego sugeruję, by, jeżeli są jakieś konkretne zastrzeżenia, wyartykułować je tutaj.

Co do "ujednolicania": mnie akurat razi szary kolor w {{---}} jako niezgodny ze skanami; pewnie chętnie bym go "ujednolicił". Ale skoro wiem, że nie ma w tej sprawie konsensusu, to nie podnoszę tematu.

Z drugiej strony, myślałem, że szablon {{Kreski-hr}} jest powszechniej używany. Ale skoro nie jest, a można używać {{Separator}}a bezpośrednio, to nie traktujcie mojego sprzeciwu jako bardzo ostry. Być może zmienię zdanie, jeśli będzie w tej sprawie szerszy odzew. Ankry (dyskusja) 14:33, 9 lis 2016 (CET)

---

Uwzględniając powyższe uwagi:

• przywróciłem poprzedni wygląd domyślny szablonu {{kreski-hr}}

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

• dodałem parametr "kol", żeby ujednoliciś podawanie koloru z rodziną szablonów formatujących, typu {{F}}

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

• pozostawiłem parametr "style"

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

• ujednoliciłem wszystko z szablonem {{kreski-hr-gęste}}

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

Jednocześnie wykonałem eksperyment czy jednak nie dałoby się ujednolicić tego szablonu, by również był oparty o tag HR jak pozostałe separatory. Miałoby to tę zaletę, że w ramach jednej przeglądarki (lub eksportera do pliku) wszystkie separatory miałyby ten sam kolor. Efekt wygląda tak: en:w:User:生きる/sandbox/kreski-hr. 生きる (dyskusja) 06:49, 10 lis 2016 (CET)

Kombajn formatujący i następny akapit

Zauważyłem na stronie Król Maciuś na wyspie bezludnej/całość, że pierwsze zdanie "Och, jak strasznie źle było Maciusiowi w więzieniu." ma większy odstęp od kolejnego akapitu niż reszta tekstu. Podejrzewam (całkowicie intuicyjnie), że ma to jakiś związek z zastosowaniem do tekstu "Drukarnia Naukowa. Warszawa, Rynek Starego Miasta 11." kombajnu formatującego, a następnie sklejenia go z "Och, jak strasznie..." przez mechanizm wikiźródeł. Czy ktoś techniczny mógłby na to spojrzeć? Z góry dziękuję, 生きる (dyskusja) 17:15, 18 lis 2016 (CET)

@生きる: taki "efekt uboczny" związany jest ze sposobem "transkludowania" stron z przestrzeni strona przez rozszerzenie proofread. Nie zanudzając, rozszerzenie dodaje (przed każdą stroną) ukryte bloki z linkiem i numerem strony w przestrzeni Page, na co parser mw "odpowiada" złamaniem akapitu w htmlu po pierwszym wersie. Drogi są trzy:1. nauczyć się z tym żyć; 2. złamać akapit "ręcznie" w "dobrym" miejscu, ubiegając parser mw, tak jak to zrobiła Wieralee; lub, 3. walczyć o zmiany w silniku rozszerzenia proofread (ostrzegam, że walka trudną będzie, ze względu na to, iż wieeeeeele źródeł "korzysta z tego efektu ubocznego"). I tyle, a wspomniany przez ciebie kombajn jest tutaj jedynie kozłem ofiarnym. Zdzislaw (dyskusja) 18:40, 18 lis 2016 (CET)

konflikt edycji

Raczej nie. Jest to efekt wstawiania przez MediaWiki w pewnych miejscach tagów <p> w sposób nie do końca kontrolowany przez użytkowników.

Zauważyłem, że Mediawiki wstawia takie tagi, m.in. jeżeli w jednym fizycznie wierszu znajdą się elementy z różnym formatowaniem (np. wycentrowane i niewycentrowane). Podobny efekt dotyczy ostatniego fizycznie wiersza tekstu (dlatego zwykle, jeśli ostatni widoczny wiersz tekstu ma takie samo formatowanie jak poprzednie - np jest to zwykły akapit - dodajemy na końcu tekstu dodatkowy <br /> w osobnym fizycznie wierszu). Dotyczy to każdego tekstu w main.

Trzeba pamiętać, ze przy łączeniu kolejnych stron, nie jest dostawiany pomiędzy nimi znak nowego wiersza, lecz spacja. W efekcie, jeżeli:

• N-ta strona kończy się np. {{---}}, {{c|cośtam}} lub innym elementem wycentrowanym,
• (N+1)-sza strona zaczyna się normalnym akapitem {{tab}}Jakiś tekst..., to po transkluzji do main zostaną one sklejone w jeden wiersz:

{{---}}{{tab}}Jakiś tekst... i pierwszy akapit Mediawiki oddzieli od następnych (sformatuje inaczej).

Można to obejść wymuszając w takiej sytuacji połączenie tekstu w kolejnych wierszach, np. zostawiając jeden pusty wiersz na początku strony (na końcu są wycinane) lub dodanie w osobnym wierszu na początku lub na końcu strony dowolnego wikikodu, który nic nie wygeneruje, np. <nowiki />, <includeonly /> lub tp.

@Wieralee: jeśli potrafisz to w prosty sposób sformułować, to może dodać to do jakiejś sekcji zaawansowane w poradniku cioci? Ja prościej chyba wyjaśnić nie potrafię ;P

Ankry (dyskusja) 18:54, 18 lis 2016 (CET)

Poprawianie OCR skanu kolumnowego

Czy są jakieś przyjęte metody poprawiania tekstu OCR skanów z kilkoma kolumnami, jak np. Strona:M. Arcta słownik ilustrowany języka polskiego - Tom 2.djvu/223, tak żeby to było wykonywane najszybciej? Edycja tego tekstu z OCR jest uciążliwa. Jest dla mnie wygodniejsze skasowanie go i przepisanie od zera. Ale nie chce mi się wierzyć, żeby starzy wyjadacze też tak robili. Przyszło mi do głowy, że można poprawiając tekst pierwszej kolumny i dochodząc do tekst drugiej kolumny naciskać SHIFT+CTRL i strzałką w prawo zaznaczyć tekst drugiej kolumny, bez zastanawiania się nad nim, następnie nacisnąć CTRL+strzałka w dół, co spowodowałoby przeniesienie całego zaznaczonego tekstu (czyli wiersz drugiej kolumny), na koniec okna edycji. Tak krok po kroku: poprawiam wiersz pierwszej kolumny, wiersz drugiej kolumny odsyłam na dół. Po ostatnim wierszu pierwszej kolumny dochodziłoby się automatycznie do pierwszego odesłanego wiersza drugiej kolumny i poprawiało resztę bez odsyłania czegokolwiek niżej. Ten sam mechanizm działałby przy 3, 4, 5 kolumnach, tylko stopniowo malałaby ilość tekstu odsyłanego w dół. Czy taki mechanizm, lub podobny, istnieje? Mą Ka (mące nierówna)^{jak odmieniać?} (dyskusja) 13:01, 10 sty 2017 (CET)

@Mą Ka (mące nierówna): Na działanie gadżetu OCR wpływ mamy niewielki: to jest zewnętrzne narzędzie z toolservera. Natomiast akurat dla tego indeksu jest lepszy, trochę już przetworzony OCR na stronie dyskusji indeksu. Trzeba go tylko podzielić na strony. Ankry (dyskusja) 13:14, 10 sty 2017 (CET)

Ale akurat na stronach, które Wieralee pominęła były z nim właśnie problemy. Trzeba go będzie wygenerować jeszcze raz zewnętrznym narzędziem. Ankry (dyskusja) 13:15, 10 sty 2017 (CET)

@Ankry: Jak to się robi? Czy jest jakiś samouczek jak dodać OCR do pliku, lub wygenerować go samodzielnie z djvu? Na stronie Wikiskryba:Liteman jest podlinkowana taka pięciotomowa pozycja "Przechadzki po mieście". Chciałbym jak najszybciej zacząć ten piąty tom redagować. Co muszę zrobić? Czy gdzieś się składa zamówienia na takie coś? Mą Ka (mące nierówna)^{jak odmieniać?} (dyskusja) 20:13, 10 sty 2017 (CET)

Pobiera się .djvu z biblioteki, wrzuca na commons i robi indeks/indeksy. Ściągam. Wrzucę. W przyszłości zgłaszać możesz tutaj. Nie sprawdzałem, czy i jaki OCR jest w środku; specjalistką od OCR-u jest Wieralee. Ankry (dyskusja) 20:42, 10 sty 2017 (CET)

Developer Wishlist Survey: propose your ideas

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

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

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

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

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

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

Kłopoty techniczne

Przepraszam, że pytam, ale czy tylko ja odczuwam bardzo niestabilną lub dziwną pracę serwerów? Systematycznie różne części interfejsu odmawiają mi pracy, lub pracują niewytłumaczalnie dziwnie, lub niewytłumaczalnie wolno, lub wstawiają mi do kodu rzeczy, których nie wprowadziłem z klawiatury. Przykład z ostatniej chwili: ktoś rozumie, dlaczego otrzymałem taki dziwny rendering szablonu {{tab}}? https://s23.postimg.org/ifd2c6kh7/dziwne1.jpg Mą Ka (mące nierówna)^{jak odmieniać?} (dyskusja) 16:38, 21 sty 2017 (CET)

Pytanie dodatkowe, czy komuś jeszcze się w CAPTCHA w wikimediach pojawia "AnitaUnion" do wpisania, albo inne w tym stylu? Kiedyś były zupełnie inne wyrazy w bazie do captcha. Mą Ka (mące nierówna)^{jak odmieniać?} (dyskusja) 17:54, 21 sty 2017 (CET)

JustowanieStart2 vs. CentrujStart2

Proszę spojrzeć na te dwie strony: 1 i 2. Mają tę samą strukturę, ale różnią się tylko tym, że transkludowane strony są otoczone szablonami jak w tytule wątku. Jednak w renderingu różnią się położeniem tabelki z danymi tekstu. Przy użyciu "JustowanieStart2" tabelka z danymi tekstu "dziedziczy" górny odstęp z bloku tekstu, którego kod jest poniżej wywołania szablonu. Tak to wygląda u mnie: https://s23.postimg.org/402n3ptnv/margin.jpg - czy to zamierzony efekt i normalna sytuacja? Mą Ka (mące nierówna)^{jak odmieniać?} (dyskusja) 20:21, 22 sty 2017 (CET)

• @Mą Ka (mące nierówna): tak, różnica pomiędzy szablonami jest zamierzona. Gdyby różnicy nie było, używalibyśmy jednego szablonu. Wieralee (dyskusja) 20:23, 22 sty 2017 (CET)

  Ja to rozumiem, że te szablony mają różne zastosowania. Ale większość szablonów zazwyczaj "infekuje" blok, który obejmują. Nie rozumiem dlaczego tekst z wnętrza bloku wpływa na to co jest poza blokiem, w szczególności przed nim. Szablon {{Dane tekstu}} jest przed startem justowania/centrowania. Dlaczego jego położenie jest modyfikowane? Mą Ka (mące nierówna)^{jak odmieniać?} (dyskusja) 20:28, 22 sty 2017 (CET)

• @Mą Ka (mące nierówna): dlaczego jego położenie jest modyfikowane? Dlatego, że twórca szablonu taki właśnie efekt chciał osiągnąć. Niestety, minusem wszelkich tabelek jest to, że muszą mieć taką samą szerokość kolumny zarówno na dole, jak i na górze strony. Co oznacza, że nie mogą się nagle "rozszerzać" w miejscu, gdzie szablon DT się kończy. Tak więc przy dość znacznym zwężeniu ekranu, co nam prezentujesz na zrzucie ekranu, tabelka się dość znacznie zwęża. Cóż, nie wszystko się da obejrzeć na wyświetlaczu telefonu komórkowego. Jeśli nie odpowiada Ci działanie szablonu, możesz z niego zrezygnować. Wieralee (dyskusja) 20:37, 22 sty 2017 (CET)
• @Mą Ka (mące nierówna): Jeśli chodzi Ci o obniżenie nagłówka, to cóż, jeśli się zadaje parametr "przed=3em", to on po prostu działa. Dlatego lepiej jest takie odstępy wpisywać w strefę noinclude nagłówka i stopki danej strony w indeksie — otwiera się je przez przycisk [+] w przyborniku. Z mojej praktyki - żeby uniknąć niespodzianek w przestrzeni głównej ja na przykład staram się nie używać parametru "przed" na początku działów/rozdziałów, natomiast zawsze dodaję parametr "po" na końcu -- wtedy nie ryzykuję, że odstępy się zdublują lub niespodziewanie zaburzą mi spójność rozdziałów, a jednocześnie mam pewność, że rozdziały nie "zleją się" w jedno na stronie całości. Wieralee (dyskusja) 20:48, 22 sty 2017 (CET)

  Tak, zadałem "przed=3em" żeby działało, ale odnośnie bloku, którego dotyczy, a nie wpływało na cokolwiek poza tym blokiem. Pierwsze słyszę, żeby jakiś szablon dotyczący justowania bloku wpływał na elementy poza nim. To nie jest logiczne zachowanie, to jakaś magia zwiększająca próg wejścia w projekt. Oprogramowanie powinno być dostosowywane do ludzi, a nie ludzie dostosowywać się do oprogramowania. Jeśli w szablonie {{C}} daję parametr "przed" to ten parametr może dotyczyć tylko tego co jest wewnątrz {{C}} zgodnie z założeniami tego szablonu. Jeśli jest jakiś mechanizm, który w celu wyjustowania "przepina" coś na stronie dynamicznie, to powinien również dynamicznie wstawić sztucznie element kompensujący tę operację tak, by efekt był zgodny z kodem strony. Np. tak jak to zrobiłem w kodzie wspomnianych stron. Teraz 3em działa przy obu blokach i nie wpływa na dane tekstu w ramce. Na marginesie, uważam, że księgarze nie bez przyczyny poprzedzali rozdziały takim górnym marginesem. Rozdziały w książkach papierowych i w elektronicznych publikacjach bez takich marginesów górnych zniechęcają do czytania, męczą oczy, utrudniają szybkie przewijanie stron. Dziwię się, że je usuwasz. To w mojej opinii produkuje exporty "brzydsze" i niepodobne do oryginałów, które przepisujemy. Ale to wyłącznie moje prywatne zdanie i kwestia gustu. I jeszcze jedno, nie wiem po co wspomniałaś o telefonie, ja z niego nie korzystałem. Mą Ka (mące nierówna)^{jak odmieniać?} (dyskusja) 15:40, 23 sty 2017 (CET)

Pytanie techniczne o eksportery

Czy jest możliwość adresowania styli CSS do eksporterów używanych przez Wikiźródła? Wcześniejsza dyskusja odnoście marginesów górnych skłoniła mnie do przyjrzenia się jak wygląda eksport gotowego tekstu. Wszedłem do wczoraj utworzonej kolekcji i wyeksportowałem do PDF "Dzieci kapiatan granta" używając ikonki w kolekcji. Pobieranie trwało 5 sekund, ale chyba minutę czekałem zanim się zaczęło (serwer tworzył PDF?) W rozdziałach jakoś eksporter rozpoznaje (ciekaw jestem jak) gdzie kończy się rozdział i wstawia podziały strony. Ale na stronach początkowych dochodzi do kuriozalnej sytuacji gdy tytuł książki jest podzielony między strony. Na jednej jest "Dzieci kapitana", na drugiej "Granta". Zastanawiam się, czy nie można mieć jakiejś kontroli nad tymi podziałami i mówić narzędziom eksportującym "w tym miejscu zacznij nową stronę". Chodzi mi o taki szablon o nazwie np. "Od nowej strony" albo "Nowa strona" albo "Podział strony", który w sobie miałby coś w rodzaju

<div class="pagebreak" />

natomiast w definicjach css wprowadzić:

.pagebreak {} // nie twórz podziału na ekranie, i w zwykłym wydruku
@media (exp2pdf, exp2epub) {
    .pagebreak { page-break-before:always; } // twórz podziały w eksporterach
}

To by przydało trochę "ludzkiej twarzy" tym eksportom. Mą Ka (mące nierówna)^{jak odmieniać?} (dyskusja) 19:04, 23 sty 2017 (CET)

• proponowane rozwiązanie jest niezgodne ze standardem ePub 3.0., na którym bazuje eksporter. (eksporter nie tworzy podziałów strony dla kolejnych rozdziałów, one są po prostu w osobnych plikach). [Co do center zaproponuję rozwiązanie na stronie dyskusji szablonu - {{Dystans}} będzie zbędny], Zdzislaw (dyskusja) 20:06, 23 sty 2017 (CET)

Ponowne przeliczenie kategorii

Zamierzam postawić na phabricatorze wniosek o ponowne naliczenie liczników kategorii.

Kilka lat temu zmuszeni byliśmy wprowadzić poprawki do niektórych liczników, gdyż ich wartości nie odpowiadały rzeczywistości. Stan ten utrzymuje się nadal, jednak różnica między wartością licznika a wartością rzeczywistą (przynajmniej dla kategorii Indeks pozostaje od kilku lat niezmienna. Pozwala to przypuszczać, że błędy w oprogramowaniu MadiaWiki, w wyniku których te różnice powstały, zostały już usunięte i że po ponownym naliczeniu będziemy mieli stabilną sytuację z prawidłowymi danymi.

Ponowne naliczenie liczników kategorii odbywa się za pomocą skryptu uruchamianego po stronie serwera i, o ile mi wiadomo, obejmuje wszystkie kategorie danej wiki.

Proszę o zaopiniowanie wniosku. Ankry (dyskusja) 13:54, 24 sty 2017 (CET)

Dodam tylko, że chodzi o uruchomienie skryptu populateCategory.php. Ankry (dyskusja) 15:35, 24 sty 2017 (CET)

•  Za Zdzislaw (dyskusja) 14:36, 24 sty 2017 (CET)
•  Za Bonvol (dyskusja) 15:45, 24 sty 2017 (CET)

---

Sprawa wydaje się załatwiona (phab:T156670). Pousuwałem korekty liczników. Ankry (dyskusja) 17:10, 1 lut 2017 (CET)

Losowe położenie przycisku do OCR

Czy znany jest fakt losowej lokalizacji przycisku do OCR w pasku narzędziowym?

• https://s30.postimg.org/r6m92le81/ocr1.png
• https://s30.postimg.org/q5m0dgx8h/ocr2.png

Od dłuższego czasu obserwuję to zjawisko ale nie mogę wywnioskować jakiejś reguły. Po prostu losowo raz w górnym pasku, raz w dolnym. Mam K. a się nie chwalę (dyskusja) 09:57, 28 sty 2017 (CET)

• @KaMan: 1) radzę wyłączyć pasek zaawansowany; strona wczytuje się wolniej, a wszystkie potrzebne na codzień przyciski są zawarte w pasku zwykłym, ale oczywiście decyzja należy do Ciebie 2) z tego, co wiem, kolejność wczytywania się gadżetów nie jest ustalona przez oprogramowanie MediaWiki, więc ich wzajemne położenie względem siebie jest losowe. Wieralee (dyskusja) 10:36, 28 sty 2017 (CET)
• znany, to tylko jeden z symptomów problemów z synchronizacją js w rozszerzeniu proof - o wszystkim możesz przeczytać i pomóc w usuwaniu błędów na phabrikatorze, gdzie realizowana (głównie przez wolontariuszy) jest obsługa techniczna oprogramowania mw. Zdzislaw (dyskusja) 12:31, 28 sty 2017 (CET)

Developer Wishlist Survey: Vote for Proposals

Almost two weeks ago, the Technical Collaboration team invited proposals for the first edition of the Developer Wishlist survey!

We collected around 77 proposals that were marked as suitable for the developer wishlist and met the defined scope and criteria. These proposals fall into the following nine categories: Frontend, Backend, Code Contribution (Process, Guidelines), Extensions, Technical Debt, Developer Environment, Documentation, Tools (Phabricator, Gerrit) and Community Engagement.

Voting phase starts now and will run until February 14th, 23:59 UTC. Click here on a category and show support for the proposals you care for most. Use the 'Vote' and 'Endorse' buttons next to a proposal to do so.

What happens next?
Proposals that will gather most votes will be included in the final results which will be published on Wednesday, February 15th. These proposals will also be considered in the Wikimedia Foundation’s annual plan FY 2017-18 - SSethi_(WMF) (talk) 04:41, 6 February 2017 (UTC)

Przycisk Publikuj zmiany

W związku z (moim zdaniem słusznymi) zastrzeżeniami odnośnie poprawności językowej sformułowania Publikuj zmiany, zmieniłem treść przycisku na Zapisz zmiany. Jeśli komuś zmiana przeszkadza lub ma inne propozycje, to proszę tu o komentarze. Ankry (dyskusja) 23:11, 1 kwi 2017 (CEST)

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 na tem.

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)

---

kliknij "Rozwiń" aby zobaczyć całą dyskusję i wprowadzone już zmiany... ⇶

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 /. na z
• zamiana cbc na chc
• zamiana _icb na _ich
• zamiana cli na ch
• zamiana cłi na ch
• 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 ° na o
  • ale może zrobić litera°literao ?
• zamiana _! na !
• zamiana _? na ?
• zamiana _. na .
• zamiana _, na ,
• zamiana _: na :
• zamiana _; na ;
• zamiana ' na ’
• zamiana i t._ na i t.  (i&nbsp;t.&nbsp;)
• zamiana n. p. na n. p. (n.&nbsp;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:

• zamiana _<br /> na <br />
• zamiana — na _—_
• zamiana dwie spacje na jedna spacja

Wieralee (dyskusja) 22:48, 12 sie 2015 (CEST)

@Wieralee: Dziękuję za pomoc i cenne propozycje. Propozycje oznaczone zostały zaimplementowane w kodzie gadżetu, pozostałe wymagają dyskusji:

• zamiana cli na ch - może niekorzystnie wpłynąć na poprawne wyrazy clić, oclić, precli, strucli...
• zamiana ° na o - ° występuje często w wypunktowaniu 1°, 2°..., być może ze spacjami na początku _° na _o?
• zamiana i t. na i t.  - w jakim celu ta niełamliwa spacja dodatkowo na końcu?

Zdzislaw (dyskusja) 17:50, 13 sie 2015 (CEST)

• 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... Mamy i t. p. i i t. d.. Tym sposobem zamienia się obydwa skróty, a samego skrótu i 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._ na i t. ? czy jednak i_t. na i t. ? Zdzislaw (dyskusja) 18:30, 13 sie 2015 (CEST)

• 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_ na ch_
• zamiana cb. na ch.
• zamiana cb, na ch,
• zamiana cb: na ch:
• zamiana cb; na ch;
• zamiana cb? na ch?
• zamiana cb! na ch!

Ż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 jest możliwość zamienienia:
  • litera6litera na literaólitera
  • litera1litera na literallitera

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ę:

• cyfraO na cyfra0
• _0litera na _Olitera

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ć na té
• zamiana t. zw. na t. 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:

• usunięcie podkreślnika dolnego
• zamiana p._t. na p. t.
• zamiana t._j. na t. j.

Vearthy (dyskusja) 11:25, 21 sie 2015 (CEST)

• zamiana slde na skie (częsty błąd w nazwiskach)
• zamiana _ocl i _ocł na _od

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

Proszę jeszcze o:

• usunięcie spacji przed …
• zamiana \v na w
• zamiana v/ na w
• myślałam jeszcze o zamianie cb na ch -- 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 \\’ na w
• zamiana {{tab}}—_1_ na {{tab}}—_I_

Wieralee (dyskusja) 21:40, 16 gru 2016 (CET)

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 na czym
• moźn na możn
• róźn na różn
• iź_ na iż_
• ćh na ch

Wieralee (dyskusja) 19:29, 1 mar 2017 (CET)

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 _ą_

@Zdzislaw: --Fallaner (dyskusja) 17:56, 8 gru 2017 (CET)

i kolejne

• _` na _,
• _7 na _,

--Fallaner (dyskusja) 22:22, 13 gru 2017 (CET)

• ñ na fi --Fallaner (dyskusja) 15:30, 6 sty 2018 (CET)

• si, na się --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)

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, [18], [19] 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.
  • Zrobione, [20], [21], [22] Zdzislaw (dyskusja) 17:32, 8 cze 2017 (CEST)

Zdzislaw (dyskusja) 20:25, 12 maj 2017 (CEST)

• @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.

Ankry (dyskusja) 11:33, 16 wrz 2017 (CEST)

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)

• 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)

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.

1. Read over the help page, it is brief and has screenshots
2. Login or register an account on Beta English Wikipedia
3. Visit Global Preferences and try enabling and disabling some settings
4. Visit some other language and project test wikis such as English Wikivoyage, the Hebrew Wikipedia and test the settings
5. 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)

Biblia Wujka (1923)

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.

CKoerner (WMF) (talk) 22:58, 12 cze 2018 (CEST)

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)

Znaczniki big

Hej

Gdy oznaczam szczególnie strony tytułowe często mam taka informację o problemie ze znacznikami big i podobnymi ze względu na HTML5. Czy Wikiźródła jako projekt interesowały sie tym? PMG (dyskusja) 10:15, 20 lip 2018 (CEST)

• @PMG: tak, oczywiście, od czasu wprowadzenia standardu html5, w którym nie są dalej wspierane takie tagi jak <font>, <center>, <big>, czy <u>, nie rekomendujemy ich stosowania, i w przyborniku oraz pasku narzędzi zostało ich wywołanie zastąpione wywołaniami z odpowiednimi parametrami szablonów {{c}}, {{f}}, {{f*}}. Przykłady użycia znajdziesz w opisie szablonów. Niestety, ze względu na mnogość opcji i przypadków użycia tagów <font>, <center>, <big>, czy <u>, ich zamiana na wywołania szablonów nie jest możliwa w sposób automatyczny. Nie stosujemy tagów w nowo tworzonych stronach. W starych (takich jakie poprawiasz) staramy się stopniowo podczas edycji zamieniać je na szablony, do czego Cię namawiam, jednakże ich pozostawienie, gdyby zamiana była dla Ciebie zbyt trudna lub nudna, w chwili obecnej nie spowoduje jeszcze problemów, ze względu na to, że przeglądarki jak i parser mw na razie radzą sobie z niebędącymi już zgodnymi ze standardami tagami. Pozdrawiam, Zdzislaw (dyskusja) 15:34, 20 lip 2018 (CEST)

Czasem, jeżeli formatowanie strony tytułowej jest bardzo skomplikowane, chyba lepiej pozostawić jej edytowanie komuś bieglejszemu w HTML5. (Czyli nie mnie, na przykład)(Anagram16 (dyskusja) 03:53, 21 lip 2018 (CEST))

Takie podejście jest całkowicie zrozumiałe i uzasadnione: z tego też powodu (aby ktoś bieglejszy mógł takie strony wyłapać i poprawić) takie edycje są jedynie oznaczane, a nie w jakikolwiek sposób wstrzymywane. Niemniej, w prostszych przypadkach, zachęcam do samodzielnej poprawy. Zwłaszcza osoby, które już opanowały używanie podstawowych obecnie szablonów formatujących, takich jak {{f}}, {{c}} czy {{f*}}. Ankry (dyskusja) 10:18, 28 sie 2018 (CEST)

Lista alfabetyczna w dwu kolumnach na dwu stronach

W Słowniku etymologicznym Brücknera jest alfabetyczny spis skrótów podany w dwu kolumnach, ale na tyle długi, że przechodzi na kolejną stronę. Tekst jest poprawnie przepisany i sprawdzony, ale po połączeniu obu stron (Słownik etymologiczny języka polskiego/Objaśnienie znaków i skróceń) rozsypuje się kolejność alfabetyczna na granicy stron. Czy zna ktoś może sposób na poprawę? Mnie przyszło do głowy jedynie danie tekstu w jednej kolumnie, ale ani to zgodne z oryginałem, ani niespecjalnie poręczne (tworzyłaby się bardzo długa a wąska kolumna). Będę wdzięczny za pomoc. Maitake (dyskusja) 22:19, 25 lip 2018 (CEST)

Z tego co widzę, Zdzislaw poprawił. Ankry (dyskusja) 09:24, 26 lip 2018 (CEST)

• Zaiste poprawił. Dziękuję bardzo. Maitake (dyskusja) 15:23, 27 lip 2018 (CEST)

Nowy gadżet Załaduj w tle skany następnej strony

Witam,
w preferencjach w sekcji Gadżety/Edycja stron dodany został nowy gadżet Załaduj w tle skany następnej strony. Gadżet ładuje w tle grafikę ze skanami następnej strony, kiedy tworzysz lub edytujesz stronę w przestrzeni Strona. Dzięki temu, kiedy przejdziesz do edycji kolejnej strony, skany wyświetlą się znacznie szybciej.
Gadżet szczególnie usprawnia pracę z nowymi indeksami, dla których na commons nie wygenerowane zostały jeszcze odpowiednie obrazy jpg dla poszczególnych stron (przy tworzeniu stron w nowym indeksie), co zazwyczaj dodatkowo zwiększa czas oczekiwania. W takim przypadku grafika zostanie także wygenerowana w tle na commons.
Proszę Użytkowników o testy, uwagi donośnie do ewentualnych problemów w funkcjonowaniu gadżetu oraz sugestie zmian. Zdzislaw (dyskusja) 21:27, 26 lip 2018 (CEST)

Wikiźródła:Wikiprojekt Proofread i limity, czyli puchnąca lista indeksów i co dalej

Dodając dzisiaj do listy kilka indeksów zauważyłem, że powoli, ale systematycznie, zbliżamy się do technicznego ograniczenia rozmiaru tej strony (obecnie rozmiar transkluzji 1 923 107/2 097 152 bajty). Oznacza to, że przy obecnej strukturze i technologii mamy miejsce na ok. 150-200 indeksów. Do końca roku pewnie wystarczy, ale co dalej? Generalnie, aby stronę odchudzić, należałoby usunąć z niej jakąś istotną część informacji, które są na niej zamieszczane przy ładowaniu strony (np. autor, tytuł, status indeksu). Informacje te mogłyby być dodawane później jakimś skryptem (@Zdzislaw?) po załadowaniu strony, ale to będzie trwać nawet kilka minut i obciążać przeglądarkę/sieć. Ewentualnie można stronę podzielić na kilka osobnych według jakiegoś ustalonego kryterium (alfabetyczne [np. A-P, Q-Ż], strukturalne [np. nie transkludujemy wydzielonych podstron], status [np. czerwone/żółte na osobną listę], wiek [starsze niż X lat na osobną listę] itp.). Niestety żadnego oczywistego i bezbolesnego kryterium nie widzę. Można też wywalić z listy całą otoczkę i zostawić "gołą" listę indeksów, jak na stronie Wikiźródła:Wikiprojekt Proofread skrócony, ale to tylko odwlekanie decyzji w czasie o kilka lat kosztem wygody (na tej ostatniej stronie jest jeszcze miejsce na ok. 500 indeksów). Alternatywnym rozwiązaniem jest "dyktatura" (@Bonvol), czyli wprowadzenie zasady, że nie dodajemy więcej indeksów do listy, niż z niej usunęliśmy. Zniechęcające dla wielu.

Uwagi? Komentarze? Propozycje?

Ankry (dyskusja) 10:41, 28 sie 2018 (CEST)

• "dyktaturę" sobie wypraszam, moje podejście jest bliżej "zrównoważonego rozwoju" (sustainable development), zwanego też "wedle stawu grobla". To zapobiega słomianemu zapałowi. Na pewno (@Matlin, @Ankry:) będę się sprzeciwiał modelowi niemieckich Wikiźródeł — jest po prostu zbyt restrykcyjny, ekstremalny i odstraszający. Ale wyjaśnię jeszcze raz publicznie moje stanowisko, dlaczego stoję za jakością, a nie ilością: projekty (u nas: indeksy) są po to, by je kończyć. Szczycimy się tym, że książki od nas są porównywane z oryginałem przez 3 osoby. Nie podcinajmy więc gałęzi na której siedzimy i uczciwie róbmy indeksy zielonymi! (zresztą pod koniec roku były już takie akcje). Ale nie jestem dyktatorem, po prostu będę robił swoje. Bonvol (dyskusja) 19:12, 28 sie 2018 (CEST)

Dyktatura nie, ale koordynacja? (Anagram16 (dyskusja) 00:11, 29 sie 2018 (CEST))

• Indeksy są uwierzytelniane, co prawda nie w tempie geometrycznym (wykres). Trzeba brać pod uwagę, że nie można kierować wikiskrybami jako zwartym i podporządkowanym (chociażby prawnie) zespołem. W związku z tym każdy, chociaż upowszechnia wyniki swojej pracy dla całej ludzkości, to pracuje na własny rachunek (w rozumieniu: przepisuje lub koryguje tyle, ile chce (ile mu na to pozwala zapał, zasób czasu i umiejętności), sam dla siebie wyznacza prakseologii. --Matlin (dyskusja) 20:05, 28 sie 2018 (CEST)

• Wydaje mi się, że naprostszym i najmniej "bolesnym" rozwiązaniem byłoby nie transkludowanie wydzielonych podstron, czyli tam gdzie jest osobna podstrona np. Wikiźródła:Wikiprojekt Proofread/Orzeszkowa dawanie tylko linku do niej. Salicyna (dyskusja) 11:13, 28 sie 2018 (CEST)
  • I mój głowny pomysł, też się na tym opiera. Idzie może nieco dalej: może by się dało zrobić skrypt, który te "podlinkowane strony" dociągnie i doklei do strony wyswietlanej po stronie użytkownika, tab by efekt końcowy był zbliżony do tego co mamy obecnie. Niestety, sam nie podejmę się tego zaimplementować a i takie rozwiązanie ma swój koszt. @Zdzislaw: co o tym myślisz? Ankry (dyskusja) 19:01, 28 sie 2018 (CEST)

• @Ankry:, oczywiście do zrobienia, jednak należałoby rozważyć najpierw aspekty związane z tym, że rozwiązanie pobierania w tle wielu stron i wklejania ich w stronę po stronie przeglądarki użytkownika, z zastosowaniem js, poza nieelegancją i postawieniem na głowie procesu generowania strony, ma, w mojej ocenie, jedną podstawową wadę, a mianowicie bezpieczeństwa takiego rozwiązania (ja wiem, że na pierwszy rzut oka wydaje się to przesadne). Wymagane byłyby rozwiązania to bezpieczeństwo zapewniające, oraz stałe monitorowanie pod kątem bezpieczeństwa. Doraźnie mógłbym zaproponować usunięcie z generowanych wierszy tabelki linku do stron dyskusji indeksów w kolumnie uwagi, które wg mnie niczego nie dają - zmniejszy to ciężar strony o 20%. Zdzislaw (dyskusja) 22:08, 28 sie 2018 (CEST)

• hmmmm u mnie pokazuje Rozmiar dołączonych elementów po ekspansji 1 923 107/2 097 152 bajty. @Ankry: czy aby na pewno dobrze zerknąłeś? Zdzislaw (dyskusja) 14:37, 28 sie 2018 (CEST)
  • rzeczywiście, przekleiłem liczby nie z tej strony. Ale pozostałe szacunki są dobre: nowy indeks daje na plus ok. 1kB; zwykle trochę mniej. Ankry (dyskusja) 19:01, 28 sie 2018 (CEST)
    • Minęło 40 dni i mamy 1 957 726/2 097 152. Wychodzi ETA na luty. Myślę, że warto omówić temat na zlocie. Ankry (dyskusja) 14:43, 7 paź 2018 (CEST)
• Łamiąc zasady, ale muszę: w niemieckich Wikiźródłach bardzo rygorystycznie podchodzi się do dodawania nowych indeksów. I one muszą mieć zadeklarowanych wikiskrybów (tutaj są zasady, także po angielsku). Ale nie wiem, czy dobrym pomysłem jest ograniczona swoboda dodawania. Oczywiście trzeba znać umiar i nie ma sensu dodawania projektów, które i tak będą puste, albo będą "wydmuszkami". Niemniej rygoryzm (nie licząc strony technicznej) to jest przywiązywanie dużej wagi do statystyki (% ukończonych indeksów) i pewne wymuszanie pracy nad rzeczami, która nas nie interesuje. Jeżeli mam interesujące skany na oku, ale aby je dodać, muszę "zazielenić" jakiś projekt, który niekoniecznie mnie interesuje, stawia mnie to w dyspozycji (nawet podświadomego) pośpiechu, a on z kolei może rodzić bylejakość. Reasumując chciałem stwierdzić, że moim zdaniem te ograniczenia powinny zostać wprowadzone tylko przy konieczności natury technicznej. --Matlin (dyskusja) 16:15, 28 sie 2018 (CEST) Dopisek Można np. zrobić szablon Szablon:Tabelka indeksu, który 'wyrywa' ze strony indeksu tytuł, autora i datę utworzenia strony Indeks:...; i na stronie Proofread wprowadzać tylko {{Tabelka indeksu... To by także uproszczało dodawanie indeksów. To, co napisałem, to luźna myśl, nawet nie jestem pewien, czy tak da się zrobić... --Matlin (dyskusja) 16:29, 28 sie 2018 (CEST)
  • Niemcy mają ograniczenie dodawania dużych indeksów (>100 stron). Małe rzeczywiście zwykle szybko schodzą. Z drugiej jednak strony taki przykład: gdy zaczynałem swoje działania z Kraszewskiem, nikt poza mną nie był nim zainteresowany (pomimo kilku deklaracji). Po pewnym czasie mi się znudził; jednak gdybym go wtedy nie dodał i nie przepisał, czy mielibyśmy kiedykolwiek tyle ukończonych jego tekstów? Chętni do korygowania znaleźli się po latach. Podobnie z Kościelną: nie ja ją wrzucałem, ale gdyby nie zrobił tego kto inny, na pewno nie przepisałbym ani jednego tomu. A tak, mam szansę ją przepisać do emerytury. Przykłady można mnożyć. Wg mnie zasada niemiecka jest dobra dla projektów rozmiaru Wikipedii, gdzie jest wielu użytkowników i zainteresowany losowo wybranym tematem zwykle się znajdzie. W małych projektech, gdzie zainteresowani tematem użytkownicy często mijają się znacznie w czasie (nawet o lata), taka zasada zabija projekt. Ankry (dyskusja) 19:01, 28 sie 2018 (CEST)
• ja proponuję najprostsze rozwiązanie, podzielić projekt sektory od [A do ...] ... [... do Z], przeszukiwanie czegoś dla siebie dalej będzie łatwe i ograniczy ilość klikania do minimum. Co do dyktatury nawet w jej minimalnej wersji to Wikiźródła są wolnym projektem i zawsze będę przeciwny jakimkolwiek ograniczeniom ilościowo/jakościowym, ostatnio patrzyłem na Polonę i planuję pobranie kilkunastu indeksów, chociaż postaram się ograniczyć ze względów o których rozmawiamy ;) @Ankry: jeżeli masz jakieś dojścia do Polony to porozmawiaj odnośnie Zbrodni i Kary dodali dwie części, druga jest dostępna a pierwsza zablokowana, chyba tylko ze względu na przedmowę, może da się udostępnić tylko tekst przetłumaczony bez przedmowy Nawider (dyskusja) 22:35, 28 sie 2018 (CEST)

Tak na marginesie, czy moglibyśmy się jakoś zorganizować w kwestii nowych indeksów Szekspira tak, żebyśmy sobie pomagali, a nie wchodzili sobie w paradę. Bo one na długo zagoszczą na liście. (Anagram16 (dyskusja) 01:03, 29 sie 2018 (CEST))

@Anagram16: Co do Szekspira, to ja raczej przepisywać będę tylko prozę, czyli przedmowy, życiorys poety - resztę będę tylko korygować. Salicyna (dyskusja) 10:16, 29 sie 2018 (CEST)

@Salicyna:, skoro wzięłaś na siebie tę trudniejszą, bardziej odpowiedzialną i niewdzięczną rolę, to przez grzeczność nie będę oponował. Sadzę, że razem z Wolanem dostarczymy Ci bardzo wiele stron do skorygowania. (Anagram16 (dyskusja) 10:22, 29 sie 2018 (CEST))

• Jeżeli strona Wikiźródła:Wikiprojekt Proofread miałaby zostać podzielona, to może w oparciu o ten podział, który już na niej jest. Tzn. na jednej stronie zostawić "Różne indeksy (nieposortowane)", "Indeksy w grupach tematycznych", "Indeksy wielojęzyczne i w wielu projektach" i "Indeksy niekompletne lub z problemami", czyli punkty 1, 2, 4 i 5 obecnego spisu treści, a na drugą wydzielić punkt 3 - "Indeksy według autorów". Himiltruda (dyskusja) 19:14, 29 sie 2018 (CEST)
• Właśnie pisałam coś podobnego co @Himiltruda: (Może na osobną stronę przenieść np. pkt. "Indeksy w grupach tematycznych", "Indeksy wielojęzyczne", czy "indeksy niekompletne i z problemami", zawsze dało by to troszkę więcej miejsca,przynajmniej tymczasowo:) Joanna Le (dyskusja) 19:27, 29 sie 2018 (CEST)
• Ja bym "odchudziła". Nie widzę potrzeby linkowania ze stroną autora ani ze stronami dyskusji, a jedynie z indeksem. Nie martwiłabym się na zapas... Myślę, że fajną alternatywą dla tej strony mogłaby być kategoria, w której by były wszystkie nie ukończone indeksy. Ale jeśli dzielić... intuicyjnie nie "łapię" podziału na grupy tematyczne... lepiej chyba alfabetycznie wg autorów. Wieralee (dyskusja) 20:49, 7 paź 2018 (CEST)

Words hyphenated across pages in Wikisource are now joined

Hi, this is a message by Can da Lua as discussed here for wikisource communities

The ProofreadPage extension can now join together a word that is split between a page and the next.

In the past, when a page was ending with "concat-" and the next page was beginning with "enation", the resulting transclusion would have been "concat- enation", and a special template like d:Q15630535 had to be used to obtain the word "concatenation".

Now the default behavior has changed: the hyphen at the end of a page is suppressed and in this case no space is inserted, so the result of the transclusion will be: "concatenation", without the need of a template. The "joiner" character is defined by default as "-" (the regular hyphen), but it is possible to change this. A template may still be needed to deal with particular cases when the hyphen needs to be preserved.

Please share this information with your community.

MediaWiki message delivery (dyskusja) 12:28, 30 wrz 2018 (CEST)

• Większość sytuacji typu "północo-" + "zachodni" już poprawiłem; Encyklopedia Kościelna nie wymaga uwagi: to jest wyłącznie czysty OCR. Na pozostałe przypadki dobrze, by ktoś zerknął drugą parą oczu. Odnośnie wierszy z pojedynczym minusem dodawanych kiedyś w okolicach znacznika <poem> przez Ashaio i Vearthy'ego czekam na wyjaśnienie, bo nie rozumiem co autorzy mieli na myśli; ale może ktoś z pozostałych skrybów wie? Ankry (dyskusja) 14:12, 30 wrz 2018 (CEST)

  @Ankry: Mógłbyś podać przykład jakiejś strony z tym pojedynczym minusem, bo nie kojarzę o co chodzi? Salicyna (dyskusja) 17:48, 30 wrz 2018 (CEST)

• @Salicyna: Ankry na pewno napisze więcej... lecz w dwóch słowach - strony kończące się przeniesieniem słowa, od teraz nie będą wymagać stosowania szablonów {{pp}} i {{pk}}. Po prostu zostawiamy urwany wyraz z minusem na końcu strony a parser połączy go w main automatycznie, co mnie niezmiernie cieszy. W związku z tym trzeba było się przyjrzeć występującym wyjątkom oraz nietypowym użyciem łącznika na końcu strony, takich jak tu i poprawić je aby parser nie potraktował ich jak przenoszenia wyrazów. Zdzislaw (dyskusja) 18:03, 30 wrz 2018 (CEST)

• Nie przypominam sobie, żebym specjalnie wstawiała myślnik na końcu strony w wierszach, chyba że przez pomyłkę (może to jakaś pozostałość OCRu?). Pamiętam, że kończyłam stronę sekwencją <br><poem> lub <poem><br> i to pomagało zachować równomierne odstępy między wierszami przy łączeniu stron. Ashaio (dyskusja) 08:03, 3 paź 2018 (CEST)

Do sprawdzenia (i ewentualnego poprawienia) jest kilkadziesiąt stron (lista). Ankry (dyskusja) 11:27, 3 paź 2018 (CEST)

@Ankry: Sprawdziłam strony z listy, poprawiłam te które tego wymagały. Natomiast te co pozostały do poprawy to strony w których szablon "pp" nie został zastosowany, ale na kolejnej stronie szablon "pk" już jest. Postaram się je również poprawić. Joanna Le (dyskusja) 17:50, 3 paź 2018 (CEST)

{{pp}}/{{pk}} i takie tam

W związku z pojawiającymi się na IRC-u pytaniami odnośnie mechanizmu łączenia stron wprowadzonego w poprzednim wątku vs. mechanizm dotychczasowy, chciałem przedstawić kilka uwag oraz propozycję.

• Po pierwsze, korzystanie z {{pp}}/{{pk}} ma jedną przewagę w stosunku do niekorzystania (pozostawienia niepołączonych fragmentów i łącznika): pozwala wyszukiwarkom znaleźć całe (połączone) słowo na obu stronach. Przynajmniej teoretycznie.
• Po drugie, podczas korekty stron zawierających fragmenty przenoszonego słowa oraz ww. szablony (lub bez szablonów) należy zawsze sprawdzić co jest na poprzedniej/następnej stronie (tu @Zdzislaw: może warto pomyśleć o jakimś narzędziu, które ułatwi w takim przypadku podgląd poprzedniej/następnej strony i/lub pokaże użycie szablonu {{pp}}/{{pk}} na stronie bez wchodzenia w tryb edycji? - np. w "dymku"). Dotyczy to także sytuacji, gdy nie dokonujemy korekty tej poprzedniej/następnej strony (ale zgodność użytego na nich mechanizmu przenoszenia wyrazów trzeba sprawdzić; @Anagram16:).
• Po trzecie, w przypadku objęcia szablonu {{pp}} ''kursywą'' lub '''pogrubieniem''' należy do treści objętej formatowaniem wiki dodać spację ('' {{pp|coś|-tam}}''). Wprawdzie użycie typu {{pp|''coś|-tam''}} czy {{pp|''coś|-tam}} też działa (ze względu na automatyczne domykanie znaczników wiki przez MediaWiki), ale użycie znaczników wiki w parametrach szablonu (zwłaszcza w tym drugim) jest problematyczne, gdyż parametry te są używane wewnątrz kodu HTML (ten drugi tylko tam), który nie rozumie znaczników wiki (i w efekcie powstaje HTML-owy koszmarek).

Wg moich testów na testowej wiki z ProofraedPage omawiany w poprzednim wątku nowy mechanizm łączenia wyrazów nie "psuje" elementów wikikodu takich, jak |- czy ---- jeśli występują na końcu strony. Natomiast co do łączenia tabelek: gdy nowa strona zaczyna się od nowej komórki: | cośtam zamiast nowego wiersza: |- to parser MediaWiki w interakcji z szablonami ProofreadPage numerującymi strony "psuje" efekt połączenia stron dodając atrybut "hidden" do całego pierwszego wiersza strony. Obejściem tego problemu jest dodanie przd znacznikiem nowej komórki tabeli (| tekst lub parametry) znacznika nowego wiersza (|-) lub użycie sekcji do łączenia tabelki (ale tu też są niuanse). Jest to efekt znany już od paru lat, który próbuję sukcesywnie poprawiać, gdy nań natrafię, niezwiązany z obecną zmianą. Być może "rozwiązaniem" problemu byłoby domyślne wyświetlanie numerów stron; ale nie wiem, czy tego chcemy.
Zwracam jednocześnie uwagę, że znaczniki wikitabelek {|, |-, |, |} nie powinny występować w pierwszym fizycznie wierszy strony (także: nagłówka/stopki), gdyż w wyniku interakcji ze znacznikami <noinclude> dodawanymi przez ProofreadPage powodują nieprawidłowe wyświetlanie zawartości (należy w takich sytuacjach po prostu dodawać przed nimi pusty wiersz).

• W związku z powyższymi uwagami proponuję, by dopuścić używanie obu mechanizmów łączenia wyrazów. Natomiast w sytuacjach spornych preferować {{pp}}/{{pk}} jako mechanizm o wyższej funkcjonalności. Zwracam także uwagę, że przy przenoszeniu wyrazów, gdzie wymagane jest zachowanie łącznika (np. "polsko-" / "francuski") i tak musimy nadal stosować pp/pk ({{pp|polsko|-francuski}} / {{pk|polsko-|francuski}}).

Ankry (dyskusja) 09:32, 8 paź 2018 (CEST)

Indeksy i informacje na stronach indeksów zamieszczone

Jak zapewne niektórzy z was zauważyli, zacząłem rozbudowywać strukturę indeksu o dodatkowe informacje. Mam nadzieję, że nie są to zmiany kontrowersyjne; a gdyby nawet były jestem otwarty na wszelkie sugestie i uwagi w szczególności odnośnie tego co już dodałem, co można by jeszcze dodać lub zmienić czy też kwestie nazewnictwa.

Zmiany, które zacząłem mają na celu: 1. umożliwienie generowania na podstawie indeksu danych o książce (jako {{Dane tekstu}}, informacje do ebuków czy też Dublin Core 2. kategoryzację indeksów ze względu na stopień zaawansowania (tu będą potrzebne jeszcze dodatkowe zmiany)

Na razie dodałem dodatkowe pola: Redaktor, Druk, Miejsce wydania, Status dodatkowy oraz rozbudowałem nieco drzewko kategorii indeksów.

Myślę, ze warto, by te i inne planowane zmiany w indeksach omówić na Źródłosłowie. Ankry (dyskusja) 02:48, 19 paź 2018 (CEST)

• Fajne by było (chociaż oszczędza to raczej sekundy, aniżeli minuty) generowanie tego opisu na podstawie samego pliku w Commons, a mianowicie szablonu Template:Book --Matlin (dyskusja) 10:38, 19 paź 2018 (CEST)

Łączenie tekstów z elementami Wikidanych

Zastanawiam się jak łączyć poprawnie teksty na naszych Wikiźródłach z odpowiednimi elementami Wikidanych, tak aby przede wszystkim aktualizowały się na bieżąco inne wersje językowe (chyba że robi to jakiś bot, ale nie wiem, na podstawie jakich informacji miałby to robić). Teraz już intuicyjnie pojmuję, że czym innym jest element np. Wikidata:Q846870, który mówi o oryginalnym wydaniu, a czym innym Wikidata:Q56155531, który jest danym wydaniem książki. Nie wiem tylko czemu moje edycje, dodające link do polskiego Wikisource są revertowane, natomiast nadal są w danym elemencie linki do innych wersji językowych Wikisource. Np. tutaj. Patrząc potem na efekt, widzę, że obcych wersji językowych nie ma. Można je dodać ręcznie, jak to zrobił w jednej edycji Ankry, lecz nie jestem pewien, czy to rozwiązuje problem zwarty w pierwszym zdaniu tego wpisu. Widzę też, że bardzo dużo tekstów jest teraz rozłączanych od elementów (przy takim filtrze ostatnich zmian należy spojrzeć na zmiany użytkownika Emaus). Wiem, że nie jest to typowo temat związany z Wikiźródłami, jednak po aktywności wikiskrybów także w Wikidanych mam nadzieję, że ktoś będzie wiedział, jak poprawnie to czynić. --Matlin (dyskusja) 15:59, 28 paź 2018 (CET)

Przede wszystkim trzeba utworzyć odpowiednie, dwustopniowe struktury w Wikidanych dla naszych tekstów, zgodnie z Wikiprojektem Books w wikidanych, który jest obowiązującym standardem dla tekstów na wszystkich Wikiźródłach. Proste dodawanie interwiki nie działa i jest bez sensu ze względu na wielość przekładów i wydań. Niestety, obawiam się, że przeniesienie wszystkich informacji ręcznie przez naszą społeczność przekracza nasze możliwości (pewnie musielibyśmy przez pół roku lub rok nic innego nie robić), dlatego nawiązując do wczorajszego wykładu PMG na Źródłosłowie, poprosiłem go o rozważenie wsparcia technicznego ze strony WMPL w tej sprawie. Na szybko, interwiki można robić po staremu, za pomocą odpowiednich wikilinków. Ankry (dyskusja) 16:18, 28 paź 2018 (CET)

Moi drodzy. Z racji tego że moja wiedza techniczna na temat połączenia Wikidanych z Wikiźródłami nie jest wystarczająca, przedstawiam was @Powerek38:. Powerek ma szeroką wiedzę z zakresu projektów, więc uważam że będzie mógł wam pomóc. Mam nadzieję że pomożecie mu swoją wiedzą. PMG (dyskusja) 11:20, 5 lis 2018 (CET)

• (@Matlin:, @Ankry:) Kłaniam się wszystkim. Faktycznie @PMG: w imieniu Zarządu WMPL poprosił mnie o pomoc Waszej społeczności we współpracy z Wikidanymi. Cieszę się z tego zadania bardzo, zwłaszcza że po zakończeniu mojej własnej kadencji w Zarządzie, Wikidane stały się zdecydowanie moim głównym polem aktywności w Wikimediach. Z drugiej strony, sam nie jestem wikiskrybą ani żadnym ekspertem od bibliotekoznawstwa, więc bardzo liczę na Waszą wiedzę merytoryczną. A przechodząc do konkretów, kilka moich uwag / pomysłów / wyjaśnień na dobry początek:

1. Na pewno zachęcam Was bardzo do dyskusji wewnątrz społeczności projektu na temat szablonu Kontrola autorytatywna. Widzę, że dotychczas jest tutaj zdecydowanie skromniejszy technicznie i rzadziej stosowany niż np. w polskojęzycznej Wikipedii. Osobiście uważam, że KA jest niezwykle przydatnym i ważnym narzędziem przy porządkowaniu i wpisywaniu w szerszy obieg bibliotekoznawczy zbiorów takich jak Wasze. Na Wikidanych mamy już ogromnie dużo oznaczeń KA, a ponadto mamy też mechanizmy pozwalające łatwo importować kolejne oznaczenia z baz zewnętrznych, zwłaszcza z VIAF. Krótko mówiąc: zachęcam do rozmowy, a chętnie przedstawię w niej konkretne propozycje.
2. Jeśli chodzi o przenoszenie Waszego dorobku do Wikidanych, to na pewno możemy zeskanować specjalnym narzędziem wszystkie Wasze szablony, a zwłaszcza infoboksy. Tą metodą moglibyśmy włączyć do Wikidanych np. daty czy miejsca urodzenia i śmierci autorów, które tu zebraliście. To zadanie mogę dość szybko wykonać ja, mam w tym sporą wprawę, choć niezbędne będzie do tego prawidłowe powiązanie stron Wikiźródeł z elementami WD.
3. Co do masowego tworzenia / wiązania elementów WD, najpopularniejszą metodą robienia tego jest na dzisiaj narzędzie, które nazywa się QuickStatements. Działa ono w ten sposób, że tworzy się plik w arkuszu kalkulacyjnym, tak naprawdę zwykłą tabelkę danych, a następnie, po eksporcie do pliku CSV, narzędzie masowo ładuje te dane do bazy WD. Mógłbym oczywiście pomóc ogarnąć to technicznie, natomiast pozostaje kwestia stworzenia jakiegoś zespołu, który np. na jakimś dysku sieciowym przygotuje dane w tabelce.
4. Napisałem o naszej współpracy na grupie najaktywniejszych edytorów WD na FB i już podrzucono mi kilka inspirujących linków: 1, 2, 3. Polecam Waszej uwadze.

Tyle mojego "expose", oczywiście jestem bardzo ciekawy Waszych poglądów, potrzeb, pomysłów itd. Postaram się zaglądać na tę stronę regularnie, a gdybyście życzyli sobie mojej obecności w innym miejscu, pingujcie szablonem. Powerek38 (dyskusja) 15:17, 5 lis 2018 (CET)

@Powerek38: Z kontrolą autorytatywną jest u nas tak, że samo wyświetlenie danych o autorze z Wikidata to nie problem. Natomiast inicjalny pomysł zakładał, że szablon kontroli autorytatywnej powinien również wyświetlać link do listy książek danego autora w bibliotekach cyfrowych, a przynajmniej w CBN Polona. Co, według mnie nie jest trywialne i dlatego zarzuciłem temat. Nikt inny go na razie nie podjął.

Dane o autorach w wikidanych w większości już są i ich uzupełnienie, o ile ważne, nie jest dla na s dużym problemem.

Problemem jest zamieszczenie danych o tekstach i ich organizacji oraz powiązanie tych danych z już dostępnymi danymi pochodzącymi z innych wikisource (w przypadku przekładów). Chodzi o to, że zgodnie z obowiązującym dla tekstów standardem (którym jest d:Wikidata:WikiProject Books) transfer tych informacji nie jest prosty dla przeciętnego redaktora Wikiźródeł (trzeba stworzyć dwa rekordy w wikidanych, odpowiednio je powiązać, i odpowiednio porozdzielać informacje pomiędzy nie, nie wspominając już o znalezieniu z czym je powiązać - np. rekordy wydawnictw, autorów, tłumaczy, języków itp.). Mój pomysł polega na tym, żeby ten proces jakoś (a) zautomatyzować w przypadku istniejących kilkudziesięciu tysięcy tekstów i/lub (b) stworzyć skrypt, który pobierze z odpowiednich stron Wikiźródeł (strona tekstu, spisu treści, indeksu) odpowiednie dane i po zatwierdzeniu przez użytkownika zapisze je w Wikidanych. Jedno i drugie jest niestety nietrywialne i nie ma u nas nikogo, kto mógłby chociaż spróbować coś takiego stworzyć. A jest nas po prostu za mało, by to wszystko wyklikać w Wikidanych ręcznie.

Większość potrzebnych danych już gdzieś na Wikiźródłach jest. Trzeba je tylko wyekstrahować. Być może możemy coś zrobić, aby ten proces ułatwić, ale nie wiedząc jak miałby przebiegać transfer, nie wiemy jak.

Inną sprawą jest, że niektóre kwestie w ramach tego Wikiprojektu są nadal dla mnie niejasne; np. nie mam pojęcia gdzie i w jakiej formie zapisać informację, że dany utwór jest wierszem, poematem, tomikiem poezji, antologią, powieścią lub nowelą. Albo jak należy powiązać utwory (współwydane: powieść i opowiadanie, wiersz zamieszczony w artykule naukowym, opowiadanie ze zbioru czy wiersz z tomiku lub antologii). Gdzie zamieścić informację identyfikującą wydanie, jeśli nie jest numeryczna (np. "szósty tysiąc" albo wydanie "nowe"). Ewentualnie gdzie w wikidanych szukać odpowiedzi na te pytania. Książki poza tym, że mogą zawierać wiele utworów (lub być ich częścią - tomy powieści - a czasem jedno i drugie na raz) mogą mieć kilku wydawców, kilku autorów itp. Dlatego zdaje sobie sprawę, że docelowo zadanie jest nietrywialne, ale od czegoś trzeba zacząć.

Wydaje mi się, że dobrze by było pogadać na ten temat online. IRC? Ankry (dyskusja) 16:12, 5 lis 2018 (CET)

@Ankry: Szczerze mówiąc nie jestem wielkim fanem dyskusji tego typu na IRC, bo ich log mało przejrzysty i stosunkowo trudno dostępny, a jednak mówimy o rzeczach ważnych chyba dla całej społeczności, więc proces powinien być transparentny. Można za to stworzyć tutaj coś w rodzaju dedykowanego wikiprojektu i dyskutować tam. A co do meritum Twojej wypowiedzi:

• Myślę, że to, o czym piszesz a propos automatycznego tworzenia elementów, wymagałoby dość skomplikowanego technicznie bota, na pewno znacznie powyżej moich umiejętności informatycznych. Pozwolę sobie przywołać tu @Yarl:a i @Masti:ego jako najbardziej "technicznych" członków Zarządu WMPL. Być może chłopaki będą miały pomysł, jak to ogarnąć, albo przynajmniej jak poszukać rozwiązania, być może korzystając ze środków finansowych WMPL.
• Niewątpliwie najlepszym miejscem na szczegółowe pytania co do edytowania na dany temat jest dyskusja wikiprojektu na Wikidanych. Proponowałbym tam zadać te pytania po angielsku. Na marginesie powiem, że jeśli użyje się na WD szablonów {p|XXXX} lub {q|XXXX}, gdzie XXXX jest numerem właściwości (P) lub elementu (Q), to każdemu wyświetli się jego etykieta we własnym języku, więc nie trzeba się martwić o terminologię.
• Co do Polony, można zaproponować stworzenie dedykowanej właściwości - identyfikatora w tej bazie. Podobnie dla innych bibliotek cyfrowych, nie jest to przesadnie trudne, tyle że wymaga akceptacji społeczności WD w trwającym tydzień głosowaniu. Oczywiście mogę w tym pomóc. Gdy takie właściwości zaistnieją, każdy projekt będzie mógł składać sobie z nich, jak z klocków, własne szablony itd. Powerek38 (dyskusja) 16:32, 5 lis 2018 (CET)

@Powerek38: Zacznę od końca: w przypadku polony chodzi obecnie o to, że nie widzę u nich możliwości wyszukiwania po autorze; może jest, tylko ja jestem ślepy? A może trzeba o tym doczytać w jakiejś dokumentacji jakiegoś API, do którego nie dotarłem. Kiedyś umiałem to zrobić; po ostatniej (ze 2 lata temu) zmianie softu w polonie nie umiem.

Co do transferu do wikidata: myślałem kiedyś, żeby zrobić to botem. I gdyby to było możliwe, to bym się pewnie tego podjął. Ale po przemyśleniach stwierdziłem, że ze względu na to, że w wikidanych sporo informacji już jest, często błędnych, robienie tego automatem, bez weryfikacji i zatwierdzenia jest ryzykowne. Dlatego, jeżeli robić to botem, musiałbym ten projekt z kimś znającym temat na bieżąco konsultować, żeby zminimalizować ryzyko błędów. Niestety nie mam z kim. I uważam, że nie da się tego robić on-wiki.

Dlatego uważam, że lepsze byłoby narzędzie interakcyjne, które pokaże co wpisuje/zmienia i pozwoli zatwierdzić. Lub nie zatwierdzić.

Jeśli masz inny pomysł jak to zrobić, wal śmiało.

Natomiast o wyklikaniu tego w obecnym GUI wikidanych zapomnij. Mamy ok. 30.000 niezależnych tekstów. Dla każdego trzeba utworzyć po dwa elementy (utwór "work" i wydanie "edition"). Żeby zrobić to dajmy na to w rok trzeba by tworzyć dzień w dzień po ok. 200 dziennie. Można przy tym zwariować. A 10 lat pracy nikt na to nie poświęci. Przyjmij, że ilość userów na wikiźródłach gotowych cokolwiek robić w wikidata oscyluje w granicach 1-5. Na ok. 20-25 aktywnych. Reszta może kliknie, jeśli dostaną guzik pt. "przenieś wszystkie informacje do wikidata".

Najprostszy przykład: masz 50 wierszy z jednego tomiku. Musisz utworzyć 2x50 elementów wzajemnie powiązanych odpowiednimi właściwościami, przy czym poszczególne pary będą się różnić tylko jedną z ok. 10 właściwości: tytułem. Jak to zrobić ergonomicznie. żeby pozostałych dziewięciu nie wpisywać po 50 razy? (a będą to różne: link do autora, może tłumacza, rok wydania, język, link do wydawcy, nazwa drukarni itp.).

Co do pytań: najtrudniej je zadać, gdy właśnie nie wiemy jakiej właściwości albo elementu użyć dla danego pojęcia lub kontekstu. A może po prostu właściwego nie ma? Ankry (dyskusja) 21:27, 5 lis 2018 (CET)

• @Ankry: Według strony pomocy Polony można wyszukiwać poszczególnych autorów. Na wskazanej przeze mnie stronie, u samej jej góry, wystarczy kliknąć w trójkącik skierowany w dół, znajdujący się pomiędzy okienkiem wyszukiwania a niebieską ikonką lupy. I tam się mieści wyszukiwanie zaawansowane. Ale może nie o to chodzi… Maitake (dyskusja) 21:37, 5 lis 2018 (CET)
  • Żeby pokazać Wam pewien kontekst w sprawie Polony lub innych bibliotek: ja jestem autorem (tzn. byłem pomysłodawcą i stworzyłem wniosek, zatwierdzony w głosowaniu) właściwości P5058, czyli identyfikatora osoby w bazie e-teatr.pl. Żeby stworzyć tego typu właściwość, potrzebujemy od architektury danej bazy tylko jednej rzeczy: aby dało się stworzyć wzór linku, w którym będziemy zaledwie podmieniać jakąś zmienną (czyli identyfikator) i w ten sposób będą powstawać linki do każdego rekordu. W przypadku wspomnianej właściwości wygląda on tak http://www.e-teatr.pl/pl/osoby/$1.html, gdzie $1 jest zmiennym identyfikatorem. Jeśli dostanę od Was coś takiego, reszta jest dość prosta technicznie, choć oczywiście musi zostać zatwierdzona przez społeczność WD. Jeśli w przypadku Polony jest to niemożliwe, to oczywiście wina leży już zupełnie poza Wikimediami. Powerek38 (dyskusja) 22:14, 5 lis 2018 (CET)
    • @Maitake: A udało ci się za pomocą tego mechanizmu utworzyć link do listy tekstów autorstwa Henryka Sienkiewicza (wyłącznie) z pominięciem tekstów innych autorów, zwłaszcza tekstów o Sienkiewiczu? Mi się nie udało. Ankry (dyskusja) 22:37, 5 lis 2018 (CET)
      • @Ankry: Musiałem kliknąć na menu, potem zbiory, potem z lewej strony w pozycji autor zaznaczyć checkbox przy Sienkiewiczu. Nie widzę, żeby wypluło coś innego, niż jego autorstwa. link --Matlin (dyskusja) 22:50, 5 lis 2018 (CET)

• się wtrącę, nic z tego, tylko poprzez filtr creator, https://polona.pl/search/?filters=creator:%22Sienkiewicz,_Henryk_(1846--1916)%22, z tym, że część może się także ukrywać w atrybucie contributor :)) Zdzislaw (dyskusja) 22:54, 5 lis 2018 (CET)

To, co ja zalinkowałem, daje ten sam rezultat, jeśli mierzyć go po liczbie zasobów, tylko pomija ten, który nie jest dostępny online (a więc o kilkadziesiąt wyników mniej) --Matlin (dyskusja) 23:04, 5 lis 2018 (CET)

@Powerek38: To jeden problem mamy jakby rozwiązany :) A co z danymi o tekstach zawartymi w {{Dane tekstu}} i indeksie? Jak je można przenieść do Wikidata? Ankry (dyskusja) 23:21, 5 lis 2018 (CET)

• Lin do właściwości "P5058:identyfikator osoby w bazie e-teatr.pl" w wikidanych, Link do innych "polskich" właściwości, link do dyskusji nad wprowadzeniem tego identyfikatora. PMG (dyskusja) 11:11, 6 lis 2018 (CET)

To teraz pytanie (do tego, kto wie): co daje przypisanie numeru Q do identyfikatora na e-teatr.pl albo na Polskim Słowniku Biograficznym poprzez narzędzie Mix'n'match? --Matlin (dyskusja) 12:27, 6 lis 2018 (CET)

Na Wikiźródłach jakiekolwiek powiązanie z serwisem e-teatr nie da dokładnie nic, jeśli o to chodziło. Raczej nie publikujemy informacji o aktorach; a jeśli nawet jakiś aktor był także pisarzem, to żadnych przydatnych dla Wikiźródeł informacji o nim w serwisie e-teatr nie znajdziemy. Linkować do e-teatru też raczej nie będziemy. Ankry (dyskusja) 14:04, 6 lis 2018 (CET)

@Ankry:: Podałem przykład e-teatru, żebyście zobaczyli (ci z Was, którzy dotąd nie wiedzieli) jak na WD tworzy się identyfikatory zewnętrzne. Liczyłem, że dzięki temu łatwiej będzie stworzyć identyfikator np. dla Polony. Muszę popracować chwilę nad tym, co padło wyżej, ale być może mamy już dobry trop. Postaram się wkrótce przygotować zgłoszenie takiej nowej właściwości i poddać je obowiązkowej procedurze zatwierdzenia przez społeczność WD. @Matlin:: Mix'n'Match jest narzędziem wspomagającym wprowadzanie do WD identyfikatorów zewnętrznych. Co to daje? Dla odbiorcy wiedzy - możliwość błyskawicznego przechodzenia, traktując WD jako swego rodzaju indeks czy bramkę, między różnymi bazami opisującymi tę samą osobę, co przydaje się, gdy szukamy o niej wiedzy. Dodatkowo wikimedianom daje to możliwość w dużej mierze zautomatyzowanego wyświetlania tych identyfikatorów na stronach projektów (Wikipedii, Wikiźródeł itd.) na zasadzie kontroli autorytatywnej lub linków zewnętrznych. Wystarczy wtedy do tego relatywnie prosty szablon. Powerek38 (dyskusja) 14:27, 6 lis 2018 (CET)

Natomiast, wracając do meritum wątku: mam wrażenie, że ciągle jesteśmy w punkcie wyjścia. Nadal nie wiemy, jak przenieść istniejące w Wikiźródłach w szablonie {{Dane tekstu}} i indeksie stron informacje do Wikidanych nie przepisując ich i nie klikając kilkadziesiąt razy per strona (najlepiej, gdyby to był pełny automat lub mechanizm jedno- lub dwukliknięciowy). @Powerek38, @PMG: jakieś pomysły, sugestie? Czy zostawiamy zagadnienie przyszłym pokoleniom? O ile ja, Matlin czy Zdzislaw sobie z ręcznym przenoszeniem danych poradzimy, o tyle dla większości bez precyzyjnej instrukcji typu: klinknij tu, sprawdź czy nie ma bzdur i jeśli nie ma to zatwierdź, a jeśli są, poproś kogoś o pomoc będzie to problem, z którym sobie nie poradzą. A i to dotyczyłoby tylko bieżących informacji o nowych tekstach. Armii klonów do przeniesienia informacji o wcześniej wprowadzonych tekstach, często przez skrybów, których u nas już nie ma, nigdzie nie widzę. Ankry (dyskusja) 14:04, 6 lis 2018 (CET)

Nie ma potrzeby przenoszenia tych danych ręcznie, jest do tego narzędzie. Istota problemu jest inna. Jak padło już wyżej, doszło do zupełnego pomieszania dzieł literackich z ich konkretnymi wydaniami, przynajmniej jeśli chodzi o powiązanie elementów WD ze stronami Wikiźródeł. Tu jest największy problem i myślę, że to wymaga roboty w jakimś stopniu ręcznej, co najwyżej wspomaganej narzędziami typu QuickStatements. Musimy doprowadzić do sytuacji, gdy te powiązania będą prawidłowe i moim zdaniem od tego cały proces musi się zacząć. Bo gdybym dzisiaj puścił narzędzie skanujące np. {{Dane tekstu}}, to ono by sobie w dużej mierze poradziło z szablonem tutaj, ale po stronie WD wpisałoby te dane do błędnych elementów. Zamierzam w miarę możliwości zabrać się za to sprzątanie, poprosiłem już Yarla o pewne wsparcie techniczne, żeby szło to nieco szybciej. Jeśli ktoś ma chęć pracować dla Wikiźródeł, ale w obrębie Wikidanych, zachęcam np. do tego, żeby po kolei lecieć po tej liście i sprawdzać prawidłowość powiązania elementu oraz tworzyć elementy konkretnych wydań. Powerek38 (dyskusja) 14:20, 6 lis 2018 (CET)

Akurat to są szczegóły techniczne, z którymi można sobie poradzić.

1. większość elementów wikidanych przypisanych do Wikiźródeł jest po prostu pusta, zrobiona przez jakiegoś bota.
2. przypadki, gdy mamy powiązania z innymi Wikisource bym w ogóle na razie zostawił; raczej do obróbki ręcznej.
3. przypadki gdy mamy powiązania z Wikipedią i/lub np. cytatatmi są albo:
   1. totalnie błędne - jeśli artykuł w Wikipedii nie dotyczy dzieła literackiego – trzeba odlinkować i utworzyć parę nowych elementów Wikidanych
   2. elementy typu "work" - jeśli artykuł w Wikipedii dotyczy dzieła literackiego – też trzeba odlinkować i utworzyć nowy element dla wydania.

... itd. Ale mam wątpliwości, czy projektowanie takiego algorytmu na wiki to dobre podejście.

Kolejna sprawa, to że najlepiej zacząć od tekstów autorów polskich (na stronie autora szablon Autorinfo nie będzie miał parametru "kod" lub będzie on pusty. Szanse, że będą jakiekolwiek powiązania interwiki będą małe.

Ankry (dyskusja) 14:59, 6 lis 2018 (CET)

Wygenerowałem (uwaga, może ładować się nawet 2-3 minuty) listę stron polskich Wikiźródeł, na których jest {{Dane tekstu}}, ale zarazem nie mają one w ogóle wartości P31 (czyli "jest to...") w Wikidanych lub jest to wartość inna niż Q3331189 (czyli wydanie). Mogę to wyciągnąć również w postaci tabelki CSV. Jeżeli mamy mówić o konkretach: trzeba się zastanowić, ale to jest pytanie wybitnie do skrybów, czy faktycznie wszystkie te strony dotyczą wydań. Jeśli tak, można w zautomatyzowany sposób (w oparciu o pliki CSV i narzędzie QuickStatements) dokonać w WD masowych zmian. Jeśli nie, trzeba podzielić to na mniejsze grupy, wg kryterium wartości, jaką ma dla tych elementów przyjąć właściwość P31. Mam nadzieję, że nie piszę zbyt technicznie. Dla mnie to jest etap 1 sprzątania powiązań Wikidane / Wikiźródła. Powerek38 (dyskusja) 15:53, 6 lis 2018 (CET)

• I tu powraca pytanie, które powinno zostać postawione na wstępie tej dyskusji... Jak definiujemy samodzielne dzieło (wydanie)?? Czy na poziomie indeksu (pozycji książkowej), czy rozdziału??, czy pojedynczego wiersza?..., czy Wybór dramatów/Wstęp. Rys biograficzny powinno mieć rekord w WD? Zdzislaw (dyskusja) 17:40, 6 lis 2018 (CET)

@Powerek38: Dzięki za listę. @Zdzislaw: powinno być postawione i powinniśmy sobie na nie odpowiedzieć, ale uważam, że niekoniecznie dyskusja musi wstrzymywać dalsze działania. Możemy znaleźć niekontrowersyjny podzbiór, na którym przećwiczymy technologię transferu danych. A później tę technologię zastosujemy do innych tekstów. Albo nie zastosujemy: w zależności od wyniku dyskusji.

Sądzę, że na początek powinniśmy odrzucić wszystkie hasła słownikowe, typu "SJP:<coś tam>", artykuły Encyklopedii Muzycznej ("Encyklopedia Muzyczna PWM/*") oraz rozdziały powieści (te można rozpoznać po tym, że w {{Dane tekstu}} nie posiadają wypełnionego pola pochodzenie). Można by też na początek wyeliminować wszystkie podstrony (jeśli tak będzie prościej; ale tu uwaga: nie tylko podstrony, bo wspomniane hasła SJP podstronami nie są). Inna sprawa, że wiele podstron (wiersze Asnyka, fraszki Kochanowskiego jest podstronami przez pewną zaszłość i prędzej czy później powinny one został przeniesione na główny poziom nazewnictwa wg schematu "Fraszka X (Kochanowski, rok)").

Wracając do pytania Zdzislawa: uważam, że w Wikidanych powinno być jak najwięcej informacji o strukturze zawartości naszego projektu. Dlatego, jeśli mamy wiersz X autora Y w wersjach (a) z gazety, (b) z autorskiego tomiku, (c) z antologii to powinniśmy utworzyć dla wszystkich trzech tekstów elementy Q3331189 (wydanie) i powiązać je (1) z utworzonym elementem utworu-wiersza oraz z (2) odpowiednimi elementami Q3331189 (wydanie) dla tomiku poezji i antologii (być może też dla numeru gazety, acz tu niekoniecznie gdyż wiele wydań tego samego numeru gazety jest mało prawdopodobne). Tak przynajmniej rozumiem rolę elementu Q3331189 i liczę, że Powerek38 mnie skoryguje, jeśli rozumiem ją opacznie. Natomiast wracając jeszcze raz do prawdopodobnej przyczyny pytania Zdzislawa: wcale nie uważam, że wszystko co się znajdzie w WD musi trafić do jakiegoś katalogu i z nim do BC. Jest to wg mnie temat na zupełnie odrębną dyskusję.

@Powerek38: czy mógłbyś sporządzić również listę różnych wartości jakie przyjmuje P31 dla tekstów z twojej listy? Myślę, że przyjrzenie się jej pozwoliłoby wyłapać ewentualne "bzdurne" rekordy (jak np. podlinkowany kiedyś przez jakiś automat Bagno (Ostrowska, 1902) (wtedy po prostu jako Bagno) do w:Bagno). Ankry (dyskusja) 19:46, 6 lis 2018 (CET)

@Ankry:: Na moją prośbę Yarl przygotował bardzo ciekawe zestawienie, pokazujące, jakie wartości P31 i w jakiej ilości można spotkać w polskich Wikiźródłach. Ze swojej strony dodatkowo służę listą wszystkich stron Wikiźródeł posiadających właściwość P31 wraz ze wskazaniem jej wartości. Mam nadzieję, że to pomoże. W kwestii technicznej - w obu przypadkach trzeba nacisnąć ikonkę "play" po lewej stronie i poczekać na wyniki. Powerek38 (dyskusja) 20:57, 6 lis 2018 (CET)

@Powerek38: Bardzo przydatne zestawienie, dzięki @Yarl. Pousuwałem powiązania naszych tekstów z różnymi miastami, wioskami, rzekami czy obiektami leżącymi z sferze zainteresowania paleologii. Zostało jeszcze parę wymagających wyjaśnienia, ale o tym gdzie indziej. W chwili obecnej, po dyskusji na IRC-u, sugerowalibyśmy by się zająć stronami:

• z pominięciem podstron ("/" w nazwie) oraz z pominięciem stron z ":" w nazwie
• z pominięciem stron posiadających linki do innych projektów Wikisource (obrabianie ich automatyczne uważam za ryzykowne; lepiej zająć się nimi ręcznie)

Chciałem zwrócić też uwagę na jeszcze jedną kwestię. Zgodnie z założeniami wikiprojektu Books: Works should be instances of utwór pisany (Q47461344) or one of its subclasses i Editions should be instances of wydanie (Q3331189) or one of its subclasses. Natomiast w zasadzie strony dotyczące różnego rodzaju aktów prawnych (ustawy, umowy międzynarodowe), jak też sztuk teatralnych wydają mi się nie być przypisanymi do żadnej z podklas wskazanych wyżej klas. Możesz zweryfikować? Jakieś sugestie? Ankry (dyskusja) 01:05, 7 lis 2018 (CET)

• • Widocznie to nie jest objęte tym wikiprojektem. Mówi on tylko o książkach. --Wargo (dyskusja) 20:45, 7 lis 2018 (CET)
    • @Wargo: jest objęte. On mówi o utworach ("works"). Poza tym dokumenty o charakterze prawnym też bywają wydawane w postaci książek (przykład, drugi). Jaką wartość P31 byś sugerował dla abstrakcyjnych elementów Wikidata ("works"), odnoszących się do tych tekstów i ich przekładów na różne języki, a wywodzącego się z Q47461344? Na wikiźródłach czy Commons pod pojęciem "książki" mieści się dowolny (wielostronicowy) dokument piśmienniczy, dla którego można określić dane bibliograficzne. Ankry (dyskusja) 21:59, 7 lis 2018 (CET)

@Wargo, @Ankry: A nie może być np. Q47461344? Opis tego elementu: dowolny utwór w formie pisemnej, taki jak: inskrypcja, rękopis, dokument lub mapa. Czyli np. Konstytucja RP (jako works) jest to utwór pisany? Z zastrzeżeniem, że dobrze rozumiem na czym polega trudność. Jeżeli źle zrozumiałem to zignorować. --Matlin (dyskusja) 22:37, 7 lis 2018 (CET)

• @Matlin: Q47461344 zawsze można dopisać. Natomiast jeśli byłoby to jedyną wartością, to prędzej czy później ktoś zdecyduje się "uszczegółowić". Po to są bardziej szczegółowe podklasy, żeby tych najbardziej ogólnych nie używać bezpośrednio. Dodanie tego elementu jako P31 jest trochę podobne do dodania do elementu jakiegoś autora informacji oprócz tego, że jest to "człowiek", że jest to także "forma białkowa" lub "organizm wielokomórkowy". Trochę absurdalne. Ankry (dyskusja) 22:52, 7 lis 2018 (CET)
• @Ankry: To prawda. W reasonator widzę, że w powiązanych elementach m. in. Książka jest podklasą dla 'Utwór pisany' - jeśli dobrze rozumiem fragment of its subclasses. Pozostałe powiązane elementy, np. dzieło literackie, inskrypcja raczej nie pasuje. --Matlin (dyskusja) 19:40, 8 lis 2018 (CET)
• @Matlin: obawiam się, że to narzędzie nie podaje pełnego drzewa hierarchii podklas. Np. nie mogę z niego wyklikać: utwór pisany (Q47461344) -> dzieło literackie (Q7725634) -> fikcja literacka (Q38072107) -> powieść (Q8261). Niestety nie wiem, jak w przystępny sposób uzyskać i przejrzeć pełne drzewo podklas wybranej klasy. Może @Powerek38: coś doradzi? Ankry (dyskusja) 20:58, 8 lis 2018 (CET)
• Obawiam się, że to co jest wynikiem tej dyskusji, tzn. usuwanie bezpośrednich powiązań w WD pomiędzy tekstami z innymi wersjami językowymi ws i zamiana na wydanie, a w zamian wstawianie ręcznych iw na naszych źródłach, to wylewanie dziecka z kąpielą i w mojej ocenie szkodliwe działanie dla projektu. Dlaczego? Otóż, w ten sposób tracimy link iw po drugiej stronie, tzn na stronie danego tekstu w enws czy rfws, i pośrednio osłabiamy widoczności naszego tekstu dla wyszukiwarek, a w konsekwencji w wynikach wyszukiwania. Takie zmiany miałyby sens, po przygotowaniu podłoża, gdyby realizowane były także przez inne wersje językowe, wraz ze zmianą mechanizmu wyświetlania linków iw dla ws. I nie da tutaj nic generator w formie nakładki js (tak jak robi to jeden z projektów), ponieważ roboty i tak tego nie widzą. Zdzislaw (dyskusja) 20:22, 9 lis 2018 (CET)
  • @Zdzislaw: Ależ właśnie inne wersje językowe to robią. Wprawdzie ręcznie, ale robią. I "niszczą" w ten sposób istniejące interwiki. Uważam, że w takich sytuacjach należałoby odtworzyć interwiki starego typu. Miałem nawet swego czasu starcie w tej sprawie na Wikidata. Ze względu na to, że nie wierzę, by automat zrobił to dobrze, sugerowałem wyżej (patrz pkt. 2), by przynajmniej na początku pominąć strony z interwiki do innych Wikisource. Być może w n-tym podejściu uda się stworzyć automat, który sobie z tym poradzi, a być może trzeba będzie to zrobić ręcznie. Ankry (dyskusja) 21:29, 9 lis 2018 (CET)
    • @Zdzislaw:, @Ankry:: Przede wszystkim musicie mieć świadomość, że nie zawrócicie kijem Wisły. To nie jest tak, że społeczność polskojęzycznych Wikiźródeł może odmówić współpracy z Wikidanymi i to zatrzyma zmiany. Tym bardziej, że te wszystkie edycje i zmiany dzieją się tam, a nie tutaj. Podczas Waszego spotkania z @PMG: na Źródłosłowie niejako zaprosiliście WMPL (jak rozumiem), by postarało się wesprzeć ten proces, ale nawet bez tego zaproszenia to i tak by się zdarzyło, to była tylko kwestia czasu, bo WD są projektem niezwykle ważnym dla Fundacji Wikimedia, Wikimedia Deutschland (największego na świecie lokalnego partnera WMF) i dla kilku dużych instytucjonalnych sponsorów Fundacji. Wikidane będą w coraz większym stopniu swego rodzaju kręgosłupem Wikimediów i tego się nie zatrzyma, można co najwyżej angażować się na WD lub na Meta w różne dyskusje i współkształtować kierunek, w jakim to idzie. A mówię to dlatego, że dopóki na WD są w tej sprawie zasady takie, jakie są, to próby powrotu do starego systemu mają duże szanse na rewerty. Zresztą moim skromnym zdaniem nawet czysto merytorycznie prawdą jest, że publikowane tutaj teksty są często jakimiś wersjami swoich oryginałów, zwłaszcza w przypadku prac obcojęzycznych. Sami zresztą pewnie wiecie to lepiej niż ja. Posprzątałem dotychczas elementy kilkudziesięciu tekstów i np. zajęło mi dobrych kilka minut ustalenie, które to dzieło Verne'a kryje się pod polską adaptacją figurującą tutaj jako Anioł kopalni węgla. Krótko mówiąc sądzę, że rzetelność i merytoryczna poprawność powinny być w Wikimediach ważniejsze od pozycjonowania. Powerek38 (dyskusja) 18:51, 13 lis 2018 (CET)
      • @Powerek38: Ależ my wcale nie zamierzamy niczego zawracać. Chcemy wykorzystać możliwości, które ten projekt mógłby dać. Ale trzeba wziąć pod uwagę dwie rzeczy: (1) żeby skrybowie zaczęli wrzucać dane z Wikiźródeł do WD muszą naocznie się przekonać, że Wikiźródła na tym jakoś skorzystają (a co tak naprawdę w odniesieniu do tekstów mogło być do WŹ z WD pobierane, a czego jeszcze w WŹ nie ma, poza interwiki? Głos Zdzislawa odbieram właśnie jako taki sceptycyzm odnośnie potencjalnych korzyści dla projektu); oraz (2) większość społeczności WŹ jest słabo zaawansowana technicznie, wielu nawet nie radzi sobie z tworzeniem stron w main czy wypełnianiem szablonu {{Dane tekstu}} (a prawdę mówiąc, nawet ja miałbym problem z określeniem wydawcy na podstawie treści typu: "Nakładem autora; druk W. L. Anczyca i Spółki pod zarządem Iksińskiego; Kraków: Skład główny w Księgarni Gebethnera; Warszawa: Gebethner i Wolff". Dlatego 50% skrybów nic do Wikidanych nie przeniesie, jeśli nie będą mogli tego zrobić (przynajmniej w podstawowym zakresie) jednym kliknięciem. Z drugiej strony, niektórzy pamiętają, że wprowadzenie Wikidanych wiązało się ze stopniową destrukcję interwiki Wikiźródeł: po pierwsze, przed ich wprowadzeniem działały statyczne "stare" interwiki wielokrotne, podobne do widocznych na tej stronie (m.in. 12 en, 3 pl i 4 cs); po drugie, po uruchomieniu WD, wiele botów (ale też użytkowników z innych wiki) zaczęło przerzucać linki interwiki do WD, ignorując zwracane uwagi, że jest to bez sensu; po czym inni użytkownicy "porządkujący" informacje w WD, rozdzielili elementy i interwiki zniknęły całkiem.

Osobiście widzę pewien potencjał, jaki mogą stanowić WikiDane dla Wikiźródeł (jako baza dla interwiki i jako źródło dla katalogu tekstów). Natomiast, aby się dało go wykorzystać, trzeba przekroczyć pewna "masę krytyczną" informacji. Zniechęcająca jest też konieczność klikania na każdym polu: przydałby się mechanizm zautomatyzowania pewnych czynności, np. wyboru podstawowych właściwości, które należy wypełnić dla tekstu czy choćby wypełnienia pól jakimiś podpowiedziami w oparciu o to, co jest już na WŹ. Także tworzenie relacji wzajemnych ("work"<->"edition" czy część<->całość) mogłoby być prostsze i oparte na pojedynczej edycji, a nie na błądzeniu po dwóch elementach. Myślę, że można by też stworzyć pewne katalogi, np. katalog wydawców, które mogłyby ułatwić pewne wybory. Tyle, że nie znając narzędzi, które mogłyby pomóc zautomatyzować pewne procesy, nie wiem jak się za to zabrać i błądzę po omacku rzucając propozycje, o których nie mam pojęcia czy są realizowalne.

Myślę, że należałoby się zastanowić nad zagadnieniami typu: "jak utworzyć od zera możliwie wypełniony element WD dla nowego tekstu wykonując nie więcej niż, dajmy na to, 10 operacji (typu klikniecie myszą, naciśnięcie klawisza, czy zaznaczenie tekstu)". Bardziej skomplikowane algorytmy możemy tworzyć dla botów i ich operatorów, ale nie dla przeciętnego skryby. Krótko mówiąc: link w menu bocznym WŹ pt. "utwórz nowy element WD" kierujący do formularza z wybranymi, predefiniowanymi polami, wypełnionymi w oparciu o dostępne dane z (a) Danych tekstu (b) strony indeksu, na której dany tekst bazuje, ew. jakież listy wyboru umożliwiające poprawienie tych danych w oparciu o informacje zawarte w WD lub predefiniowane listy oraz przycisk "Zatwierdź". Tyle, że ja nie wiem, jak się technicznie za coś takiego zabrać :( Ankry (dyskusja) 00:16, 14 lis 2018 (CET)

Jak to kiedyś napisała Magda Gessler: moni (sic!) mili, tu trochę trzeba na chwilę odejść od głównego wątku: myślę, że jeżeli wszystkie strony pomocy zostaną uaktualnione, jeżeli wszystkie niepisane zasady i zasady tworzone ad-hoc nie zostaną przedyskutowane, ustalone i zapisane, to tych wikiskrybów, dysponujących umiejętnościami technicznymi nie przybędzie, bo osoba, która nawet chce się czegoś nauczyć: z czego ma czerpać wiedzę?

1. Musi naśladować działania tych doświadczonych wikiskrybów (na przykład zobaczyć, jak inna osoba zastosowała szablon) - ma to tę wadę, że mechanizm wiki jest do bólu elastyczny i nie zawsze da się zastosować daną metodę bez żadnych ubytków.
2. Musi przekopywać się przez dyskusje i inne strony: czytaj to w ten sposób: musi być obyty ze skryptorium, musi przeglądać strony książek i patrzeć, jak tam dane zagadnienie zrealizowano.
3. Musi w końcu czasem zrobić coś na oślep, bo nie do końca rozumie dany mechanizm (jakie powoduje skutki, dlaczego trzeba zastosować to albo tamto): ale wtedy jest ryzyko, że dostanie l*nie po d*pie, a ono bardzo boli od niektórych osób.
4. Oczywiście część zagadnień jest spisana w pomocy, czasem dostatecznie (i po prostu popełniane są błędy z lenistwa czy pójścia na łatwiznę), a czasem zbyt ogólnie lub bez odniesienia do obecnych mechanizmów.

Dlatego uważam tak, jak w pierwszych zdaniach (prakseologicznych) tej wypowiedzi, dodając, że spisanie jasnych zasad postępowania (nie unikając czasem kazuistyki) spowodowałoby, że mniej osób obawiałoby się działań tzw. technicznych :-) --Matlin (dyskusja) 10:21, 14 lis 2018 (CET)

Właściwość WD dla Polony

Drodzy Skrybowie, po tej ogólnej dyskusji przystępuję powoli (powoli, bo niestety mam do połowy grudnia wyjątkowo dużo obowiązków zawodowych, o czym uczciwie uprzedziłem Zarząd WMPL, podejmując się współpracy z Wami) do konkretnych działań. Jako pierwsze z nich chciałbym zrealizować złożenie wniosku do społeczności Wikidanych o utworzenie nowej właściwości, o której dyskutowaliśmy wyżej - identyfikatora autora w bazie Polony. Bardzo byście mi ułatwili zadanie, gdybyście mogli podać mi następujące informacje:

• wzór linku do bazy dla przykładowego rekordu, z zaznaczeniem części stałej i zmiennego identyfikatora w linku (już o tym gadaliśmy powyżej, ale proszę o dokładne sprawdzenie, czy to działa);
• przypuszczalną liczbę encyklopedycznych rekordów w tej bazie;
• wyrażenie regularne (np. ^[1-9]\d{0,2}$) opisujące zakres, w jakim będą się mieściły zmienne identyfikatory.

Z góry dziękuję. Powerek38 (dyskusja) 13:33, 8 lis 2018 (CET)

Tutaj może być problem (a może się mylę), linki do polony wyglądałyby następująco https://polona.pl/items/?filters=creator:%22Sienkiewicz,_Henryk_(1846--1916)%22, lecz z identyfikatorem może być problem, może on przyjmować postać "Imię,_Nazwisko_(rok*--rok†)", jak również, wiele innych odmian, np. w przypadku, gdy rok śmierci lub urodzenia jest nieznany "Imię,_Nazwisko_(rok*--_)",... aż do przypadków gdy żadna z dat jest nieznana, np. "Imię1,_Imię2_Nazwisko" (https://polona.pl/items/?filters=creator:%22Wr%C3%B3blewski,_Jan_Tadeusz%22)... zmienna liczba członów, raz z przecinkiem, raz bez. Nie ma także gwarancji, że dany identyfikator nie zmieni się z czasem, np. gdy zostanie ujawniona data śmierci. Tak więc regexp dla zmiennej części identyfikatora, to /^.+$/ :))), Zdzislaw (dyskusja) 20:16, 8 lis 2018 (CET)

Dodam, że w nawiasie może być co innego niż daty, np https://polona.pl/items/?filters=creator:%22Go%C5%82%C4%99biowski,_S%C5%82awomir_(teologia)%22. Chyba jedyne co jest w miarę pewne, to że identyfikator zaczyna się od wielkiej litery alfabetu łacińskiego (ale może być ze znakami diakrytycznymi).

Ręczne sprzątanie powiązań

@PMG: poprosił mnie parę dni temu o wrzucenie gdzieś instrukcji czy też opisu, co właściwie robię, gdy ręcznie sprzątam powiązania Wikiźródeł i Wikidanych (a w wolnych chwilach ostatnio trochę się tym zajmuję). Gdyby ktoś jeszcze chciał się z tym zapoznać, zostawiam tutaj. Oczywiście prace te można by też wykonywać półautomatycznie, ale póki nie powstaną stosowne narzędzia, można bawić się też tak. Powerek38 (dyskusja) 17:38, 12 lis 2018 (CET)

>>Duplikuj<<, przełomowa funkcja na Źródłach

Dobry, na stronach naszych indeksów zaimplementowałem zapowiadaną podczas Źródłosłowu nową opcję pozwalającą (jednym kliknięciem) na rozpoczęcie tworzenia nowej strony automatycznie wypełnionej treścią ze źródłowej. Nie udało się jej zaimplementować (choć powstawała w kuluarach) podczas samego zlotu, z prozaicznego powodu - poprzednie punkty programu i żarliwa dyskusja wypełniła cały dostępny czas naszych sesji. Lecz, co się odwlecze... i jest :) Na razie można z niej korzystać podczas tworzenia nowych indeksów w przestrzeni Indeks:, na podstawie danych pobieranych z już istniejących. Proszę tutaj o uwagi i opinie. Pozdrawiam, Zdzislaw (dyskusja) 21:40, 28 paź 2018 (CET)

Wyłączyłem w CSS widoczność tej funkcji dla nie-redaktorów. Niezalogowanych czytelników raczej rozprasza, niż stanowi dla nich pożyteczny element, a początkującym tez raczej się nie przyda. Ankry (dyskusja) 18:18, 27 gru 2018 (CET)

Generator linków

Zmodyfikowałem troszkę gadżet Generator linków, rozszerzając nieco jego możliwości (generowanie nazw stron bez zer w numerach, czy uwzględnienie przesunięcia fizycznej numeracji w książce względem numeracji stron w pliku. Gadżet rzadko używany, niemniej proszę o ewentualne uwagi. Ankry (dyskusja) 10:19, 30 paź 2018 (CET)

rezerwacja

@Zdzislaw, @Wieralee, @Rosewood, @Anwar2:@PMG, @Masti: Podobno na Źródłosłowie była omawiana kwestia wprowadzenia/implementacji rezerwacji indeksów. Czy ktoś mógłby podsumować tamtejszą dyskusję? (sugerujemy wprowadzenie w taki sposób..., nie implementujemy bo..., pojawiły się następujące opinie i wątpliwości..., itp...) Ankry (dyskusja) 19:18, 30 paź 2018 (CET)

Mnie przy tym nie było, widocznie byłem w innej sali. PMG (dyskusja) 19:29, 30 paź 2018 (CET)

Omawiana, to za dużo powiedziane, poruszyliśmy jedynie tę kwestię już poza samą sesją, jedynie w kontekściem możliwych problemów z osobami, które nagminnie odrezerwowałyby indeksy w toku, jako iż opcja rezerwacji stanowić ma jedynie funkcję informacyjną, nie restrykcyjną, i jako taka, może być przez każdego dowolnie wyłączana. Pytanie to oczywiście jest ciągle otwarte, jednakże ja wyraziłem pogląd, że w takich razach (częstych odrezerwowaniach) powinien z wyczuciem reagować administrator. W przeciwnym wypadku wymagane byłoby stworzenie swoistego zbioru zasad. Zdzislaw (dyskusja) 20:32, 30 paź 2018 (CET)

Odrezerwowywanie to wg mnie małe piwo: można ustalić, że jeśli indeks jest zarezerwowany nie dawniej niż N dni temu, to obowiązkiem odrezerwującego jest zapytanie się rezerwującego o zgodę na odrezerwowanie i poczekanie określony czas na odpowiedź. Niedotrzymanie tych zasad, dawałoby zatrudnienie administratorom.

Natomiast większym problemem może być zarezerwowanie sobie indeksu, który ktoś niedawno edytował, ale go nie zarezerwował. Bo tego, że edytował, nie da się łatwo sprawdzić. Ankry (dyskusja) 20:45, 30 paź 2018 (CET)

@Zdzislaw, @Ankry: a nie dałoby się zrobić na stronie indeksu jakiegoś małego podglądu który by pokazywał kto i kiedy robił ostatnią edycję na stronach indeksu? Np. "Wikiskryba... edytował stronę nr... data..." Joanna Le (dyskusja) 12:36, 31 paź 2018 (CET)

Technicznie by się dało. Ale skrypt, który by to robił musiałby pobrać i przeanalizować strony historii wszystkich stron w indeksie (statystycznie kilkuset). Czaso- i zasobochłonne. Jeśli używasz gadżetu Oznaczaj skorygowane przeze mnie strony, to mniej-więcej tak by to działało. Ankry (dyskusja) 14:02, 31 paź 2018 (CET)

A jakby była możliwość uruchamiania takiego skryptu tylko kiedy się potrzebuje sprawdzić ostatnią edycję, jakimś przyciskiem, a nie jak gadzet Oznaczaj skorygowane przeze mnie strony, który się uruchamia przy każdym wejściu na stronę indeksu? Czyli wchodzę na stronę indeksu który chcę zarezerwować klikam "sprawdź" i wyświetla mi się kto edytował ostatnio. Wtedy byłoby to czaso- i zasobochłonne, ale tylko kiedy byłoby konieczne. Joanna Le (dyskusja) 14:22, 31 paź 2018 (CET)

@Joanna Le:Obawiam się, że w przypadku dużych i uczęszczanych indeksów ilość danych byłaby istotnie pokaźna, nawet dla bota. Czy nie wystarczyłoby na górze strony indeksu małe (może potrójne?) okienko, gdzie użytkownik ręcznie by się podpisywał. A wchodzący na stronę widziałby informacje: ten indeks przepisuje/przepisują np. Ankry, korygują/korygują np. Anagram16 i uwierzytelnia/uwierzytelniają np. Zdzislaw. Po kilku dniach weszło nam w nawyk oglądanie tej informacji i rzadziej by się zdarzało, że ja wejdę komuś w paradę, a ktoś mnie. Gdyby ktoś się wpisał, ale by nie edytował przez miesiąc i się nie wypisał, wtedy każdy mógłby usunąć jego podpis i ewentualnie wstawić swój. (Anagram16 (dyskusja) 15:33, 31 paź 2018 (CET))

@Anagram16: Umieszczenie informacji o rezerwacji w indeksie to żaden problem. Tu chodziło o sposób przekazania tej informacji edytującemu stronę. Nie jestem pewien, czy wszyscy edytujący strony wchodzą na nie z indeksu. PMG raczej nie. Ankry (dyskusja) 17:30, 31 paź 2018 (CET)

@Anagram16: o takiej rezerwacji myślałes? Ankry (dyskusja) 18:56, 31 paź 2018 (CET)

Mniej więcej. A PMG, o ile pamiętam, nie zostawia po sobie błędów, chociaż pracuje jak japoński pociąg. (Anagram16 (dyskusja) 20:12, 31 paź 2018 (CET))

Rezerwacja nie ma nic do błędów lub ich braku. Chodzi o konflikty edycji. Na japoński pociąg też się można naciąć, choć trudniej. Ankry (dyskusja) 21:31, 31 paź 2018 (CET)

Wycofałem zmianę w strukturze indeksu, bo jak rozumiem nie ma zainteresowania tematem. Ankry (dyskusja) 22:35, 7 lis 2018 (CET)

Pytania do inicjatorów tego pomysłu:

1. Czy celem wprowadzenia tej funkcji ma być a) ograniczenie konfliktów edycji, czy b) przekazywanie ogólnej informacji o tym, że ja już pracuję nad danym indeksem i znajdź se inny (bo np. robię strony offline, a potem je wszystkie jednocześnie wprowadzam)?
2. Jak często spotkaliście się w swojej pracy edytorskiej z konfliktem edycji? Osobiście - choć edytuję o wiele mniej i mam wielomiesięczne przerwy w edytowaniu - tylko raz, jak łapczywie rzuciłem się w 2015 roku na Maksymy i rozważania moralne.--Matlin (dyskusja) 11:35, 4 lis 2018 (CET)

Oba względy (a i b) są uzasadnione. Konflikty edycji się zdarzają, a niektórzy z nas opracowują całe indeksy poza przestrzenią główną a nawet tutejszym brudnopisem i potem wklejają kilkadziesiąt stron z szybkością jednej na minutę. (87.207.9.162 (dyskusja) 13:03, 4 lis 2018 (CET))

@Matlin: Chyba kilkanaście razy. Ale ostatnio były to w zasadzie konflikty tylko z jednym skrybą. Każdy taki konflikt działa na mnie na tyle zniechęcająco, że odechciewa mi się edytowania w danym projekcie (trochę tak, jakby w trakcie czytania książki ktoś mi ją zabrał i wyrwał z niej nieprzeczytaną jeszcze kartkę). Dlatego jestem skłonny podjąć pewne działania wyprzedzające, które pozwolą mi upewnić się, że na kilkuset stronach, które zamierzam edytować z nikim się konfliktował nie będę. A jeśli się nie da, wolę sobie pójść na inną wiki, gdzie tego problemu nie ma lub zająć się czymś innym. Po prostu. Przez lata wypracowaliśmy sobie niepisaną zasadę, że nie wchodzimy sobie w drogę, jeśli edytujemy w tym samym indeksie, w którym edytuje ktoś inny, to albo zachowujemy pewien dystans, postępując za użytkownikiem, albo jeśli robimy to przed, to po to, żeby ten indeks szybciej ukończyć. A nie po to, żeby "obrobić" jedną stronę i po konflikcie się wycofać rakiem.

Konflikty edycji zdarzają się też w dyskusjach, ale te tak nie drażnią.

Co do celu: chodziło chyba przede wszystkim o a), ale to b) nie wyklucza. Masz jakieś inne propozycje w tej materii? Ankry (dyskusja) 23:09, 5 lis 2018 (CET)

• Nie miałem pomysłu i motywacji ostatnimi czasy, lecz okazało się, że Sitenotice/Editnotice parsuje szablony po transkluzji, więc i urodził się pomysł implementacji, z minimalnym użyciem js. Tak czy siak, po niespełna roku Rezerwacja doczekała się implementacji i od dzisiaj testowo działa na naszych ws. Obsługa zgodnie z opisem w Pomocy. Funkcja ta działa z większością nowych indeksów wykorzystujących funkcję pages rozszerzenia Proofread (tymi, których nazwy/adresy stron są takie same jak nazwa indeksu). Chętnych proszę o testy i uwagi. Zdzislaw (dyskusja) 22:19, 31 paź 2019 (CET)

• Czy będzie możliwość w zakładce rezerwacja zrobić tak, żeby do rezerwacji były przypisane 2 konta (np. gdy robię to zespołowo z kolegą z harcerstwa)? Superjurek   (Dyskusja) 20:51, 25 cze 2020 (CEST)

• @Superjurek: na pierwszy rzut oka wydaje się, że byłoby to możliwe. Muszę jednak znaleźć dłuższą chwilę aby toto dokładnie przetestować. Dam znać. Zdzislaw (dyskusja) 23:41, 25 cze 2020 (CEST)

• Mam pytanie w temacie tej funkcji. Jak ona się ma do tego, że każdy może edytować? Jak blokada edycji ma się do tego, że jest to projekt wiki? Rozumiem zamysł choć ciężko mi uwierzyć w nagminne konflikty edycji zwłaszcza na nielicznym gronie edytujących. Zauważyliście, że redaktorzy dawno wypracowali metodę nie wchodzenia sobie w drogę. Teraz czytam obowiązkiem odrezerwującego jest zapytanie się rezerwującego o zgodę na odrezerwowanie i poczekanie określony czas na odpowiedź. Niedotrzymanie tych zasad, dawałoby zatrudnienie administratorom.. Obowiązek pytania o możliwość edycji???? Reakcja administratorów???? Jeśli jakiś user wejdzie w listę stron do weryfikacji i zacznie weryfikować losowo, po pierwsze spotka się z blokadą edycji, po drugie gdy ją ominie, może doczekać się reakcji adminów? Jakoś tak mi to wychodzi z tej dyskusji i jakoś mocno kłóci się z ideą wiki. Tommy J. (pisz) 00:45, 26 cze 2020 (CEST)

• @Tommy Jantarek: Cytujesz wycinki propozycji z dyskusji, które nie zostały przyjęte jako jakakolwiek zasada. Implementacja funkcji została wykonana w taki sposób, że odrezerwowanie nie wymaga ani żadnych uprawnień, ani pytania kogokolwiek o zgodę. Całość znajdziesz w Pomoc:Proofread/Rezerwacja. Zdzislaw (dyskusja) 00:57, 26 cze 2020 (CEST)

• @Zdzislaw: wiem co cytuję. Skoro się to pojawia w dyskusji, to jest brane pod uwagę. Na projekcie wiki. Wydaje mi się że to ogromnie zgrzyta. Wg mnie, nawet gdy w przepisywany przez jednego usera projekt wejdzie inny user pozostający z pierwszym w jawnym i nieskrywanym antagoniźmie, to ma prawo edytować co chce, kiedy chce i nikt nie może mu tego utrudniać czy blokować, jeśli edytuje bez wandalizmów. Wg mnie również, taka rezerwacja może (przynajmniej na projekcie wiki gdzie każdy może edytować) jedynie rolę informacyjną. Wg mnie nawet automatyczne zblokowanie edycji już jest nadużyciem. Sam nie lubię konfliktów edycji czy gdy w ulubionym projekcie pojawia się Obcy, ale to jednak wiki.... Tommy J. (pisz) 01:09, 26 cze 2020 (CEST)

• Jeszcze jedno pytanie. Rozumiem że rezerwacja uniemożliwia pracę innych skrybów. Czyli gdy jeden przepisuje, drugi nie może korygować a trzeci weryfikować? Najpierw indeks musi zostać odrezerwowany? Tommy J. (pisz) 02:13, 26 cze 2020 (CEST)
• Dokładnie. Rezerwacja jest informacją dla kogoś kto chciałby edytować strony indeksu, że w tym samym indeksie grzebie lub grzebał ktoś inny i że ta osoba prosi by jej w tym nie przeszkadzać. To, czy ta druga osoba zastosuje się do prośby, czy nie jest w kwestii dobrych obyczajów raczej niż zasad. Jednak taka semi-blokada pozwala uniknąć przypadkowych konfliktów edycji. Jeśli ktoś chciałby edytować strony indeksu pomimo rezerwacji, to byłoby wskazane przynajmniej poinformować o tym użytkownika, który rezerwację utworzył (chociaż ten i tak powinien się w tej materii zorientować przy pierwszej swojej edycji strony tego indeksu). Chyba, że jest to stara, zapomniana rezerwacja. Zdarzają się czasem użytkownicy edytujący przypadkowe strony w przypadkowych indeksach, i to do nich głównie jest skierowana taka informacja. Dodam, ze niektórzy użytkownicy praktykują pracę offline (kiedy pomiędzy pobraniem wersji strony a zapisaniem nowej może upłynąć nawet kilka dni) i w takich sytuacjach konflikty edycji mogą być dokuczliwe. Ankry (dyskusja) 06:56, 26 cze 2020 (CEST)

• @Tommy Jantarek: nie nazwałbym tego nieuniemożliwianiem pracy - rezerwacja jedynie wymusza jednorazowe dodatkowe trzy (cztery kliknięcia) w celu odrezerwowania, po ich wykonaniu (do czego nie trzeba mieć żadnych dodatkowych uprawnień) rezerwacja całego indeksu znika. Nie trzeba odrezerwowywać przy każdej stronie. Zdzislaw (dyskusja) 16:30, 26 cze 2020 (CEST)

• @Zdzislaw: w pewnych przypadkach (w tej chwili mam dwa) może być. Jeśli user będzie korygować z poziomu kategorii bo przyjdzie mu do głowy że akurat dziś nie ma co robić, nie ma na celu i ochoty na żaden konkretny projekt i postanowi sobie zmniejszyć cyfrę nieskorygowanych. Drugi przypadek to uczenie się. Rzucane nowego skryby na konkretny projekt niewiele go nauczy. Taki user może skakać po projektach i korygować losowo strony podglądając różne rozwiązania i składnie. Sam tak się uczyłem. Wreszcie też chodzi mi o samą ideę. Ja rozumiem niechęć, gdy ktoś Ci wchodzi z ciężkimi butami w projekt. Sam tego nie lubię. To zrozumiałe. Ale jednak to wiki, zaden projekt nie jest niczyją własnością. I choćbym nawet z pełnym poświęceniem na nim pracował, "prawnie" nie mogę komukolwiek zabronić czy utrudnić pracy na tym projekcie, choćby ten ktoś postanowił sobie korygować np. co jedenastą stronę. Wg mnie rezerwacja może pełnić jedynie rolę informacyjną, pozostawiając edytorowi wolną wolę i wybór, zechce zrezygnować z edycji czy nie. Wg mnie zniknięcie przycisku edycji i spowodowanie kolejnych kliknięć by to umożliwić już jest nadużyciem na projekcie wiki. Taka jest moja opinia acz zaznaczam, całkowicie rozumiem z czego wynika pomysł rezerwacji w tej postaci. Tommy J. (pisz) 18:06, 26 cze 2020 (CEST)

• @Tommy Jantarek: Osobiście z rezerwacji nigdy nie korzystałem. Wykonałem ją testowo ze względu na zapotrzebowanie społeczności. Nikt od 10.2019 nie zgłaszał żadnych zastrzeżeń, nikt nie sygnalizował, że ogranicza to jego prawa. W takim razie wyjścia są dwa - całkowity rewert lub pozostawienie jedynie komunikatów. @Ankry, @Anagram16, @Matlin, @Joanna Le: jakieś opinie? Zdzislaw (dyskusja) 18:29, 26 cze 2020 (CEST)

• Rezerwacja jest stosowana, według mojej obserwacji Ostatnich zmian, bardzo rzadko. Wynika to oczywiście z tego, że stosunkowo trudno o konflikt edycji, a jeśli pojawiały się jakieś widoczne w dyskusjach problemy, to nie w tym, że dwóch użytkowników chciało przepisywać ten sam indeks, tylko rezerwacja była założona przez nowego, niedoświadczonego użytkownika, którego edycje chciał sprawdzić drugi wikiskryba, aby udzielić mu pomocy i wskazówek. Nie oznacza to, że jest to rozwiązanie nieużyteczne, tylko lepiej sprawdziłoby się przy większej liczbie wikiskrybów. Poza tym przekonałem się, że to nie jest tak daleko idąca ingerencja w swobodę edycji, bowiem zawsze można rezerwację usunąć, chociażby na chwilę. Jedyną zalecaną przeze mnie modyfikacją jest to, aby rezerwację mogli zapisywać tylko wikiskrybowie o randze redaktora, tak aby nowicjusze mieli możliwość otrzymania szybkiej pomocy. Może i pozostawienie tylko samego komunikatu, bez znikania zawartości strony? Nie jestem chyba sam w tym, że czasami przeglądam ostatnie zmiany i oglądam cudze edycje, bez żadnego klucza wyboru. W ten sposób mogę przy okazji wyłapać np. jakieś literówki, które są widoczne gołym okiem po wejściu w taką edycję. --Matlin (dyskusja) 18:50, 26 cze 2020 (CEST)
• Moim zdaniem najzupełniej "legalna" jest rezerwacja w formie komunikatu nawet obszerniejszego, jednak z możliwością edycji. Jeśli obstajecie przy zniknięciu edycji, to może łatwiejszy i szybszy sposób na odblokowanie/jednoedycyjne odblokowanie edycji, niż klikanie po dyskusjach indeksów i kasowanie a potem przywracanie rezerwacji. I prośba, zapomnijcie o jakichkolwiek "reakcjach admińskich". Nawet jeśli user nagminnie czy złośliwie będzie kasował rezerwacje, a jego edycje będą poprawne, to niestety ma do tego prawo a reakcja na to byłaby już przekroczeniem granicy. Tommy J. (pisz) 19:31, 26 cze 2020 (CEST)
• Zgadzam się, że z rezerwowaniem indeksów przez nie-redaktorów jest tylko kłopot. Ale pewnie wystarczy ukryć przed nimi informację o tym, jak rezerwować. Możliwe, że warto informację o tym jak rezerwować, schować głębiej w dokumentacji (może pokazywać nowym userom informację o tym mechanizmie dopiero przy konflikcie edycji? - nie wiem czy się tak da). Przyznam, że mi w przypadkach konfliktów edycji najbardziej brakowało ostrzeżenia przed próbą zapisu, że taki konflikt może wystąpić. Ewentualne zniknięcie informacji o rezerwacji lub (szczyt marzeń) informacja o jej zdjęciu na stronie dyskusji byłyby dla mnie zadowalające. Ja często edytuję strony offline, seriami (zwykle do 50 kolejnych stron) i nerwowe oczekiwanie, czy nie będę miał co kilkanaście stron konfliktu edycji przy seryjnym, półautomatycznym zapisie, jest nieco zniechęcające. Inna rzecz, ze od chwili utworzenia tego mechanizmu, nie miałem potrzeby z niego korzystać, bo "skaczący" po indeksach użytkownicy jakby zniknęli ostatnio z projektu. Nie mam nic przeciwko "jednoguzikowemu" likwidowaniu rezerwacji. Mógłby to być gadżet, który wyczyści stronę rezerwacji (a może jeszcze zostawi na stronie dyskusji rezerwującego wiadomość: "Słuchaj koleżanko/kolego, usunąłem/usunęłam twoją rezerwację z indeksu XXXX bo mi przeszkadzała w edycji <4 tyldy>". W moim rozumieniu, celem mechanizmu rezerwacji jest zniechęcanie innych użytkowników (nie: uniemożliwianie) do edytowania danego indeksu. Ankry (dyskusja) 20:20, 26 cze 2020 (CEST)

• Niestety, ze względu na specyfikę rozszerzenia proofread, nie powiodła się implementacja opcji jednoguzikowego likwidowania rezerwacji. Nie twierdzę, że tego się nie da wykonać, lecz ja nie widzę prostego mechanizmu. Zostawiłem na chwile obecną cały dotychczasowy mechanizm, lecz okrojony jedynie do komunikatów. Pytanie: Zostawić mechanizm z komunikatami, czy robimy całkowity rewert? Zdzislaw (dyskusja) 23:52, 30 cze 2020 (CEST)

• Wyłączyłem w indeksie widoczność tego mechanizmu dla nieredaktorów. Wydaje mi się, że jest konsensus co do tego, że używanie go przez nieredaktorów (których edycje wymagają przeglądania) jest niezalecane. Ankry (dyskusja) 23:26, 27 cze 2020 (CEST)

wikEd

Okazuje się, ze nie tylko ja mam problemy z gadżetem wikEd. Gryzie się on z wieloma mechanizmami wiki (w przestrzeni Strona potrafi likwidować okno edycji i inne elementy strony, przy edycji js z kolei okno edycji powiela, nieszczególnie współpracuje z tzw. "rozszerzonym" paskiem edycji itp.). Sugerowałbym usunięcie go z listy dostępnych gadżetów. Ale ponieważ kilkudziesięciu użytkowników ma go włączony (w tym 2 aktywnych), sugeruję by się odezwali tutaj, jeśli się z tym nie zgadzają, a spróbujemy wypracować jakiś kompromis.

Zwracam uwagę, że nawet jeśli gadżet zostanie usunięty z listy gadżetów, można go będzie ładować z common.js użytkownika. Ankry (dyskusja) 20:56, 3 lis 2018 (CET)

• Dodać notę, że gadżet działa niestabilnie i nie jest zalecane jego włączanie. --Matlin (dyskusja) 11:24, 4 lis 2018 (CET)
  • I wywalić go na koniec do osobnej sekcji "niewspierane gadżety"? Tu, gdzie jest, po prostu "utrudnia" dostęp do pozostałych gadżetów, a zwiększenie ilości tekstu w opisie tego użytkownikom nie ułatwi (będą musieli poświęcić więcej czasu na przeczytanie i zrozumienie, zanim dotrą do tego, czego szukają). IMO, jeśli go potrzebujesz, to po prostu skopiuj zawartość MediaWiki:Gadget-wikEd.js do swojego common.js. Ankry (dyskusja) 16:20, 5 lis 2018 (CET)
    • Ale ja tego dziadostwa nie używam :-) Chciałem raczej, żeby korzystający użytkownicy nie byli zaskoczeni, chociaż jest ich tak mało, że milczenie należy przyjąć za zgodę. Solidny wikiskryba powinien czytać skryptorium. --Matlin (dyskusja) 11:52, 6 lis 2018 (CET)

---

Załatwione usunąłem go z gadżetów wobec braku zadeklarowanych użytkowników. Ankry (dyskusja) 21:06, 25 cze 2020 (CEST)

Indeks

Może część z was zauważyła, że od pewnego czasu rozwijam szablon {{Index}} służący do wyświetlania informacji w Indeksie, głównie poprzez dodawanie do niego nowych pól. Jeżeli macie w tej materii jakieś uwagi (np. uważacie, że jakiś pola są potrzebne lub zbędne, albo że coś można by rozwiązać inaczej, proszę o sygnał, najlepiej w tym wątku).

Jakiś czas temu zauważyłem, że dość powszechnie przyjętym standardem rozgraniczania wartości wielokrotnych (wielu autorów, tłumaczy, wydawców, miejsc wydania) jest używanie w tym celu średników. I proponuję, by ten de facto standard stosować, przynajmniej w indeksie. Powinno to ułatwić w przyszłości ewentualny transfer informacji do wikidanych (o którym mowa w jednym z wątków wyżej; chociaż na razie widzę tam więcej czarnych chmur niż jaskółek).

Ankry (dyskusja) 08:34, 6 lis 2018 (CET)

Błędy składni

Hej

Czy macie świadomość istnienia takiej strony i czy ktoś pracuje nad poprawkami pokazywanych tam błędów? PMG (dyskusja) 13:35, 14 lis 2018 (CET)

Hej @PMG:, świadomość mamy, chociaż dobrze jak czasami ktoś przypomni. Ale do zrobienia jest tyle różnych rzeczy, że nie wiadomo czasem za co się brać. A większość z nas najchętniej (bo w sumie po to tu jesteśmy) czyta książki, przepisując bądź korygując jednocześnie. Joanna Le (dyskusja) 18:43, 14 lis 2018 (CET)

@PMG: jak wynika ze statystyk postępu za jakieś 14 lat powinniśmy wyjść na prostą. Chyba, że znowu coś pozmieniają w HTML-u do tego czasu ;P Ankry (dyskusja) 22:51, 14 lis 2018 (CET)

W3C działa wolno - ale myślę że HTML6 powstanie szybciej niż za 14 lat. Pewnie augmented reality będzie już powszechne jak ostatnie znaczniki big będą usuwane z Wikiźródeł :) PMG (dyskusja) 23:27, 14 lis 2018 (CET)

Interwiki

Zaimportowałem od Szwedów ich skrypty do tworzenia interwiki na podstawie informacji z Wikidata. Strony wykorzystujące ten mechanizm można znaleźć w tej kategorii (nowe będą się sukcesywnie pojawiać po odświeżeniu). Proszę o sygnały o nieprawidłowym działaniu i ew. inne uwagi. Ankry (dyskusja) 01:30, 21 lis 2018 (CET)

• Super. Teraz wystarczy tylko utworzyć odpowiedni element wikidanych i teksty same linkują do siebie. Dzięki Nawider (dyskusja) 21:38, 24 lis 2018 (CET)
• @Ankry: Hej, jeżeli P629 zostanie wprowadzone z wartością nieznana wartość, (patrz [23]), skrypt generuje błędy na naszych stronach. Nie znam się na data, lecz wydaje mi się, że to raczej błędnie wprowadzone P629, lecz sam moduł chyba także należałoby uodpornić na takie rzeczy? Zdzislaw (dyskusja) 17:29, 30 lis 2018 (CET)

• Ano. Dzięki za sygnał. Choć chyba lepiej by było jakoś takie sytuacje wykrywać, bo w tym przypadku w Wikidata są ewidentnie bzdurne informacje. Ankry (dyskusja) 20:45, 30 lis 2018 (CET)

Status proofread a anonimowi użytkownicy

Jakiś czas temu zauważyłem, że na niemieckich Wikiźródłach anonimowi użytkownicy mają możliwość zmiany statusu korekty. Następnie nastąpiła ta dyskusja, w wyniku której doszedłem do wniosku, że może to niegłupi pomysł, by dać niezalogowanym przynajmniej ograniczone możliwości w tej materii.

A w szczegółach pomysł wygląda tak:

• wnioskujemy w phabricatorze, by nadać anonimowym użytkownikom prawo zmieniania statusu strony
• usuwamy "żółty" guziczek w przypadku nowych stron (OK, to właśnie zrobiłem; a dla "hackerów" mamy jeszcze blokadę na abusefiltrze)
• usuwamy dla anonimowych wszystkie guziczki statusu, jeśli edytują istniejącą stronę
• blokujemy na abusefiltrze możliwość zmiany przez nich statusu w przypadku już istniejących stron

Raz ustawionego statusu nie będą mogli zmienić; ale będą mogli ustawić status strony na dzień dobry i zobaczą, że jest coś takiego jak ustawianie statusu przez użytkownika.

@Joanna Le, @Nawider, @Salicyna, @Bonvol, @Wieralee:@Alenutka, @Matlin, @Wrzodek, @JKW, @Zdzislaw:@Wolan, @Anwar2, @Anagram16, @Kejt, @Draco flavus:@Sempai5, @Zetzecik, @Kanioska: Co o tym pomyśle myślicie? Ankry (dyskusja) 23:23, 13 gru 2018 (CET)

Krótko mówiąc, obecnie jest tak, że niezalogowany użytkownik, tworząc nową stronę, może ją pozostawić jedynie w domyślnej pozycji czerwonej, nawet jeżeli strona powinna być szara (bez treści) lub niebieska (problemy). Zmiany proponowane przez Ankrego spowodują, że niezalogowany może utworzyć nową stronę także nadając jej status szary lub niebieski. Osobiście jestem  Za Salicyna (dyskusja) 23:29, 13 gru 2018 (CET)

Zmiana na szary lub niebieski jak najbardziej, ale na żółty lub zielony, jak rozumiem, nie. (Anagram16 (dyskusja) 01:02, 14 gru 2018 (CET))

Moim zdaniem to dobry pomysł. Oznaczanie na czerwono, niebiesko i szaro powinno być dostępne dla każdego, jestem  Za Joanna Le (dyskusja) 11:13, 14 gru 2018 (CET)

A czy niezalogowani dostają przy oknie edycji jakieś info, że pełna funkcjonalność będzie dostępna po zalogowaniu? --Matlin (dyskusja) 11:21, 14 gru 2018 (CET)

@Matlin: Pojawiają się komunikaty:

"Dokonane przez Ciebie zmiany zostaną pokazane natychmiast po przejrzeniu przez uprawnionego użytkownika. (pomoc)"

"Osoby zaczynające pracę na Wikiźródłach zachęcamy do zapoznania się ze stroną Pomoc:Proofread."

"Uwaga: Nie jesteś zalogowany. Jeśli wykonasz jakąkolwiek zmianę, Twój adres IP będzie widoczny publicznie. Jeśli zalogujesz się lub utworzysz konto, Twoje zmiany zostaną przypisane do konta, wraz z innymi korzyściami." Joanna Le (dyskusja) 11:37, 14 gru 2018 (CET)

...nie mam nic naprzeciwko, Zdzislaw (dyskusja) 14:46, 14 gru 2018 (CET)

wstępnie za, ale rozumiem, że w dalszym ciągu ktoś będzie musiał to przejrzeć i zatwierdzić zmiany Nawider (dyskusja) 19:17, 14 gru 2018 (CET)

...i to ktoś posiadający konto. Uprawnień redaktora anonimowi też nie dostają. Ankry (dyskusja) 20:27, 14 gru 2018 (CET)

w sumie dlaczego nie, w takim ograniczonym zakresie. Kejt (dyskusja) 19:55, 14 gru 2018 (CET)  Za

właściwie, czemu nie, też jestem  Za Sempai5 (dyskusja) 21:20, 14 gru 2018 (CET)

•  Za Wieralee (dyskusja) 13:19, 16 gru 2018 (CET)

Zgłoszone na phabricatorze: phab:T212478. Ankry (dyskusja) 08:30, 21 gru 2018 (CET)

Funkcja została dziś włączona (działa).

Czyli Załatwione Ankry (dyskusja) 17:24, 8 sty 2019 (CET)

Przycisk do szybkiego wstawiania sekcji

Przycisk do szybkiego wstawiania sekcji nie działa. Ktoś, coś? Nawider (dyskusja) 20:04, 15 gru 2018 (CET)

Ja mogę jedynie powiedzieć, że u mnie też nie działa. Joanna Le (dyskusja) 21:07, 15 gru 2018 (CET)

Powinien już działać. Jeśli nie, sugeruję na chwilę wyłączyć ten gadżet, a potem włączyć go ponownie. Niestety, popsuto go przy usuwaniu starego toolbara, a jakoś nikt dotąd nie zwrócił uwagi, że nie działa. Ankry (dyskusja) 21:50, 15 gru 2018 (CET)

Dziękuję, już działa Nawider (dyskusja) 22:26, 15 gru 2018 (CET)

Znaczniki formatowania

Chciałam zwrócić uwagę na sposób oznaczania pogrubionego i pochylonego tekstu. Na liście Błędy składniowe: Źle zagnieżdżone znaczniki jest całkiem sporo pozycji które w dużej części tego dotyczą. Jak widzę po edycjach, nie zwracamy na to zbytnio uwagi (ja z pewnością nie zdawałam sobie z tego sprawy, i sądzę że jest tak ze sporą częścią redaktorów).

Oznaczając tekst, aby był pochylony czy pogrubiony, wszystkie znaczniki muszą znajdować się wewnątrz szablonów {{c}} i {{f}} i nie mogą znajdować się wewnątrz szablonu {{rozstrzelony}}. Np. zapis {{c|{{roz|''COŚ TAM}}''|w=130%}} jest nieprawidłowy, powinno być {{c|''{{roz|COŚ TAM}}''|w=130%}}.

Pozdrawiam Joanna Le (dyskusja) 08:35, 4 sty 2019 (CET)

• @Joanna Le:, {{c|{{roz|''COŚ TAM}}''|w=130%}} jest nieprawidłowy, ponieważ "początek" italica '' znajduje się w {{roz}}, natomiast "koniec" już w {{c}}. Nie widzę przeszkód aby znacznik znajdował się wewnątrz {{rozstrzelony}}, tak jak tu: {{c|{{roz|''COŚ TAM''}}|w=130%}}. Zdzislaw (dyskusja) 18:29, 5 sty 2019 (CET)
• @Zdzislaw: wydaje mi się, że na liści błędów były strony w których znaczniki były wewnątrz szablonu , jak np. tutaj, ale możliwe że jest tam coś innego nie tak, czego ja nie widzę.

• tak, tam problem wywołuje(ywał) ''' w {{Roz*}}. {{Roz*}} generuje kod dynamicznie, aby omijać znaki interpunkcyjne, i nie jest w stanie "parsować" znaczników wikikodu. Tutaj trzeba unikać zagnieżdżania - dodam informację w opisie szablonu. Zdzislaw (dyskusja) 19:25, 5 sty 2019 (CET)

I zauważyłam właśnie, że jako błąd oznaczane jest też, że znacznik jest poza <poem> [24], czyli powinniśmy oznaczać każdy wers osobno? Joanna Le (dyskusja) 18:50, 5 sty 2019 (CET)

@Joanna Le:, Aby być w zgodzie ze standardem, to każdy osobno, lub tak, Zdzislaw (dyskusja) 19:03, 5 sty 2019 (CET)

Kwestia formatowania

Zastanawiam się jak możliwie jak najwierniej (ale bez generowania trudności technicznych, uniemożliwiających przeglądanie utworu) odwzorować komentarze na marginesie objaśnień (zob. np. str. 38). Raczej nie może do tego służyć Szablon:wiersz. Być może wystarczyło by coś takiego jak Szablon:right sidenote na angielskiej Wikisource (np. tu). Jeżeli ktoś mógłby opracować znaczniki formatowania html/css na potrzeby tego, to byłbym wdzięczny podwójnie; bo tego typu komentarze występują chyba też w innych dialogach tłumaczonych przez Witwickiego, które zamierzam opracować. --Matlin (dyskusja) 21:10, 7 sty 2019 (CET)

Na razie można uznać za Załatwione. Dzięki, Ankry. --Matlin (dyskusja) 21:15, 20 sty 2019 (CET)

Zepsute renderowanie PDF-ów

Uwaga

Wygląda na to, że nam developerzy zaserwowali popsute renderowanie PDF-ów. O ile wcześniej wygenerowane obrazki stron wyświetlają się prawidłowo, o tyle nowo wygenerowane (gdy starych nie było lub się przeterminowały) dla wielu plików pokazują goły OCR lub pustą stronę zamiast jej obrazu.

Dlatego zalecam szczególną ostrożność przy wprowadzaniu / korygowaniu stron opartych o pliki PDF. Z DjVu problemu nie ma.

Problem zgłoszony na phabricatorze. Ale znając życie, nie liczyłbym na szybie usunięcie usterki ;P Ankry (dyskusja) 21:10, 20 sty 2019 (CET)

Wygląda na to, że już poprawione. Ankry (dyskusja) 23:46, 17 lut 2019 (CET)

Jak to poprawić

"ludu polskiego na {{Kor|Slązku|Ślązku]] i wszędzie i ciągle głoszą" w https://pl.wikisource.org/wiki/Baczno%C5%9B%C4%87!_Chleb_dro%C5%BCeje! na pewno mnie jest porządane. Jak to poprawić? Mateusz Konieczny (dyskusja) 12:52, 26 sty 2019 (CET)

• Błędne było zamknięcie szablonu: ]] zamiast }}. Poprawiłem, efekt tutaj: Baczność! Chleb drożeje!. Maitake (dyskusja) 21:58, 26 sty 2019 (CET)

Podmiana plików DjVu itp.

Wygląda na to, że w MediaWiki mocno kuleje obsługa plików z bardzo dużą liczbą powiązanych z nimi miniaturek (thumbnails) (patrz też phab:T214759). W związku z tym sugerowałbym osobom podmieniającym takie pliki (@Draco flavus:), zwłaszcza z dużą ilością stron, by przed ich załadowaniem na Commons sprawdziły, czy operacja wyczyszczenia cache (purge) nie zwróci błędu (jeśli zwróci to mamy prawie pewność, że pozostaną nam miniaturki stron ze starego pliku - przynajmniej tych, które były w ostatnim czasie - miesiąc wstecz? - przez kogoś oglądane). Można spróbować kilka razy. Jeśli operacja się nie powiedzie, sugerowałbym zamieszczenie pliku lokalnie korzystając z Special:Upload zamiast/oprócz zamieszczania pliku na Commons. Tyle, że warto przed zamieszczeniem sprawdzić, czy nowy plik jest na pewno tym o który chodzi, bo taki "numer" obejścia problemów z czyszczeniem cache uda się zrobić dla danego pliku prawdopodobnie tylko raz. Ankry (dyskusja) 15:13, 28 sty 2019 (CET)

Niewidoczne separatory

Szablony: {{Separator linia}}; {{Separator}}; Szablon:-=- (tego ostatniego nie da się go wstawić w {{s}}) nie wyświetlają się w mojej przeglądarce Firefox, są widoczne za to w Google Chrome. Poprosiłbym, abyście sprawdzili u siebie i ewentualnie, jeśli też nie będą widoczne, napisali tutaj. A ogólne pytanie brzmi: czy nie da się "poprawić" tych szablonów, aby były kompatybilne, albo czy da się, aby w takich sytuacjach wyświetlały alternatywnie zwykły separator, np. z {{---}}? --Matlin (dyskusja) 14:50, 8 kwi 2019 (CEST)

• {{Separator}} wyświetla się u mnie prawidłowo. {{Separator linia}} i Szablon:-=- są niewidzialne w przeglądarce Firefox, ale już w Operze je widać. Joanna Le (dyskusja) 18:58, 8 kwi 2019 (CEST)
  • Jak napisała Joanna, Firefox Wersja 66.0.2 , Ubuntu Draco flavus (dyskusja) 20:44, 8 kwi 2019 (CEST)
    • Poprawiłem {{Separator linia}}, lecz utrzymywanie tego toto, wymagać będzie ciągłej uwagi, Zdzislaw (dyskusja) 21:18, 8 kwi 2019 (CEST)

Z bratniej niwy: link między stronami i ebook

Nie mogę sobie poradzić z linkiem między stronami w spisie treści Z bratniej niwy i ebookiem, który generuje się pusty. Uprzejmie proszę o pomoc. Pozdrawiam, Wolan (dyskusja) 06:59, 9 kwi 2019 (CEST)

@Wolan: Nie wiem, czy nadal występuje u Ciebie problem z ebookiem, ale gdy pobieram go ze strony głównej (Z bratniej niwy) to zawiera wszystkie utwory; więc chyba Załatwione? --Matlin (dyskusja) 12:37, 12 maj 2019 (CEST)

• @Matlin: U mnie też jest ok. Dziękuję! Wolan (dyskusja) 18:58, 12 maj 2019 (CEST)

Czy możliwe jest płynne połączenie tekstu pochodzącego z 2 (lub więcej) indeksów?

Pytanie jak w tytule. Dla przykładu, popatrz np. -> Old Surehand/Tom III. Tekst jest łączony z 2 oddzielnych indeksów, przy czym na ich "styku" powstaje przerwa, co nie wygląda zbyt elegancko. Chodzi mi o przerwę w zdaniu:

Nieraz dwaj lub trzej zuchwalcy napadają na pociąg i zmuszają podróżnych do poddania się rewizyi

a

na okrzyk: hands up!

Może jednak ktoś ma na to jakiś patent? Electron  ^<Odpisz> 11:43, 12 maj 2019 (CEST)

• @Electron: Masz chyba na myśli sytuację, występującą ściślej na tej stronie i związaną z tym, że przerwę tworzą trzy puste strony (007 itd.) z nowego pliku (które należą do tego samego indeksu). Rozwiązaniem mogłoby być pominięcie tych stron przy wstawianiu znacznika pages index, ale widzę, że to też powoduje wystąpienie przerwy. --Matlin (dyskusja) 12:47, 12 maj 2019 (CEST)
• @Electron: Z dwóch różnych indeksów nie jest możliwe ze względu na specyfikę formatowania MediaWiki. Ale tutaj widzę jeden indeks. Można użyć sekcji. Zobacz, jak to jest zrobione w niektórych rozdziałach Winnetou. Ankry (dyskusja) 13:10, 12 maj 2019 (CEST)
  • OK. Dzięki za radę. Ciekawe rozwiązanie i widzę, że działa. Problem w tym, że sekcję trzeba by było wkleić na każdej stronie... A dużo tego jest (podobna sytuacja występuje także w innych rozdziałach i stronach całości). Najlepiej by było zatrudnić bota. Więc na razie sobie chyba odpuszczę... Po za tym jeszcze kupa stron została do przepisania. Electron  ^<Odpisz> 11:09, 13 maj 2019 (CEST)
  • Btw. Próbowałem też zastosować parametry "exclude" bądź "include", które pozwalają wyświetlać tylko konkretne strony ale bez rezultatu (tzn. nie ma na nie żadnej reakcji oprogramowania). Ale może źle je stosuję, bo tak na dobrą sprawę to nigdzie nie jest szerzej opisane jak je zapisywać, gdy stron do wykluczenia/załączenia jest więcej i nie są one tylko prostymi numerami, a indeks jest bardziej złożony. Być może wtedy nie działają. Electron  ^<Odpisz> 12:19, 13 maj 2019 (CEST)
    • Niestety, parametr exclude działa tylko dla nowego formatu indeksów, opartych na pojedynczym pliku pdf/djvu. I chyba nie byłoby łatwo to zmienić. Ankry (dyskusja) 12:51, 13 maj 2019 (CEST)
      • Szkoda, bo to by elegancko rozwiązało sprawę. W takim razie pozostaje rozwiązanie z zastosowaniem sekcji. Ale zajmę się nim jak już uporam się z tekstem. A jeszcze trochę tego zostało. May nie należał do pisarzy oszczędnych w słowa ;) Electron  ^<Odpisz> 13:06, 13 maj 2019 (CEST)

Problem z wprowadzaniem niektórych znaków specjalnych

Od przedwczoraj mam problem z wprowadzaniem niektórych znaków specjalnych z klawiatury takich np. jak

"dwukropek" -> ː

"plus" -> ̟

"gwiazdka" -> ̈

nawiasy kwadratowe (jak je wprowadzam podwójnie) -> ʽʼ

nawiasy klamrowe (jak je wprowadzam podwójnie) ->̻ ˌ

i inne (to co mi się wprowadza jest pokazane po znaku "->") Litery wchodzą OK.

Jak widać wprowadzają się jakieś inne dziwne znaczki. Na innych projektach wiki (mediawiki) jest wszystko OK. Nie bardzo wiem o co biega... Czy to coś z moim kompem lub konfiguracją oprogramowania (Win XP ̟ FF ESR 52.9.0)? Wygląda jednak, że to coś zostało przestawione w tej wiki.

Przedtem wszystko było w porządku. Nic w międzyczasie nie przestawiałem ani nie instalowałem na kompie. Zmiana nastąpiła "w biegu" podczas pracy i od tego czasu jest źle (choć czasami jakby na krótko odpuszcza i niektóre znaki specjalne wchodzą prawidłowo ale to z rzadka). Oczywiście nie muszę chyba dodawać jak to utrudnia formatowanie, gdy niektóre znaki można tylko wstawiać metodą "skopiuj i wklej"...

Co to może być? Czy ktoś ma ten sam problem? --Electron  ^<Odpisz> 12:06, 20 maj 2019 (CEST)

Nie wiem jakiego edytora używasz, ale ja w edytorze z 2010 nie mam tego problemu: ":.*" Ankry (dyskusja) 13:08, 20 maj 2019 (CEST)

Edytora? Czy chodzi ci o przeglądarkę? To Fire Fox ESR 52.9.0 - nic nowszego na Windows XP nie pójdzie, a Wikimedia od jakiegoś czasu blokują inne starsze przeglądarki. Oczywiście dla mojego dobra ;) --Electron  ^<Odpisz> 13:27, 20 maj 2019 (CEST)

W starszym (po wyłączeniu "paska edycji") też nie mam żadnego problemu: ":.*"

A nowszych cudeniek nie używam, więc się nie wypowiem. Może coś nie tak z klawiaturą na twojej maszynie, albo z jakąś wybraną niestandardową klawiaturą w samym MediaWiki?

Chodzi mi o edytor mediawiki: [25] Ankry (dyskusja) 13:36, 20 maj 2019 (CEST)

• Może problem w skrótach klawiszowych? Wikiskryba:Electron/common.js Wieralee (dyskusja) 13:40, 20 maj 2019 (CEST)

Aha. Też nie używam żadnych nowych wynalazków. Edytuję w wikikodzie, po staremu. W preferencjach mam zaznaczone Włącz pasek narzędzi edycyjnych Inna nazwa to 'edytor wikikodu 2010' Co do skrótówː Java skrypt wydaje się chodzić prawidłowo ale być może zaczął się nagle z czymś gryźć? Zresztą zerżnąłem go dawno temu od Ciebie ː) Być może trzeb by zaktualizować? --Electron  ^<Odpisz> 13:52, 20 maj 2019 (CEST)

Najwyraźniej edytując na Wikiźródłach niechcący przestawiłeś w oknie edycji rodzaj klawiatury. Wejdź w jakiekolwiek okno edycji, najedź na trójkącik w prawym dolnym rogu (pod paskiem przewijania), po kliknięciu powinna wyświetlić ci się ikonka klawiatury, a po kliknięciu w nią lista wyboru - przełącz na "Użyj swojej klawiatury". Salicyna (dyskusja) 14:09, 20 maj 2019 (CEST) Może niekoniecznie na sam trójkącik, ale w jego okolicach, w prawym dolnym rogu okna edycji. Pingam jeszcze raz, bo w pierwszej edycji zrobiłam to z błędem i pewnie nie zadziałało. @Electron: Salicyna (dyskusja) 14:28, 20 maj 2019 (CEST)

Odkryłem o co chodzi. Jak wprowadzałem te problemowe znaki to pojawiało mi się na ekranie jakieś małe okienko z nazwą "International Phonetic Alphabet". Na początku tego nie zauważyłem, bo jakoś tak tylko niezbyt wyraźnie majaczyło. A oczy już nie te... Można toto wyłączyć - po kliknięciu na to okienko jest taka opcja. I po sprawie. Na co to to komu do tej pory nie wiem... Pewnie dla ułatwienia czegoś tam, a mnie mało co szlag nie trafiał... Dziękuję wszystkim pięknie za pomoc i pomysły :) Electron  ^<Odpisz> 14:33, 20 maj 2019 (CEST)

@Electron: No, to jest właśnie to, o czym mówiłam powyżej - musiałeś niechcący podczas edycji kliknąć na wybór rodzaju klawiatury i przełączyć na fonetyczną. Salicyna (dyskusja) 14:37, 20 maj 2019 (CEST)

OK. Dzięki za wyjaśnienie. Wprowadzają te nowe funkcje za funkcją a człowiek coś niechcący włączy i siwieje potem ze zgryzoty, że coś mu się nagle popsuło... Ech... Ja już nie nadążam. Electron  ^<Odpisz> 14:43, 20 maj 2019 (CEST)

Maszynopis a typografia

 Od czasu do czasu zdarzają się nam do przepisania maszynopisy. Przykład Ethos społeczny literatury polskiej. Wydaje mi się, że trzymanie się ogólnych zasad stosowanych na wikiźródłach nie ma sensu. Rozumiem, że zasady są takie: cudzysłowy zostawiamy, jak w oryginale, myślnik/łącznik typograficzny (zgodnie z funkcją), nawias jak w oryginale, trzy kropki w wielokropek (zresztą dzieje się to na wiki automatycznie).
 Mielibyśmy tu taką sytuację (zmyślony przykład): "Flaga czerwono-biała /czyli/ odwrócona..." — rzekł nauczyciel.
 Wydaje mi się, że naturalniejsze byłoby w tym wypadku (maszynopis) zdecydowanie się na konsekwentne stosowanie polskich typograficznych cudzysłowów „”, normalnych nawiasów ()i rozróżniania łączników od myślników(czyli naturalna transformacja tradycyjnego maszynopisu w tradycyjny tekst złożony przez zecera.
 Maszynopis był pisany wg przysłowia „Tak krawiec kraje, jak mu materiału staje.” — jeśli nie było na maszynie nawiasów — zastępowano je ukośnikiem, cudzysłów był jeden (łączył funkcję ze znakiem cali), kreska również była jedna (minus-myślnik-łącznik), trzy kropki były od siebie oddalone, jak w każdym nieproporcjonalnym kroju, nienaturalnie daleko.
Draco flavus (dyskusja) 16:30, 26 cze 2019 (CEST)

• @Draco flavus: Ta dyskusja jest skazana na niepowodzenie - jest przyjęty tak zwany konsensus dotyczący tego, że teksty należy wprowadzać tak wiernie, jak to jest możliwie. I myślę, że w sporej części słusznie, bo przyjęcie polityki redakcyjnej (nawet tylko w części źródeł) utrudniłoby pracę - dlatego są takie serwisy, jak Wolne Lektury. Dyskusje o tej kwestii toczą się często. Myślę, że, skoro temat powraca, warto stworzyć jakąś wiki, której funkcją byłaby jakaś obróbka redakcyjna i krytyczna tekstu - oczywiście poza ruchem Wikimedia. Coś jak np. Ogród Petenery, który istnieje na bezpłatnej (bodaj) platformie Wikia (Fandom). --Matlin (dyskusja) 17:40, 26 cze 2019 (CEST)
  • Ad vocem - dla jasności, nie mam do tematu, żadnego stosunku emocjonalnego, indeks był już opracowywany przez kilka osób, podchodziły do tego różnie. Raczej oczekuję porady, czy w przypadku maszynopisu uwzględniać ich naturalne ograniczenia i robić dziwną mieszaninę "skansenu" (cale, ukośniki) i postępowych zasad (wielokropki, myślniki) czy w tym wypadku zrobić jakiś kompromis. I nie chcę tu naprawdę odgrzewać starych tematów, na poziomie ogólnym zgadzam się, z ideę zachowywania oryginału.Draco flavus (dyskusja) 17:53, 26 cze 2019 (CEST)

No nie, nie stwierdziłem, że masz jakikolwiek stosunek do tematu, jest on zresztą nieistotny, jednakowoż on się sprowadza do tych [tematów], które wymieniłem, a w jaki sposób? To działania ocenne, które wykraczają poza potrzebę; tę potrzebę wyznacza następujące kryterium: należy dokonywać ocen (czy dany zapis/pisownia, czy dany sposób zapisu w znaczeniu typograficznym jest merytorycznie i teleologicznie dobrym/poprawnym/spójnym) tylko wtedy, gdy mamy wątpliwości, czy jest w ogóle możliwe odwzorowanie (w kodzie strony) tego, co poddajemy ocenie. A więc także przykładowo w sytuacji, gdzie mamy na skanie subtelność w zapisie tak wielką, że prawie niedostrzegalną (konkretnie: wahamy się, czy rozmiar czcionki jakiegoś nagłówka jest, w odniesieniu do tekstu zasadniczego, większy lub mniejszy o kilka procent). Przy czym taka subtelność nie może dawać zbyt dużego luzu interpretacyjnego i sprawiać wrażenia, że odwzorowanie (w kodzie strony) jest przekłamane. Chcąc podsumować i odpowiedzieć na zadaną Twoją kwestię, muszę stwierdzić, że przyjęty tak zwany konsensus oznacza, że znaki interpunkcyjne należy odwzorować, o ile mają swój odpowiednik na bitowej tablicy znaków, jeżeli nie mają, to należy sięgnąć po najbardziej podobny (wizualnie) znak i konsekwentnie stosować go w obrębie tekstu. --Matlin (dyskusja) 20:42, 26 cze 2019 (CEST)

• Btw. Przypominam, że istnieje Kategoria:Transkrypcje. Fakt, że kurzem porosła... ale można by było ten tekst poprawić w ramach transkrypcji. Jakby komuś się chciało. Były też pojedyncze próby uwspółcześniania zamierzchłej ortografii. Ale już nie pamiętam, których to konkretnie tekstów dotyczyło. Electron  ^<Odpisz> 00:29, 27 cze 2019 (CEST)

Możliwości są następujące (+ jeszcze kilka pośrednich)

• 1. "Flaga czerwono-biała /czyli/ odwrócona..." - rzekł nauczyciel. (najbliższa oryginałowi)
• 2. "Flaga czerwono-biała /czyli/ odwrócona..." - rzekł nauczyciel.
  
• 3. "Flaga czerwono-biała /czyli/ odwrócona..." - rzekł nauczyciel.
• 4. "Flaga czerwono-biała /czyli/ odwrócona..." — rzekł nauczyciel. (najbliższa moim zdaniem ogólnym zasadom stosowanym na Wź )
• 5. „Flaga czerwono-biała /czyli/ odwrócona...” — rzekł nauczyciel.
• 6. „Flaga czerwono-biała (czyli) odwrócona...” — rzekł nauczyciel. (najbliższa idei autora zapewne)

Za jaką wersją byście byli (ja za 6)? W jakieś transkrypcje dla "głupiego" maszynopisu z lat 80-tych bym się nie bawił. Draco flavus (dyskusja) 09:11, 27 cze 2019 (CEST)

• Szósta wersja jest, rzecz jasna, zakazana. Można bazować na innych indeksach, np. Pamiętnik więźnia. --Matlin (dyskusja) 11:54, 27 cze 2019 (CEST)

• Kwestia gustu, jak to w transkrypcjach, przekładach, itp.... Zawsze to jest jednak jakiś arbitralny wybór. Electron  ^<Odpisz> 12:14, 27 cze 2019 (CEST)

• Przyjęło się stosować u nas wersję czwartą i do tej bym się skłaniał (nawiasy traktowałbym tutaj jak cudzysłowia — staraliśmy się zawsze pozostawić oryginalne, a że tekst nam się trafił w maszynopisie... — unikałbym takich jeśli mamy dostępną inną wersję na otwartej licencji). Przy okazji: mamy jeszcze nieopracowany indeks a ciekawie się zapowiadający (czytałem Anda) o nietypowej typografii: patrz przykład np. tu Bonvol (dyskusja) 21:03, 27 cze 2019 (CEST)

Dodam jeszcze, że możemy spotkać jeszcze inne problemy w innym maszynopisach:

• Druga wojna światowa wybuchła w I939 roku.
• Druga wojna światowa wybuchła w l193 roku.

Praktyka zamieniania 1 na wielkie i lub małe ℓ była powszechna i zalecana... Draco flavus (dyskusja) 20:37, 29 cze 2019 (CEST)

Wszystko fajnie, ale wg mnie należałoby zacząć od zastanowienia się, czy jesteśmy w stanie sformułować jasne i jednoznaczne zasady "transkrypcji" takich maszynopisów. Celem wspierania naszych tekstów przez skany jest ich weryfikacja ze źródłem. Weryfikacja, która zakłada, że jest możliwe jednoznaczne stwierdzenie czy dany tekst jest zgodny ze źródłem, czy nie. Jeśli takiej możliwości nie będzie, to zamiast wprowadzać nowe teksty, zaczniemy się zajmować dyskusjami nt. właściwej interpretacji poszczególnych fragmentów, a na to raczej nie mamy zasobów. Podam przykład: załóżmy, że mamy dokument oznaczony sygnaturą: "I94o/II/A": jak stwierdzić, czy jest to rzymska II, czy 11? Osobiście nie mam nic przeciwko takim transkrypcjom, ale pod warunkiem, że ktoś będzie w stanie zdefiniować jednoznaczne reguły postępowania (co zamieniamy, na co i w jakim kontekście). Ankry (dyskusja) 08:58, 30 cze 2019 (CEST)

Za całkowitym zachowaniem liternictwa tekstu pierwotnego. — Paelius (dyskusja) 23:44, 8 lip 2019 (CEST)

PetScan a wikiźródła

Taki problem: zawsze używałem jednego zapytania Petscana do wyciągania małych stron do oznaczania. Ale ostatnio strony oznaczone przestały mi znikać z listy. Takie zapytanie w PetScanie pokazuje mi na pierwszych 10 pozycjach 9 stron Skorygowanych (pierwszego nie oznaczę bo nie znam rosyjskiego). Jakiekolwiek idee dlaczego? PMG (dyskusja) 10:05, 12 wrz 2019 (CEST)

Zgłosiłem na to defekt. PMG (dyskusja) 10:18, 12 wrz 2019 (CEST)

Teraz jest chyba dobrze. --Wargo (dyskusja) 22:37, 16 wrz 2019 (CEST)

Tak, jeszcze na to zerknę trochę. Poza tym widzę że ktoś to oznacza bo poznikało trochę z listy rzeczy, których ja nie oznaczyłem :P PMG (dyskusja) 10:19, 17 wrz 2019 (CEST)

Czytniki epub

Witam, Bardzo podobają mi się pozycje w wikiźródłach, ale mam pytanie. Dla kogo tworzycie pliki w formacie epub? Dla ludzi korzystających z czytników? Nie wydaje mi się. Czytniki są tak prostymi urządzeniami, przynajmniej na razie, że dla nich odpowiedniejszym formatem jest epub 2. Czytniki nie są w stanie wykorzystywać wszystkich znaczników stylów z css. Nie są w stanie prawidłowo obsługiwać tabel. Wariują gdy gdy w css znajduje się błąd. Czemu w kodzie html formatowanie z css zastąpione zostaje przez formatowanie wewnątrz tekstu ( np. <div style="">). Po co odnośniki do skanów źródłowych; zresztą ukryte. Wydaje mi się, że forma przerosła treść, a twórcy zapomnieli o naczelnej zasadzie programistów BUZI (bez udziwnień zapisu idioto). Rozumiem, że chcecie zrobić super plik multimedialny, ale większość ludzi czyta epuby na czytnikach, a nie na komputerach lub tabletach. Dlatego na epub należy patrzeć jak na książkę papierową, a nie plik multimedialny. -- niepodpisany komentarz użytkownika 91.222.140.70 (dyskusja | wkład)

Po pierwsze, epub jest formatem bazowym używanym do generowania wszystkich innych (mobi, pdf, txt) przez używane narzędzie. Dlatego nawet jeżeli jest on mało przydatny, i tak jest niezbędny a jego obecność niewiele kosztuje. Z tabelami rzeczywiście jest problem, ale na to chyba niewiele obecnie można poradzić poza sukcesywnym rezygnowaniem z nich przy opracowywaniu tekstów. Ale nie wszędzie się da.

Po drugie, nie rezygnujemy z css, bo w odróżnieniu od styli inline nigdy go u nas na szeroką skalę nie było. Problem z css jest taki, że przerobienie wszystkich możliwych styli występujących w tekstach na uniwersalne klasy w taki sposób, by niczego nie popsuć (zwłaszcza, że mamy nadal mnóstwo kodu opartego jeszcze na HTML4) to jest multum roboty dla wielu osób. A nas jest garstka wolontariuszy, którzy niekoniecznie znają się na css.

Po trzecie, jeśli chcesz pomóc, zapraszamy do współpracy. Ankry (dyskusja) 11:14, 6 paź 2019 (CEST)

• Wtrącę w temacie swoje 3 grosze, jako w pewnym sensie odpowiedzialny za taki stan rzeczy. Przybyłem na Wikiźródła właśnie w poszukiwaniu utworów, które zazwyczaj czytam na Kindlu - właściwie o Źródłach dowiedziałem się na Świecie Czytników, i kiedy się tutaj pojawiłem (chyba w 2014) pobranie jakiegokolwiek tekstu, szczególnie w zjadliwym dla czytnika formacie było baaardzo utrudnione. Jednak możliwość pobierania tekstów w formatach zewnętrznych była ważną sprawą dla międzynarodowej społeczności źródeł. Aby ułatwić życie czytelnikom (m.in. nam, czytnikowcom), międzynarodowa społeczność wolontariuszy stworzyła narzędzie pozwalające w locie eksportować teksty ze źródeł (Wsexport). A jest to o tyle karkołomne zadanie, że teksty na źródłach wciąż żyją (są przeglądane, poprawiane i uwierzytelniane przez kolejnych użytkowników, dopisywane są kolejne rozdziały, teksty powstają czasami latami, tworzone przez kilku wolontariuszy, mających różne przyzwyczajenia, ....), tak więc (także z powodu tego, że wolontariuszy jest zdecydowanie za mało, aby tworzyć dedykowane epuby dla poszczególnych pozycji) jedynym rozwiązaniem było automatyczne tworzenie plików (w tym epub) na żądanie. Zaimplementowaliśmy je także u nas, co spowodowało, że praktycznie 90-cioma% pozycji możemy się cieszyć pobierając je i czytając także na czytnikach. Teraz kwestie, które poruszyłeś - możesz pobrać każdą pozycję w epub2 wybierając odpowiedni format bezpośrednio w Wsexport wpisaując tytuł strony ze Źródeł; eksporter z definicji nie zastępuje css przez formatowanie wewnątrz tekstu, lecz aby zachować uniwersalność ze wszystkimi wersjami językowymi wprowadza jedynie pewne uproszczenia [26]; tabele to osobny problem, tutaj chyba nigdy nie będzie złotego środka, lecz nie mamy ich zbyt dużo, a Kindelki jakoś sobie radzą; odnośniki do skanów źródłowych; zresztą ukryte są, ponieważ istnieją także ukryte w naszych tekstach, a są one ważne ze względu na możliwe do implementacji automatyczne odnośniki w plikach do konkretnej strony w źródle. Istniałaby możliwość ich usunięcia dla naszej wiki lokalnie, lecz musiałby istnieć ważny powód (mi nie przeszkadzają w czytaniu (bo ich nie widać :) ), poza tym to jedynie kilka bajtów, raczej nie stanowiących problem wagi pliku dla czytnika). Zaręczam, że twórcy narzędzia nie zapomnieli o naczelnej zasadzie programistów, wręcz przeciwnie, narzędzie jest najprostsze jak to możliwe (a wielce efektywne, dość wspomnieć, że generuje powyżej 100 000 plików miesięcznie); zaręczam także, że nie było naszą intencją zrobienie pliku multimedialnego. Chodziło o sprawne i efektywne obsłużenie tysięcy żądań przez serwer, i co bardzo ważne, udostępnienie naszych tekstów dla wszystkich w najpopularniejszych formatach bez angażowania wolontariuszy, których po prostu jest za mało, a wolą skupiać się nad powiększaniem księgozbioru, niż na myśleniu o technikaliach.
  

Życzę więc wielu radości w konsumpcji naszych utworów, i proszę o przymykanie oczu na pewnie niedoskonałości składu :))) Zapraszamy oczywiście do współpracy. Zdzislaw (dyskusja) 15:29, 6 paź 2019 (CEST)

• No niestety, co książka, to inne formatowanie - brak jest jednolitych stylów formatowania i redakcji książek, jakie mają na przykład Wolne Lektury. Na moim e-czytniku na przykład nie działają książki z Wikiźródeł, urządzenie nie jest w stanie otworzyć poprawnie plików epub z Wikiźródeł (z wyjątkami). Pomaga jedynie usunięcie z pliku strony tytułowej czy spisu treści (nie mylić z toc.xml wewnątrz pliku, czy jakoś tak) poprzez edytor ebooków w Calibre. Matlin (dyskusja) 15:07, 9 paź 2019 (CEST)

• @Matlin: gdybyś mógł podać jaki to czytnik, przykład pozycji, która nie działa, przykład takiej która działa, przykład tego co musisz usuną i z jakiego pliku usuwasz... być może udałoby się znaleźć przyczynę blokowania działania na Twoim czytniku i coś ulepszyć w generatorze, Zdzislaw (dyskusja) 21:32, 10 paź 2019 (CEST)

Błąd w niekorygowaniu

Nie mogę skorygować strony Strona:PL Waleria Marrené-Mąż Leonory 042.jpeg - przy próbie zmiany statusu na skorygowaną wyświetla się komunikat "Błąd: Ta akcja została automatycznie zidentyfikowana jako szkodliwa, w związku z tym została odrzucona. Jeśli uważasz, że ta edycja była zasadna, skontaktuj się z administratorem i poinformuj go o zaistniałej sytuacji. Krótki opis reguły nadużycia, do której Twoja akcja została dopasowana: zmiana statusu czerwony -> żółty przez tego samego użytkownika". Tymczasem w historii edycji tej strony nie widzę, bym kiedykolwiek zmieniała jej status... Salicyna (dyskusja) 21:00, 13 paź 2019 (CEST)

@Salicyna: system widzi twoją zmianę, z 2016 jako "Przepisanie" i dlatego nie daje ci skorygować, z jakiegoś powodu w niektórych przypadkach tak się robi. Najłatwiej chyba w tym przypadku żebyś anulowała swoją poprzednią edycję i wprowadzone wtedy zmiany wprowadziła na nowo przy zmianie statusu na "Skorygowana". Joanna Le (dyskusja) 21:14, 13 paź 2019 (CEST)

Kiedy próbuję wycofać moją poprzednią zmianę, z kolei wyświetla mi się "Błąd: Ta akcja została automatycznie zidentyfikowana jako szkodliwa, w związku z tym została odrzucona. Jeśli uważasz, że ta edycja była zasadna, skontaktuj się z administratorem i poinformuj go o zaistniałej sytuacji. Krótki opis reguły nadużycia, do której Twoja akcja została dopasowana: wykrywanie pomyłek pp/pk" i znowu nie mogę zapisać... ;) Salicyna (dyskusja) 21:22, 13 paź 2019 (CEST)

@Salicyna: zdaje się, że jako administrator na czas takiej edycji możesz wyłączyć filtr 6, który uniemożliwia zmianę statusu czerwony -> żółty przez tego samego użytkownika, ale jak to dokładnie działa to niestety nie pomogę. Joanna Le (dyskusja) 22:15, 13 paź 2019 (CEST)

@Salicyna: problem wynika z przeszłych zmian w rozszerzeniu proofreadpage: pierwotnie nie odnotowywało ono w nagłówku nazwy użytkownika, który ustawiał status czerwony. Od pewnego czasu robi to i w efekcie, jako użytkownik ustanawiający status czerwony, odnotowywany jest ten, kto pierwszy edytował daną stronę przy tym statusie, bez jego zmiany (jeśli takie edycje miały miejsce). Z drugiej strony, abusefilter ma dostęp tylko do ostatniej edycji i nie może analizować całej historii strony. Efekt jest jak widziałaś. Jeśli uważasz, że filtr sprawia więcej kłopotów niż z niego pożytku, nie krępuj się i wyłącz go. "Poprawić" go się nie da. Przypisać czerwonych edycji właściwym użytkownikom też nie za bardzo (zmienić użytkownika przypisanego do danej zmiany statusem można chyba tylko zmianiając status strony (chyba, że pole to jest puste). Ankry (dyskusja) 08:15, 14 paź 2019 (CEST)

Nie wiem, czy filtr sprawia więcej kłopotów niż z niego pożytku, osobiście pierwszy raz miałam przez niego problem z edytowaniem. Po prostu miałam pecha, że jednocześnie blokował mnie filtr korygowania i filtr pp/pk przy próbie anulowania... Salicyna (dyskusja) 09:02, 14 paź 2019 (CEST)

Problem z plikami EPUB na czytnikach

W ostatnich paru tygodniach widziałem doniesienia użytkowników czytników, że są problemy z działaniem plików EPUB z Wikiźródeł. Tu przykładowa konwersacja na grupie eCzytelnicy na FB. Grupa jest publiczna, można czytać bez logowania.

Postanowiłem to sprawdzić i wgrałem dwie książki na PocketBook Touch HD 3, jeden z lepszych dostępnych czytników, obsługujący w dużym stopniu format EPUB 3:

• Podróże Guliwera - otwiera się, zmieniam kilkanaście stron, program zamyka książkę automatycznie. Tak samo przy próbach nawigacji.

• Żywot Jezusa - otwiera się na pierwszej stronie, nie jestem w stanie przejść dalej.

Edit: na Kobo jest tak samo, czytnik restartuje się po kilkunastu stronach, niezależnie czy to EPUB2 czy EPUB3.

Sprawdziłem oba pliki w walidatorze Flight Crew, używanym też w programie Sigil (to popularny edytor epubów). Dla obu plików program wywala setki błędów, w rodzaju pominięte i niewłaściwe atrybuty HTML. Tu przykładowe screeny: [27] oraz [28].

Podobnie z walidatorem w3c.

Dla porównania sprawdziłem kilka książek zakupionych w księgarniach - zwykle błędów nie ma, albo jest ich kilka.

Nie znam się na robieniu epubów, wiele z tych błędów wydaje się nieistotnych (przeglądarka powinna zignorować np. nieistniejącą właściwość taga), ale być może ich nagromadzenie powoduje problemy. Trudno mi też określić, czy jest to problem obecnego narzędzia do generowania e-booków, a nie samego źródła HTML, które jest wykorzystywane. W tym drugim przypadku generator powinien filtrować odpowiednio HTML, tak aby pozbywać się elementów niezgodnych z walidatorem. Ktoś ma pomysł, co z tym możemy zrobić? rdrozd (dysk.) 00:53, 20 paź 2019 (CEST)

Dzięki @Rdrozd:, godzina późna, ale od rana będziemy mieli wyjątkową koncentrację właściwych osób we właściwym miejscu (na razie poszli do hotelu). A i zasugeruję obserwowanie tej grupy, na której zgłoszenie się pojawiło - rozsądni ludzie. Bonvol (dyskusja) 01:01, 20 paź 2019 (CEST)

Mi się jutro mam nadzieję uda wpaść na Źródłosłów, więc pokażę na żywo, co nie działa :) a jak widzę jeden z dyskutantów z grupy odzywał się powyżej jako IP... rdrozd (dysk.) 01:19, 20 paź 2019 (CEST)

• @Rdrozd: Dziękujemy za informacje - w miarę wolnych mocy przerobowych będę starał się zidentyfikować przyczyny problemów. Sprawdzałem przykładowe pozycje przy pomocy Flight Crew i rzeczywiście dla oby pozycji zgłasza setki ostrzeżeń - jednakże wynika to raczej z epub-3, którego mogą słabo trawić, szczególnie starsze czytniki. Wydaje mi się, iż dobrym rozwiązaniem byłoby generowania i pobieranie epubów w wersji 2, lista błędów wskazywanych przez walidator spada bardzo drastycznie, ograniczając się jedynie do dwóch pominiętych deklaracji dla każdego z obrazków, tutaj do pobrania w formacie 2.0:

Żywot Jezusa (epub2)

Podróże Gulliwera (epub2)

za które oczywiście zabierzemy się w ramach wolnego czasu. Gdybyś Rdrozd zobaczył jak zachowują się na czytniku. Prosiłbym o zgłaszanie tutaj kolejnych uwag i błędów, w miarę możliwości będziemy starali się poprawić (przynajmniej lokalnie), pamiętając, że narzędzie generowania epubów obsługuje wszystkie wersje językowe. Zdzislaw (dyskusja) 10:13, 20 paź 2019 (CEST)

• @Rdrozd: Jeszcze raz dziękuję za pomoc w identyfikacji problemów z dostępnością naszych utworów, odkrycie, iż użycie br-ów do wydzielenia akapitów powoduje poważne problemy jest ogromnie cenne, lecz zanim podejmiemy decyzje o zmianach w formatowaniu (przełomowych dla ws) istnieje potrzeba potwierdzenia ich wpływu. Potraktować chciałbym Podróże Guliwera i Żywot Jezusa jako indeksy ćwiczebne, dla których zmieniona zostanie źródłowe formatowanie, po czym będę Cię prosił o testy. @Ankry:, potrzebowałbym w pierwszej kolejności Twojej pomocy, aby przebotować wszystkie strony powyższych dwóch indeksów z dokonaniem zmian typu \<br ?\/?\>\n\{\{tab na \n\n\{\{tab. Czy mam wpisać zadanie dla bota? :)Zdzislaw (dyskusja) 21:58, 20 paź 2019 (CEST)
  • @Zdzislaw: Właśnie miałem poruszyć ten sam temat. Zadanie można stworzyć, na razie pod dyskusję. Jednak istotniejsze według mnie jest to, że "naprawienie" usterki będzie się wiązało ze zmianą naszych przyzwyczajeń, opracowaniem nowych standardów, a wtedy można myśleć o (prawdopodobnie półautomatycznej) konwersji tekstów, które mamy. Decyzja jest na tyle ważna, że powinniśmy ją podjąć w szerszym gronie i wyjaśnić konsekwencje całej społeczności. Ankry (dyskusja) 22:12, 20 paź 2019 (CEST)
    • @Ankry:, ależ oczywiście, lecz zanim rozpoczniemy dyskusję nad zmianą standardów, wolałbym najpierw potwierdzić przypuszczenie i przetestować to dokładnie. Dlatego w tych celach chciałbym przebotować jedynie te dwa indeksy. Zmiana ta nie wpłynie na ich wygląd, a pozwoli na dogłębne testy. Zdzislaw (dyskusja) 22:17, 20 paź 2019 (CEST)
      • OK. Ankry (dyskusja) 22:19, 20 paź 2019 (CEST)
      • @Zdzislaw, @Rdrozd: Przerobiłem na akapity również Potop Sienkiewicza. To tak dla sprawdzenia, czy rozmiar ma dla tych czytników znaczenie... Ankry (dyskusja) 16:25, 21 paź 2019 (CEST)
  • Ja jeszcze w tygodniu spróbuję przerobić i przetestować tak inne epuby (np. tę "Wojnę i pokój" zgłaszaną na FB) i sprawdzę czy to załatwia problem. rdrozd (dysk.) 22:34, 20 paź 2019 (CEST)

@Zdzislaw, @Ankry: No i nie wiem, o co chodzi. :-( Ściągnąłem te dwie książki w wersji z akapitami + Potop i... tak samo nie działa. "Żywot Jezusa" wywala się na pierwszej stronie (choć to może kwestia tabelki ze spisem treści o której wspominałem na spotkaniu). "Potop" na pierwszej stronie w ogóle zawiesza czytnik. A "Podróże" działają różnie: na jednym czytniku wywala się po 1/3 książki, na innym działa, ale ma problemy ze zmianą stron - skacze np. między 17 i 24 i z powrotem. W źródle EPUB na pewno są akapity zamiast przełamań.

Otworzyłem jeszcze raz "Podróże" w mojej wersji, którą na szybko zrobiłem podczas Źródłosłowu (mechaniczna zamiana <br /> na <p> plik tutaj: [29]) i działa... Nie mam pojęcia dlaczego. Porównałem źródła HTML pierwszego rozdziału - różnice oczywiście są w liczbie i układzie akapitów, czasami jakieś dodatkowe divy, ale czy to jest decydujące? Nie mam pojęcia. W każdym razie obecna metoda nadal nie działa. rdrozd (dysk.) 19:33, 21 paź 2019 (CEST)

@Rdrozd: Strzelam: może się czytnikom nie podoba coś co MediaWiki umieszcza pomiędzy akapitami? Spróbuj może z tego "niedziałającego" ePuba usunąć wszystkie </p>.

@Rdrozd: wywaliłem tabelkę ze strony tytułowej i spisu treści w Żywot Jezusa, ściągnij ponownie i przetestuj w wolnej chwili, Zdzislaw (dyskusja) 22:27, 21 paź 2019 (CEST)

@Zdzislaw: Z "Podróży" usunąłem wszystkie </p>, wywala się teraz na obu czytnikach solidarnie w okolicy nagłówka "ARTYKUŁY OSKARŻENIA" - tam jest dużo obrazków, może o to chodzi.

Co do "Żywota" - bez zmian, wysypuje się na okładce. Jedno co pozytywne, że po usunięciu tabelki na Kindle w wersji MOBI działa spis treści. rdrozd (dysk.) 19:20, 23 paź 2019 (CEST)

MediaWiki:Abusefilter-pagestatusrestrictions

Nie masz uprawnień do zmiany statusu proofread tej strony. Uprawnienia zmiany statusu stron maję tylko zalogowani użytkownicy. → Nie masz uprawnień do zmiany statusu proofread tej strony. Uprawnienia zmiany statusu stron mają tylko zalogowani użytkownicy. 83.31.86.73 (dyskusja) 00:11, 22 paź 2019 (CEST)

Dziękujemy za zauważenie błędu, już poprawione. Pozdrawiam, Salicyna (dyskusja) 00:13, 22 paź 2019 (CEST)

przypis w przypisie

Czy mamy metodę wstawienia przypisu w przypis? Taka sytuacja pojawia się m.in. tutaj z odnośnym dwupoziomowym przypisem stąd. Pamiętam, że kiedyś to było niemożliwe; czy się to obecnie zmieniło? Czy jest jakiś szablon na wzór wikipedyjnego {{w:Szablon:Refn}}? Vearthy (dyskusja) 23:10, 23 paź 2019 (CEST)

Można przez #tag, szablonu na wzór wikipedii nie mamy. Ankry (dyskusja) 02:12, 24 paź 2019 (CEST)

Super! Jest tylko jedno ale, w obecnym kształcie uwaga do przypisu pojawia się nieco nieintuicyjnie przed właściwym przypisem, w którym do tej uwagi jest odnośnik. Da się to jakoś obejść czy wymaga to zbyt dużo roboty? Vearthy (dyskusja) 02:23, 24 paź 2019 (CEST)

owszem jest sposób, zagnieżdżony przypis we właściwej kolejności Draco flavus (dyskusja) 22:47, 16 sty 2023 (CET)

Linki w pdf

W Język międzynarodowy linki spisu treści w pdf prowadzą do strony internetowej a nie do stron pdf. Jak to naprawić? Marek Mazurkiewicz (dyskusja) 08:28, 26 paź 2019 (CEST)

Dodać do epuba strony do których linki kierują na wiki (stron do których linki nie działają nie ma w epubie). Tylko, nie wiem, czy wtedy będzie lepiej, bo będzie dublowana treść: teraz mamy cały rozdział, dojdą jeszcze jego podrozdziały, każdy na osobnej stronie i z własnym szablonem licencji. Można zostawić tylko te podrozdziały, ale do czego ma wtedy linkować link do strony głównej rozdziału?

Chyba, że masz pomysł, jak zrobić w MediaWiki różne linki w zależności od narzędzia, które pobiera stronę w HTML? Ankry (dyskusja) 14:09, 26 paź 2019 (CEST)

Czy przeniesienie podstron pod Język_międzynarodowy/nazwa_rozdziału by nie pomogło? Język międzynarodowy/tył działa w epubie poprawnie, a ma w spisie treści podaną ścieżkę względną. --Wierzbowski (dyskusja) 21:00, 26 paź 2019 (CEST)

@Wierzbowski: Przeniesienie niczego nie zmieni, tylko nazwy. Weźmy taki przykład: w tej chwili "Przedmowa" linkuje do strony Przedmowa do Języka międzynarodowego (i jest e ebooku), a "Do czytelnika" linkuje do strony Przedmowa do Języka międzynarodowego/Do czytelnika (która nie wchodzi w skład ebooka, bo jej treść stanowi początek poprzedniej strony). Jeślibyśmy dołączyli tę ostatnią do ebooka, to co z pierwszą? Zostawiamy i dublujemy treść? Zastępujemy czymś innym - czym? Ebook to są po prostu scalone różne strony wiki. O ile wiem, nie ma obecnie możliwości tworzenia w ebooku linków do sekcji na stronach, jedynie do osobnych stron.

Być może jakimś rozwiązaniem byłoby zastąpienie strony z całą przedmową, stroną z fragmentem spisu treści (rozdziały przedmowy). Tylko czy takie rozczłonkowanie przedmowy na osobne strony + licencje ma w ebooku sens? Nie twiardzę, że nie ma problemu; tylko nie widzę dobrego sposoby na jego rozwiązanie. Być może linki do wiki to mniejsze zło.

A może @Zdzislaw: ma jakiś pomysł? Ankry (dyskusja) 21:34, 26 paź 2019 (CEST)

• @Ankry, @Wierzbowski: w mojej ocenie całkowicie zbędne jest dublowanie treści na stronach - jeżeli mamy osobne podstrony np. dla Przedmowa do Języka międzynarodowego/II/I to nie widzę potrzeby aby ta treść "I. Patr͵o ni͵a...." była także na Przedmowa do Języka międzynarodowego/II... Chyba, że czegoś nie dostrzegam... Zdzislaw (dyskusja) 17:54, 28 paź 2019 (CET)
  • @Zdzislaw: A jaka treść powinna być według ciebie na Przedmowa do Języka międzynarodowego? Ankry (dyskusja) 18:17, 28 paź 2019 (CET)
    • @Ankry: Przy takim podziale podstron, to chyba tylko nagłówek z linkami do podstron... Zdzislaw (dyskusja) 18:20, 28 paź 2019 (CET)
• @Wierzbowski, @Wieralee: Zatem jak widzicie, rzecz polega na tym, by w epubie znalazły się wszystkie strony podlinkowane ze spisu treści i by były one rozłączne. Natomiast w którą stronę / jak to należy poprawić, to jest wasza decyzja. Ankry (dyskusja) 18:30, 28 paź 2019 (CET)

Google Code-In will soon take place again! Mentor tasks to help new contributors!

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributor about two or three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have any Lua, template, gadget/script or similar task that would benefit your wiki? Or maybe some of your tools need better documentation? If so, and you can imagine enjoying mentoring such a task to help a new contributor, please check out mw:Google Code-in/2019 and become a mentor. If you have any questions, feel free to ask at our talk page. Many thanks in advance! --Martin Urbanec 08:28, 5 lis 2019 (CET)

Blokowanie adresów IP

Chciałbym zwrócić uwagę naszym administratorom, że w dużych sieciach (Orange, Plus, Cyfrowy Polsat itp.) adresy IP są zazwyczaj przydzielane użytkownikom dynamicznie. Oznacza to, że użytkownik łącząc się z siecią dostaje losowo jeden z adresów z pewnego zakresu, który to adres po pewnym czasie może zostać przydzielony innemu użytkownikowi, a dany użytkownik może po chwili otrzymać zupełnie inny adres. Oznacza to, że:

1. długoterminowe blokowanie takich adresów nie ma sensu
2. blokowanie użytkowników zalogowanych z takich adresów również zazwyczaj nie ma sensu
3. trudno skutecznie zablokować jednego użytkownika (można wprawdzie zablokować całą sieć, ale to eliminuje możliwość edycji przez wszystkich potencjalnych niezalogowanych użytkowników danej sieci i jednocześnie uniemożliwia im założenie kont)

Jak sprawdzić z jakiej sieci dany użytkownik korzysta? Służy do tego baza WHOIS, którą można odpytać korzystając z różnych stron internetowych, jak np. ta (wybrałem pierwszą z brzegu; jest ich wiele). W bazie znajdują się informacje o operatorze sieci, kraju oraz, co ważne, o pełnym zakresie adresów IP danego operatora, do którego dany adres należy (operator może mieć wiele takich zakresów, ale to sprawa drugorzędna).

Od pewnego czasu MediaWiki pozwala zarówno na blokowanie całych zakresów IP, jak tez sprawdzanie wkładu użytkowników z wybranego zakresu, co pozwala administratorom podejmować decyzje o ewentualnej blokadzie. Kilka przykładów:

IP=‎37.248.155.254
Operator: Cyfrowy Polsat S.a
Zakres IP: 37.248.152.0/21 (tzn. od 37.248.152.0 do 37.248.183.255)
Edycje z tego zakresu: Specjalna:Wkład/37.248.152.0/21

Albo:

IP=2A00:F41:4894:D68C:ECE1:157E:56DB:BDE4
Operator: Orange Polska Spolka Akcyjna
Zakres IP: 2a00:f40::/29 (tzn. od 2a00:f40:: do 2a00:f47:ffff:ffff:ffff:ffff:ffff:ffff)

(niestety ten zakres jest zbyt szeroki, by odpytać o edycje z całego zakresu lub go zablokować, ale możemy po prostu wziąć fragment, do którego należy "nasz" podejrzany adres, kopiując jego początkowy fragment - dwie 16-bitowe sekcje)

Edycje z zakresu 2A00:F41::/32 : Specjalna:Wkład/2A00:F41::/32

itd.

Zdaję sobie sprawę, że większość administratorów Wikiźródeł nie jest "specjalistami od sieci", stąd powyższe wyjaśnienie. @Cafemoloko, @Bonvol, @Fallaner, @Himiltruda, @Joanna Le:@Nawider, @Salicyna, @Wieralee, @Zdzislaw: Czy uważacie, że warto zrobić w tym celu specjalizowaną instrukcję? (A może już taka gdzieś jest; na Wikipedii?).

Według mnie wandalizmy w IP nie są jeszcze u nas na tyle dokuczliwe, by blokować całe zakresy IP (utrudniając tym samym założenie kont użytkownikom z zablokowanych sieci). Ale może warto rozważyć zablokowanie edycji mobilnych przez niezalogowanych użytkowników (poprzez AbuseFilter z komunikatem typu "aby edytować załóż konto i zaloguj się"): [30] AbuseFilter bardziej obciąża serwery (choć dla ruchu z/do Wikiźródeł to nie powinien być problem), ale jest bardziej selektywny (można np. nie blokować możliwości założenia konta czy edycji na stronach dyskusji)

Uwagi, komentarze? Ankry (dyskusja) 13:21, 5 lis 2019 (CET)

Dzięki Ankry za zajęcie się sprawą. Opcja włączenia AbuseFilter dla IP-ków ze wskazaniem: zarejestruj/zaloguj się najpierw jest daleko idąca, ale na ile sięgam ostatnio pamięcią, to proporcja przyjętych edycji z IP-ków do wygłupów jest niewielka; więc ignorowanie wkładu IPków może u nas mieć rację bytu. Niemniej: czy uważasz, że liczba wandalizmów jest już u nas na tyle problemem, by szukać systemowych rozwiązań? Włączyłem też sobie gadżet "Dynamiczne adresy IP" (w Preferencjach). Bonvol (dyskusja) 14:24, 5 lis 2019 (CET)

Nie wiem. Dlatego poddaję temat pod dyskusję. Administratorów mamy w sumie sporo... Ankry (dyskusja) 16:13, 5 lis 2019 (CET)

Sądzę że na Wikiźródłach mamy do czynienia z takimi wandalizmami na tyle rzadko, że nie wiem czy nie szkoda czasu i pracy na tworzenie jakichś specjalnych narzędzi. Może wystarczy ustalenie zasady co do blokowania IP-ków, tzn. jak długa powinna być ta blokada. Ja do tej pory nr IP blokowałam jedynie na 1 dzień, ale może wystarczy na 1h? Ale w sumie to na sieci się nie znam :) Joanna Le (dyskusja) 19:00, 5 lis 2019 (CET)

Podzielam zdanie Joanna Le, że wystarczy określić mniej więcej na jaki czas zablokować dany adres, faktycznie 1 dzień wydaje się być optymalny. Do czasu kiedy ingerencje w tekst nie będą naprawdę wyzwaniem tj. bardzo bardzo mała liczba wikiskrybów lub bardzo duża liczba ingerencji to można sobie odpuścić. Bardziej mnie zastanawia @Ankry: skąd wiesz czy nowo utworzone konto np. Michał 453, Basia454 powstało w celach destrukcyjnych, można to jakoś próbować sprawdzić? Nawider (dyskusja) 21:57, 5 lis 2019 (CET)

Te które blokuję, próbowały spamować, ale zostały zablokowane przez abusefilter (patrz Abuselog). Zdaje się, że w planach jest danie abusefiltrowi możliwości blokowania takich użytkowników automatycznie. Ankry (dyskusja) 22:03, 5 lis 2019 (CET)

Trzeba ustawić $wgAbuseFilterActions['block'] aby włączyć możliwość blokowania --Wargo (dyskusja) 15:42, 6 lis 2019 (CET)

Z mojego doświadczenia: spam-boty tworzą zwykle konta o nazwach typu zlepek: NameSurname (pisane bez spacji zwykle in English, losowo wybrane ze swojej bazy danych imion i nazwisk) więc na tego typu konta trzeba zwracać przede wszystkim uwagę. Przy czym nie zawsze od razu wklejają spam, czasami mogą odczekać kilka dni... Electron  ^<Odpisz> 06:39, 6 lis 2019 (CET)

Nowa grupa uprawnień do celów technicznych

Dzisiaj, próbując odtworzyć materiały, które przeszły do domeny publicznej natrafiliśmy z Himiltrudą na problem na stronach [[31]] i następnych. Okazuje się, że aktualna wersja oprogramowania ProofreadPage uniemożliwia odtworzenie skasowanej wcześniej wersji uwierzytelnionej strony użytkownikom nie posiadającym uprawnienia "pagequality-admin", którego posiadanie pozwala użytkownikowi ignorować ograniczenia ProofreadPage dotyczące zmiany statusu strony.

Problem został zgłoszony na phabricatorze: phab:T241691. Trudno w tej chwili powiedzieć, czy zostanie to uznane za bug czy za ficzer, ani kiedy problem zostanie rozwiązany, jeśli to bug. Jak wiemy, proces poprawiania błędów w oprogramowaniu trwa zwykle miesiące.

W chwili obecnej, uprawnienia "pagequality-admin" nie zawiera żadna istniejąca grupa użytkowników, więc nie można go nikomu nadać. Z drugiej strony, jak jest wyjaśnione w phab:T167491, kiedy parę lat temu zostało ono przyznane adminom, żaden użytkownik nie powinien dysponować tym uprawnieniem "na stałe" (gdyż mógłby w niekontrolowany sposób zmieniać stan korekty stron).

W związku z powyższym, proponuję utworzenie nowej grupy uprawnień użytkowników (nazwanej roboczo "proofread-admin" lub "proofreadpage-admin" - "Administrator statusu korekty"?), która zawierałaby wyłącznie to uprawnienie i mogła być nadawana i odbierana (a) dowolnemu użytkownikowi przez biurokratę w razie uzasadnionej potrzeby, lub (b) administratorzy mogliby ją nadawać i odbierać samym sobie w razie takiej potrzeby. Uważam, ze administratorzy są odpowiedzialnymi użytkownikami i nie będą nadużywać tego uprawnienia, dlatego jest mi obojętne, który wariant zostałby wybrany. Z drugiej strony, uprawnienie to powinno być potrzebne niezmiernie rzadko. Wygląda na to, że od dwóch lat żadne Wikisource tego dotąd nie potrzebowały; jesteśmy pierwsi.

Innym możliwym rozwiązaniem jest odtworzenie stron w wersji "Skorygowana" i uwierzytelnienie ich ponownie. Jednak jestem przeciwny takiemu rozwiązaniu, gdyż uważam, że byłoby ono nie fair w stosunku do użytkowniczki, która je już wcześniej uwierzytelniła (Lilibalu).

@Ajsmen91, @Cafemoloko, @Bonvol, @Fallaner, @Joanna Le:@Nawider, @Salicyna, @Wieralee, @Zdzislaw: proszę was o opinię, co robimy w tej sytuacji: czekamy na rozwiązanie problemu (mam nadzieję) w nowej wersji oprogramowania, czy występujemy o utworzenie nowej grupy uprawnień dla obejścia problemu i, w tym wypadku, który wariant przyznawania uprawnień preferujecie: (a) czy (b). Oczywiście opinie innych użytkowników, nie-administratorów, też są mile widziane Ankry (dyskusja) 11:53, 2 sty 2020 (CET)

No i nie pingnąłem wszystkich, więc się poprawiam: @Ajsmen91, @Cafemoloko, @Bonvol, @Fallaner, @Joanna Le: @Silvanka, @Electron, @Zetzecik, @Anwar2, @Draco flavus: Ankry (dyskusja) 11:56, 2 sty 2020 (CET)

I jeszcze @Wierzbowski, @Wydarty, @Maire, @Alenutka, @Wolan: to chyba już wszyscu z OZ; przepraszam, jeśli kogoś pominąłem. Ankry (dyskusja) 11:59, 2 sty 2020 (CET)

• Kiedyś też natknąłem się na podobny problem na innej wiki, że nie mogłem w pełni odtworzyć strony, którą przed chwilą skasowałem, bo Mediawiki nie pozwalała odtworzyć wersji sprawdzonej przez kogoś innego. W sumie to wszystko jedno jak to będzie rozwiązane byleby ktoś miał takie uprawnienia. Electron  ^<Odpisz> 12:12, 2 sty 2020 (CET)
• Problem w praktyce ma miejsce jedynie na początku roku, gdy utwory trafiają do domeny publicznej. Mnie wielokrotnie samo Mediawiki przypominało, że nie mogę podbić statusu strony, bo rok temu akurat coś na niej poprawiałem i wtedy przy okazji np. skorygowałem. Obie opcje (a) i (b) są dla mnie OK - przy czym kluczowe jest, by w wariancie (b) od razu na kalendarzu nakleić kartkę "odebrać sobie uprawnienia za 2 dni". Bonvol (dyskusja) 12:21, 2 sty 2020 (CET)
  • Ja bym powiedział nawet, że za 10 min., zaraz po wykonaniu niezbędnej operacji. Jednak z drugiej strony, jeśli stronę korygowałeś, nawet rok temu, to nie powinieneś jej uwierzytelniać. Byłoby to wbrew zasadom, których chyba nie chcemy zmieniać? Ankry (dyskusja) 13:00, 2 sty 2020 (CET)
    • Oczywiście. Dałem przykład, że oprogramowanie, przez swoje walidacje dotyczące statusu, nie zmusza mnie do sprawdzania na każdej stronie "czy już ją kiedyś obrabiałem". Bonvol (dyskusja) 13:13, 2 sty 2020 (CET)
•  Za a i b (prędzej jeśli tylko jedno to raczej a)- Mnie osobiście to nie interesuje, ale wyobrażam sobie scenariusz taki, że któryś z nie-administratorów z żyłką porządkową i po prostu mający ochotę się tematem zająć, na początku roku dostaje takie uprawnienia i tyle. Draco flavus (dyskusja) 12:29, 2 sty 2020 (CET)
  • Nie-administratorzy nie maja prawa do usuwania/odtwarzania stron; więc w przypadku tego konkretnego problemu uprawnienie byłoby dla nich bezużyteczne (chyba, że jednocześnie otrzymaliby uprawnienia administratora) Ankry (dyskusja) 12:36, 2 sty 2020 (CET)
    • To w tym momencie raczej b. Draco flavus (dyskusja) 12:43, 2 sty 2020 (CET)
• Obie wersje są wg mnie w porządku. Może dałoby się wprowadzić i a i b jednocześnie - byłoby większe pole manewru w razie potrzeby. Maire (dyskusja) 12:35, 2 sty 2020 (CET)
•  Za a i b (jeśli tylko jedno to raczej b), przekonuje mnie argumentacja Maire Wieralee (dyskusja) 18:43, 2 sty 2020 (CET)
• nie jestem zwolennikiem mnożenia grup użytkowników (tu tworzenia grupy dla jednego uprawnienia), byłem zresztą przeciwny usunięciu go z grupy adminów, szkoda słów... jeżeli już to  Za b, Zdzislaw (dyskusja) 19:46, 2 sty 2020 (CET)
  • Tu się z tobą nie zgodzę; wg mnie utrzymywanie tego uprawnienia włączonego dla jakiegokolwiek aktywnego użytkownika byłoby strasznie błędogenne i powinniśmy taką praktykę wykluczyć w naszych zasadach. Ankry (dyskusja) 22:54, 2 sty 2020 (CET)
    • cóż, przez wiele lat mieliśmy (mamy teraz ograniczone js-em) możliwość tworzenia żółtych, co jest niezgodne z naszymi zasadami, i jakoś nie zauważyłem, rezultatu starsznie błędogennego wśród edycji adminów. Zdzislaw (dyskusja) 23:55, 2 sty 2020 (CET)
      • Przy tworzeniu strony nie ma problemu sprawdzania czy się ją wcześniej edytowało. A wiem po sobie, ile razy mi się zdarzyło, że byłem przekonany, że strony nie korygowałem, tymczasem jednak... Ankry (dyskusja) 08:01, 3 sty 2020 (CET)
    • samo b też nie jest takie złe... okrężną drogą, ale można uzyskać te uprawnienia także przy pomocy biurokraty, jeśli się wykaże że projekt umarł i nie ma komu głosować w PUA. Wieralee (dyskusja) 11:08, 3 sty 2020 (CET)
•  Za b Nawider (dyskusja) 21:31, 2 sty 2020 (CET)
•  Za b Cafemoloko (dyskusja) 08:45, 3 sty 2020 (CET)
•  Za b Joanna Le (dyskusja) 12:23, 3 sty 2020 (CET)

Wobec wyraźnego konsensusu, zgłosiłem wniosek phab:T241824. Ankry (dyskusja) 11:45, 3 sty 2020 (CET)

Sprawa na razie upadła... i może lepiej. Po co tworzyć grupy o niejasnym przeznaczeniu? Pliki odtworzył sysadmin skryptem po stronie serwera (pewnie checkuser by się zdziwił, z jakiego to ja adresu operowałem...). Możliwość odtwarzania "zielonych" stron trzeba raczej rozwiązać systemowo, poprawiając proofreadpage, a nie łatając dziury dziwnymi uprawnianiami. Dziękuję wszystkim za udział w dyskusji i... do następnej potrzeby odtwarzania uwierzytelnionych stron. I na koniec prośba do administratorów: ostrożnie z kasowaniem zielonych. Ankry (dyskusja) 15:35, 3 sty 2020 (CET)

Brakujące znaki unicode w przyborniku

Przepisując Sādhanę, zauważyłam, że w części Inne litery brakuje znaków m.in. dla litery m z listy Unicode/Alfabet łaciński/Łaciński rozszerzony dodatkowy: od znaku 7742 do 7747. Brakuje też: b, k, p, v, w i innych.
Można je dodać czy obowiązuje jakieś ograniczenie?
Cafemoloko (dyskusja) 10:20, 12 sty 2020 (CET)

Litery Ḿ ḿ ḿ Ṁ ṁ Ṃ ṃ to zupełna egzotyka. Jeden-dwa teksty może na całych wź. Warto kruszyć kopie? Ja bym sobie na przykład skopiował potrzebne literki do jakiegoś dokumentu tekstowego i Ctrl-C, Ctrl-V. Bardziej fachowo by pewnie było dopisać do common.js Draco flavus (dyskusja) 10:48, 12 sty 2020 (CET)

Myślę, że kilka dodatkowych znaków w przyborniku nikomu nie zaszkodzi, a że rzadko się będą przydawać – taka już ich natura, większość ze znaków w przyborniku rzadko się przydaje. Salicyna (dyskusja) 11:15, 12 sty 2020 (CET)

Można dodać, jeśli uważasz, że warto. Z tym, że od razu dodam kilka uwag:

1. Te znaki są dostępne dla używających tzw. nowego paska edycji (inna nazwa: edytor wikikodu 2010) z menu ("Znaki specjalne" -> "Łacińskie (rozszerzony)"
2. Ja często takie (i inne egzotyczne) znaki dodawałem poprzez C&P ze stron Unicode, które niedawno zostrały zgłoszone do usunięcia.

BTW: diakrytyków greckich też tam nie ma, choć dużo częściej są potrzebne. Ankry (dyskusja) 11:22, 12 sty 2020 (CET)

Tutaj (greka) klawiatura Matlina jest nieoceniona Draco flavus (dyskusja) 11:28, 12 sty 2020 (CET)

Ja korzystam z brudnopisu Salicyny. Ankry (dyskusja) 11:31, 12 sty 2020 (CET)

Aha, jeśli ktoś z adminów ma ochotę jakieś znaki dodawać, to tutaj. Ankry (dyskusja) 11:33, 12 sty 2020 (CET)

To może link do Unicode/Alfabet łaciński/Łaciński rozszerzony dodatkowy w przyborniku z opisem inne znaki? Dla mnie to byłaby wygodniejsze w użyciu, a pewnie też nie każdy korzysta z z edytora wikikodu 2010. Cafemoloko (dyskusja) 11:36, 12 sty 2020 (CET)

Tak, to jest dobry pomysł. Electron  ^<Odpisz> 11:54, 12 sty 2020 (CET)

@Cafemoloko: Ale jaki to ma sens wobec twojej opinii w Wikiźródła:Strony do usunięcia#Unicode/Lista znaków i podstrony? Ankry (dyskusja) 12:09, 12 sty 2020 (CET)

@Ankry: Jestem za usunięciem Indeks:Unicode (HD Table) a nie Unicode/Alfabet łaciński/Łaciński rozszerzony dodatkowy. Cafemoloko (dyskusja) 12:13, 12 sty 2020 (CET)

@Cafemoloko: Mam jednak wrażenie, że zgłaszający mia inne intencje. Proponuję doprecyzowac to w dyskusji PUA. Ankry (dyskusja) 12:19, 12 sty 2020 (CET)

@Cafemoloko, @Ankry: Po usunięciu indeksu przy pozostawieniu podstron strony jak ta: Unicode/Rozszerzony łaciński A zostaną nieuźródłowione. W kategorii Unikod jest też druga grupa — takich spisów jak ten: Unicode/Alfabet łaciński/Łaciński rozszerzony A. Już współistnienie dwóch grup w tej samej kategorii wywołuje spore zamieszanie. Kolega z Wikibooks jest gotów przenieść wszystko — czyli całość kategorii — w obu formach — na Wikibooks, a więc treść będzie nadal dostępna, tylko nie tu. Bonvol (dyskusja) 19:42, 13 sty 2020 (CET)

@Bonvol: ok, to tak zróbcie. Cafemoloko (dyskusja) 20:09, 13 sty 2020 (CET)

Można też chyba skorzystać z możliwości oferowanych przez własny komputer, np. ze wstawiania znaków. Można wykorzystać edytor tekstów, gdzie powinna być opcja: „Wstaw symbol” (bądź coś podobnego) i stamtąd skopiować. Windows 10 ma też coś takiego jak „Tablica znaków”, umożliwiająca skopiowanie stamtąd znaku do dowolnego programu, w tym i do przeglądarki internetowej. Dostęp do tego jest następujący:

• Przycisk startowy ⊞ (po lewej u dołu) > Wszystkie aplikacje > Akcesoria systemu > Tablica znaków

Po przypięciu tej Tablicy do paska ikon u dołu lub do obszaru startowego (tak się chyba te elementy nazywają) dostęp do niej jest bardzo szybki. Nie wiem, czy w innych systemach coś podobnego istnieje, ale pewnie tak, choć raczej nie w starszych wersjach. No i na tabletach / telefonach też pewnie tego nie ma. Maitake (dyskusja) 17:02, 12 sty 2020 (CET)

Kolekcja:100 książek na stulecie niepodległości i Baczyński

W tej kolekcji pozycja z Baczyńskim daje możliwość pobrania "ebooków", zawierających tylko stronę w przestrzeni Autor. Da się to jakoś wyłączyć czy trzeba Baczyńskiego z tej kolekcji wykreślić? --Matlin (dyskusja) 17:10, 23 sty 2020 (CET)

• Generator ebooków pobiera metadane z szablonu {{Dane tekstu}} zamieszczonego na wskazanej stronie i dołącza do ebooka zawartość tych podstron tej strony, które są na niej podlinkowane (oraz odpowiednich podstron tychże podstron - bez głębszej rekursji) lub stron, linki do których znajdują się wewnątrz szablonu {{Summary}} (wtedy bez podstron, natomiast ze stronami objętymi tym samym szablonem na wskazanych stronach).

Zatem należy po prostu wskazać odpowiednią stronę, zawierającą te metadane. Ankry (dyskusja) 17:45, 23 sty 2020 (CET)

Indeks:PL Doyle - Tajemnica oblubienicy i inne nowele.pdf

Od kilku dni mam problem z załadowaniem poprawionego pliku (w oryginale: skany 223 i 224 (strony 210 i 209) są zamienione miejscami) na Commons. Być może to wina mojego wolnego łącza. Byłbym wdzięczny, gdyby ktoś z szybkim łączem wgrał ten poprawiony plik (wystarczy po prostu przestawić kolejność wymienionych stron). W razie trudności z naprawą, mogę też przesłać już poprawiony plik jako załącznik mailem (z uwagi na wielkość pliku w kilku częściach) na podany adres osoby, która by go wgrała potem na Commons. Z góry dzięki za pomoc. Electron  ^<Odpisz> 15:29, 5 lut 2020 (CET)

Spróbuj wrzucić poprawiony plik pod inną nazwę wizardem i podaj pod jaką, a ja je scalę. Ankry (dyskusja) 17:06, 5 lut 2020 (CET)

::To nic nie pomaga. Tak czy owak, po wgraniu ok. 60 MB przerywa upload, a że każda próba przy moim łączu zajmuje ok. 15 min. to to się staje mało zabawne :( Electron  ^<Odpisz> 22:50, 5 lut 2020 (CET)

@Ankry: OK. W końcu jakoś wgrałem jako nowy plik: File:PL Doyle - Tajemnica oblubienicy i inne nowele (fixed).pdf. Trzeba go połączyć ze starym: File:PL Doyle - Tajemnica oblubienicy i inne nowele.pdf. Electron  ^<Odpisz> 01:19, 6 lut 2020 (CET)

Załatwione @Electron: Ankry (dyskusja) 07:58, 6 lut 2020 (CET)

@Ankry: OK. Dzięki. Btw. Wydaje się, że ten Wizard korzysta z jakiegoś trochę innego protokołu przesyłu z informacją zwrotną i jest przez to stabilniejszy. A to ma znaczenie przy dużych plikach. Electron  ^<Odpisz> 12:12, 6 lut 2020 (CET)

@Electron: Korzysta z "Chunked upload" i c:Special:UploadStash. Są inne skrypty korzystające z tego mechanizmu, ale wymagają trochę zachodu by ich użyć. Możesz zerknąć do mojego common.js. Ankry (dyskusja) 13:06, 6 lut 2020 (CET)

@Electron: Dobrze wiedzieć. Dzięki za info. W wolnej chwili się tym pobawię :) Electron  ^<Odpisz> 13:19, 6 lut 2020 (CET)

@Electron: Napisz do mnie w takich sytuacjach, pomogę konwertować/modyfikować plik. Matlin (dyskusja) 13:32, 27 lut 2020 (CET)

@Matlin: OK. Dzięki za chęć pomocy. Będę pamiętał na przyszłość. Na razie sobie poradziłem - "Chunked upload" rzeczywiście może zdziałać cuda, nawet na takich wolnych łączach jak moje :) Electron  ^<Odpisz> 13:43, 27 lut 2020 (CET)

Nowy szablon do umieszczania spisów na stronach całości tekstów

Podaje dla informacji, że sporządziłem taki szablonik, który pomaga w tworzeniu spisów uniwersalnych, które prawidłowo działają umieszczone na stronie tytułowej i na stronie całości tekstów. Do tej pory był z tym problem, bo zwykle spis umieszczony na stronie całości prowadził linki poza tę stronę. Więcej informacji i przykład zastosowania umieszczony jest na stronie opisu {{Szablon:id sekcji}}. Electron  ^<Odpisz> 17:24, 25 lut 2020 (CET)

{{Dane tekstu}} a {{Nagłówek}}

Chodzi za mną już od dłuższego czasu pomysł, by zunifikować te dwa szablony w jeden, wariantowy. W sumie, informacje, które one zawierają są bardzo podobne, różnią się głównie sposobem ich wyświetlania. Może dałoby się jakoś rozwiązać, by sposób wyświetlania tych informacji był sterowany:

• przy użyciu js, według wyboru użytkownika, albo jego indywidualnych ustawień,
• domyślny - sterowany za pomocą dodatkowego opcjonalnego parametru?

Informacje niewyświetlane w {{Nagłówek}} mogłyby być zawarte w kodzie jako ukryte. Przełączanie wyglądu mogłoby się odbywać za pomocą dobrze widocznego przełącznika.

Mam wrażenie, ze większość informacji wyświetlana w {{Dane tekstu}} jest dla przeciętnego czytelnika nieistotna. Część skrybów również preferuje prosty {{Nagłówek}}. I chyba przy małych ekranach, typu mobilnego, pominięcie tych informacji może zwiększyć czytelność tekstów.

Rzucam na razie luźny pomysł, aby rozważyć różne za i przeciw, a przede wszystkim konsekwencje. Już w tej chwili widzę, że może to mieć istotny wpływ na konfigurację eksportera ebuków, spowoduje też pewnie nieznaczne "spuchnięcie" stron o dodatkowy (ale jednorazowy) kod. Coś jeszcze? To pytanie przede wszystkim do naszych najbardziej "technicznych" użytkowników (@Zdzislaw, @Wargo:), ale ciekaw jestem też opinii innych.

Ankry (dyskusja) 13:20, 13 kwi 2020 (CEST)

• @Ankry: jeżeli nagłówek/DT miałby się tworzyć dynamicznie (zmieniać) to czy nie należałoby się zastanowić, czy nie powrócić do źródeł, i nie tworzyć ich automatycznie, tak jak w en i fr, bezpośrednio z danych z Indeksu (które powielamy na każdej stronie w main), z możliwością nadpisywania danych przez wprowadzenie wartości parametrów w wywołaniu <pages...? Zdzislaw (dyskusja) 14:23, 15 kwi 2020 (CEST)
  • @Zdzislaw: Być może to też, czemu nie? Ale według mnie nie dla wszystkich tekstów ma to sens (wyekstrahowane, współoprawne, oparte o wiele indeksów itp.). Główny problem z tworzeniem nagłówków przez ProofreadPage polega na tym, że większość użytkowników ma niezmiernie blade pojęcie jak to działa, a ci, co jakieś mają, niekoniecznie są w stanie zaoferować pomoc techniczną innym. Ktoś by musiał to zaimplementować i służyć supportem dla userów (w przeciwnym razie będzie to casus Emeczki, który zaimplementował rodzinę szablonów i zniknął; po czym nikt nie wiedział, jak tego prawidłowo używać).

Obie zmiany łączy tylko to, że wymagają grzebania w kodzie krytycznych szablonów. Pierwsza propozycja wiąże się jedynie z przebudową szablonu i stworzeniem okołoszablonowego js. Druga, oprócz zmian w szablonach, wymaga zmiany sposobu tworzenia stron lub przebudowania istniejących. A to wymaga przeszkolenia użytkowników, zmiany ich przyzwyczajeń, kogoś, kto będzie umiał wyjaśnić jak to działa albo dlaczego nie działa. Bez tego może się okazać pracą daremną (casus Emeczki).

Powrotem do źródeł bym tego nie nazwał; "źródłowy" {{Nagłówek}} jest dużo starszy niż ProofreadPage. Raczej przejściem z epoki brązu do epoki żelaza (skąd do epoki przemysłowej wciąż daleka droga). Ankry (dyskusja) 16:11, 15 kwi 2020 (CEST)

• @Ankry: ok, zapomnijmy na razie o <pages... Pytania... od czego zacząć? Od unifikacji w wariantowy? Czy nagłówek przejmuje DT, czy odwrotnie? Który miałby być przekierowywany, na który? Czy raczej nowy szablon? Czy najpierw spróbować stworzyć gadżet przełączający widok obecnego n->DT i DT-> n? Zdzislaw (dyskusja) 13:42, 19 kwi 2020 (CEST)
• No właśnie do końca nie wiem, stąd ten wątek. Wydaje mi się, że najsensowniej by było utworzyć nowy szablon, a później przekierować na niego istniejące. Lub później przenieść go pod jeden z dotychczasowych (raczej pod DT, bo ma więcej parametrów). Jak uważasz? Myślę też, że proste przekierowanie Nagłówka na DT nie jest możliwe, bo się jednak trochę różnią składnią i raczej byłaby to nakładka.

Zastanawiam się też, na ile taki mechanizm dałoby się wykorzystać w przyszłości do innych zmian sposobu wyświetlania (np. zawężanie jak w fr); rozważyć jakie zmiany byłyby potrzebne do integracji z <pages> też można się zastanowić. Chodzi mi o to, by dobrze przemyśleć zasadę działania oraz jak i do czego mozna go wykorzystać w przyszłości (a do czego nie można / z czym by kolidował), niż o branie się za implementację. Raczej taka wstępna wishlist z analizą wykonalności. Ankry (dyskusja) 14:26, 19 kwi 2020 (CEST)

• @Ankry: w ostatnich dniach przegryzałem się trochę przez dokumentację i zgłębiałem omawiany problem. Analizując możliwości, dochodzę do wniosku, że odpowiednie zaimplementowanie mechanizmu header i jego odpowiednie opisanie w prostym wizualnym samouczku nie dość, że umożliwiło by generowanie DT/nagłówka spiętego z ich zamianą poprzez js lub nawet opcją w ustawieniach użytkownika, to pozwoliłoby na zaimplementowanie mechanizmu zmiany formatu main (tak jak na en i fr... szerokość, styl fontu... zob. tu, link Maquette 1 (2,3...) w menu po lewej), i jednocześnie linki następny/poprzedni byłyby być generowane automatycznie... To wszystko razem spowodowałoby ogromne ułatwienie nie tylko dla starych, lecz także dla nowych skrybów. Oczywiście, znajdziesz przypadki, w których wymagane byłoby wprowadzenie DT/header, lub chociażby pewnych parametrów ręcznie, lecz jedno drugiego nie wyklucza, a dla 95% nowych tekstów (i 95% starych) mechanizm <pages byłby odpowiedni. Jestem także przekonany, że przy odrobinie wysiłku informacyjnego w niedługim czasie (jak na warunki ws:) ) większość Skrybów uznałaby ten mechanizm za łatwiejszy, dający lepszy efekt końcowy i prostszy. Oczywiście obecne mechanizmy (tak jak dla korekta funkcjonowałyby bez zmian). Zdzislaw (dyskusja) 13:21, 1 maj 2020 (CEST)
  • No to super! Patrząc na tę duskusję wydaje mi się, że @Electron, @Draco flavus: mogą również być zainteresowani tym tematem (żeby nie dublować rozwiązań automatyzujących pewne rzeczy). Ankry (dyskusja) 13:42, 1 maj 2020 (CEST)

• Ja jestem w tej materii raczej samoukiem praktykiem i użytkownikiem. Jak mi jest coś potrzebne (a nie ma tego już stworzonego przez kogoś innego) to gdy idea mi w głowie się zarysuje i mam już jakiś pomysł jak to rozwiązać to po prostu siadam i coś na bieżąco płodzę, a potem ewentualnie poprawiam zauważone błędy i braki i dodaję nowe funkcje, których brak mi się nasunął w trakcie testów. Nie jestem więc tak dobrze zorganizowany teoretycznie jak koledzy... Na razie obserwuję ten wątek ale nie mam aż takiej wyobraźni aby coś planować wielowariantowo i ze wszystkimi szczegółami. I obawiam się, że przed zobaczeniem wyników niewiele mogę pomóc w tej materii. Ale jak mi się coś nasunie w trakcie to oczywiście dam znać. Na razie mam taką uwagę, że te dodatkowe opcje (np. szerokość tekstu) powinny być do wyboru przez użytkownika - ja np. preferuję tekst w dostępnej całej szerokości ekranu (używam monobooka, a w proofie używam także gadżetu do chowania sidebaru, aby móc korzystać z całej szerokości), więc nie cieszyłoby mnie wymuszone jego zwężenie, jak się obserwuje na niektórych wiki. Electron  ^<Odpisz> 11:37, 2 maj 2020 (CEST)

• Jeśli chcecie wiedzieć, jak to działa, to przyjrzyjcie się jak są tworzone strony w main w fr:. Ankry (dyskusja) 09:51, 3 maj 2020 (CEST)

• Jestem za unifikacją. Najchętniej zastąpiłabym szablon Nagłówek szablonem Dane tekstu, ale rozwiązania techniczne pozostawiam wykonującemu ;) Wieralee (dyskusja) 00:05, 20 kwi 2020 (CEST)

Owszem, jak zauważył Ankry również dostrzegam problemy z obecnym szablonem {{Dane tekstu}} aczkolwiek widzę tu dwa aspekty. Wg mnie

• tworzenie stron w przestrzeni głównej jest problemem dla nowicjuszy i nawet niektóre stare wygi tego unikają.
• bardzo żmudne (=podatne na błędy) jest zwłaszcza zmienianie struktury np. przy zmianie numeracji, tytułu...
• inne wymagają więcej uwagi (stary styl, bunch of jpgs, kilka plików w jednym indeksie)

Pierwsza idea, która mi przyszła do głowy to centralna strona z danymi podstron:

Rozdział II✽224✽265✽sekcja_02✽R_02

Rozdział III✽266✽269✽sekcja03✽R_03

itp. itd.

Druga idea to automatyzacja podstron (następna, poprzednia – rozumiem, że uwzględnione w projekcie Zdzisława, bieżąca przydatna do tworzenia kategorii i sekcji) (idee można połączyć):

Rozdział II✽224✽265✽sekcja_{{BieżącyU|2}}✽{{BieżącyU|2}}

Rozdział III✽266✽269✽sekcja_{{BieżącyU|2}}✽R_{{BieżącyU|2}}

Jeśli nie wykorzystać idei I, to pozostaje zastosowanie
<pages index="........" from="11" to="12" fromsection="sekcja_{{Bieżący_U|3}}" tosection="{{Bieżący_U|3"}}/>
i [[Kategoria:....|R_{{BieżącyU}}]]
O ile to pierwsze zastosowanie (sekcje) nie jest często potrzebne (wiele rozdziałów zaczyna się na nowej stronie – choć jeśli sekcje są potrzebne, to warto to móc automatyzować), o tyle tworzenie kategorii można w ten sposób zautomatyzować.

Draco flavus (dyskusja) 14:06, 3 maj 2020 (CEST)

Wikibiblioteka: prosty front-end dla Wikiźródeł

Przy okazji, w WMPL wykiełkował taki pomysł. Może warto go przedyskutować w naszym gronie? Ankry (dyskusja) 13:20, 13 kwi 2020 (CEST)

Jak najbardziej warto przedyskutować ten pomysł.

1. czy ten portal miałby zastąpić obecną stronę główną czy być czymś zupełnie oddzielnym?
2. jaka jest preferowana technologia i wymagania techniczne?

Cafemoloko (dyskusja) 13:42, 13 kwi 2020 (CEST)

Na pewno nie może zastąpić SG, bo, jak rozumiem, chodzi o serwis zewnętrzny. Natomiast być może mógłby zastąpić wsexportera albo stać się serwisem pośredniczącym w naszym korzystaniu z niego. Na etapie pomysłu trudno mówić o technologii; wydaje mi się, że jest to kwestia otwarta. Pewne osoby z WMPL zaproponowały przedyskutowanie tego po Świętach. Ankry (dyskusja) 15:13, 13 kwi 2020 (CEST)

Tak rzucam tylko do pomyślenia, mamy trzy kategorie tekstów (A. ukończone = zielone, B. skończone=kompletne np. dużo powieści Dumasa i C. takie teksty dziurawe (przeniesione do głównej ale nie przepisane) . Zawężać się do A trochę szkoda..., udostępniać C to antyreklama dla nas, B. bym ew. udostępniał na zewnątrz z jakimś sygnałem, że nieukończone są prace nad tekstem. Draco flavus (dyskusja) 21:48, 13 kwi 2020 (CEST)

Hej wszystkim! Dzięki za rozpoczęcie dyskusji, Ankry! Ja podpowiem czego bym potrzebował, żeby ruszyć to dalej:

• listy rzeczy koniecznych (must have)
• listy rzeczy mile widzianych (nice to have)
• listy pomysłów z kosmosu ("A jakby jeszcze robiło kawę…")

Proponuję na tym etapie nie przejmować się technologią ani graficznym kształtem, tylko skupić na dobrym opracowaniu samych potrzeb. Dzięki temu będę mógł to potem zabrać do programistów i designerów i powiedzieć "Zróbcie nam coś co będzie spełniać te wymagania".

Jedna rzecz jest raczej trwała i tego (na razie) nie przeskoczymy, a mianowicie: będzie to odrębny serwis internetowy na oddzielnej domenie (w ten sposób możemy sobie pozwolić na ruszenie z projektem bez oglądania się na WMF). Ale to mam nadzieję rozwiązuję kwestię pytań o stronę główną – nic na Źródłach nie zmieniamy. :)

Jeśli mogę sobie pozwolić na metaforę, mamy skryptorium i drukarnię (Wikiźródła) dla skrybów/skrybek i zecerów/zecerek, a teraz chcemy do tego od frontu dobudować bibliotekę dla czytelników i czytelniczek.

Dla przykładu, na mojej liście rzeczy koniecznych w bibliotece mam:

• bardzo prosty w użyciu interface i wyszukiwarka – Moja mama chce przeczytać Kordiana i musi go znaleźć i ściągnąć
• atrakcyjna oprawa graficzna z okładkami książek jako elementem prezentacji
• dostosowanie do używania serwisu na urządzeniach mobilnych i tabletach
• możliwość ściągnięcia książki w różnych formatach z prostym objaśnieniem
• możliwość przejścia z serwisu dla czytelników do serwisu dla skrybów (rekrutacja nowych użytkowników Wikisource)

A na liście rzeczy mile widzianych:

• możliwość podziękowania skrybom
• możliwość pokazania użytkownikowi kategorii lub listy książek (np. listy lektur lub książek powiązanych z danym tematem)
• możliwość pokazywania postępów prac na kolejnymi książkami (takiej list "Wkrótce w naszej bibliotece…")

A na liście rzeczy z kosmosu mam:

• możliwość osadzania książki w innej stronie internetowej z odniesieniem do strony
• możliwość dodawania do książki oddzielnych "warstw" (analogicznie do Open Street Maps) tworzonych przez skrybów przypisów i/lub komentarzy do oryginalnego tekstu (np. "warstwa historyczna" z odniesieniami do Wikipedii, "warstwa literaturoznawcza" dla studentów i wykładowców wskazująca zabiegi literackie lub tematykę, "warstwa komparatywna/tłumaczeniowa" z odniesieniem do tekstu oryginału

Także poproszę na tym etapie o listy potrzeb i/lub pomysłów z podziałem na te trzy kategorie. Z tego punktu będzie łatwiej ruszyć dalej. :)

Cieszę się, że przyjmujecie pomysł ciepło – będę z ciekawością czekał na Wasze pomysły.

TOR (dyskusja) 20:16, 14 kwi 2020 (CEST)

• Może zaimplementowanie znanego ostatnio z Commons mechanizmu dodawania tagów - danych strukturalnych, takich jak: rodzaj (literacki), gatunek, tematyka, motywy, tak żeby można było wyszukać łącznie np. "powieść historyczna", "tematyka: XVIII wiek". To by odciążyło kategorie, z którymi jest obecnie mały problem (brak kryteriów: gdzie i jaką kategorię dodać). Matlin (dyskusja) 20:49, 14 kwi 2020 (CEST)

  Przyłączam się do prośby o możliwość tagowania (mogą być proste albo w formie klucz wartość typu autor=LD, miejsce=Galicja i uwzględniania tagów jako jednej z opcji wyszukiwania). Bonvol (dyskusja) 19:20, 17 kwi 2020 (CEST)

  Wiele sposobów grupowania utworów: po autorze, po roku powstania, po narodowości, tylko słowniki, kolekcje tematyczne itp. Bonvol (dyskusja) 19:20, 17 kwi 2020 (CEST)

• Jeżeli miałby to być nawet prosty front-end, to i tak, jak mi się wydaje, w pierwszym kroku wymagane byłoby zindeksowanie "gotowych" utworów ze Źródeł, wraz z metadanymi. I oczywiście ich okresowa aktualizacja, w miarę pojawiania się kolejnych "gotowych" utworów na Źródłach. Jeżeli tak, to dlaczego nie iść za ciosem i nie powrócić do możliwości połączenia ws z FBC? To co jest do zrobienia opisywałem tu:
  wmpl:Użytkownik:Zdzislaw/Źródłosłów_2018
  Wtedy naszym prostym front-end-em mogłoby się stać FBC :)) Zdzislaw (dyskusja) 14:29, 15 kwi 2020 (CEST)

  Cache'owanie gotowych epubów/pdfów też może być opcją i sposobem na odciążenie eksportera. Bonvol (dyskusja) 19:20, 17 kwi 2020 (CEST)

Mam pytanie: a ten serwis zewnętrzny gdzie ma być zarejestrowany? Bo jeśli by działał na polskiej domenie to dobrze by było dostawienie tam także forka polskich wikiźródeł, dla prac które są już PD w Polsce a wujek Sam dalej uparcie próbuje je ochraniać nie wiadomo dla kogo, na co i po co... Dotyczy to zwłaszcza polskojęzycznych prac wydanych po wojnie (i nie tylko). Electron  <Odpisz> 23:26, 15 kwi 2020 (CEST) przeniosłem część tej wypowiedzi do następnego wątku; tam ją kontynuujmy Ankry (dyskusja) 21:43, 16 kwi 2020 (CEST)

Czasem tak jest, że rzeczy dzieją się szybciej niż przypuszczałeś… :) W ten weekend będę pisał wniosek o dofinansowanie z programu Kultura w Sieci na stworzenie strony internetowej i oprogramowania "łączącego" Wikisource z biblioteką, promocję i pewnie więcej działań jeszcze. Będę Was informował na bieżąco o wynikach. Trzymajcie kciuki. TOR (dyskusja) 11:42, 16 kwi 2020 (CEST)

• @TOR: byłoby przyszłościowo, gdyby w projekcie wziąć pod uwagę koszt narzędzia dającego możliwość wyjścia z danymi o pozycjach w tworzonej bibliotece przez OAI-PMH (daje to możliwość wyjścia do FBC i Europeany). Zdzislaw (dyskusja) 14:57, 16 kwi 2020 (CEST)

Wiki dla tekstów PD-PL

Dobrze by było dostawienie forka polskich wikiźródeł, dla prac które są już PD w Polsce a wujek Sam dalej uparcie próbuje je ochraniać nie wiadomo dla kogo, na co i po co... Dotyczy to zwłaszcza polskojęzycznych prac wydanych po wojnie (i nie tylko). Electron  ^<Odpisz> 23:26, 15 kwi 2020 (CEST)

• Może ja odpowiem: ten temat już wypłynął i będzie dyskutowany; jednak w tym przypadku sprawa jest trochę bardziej złożona: choćby dlatego, że systemem z aktywnymi użytkownikami trzeba aktywnie zarządzać i go jakoś nadzorować. Ankry (dyskusja) 08:54, 16 kwi 2020 (CEST)

  Nawet system "samoobsługowy" wymaga opieki jakiegoś admina, który dba o to aby pracował on poprawnie, nie zawieszał się i dokonywał jego aktualizacji. Tak więc dodanie jeszcze jednego serwisu nie powinno go zbytnio dodatkowo obciążyć. A adminami dbającymi bezpośrednio o treść mogliby być wszyscy dotychczasowi admini Wikiźródeł wyrażający takie zainteresowanie - raczej nie powinno być z tym problemu... Upiekło by się dwie pieczenie przy jednym ogniu.

  Aby nie zajmował on zbyt wiele miejsca można ustanowić zasadę, że można by było tam umieszczać tylko teksty i pliki, które nie nadają się do "właściwych" Wikiźródeł ze względów prawnych. I ograniczyć wielkość maksymalną ładowanych plików do rozsądnych rozmiarów (pliki pdf i djvu można zwykle dokompresować do właściwych rozmiarów). Electron  ^<Odpisz> 11:20, 16 kwi 2020 (CEST)

  Potraktowałbym to jako odrębny projekt. Możemy zacząć osobny wątek na ten temat? Bo to ważna kwestia (pozdrowienia dla prawników Myszki Mikki), ale nie powinno nas blokować przy tworzeniu naszej "biblioteki". Chętnie bym się dowiedział czy inne kraje w jakiś sposób rozwiązały już tę kwestie, czy też jako ruch Wikimedia jesteśmy cały czas w kropce globalnie? TOR (dyskusja) 11:42, 16 kwi 2020 (CEST)

  @TOR: Wedle życzenia. Wydawało mi się wprawdzie, że pewne założenia organizacyjno prawne tego projektu warto by przedyskutować najpierw poza wiki, ale jeśli nie masz nic przeciwko temu, to możemy i tutaj. Ankry (dyskusja) 21:43, 16 kwi 2020 (CEST)

• @Electron: Mając doświadczenia z Wikilivres, na pewno jesteś świadomy tego, że nie jesteśmy w stanie po prostu "przenieść" kont z Wikiźródeł, w każdym razie zachowując WMF-owe zasady dotyczące anonimowości. Więc nie można po prostu powiedzieć że admini stąd będą adminami tam. Ponadto, admini (techniczni) tego systemu będą mieli dostęp do informacji o IP użytkowników, co w przypadku jakiegokolwiek powiązania kont może być problematyczne. Z drugiej strony chyba nie bez powodu samodzielne zakładanie kont w Wikilivres było wyłączone, prawda? I chyba tutaj też nie zechcemy pozwolić na zakładanie kont wszystkim spamerom?

Inną kwestią jest odpowiedzialność WMPL za zamieszczone tu treści. I dotyczy to nie tylko tekstów, ale także stron dyskusji. Odpowiedzialność ta w Europie jest dużo większa niż w USA i może rodzić dodatkowe koszty/ryzyko, które WMPL może zdecydować się ponieść albo nie. Prawdopodobnie dotychczasowe doświadczenia z użytkownikami Wikiźródeł i ich podejście do kwestii prawnych, zwłaszcza prawnoautorskich, dają tu pewien poziom bezpieczeństwa. Ale czy można przewidzieć jak będzie w przyszłości?

Jest kwestia, jakie teksty miałyby tu być wrzucane: wszystko na hurra, czy może jakieś wstępne zatwierdzanie każdej nowej pozycji? Wtedy jak i przez kogo? Co będzie jeśli ktoś zdecyduje się wrzucić tłumaczenie Mein kampf na CC-BY-SA 3.0? Albo przekłady białoruskich autorów zmarłych w latach 1950-tych? Czy choćby teksty PD, ale antysemickie? Lub przekłady francuskich autorów, które są PD w Polsce, ale we Francji już nie? Możemy tę listę rozwijać. Na pewno ktoś z WMPL musi mieć prawo weta i wywalenia bez dyskusji czegokolwiek, co do takiego systemu trafi. Bez pyatń i bez dyskusji. Natomiast wydaje się, że WMPL nie byłoby zainteresowane tym, by ktoś od nich weryfikował każdy nowo wrzucony tekst.

Kolejną sprawą będzie opozycja wewnętrzna. Są już głosy, że uruchomienie takiego projektu będzie ze szkodą dla Wikiźródeł, bo każdy user, który pójdzie edytować tam, nie będzie edytował tu. I to fakt.

Ankry (dyskusja) 22:23, 16 kwi 2020 (CEST)

Moim zdaniem jeśli to byłby projekt w polskiej domenie i na polskich serwerach to tylko polskie prawo autorskie się liczy. Bo przecież o to chodzi aby "uwolnić" te utwory, które według polskiego PA są już PD, ale w USA (lub gdziekolwiek indziej) są dalej chronione. Prawo zwykle działa tylko na danym terytorium, a my w większości mieszkamy w Polsce więc powinniśmy mieć możliwość w pełni z niego skorzystać. Oczywiście należy brać także ratyfikowane przez Polskę zobowiązania międzynarodowe w tej dziedzinie (bo są one traktowane na poziomie ustaw), ale nic ponadto.

Co do jakiejś formy cenzury: prawdę powiedziawszy jestem przeciw cenzurze. W wikilivres mieliśmy zaczęty "Mein kampf" w oryginale (w proofread). Co ciekawe pdf był zaciągany z commons. To dzieło historyczne i powinno być dostępne, jak każde inne. Nie żebym był jego fanem, i namiętnie się w nim zaczytywał (prawdę powiedziawszy jakoś do tej pory nie chciało mi się w nie zagłębiać, chociaż jak ktoś chce to i tak w sieci może znaleźć jego przekład), ale jak zaczniemy coś cenzurować, to różne grupy zaczną dodawać nowe pozycje, bo dlaczego by i nie? Zawsze można znaleźć jakieś powody. Powiedział bym tak: od przeczytania tego "dzieła" od razu nikt nie robi się hitlerowcem i chce wywołać III wojnę. Druga w zupełności większości wystarczy... A osoby o skrajnych poglądach zawsze były i będą. Nie należy ich tylko dopuszczać do władzy. Oczywiście właściciel serwisu może zawsze narzucić jakieś własne dodatkowe reguły, ale to zwykle tak jest, że kto wykłada pieniądze ten ma zawsze więcej do powiedzenia...

Co do identyfikacji nowych/starych kont użytkowników: to nie ma problemu. Już to przecież było przerabiane: po prostu zakładający nowe konto o tym samym brzemieniu jak w starym serwisie deklaruje, że jest tym kim jest, a dodatkowo proszony jest aby w starym serwisie (po zalogowaniu się) to potwierdził. I to w zupełności wystarczy. Gdy natomiast ktoś obcy zakłada konto o takiej samej nazwie jak w starym serwisie miał ktoś znany, z dużą ilością edycji, to się go prosi o zmianę jego nazwy, a gdy to nie poskutkuje to się ją zmienia bez jego zgody z uwagi na takie przyjęte zasady. Podobnie było w projektach wikimedii, gdy unifikowano konta. A Electronów było chyba z kilkunastu w innych projektach (całe szczęście, że z małą ilością edycji i głównie nieużywanych). Trochę trwało zanim to wyprostowałem... W wikilivres/bibliowiki blokada samodzielnego zakładania konta trwała tylko czasowo, zanim nie zainstalowaliśmy systemu moderacji edycji dla nowych użytkowników (z uwagi na spam-boty). Ale w wikiźródłach spam-boty są temperowane skutecznie w inny sposób...

Co do opozycji wewnętrznej - to nie zróbmy z niej opozycji zewnętrznej. Bo może sobie równie dobrze pójść lub założyć nowy serwis który nie będzie miał takich ograniczeń. A to już może być konkurencja. Chociaż konkurencja jest zwykle sytuacją zdrową, to przy niewielkich serwisach rozbicie sił i środków zwykle nikomu nie wychodzi na dobre. Po za tym nie widzę tego, aby np. polska sekcja w old wikisource odciągała jakąś poważną część dotychczasowych użytkowników wikiźródeł - jest tylko ich uzupełnieniem, gdzie publikuje się prace, które są PD w USA a w Polsce nie są. Tak będzie moim zdaniem i z "polskimi Wikiźródłami", tylko że będą tam publikowane prace, które są PD w Polsce a w USA nie są... W Wikilivres zwykle działali użytkownicy aktywni także w wikisource. Electron  ^<Odpisz> 11:38, 17 kwi 2020 (CEST)

@Electron: Mówisz: "polskie serwery, polskie prawo", inni myśleli: "amerykańskie serwery, amerykańskie prawo", a niemiecki sąd miał inne zdanie. Jesteśmy w Unii, trzeba różne warianty brać pod uwagę.

Co do Mein Kampf: ty możesz chcieć wrzucić, natomiast prezes WMPL może nie chcieć w tej sprawie spotykać się z prokuratorem. Trzeba to jakoś wyważyć. To samo dotyczy swobodnego zakładania kont: jeśli każdy je będzie mógł założyć, to jest ryzyko, że ktoś wrzuci coś, czego nie powinien. I jeśli z jakiegoś powodu nie zostanie to dostatecznie szybko usunięte, to WMPL może mieć problem. Jestem pewien, że WMPL nie chce tu zatrudniać moderatora, a czy na wolontariuszach można polegać? Tu jest właśnie różnica pomiędzy umieszczeniem serwisu w Europie, a np. w Ameryce: u nas odpowiedzialność (i obowiązki) hostującego jest większa. Według mnie serwis ze swobodnym zakładaniem kont przez użytkowników jako serwis prowadzony przez WMPL w ogóle nie wchodzi w grę Ankry (dyskusja) 21:31, 17 kwi 2020 (CEST)

Toteż mówię, że to jest moje zdanie, a właściciel serwera ma zwykle zdanie ostanie. Co do niemieckiego sądu: tak czy owak, jego decyzje mają skutek tylko na terytorium Niemiec. Po za tym pisałem przecież, że umowy międzynarodowe ratyfikowane przez Polskę są wg polskiego prawa jego częścią (w mocy polskich ustaw) więc należy je oczywiście brać pod uwagę... Co do zakładania kont: sprawa jest do dyskusji, ale przecież to, że to ktoś inny założy konto dla danego użytkownika nie daje jeszcze 100%-owej gwarancji, że on czegoś takiego nie wrzuci. Po to są admini aby to wyłapywali a w sytuacjach wątpliwych przeprowadza się dyskusje nad danym przypadkiem. Po za tym: to nie jest tak, że w serwisie nie można popełnić błędu - chodzi o to żeby błąd był wyłapany i naprawiony w rozsądnym czasie. Np. jakiś czas temu jeden wandal namieszał mi w OP i miedzy innymi podmienił na stronie tytułowej jedną z ilustracji na "zwis męski prosty". Ja to potem oczywiście odkręciłem, a jego zablokowałem na amen. To znany stały wandal i był już definitywnie zablokowany ale skorzystał z tego, że zmienił IP po zakupieniu karty jednego z operatorów mobilnych. Czy ja jestem winny temu, że serwis prezentował przez jakiś czas pornografię na stronie głównej? Nie. Zrobiłem co było można i w tak krótkim czasie jak się tylko dało. Takich sytuacji nie można nigdy wykluczyć całkowicie, zwłaszcza w serwisach o dostępie otwartym. A za dane czyny odpowiada przede wszystkim ten, kto je dokonał. Electron  ^<Odpisz> 21:57, 17 kwi 2020 (CEST)

Odezwa Wojewódzkiego Komitetu Zlotu Jubileuszowego Związku Harcerstwa Polskiego

Nieźle się nagimnastykowałem z tym, ale dalej mam problem. Jeden z wierszy kończy się słowem choćby, następny zaczyna słowem najmniejszą, ale w zamyśle chciałbym, żeby nie było złamania do nowego wiersza. Niestety nie umiem tego złamania usunąć. W jaki sposób ten problem usunąć? Superjurek   (Dyskusja) 00:48, 25 maj 2020 (CEST)

@Superjurek: Trzeba tak wykombinować, by to umieścić w jednym tagu <pages ... > Spróbuję coś wyrzeźbić. Ankry (dyskusja) 09:33, 21 cze 2020 (CEST)

Zobacz teraz. Sekcja na stronie nie musi być ciągła. Ankry (dyskusja) 07:07, 26 cze 2020 (CEST)

Wersje przejrzane

W związku z tym, że rozszerzenie FlaggedRevs jest od dłuższego czasu nierozwijane, nie ma wsparcia, ta sytuacja coraz częściej powoduje różne problemy (np. wczorajsze "zamulanie" przy ładowaniu stron) i istnieje ryzyko, że zniknie zupełnie, sugeruję, by się zastanowić, czy jest ono dla nas niezbędne i czy dałoby sie je ewentualnie czymś zastąpić.

Rozszerzenie to posiada dwie funkcje wykorzystywane obecnie na wiki

1. możliwość "zatwierdzania" edycji stron dokonywanych przez niedoświadczonych użytkowników,
2. ukrywanie takich edycji przed niezalogowanymi użytkownikami.

Moim zdaniem ta druga funkcja jest w przypadku Wikiźródeł (w odróżnieniu od Wikipedii) nieistotna, gdyż treści, które moglibyśmy chcić w ten sposób ukrywać (wandalizmy, nieporadne edycje początkujących) rzadko trafiają do przestrzeni głównej, gdzie ich ukrywanie ma sens (raz, że wandalizmy są u nas generalnie rzadkie, a dwa, że są trudne technicznie poprzez mechanizm transkluzji używany przez ProofreadPage). Z kolei edycje początkujących mają zwykle miejsce w przestrzeni Strona i do przestrzeni głównej w takiej formie nie są transkludowane.

Dlatego skoncentruję się na tym, co by można zrobić w pierwszej kwestii.

Według mnie można by tę rolę rozszerzenia zastąpić dwoma nowymi funkcjami:

1. skrypt w js, który by sprawdzał, kto ostatnio edytował daną stronę, jakie ma uprawnienia i jeśli nie był do redaktor dawał edytującemu stronę redaktorowi wyraźny komunikat (dla edytujących nieredaktorów nic by nie robił)
2. generowana co jakiś czas (np. przez bota) lista stron wymagających "przejrzenia", czyli takich, które ostatnio edytowali "nieredaktorzy"

Minusy tego rozwiązania w porównaniu z obecnym

• nieco wolniejsze ładowanie formularza edycji strony (bo skrypt musi sięgnąć do jej historii; a może nie?)
• wymagałoby to większej uwagi od redaktorów, gdyż w tym wariancie każda ich edycja "niezatwierdzonej" strony oznaczałaby jej "zatwierdzenie" (ale w końcu na tym ma chyba polegać rola nas, redaktorów?)
• "zatwierdzenie" wersji strony wymagałoby jakiejś realnej edycji (np. dodanie/usunięcie spacji, podbicie statusu; itp.); można w tym celu utworzyć pusty szablon {{zatwierdzone}}.
• "zatwierdzone" strony znikałyby z listy stron "do przejrzenia" nie od razu, lecz po następnym przebiegu bota.
• starsze edycje świeżo upieczonych redaktorów stawałyby się automatycznie zatwierdzone w chwili nadania uprawnień; można by co prawda kombinować ze sprawdzaniem przez skrypt w jakiś sposób daty nadania uprawnień (ale to by chyba nadmiernie go skomplikowało)
• inaczej by działało "odbieranie" uprawnień ("nieprzejrzane" by się stawały wszystkie strony których najnowszej edycji dokonał ten user); ale to może być akurat plus, nie minus.

No i główny problem, że ktoś to musi zaimplementowac...

Proszę szanownych redaktorów o opinie. Ankry (dyskusja) 15:26, 7 wrz 2020 (CEST)

Również uważam, że "funkcja ukrywanie" nie bardzo jest u nas przydatna, i jej brak raczej nie będzie zauważalny. A jeżeli chodzi o minusy nowego rozwiązania nie wyglądają na problemowe (zwłaszcza, że niektóre mogą się okazać plusami). Jestem za wprowadzeniem nowego rozwiązania. O ile oczywiście znajdzie się ktoś kto to zrobi, bo na technicznej stronie to ja się niestety za bardzo nie znam. Joanna Le (dyskusja) 10:55, 8 wrz 2020 (CEST)

 Za, bo chyba to dłuższe ładowanie nie będzie wynosiło więcej niż kilka sekund. A może jakieś podobne rozwiązania mają inne wersje językowe? Matlin (dyskusja) 12:45, 8 wrz 2020 (CEST)

Chyba nie. Temat "co zrobić z nierozwijanym i niewspieranym FlaggedRevisions" nie jest wprawdzie nowy (phab:T185664), jednak większość, zwłaszcza wikipedyści, liczy pewnie że WMF się weźmie i coś zrobi. Powyższy wariant dotyczy sytuacji "a jeśli nie?" Ankry (dyskusja) 15:02, 8 wrz 2020 (CEST)

Proponowane rozwiązanie przypomina napisanie tego rozszerzenia od nowa. Jeżeli chodziłoby tylko o wyłączenie ukrywania to da się zrobić, reszta pożądanych funkcji by została. W MediaWiki jest też wbudowany mechanizm do oznaczania jako "sprawdzona" strona i edycja. Można by go udostępnić szerszej grupie niż administratorzy. Wargo (dyskusja) 12:50, 10 wrz 2020 (CEST)

I to de facto jest napisanie od nowa tej części, która jest dla nas przydatna. Ale może ktoś ma lepszy pomysł? Ankry (dyskusja) 20:00, 10 wrz 2020 (CEST)

A co z wbudowanym mechanizmem patrolowania? Sprawdź czy widząc nowo utworzoną stronę przez osobę nie-automatycznie zatwierdzoną widzisz w prawym dolnym rogu link do oznaczenia jako sprawdzoną. Albo w porównaniach zmian pod informacjami o prawej wersji. To inny mechanizm i jest bardzo uproszczony - daje tylko znacznik sprawdzona/niesprawdzona. Uprawnienie autopatrola też działa. Wargo (dyskusja) 23:44, 10 wrz 2020 (CEST)

Tu nie chodzi wyłącznie o nowo utworzone strony. Równie istotne są edycje już istniejących. A także o, rzadko stosowaną, możliwość odebrania uprawnień (automatycznie zatwierdzonych, o ile wiem, się nie da). Ankry (dyskusja) 13:45, 11 wrz 2020 (CEST)

Funkcja obejmuje również oznaczanie edycji. Zobacz na Wikidanych. Grupy użytkowników można konfigurować i nadać im uprawnienie "autopatrol". Można też stworzyć grupę odbierającą uprawnienia jeżeli usuwanie z grupy stanowiłoby problem. Wargo (dyskusja) 15:06, 11 wrz 2020 (CEST)

• Może zastosować to co już jest opracowane i dalej jest rozwijane: mw:Extension:Moderation. Mieliśmy to kiedyś w Wikilivres. W skrócie: wszystkie nowe edycje użytkowników nie będących w grupie automoderatorów są zapisywane w rejestrze do moderacji i do momentu ich aprobaty nie są widoczne dla ogółu. W sumie już po pierwszej edycji widać czy jest to dzieło wandala, czy też nie - więc od razu można zdecydować, czy usera można dodać do listy automoderatorów, a jego dotychczasowe edycje zatwierdzić. Dość radykalne (w stosunku do dotychczasowej praktyki, ale bardzo skuteczne). Electron  ^<Odpisz> 14:24, 11 wrz 2020 (CEST)
  • 1. Tego chyba nie ma na serwerach Wikimedia.
    2. W przestrzeni Strona, owszem wandalizmy widać. Ale chodzi nie tylko o wandalizmy, ale także o przejrzenie edycji początkujących użytkowników pod kątem ich poprawności. Natomiast w przestrzeni main, wandalizm może polegać na zamieszczeniu tekstu innego niż w podawanym źródle. A to, czy tak jest, czy nie, nie zawsze widać.
  • @Wargo: Jeśli patrolowanie, spełniałoby nasze wymogi, to rzeczywiście nie warto wyważać otwartych drzwi. Ankry (dyskusja) 00:36, 12 wrz 2020 (CEST)

tag <hr>

Zauważyłem dziś problemy z tagiem <hr>. "Nabył" on z jakiegoś powodu zerowy rozmiar, przez co generowana przezeń linia "zniknęła" podczas renderowania przez przeglądarkę. W szablonach {{---}} i {{===}} poprawiłem to, ale ten tag jest używany w wielu innych miejscach i nie wiem co z tym zrobić:

• przywrócić "starą" wartość w globalnym CSS (która nie mam pojęcia dlaczego została zmieniona)
• dodać dodatkowy atrybut wszystkim hr-om... (botem?)

Sugestie co do sposobu naprawienia są cenne. @Zdzislaw: masz jakieś pojęcie o przyczynach zmiany? Ankry (dyskusja) 17:55, 10 wrz 2020 (CEST)

phab:T262507. Czekamy. Ankry (dyskusja) 21:47, 10 wrz 2020 (CEST)

@Ankry: widziałem to w [32], ale znaleźć/połączyć z [33] nie zdążyłem :) Zdzislaw (dyskusja) 22:52, 10 wrz 2020 (CEST)

Pagelist widget

Pojawił się nowy wodotrysk w ProofraedPage, który nawet nie wiem jak po polsku nazwać (kontrolka listy stron?), a który wstępnie skonfigurowałem. Można go sobie aktywować podczas edycji indeksu. Służy do numerowania / nazywania stron w indeksach używających <pagelist>. Krótko mówiąc jego przydatność jest dla nas ograniczona. Jednakże, gwoli formalności, jeśli ktoś chce ich używać lub ma sugestie/uwagi odnośnie nazywania wybranych stron to proszę je kierować do mnie, lub do kogoś z pozostałych administratorów interfejsu, którzy mogą edytować tę stronę. Ankry (dyskusja) 14:11, 11 wrz 2020 (CEST)

Przykładowy efekt użycia tego wodotrysku jest tutaj. Ankry (dyskusja) 14:19, 11 wrz 2020 (CEST)

Zlynchujemy Strona:Karol May - Czarny Mustang.djvu/98

czy można poprawić czy zostawić -- niepodpisany komentarz użytkownika Anwar2 (dyskusja | wkład) 10:33, 23 wrz 2020‎

Ale tu nie ma co poprawiać: słowo ma angielki pierwowzór "lynch", więc pewnie tak się wtedy pisało... Electron  ^<Odpisz> 10:44, 24 wrz 2020 (CEST)

Pomysł na autoprzypisy

Może ktoś ma pomysł jak skonstruować taki szablon przypisów, które by się same pojawiały w tekście w razie potrzeby, a nie ujawniały swojej obecności gdy w tekście nie ma refów. Oczywiście tak działa tag <references/>, ale mi chodzi o to, aby w razie potrzeby oprócz przypisów tak samo znikał lub pojawiał się napis "Przypisy". Uprościłoby to automatyzację tworzenia stron, bo można by zawsze wstawiać tam taki szablon, a przypisy by się pojawiały w tylko w razie potrzeby. Electron  ^<Odpisz> 00:38, 1 paź 2020 (CEST)

Temat był już rozważany: po stronie serwera się nie da: przypisy są dodawane przez rozszerzenie do kodu strony po jej przetworzeniu przez parser (więc taka możliwość musiałaby i mogłaby istnieć jedynie wewnątrz tagu <references/> (ale nie zlokalizowałem żadnej funkcji rozszerzenia, którą by można tu wykorzystać). Można by się oczywiście bawić z widocznością/usuwaniem sekcji na poziomie przeglądarki, ale to z kolei popsułoby e-booki (bo generator nie odpala żadnych skryptów - nie potrafi tego). Ankry (dyskusja) 07:26, 1 paź 2020 (CEST)

Z tego co znalazłem tutaj ->Help:Cite#Adding an automatic heading before the references list wynika, że istnieją na to 2 sposoby, ale oba dość inwazyjne; tzn. mamy zawsze dodawany autonagłówek (o sztywnie zdefiniowanych parametrach) przed <references/> gdy tylko pojawią się przypisy. Czasami jednak to może być niezbyt wygodne: gdy już jest generowany nagłówek przez jakiś inny szablon przypisów. Można by było oczywiście z tą sztywną właściwością się pogodzić, a z dotychczasowych szablonów przypisów usunąć nagłówki... tym niemniej nie zawsze to może być wygodne. Electron  ^<Odpisz> 12:43, 1 paź 2020 (CEST)

Tak jak wyżej, skrypty tylko wpłyną na wyświetlanie w przeglądarce. Ale dałoby się dodać do niego sprawdzanie, czy jest już jakiś nagłówek. Może lepszym pomysłem byłoby wstawianie automatyczne do okna edytowania, gdy wykryje określony ciąg znaków... Czy automatyzacja o której piszesz jest tak często konieczna? Wargo (dyskusja) 09:49, 2 paź 2020 (CEST)

Przydatna by była taka funkcjonalność często (moim zdaniem przede wszystkim na podstronach w przestrzeni głównej = rozdziały książek). Pomysł jest taki, by przy tekstach "standardowych" W pustyni i w puszczy/Rozdział 3, W pustyni i w puszczy/Rozdział 4 różnic w kodzie strony było jak najmniej. Problematyczne jest to, że w części rozdziałów powinny się znaleźć przypisy, w innych są zbędne (i wyglądałyby bezsensownie = pusta sekcja). Oczywiście nie jest to jakaś kluczowa funkcjonalność natomiast zaburza koncepcję automatyzacji tworzenia podstron. Draco flavus (dyskusja) 10:07, 2 paź 2020 (CEST)

1. Na stronach będących w przestrzeni Strona: (Page:) wstawianie nagłówków mogło by zaburzać potem wyświetlanie przypisów na stronach zbiorczych, więc nie ma to tam raczej sensu.
2. Myślałem już o wstawianiu autonagłówków poprzez sprawdzenie czy w tekście strony występują tagi <ref> (dało to by się zrobić za pomocą funkcji String). O ile działałoby to pewnie dla zwykłych stron, to już dla treści inkludowanych (a takie mamy przede wszystkim na stronach rozdziałów) to nie zadziała bo nie widzę sposobu zajrzenia za pomocą tej funkcji do stron, które mają być inkludowane (nie mówiąc już o tym, że przy dużej ilości inkluzji mogło by znacząco spowalniać proces ich wyświetlania).
3. Najgłupsze jest to, że (jak wynika z cytowanego helpu) do wersji MediaWiki 1.29 autoheading był funkcją wbudowaną. I komuś (nie wiadomo dlaczego) to przeszkadzało i został usunięty... Electron  ^<Odpisz> 11:54, 2 paź 2020 (CEST)

Wstawiłem dzisiaj {{pw}} na stronę Strona:M. Arcta Słownik Staropolski.djvu/1011 i się ździebko zdziwiłem, że na stronie M. Arcta Słownik Staropolski/Zwoźny pojawiła się "automagicznie" sekcja {{przypisy}} generowana przez szablon {{Staropolski}} a konkretnie współpracujący z nim Moduł:Staropolski spłodzony swego czasu przez @Zdzislaw:. A więc jednak można? Electron  ^<Odpisz> 13:31, 2 lis 2020 (CET)

@Electron: można, gdy cała treść strony generowana jest przez moduł przed odpaleniem parsera. To jest wykonalne dla maleńkich stron słownika, lecz dla normalnych tekstów już nie, ponieważ przy ~70% z nich (trzeba modułem zajrzeć do każdej inkludowanej strony) przepełniałoby ograniczenia serwera i wywalało błędy parsera. Zdzislaw (dyskusja) 17:17, 15 lis 2020 (CET)

Tak coś przypuszczałem, że obejście tego byłoby dość mocożerne; czyli na razie klapa. Chyba, że przywrócą autoheading... Electron  ^<Odpisz> 11:45, 16 lis 2020 (CET)

Ja niestety również nie znalazłem sposobu uniwersalnego ukrywania/tworzenia przypisów. Owszem, można sprawdzać modułem, czy w danym zakresie stron występują charakterystyczne ciągi znaków <[Rr][Ee][Ff]>, {{[Pp]w| , {{[Bb]wd| ale:

1. prawie cały zysk z uniwersalności narzędzia bierze w łeb, bo musimy dwa razy wpisywać to samo raz w tagu <pages...> drugi raz w omawianym wywołaniu modułu
2. sprawę bardzo komplikują ewentualne sekcje (czytaj początek/koniec rozdziału w środku strony).
3. naprawdę nie wiem, jak by w rozsądny sposób należało odwzorować exclude, step itp.
4. w przypadku więcej niż jednego zakresu stron sprawa się jeszcze bardziej komplikuje

Słowem pomysł jest moim zdaniem warty śledzenia, ale obecnie skórka nie warta wyprawki. W przypadku, przenoszenia do przestrzeni głównej książki (zakresu stron) przepisanej trzeba po prostu zobaczyć, czy na końcu generują się przypisy i ew. uzupełnić szablon {{Przypisy}}.

Brakuje faktycznie takiego narzędzia najbardziej, gdy tworzymy strony w przestrzeni głównej, gdy jeszcze dany zakres jest nieprzepisany oraz gdy tworzymy to dla kogoś początkującego a przepisującego daną książkę.

Wydaje mi się jednak, że tworzenie dodatkowego szablonu/modułu z licznymi ograniczeniami i niedoskonałościami jest raczej bez sensu. Draco flavus (dyskusja) 22:39, 20 lis 2020 (CET)

Dane Tekstu

@Electron: mógłbyś wyjaśnić (pokazać) jaki problem występował z rozjeżdżaniem, który był przyczyną do tej edycji +Sekcja "Dane tekstu" w Arial Narrow, bo się rozjeżdża już przy lekkim powiększeniu? Wbijanie w bolda Arial narrow, zamiast natywnego fontu, wygląda lekko mówiąc paskudnie w niektórych rozdzielczościach (litery interpolowane w różnej grubości):

Zdzislaw (dyskusja) 17:09, 15 lis 2020 (CET)

U mnie to tak "rzadko" nie wygląda (Napis "Dane tekstu" ledwo mieści się w swojej kratce) i przy normalnym powiększeniu (z którego standardowo korzystam) te 3 strzałki po prawej obowiązkowo przeskakiwały linijkę niżej (i były widoczne po lewej), co wyglądało nie tyle paskudnie ile po prostu głupio. Obecnie nie mam już tego problemu. Oczywiście można zamiast 3 strzałek dać dwie lub jedną albo skrócić napis, ale nie sądzę aby to razem wyglądało lepiej. Electron  ^<Odpisz> 11:39, 16 lis 2020 (CET)

@Electron: DT od roku 2010, tj. od 11 lat, został zdefiniowany jako tabela o stałej szerokości 265px. Niezależnie zatem od rozdzielczości ekranu, samo DT powinno mieć szerokość pozwalającą bez problemu pomieścić treść. Jeżeli zatem u Ciebie napis "Dane tekstu" ledwo mieści się w swojej kratce, to jest to najprawdopodobniej problem lokalnego nadpisania styli lub lokalnego nadpisania defaultowych czcionek i rozwiązania powinieneś szukać w swoich ustawieniach. Arbitralna zmiana czcionki, choć być może polepsza wygląd u Ciebie lokalnie, to pogarsza go u wszystkich innych, korzystających ze standardowych ustawień. Nie tędy droga. Zdzislaw (dyskusja) 16:50, 16 lis 2020 (CET)

No i zawsze to u mnie źle działało, aż przebrała się miarka... Moim zdaniem nie wygląda to aż tak źle. A u mnie wygląda o wiele lepiej niż było. A po za tym powinno prawidłowo działać na monitorach większości użytkowników, nawet u takich, którzy mają problemy ze wzrokiem i sobie muszą tekst powiększyć, a jak widać nie działało bo napis był za długi. I nikt do tej pory po mojej korekcji nie zgłaszał jednak problemu, że ta drobna zmiana mu jakoś szczególnie przeszkadza. Electron  ^<Odpisz> 17:05, 16 lis 2020 (CET)

Nikt przez 10 lat nie zgłaszał żadnych uwag, że napis jest za długi. To 1. "jak widać nie działało bo napis był za długi" jest nieuprawione ponieważ pomimo mojej prośby w pierwszej wypowiedzi (mógłbyś wyjaśnić (pokazać)), zamiast pokazać, jak ten nagły problem się objawił, stwierdziłeś, że ledwo się mieścił. To 2. Powiększenie poprzedniej wersji nie powinna powodować problemu, ponieważ powiększałaby się całość, łącznie z tabelką. To 3.
To nie jest drobna zmiana (!) - co innego po prostu zmniejszyć czcionkę, a co innego wbijać bolda w arbitralny narrow, co powoduje, że przy zmianie skórki czy ustawień wiki, napis nie przystosuje się do nowej skórki, tylko zawsze będzie wymuszał Arial Narrow. A to już problem, że w najczęściej używanym szablonie pozbawiłeś wszystkich użytkowników skórki timeless zgodności wyświetlania treści szablonu z całością wybranej skórki (Segoe UI). Wygląda to po prostu nieładnie i razi, gdy jeden napis w tabeli jest inny. Innych styli to także dotyczy. To 4. Uważam, że to nie jest ok i nie jest to dobra praktyka. Wspólne szablony powinny korzystać z ustawień skórki, powinny być responsywne, a nie wymuszać parametrów takich jak krój czcionki, bez powiązania z całością. Zdzislaw (dyskusja) 17:34, 16 lis 2020 (CET)

Być może nie powinna a jednak powodowała (myślisz, że w innym przypadku zawracał bym sobie tym głowę?). Jak masz lepszy pomysł na skrócenie nagłówka to działaj śmiało... Bierz jednak pod uwagę, że krótkowzroczni i niedowidzący też mają prawo do prawidłowego jego działania przy różnych monitorach i różnych ustawieniach ich parametrów. Btw. Ktoś korzysta z owej egzotycznej skórki? Robiłeś jakieś badania? Btw2. Masz nieprzyjemną tendencję do narzucania innym tylko twojego punktu widzenia. A tu potrzebny jest szeroki kompromis. Electron  ^<Odpisz> 18:25, 16 lis 2020 (CET)

Cóż, wręcz przeciwnie. Po to prosiłem w pierwszej wypowiedzi o pokazanie problemu, ponieważ chciałem poznać jego genezę i zastanowić się, czy nie da się wprowadzić dodatkowej responsywności tego elementu. Lecz (jak zwykle) przypisałeś mi złą wolę i insynuujesz tendencję do narzucania. Starałem się odtworzyć samodzielnie problem, lecz pomimo ustawienia w przeglądarce (Chrome) rozmiaru czcionki na "bardzo duży" (nie powiększenia, bo te powiększa wszystkie elementy) nie udało mi sie odtworzyć problemu:

Ty zaś, zarzucając mi złą wolę (standard), w komentarzu sugerujesz, że nie biorę pod uwagę krótkowzrocznych, niedowidzących... Idąc tym tokiem powinniśmy w całym serwisie wbić "Narrow", bo zawsze znajdzie się nietypowy stopień powiększenia, przy którym np. opisy w menu bocznym będą uciekać... Otóż responsywaność polega na tym, aby zawartość dostosowywała się do ustawień przeglądarki (tak dopasowywany jest natywny css skórek i nowy Wektor od 12.2019 (można go uruchomić testowo w Preferencjach)). I jeżeli tu (w DT) wymagana byłaby zmiana jego zachowania (swoją drogą oczywiście stała szerokość tabel to zwyczaj bardzo niedobry z punktu widzenia dzisiejszych standardów, lecz tutaj akurat paradoksalnie chroni ona przed przeskakiwaniem), gdybym poznał przyczynę, możnaby... lecz wolisz podejście bo tak. W takim wypadku najlepszym rozwiązaniem, zamiast arbitralnego wbijania fontu Narrow, byłoby po prostu dodanie klasy do opisu i wtedy każdy, komu nagle przeszkadza standard, prostą edycją jednej linii w swoim CSS-ie może sobie ustawić dowolną niestandardową czcionkę, rozmiar, szerokość.... tyle. Zdzislaw (dyskusja) 20:58, 16 lis 2020 (CET)

No jakoś to tak wynika z mojego (pewnie jednostkowego) doświadczenia: zwykle nikt (z których większość to zwykle częstszy bywalce) nie zgłasza żadnych uwag, po czym zjawiasz się (zwykle po dłuższej nieobecności) ty i od razu z jakimiś pretensjami...

No dobra, jak ci się to do czegoś nada: od jakichś kilkunastu lat korzystam z monobooka, WinXP, FF ESR 52.9.0 (ostatni mohikanin zdolny do pracy z XP i nie blokowany przez wikimedię), ekran 21,5" FullHD (1920x1080), rozmiar czcionki: normalny, DPI: 150% normalny (przy mniejszym powiększeniu czcionek na tym ekranie ledwo co je widać). I na razie nie zamierzam tego zmieniać, bo jest to ustawienie dobrane po licznej ilości prób i dla mnie najbardziej optymalne. Zresztą wszystkie inne szablony pracują w większości wiki poprawnie. Ten tylko się rozłazi, a konkretnie prawe strzałki w nagłówku. Electron  ^<Odpisz> 12:53, 17 lis 2020 (CET)

@Electron: Czy zaoferujesz jakiś screenshot w ramach przykładu? No i żeby Zdzisław wobec Twoich zarzutów nie stał sam, to stwierdzam, że i u mnie Twoja zmiana sprawiła, że szablon prezentuje się bardzo źle. Vearthy (dyskusja) 13:32, 17 lis 2020 (CET)

Nie wiem czy to coś pomoże, ale ok, przesłałem obrazek, w pełnej krasie. To oczywiście kwestia gustu, ale nie należy przesadzać - moim zdaniem jest nieźle, a po za tym znosi on obecnie mężnie nawet bardzo duże powiększenia, czego nie można było powiedzieć o wersji poprzedniej. Electron  ^<Odpisz> 14:05, 17 lis 2020 (CET)

Btw. Dla jednolitości można by było całą tabelkę dać Narrowem: dodatkową zaletą byłoby to, że zmieściło by się więcej treści w krótszej tabelce, bo obecnie przy wielopoziomowych długich tytułach zwykle strasznie się ona wydłuża... Electron  ^<Odpisz> 14:29, 17 lis 2020 (CET)

@Electron: Na wstępie, prosiłbymm o zaprzestanie osobistych wycieczek w stylu:
"zwykle nikt (z których większość to zwykle częstszy bywalce) nie zgłasza żadnych uwag, po czym zjawiasz się (zwkle po dłuższej nieobecności) ty i od razu z jakimiś pretensjami".
Sugestie, że moja osoba zwylke kojarzy się z dłuższymi nieobecnościami jaki ma cel? (pretensje pominę). Czy sugerujesz, że "częstszy bywalec" jest kimś lepszym, a więc ja gorszym?? Gorszym od kogo? A może niegodnym, aby zwrócić uwagę na coś, co od razu po zwykłej mojej dłuższej nieobecności rzuca się w oczy i kłuje zaburzając natywny styl i repsponsywność skalowania? Jaki jest cel zwracania uwagi użytkowników czytających ten wątek na moje częste i długie (z czym się nie zgadzam) nieobecności, a nie na podniesiony problem merytoryczny. Czy chodzi o odwrócenie uwagi od problemu i skierowaniu uwagi na mnie jako Usera, który ma pretencje, poza tym często jest nieobecny, w przeciwieństwie od częstszy bywalce? Pisałem o tym przy Twoim PUA i w odpowiedzi czytałem, że takie wycieczki nie są ok. W dalszym ciągu uważam, że wrzucanie mimochodem wstawek osobistych nie jest ok w dyskusjach na wiki. Takie wbijanie szpileczki, i powtarzające się przypisywania złej woli tej drugiej stronie jest, w mojej ocenie, szkodliwe dla projektu opartego na współpracy społeczności. Nie czuję się z tym dobrze.
Wracając do meritum. Cóż, monobook, który z natury skaluje w dół, plus 21,5" przy FullHD, to rzeczywiście połączenie wymagające niestandardowego skalowania dla czytelności. Na to nie wpadłem. Oczywiście, można sobie wyobrazić bardziej daleko idące dostosowanie ekranu, pomagające osobom ze szczególnymi wymaganiami. I jako, że uważam, że każdy powinien mieć możliwość wprowadzenia przy istotnych elementach interfejsu niestandardowego ustawienia styli, tak jak dla większości elementów skórki, co nie było uwzględnione pierwotnie w szablonie, poprawiłem DT dodając klasę dttable, dzięki której każdy może dowolnie dostosować np. czcionkę w DT. Wystarczy na swojej stronie common.css dopisać kilka linii stylu i poczkać kilka minut, np. (dla Arial Narrow):

/* Style dla DT */
.dttable  {
	font-family: "Arial Narrow";
}

Zdzislaw (dyskusja) 01:06, 20 lis 2020 (CET)

Dla tych co nie lubią wycieczek: uważam, że łatanie zasadniczego problemu (czyli napisu zrobionego zbyt szeroką czcionką) za pomocą css-u to jest po prostu porażka. Należałoby zająć się wreszcie tym problemem a nie go obchodzić (z lewa lub z prawa), bo to nie wygląda zbyt profesjonalnie, gdy krytyczny, często używany szablon sobie po prostu nie radzi... Większość osób, u których ten problem występuje i tak nie będzie go łatała css-em ale po prostu uzna, że tak po prostu jest i większości to widocznie nie przeszkadza... I oczywiście może coś sobie pomyśleć o profesjonalizmie jego twórców... Electron  ^<Odpisz> 15:23, 23 lis 2020 (CET)

Stwierdzenie, że DT sobie nie radzi jest nadmiarowe. DT, zgodnie ze sztuką, przejmuje krój czcionki z elementów wyższego poziomu, a więc dostosowuje się (tak jak każdy inny element interfejsu użytkownika wiki) do całości interfejsu, a samo skalowanie rozmiaru fontu także nie jest wymuszane (np. w px), lecz skaluje (do 120%) ten przyjęty przez Twórcę skórki, przeglądarki lub ustawień użytkownika. Jak użytkownik ustawi sobie ulubioną skórkę to treść w DT przejmuje jej krój, styl, wielkość..., jeżeli ktoś wymusi czcionkę w ustawieniach przeglądarki, DT się dostosuje... To właśnie próba narzucenia kroju czcionki w css powoduje nieradzenie sobie szablonu. Twórcy DT zarezerwowali 250px dla zaledwie 17 znaków - myślę, że to duży zapas, i dla 99,9% przypadków nie powinien powodować problemów. Czy obecne 120% to za dużo? Jeżeli to nagłówek tabeli, to powinien się wyróżniać nieznaczenie. Jeżeli nie mieści się w swojej kratce, to raczej w przypadku nietypowych ustawień. Można by usunąć to 120%, lecz czy to byłoby dobre posuniecie, aby zmniejszyć liczbę użytkowników, którym napis w DT się ne mieści o ~0,01%?? Można by oczywiście także zacząć wymuszać automatyczne powiększanie szerokości DT, lecz byłoby to być trudne i powodować inne problemy. Zdzislaw (dyskusja) 20:11, 24 lis 2020 (CET)

Zdania nie zmieniam: uważam, że często używany krytyczny szablon powinien być tak skonstruowany ("sam w sobie") aby się nie rozjeżdżał przy byle powiększeniu, nawet w trochę niestandardowych warunkach... Bo to jest po prostu obciachowe dla serwisu. Być może powinien być default ciutek szerszy lub te strzałki powinny być "sklejone" z napisem nagłówka jakimiś spacjami niełamliwymi, które by wymuszały jego większą szerokość... Zauważyłem na przykład, że gdy szablon wypełniają długie tytuły/nad i podtytuły, to się on lekko poszerza i wtedy już nie jest taki wrażliwy na przeskakiwanie strzałek (to jest chyba kwestia 1-2 znaków). Tak czy owak stan obecny jest niezadowalający. Electron  ^<Odpisz> 13:26, 25 lis 2020 (CET)

tak, gdyby usztywnić w jakiś sposób łańcuch w nagłówku, tabela powinna się, ja to ująłeś lekko poszerzyć zamiast powodować przeskakiwanie. Uważam, że to dobry pomysł. Nie wiem jeszcze, jaki sposób tego uszytwnienia byłby najlepszy, lecz przyjrzę się temu w najbliższym czasie. Zdzislaw (dyskusja) 16:45, 25 lis 2020 (CET)

Zastanawiam się, czy nie można by poprawić tego problemu przez zastosowanie em w miejsce px. Paelius (dyskusja) 09:48, 13 paź 2021 (CEST)

Update to ICU Unicode library

Począwszy od 16 listopada 2020 będziemy dokonywać migracji na serwerach MediaWiki do nowej wersji biblioteki Unicode ICU (w:International Components for Unicode) (z wersji 57 na 63). To odblokuje nam nowe możliwość przyszłej aktualizacji wydań systemu operacyjnego oraz korzystanie z ulepszonych mechanizmów internacjonalizacyjnych, związanych z nowymi funkcjami udostępnianymi przez nową wersję ICU, takimi jak nowe definicje porównywania znaków czy najnowsza wersja Unicode w MediaWiki.

Podczas migracji mogą wystąpić nieuniknione przejściowe widoczne dla użytkowników utrudnienia. Sortowanie w niektórych kategoriach może zostać czasowo zaburzone. Będziemy uruchamiać skrypt, który zaktualizuje poprawny sposób sortowania starych wpisów.

Te zaburzenia mogą trwać od kilku godzin (wiki średniej wielkości) do jednego dnia (duże wiki) i przez kilka dni na anglojęzycznej Wikipedii. Czas rozpoczęcia zależy od czasu dotarcia przez skrypt aktualizujący do poszczególnych wiki.

Będzie to miało wpływ na 149 wiki (w tym osiem największych Wikipedii). Lista szczegółowa i opis techniczny implementacji znajduje się w T264991.

Dziękujemy.

Trizek (WMF) 15:53, 16 lis 2020 (CET)

Indeks do usunięcia

Mamy w Proofread dwie książki z opowiadaniami Oscara Wilde'a: Duch z Kenterwilu i Duch w zamku. Oba zawierają praktycznie tę samą treść - te same opowiadania i to samo ich tłumaczenie. Jedyną różnicą jest tytuł jednego (a co za tym idzie - także tytuł całego zbioru), no i oczywiście wydawnictwa. Nie zauważyłam też różnic w pisowni. Oczywiście nie porównywałam absolutnie całych tekstów, niemniej wyrywkowe sprawdzanie oryginałów z Polony ([34] i [35]) dawało identyczne wyniki.

Proponuję więc usunąć ten drugi indeks (Duch w zamku), bo pierwszy jest już częściowo przepisany (oraz jest to wydanie wcześniejsze o 2 lata) - nie ma sensu dublować pracy. --Czupirek (dyskusja) 16:07, 27 lis 2020 (CET)

 Za jeśli nie będzie osoby, która by chciała przepisać. Matlin (dyskusja) 20:21, 27 lis 2020 (CET)

• Tylko czemu to zgłoszenie jest tutaj, a nie na właściwej ku temu stronie? Ankry (dyskusja) 12:52, 27 kwi 2021 (CEST)

Problem z zamieszczeniem w indeksie stron

Zgłaszam problem. Próbowałem zamieścić w Indeks:PL Wstęp do nauki prawa cywilnego H. Capitant pozostałe strony, ale nie serwer nie chce ich zapisać. Serwer pozwolił mi tylko wstawić pierwszą stronę. Próbowałem zarówno z laptopa, jak i ze smartfona. Kod źródłowy ze stronami udało mi się zamieścić na stronie dyskusji indeksu. Superjurek   (Dyskusja) 23:49, 12 lut 2021 (CET)

Techniczny problem nie jest trudny do rozwiązania. Natomiast moim zdaniem musimy ustalić daty śmierci obu panów (autor, tłumacz) i datę wydania oryginału. Draco flavus (dyskusja) 09:50, 13 lut 2021 (CET)

Lepiej jest scalić pliki. Matlin (dyskusja) 14:33, 15 lut 2021 (CET)

Technical maintenance planed‬

A maintenance operation will be performed tomorrow morning UTC time (Wednesday 17th at 07:00 AM UTC).

It will impact all wikis and is supposed to last up to one minute.

During this time, new translations may fail, and Notifications may not be delivered. For more details about the operation and on all impacted services, please check on Phabricator.

A banner will be displayed 30 minutes before the operation.

Thank you, SGrabarczuk (WMF) 18:45, 16 lut 2021 (CET)

Scalenie tabelek ze spisem treści

Cześć, potrzebuję pomocy ze scaleniem tabelek. Jak wykonać łamanie tabeli na kilku stronach? Chodzi o spis treści który wyświetla się na stronie tytułowej mojej pracy magisterskiej. Chciałbym żeby justowanie było jednolite dla wszystkich trzech stron, przez które się przewija spis treści, to jest strony 4, strony 5 i strony 6. Z góry dzięki :) Superjurek   (Dyskusja) 14:17, 18 mar 2021 (CET)

@Superjurek: Chyba wystarczyłoby użyć samego szablonu {{SpisPozycja}} bez tabelki. Joanna Le (dyskusja) 15:55, 18 mar 2021 (CET)

@Joanna Le: Faktycznie, dziękuję za słuszną wskazówkę. Superjurek   (Dyskusja) 10:40, 19 mar 2021 (CET)

Niepotrzebne wcięcie w nagłówku nr 3.10

Mam problem, w tym rodziale powstaje mi wcięcie przed nagłówkiem 3.10, choć nie wynika ono nijak z kodu źródłowego stron.Superjurek   (Dyskusja) 18:52, 20 mar 2021 (CET)

Może to dlatego że w 3.10 nie użyto znacznika section tak jak w innych. --Wargo (dyskusja) 22:51, 5 kwi 2021 (CEST)

@Superjurek: parser nie widział zakończenia wypunktowania. Zdzislaw (dyskusja) 00:51, 6 kwi 2021 (CEST)

Futrue of FlaggedRevs (Pending Changes) extension

Pomóż przetłumaczyć na Twój język

Hello, I’m posting this here because this wiki has FlaggedRevs (Pending Changes) enabled.

This extension is one of the oldest extensions we have in production and currently does not have a maintainer. FlaggedRevs has been the cause of several incidents and visible regressions, especially because software decays and our technology constantly changes.

Another problem with this extension is its scope. While most of its functionalities are not enabled at Wikimedia, or are enabled on a very small set of wikis only (e.g. "multiple dimensions" was enabled only on Hebrew Wikisource, and they agreed to disable it). This has made maintaining the extension a tall order (more of a nightmare). In other words, this extension does too many things, and none well.

To move forward, barely used functionalities of this extension will be removed. Such as: support for multiple dimensions (like “style” and “tone”), multiple tiers (“quality” and “pristine”), several one of its special pages (ProblemChanges, ReviewedPages, ReviewedVersions, QualityOversight), and more. This will make it less of a burden to start maintaining and improving the main functionalities. The user interface will have only one mode in the future (currently it has four).

You can check this Phabricator ticket for more information about functionalities being removed: phab:T277883

These removals would simplify its logic drastically, and enable us to rework its old interface, fix several deprecated dependencies that this extension is the last to block their removal of (like the "action=ajax" API), and reduce the number of issues/incidents/regressions that can be caused by this extension.

Most users of wikis that have this extension enabled (including English Wikipedia and German Wikipedia) won't see any difference. Wikis will still be able to use multiple "levels" (but not multiple "tiers") and will still be able to enable pending changes for whole namespaces, or on a group of pages only (otherwise known as “protect mode”). Those features will not be removed.

To follow the discussion around this, take a look at T185664.

Thank you for understanding and sorry for any inconvenience. Ladsgroup (talk) 18:17, 23 mar 2021 (CET)

Szablon:Odnośnik

Wczoraj utworzyłem ten szablon na potrzeby przypisów harwardzkich w mojej pracy magisterskiej. Mam nadzieję, że przyda się też przy innych przyszłych pracach dyplomowych, które ktoś zechce udostępnić na wolnej licencji. Na komputerze działa ok, bo wyświetla dymek przy kursorze. Mam jednak pytanie, czy da się go tak ulepszyć, żeby dymek wyświetlał się również na urządzeniach mobilnych? Superjurek   (Dyskusja) 09:51, 4 kwi 2021 (CEST)

Rozmiar i typ pliku źródłowego a jakość edycji

Dzień dobry! Chciałbym poruszyć dwie problematyczne kwestie:
1) Proszę otworzyć sobie edycję 2. strony tej noweli. Obrazek ze skanu już przy lekkim powiększeniu wygląda słabo. Gdy zerkniemy na grafikę widzimy, że ma ona szerokość tylko 770px. Jak to możliwe, skoro źródłowa strona podaje rozmiar 2043 × 1128 pikseli? Okazuje się, że oprogramowanie, na którym tu pracujemy, dostosowuje szerokość obrazków wszystkich stron skanu do szerokości jego pierwszej strony. Czyli w większości przypadków tego problemu nawet nie zauważymy, bo w książce skany stron mają bardzo zbliżone do siebie wymiary. Natomiast w przypadku takich „wycinanek“ gazetowych to rozwiązanie techniczne się nie sprawdza i nawet z najlepszej jakości pliku wyjść może kupa. Wiem, że „wycinanki“ gazetowe są małym procentem na WŹ i tylko garstka ludzi będzie musiała tę niewygodę zmęczyć, ale mimo wszystko pytam, czy można to zmienić? Dałoby radę zrobić tak, żeby kolejne strony zachowywały swoją rozdzielczość (przynajmniej w przypadku takich dużych różnic)?
2) Jakość obrazka w oknie edycyjnym w przypadków PDF-ów mocno rozczarowuje. Zainteresowanych zachęcam do porównania np. którejś ze stron powieści Syzyf z plikiem oryginalnym. Pytanie moje brzmi: czy jest szansa polepszyć jakość tego? Czy może po prostu omijać PDF-y szerszym łukiem?

Seboloidus (dyskusja) 20:14, 10 kwi 2021 (CEST)

ad 1. niestety tak właśnie jest, są trzy możliwości rozwiązania: a. "podwatowanie" pierwszego obrazka do rozmiaru innych (jeśli tylko on jest taki karłowaty) b. zamieszczenie całego indeksu w formie osobnych obrazków c. zamieszczenie pierwszego obrazka (zakładając że jest to tylko "strona tytułowa" i jest powtórzona na następnym obrazku) jako osobnego obrazka ("okładki") -- znowu z zastrzeżeniem jak w punkcie a. Do wycinanek rozwiązanie b jest najlepsze, ponieważ pozwala bezboleśnie podmieniać skan (lub wstawiać dwa zamiast jednego), można też podawać dokładniej źródło każdego wycinka, można potem połączyć ze skanem całej gazety itp. Jest to jednak dość pracochłonne.

ad 2. z pdf-ami bywały rzadko bo rzadko ale problemy techniczne, ja osobiście wstawiam tylko djvu, ew. jpg/png (wycinanki). Chyba że oryginalny pdf jest tak niskiej jakości, że jakakolwiek konwersja spowoduje nieczytelność pliku wynikowego.

Draco flavus (dyskusja) 20:40, 10 kwi 2021 (CEST)

@Draco flavus: Dzięki za informacje, rzeczowo to podsumowałeś. Osobiście bardziej mi odpowiada, aby cały utwór był w jednym pliku (nie wiem ile w tym wygody, a ile przyzwyczajenia), więc w tej problematycznej kwestii skłaniać się będę do opcji a.

Co do pkt. 2 — ja wrzuciłem chyba tylko dwie książki w pdf-ach, skuszony niewielkimi rozmiarami plików, których nie osiągnąłbym po przekonwertowaniu na djvu, chcąc zachować dobrą jakość. I to rozumowanie okazało się błędne. Seboloidus (dyskusja) 23:13, 10 kwi 2021 (CEST)

@Draco flavus: Rozwiązanie z powiększeniem pierwszego obrazka do rozmiaru pozostałych sprawdza się bardziej w teorii niż w praktyce. Na przykładzie tego opowiadania widać, że grafika ma 3219px, ale cóż z tego, skoro obrazek w okienku ma wielkość 1024px(!) Zaś samo okienko przy większym powiększeniu strony zaczyna przypominać wizjer z tankietki... Domyślnie nie da się tego okienka powiększyć (co uważam za kolejny minus), lecz można to zmienić w indywidualnym common.css (gdyby kogoś interesowało: .prp-page-image { resize: vertical; }). Seboloidus (dyskusja) 13:35, 14 kwi 2021 (CEST)

W rozwiązaniu b. (zamieszczenie całego indeksu w formie osobnych obrazków) jest to samo. Dla przykładu w Bajce o Gacku 3-szpaltowe grafiki mające szerokość ponad 3700px są wyświetlane w oknie edycyjnym w rozmiarze 1024px... 😐 Seboloidus (dyskusja) 01:28, 17 kwi 2021 (CEST)

Założenie proofreadpage było takie, że skan powinien się mieścić w prawej połówce okna; raczej mało kto ma ekran o szerokości 7400px. Z drugiej strony, obraz nie powinien być zbyt duży, by nie generować niepotrzebnego ruchu sieciowego (niektórzy wciąż płacą za przetransferowane bajty). Myślę, że gdy standardem będą ekrany o szerokości większej niż 2048px, to można będzie zgłosić programistom sugestię powiększenia domyślnej wartości dla maksymalnego rozmiaru skanu. Wieralee swego czasu optowała za dzieleniem wieloszpaltowych tekstów na osobne szpalty. Wg mnie, o ile w przypadku książek takie podejście może być dyskusyjne, w przypadku wycinków jest bardzo sensowne. Ankry (dyskusja) 14:29, 25 kwi 2021 (CEST)

@Ankry: Zgadzam się z założeniem, że skan winien się mieścić w połówce okna. I tak się dzieje, bo jest on na początku wczytany z odpowiednio wyskalowaną width. Problemem jest ta domyślna wartość dla maksymalnego rozmiaru skanu (1024px tutaj), z której on startuje, i która go ogranicza. Gdyby obrazek z Gacka miał 3700px szerokości, to w okienku przy powiększeniu do jednej szpalty osiągnąłby pożądaną jakość, a to — w połączeniu w możliwością wydłużenia tego okna, o czym wyżej napisałem — byłoby umożliwiające komfortową pracę. (Edytowanie z wyświetlonym w całości 3-szpaltowym skanem na super szerokim ekranie moim zdaniem byłoby niepraktyczne, bo przy edycji wzrok niepotrzebnie błądziłby w nadmiarze tekstu.) Rozwiązanie widziałbym w dodatkowej, włączanej w preferencjach opcji, która pozwalałaby wczytywać każdą stronę skanu ze swoją nominalną szerokością (albo przynajmniej wykorzystywać szerokość pierwszej z parametru data-file-width), za cenę niewygody, czyli zapewne dłuższego wczytywania stron. Biorąc jednak pod uwagę marginalność problemu, a właściwie ilość osób, którym to przeszkadza, to pewnie taka opcja „dla koneserów“ nie powstanie prędko, bądź wcale. Nauczony zatem doświadczeniem... ✂ kroję... Pozdrawiam. Seboloidus (dyskusja) 18:11, 25 kwi 2021 (CEST)

@Seboloidus: Myślę, że nie rozumiesz gdzie leży problem. Chodzi o to, że często skany są w dużo większej rozdzielczości niż potrzebna. A generowanie skanów o szerokości 2048px dla bajeczek dla dzieci, drukowanych dużą czcionką to jest marnotrawstwo zasobów: potrzeba na to więcej zasobów serwera, więcej bajtów przesłać siecią i wymagać więcej zasobów od przeglądarki (2x większa rozdzielczość to 4x większy plik). I dotyczyłoby to wszystkich skanów, gdzie uzyskanie takiej rozdzielczości jest technicznie możliwe. Dotyczyłoby to przy tym wszystkich użytkowników na całym świecie (a niektórzy mający słabe komputery/łącza mogliby nie być z tego zadowoleni). Dlatego zmiana domyślnej wartości raczej nie wchodzi w grę. Ale proofread wspiera od dawna możliwość ustawiania tej rozdzielczości indywidualnie, per indeks (zobacz np. na mul: parametr Width of scans). U nas nie zostało to zaimplementowane, bo nikt tego dotąd nie potrzebował. Można to zrobić, tyle że jest to dość głęboka ingerencja w system, zmieniająca strukturę indeksu i wymagająca poprawienia szeregu plików konfiguracyjnych oraz, być może, zmodyfikowania botem wszystkich indeksów. Krótko mówiąc: potrzeba konsensusu i kogoś, kto to zrobi (będzie umiał i znajdzie na to czas). Przy ostatnich grzebaniach w strukturze indeksu parę lat temu konsensusu na to nie było (kilka osób podczas wstępnej dyskusji uznało, że to niepotrzebne). Natomiast nie mam 100% pewności, czy da się ustawić indywidualnie większą rozdzielczość niż domyślna maksymalna. Trzeba by to sprawdzić (albo w kodzie proofreadpage, albo przetestować, np. na mul:). Ankry (dyskusja) 20:31, 25 kwi 2021 (CEST)

Cóż, nie wszystko jestem w stanie pojąć, ale tutaj zrozumiałem chyba wystarczająco dużo. @Ankry: Dziękuję za wypowiedź. Seboloidus (dyskusja) 21:45, 25 kwi 2021 (CEST)

ad 1... d. można zaimplementować w indeksie funkcję ręcznego ustawiania szerokości skanów; wtedy wszystkie strony będą najpierw skalowane do tej szerokości (być może część skalowana w górę), a dopiero potem dostosowywane do aktualnych potrzeb (rzeczywistego powiększenia ekranu). Niektóre wiki mają to zaimplementowane. U nas dotychczas nie było ku temu motywacji. Jednak wątpię, by w przypadku wycinków był to dobry pomysł: generalne założenie jest takie, że dla jednaj "książki" rozmiar stron powinien być ustalony. Ankry (dyskusja) 14:29, 25 kwi 2021 (CEST)

Jak powiększyć przyciski pod polem edycji?

Dzień dobry,
W mojej pracy z Wikiźródłami całkowicie nie korzystam z fizycznej klawiatury i myszki, a moim głównym narzędziem pracy są przyciski pod polem edycji. Problem w tym, że niektóre z nich są na tyle małe, że mam problem z ich wybraniem. Czy jest jakiś sposób na powiększenie (nawet 200-300%) tych przycisków bez powiększania całej strony. Rozmiar pozostałego tekstu na stronie mam odpowiedni. Mahnka (dyskusja) 17:33, 24 kwi 2021 (CEST)

• @Mahnka: Dobry wieczór! Nie jestem specem w tym zakresie, ale ja bym rozwiązał to w taki sposób: na swojej stronie common.css proszę wpisać:

/* Wielkość przycisków pod polem edycji */
.plainlinks {
  font-size:200% !important;
}

Wielkość procentowa wedle potrzeb (domyślnie jest 95%). Seboloidus (dyskusja) 22:35, 24 kwi 2021 (CEST)

Problemy z szablonem Odnośnik

Ad. Problemy z szablonem Odnośnik
Wracam się z prośbą o pomoc z tym szablonem. Więcej opisałem w dyskusji szablonu.
Superjurek   (Dyskusja) 21:33, 25 kwi 2021 (CEST)

Abstrahując od technikaliów, nie bardzo rozumiem cel tego szablonu: jeśli informacji w "dymku" nie ma w oryginalnym tekście, to może raczej powinien to być {{Przypiswiki}}? Ankry (dyskusja) 12:39, 27 kwi 2021 (CEST)

Pusta strona w wygenerowanym PDF

Dzień dobry,
Czy to jest normalne że w PDF jaki wygenerowałem dla tekstu Antoni Sznejder cała pierwsza strona jest pusta? Mahnka (dyskusja) 14:40, 27 kwi 2021 (CEST)

U siebie na pierwszej stronie mam trzy portrety Sznejdera, tak do 1/3 wysokości strony. Poniżej czarno. Szandlerowski (dyskusja) 15:03, 27 kwi 2021 (CEST)

@Mahnka, @Szandlerowski: To nie jest normalne, aczkolwiek występuje już od pewnego czasu. Na pierwszej stronie ongiś ładowany był obrazek okładki książki. U mnie przy otwarciu PDF wyskakuje komunikat "Niewystarczające dane dla obrazu" i pozostaje pusta pierwsza strona. ♦ Druga ciekawostka to: na końcu PDF jest zapis "W tworzeniu niniejszej książki uczestniczyli następujący wolontariusze:" i znów od pewnego czasu pojawiło się tam, oprócz wikiskrybów mających oczywisty wkład w daną książkę, ok. 7 - 8 nicków osób spoza naszych WŹ, które na pewno tej książki nie tworzyły. Nie znam przyczyn obydwu zjawisk. Seboloidus (dyskusja) 23:30, 27 kwi 2021 (CEST)

@Szandlerowski: Zmieniłem wyświetlarkę PDF-ów i właśnie poznałem ten efekt trzech rozpikselowanych obrazków u góry strony... Czyli nadal bez zmian. Seboloidus (dyskusja) 02:03, 30 paź 2021 (CEST)

Szablon:===

Czy ktoś z was wie może dlaczego szablon Szablon:=== nie wyświetla się wycentrowany tylko z przesunięciem do prawej, u mnie wyświetla się prawidłowo, a u @Mahnka: w ten sposób: https://ibb.co/khp9DQz Joanna Le (dyskusja) 16:02, 27 kwi 2021 (CEST)

@Joanna Le: z powodu szablonu Dane tekstu. On powoduje od bardzo dawna problemy z centrowaniem i przesuwa linie, podobnie robi z szablonem ---. Gdy linie znajdują się już poniżej szablonu Dane tekstu wszystko wyświetla się dobrze. Tommy J. (pisz) 16:12, 27 kwi 2021 (CEST)

Czasopisma i szpalty

Mam taki temat, z którym na razie mentalnie nie mogę sobie do końca poradzić... chciałbym wrzucić tu czasopismo "Inżynier Kolejowy" (patrz. https://winntbg.bg.agh.edu.pl/skrypty4/0542/1924-25/InzKol_01_1924.pdf ) ino nie bardzo wiem jak sobie poradzić ze szpaltami i ogólnie jak się do tego zabrać. Chętnie bym poznał przykłady (których nie potrafię znaleźć) lub poznać rady bardziej doświadczonych Wikiskrybów Jacek Fink-Finowicki (dyskusja) 09:54, 30 kwi 2021 (CEST)

Dzień dobry,
Nie wiem czy robię dobrze, bo robiłem to niedawno pierwszy raz, ale ja na potrzeby tego indeksu pociąłem strony na pojedyncze prostokąty odpowiadające mniej więcej proporcjom zwykłej książkowej strony. Jeśli stron jest więcej i mają regularny podział, to takie cięcie można zautomatyzować i efekt ponownie skleić w PDF. Gorzej jeśli oryginalny plik miał OCR. Ale ja i tak zauważyłem że najlepiej mi się pracuje z OCR od Google aplikowanym już na stronie. Mahnka (dyskusja) 11:49, 30 kwi 2021 (CEST)

Jest to jakiś pomysł... tylko po pierwsze "moje" PDFy mają OCR, którego k=trochę szkoda tracić. Po drugie, czy konieczne jest ręczne dzielenie na szpalty, czy po prostu możemy uznać, że układ w szpaltach jest wtórny i możemy lecieć tekstem ciurkiem - wolałbym uniknąć dodatkowej ingerencji w pliki źródłowe Jacek Fink-Finowicki (dyskusja) 23:27, 30 kwi 2021 (CEST)

Te twoje czasopisma mają prosty układ. Uważam, że można je zamieścić, jak są (raczej ew. może konwertując do djvu). Przepisując można pomijać fakt, że są łamy. Dzielenie na łamy/artykuły itp. ma sens, gdy to jest gazeta ze skomplikowanym układem (jak gazety codzienne) z 3–5 łamami. Draco flavus (dyskusja) 23:45, 30 kwi 2021 (CEST)

Kiedyś był taki projekt i jemu podobne. Tam pominięto w przepisywaniu szpalty. Tommy J. (pisz) 09:38, 1 maj 2021 (CEST)

Można zeszkrobać OCR z pliku, umieścić go w dyskusji indeksu i kopiować sobie do stron podczas przepisywania. Albo pociąć szpalty i ponownie wygenerować OCR z jakiegoś dobrej jakości narzędzia. Matlin (dyskusja) 13:30, 1 maj 2021 (CEST)

Na pewno nie ma sensu tworzyć przy przepisywaniu tekstu szpalt, które później utrudniałyby połączenie stron. Jeżeli komuś zależy na dwuszpaltowej prezentacji stron, to można ją zrobić w oparciu o nagłówek i stopkę. Z drugiej strony, te strony są obszerne i ich przepisywanie (niezależnie, czyt będzie to każda szpalta osobno, czy całe strony) i tak będzie kłopotliwe. Podział na osobne szpalty, będzie wymagał odcięcia nagłówków (które nie sa dwuszpaltowe), jednak wg mnie decyzja co do sposobu opracowywania należy przede wszystkim do opracowującego. tutaj mamy przykład indeksu, który miał dwuszpaltowe strony. Ankry (dyskusja) 14:10, 1 maj 2021 (CEST)

OCR to to ma całkiem dobry... ba mam pierwszy numer prawie na gotowo zrobiony na moim komputerze. Lecę bez zbędnych szpalt - nie jesteśmy wszak drukarnią ;) Gorzej, że występuje wątek PA, który trzeba umiejętnie rozpracować Jacek Fink-Finowicki (dyskusja) 01:02, 2 maj 2021 (CEST)

@Jacek Fink-Finowicki: Można rozważyć przeniesieniu projektu w całości na mul: Gdybyś się na to zdecydował, daj znać: pomogę go tam zaimportować. Ankry (dyskusja) 01:01, 3 maj 2021 (CEST)

@Ankry: To ja właśnie o taką pomoc poproszę - jak będę wiedział jak (czyli jeśli byś zaimportował wręcz tylko pierwszy numer rocznika) to dalej już ogarnę, bo będę widział na przykładzie jak robić dalej Jacek Fink-Finowicki (dyskusja) 08:24, 3 maj 2021 (CEST)

@Jacek Fink-Finowicki: Tylko który konkretnie indeks? Przenoszenie tekstu wydanego w 1875 nie ma chyba sensu. Zakładaliśmy dotąd, że autor, który się urodził ponad 160 lat temu lub coś wydał ponad 140 lat temu, jest PD-old, nawet gdy jego data śmierci jest nieznana. Draco coś kombinował ze specjalnymi szablonami na takie przypadki, ale nie śledziłem czy sfinalizował temat. Ankry (dyskusja) 09:29, 3 maj 2021 (CEST)

@Ankry: Tenże, bo to już w nim istnieją strony których PD jest "dyskusyjne" - można by go skrócić do "Indeks:Inżynier Kolejowy - 1924" ponieważ numeracja stron w danym roczniku jest ciągła i każdy rocznik posiadał wspólny spis treści. Jacek Fink-Finowicki (dyskusja) 06:58, 4 maj 2021 (CEST)

Wydaje mi się, że Załatwione. Gdyby brakowało jakichś szablonów, daj znać. Indeks niestety trzeba było utworzyć od nowa. Ankry (dyskusja) 10:21, 4 maj 2021 (CEST)

Wykorzystanie skrótów klawiaturowych na innych projektach

Czy ktoś wie i mógłby mi pomóc jak wykorzystać u nas istniejący gadżet MediaWiki:Gadget-shortcuts.js jako skrypt własny na innym projekcie, gdzie taki gadżet nie istnieje? Probowałem to za pomocą odwołania "mw.loader.load('//pl.wikisource.org/wiki/MediaWiki:Gadget-shortcuts.js&action=raw&ctype=text/javascript');" ale bez reakcji, choć inne skrypty w ten sposób się wczytują. Tommy J. (pisz) 19:37, 1 maj 2021 (CEST)

Jak widać z MediaWiki:Gadgets-definition ten gadżet potrzebuje jeszcze lib-shortcuts.js

Może pomoże wczytanie obu? Ankry (dyskusja) 01:00, 3 maj 2021 (CEST)

Nie pomogło niestety. Pewno nie umiem wywołać funkcji.Trudno, muszę sobie poradzić bez ułatwienia. Dzięki. Tommy J. (pisz) 14:44, 3 maj 2021 (CEST)

@Tommy Jantarek: źle wpisałeś adres odwołania (bez index.php). Spróbuj w ten sposób:

mw.loader.load('//pl.wikisource.org/w/index.php?title=MediaWiki:Gadget-lib-shortcuts.js&action=raw&ctype=text/javascript');
mw.loader.load('//pl.wikisource.org/w/index.php?title=MediaWiki:Gadget-shortcuts.js&action=raw&ctype=text/javascript');

Aby działało z włączonym trybem podświetlenia składni w głównym oknie edytora, należy zamienić selektor ":focus" na "#wpTextbox1" w MediaWiki:Gadget-shortcuts.js#L-16. Pozdrawiam, Peter Bowman (dyskusja) 17:29, 31 maj 2021 (CEST)

@Peter Bowman: rzeczywiście brakowało tego w adresie, wkleiłem ale nic to nie dało. Próbowałem też przekopiować zawartość Gadget-shortcuts do swojego pliku commons, ale również bez rezultatu. Trudno, widocznie tak ma być. W każdym razie dziękuję. Tommy J. (pisz) 03:37, 1 cze 2021 (CEST)

@Tommy Jantarek: poprzednio miałeś błędne wywołanie mw.loader.using, które mogło zakłócić działanie reszty (s:en:User:Tommy Jantarek/common.js). Teraz problem w tym, że funkcje gadżetu są wywoływane, zanim ten został pobrany. Powinno wystarczyć jednosekundowe opóżnienie (1000 ms):

setTimeout( function() {
    shortcutsGadget.addTextShortcut('alt+q', '—', '', '');
    shortcutsGadget.addTextShortcut('alt+t', 'ë', '', '');
    shortcutsGadget.addTextShortcut('alt+y', 'Ë', '', '');
    shortcutsGadget.addTextShortcut('alt+w', '<ref></ref>', '', '');
}, 1000 );

Peter Bowman (dyskusja) 12:04, 1 cze 2021 (CEST)

@Peter Bowman: tak, teraz zadziałało i działa rewelacyjnie. Wielkie wielkie dzięki za poświęcony czas :) Tommy J. (pisz) 15:00, 1 cze 2021 (CEST)

Długie nazwy indeksów

Właśnie zauważyłem, że mamy klikanaście indeksów o długich nazwach (powyżej 160 bajtów), których status nie jest i nie będzie na bieżąco aktualizowany przez AkBota. Należy to traktować jako ficzer, nie jako bug.

Jednocześnie zwracam uwagę, że umieszczanie linków do indeksów o długich nazwach w tabelkach typu Wikiźródła:Wikiprojekt Proofread powoduje ich szybkie puchnięcie, grozi osiągnięciem limitu i jako takie jest szkodliwe. Ankry (dyskusja) 00:26, 6 cze 2021 (CEST)

Gadżet Extract text

Dzień dobry!
W jaki sposób mogę to wyłączyć: https://i.imgur.com/1hmbdGv.png ?
Seboloidus (dyskusja) 13:42, 24 cze 2021 (CEST)

dołączam się do pytania, tym bardziej że zablokowali płynność okna edycji i nie idzie przepisywać bez przesuwania całej strony, chyba że się edytuje na ekranie kinowym.Tommy J. (pisz) 21:10, 24 cze 2021 (CEST)

@Tommy Jantarek: zerknij sobie na moje, chwilowe ukrycie problemu: Seboloidus/common.css. Być może to prowizorka, ale nic lepszego nie wymyślę. Seboloidus (dyskusja) 21:58, 24 cze 2021 (CEST)

@Seboloidus: ważne że zadziałało i ukryło. Dzięki. Jeszcze szukam jak wymusić ustawienie rozmiaru pola edycyjnego, kiedyś to się ustawiało w preferencjach, ale znikło a tak usztywnili pole edycji, że nie ma możliwości przesunąć samego tekstu widząc wciąż skan. Tommy J. (pisz) 22:29, 24 cze 2021 (CEST)

@Seboloidus: czy mogę prosić o łopatologiczne wyjaśnienie jak to zastosować? Sprawy techniczne to zupełnie nie moja bajka, a z tym przyciskiem przepisuje się fatalnie :( Sempai5 (dyskusja) 07:47, 25 cze 2021 (CEST)

@Sempai5: sprawa jest prosta: wejdź na adres Sempai5/common.css; strony tam na razie nie ma, więc ją musisz utworzyć. W treści wklej skopiowane ode mnie ostatnie linijki:

/* ukrycie przycisku Extract-text-widget*/
.ext-wikisource-ExtractTextWidget {
	visibility: hidden;
}

Zapisz zmiany i to wszystko. Pozdrawiam, Seboloidus (dyskusja) 11:57, 25 cze 2021 (CEST)

@Seboloidus: Bardzo dziękuję! Sempai5 (dyskusja) 12:07, 25 cze 2021 (CEST)

Dzień dobry! A ja mam pytanie: Czy ktoś wie gdzie raportować uwagi o tym gadżecie? Zauważyłem różnice między OCR z dotychczasowego gadżetu Google OCR, a OCR z tego nowego gadżetu Extract text w trybie Google. Niby ten sam silnik, a różne wyniki. Na korzyść starego mechanizmu. Mahnka (dyskusja) 10:41, 25 cze 2021 (CEST)

@Mahnka: myślę, że @Ankry: jest w stanie pomóc, bo udzielał się kiedyś i coś zgłaszał na Phabricatorze. Seboloidus (dyskusja) 11:57, 25 cze 2021 (CEST)

@Mahnka: zerknij na en:Scriptorium#Extract_Text_button, tam też mają z tym problemy. Zajmuje się tym gadżetem m. in. NRodriguez (WMF).Tommy J. (pisz) 17:38, 25 cze 2021 (CEST)

@Mahnka: A na czym dokładnie polega "gorszy" wynik OCR-u z nowego gadżetu? Przy okazji zwracam uwagę, że są plany usunięcia wszystkich innych OCR-owych gadgatów z Wikisource: phab:T283897. Ankry (dyskusja) 23:02, 26 cze 2021 (CEST)

@Ankry: Dzień dobry, Na ukraińskich wikiźródłach miałem różnice w rozpoznawaniu rosyjskiej litery ы w ukraińskim OCR. Ale teraz już jest poprawnie, nie mam uwag. Mahnka (dyskusja) 10:04, 27 cze 2021 (CEST)

Gadżet Extract text został przeniesiony do paska narzędziowego i nie przesłania już skanu. @Seboloidus:, @Sempai5:, @Odder: - zaznaczam Was jako mających wyłączony gadżet. Tommy J. (pisz) 13:30, 30 lip 2021 (CEST)

Okno edycji

Coś się zadziało z oknem edycji. Wczoraj jeszcze w ustawieniu horyzontalnym (skan nad polem edycyjnym) pole edycji było płynne, można było dowolnie przewijać bez przewijania strony i gubienia z oczu skanu. Dziś jakakolwiek próba manewrowania w nim powoduje przesuwanie całej strony. Da się coś z tym zrobić czy muszę edytować w pozycji wertykalnej? Tommy J. (pisz) 00:15, 25 cze 2021 (CEST)

Póki co poradziłem sobie za pomocą #wpTextbox1 {max-height:10em !important;}, chociaż pomniejszyło to wszystkie pola edycyjne, nawet poza przestrzenią Strona. Tylko wydaje mi się chore żeby użytkownicy musieli się "ratować" przed takimi zmianami za pomocą JS i CSS. Niedługo podstony userów zamiast usprawniać pracę będą umożliwiać pracę. Tommy J. (pisz) 03:17, 25 cze 2021 (CEST)

Nie wiem, czy pomogę, bo używam monobooka i skanu po prawej. W każdym razie powyłączałem sobie atrybut flex, który koszmarnie rozciągał pole edycji. Zerknij na mój CSS, może to coś pomoże. A wyżej w tym pliku mam porobione ustawienia styli dla konkretnych namespace. Ankry (dyskusja) 13:05, 25 cze 2021 (CEST)

@Tommy Jantarek: Przepraszam za pisanie po angielsku. Any chance you could provide a more detailed description of this issue—in English for us Polish-deficients :)—including what it used to look like that has now changed and the way the change creates a problem for you. A screenshot is often useful for others to understand. Details of your web browser and version number, the MediaWiki skin you're using if different from the default (Vector), and any user scripts or styles that could conceivably affect the issue. Xover (dyskusja) 08:41, 28 cze 2021 (CEST)

Zaznaczę, że aktualnie dyskutujemy na ten temat tutaj, jeśli ktoś chciałby coś dodać. Ankry (dyskusja) 10:28, 28 cze 2021 (CEST)

Spis treści w przestrzeni indeks

Czy dałoby się spis treści w przestrzeni Index umiejscowić jakoś bardziej po prawej stronie? Np. tu zachodzi on prawie na informacje o rezerwacji i skan okładki. Przesunięcie go w prawy górny róg ekranu byłoby zbyt radykalne, ale można byłoby go zostawić pod informacją o statusie indeksu, ale cały blok dociągnąć do prawej strony ekranu, może nawet trochę zmniejszyć szerokość, żeby nie zajmował tak dużej przestrzeni. Tommy J. (pisz) 01:18, 29 cze 2021 (CEST)

P.S. Teraz popatrzyłem na inny indeks gdzie inaczej są ułożone strony. Nie wiem czy nie lepiej byłoby jednak spis treści przesunąć całkiem na lewą stronę, ale tak, żeby wszedł pod skan i informacje o rezerwacji. Tommy J. (pisz) 04:46, 29 cze 2021 (CEST)

Trudno o uniwersalne rozwiązanie. Ale można też próbować formatować spis treści w samym indeksie. Ankry (dyskusja) 13:44, 2 lip 2021 (CEST)

Trochę zmodyfikowałem Szablon:Index, może nic ważnego nie popsułem. Ankry (dyskusja) 14:23, 2 lip 2021 (CEST)

@Ankry: nie popsułeś, to ja nie za bardzo przemyślałem zanim zgłosiłem sprawę. Nie pomyślałem natomiast o dużych indeksach z np. tysiącem stron. Mianowicie pole spisu jest ustawione pod polem statusu dodatkowego. Żeby to dobrze wyglądało na każdym indeksie, to albo trzeba byłoby przenieść cały obszar "spis treści" razem z jego polem tekstowym na lewą stronę, czyli musiałby wyjść przed tabelę w szablonie indeks i trafić tuż pod div z rezerwacją. Ale wtedy musiałby mieć dokładnie określone parametry szerokości żeby nie wchodził na tabelę i nie burzył widoku. Druga opcja, chyba lepsza i mniej pracy, zostawić obszar spisu treści tu gdzie jest, ale jego pole tekstowe wycentrować całym blokiem, czyli żeby nie centrował tekstu, ale inkludowaną do pola tekstowego stronę, tak żeby strona była ładowana na osi pionowej wyświetlanych wyżej weryfikowanych stron. Przepraszam za zamieszanie z góry. Tommy J. (pisz) 15:41, 2 lip 2021 (CEST)

Spis treści też może mieć kilkaset pozycji albo może go nie być. Dlatego trudno o uniwersalne rozwiązanie. Ankry (dyskusja) 15:47, 2 lip 2021 (CEST)

@Ankry: w czym innym jest problem. Zobacz na podgląd tworzonego indeksu, Spis treści wywala do lewego marginesu, ponieważ jest wpisany pod tabelą. Ostatnią pozycją tabeli jest wiersz z CSS. Natomiast jak blok spisu treści wstawić na koniec tabeli tuż pod blokiem CSS w postaci |- {{#if:{{{Spis treści<includeonly>|</includeonly>}}}| {{!}}valign=top{{!}}<p> Spis treści:</p> {{!}} <!-- -->{{{Spis treści}}} }} |} to sam spis jest elegancko centrowany tuż pod informacjami o indeksie. Rzuć okiem. Tommy J. (pisz) 17:23, 2 lip 2021 (CEST)

Z tego co pamiętam, pierwotną ideą było, żeby przy dużej liczbie stron umieścić spis treści pod okładką. Ale nie zawsze się tam zmieści. Być może warto popracować nad tym, by w ogóle zrezygnować z tabeli w indeksie. Ankry (dyskusja) 17:53, 2 lip 2021 (CEST)

Nie mieścił się bo miał ustawioną szerokość na 550px, a jeśli miałby być pod okładką jego maksymalna szerokość powinna być 250px. Zobacz teraz, mam wypróbowane dwie wersje widoku
P.S. W drugiej wersji blok spisu wprowadziłem do diva zawierającego ilustrację i rezerwację, jeszcze przed tabelą Tommy J. (pisz) 19:34, 2 lip 2021 (CEST)

@Ankry:, @Zdzislaw: przepraszam że truję głowę, ale moglibyście zajrzeć na moją propozycję przedstawioną dotyczącą ustawienia obszaru spisu treści w indeksie? Jak uważacie? Czy nie byłoby tak lepiej? Tommy J. (pisz) 14:43, 8 lip 2021 (CEST)

@Tommy Jantarek: nie wiem i myślę, że nawet we dwójke ze Zdzislawem nie stanowimy właściwego forum, dla kierowania takich zapytań. Trzeba rozważyć, jak ro się zachowa w takich i podobnych indeksach. Może jakiś sposób wariantowego definiowania układu indeksu? Sam nie wiem... Ktoś gdzieś kiedyś sugerował, by spis treści dawać z prawej u góry; to też jest jakiś pomysł. Ankry (dyskusja) 15:29, 8 lip 2021 (CEST)

@Ankry: zwróciłem się do Was dlatego, że ostatnio Wy najwięcej w tym szablonie pracowaliście, więc go dobrze znacie. Poza tym nie widzę przeciwwskazań żeby ktoś jeszcze wyraził swoje zdanie, to Skryptorium, nie prywatny kanał komunikacji. I dlatego przedłożyłem temat tu a nie na maila czy stronę dyskusji.
Przy dużych wielostronicowych indeksach wydaje mi się, że najlepiej byłoby umiejscowić spis przed tabelą i całkiem po lewej (czyli drugi wariant w moim brudnopisie), ale przy zadeklarowaniu szerokości nie więcej niż 250px, żeby nie nadchodziło na resztę strony i mieściło się pod okładką. Oczywiście dłuższe tytuły będą się łamały podobnie jak to jest w enWS. Co do wskazanych przez Ciebie indeksów, one są już podzielone w pagelist, więc wstawianie stron spisu to dublowanie treści i raczej nikt tego nie będzie stosował, ale jeśli, to i tak spis po lewej nic nie przeszkadza. Pod spodem, w tabeli (pierwszy wariant brudnopisu) raczej bardzo mocno wydłuży stronę indeksu. Spis po prawej też jest pomysłem, mają tak na enWS, ale nie sadzę żeby to dobrze wyglądało, wtedy trzebaby i tak coś przerzucić pod okładkę (np. pagelist jak w enWS) i w sumie przebudować cały szablon. Wariantowe zdefiniowanie też wymaga całkowitej przebudowy i sprawdzenia jak się to zachowa w różnych sytuacjach. Nie mam na celu i nie śmiałem angażować Was w aż tak pracochłonne zadanie, skoro to nie jest konieczne. Dlatego proponuję dwa najprostsze rozwiązania. Tommy J. (pisz) 16:00, 8 lip 2021 (CEST)

Podałem te indeksy jako przykłady, nie jako sugestie dodawania w nich spisu. W starych indeksach raczej go nie dodajemy, ale nowo tworzone mogą mieć różny charakter, także podobny do tych. Co do zmiany, uważam, że jeśli nikt nie oponuje (a nie widzę), to można zastosować metodę faktów dokonanych: jeśli ktoś zasadnie zaprotestuje, zawsze taką zmianę można cofnąć. Nie ingeruje ona głęboko w żadne zasoby. Generalną ideą wprowadzenia spisu treści w indeksie miało być automatyczne generowanie stron w przestrzeni głównej na jego podstawie. Ankry (dyskusja) 15:05, 9 lip 2021 (CEST)

e -> é

Zauważyłem, że przy ręcznej zamianie tych liter, czasami pozostawiamy je obie razem w tekście. Jako, że nie ma w języku polskim wyrazów kończących się na -eéj, stworzyłem filtr wykrywający takie przypadki z odpowiednim komunikatem. Proszę o sygnał, gdyby sprawiał problemy. Ankry (dyskusja) 21:38, 4 lip 2021 (CEST)

Brakujące grafiki

Mam do dodania grafiki w indeksie, na stronach, i na Commons jest plik z usuniętymi grafikami, natomiast nie mogę dodać pliku z grafikami bo Commons twierdzi że plik jest identyczny, i faktycznie po wejściu na pdf grafiki są widoczne. Ma ktoś jakiś pomysł co jest nie tak, i jak to naprawić? Joanna Le (dyskusja) 11:08, 12 lip 2021 (CEST)

• @Joanna Le: Cześć. Spróbuj może dodać na Commons lekko zmieniony plik, np. bez znaku wodnego. Seboloidus (dyskusja) 13:25, 12 lip 2021 (CEST)

@Seboloidus: pięknie dziękuję :) Zadziałało Joanna Le (dyskusja) 13:40, 12 lip 2021 (CEST)

score

Jest szansa, że będziemy mieć pełne score w przyszłym tygodniu: phab:T257066#7206899. Trzeba będzie posprawdzać, czy wszystko działa. Ankry (dyskusja) 21:55, 12 lip 2021 (CEST)

• Wydaje się, że będzie działać. Ankry (dyskusja) 22:43, 12 lip 2021 (CEST)
• Od wczoraj plwikisource jest jedną z "produkcyjnych" wiki, na których ponownie działa score, na razie w formie testu. Niestety, są pewne problemy: "bezpieczny" tryb, w którym zostało uruchomione nie obsługuje niektórych funkcjonalności. Stare partytury się renderują, ale przez to nie zawsze możliwa jest ich modyfikacja; działa też wolniej, więc łatwiej natrafić na problemy z renderowaniem dużych stron, zawierających wiele partytur. Developerzy proszą o zgłaszanie ewentualnych innych problemów. Ankry (dyskusja) 09:09, 23 lip 2021 (CEST)

problemy

Znalezione/zgłoszone problemy ze Score w obecnej wersji:

• przy renderowaniu stron (oprócz timeoutu przy renderowaniu dużych stron) można spotkać również Krytyczny wyjątek typu „Shellbox\ShellboxError”, często natychmiast przy próbie zapisania / odświeżenia strony. Sugeruję próbować kilka razy. Problem zgłoszony phab:T287288; mam nadzieję, że wynika z dużego obciążenia serwerów bezpośrednio po włączenie Score i z czasem zaniknie.
• po przejściu na lilypond 2.22.0 zmieniła się nieco składnia: fermaty na pauzach uzyskujemy za pomocą \fermata, a nie \fermataMarkup, jak dotychczas. Co znalazłem, poprawiłem.
• prawdopodobnie w związku z tym, że lilypond pracuje na serwerach w trybie "bezpiecznym" (safe mode) nie działają niektóre komendy (phab:T287165). U nas wykorzystywana była komenda \paper { #(set-paper-size ...) } do tworzenia partytur o szerokości większej niż 200mm. Zablokowałem taką możliwość w Moduł:Mscore. W lilypond 2.18 te komendy zgłaszały błąd; teraz są po prostu ignorowane.
• prawdopodobnie z tego samego powodu nie działa łączenie nutek pomiędzy pięcioliniami za pomocą komendy \crossStaff.

Gdybyście odkryli coś więcej, proszę o dopisywanie do listy. Będziemy zgłaszać. Ankry (dyskusja) 21:49, 24 lip 2021 (CEST)

Szablon Autorinfo

Czy ten szablon obecnie pobiera dane z Wikidata? Od jakiegoś czasu zauważyłem że nie uzupełnia grafik i dat. Dziś utworzyłem Autor:Leon Rogalski i po wielu godzinach i odświeżeniu pamięci podręcznej nadal dane są nieuzupełnione. Tommy J. (pisz) 13:02, 31 lip 2021 (CEST)

• @Tommy Jantarek: Parametry, które są pobierane automatycznie z Wikidanych należy usunąć z szablonu. Gdy zostawimy je puste dane się nie pobiorą. Himiltruda (dyskusja) 01:12, 1 sie 2021 (CEST)

  @Himiltruda: teraz zrozumiałem dopiero jak to działa. Dziękuję :) Tommy J. (pisz) 01:27, 1 sie 2021 (CEST)

• @Tommy Jantarek: To ja jeszcze zwrócę, ze swojej strony, uwagę, że w przypadku osób urodzonych lub zmarłych w zakresie czasoprzestrzennym obowiązywania kalendarza juliańskiego, nasi koledzy ze wschodu dość uparcie usuwają daty gregoriańskie zastępując je juliańskimi. A nasze narzędzia nie konwertuja kalendarzy, więc możemy otrzymać niekoniecznie pożądany rezultat. Ja zwykle w takich sytuacjach zostawiam datę lokalnie w szablonie. W Wilnie w 1806 były daty juliańskie. Ankry (dyskusja) 22:43, 1 sie 2021 (CEST)

  @Ankry: to wychodzi że na pl wikipedii biogram również ma źle daty urodzin i śmierci Rogulskiego? Czyli powinienem to przeliczyć i popoprawiać u nas i na plwiki :( Tommy J. (pisz) 22:56, 1 sie 2021 (CEST)

  Jest gorzej niż myślałem akurat w przypadku Rogulskiego, bo daty są wzięte z kosmosu, bez podania źródła, plwiki i wikidata mają skopiowane daty z ruwiki, to że daty są wg juliańskiego wstawiono na wikidata też ot tak sobie. Więc jedyne co by się tu zgadzało to rok śmierci, bo nawet roku urodzenia nie byłbym pewien. Tommy J. (pisz) 23:11, 1 sie 2021 (CEST)

Margines górny w przestrzeni Strona

Cześć. Czy mógłby ktoś wytłumaczyć, czemu margines górny w przestrzeni Strona raz jest większy, a raz mniejszy? Na przykładzie np. tego indeksu, gdzie formatowanie pierwszych stron rozdziałów jest identyczne, a nagłówki puste, widać ten problem z marginesami. Ilustracja tematu: https://i.imgur.com/0pyIQ8r.png Sprawdzałem na różnych przeglądarkach. Ponadto wydaje mi się, że wcześniej nie było z tym problemu. Seboloidus (dyskusja) 20:27, 8 sie 2021 (CEST)

Zgaduję, że coś się zmieniło z domyślnym ostylowaniem, a w keszu posostały stare wersje. Po action=purge wszystkie mają identyczny margines. Ankry (dyskusja) 19:29, 12 sie 2021 (CEST)

@Ankry: Dzięki! Faktycznie, po wyczyszczeniu wyświetla dobrze. Seboloidus (dyskusja) 21:16, 12 sie 2021 (CEST)

Kasowanie ilustracji ze skanu książki

Dzień dobry! Jak w Windowsie lub Linuksie wyedytować pdf i nanieść białe prostokąty w miejscach ilustracji żeby móc opracowywać tekst PD z ilustratorem, który zmarł w 1979 roku? Umiem kasować całe strony, ale nie umiem edytować fragmentów stron. Ewentualnie może ktoś mógłby wyświadczyć mi tę przysługę i wymazać ilustracje z pdf. Z góry dziękuję za wszelką pomoc. Mahnka (dyskusja) 11:32, 22 sie 2021 (CEST)

@Mahnka: Dzień dobry! A dużo tych stron do wyedytowania? Zrobić to można np. w gimp-ie (ale otrzyma się pojedyncze strony pdf-owe), które trzeba scalić. Jeśli niewiele, to myślę, że podołam (zawsze to lepiej niż czekać 29 lat...) Draco flavus (dyskusja) 18:17, 22 sie 2021 (CEST)

• Mahnka, daj linka do pdf-u, i powiedz co trzeba wyciąć. To szybka robota :) Wieralee (dyskusja) 18:37, 22 sie 2021 (CEST)
• @Draco flavus, @Wieralee: Dziękuję za ofertę, z pewnością jeszcze kiedyś skorzystam, tymczasem jednak okazało się, że Leh Palych zajął się tą sprawą. Chodziło o wpasowanie się w Dzień Niepodległości Ukrainy i ten indeks uk:Індекс:Коковський Франц. За Україну (збірка) (Львів, 1934).djvu Mahnka (dyskusja) 23:46, 23 sie 2021 (CEST)

Strona:Józef Ignacy Kraszewski - Sto Djabłów T. 1.djvu/5

Czy to jest naturalne, że ta strona jest żółta, a edytowała ją tylko jedna osoba? Taka sytuacja nie powinna być jakoś programowo zablokowana?

• Dzień dobry. Dziękujemy za zwrócenie uwagi. W niektórych, specyficznych typach tekstu dopuszcza się wyjątkowo, aby tekst od razu był żółty. Tutaj oczywiście tekst jest typowy, więc nie można pominąć 3-etapowej jego weryfikacji. Najprawdopodobniej zatem jest to pomyłka edytora. Stronę przejrzałem i skorygowałem — jest już pełnoprawnie żółta. Seboloidus (dyskusja) 14:47, 30 sie 2021 (CEST)

{CONTRIBUTORS} w naszych ebookach

Tak nieśmiało kilka miesięcy temu wspomniałem tutaj, że "na końcu generowanego pliku książki (epub, PDF) jest zapis W tworzeniu niniejszej książki uczestniczyli następujący wolontariusze: i że od pewnego czasu pojawiło się tam, oprócz wikiskrybów mających oczywisty wkład w daną książkę, ok. 7 - 8 nicków osób spoza naszych WŹ, które na pewno tej książki nie tworzyły". Od tamtego czasu tych osób jest już 11, a końcowa strona np. Salonu baronowej Wiery w epub-ie wygląda tak: https://i.imgur.com/ylnl7yk.jpg
Czy ktoś wie, czemu tak się dzieje? Co to za nicki? Może da się to naprawić? Seboloidus (dyskusja) 01:50, 10 wrz 2021 (CEST)

• Wydaje się, że mogą to być autorzy, którzy mieli wkład związany z logo Wikiźródeł albo którzy dodawali wikidane?--Rosewood (dyskusja) 09:32, 11 wrz 2021 (CEST)
• Też na to zwróciłam uwagę... To mogą być też twórcy mechanizmów pobierania epubów lub twórcy szablonów... do wyjaśnienia... W każdym bądź razie byłabym za tym, żeby pojawiały się tam tylko dane edytorów Wikiźródeł. Wieralee (dyskusja) 10:37, 11 wrz 2021 (CEST)
• Wydaje mi się, że nie ma ku temu podstaw (bo niby dlaczego twórcy szablonów mają mieć mniejszy wkład niż ktoś kto uwierzytelnił jedną stronę?) ani też technicznych możliwości (nie my tworzymy kod generatora e-booków; co najwyżej ktoś od nas może napisać własny generator). Ankry (dyskusja) 14:37, 13 wrz 2021 (CEST)
  • @Seboloidus, @Rosewood, @Ankry: @Wieralee: Przyglądałem się sprawie. Są to wolontariusze, którzy tworzyli grafiki: , czy , które to są częściami naszych szablonów PD (ta ostatnia {{Przypiswiki}}). Niestety, mechanizm tworzenia epubów nie analizuje treści naszych stron tekstów i jako {CONTRIBUTORS} wyszukuje wszystkich edytorów zaangażowanych we wszystkie strony i pliki wchodząc w skład utworu zwracanego przez parser (tak [36] widzi eksporter stronę utworu). Wydaje mi się, że nie ma szans na wydzielanie tego co ma być sprawdzane, a co nie - zbytnia komplikacja, trudnośc w uzasadnieniu takiej zmiany. Być może rozwiązaniem byłoby zrobienie lokalnych kopii grafik "okołotekstowych" (wtedy dopisywany byłby tylko autor lokalnych grafik :)... lub po prostu pomijanie ich w wysyłaniu do eksportu, wtedy w ebooku byłaby tylko treść licencji, bez rysunków) (to da się zrobić lokalnie)....Zdzislaw (dyskusja) 16:18, 13 wrz 2021 (CEST)
    • Dziękuję za wyjaśnienie. Do tej pory patrzyłem na zapis W tworzeniu niniejszej książki... z węższej perspektywy. Przy szerszym spojrzeniu — twórcy grafik, tak jak i one same, mają prawo tam być. Seboloidus (dyskusja) 16:46, 13 wrz 2021 (CEST)

Automatyzacja a skrypty LUA

@Seboloidus zwrócił dziś uwagę na błąd przy wyświetlaniu okładek na stronie głównej. Okazało się, że problemem było użycie magic word w nazwie pliku i ta edycja naprawiła problem. Jednak widać tu generalny konflikt użycia (niesubstytuowanych) magic words z ekstrakcją informacji przy użyciu LUA na inne strony. W tej chwili rzecz dotyczy okładek, być może także kolekcji, jednak w miarę rozwoju technikaliów, także innych rzeczy (przenoszenie danych do Wikidata?). W tym przypadku rzecz dotyczyła kodu:

		if not ( okladka_link[nr_okl] == '' ) then
			title = mw.title.new( 'File:' .. okladka_link[nr_okl] )
			if title.file.width < title.file.height then
			...

gdzie w efekcie pojawiło się odwołanie do pliku File:PL Buffalo Bill -34- {{BASEPAGENAME}}.pdf na stronie głównej i sprawdzanie jego rozmiaru przed sparsowaniem magic word. Stąd moje pytanie do zwolenników słów magicznych (@Draco flavus, @Electron, @Wieralee:), a także odnośnie możliwości technicznych do @Zdzislawa o to, jak rozwiązać ten problem. Propozycje:

1. możemy ignorować takie odwołania w kodzie LUA; w efekcie takie okładki nie pojawią się ani na głównej ani w kolekcjach
2. możemy dokonywać substytucji takich konstrukcji w {{Dane tekstu}} botem (w tej chwili nie mam koncepcji, jak, ale pewnie się da)
3. możemy dokonywać substytucji takich słówek w skrypcie i tu pytanie do Zdzislawa: czy się da i czy to nie będzie kosztowne?); może to spowolnić skrypt lub przez swoją kosztowność znacznie ograniczyć maksymalny rozmiar kolekcji
4. inne pomysły?

Ankry (dyskusja) 15:01, 13 wrz 2021 (CEST)

W skrócie: chodzi o to, że wikikod wywołania szablonu DT ze strony w przestrzeni głównej może być efektywnie wykorzystywany także na innych stronach i w efekcie wartość użytych tam magic words może być inna, niż autor się spodziewa. Ankry (dyskusja) 15:05, 13 wrz 2021 (CEST)

Lua generalnie czyta kod strony. Moim zdaniem, użycie w tym miejscu {{BASEPAGENAME}} nic konkretnego nie niesie (żadnej wartości dodanej), dlatego w nazwie pliku (niezmiennej przecież) nie stosował bym tego. Jeśli się takie coś się fajnie kopiuje (ctrl-c, ctrl-v) przy tworzeniu kolejnych indeksów, to rozwiązaniem jest substytucja {{subst:BASEPAGENAME}} Draco flavus (dyskusja) 15:25, 13 wrz 2021 (CEST)

@Electron: problem (przypuszczam) dotyczy serii Bill-a (tylko?) i prosto jest go naprawić (botem lub ręcznie) wstawiając w tych miejscach subst: Draco flavus (dyskusja) 15:28, 13 wrz 2021 (CEST)

• @Ankry: zabezpieczyłem moduł w taki sposób, że dla tego typu opisu plików okładki, na głównej pomija je podczas losowania, w kolekcjach zaś podmienia na okładkę standardową (nie da się tego sparsować w prosty sposób, trzeba by parsować lokalnie, tworząc mikroparser, a to byłoby dosyć kosztowne). Zdzislaw (dyskusja) 12:29, 19 wrz 2021 (CEST)

Wikiźródła:Wikiprojekt Proofread skrócony

Zauważyłem dzisiaj, że na tej stronie mamy:

Rozmiar dołączonych elementów po ekspansji	2 027 112/2 097 152 bajty

Co oznacza, że po dodaniu jeszcze 50-70 indeksów odbijemy się od ściany i strona przestanie się renderować.

Czy i co z tym robimy i w jakim kierunku idziemy. Możliwości widzę kilka:

1. . rezygnujemy z tej strony
2. . dokonujemy pewnej selekcji i ograniczamy stronę, eliminując część pozycji
3. . zmniejszamy ilość informacji zamieszczanej per indeks
4. . migrujemy stronę na serwer zewnętrzny, poza wiki
5. . inne pomysły?

Ankry (dyskusja) 09:34, 15 wrz 2021 (CEST)

Ad. 5. Nie wiem czy jest w tym co napiszę jakiś sens. Czy coś da takie zbudowanie tej strony żeby pozycje wprowadzać w formie tekstowej do strony dyskusji, a strona główna ładowałaby to w formie tabeli (coś na styl stron Kolekcji)? Łatwiej byłoby wprowadzać czy kasować pozycje dla użytkowników, wystarczyłoby wprowadzić link do indeksu, a na głównej stronie projektu ładowałaby się tabela czerpiąca informacje z zalinkowanych pozycji. Tommy J. (pisz) 13:01, 15 wrz 2021 (CEST)

@Tommy Jantarek: Problemem jest właśnie ilość danych wstawianych poprzez szablony (transkludowanych). Wszystko jedno, skąd i jak zostaną one pobrane. Pomóc może np. rezygnacja z jakiejś kolumny, rezygnacja z jakichś linków lub skrócenie nazw linkowanych stron. Niemniej, ze względu na limity MediaWiki i tak przy pewnej liczbie wierszy w tabelce, kiedyś dotrzemy do ściany. Ankry (dyskusja) 16:05, 15 wrz 2021 (CEST)

ad 1. Ja przyznam nie korzystam z tej strony, wręcz wydaje mi się zbędną komplikacją (jeszcze tu wejść i dodać lub usunąć wiersz w tabeli). Ale dlatego być może moje zdanie nie ma tu nic specjalnie do rzeczy??? Draco flavus (dyskusja) 14:05, 15 wrz 2021 (CEST)

• Utworzyłam tę stronę, żeby móc łatwo znaleźć indeksy do ukończenia, czyli takie, które mają niewiele stron. Wystarczy tam ustawić sortowanie w tabeli wg ilości stron i wszystko widać jak na widelcu. Na stronie pełnego Wikiprojektu Proofread czegoś takiego nie da się zrobić, bo trzeba sortować każdą tabelkę z osobna, a że są one tworzone osobno nawet dla dwóch tytułów, więc ich funkcjonalność w sortowaniu jest bardzo bardzo mała... Ale skoro ta strona jest źródłem problemu, to można ją usunąć, tym bardziej, że nie jest niezbędna. Wieralee (dyskusja) 21:33, 15 wrz 2021 (CEST)
  • Póki działa, nikomu specjalnie nie przeszkadza. Pytanie jest raczej o jej przyszłość: czy chcemy z niej zrezygnować, jakoś ograniczyć, czy zmigrować do zewnętrznego narzędzia? Funkcjonalne, używane narzędzie powinno zostać. A ponieważ ja z n iej nie korzystam, to nie wiem, co jest ważne, a co nie i dla jak szerokiego grona? Ankry (dyskusja) 21:41, 15 wrz 2021 (CEST)
• Dla mnie strona jest niezwykle przydatna i korzystam z niej bardzo często. Dokładnie z tych powodów, o których pisze wyżej Wieralee, czyli możliwości sortowania wszystkich uruchomionych indeksów. Najczęściej łączę sortowanie "ilość stron" + "stan". Całkowicie zbędna jest kolumna "Uwagi", właściwie bez kolumn "Autor" i "Start" też mogłoby się obyć. Himiltruda (dyskusja) 23:47, 15 wrz 2021 (CEST)
• Ze względu na sortowanie zostawiłabym jeszcze "start", ale "uwagi" i "autor" jak najbardziej według mnie można usunąć. Można też wydzielić na osobną stronę najstarsze indeksy np. do 2012 roku włącznie, albo dalej. Joanna Le (dyskusja) 21:01, 22 wrz 2021 (CEST)

   Za podobnie, pozostawiłbym "autor", a pomysł podzielenia na dwie strony wg mnie bardzo sensowny Tommy J. (pisz) 21:12, 22 wrz 2021 (CEST)

  zgadzam się z @Tommy Jantarek: - autora bym zostawił (niektórzy "specjalizują się" w konkretnych autorach, tytuł też mówi mało...), osoby korzystające ze strony interesuje raczej wielkość indeksu niż data dodania. Dlatego proponuję usunąć datę dodania i uwagi. I dziękuję @Ankry: za aktywny monitoring ograniczeń. O liczbie nieskończonych indeksów wypowiedziałem się niedawno, przyjąłem argumenty i nie będę już podnosił tego tematu. Bonvol (dyskusja) 22:02, 22 wrz 2021 (CEST)

Utworzyłam roboczo strony z podziałem Indeksy do 2012 roku [37] i od 2013 [38], ta druga jako właściwa strona Wikiźródła:Wikiprojekt Proofread skrócony z linkiem do tej pierwszej. Gdyby do tego usunąć "uwagi" i "start" to trochę miejsca się zrobi. Do tego jeszcze kilka akcji zazieleniania :) i przepełnienie nie powinno być problemem. A może ktoś jeszcze ma jakieś pomysły i uwagi. Joanna Le (dyskusja) 09:16, 23 wrz 2021 (CEST)

@Joanna Le: 2013 i 2014 też bym przerzucił do starszych. Tommy J. (pisz) 15:31, 23 wrz 2021 (CEST)

"Start" bym jednak zostawił, jest możliwość wyszukania indeksu wg daty wprowadzenia.
A to gdyby zbudować tę stronę na zasadzie strony specjalnej (bardziej funkcjonalnej niż Spis stron indeksów), stronę która przeszukiwałaby kategorie indeksów wskazane przez użytkownika i wg kryteriów jakie użytkownik żąda, czyli sort wg statusu, daty dodania, ilości stron, plus wyświetlałaby na stronie wskazaną ilość wyników, np. 50. Coś na zasadzie petscan. Czy byłoby to możliwe to wykonania? Tommy J. (pisz) 15:23, 23 wrz 2021 (CEST)

• Proponowałbym zamienić obecne ikonki w kolumnie "Stan" na zapis tekstowy 0%, 25%, 50%,... Pozwoli to odchudzić limit o ~7%, co da bufor dla kolejnych 150 indeksów. Zdzislaw (dyskusja) 19:56, 23 wrz 2021 (CEST)

Dodałbym pod troskę też stronę Wikiźródła:Ukończone projekty proofread, na tę chwilę ponad 1,9M. Również trzebaby pomyśleć nad innym sposobem przedstawienia wyników Tommy J. (pisz) 15:00, 2 paź 2021 (CEST)

• W przypadku tej strony sprawa jest prosta i załatwiona przez {{Iwtrans}}. Wadą jest jedynie to, że starsze lata nie będą się rozwijac w spisie trści. Ale to chyba nie problem. Ankry (dyskusja) 16:20, 2 paź 2021 (CEST)

Odchudziłam stronę o najstarsze indeksy, i utworzyłam podstronę z indeksami sprzed 2015 roku. Teraz przydałoby się żeby ktoś "kto się na tym zna" :-) usunął kolumnę "uwagi" (według dyskusji nikomu nie jest potrzebna) i zmienił w kolumnie "Stan" ikonki na zapis procentowy. Wtedy już na długo nie było by problemu z tą stroną. Joanna Le (dyskusja) 13:19, 6 paź 2021 (CEST)

Przykład w szablonie Grafika z podpisem

W ostatnim z przykładów szablonu {{Grafika z podpisem}} pt. Obrazek z dodatkową ramką:

{{Grafika z podpisem
 | file     = The Kinematics of Machinery Fig 1.png
 | width    = 200px
 | align    = center
 | cap      = Rys. 2.
 | style    = width:220px
 | image style = width:220px;padding-top:10px;padding-bottom:10px;border:2px dotted red
}}

wydaje mi się, że jest niepotrzebna linia | style = width:220px, skoro wcześniej jest już podany parametr width. W kodzie strony jest on zduplikowany: <div style="margin: 1.0em auto 1.0em auto;text-align:center;padding:0 0.5em 0 0.5em;background-color:transparent;width:200px; width:220px">. Proszę o zweryfikowanie mojego spostrzeżenia. Seboloidus (dyskusja) 13:48, 27 wrz 2021 (CEST)

| style = width:220px jest niepotrzebne, lecz wtedy powinno być | width = 220px. Bez zmiany należałoby tutaj usunąć linię | width = 200px. Zdzislaw (dyskusja) 22:24, 27 wrz 2021 (CEST)

Szablon Index

Mam prośbę do administratorów bo sam nie mam jak tego sprawdzić gdyż pagelist działa tylko w przestrzeni Indeks, a nie wiem jak przetestować stronę w tej przestrzeni bez ładowania szablonu Indeks. Chodzi mi o to że obecnie tag pagelist ładuje automatycznie strony tylko jeśli nazwa strony indeksowej jest identyczna z podanym źródłem, czyli dla pliku na commons File:nazwa.djvu strona indeksowa Indeks:nazwa.djvu. Tag ten nie działa przy jakiekolwiek różnicy w nazwach. Wydaje mi się, że gdyby w {{Index}} w miejscu <span class="plainlinks">'''[{{fullurl:{{FULLPAGENAMEE}}|action=purge}} Strony]</span> zamiast FULLPAGENAMEE wstawić odnośnik do podanej wartości {{{Źródło}}} tag pagelist zadziałałby bez względu na nazwę indeksu. Można to jakoś sprawdzić i ewentualnie poprawić? Tommy J. (pisz) 17:18, 28 wrz 2021 (CEST)

Niestety, {{Index}} zawiera konfigurację jedynie sposobu pokazywania zawartości indeksu. Funkcjonalność, o której piszesz i obsługa tagu ‎<pagelist /> zaszyta jest w rozszerzeniu proofread i nie posiada możliwości odmiennej konfiguracji. Zdzislaw (dyskusja) 01:33, 30 wrz 2021 (CEST)

...Dlatego przy tego typu różnicach (wynikających np. ze zmiany nazwy pliku) jedynym rozwiązaniem jest zmiana nazwy indeksu. Ankry (dyskusja) 16:13, 2 paź 2021 (CEST)

Coolest Tool Award 2021: Call for nominations

The third edition of the m:Coolest Tool Award is looking for nominations!

Tools play an essential role for the Wikimedia projects, and so do the many volunteer developers who experiment with new ideas and develop and maintain local and global solutions to support the Wikimedia communities. The Coolest Tool Award aims to recognize and celebrate the coolest tools in a variety of categories.

The awarded projects will be announced and showcased in a virtual ceremony in December. Deadline to submit nominations is October 27. More information: m:Coolest Tool Award. Thanks for your recommendations! -- SSethi (WMF) for the 2021 Coolest Tool Academy team 07:57, 19 paź 2021 (CEST)

Narzędzie powiększania

Cześć! Czy Wam też powiększanie skanów działa dziwnie? U mnie pojawiły się dwa zestawy do powiększania — ilustracja. To stare po lewej nie działa wcale, a to nowe z prawej działa z dużo większym skokiem powiększenia niż wcześniejsze. Poza tym powiększenie przez scrollowanie działa cały czas (wcześniej można też było przewijać stronę trzymając kursor nad okienkiem skanu) i jest to jedyna opcja ustawienia odpowiadającego mi powiększenia. Tudzież nie mogę podjechać maksymalnie skanem do brzegu okienka jak dawniej — w tej chwili każda z krawędzi obrazka skanu nie może wyjechać za połowę szerokości okienka. Seboloidus (dyskusja) 22:52, 18 lis 2021 (CET)

U mnie samo okno skanu działa dziwnie i denerwująco. Ilustracja skanu przy przesuwaniu skacze po całym oknie, zamiast się scrollować (przy edycji mobilnej). Poza tym po przesunięciu ilustracji trzeba wracać kursorem na pole edycji, ponieważ kursor znika, wcześniej pozostawał w miejscu edytowania. Tommy J. (pisz) 01:41, 19 lis 2021 (CET)

@Tommy Jantarek: Potwierdzam tę przypadłość z kursorem. Seboloidus (dyskusja) 01:52, 19 lis 2021 (CET)

Na stronie Strona:PL Nowodworski-Encyklopedia koscielna T.3 312.jpeg powiększanie/ przesuwanie nie działa w ogóle... Ani scrollowanie, ani te lupki po prawej stronie... Na innych na szczęście działa scrollowanie, (chociaż, tak jak pisali Poprzednicy, dziwnie) bo przeskok przy lupce jest zdecydowanie za duży... Sempai5 (dyskusja) 08:56, 19 lis 2021 (CET)

Dwa zestawy narzędzi do powiększania pojawiały się, gdy ktoś miał włączony gadżet Przeniesienie narzędzi z grupy Narzędzia proofread na podstawowy poziom rozszerzonego paska narzędzi. Wydaje mi się, że to poprawiłem. Natomiast czekamy na razie jeszcze na poprawkę działania przy wyłączonym toolbarze (zgłaszał Anwar2, bug phab:T296033). Myślę, ze gdy to naprawią, będzie się można zastanowić co dalej z tym zoomem. Ankry (dyskusja) 10:15, 19 lis 2021 (CET)

Jeszcze jedno: z większą precyzją można obecnie sterować powiększeniem za pomocą kółka myszy. Ankry (dyskusja) 10:19, 19 lis 2021 (CET)

zobaczę czy to coś da Anwar2 (dyskusja) 10:27, 19 lis 2021 (CET)

A czy ktoś wie jak wyłączyć to powiększanie/przesuwanie skanu? Korzystam z Wikiźródeł na dwóch maszynach: na windowsie do dzisiaj bez patrzenia w ekran gest dwoma palcami na touchpadzie przewijał stronę html w dół, a teraz jak po pierwszym przewinięciu kursor trafi w skan to się nagle zmniejsza skan. Męczące. Natomiast na ChromeOS z dotykowym ekranem nie można przewinąć strony w dół jak się trafi palcem w skan, bo skan zaczyna latać po ekranie. Równie męczące. Najlepiej jakby na pasku narzędzi była ikonka kłódki otwartej lub zamkniętej co powodowałoby włączanie i wyłączanie czułości skanu na ruchu myszy/gestów/dotyku ekranu. I żeby stan tej kłódki był zapamiętany między przeładowaniami strony. I żeby stan tej kłódki można było przełączać szybko skrótem klawiszowym. Gdzie/komu/jak można to zgłosić? Mahnka (dyskusja) 13:45, 19 lis 2021 (CET)

Myślę, że jedyna szansa by się coś zmieniło, to odpowiednio dużo i precyzyjnie zgłoszonych problemów na phabricatorze. Ja tego nie zgłoszę, bo problemu ani ekranu dotykowego nie mam. Ankry (dyskusja) 15:51, 19 lis 2021 (CET)

@Ankry: Dziękuję za odpowiedź. Nie wiem czy wystarczająco dobrze to opisałem i czy prawidłowo wypełniłem pola w zgłoszeniu ale oto jest phab:T296194. Mahnka (dyskusja) 16:10, 22 lis 2021 (CET)

witaj dzięki za ingerencję znowu działam Anwar2 (dyskusja) 18:59, 19 lis 2021 (CET)

• Na chwilę obecną (od 17:50) wróciła dawna funkcjonalność, pomijając brak ikonek do powiększania (przy włączonym gadżecie Przeniesienie narzędzi z grupy Narzędzia proofread na podstawowy poziom rozszerzonego paska narzędzi). Seboloidus (dyskusja) 17:58, 19 lis 2021 (CET)
  • Z powodu wielu problemów, przywrócono starą wersję MediaWiki. Jednak nowa, po jakichś poprawkach wróci w najbliższych tygodniach. W związku z tym, że jedną z bardziej istotnych zmian jest zmiana narzędzia do manipulowania obrazkami skanów, warto będzie zwrócić uwagę jak ono działa i czy nie za bardzo obciąża system (bo ze bardziej obciąża to już wiadomo). Ankry (dyskusja) 13:47, 21 lis 2021 (CET)

  Liczyłam, że te "najbliższe tygodnie" potrwają trochę dłużej :( cały dzień było ok, a teraz znowu ciężko się z tego korzysta... Sempai5 (dyskusja) 14:28, 22 lis 2021 (CET)

  Ja również, i nie widzę żadnych absolutnie zmian na plus, tylko utrudnienie edytowania. Zadziwiające że tak chętnie produkują rzeczy które przeszkadzają w edytowaniu, a ciężko się doprosić o rzeczy które użytkownikom są potrzebne. Zawsze jak widzę masowe logowania dziwnych nicków zaczynam się bać co tym razem schrzanią. Tommy J. (pisz) 18:17, 22 lis 2021 (CET)

  Przepisuję teraz indeks Zosia (złożony z plików PNG), a w nim wcale nie można powiększać skanów, stoją one nieruchomo jak wmurowane. Czasem zdarzy się taki kwiatek: https://i.imgur.com/OSaQF9M.png *** Z ciekawości zajrzałem na tę stronę, a tam nie wyświetla się skan (przy edycji już go widać). Inne przykłady: 1, 2. Ciekawe co dalej... czy te zmiany przed wprowadzeniem to w ogóle są testowane? (nieważne) Seboloidus (dyskusja) 23:22, 22 lis 2021 (CET), Seboloidus (dyskusja) 14:43, 23 lis 2021 (CET)

  Jak wspomniałem wcześniej: krawędź obrazka skanu nie może wyjechać za połowę szerokości okienka. W praktyce wygląda to w ten sposób, że przy długim obrazku jak np. ten w ogóle nie korzystam z tego okienka. Skan otwieram w osobnej przeglądarce plików djvu, która jest na połowie strony, always on top. Ponadto nie tylko nadal nie ma możliwości regulacji wielkości okienek, ale już nie działa moje (połowiczne) obejście tego problemu w common.css. 😐 Seboloidus (dyskusja) 14:18, 28 lis 2021 (CET)

Mam pytanie podobne jak wcześniej Mahnka. Czy jest jakaś możliwość wyłączenia tych ostatnich "udogodnień"? To już jest naprawdę irytujące, bo te innowacje przybierają postać karmienia trzody ptasim mleczkiem choć trzoda zwykle wolałaby paszę. Nie wiem do czego ma mi służyć opcja powiększania skanu czy przewracania go na wszystkie sposoby, skoro do tej pory nigdy nie miałem potrzeby korzystania z takich funkcji. Wiem natomiast że po wprowadzeniu udogodnień edytowanie stało się znacznie bardziej niewygodne, przewijając skan muszę za każdym razem wracać kursorem na pole edycji, które dziś dodatkowo zostało pomniejszone do połowy rozmiaru przy widoku horyzontalnym. Może jutro programiści stwierdzą że okienko edycji w ogóle nie jest mi potrzebne, skoro automat może wrzucić OCR. To zaczyna być naprawdę wkurzające choć ciśnie się żeby napisać ostrzej. Tommy J. (pisz) 00:06, 9 gru 2021 (CET)

Niestety nie wiem jak wyłączyć te "udogodnienia"... Natomiast zmuszony jestem dorzucić kolejną cegiełkę niezadowolenia. Na chwilę obecną przy powiększeniu strony w przeglądarce (np. 150%) ramka ze skanem zaczyna dusić ramkę z tekstem. Screen obrazujący tę sytuację: https://i.imgur.com/zK8W1eQ.png — sprawdziłem na 2 przeglądarkach oraz w trybie incognito, aby mieć pewność, że to nie wina moich ustawień. Można pokombinować i uruchamiać tryb edycji w już zadanym powiększeniu, ale... Seboloidus (dyskusja) 19:10, 9 gru 2021 (CET)

Jeszcze jeden przykład curiosum: gdy zwiększam szerokość przeglądarki (np. gdy mam ją otwartą na niepełnej szerokości ekranu, po czym ją maksymalizuję) to obrazek skanu zostaje w jakiejś ucinającej go ramce o poprzednio przyjętej szerokości. Screen sytuacji: https://i.imgur.com/kKi6Z0F.png Seboloidus (dyskusja) 19:31, 9 gru 2021 (CET)

• @Seboloidus: tego, co tu piszesz, najprawdopodobniej nie czyta nikt z osób wprowadzających takie zmiany. Trzeba napisać na Phabrykatorze. Wieralee (dyskusja) 19:41, 9 gru 2021 (CET)
  • @Wieralee: użytkownik nie musi znać angielskiego, użytkownik nie musi wiedzieć ani umieć poruszać się na Phabrycatorze. Strony natomiast użytkowe na Wikiźródłach mają służyć użytkownikowi dobrze, by edytowanie było dla niego wygodne, to raz, programowanie powinno służyć użytkownikom i ułatwiać im pracę a nie sprawiać im problemy i być twórczym wymysłem grupki osób, to dwa. Aż tak liczne grono wikiskrybow ciśnie się drzwiami i oknami? I kto tu jest dla kogo? Wikiskrybowie dla programistów czy oni dla nas? Tommy J. (pisz) 21:32, 9 gru 2021 (CET)
    • Podpisuję się obydwiema rękami pod tym, co napisałeś, Tommy. Tyle, że realia są jakie są... :// Wieralee (dyskusja) 21:42, 9 gru 2021 (CET)
    • @Tommy Jantarek: Jeśli znajdziesz sposób, by przekonać do tego decydentów z WMF, to jestem pewien, że wielu użytkowników by się ucieszyło. Niestety, udało się osiągnąć sukces puszczając Wikipedię na żywioł, to próbują stosować ten mechanizm także w dziadzinie rozwoju oprogramowania: "niech wolontariusze-programiści się tym zajmą, my wykreślimy jedynie ogólne kierunki rozwoju". A że programiści to też ludzie i popełniają błędy? No cóż, ktoś kiedyś poprawi, jeśli mu będzie to przeszkadzać. Niestety, z naukowych badań wynika, że jeśli programista nie jest jednocześnie specjalistą w dziedzinie, dla której tworzy program, to potrzeba wielu przybliżeń by uzyskać dobry produkt. A programistów-wikiskrybów zajmujących się rozwojem Mediawiki to raczej wielu nie ma (nawet nie jestem pewien, czy ich liczba jest dodatnia). A WMF cóż, ma inne preferencje niż stabilizowanie rozwoju oprogramowania: wolą wyrównywać różnice: kulturowe, genderowe, w dostępie do wiedzy i planować co będzie za 30 lat. Problem w tym, że jesteśmy od nich uzależnieni, bo sami dla siebie wygodnego interfejsu nie stworzymy. Zwłaszcza, że nasze oczekiwania też nie są całkiem jednolite. Ankry (dyskusja) 08:53, 10 gru 2021 (CET)
  • Dodam, że ta zmiana wygląda mi na celową. Ankry (dyskusja) 19:47, 9 gru 2021 (CET)
  • @Wieralee: Dziękuję za tę uwagę. Zdaję sobie z tego sprawę. Nie znam się na raportowaniu tamże błędów. I zastanawiam się, czy chcę w to wchodzić. Czasami zazdroszczę osobom, które tylko sobie edytują, niewiele wychylając się poza przestrzeń strona. Zapewne mają one spokój, który ja też pragnąłbym mieć. To tak na marginesie. Seboloidus (dyskusja) 20:19, 9 gru 2021 (CET) P.S. Może się okazać, że te zmiany przeszkadzają tylko trzem czy czterem osobom, a po czasie może nawet mniejszej liczbie użytkowników. A wtedy może być, parafrazując pewien dowcip, że dla dwóch osób to nie opłaca się programować.

rozmiar skanu

Dodałem do indeksu nowe pole: rozmiar skanu. Teoretycznie jest to szerokość do jakiej powinny być skalowane obrazki poszczególnych stron. Do wczoraj był to rozmiar rzeczywisty, jednak nie więcej niż 1024px, obecnie domyślna wartością jest 2x rozmiar rzeczywisty (skalowanie w górę - przypuszczam, że to może być błąd). De facto, obecnie, skalowane one będą do 2x podanej wartości. Może to mieć znaczenie dla kogoś, kto ma limity transfery sieciowego lub zań płaci albo ma słaby komputer, który sobie nie radzi z dużymi obrazkami. Uważam, że użytkownicy nie powinni się krępować i ustawiać w tym polu taką wartość, jaka dla nich w danej chwili jest wygodna. Funkcjonalność istnieje w ProofreadPage od dawna, ale dotychczas nikt nie uważał jej u nas za potrzebną. Ja uważam, że obecnie jest przydatna. Ankry (dyskusja) 10:35, 23 lis 2021 (CET)

Znikające skany

Jeśli macie koleżanki i koledzy problem ze "znikającym skanem", to jest szansa, że dodając do swojego common.css następujące ustawienie (phab:T297339#7558451):

#prp-page-image-openseadragon-vertical {
	height: 100%;
}

skany "odzyskacie". Nie ustawiam tego globalnie, bo nie mam pewności, czy nie popsuje to komuś czego innego. Ankry (dyskusja) 19:54, 9 gru 2021 (CET)

Community Wishlist Survey 2022 is coming. Help us!

The Community Wishlist Survey 2022 starts in less than two weeks (Monday 10 January 2022, 18:00 UTC). We, the team organizing the Survey, need your help.

Translate important messages

Promote the Survey Among anyone and everyone you know who has an account on wiki. Promote the Survey on social media, via instant messaging apps, in other groups and chats, in your WikiProject, Wikimedia affiliate - wherever contributors with registered accounts may be.

Only you can make the difference

How many people will hear and read about the Survey in their language? How many will decide to participate? Will there be enough of you to vote for a change you would like to see? It all depends on you, volunteers.

Why are we asking?

• We have improved the documentation. It's friendlier and easier to use. This will mean little if it's only in English.
• Thousands of volunteers haven't participated in the Survey yet. We'd like to improve that, too. Three years ago, 1387 people participated. Last year, there were 1773 of them. We hope that in the upcoming edition, there will be even more. You are better than us in contacting Wikimedians outside of wikis. We have prepared some images to share. More to come.

What is the Community Wishlist Survey?

It's an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements. Long years of experience in editing or technical skills are not required.

Thanks, and be safe and successful in 2022! SGrabarczuk (WMF) (talk) 04:15, 29 gru 2021 (CET)

Podział skanu na lewą i prawą stronę

Dzień dobry, potrzebuję pewne partie tekstu z tej książki i w związku z tym chętnie bym się nią zajął, ale niestety skan zawiera na jednej stronie dwie strony książki. Czy ktoś mógłby mi pomóc automatycznie rozdzielić skan na osobne strony a następnie wynik wgrać na Commons? Z góry bardzo dziękuję. Mahnka (dyskusja) 06:55, 29 gru 2021 (CET)

Dzień dobry, mogę podzielić, natomiast być może utracimy w ten sposób ocr. Czy to jest problem? Draco flavus (dyskusja) 08:47, 29 gru 2021 (CET)

Masz też tutaj już podzielone: [39] i [40]. Z pierwszą częścią może być problem z pobraniem ale poszukaj tutaj [41] . Ewentualnie zadecyduj i działamy. Draco flavus (dyskusja) 11:04, 29 gru 2021 (CET)

@Draco flavus: Ta wersja części pierwszej z polony wydaje się być uszkodzona na kilku stronach więc pozostańmy przy pierwotnym zamiarze automatycznego podziału na prawą i lewą stronę. Nie przeszkadza mi ewentualny brak ocr. Dziękuję za znalezienie tego w polonie, pozostałe książki tego autora wezmę stąd. Mahnka (dyskusja) 13:13, 29 gru 2021 (CET)

Załatwione File:Lud ukraiński. T. 1.djvu, jest OCR. Matlin (dyskusja) 11:15, 30 gru 2021 (CET)

OK, dzięki Draco flavus (dyskusja) 17:39, 30 gru 2021 (CET)

Inline styling na stronie głównej

Hej,

Korzystam z css userstyle'a Dark Wikipedia, który m.in. ustawia tło wikipedii na ciemny kolor. Tabelka na stronie głównej Wikiźródeł ma ustawiony background-color: #ffffff; co z tym css'em wygląda okropnie. Chciałom ustawić sobie swój własny css, żeby to nadpisać, jednak okazało się, że cała strona główna korzysta z inline styling'u, co znacząco to utrudnia. W związku z tym moje pytanie: Czy mogłobym utworzyć styles.css dla strony głównej i pozamieniać wszystkie style="..." na class="..." z odpowiednią klasą w pliku .css (analogicznie do angielskiej wikisource)? Mam uprawnienia do edytowania strony głównej (czy tak powinno być?), więc to tylko pytanie o zgodę, bo jako nowa osoba nie chcę edytować czegoś tak reprezentatywnego jak strona główna bez pozwolenia. -- niepodpisany komentarz użytkownika Alnaling (dyskusja | wkład)

Moim zdaniem nie ma ku temu przeszkód. To jest wiki, więc jeśli coś przypadkiem popsujesz, zawsze można cofnąć :) Zwróć jednak uwagę, że w tekstach inline-styling jest powszechny, a to dużo trudniej dostosować. Ja osobiście nie podejmę kroków w tym kierunku, bo zauważyłem, że zewnętrzne style dość często się nie dociągają (zwłaszcza przy jakichś przejściowych problemach na serwerach) pozostawiając stronę w ordynarnym, niesformatowanym stanie. Ankry (dyskusja) 16:34, 14 sty 2022 (CET)

Zmieniłom stronę główną i przy okazji poprawiłom parę drobnych błędów (np. id mf-indexes było dwukrotnie). Wydaje mi się, że nic się nie zmieniło ale możesz sprawdzić w wolnej chwili. Odnośnie zewnętrznych cssów, to nie powinien być problem, ponieważ templatestyles to jest de facto szablon, który wkleja internal css do outputu parsera, więc ten styl wciąż jest zaciągany razem z htmlem. Alnaling (dyskusja) 20:56, 14 sty 2022 (CET)

W poszukiwaniu znaku Unicode

Dzień dobry. Czy ktoś mógłby mi pomóc w znalezieniu znaku Unicode odpowiadającego temu co jest w pierwszym wersie strony Strona:Lud ukraiński. T. 1.djvu/198. Na stronie poprzedzającej tę stronę jakoś udało mi się odszukać znaki dzięki stronie https://shapecatcher.com/ ale z tym znakiem nie mogę sobie poradzić. Mahnka (dyskusja) 03:04, 11 sty 2022 (CET)

@Mahnka:obawiam się, że jedyny rozsądny sposób to stworzenie takiego znaku w jakimś formacie graficznym (.png lub .svg). Draco flavus (dyskusja) 13:53, 11 sty 2022 (CET)

Save the Date: Coolest Tool Award 2021: this Friday, 17:00 UTC

<languages />

Hello all,

The ceremony of the 2021 Wikimedia Coolest Tool Award will take place virtually on Friday 14 January 2022, 17:00 UTC.

This award is highlighting software tools that have been nominated by contributors to the Wikimedia projects. The ceremony will be a nice moment to show appreciation to our tool developers and maybe discover new tools!

Read more about the livestream and the discussion channels.

Thanks for joining! andre (talk) -08:02, 6 January 2022 (UTC)

Problem przycisku Duplikuj przy tworzeniu nowego indeksu

Dzień dobry! Przy duplikowaniu indeksu nie przenosi mi praktycznie żadnych danych do nowego indeksu. Screen problemu: https://i.imgur.com/8d0sfGO.png Czy może ktoś potwierdzić / zaprzeczyć? Seboloidus (dyskusja) 15:40, 21 sty 2022 (CET)

Mi też. Ale podobno niektórym działa, więc nie wiem jak diagnozować. Ankry (dyskusja) 21:48, 24 sty 2022 (CET)

Mnie jednak też nie działa, zadowoliłem się otwarciem pustej strony. Draco flavus (dyskusja) 22:03, 24 sty 2022 (CET)

Last two days for submitting proposals

Tomorrow is the last day for submitting proposals for the Community Wishlist Survey 2022.

Also, everyone is welcome to translate, promote, and discuss proposals. SGrabarczuk (WMF) (talk) 15:45, 22 sty 2022 (CET)

Szablon {{f*}}

Dlaczego w tym szablonie, mimo odwołania do parametru style i Modułu Style nie działa mi na stronie zastosowanie stylu css? Tommy J. (pisz) 01:08, 30 sty 2022 (CET)

Dzień dobry! Zastosowanie parametru style w tym miejscu działa, co można sprawdzić zmieniając np. text-align:right na color:red. Wydaje mi się, że po prostu nastąpiła próba zastosowania stylu przeznaczonego dla elementów blokowych w elemencie typu inline. Zwykły span chyba nie daje się wyrównać do prawej. Zamiast text-align:right użyłem float:right;display:block; i zadziałało. Mahnka (dyskusja) 05:40, 30 sty 2022 (CET)

Tak jest. Należałoby tu IMO zastosować {{f}}. Draco flavus (dyskusja) 09:23, 30 sty 2022 (CET)

Dzień dobry. Na tym przykładzie widać, że nie musi to być element blokowy, ważne tylko, aby miał właściwość float. Poprawcie mnie, jeśli się mylę. Seboloidus (dyskusja) 14:22, 30 sty 2022 (CET)

Dziękuję. O to mi chodziło. Tommy J. (pisz) 18:15, 30 sty 2022 (CET)

@Tommy Jantarek: Dodałem tam szablon {{Clear}}, aby nie powstawały takie zderzenia tekstu: https://i.imgur.com/u0CtuM6.png Seboloidus (dyskusja) 15:48, 1 lut 2022 (CET)

Łamanie tekstu w dymkach

Cześć, zwracam się z pytaniem o to, jak zrobić, aby w dymku tekst nie łamał się po każdym wyrazie? Aktualnie kod źródłowy odpowiedzialny za tworzenie dymków znajduje się tu, zaś przykład jego zastosowania jest tu. Co należałoby zmodyfikować z kodzie źródłowym dymku, aby dopasowywał się on do szerokości ekranu i tak łamał ten tekst, aby równomiernie wypełniał dymek? Z góry dziękuję za pomoc. Superjurek (Dyskusja) 21:01, 6 lut 2022 (CET)

Rollout of the new audio and video player

Pomóż przetłumaczyć na Twój język

Hello,

Over the next months we will gradually change the audio and video player of Wikis from Kultura to Video.js and with that, the old player won’t be accessible anymore. The new player has been active as a beta feature since May 2017.

The new player has many advantages, including better design, consistent look with the rest of our interface, better compatibility with browsers, ability to work on mobile which means our multimedia will be properly accessible on iPhone, better accessibility and many more.

The old player has been unmaintained for eight years now and is home-brewn (unlike the new player which is a widely used open source project) and uses deprecated and abandoned frameworks such as jQuery UI. Removing the old player’s code also improves performance of the Wikis for anyone visiting any page (by significantly reducing complexity of the dependency graph of our ResourceLoader modules. See this blog post.). The old player has many open bugs that we will be able to close as resolved after this migration.

The new player will solve a lot of old and outstanding issues but also it will have its own bugs. All important ones have been fixed but there will be some small ones to tackle in the future and after the rollout.

What we are asking now is to turn on the beta feature for the new player and let us know about any issues.

You can track the work in T100106

Thank you, Amir 18:59, 17 lut 2022 (CET)

Nowy filtr

Hej, jest nowy filtr, który nie dopuszcza do konstrukcji na końcu strony typu prze-<section end="abc" />. O ile przenoszenie przy pomocy dywizu od kilku lat działa, o tyle wstawienie po dywizie znacznika sekcji powoduje błąd. W takiej sytuacji należy użyć starszej konstrukcji {{pp|prze|niesienie}} i {{pk|prze|niesienie}}. W razie problemów czy po prostu uwag proszę mnie lub Ankry'ego pingować. Mam nadzieję, że filtr nie będzie nikogo denerwował a tym bardziej utrudniał pracy. Draco flavus (dyskusja) 18:35, 6 kwi 2022 (CEST)

Propozycja zaleceń co do przenoszenia wyrazów

Ostatnio jeden z nowych uczestników miał wątpliwości, co do właściwego sposobu przenoszenia wyrazów na Wikiźródłach. Moim zdaniem zalecenia powinny iść w kierunku dywizu, nawet jeśli są osoby przyzwyczajone do szablonów {{pp}}/{{pk}}.

Strony w przestrzeni Strona: generalnie traktujemy jako robocze i służące przygotowaniu tekstu do prezentacji na stronie głównej. W przypadku przenoszenia wyrazów między stronami oczekujemy przede wszystkim, by w przestrzeni głównej uzyskać właściwie złożony tekst.

Można ten efekt uzyskać na trzy-cztery sposoby:

1. pomijając jeden z członów wyrazu i wstawiając cały wyraz na jednej ze stron
2. kończąc człon przepisywanego wyrazu dywizem (czyli literalnie jak w tekście) — w wyjątkowych wypadkach ta metoda nie daje prawidłowych wyników
3. używając szablonu {{tns}}
4. używający przeznaczonych do tego szablonów {{pp}} i {{pk}}

Metoda pierwsza jest stosowana na innych Wikiźródłach, jednak nie na polskich, gdyż inne metody pozwalają lepiej odwzorować treść poszczególnych stron. Nie należy jej stosować rutynowo, ponieważ nie odpowiada to przyzwyczajeniom kolejnych skrybów przeglądających tekst.
Druga metoda jest czytelna i z reguły daje prawidłowy wynik.
Działanie szablonu {{tns}} polega na określaniu widoczności tekstu w zależności od przestrzeni, na której jest dany tekst. Możemy więc na stronie gdzie występuje pierwszy człon przenoszonego słowa podać, by efektem szablonu był fragment słowa, gdy wyświetlana jest strona w przestrzeni Strona: zaś nic w innych przestrzeniach (w tym Głównej); na drugiej zaś zastosowany szablon powinien być zadany w sposób komplementarny a więc: odpowiednio druga część słowa w przestrzeni Strona: zaś całe słowo w innych przestrzeniach (w tym Głównej)
Czwarta metoda to faktycznie wyspecjalizowany szablon {{tns}} z dodatkowym rozszerzeniem funkcjonalności o prezentowanie przy wyszukiwaniu całego słowa na obu stronach.

Zalety i wady dywizu:

• • dla przepisującego jest najprostsze, nie wymaga zaglądania na następną stronę
  • prostsze wizualnie (a więc czytelniejsze) dla redaktora przy sprawdzaniu i czytaniu tekstu w przestrzeni strona
  • Nieużywanie szablonów, co pozwala nieco oszczędzać limity w przypadku długich tekstów
  • w pewnych nielicznych wypadkach nie działa prawidłowo – patrz niżej

Zalety i wady szablonów {{pp}}/{{pk}}

• • konieczne w przypadku, gdy po znaku przeniesienia występują na stronie jeszcze inne fragmenty kodu (np. granice sekcji, szablony)
  • konieczne w przypadku niektórych nielicznych przeniesień (np. zbieg przenoszonego słowa i formatowania)
  • konieczne w przypadku tekstów, które nie są transkludowane lecz substytuowane
  • umożliwia znalezienie wyrazu na obu stronach (marginalna korzyść)
  • są to kolejne szablony wchodzące w limit transkluzji strony
  • przy przepisywaniu i sprawdzaniu konieczne jest sprawdzanie obu strony i kodu w szablonie
  • nie działają poprawnie lub kod jest bardzo skomplikowany w przypadku formatowań przenoszonego wyrazu (kursywa, wytłuszczenie)

Zalety i wady szablonu {{tns}}

• • konieczne wyjątkowo zastosowanie w bardzo rzadkich przypadkach
  • przy przepisywaniu i sprawdzaniu konieczne jest sprawdzanie obu strony i kodu w szablonie
  • jest używany zasadniczo rzecz biorąc do czego innego, dlatego przy regularnym systematycznym stosowaniu intencja przepisującego redaktora jest niejasna

Zalety i wady umieszczania całego wyrazu na jednej ze stron

• • metoda najprostsza
  • przy przepisywaniu i sprawdzaniu konieczne jest sprawdzanie obu stron
  • jest to metoda nieużywana zasadniczo rzecz biorąc u nas (w przeciwieństwie do np. innych Wikiźródeł) i w związku z tym intencja redaktora może nie być jasna i zachęcać do uzupełniania brakującej części wyrazu

Zalecenia:

1. Jako podstawową metodę przenoszenia traktować dywiz (a więc przepisywać tak, jak się widzi)
2. Starych już zrobionych tekstów (jeśli nie ma błędów) nie zmieniać
3. Długie teksty, gdzie strona całości jest tworzona specjalnie (z reguły teksty powyżej 700 stron) powinny być robione (przynajmniej w części, która jest substytuowana, a nie transkludowana) przy pomocy pp/pk, gdyż w takim wypadku metoda podstawowa (z dywizami) nie działa. Jest to istotne zwłaszcza po utworzeniu strony całości, dlatego że do starych tekstów rzadko się wraca i kontroluje poprawność.
4. Gdy jest to konieczne, stosować {{pp}}/{{pk}}
   • prze-<section end=abc /> – dywiz nie jest ostatnim znakiem
   • prze-{{skan zawiera grafikę}} – dywiz nie jest ostatnim znakiem
   • prze-</ref> – dywiz nie jest ostatnim znakiem
   • prze-
     

|-
|niesienie – dywiz nie jest ostatnim znakiem (w tym wypadku następna kolumna tabeli)

5. W ostateczności stosować {{tns}}

• (prze- niesiony – wyróżniony wyraz (kursywa) styka się po lewej stronie z tekstem pisanym normalnym krojem pisma
• (prze- niesiony – wyróżniony wyraz (wytłuszczony) styka się po lewej stronie z tekstem pisanym normalnym krojem pisma
• gdy konieczne jest zastosowanie szablonu {{kor}} w stosunku do przenoszonego wyrazu
• w pewnych wypadkach, gdy konieczne jest formatowanie części wyrazu itp.

6. W przypadkach szczególnych zastosować umieszczanie całego wyrazu na jednej ze stron (tradycyjnie tej, na której występuje drugi człon wyrazu).

Czy ktoś by chciał się wypowiedzieć? Zmodyfikować to? Draco flavus (dyskusja) 23:38, 1 maj 2022 (CEST)

•  Przeciw, gdyż:

1. jestem przeciwna wprowadzaniu niejasnych i dość skomplikowanych zasad, które jeszcze bardziej zniechęcają nowicjuszy... przebicie się przez to, co zaproponowałeś nabawiło mnie bólu głowy... kto to przeczyta, zrozumie i nie zapomni? czy naprawdę musimy tworzyć zalecenia tam, gdzie nie są one niezbędne?
2. jestem też przeciwna narzucaniu odgórnemu, że tak jest dobrze, a tak jest źle, w sytuacji gdy dobrze jest i tak — i tak,
3. nie wiem też, po co się wcinać w ulubiony sposób edytowania tym nielicznym edytorom, których jest coraz to mniej... i na siłę przyzwyczajać ich do innej metody, co do której nie mamy jeszcze pewności, że jest lepsza,
4. nie wiemy jeszcze, która metoda okaże się w przyszłości tą właściwą... cały czas trwają eksperymenty na proofreadzie i co środa jesteśmy zaskakiwani nowymi rozwiązaniami. Może więc weźmy na wstrzymanie i poczekajmy... samo się okaże, która metoda przetrwa... i wtedy wydamy proste zalecenie, które się da zamknąć w jednym zdaniu. Wieralee (dyskusja) 00:56, 2 maj 2022 (CEST)

Nie chodzi o to żeby zmieniać zasady czy coś narzucać. Tylko o to żeby były ustalone zalecenia.

Na ten moment ja robię używając po/pk, a po mnie ktoś na wszystkich stronach poprawia na dywiz bo jest powiedziane, że tak jest podobno prościej.

W tych wytycznych mamy napisane, że na ten moment użycie dywizu jest najprostsze, ale można używać po/pk, i żeby nie zmieniać tego co zastaliśmy w indeksie jeżeli nie jest błędne. Nikt nie narzuca zmiany sposobu pracy.

Jeżeli te zalecenia dopiszemy do strony pomocy to będzie jasne co robić. A że tekst jest długi, są dłuższe i mniej klarowne, i nie trzeba czytać do końca, tutaj na początku jest wyjaśnione o co chodzi, reszta jest dla tych bardziej dociekliwych.Joanna Le (dyskusja) 21:37, 2 maj 2022 (CEST)

Ja się tu zgadzam z Joanną: podstawowym zaleceniem powinno być nie zmieniać tego co się zastało, jeśli nie jest błędne. Poza tym, zostawiłbym użytkownikom dowolność - czyli niech sami decydują, której z dwóch metod przeniesienia używają. I tak trzeba opisać obie. Ankry (dyskusja) 01:33, 4 wrz 2022 (CEST)

Księga Przysłów Polskich

Próbuję ściągnąć ten oto słownik, aby go wrzucić na Commons i zrobić indeks na WŹ. Niestety nie pobiera się jako PDF, albo jeden plik DJVU, ale jako ZIP z masą pojedynczych stron w formacie DJVU i to takich, że żaden konwerter mi tego nie chce przerobić. Czy ktoś z Was ma możliwość wesprzeć w pobraniu tego pliku? z góry dziękuję za pomoc! Superjurek (Dyskusja) 21:10, 2 maj 2022 (CEST)

Indeks:Samuel - Adalberg - Księga przysłów.djvu Już jest, jeśli nie to samo, to podobne. Możesz przepisywać nie trzeba wgrywać plików. Joanna Le (dyskusja) 21:30, 2 maj 2022 (CEST)

Dobry wieczór @Superjurek:, z „wrzucaniem” tego typu rzeczy należy moim zdaniem podchodzić z wyczuciem, jeśli sam nie chcesz tego przepisywać, jak przypuszczam, i nie widzisz chętnego, to zostaw to. W tym konkretnym wypadku dochodzi jeszcze to, że ten akurat tekst mamy (Indeks:Samuel - Adalberg - Księga przysłów.djvu). Pozdrawiam Draco flavus (dyskusja) 21:31, 2 maj 2022 (CEST)

@Superjurek: tych pojedynczych plików djvu nie trzeba konwertować, a scalać. Narzędzie godne polecenia: DjVuToy (na Windowsa), zakładka Merger i w 5 sekund masz jeden scalony plik. Oczywiście, tak jak zauważyli przedmówcy, tę książkę już mamy. :-) Seboloidus (dyskusja) 22:39, 2 maj 2022 (CEST)

Duplikowanie

Czy potrzebna jest funkcja duplikowania indeksów i jak się sprawuje? Wargo (dyskusja) 19:34, 22 maj 2022 (CEST)

@Wargo: Cześć. Nie sprawuje się, bo jej nie ma od kilku miesięcy. Wcześniej była i uważam, że to przydatna i wygodna funkcja (była). Seboloidus (dyskusja) 20:06, 22 maj 2022 (CEST)

Popieram Draco flavus (dyskusja) 18:25, 23 maj 2022 (CEST)

Od jakiegoś tygodnia znowu działa funkcja duplikowania Draco flavus (dyskusja) 08:35, 5 paź 2022 (CEST)

Dodatkowe funkcje narzędzia Popraw tekst OCR

Dzień dobry! Zgłaszam potrzebę zwiększenia funkcji zamiany w narzędziu Popraw tekst OCR o następujące zestawy:
ś. p. ⇒ ś. p.
Ś. p. ⇒ Ś. p.
n. p. m. ⇒ n. p. m.
Proszę też o sprawdzenie, czemu jest tworzona konstrukcja np. ostatni&nbsp;t.&nbsp;j.?
Seboloidus (dyskusja) 11:59, 4 sie 2022 (CEST)

@Seboloidus zrobione! Zdzislaw (dyskusja) 21:07, 4 wrz 2022 (CEST)

Biblia Królowéj Zofii

Wzorem Biblii Wujka postanowiłem dodać wersety do Biblii Królowej Zofii. Jedyny sposób w jaki mi się to udało to zrobić można zobaczyć na stronie Biblia Królowéj Zofii/Księga Rodzaju 1 i strony wyjściowe Strona:PL Biblia Krolowej Zofii.djvu/49 + Strona:PL Biblia Krolowej Zofii.djvu/50. Spowodowało to znaczne skomplikowanie kodu na stronach i wydaje mię nieeleganckie. Może istnieje lepsze rozwiązanie? Fallaner (dyskusja) 18:55, 7 sie 2022 (CEST)

może zbędny trud - (= zostawić bez numerków?), albo prościej to zrobić (= po prostu wstawić numery wersetów kolorkiem mniejszym pismem przed każdym wersetem niejako już w kodzie strony, można to zrobić szablonem, wtedy będzie można wyłączać i włączać coś takiego {{wBKZ|Rdz|3|27}} albo {{wBKZ|27}} ₂₇. Ta pierwsza wersja komplikuje kod ale teoretycznie pozwala na większą elastyczność. Sekscji jednak nie zastąpi, sekcji nie da się wstawić szablonem. Draco flavus (dyskusja) 19:47, 7 sie 2022 (CEST)

Problem z odświeżeniem stron skanu

Załadowałem ostatnio nowy, zreperowany skan książki Ogniem i mieczem. Niestety, podmienione strony 226 oraz 229 nie wyświetlają nowych grafik. Różnice w grafikach są następujące: strona 226 i strona 229. Aby sprawdzić to co podaję, trzeba otworzyć grafikę dla danej strony i w pasku adresu zmienić jej rozmiar (z 2570px na inny) — wtedy ładuje się już nowy obrazek — o ile ktoś nie widzi go wcześniej (ja niestety, nie widzę).
@Bonvol, @Piotr433: Dziękuję wam za korekty, ale trzeba będzie jeszcze raz to skorygować.
Póki co nie mam pomysłu co z tym dalej zrobić... Seboloidus (dyskusja) 00:06, 4 wrz 2022 (CEST)

to ciekawa, ja mam najwyraźniej nową stronę 226 i starą 229. Wydaje mi się, że @Ankry: może tu pomóc. Ale sugeruję downgrade do koloru czerwonego. (Można skorygować zewnętrznie otwierając w innym oknie stronę na commons - ale to wymaga precyzji... Draco flavus (dyskusja) 00:24, 4 wrz 2022 (CEST)

obie strony sprawdziłem na podstawie nowych wersji – statusu ustawiłem na żółty... Proszę o korektę PO upewnieniu się, że widoczna jest strona nowa. Draco flavus (dyskusja) 00:51, 4 wrz 2022 (CEST)

Ja widzę poprawnie nowe wersje. Może to kwestia cache przeglądarki? Wtedy pół biedy. Albo problem z cache serwerów MediaWiki? Wtedy gorzej, bo różni użytkownicy mogą widzieć różne wersje dopóki stare nie wyekspirują. @Seboloidus, @Draco flavus: Generalnie, zalecałbym na przyszłość purge strony pliku na Commons przed nadpisaniem (przynajmniej w przypadku książek, które mają więcej niż ok. 300 stron). A jeśli wystąpi błąd, to spróbować po kilku minutach ponownie, nawet kilka razy. Przy nadpisywaniu też jest robiony purge, ale w razie błędu nie jest powtarzany i zostają na serwerach stare miniaturki, do których oprogramowanie MediaWiki nie ma już dostępu. Teoretycznie, jedyną możliwością naprawienia problemu jest wtedy interwencja administratorów serwerów w WMF. Ale oni nie są chętni do podejmowania działań, jeśli problem nie dotyczy przynajmniej tysięcy, jeśli nie dziesiątek czy setek tysięcy stron. ("Inne strony działają, więc problem jest marginalny i nie warto się nim zajmować.") Ankry (dyskusja) 01:16, 4 wrz 2022 (CEST)

Dzięki za info. Postaram się pamiętać o purge. U mnie wcześniej problem występował także bez cache'u przeglądarki, bo sprawdzałem na kilku. Seboloidus (dyskusja) 01:58, 4 wrz 2022 (CEST)

@Ankry:Tu było mylące, że pierwszą ze stron ja widziałem poprawnie, drugą starą; @Seboloidus: obie stare... Co zrobiłem wczoraj, już po eskalacji przez Seboloidusa tutaj? Dopisałem do indeksu wielkość strony. To pomogło, ale to niezbyt satysfakcjonujące. Może byś, ankry, te dwie strony uwierzytelnił? Wtedy można je najwyżej wrzucić do obserwowanych, ale i tak pies z kulawą nogą się nimi już nie zajmie. Draco flavus (dyskusja) 10:29, 4 wrz 2022 (CEST)

@Draco flavus: Ja je właśnie byłem przepisałem od nowa, więc nie mogę już zmieniać ich statusu na wyższy. Ankry (dyskusja) 15:30, 4 wrz 2022 (CEST)

@Ankry:, ok, pogubiłem się już, ja zrobiłem żółty, wynikałoby z tego, że @Seboloidus: może zmienić na zielony... Draco flavus (dyskusja) 16:16, 4 wrz 2022 (CEST)

@Draco flavus: Nieprawda, ja zmieniłem na żółty. 😀 Piotr433 już zazielenił. Seboloidus (dyskusja) 16:21, 4 wrz 2022 (CEST)

@Seboloidus: ja też, wczoraj o 0:34 (uff, nie jest ze mną aż tak źle) Draco flavus (dyskusja) 16:29, 4 wrz 2022 (CEST)

Nowy wygląd naszych stron - Wektor (2022)

Witam. Chciałbym poznać Wasze zdanie nt. utrzymania jako domyślnego nowego wyglądu interfejsu - skórka "Wektor (2022)". W moim odczuciu Wikiżródła straciły znacznie na czytelności i dostępności. Oczywiście, korzystając z preferencji, każdy może zmienić wygląd pomiędzy "Wektor (2022)" i "Stary Wektor (2010)", lecz... w mojej ocenie domyślnie (także dla niezalogowanych czytelników), tak jak na en i fr, powinniśmy pozostawić stary wygląd i skórkę "Stary Wektor (2010)". Jakie są Wasze odczucia? Pozdrawiam, Zdzislaw (dyskusja) 20:03, 6 wrz 2022 (CEST)

Dzień dobry, Pobieżnie spojrzawszy myślę, że nie widać większej zmiany, prócz zwiniętej lewej kolumny z informacjami technicznymi. Dla niezalogowanych nie powinno to być dotkliwe. Wikiskrybowie mogą kolumnę rozszerzyć jednym klikiem. Na małych ekranach Wektor (2022) moim zdaniem jest bardziej przejrzysty. Pozdrawiam, Rosewood (dyskusja) 19:14, 16 wrz 2022 (CEST)

W menu po lewej jest wielki wytłuszczony nagłówek "Języki" (z zębatką) tymczasem wybór języków jest w prawym górnym rogu. Mahnka (dyskusja) 01:57, 17 wrz 2022 (CEST)

@Mahnka poprawiłem. Te języki były dodawane w naszym Common.js. Można by pomyśleć nad zrobieniem domyślnego gadżetu z tego innych tego typu skryptów. Aczkolwiek nie jestem pewien zastosowania tego. W narzędziach jest link "Dodaj linki wersji językowych", więc to dodawanie sekcji chyba nie jest potrzebne. Nux (dyskusja) 22:04, 18 paź 2022 (CEST)

Niestety niektóre karty na górze są zepsute. Na Discrodzie było to wspomniane. To jest w wypadku kodu, który dodaje karty ręcznie zamiast korzystać ze standardowej funkcji (addPortletLink). Patrzyłem na to jakiś czas temu, ale w między czasie przełączyłem się na starego wektora... Pewnie trzeba by do tego wrócić, skoro w tym roku ma być domyślną skórką. Jakby co mogę poprawić później, tylko chyba muszę wystartować w wyborach czy coś ;-) Nux (dyskusja) 16:53, 25 wrz 2022 (CEST)

Taby częściowo poprawione dzięki @Zdzislaw. Dodałem jeszcze małą poprawkę klas, która powinna rozwiązać problem z kartą Koryguj i do indeksu. Nux (dyskusja) 21:52, 18 paź 2022 (CEST)

Linkujące z siostrzanych projektów - aktualizacja

Zaktualizowałem gadżet Wikiźródła:Narzędzia/Linkujące z siostrzanych projektów. Dajcie znać, jeżeli zauważycie jakiś problem z nim związany. Zdzislaw (dyskusja) 17:25, 18 wrz 2022 (CEST)

Kroje pisma / Fonty

Witajcie. Spędziłem trochę czasu nad próbą doboru właściwych fontów dla takiej szalonej strony Tytułowej i na koniec wyszło mi to, że i tak danego fontu przeglądarka czy serwer czy cokolwiek innego nie ma i wyświetla się Times New Roman lub inny standard. Stąd przyszło mi do głowy, że dobrze by było zrobić gdzieś stronę pomocy z listą zalecanych fontów. Jacek Fink-Finowicki (dyskusja) 12:02, 29 wrz 2022 (CEST)

@Jacek Fink-Finowicki: Cześć. Myślę, że nie ma co przesadzać z tym. Z fontami jest zawsze problem ich licencji i tego czy są zainstalowane po stronie przeglądającego. A takie mało znane jak „Corki“ to już kosmos. :-) Druga rzecz jest taka, że trzeba też patrzeć pod kątem ebooka. Bo to niejako główny cel naszej pracy, aby przepisana książka mogła być dostępna w formatach ebookowych. A tutaj czytniki ebooków przesieją temat fontów, jak przez gęste sito. Seboloidus (dyskusja) 14:12, 30 wrz 2022 (CEST)

Abo właśnie i o to sito jest to pytanie. Bo o ile patrząc na fonty googla, które są teoretycznie dostępne właśnie taki Corki mi pasował najbardziej, a i kilka jeszcze innych znalazłem, lecz już odpuściłem próby ich przywoływania. Stąd chciałbym wiedzieć jaką pulą fontów dysponujemy lub jakie są zalecane. I dobrze by było gdyby to np. dorzucić do dokumentacji szablonu F, aby kolejni nie musieli robić kwerendy w tym temacie. Jacek Fink-Finowicki (dyskusja) 14:23, 30 wrz 2022 (CEST)

@Jacek Fink-Finowicki: Mierzyłem się z tym samym problemem wielokrotnie. Na szczęście CSS dopuszcza priorytetyzację. Mnie wielokrotnie pomagały strony typu W3Schools CSS Websafe Fonts, które dają jakiś kierunek. Chętnie przygarniemy pierwsze pomysły do listy w stylu: oryginał książki -> najbliższe fonty

Rozstrzelenie i korekta

Hej, na tej stronie na początku nowego akapitu jest literówka:   „Chreśćianin” zamiast „Chrześćianin”. Niestety słowo to jest rozstrzelone, a po nim jest kropka. Wewnątrz {{Korekta}} nie można używać {{Rozstrzelony}}, jednak całej korekty nie da się wsadzić do {{Rozstrzelony}} bez dodania odstępu przed kropką. Co zrobić w takiej sytuacji? Alnaling (dyskusja) 12:21, 29 wrz 2022 (CEST)

Myślę, że tak, jak zrobiłeś, jest OK. Dymek daje wprawdzie tylko podgląd "techniczny" ale poza tym OK. Draco flavus (dyskusja) 13:59, 30 wrz 2022 (CEST)

Coolest Tool Award 2022: Call for nominations

The fourth edition of the Coolest Tool Award welcomes your nominations! What is your favorite Wikimedia related software tool? Please submit your favorite tools by October 12, 2022! The awarded projects will be announced and showcased in a virtual ceremony in December.

MediaWiki message delivery 20:30, 3 paź 2022 (CEST)

Usunięcie pola Css z indeksu

Cześć. Chciałbym usunąć pole Css z indeksu. Wygląda na to, że nie jest nigdzie dołączane to automatycznie, ale wolałbym spytać, czy ktoś ma jakieś narzędzie, które tego używa. Zaznaczam, że nie mówię u usuwaniu karty Style, to jest inny CSS i ten działa automatycznie (przynajmniej na poziomie przestrzeni Strona oraz ePub).

Konfiguracja tego pola jest fizycznie tutaj od dawana: MediaWiki:Proofreadpage index data config.json. Ale co najmniej en.ws tego nie używa w ogóle, a większość narzędzi pod nich jest zrobiona z tego co słyszałem.

Mogę przelecieć botem i sprawdzić czy gdzieś to jest używane. W sumie pewnie i tak mógłbym sobie zrobić z tego jakąś testową bazę (w razie gdyby FBC jednak potrzebowało pomocy z importem). Nux (dyskusja) 20:00, 21 lis 2022 (CET)

• Funkcja działająca, używana, chociaż stara, nie widzę powodów do usuwania (większość narzędzi jest(była) robione przez kolegów z fr, gdzie pole to jest także aktywne). Zdzislaw (dyskusja) 01:53, 22 lis 2022 (CET)

  Przykład użycia? Nux (dyskusja) 01:56, 22 lis 2022 (CET)

  ehhhh... .pagetext p {margin-top: 5em;} Zdzislaw (dyskusja) 02:48, 22 lis 2022 (CET)

• Laickie pytanie mam: a co miałoby przynieść usunięcie tego pola z indeksu? Seboloidus (dyskusja) 02:28, 22 lis 2022 (CET)

  Chodzi o to, żeby się nie myliło po prostu. Najpierw myślałem, że tam trzeba wpisywać CSS, ale najwidoczniej to nie działa. Zrobiłem parę testów i nie widzę żadnego efektu. Nie znalazłem też dokumentacji i póki co nikt też jej nie wskazał. Gdyby tego pola nie było, to nie musiałbym na pewno poświęcać czasu na to, żeby sprawdzić co robi ;) Nux (dyskusja) 02:35, 22 lis 2022 (CET)

  Rozumiem. Znalazłem kilkanaście indeksów korzystających ze stylów css zamieszczonych w tym polu, m.in.: Indeks:Dzieła dramatyczne Williama Shakespeare T. 10.djvu i kilka innych tomów, Indeks:Elwira Korotyńska - Złota Marysia.djvu, Indeks:Stanisław Goldman - Słownik Dux-Liliput.djvu. I style te na stronach tych indeksów działają.
  

  Może to jest jedynie problem słabego (mało precyzyjnego) opisu tej funkcji? Do tej pory z tego korzystało chyba tylko dwóch Skrybów. Seboloidus (dyskusja) 02:44, 22 lis 2022 (CET)

  Chyba nie tylko, bo jak się wejdzie w Chrome, w devtools (ctrl+shift+i) to tam jest wyszukiwanie (ctrl+shift+f). I ten css nie jest u nas dołączany w ogóle. Porównaj te przykłady z francuskimi.

  Myślę, że Francuzi też się z tego wycofali, bo ich przykłady nie działają. fr:Aide:Espace « Livre ». Wygląda na pozostałość po jakiś starych eksperymentach. To zdaje się miało dodawać klasy do div otaczającego strony, ale potem zaczęli dodawać to jako css, ale nie skonwertowali starych przykładów i teraz mają rozjechane. Nux (dyskusja) 02:48, 22 lis 2022 (CET)

  Ciężko mi powiedzieć coś więcej, bo to, co na franc. WŹ widzę, to jakieś nazwy własne np. "ligatures largeur20" i nie będę dociekał ich pochodzenia. U nas, w w/w przykładzie Złotej Marysi widzę normalną klasę i widzę, że tekst na stronach jest formatowany prawidłowo. I tyle mogę wysnuć jako laik. A skoro działa te kilkanaście (może więcej) indeksów, to nie wiem czy jest sensownym usuwanie tego pola. Seboloidus (dyskusja) 03:01, 22 lis 2022 (CET)

  O. Naprawiło się... No cóż, skoro działa, to OK, to może tylko dokumentacji brakuje. Nux (dyskusja) 02:54, 22 lis 2022 (CET)

  Uffff... dobrze, że się naprawiło, zanim usunąłeś, co ciekawe u innych działało cały czas. Zdzislaw (dyskusja) 02:57, 22 lis 2022 (CET)

  No, nie. Co za ulga, że Ciebie nie posłuchałem, żeby usunąć. Nux (dyskusja) 03:05, 22 lis 2022 (CET)

Poprawa jednostek i przycięcie Epub.css

Cześć. Trzeba by pomyśleć o zmianie jednostek {{tab}} i wyczyszczeniu CSS z powtórzonego kodu. CSS z MediaWiki:Epub.css jest dołączanym do e-booków (dopisany w main.css).

Problem jednostek. Rozmiary czcionek (fontów) są w em i tak jest też skalowany tekst. Wszystko co jest powiązane z czcionkami powinno być w em. Na pewno w px mogą zostać te rzeczy typu border:1px, chociaż przy szerszych ramkach też miałbym wątpliwości. Tak jak pisał @Alnaling w innym wątku em (i inne jednostki względne) to dosyć ogólna rekomendacja w CSS (nie tylko do ePubów).

Duplikacja kodu CSS. Podobnie można pomyśleć, czy w treści książek są/bywają infoboksy, amboksy i inne messagebox i czy te style są potrzebne w Epub.css.

• Podobne style można znaleźć w: MediaWiki:Epub.css, MediaWiki:Common.css oraz ew. MediaWiki:Mobile.css (ten ostatni może akurat odwrotnie - trzeba by uzupełnić).
• Osobiście za mało znam zwyczaje, żeby to móc uporządkować (nie wiem co jest potrzebne co nie). Podejrzewam, że co najmniej infoboksów nie używa się w przestrzeni Strona (a skoro nie jest używane w Strona, to pewnie nie jest potrzebne w Epub.css).
• Wielkość (bajtowa) tego css może nie jest dużym problemem, ale kopiowanie ewentualnych zmian pomiędzy wieloma miejscami, to jest problem utrzymania kodu. To jest główny problem duplikacji kodu. Wystarczy, że ktoś zapomni zmienić w jednym miejscu i problem gotowy.

Zamieszczam te dwie sprawy razem, bo po przycięciu zbędnego kodu łatwiej będzie też zrobić poprawki. No i potem pewnie przetestować i tak trzeba to razem. Nux (dyskusja) 17:27, 23 lis 2022 (CET)

• Ja na Twoim miejscu wydzieliłbym wątek {{tab}} :) Przeżyłem na ws kilka gorących dyskusji o nim... Jest to szablon używany (cytuję ze statystyk "używany na 818 498 stronach). Jego 18px to oczywiście zaszłość wieeeeeloletnia, lecz nawet sobie nie wyobrażasz do jakich celów Skrybowie potrafią go użyć, formatowania tabelek (ich szerokości), dialogów, pozycji obrazków,..... Zapewnienie wstecznej zgodności będzie karkołomnym zadaniem. Jest on także częścią składową wieeeelu innych szablonów... Czego byś nie zmienił to jest szansa, że inne się rozleci :) Już chyba łatwiej zaproponować nowy szablon, "poprawny", i zachęcać do jego stosowania, mając nadzieję, na przyjęcie się tej nowej świeckiej tradycji.

• Prosze pamiętaj, że w tym przypadku nie możemy sobie pozwolić na ani jeden bit więcej - jako szczególnie poszkodowany projekt siostrzany poprzez nałożone limity parsera oprogramowania mw (które w naszym przypadku należy jeszcze dzielić przez dwa :) ) - dodanie tutaj chociażby jednego bitu wywalić może wiele tekstów.

• Co do styli (wydawałoby się nadmiarowych) w epub.css i innych, to pamiętać należy, że mamy trochę tekstów non-proof i tam znajdują się różne formatowania, szczególnie w starych. A, i to, że styl ktoś dedykował infoboksowi, nie znaczy, że nie jest użyty w innych celach. Trzeba by tutaj szczegółowej kwerendy i ewentualnych zmian przed usuwaniem. Po kawałku... One są raczej statyczne, patrząc na ostatnie kilka lat.

Zdzislaw (dyskusja) 19:09, 23 lis 2022 (CET)

Odnosząc się do propozycji nowego, poprawnego szablonu {{tab}}, to chciałobym zwrócić uwagę, że sam fakt, że korzystamy z takiego szablonu do akapitów jest błędem (o czym pisałom już szerzej tutaj), więc jeśli pójdziemy tą ścieżką to lepiej zachęcać do stosowania zwykłych pustych linii, a ewentualny nowy szablon zalecać tylko do wstawiania jakichś większych odstępów w tekście (coś jak {{gap}} i {{wide space}} na enws). Alnaling (dyskusja) 22:32, 23 lis 2022 (CET)

O. Nie widziałem tego posta. Tak, to że tam jest br zamiast akapitu, to też jest problem. W windowsowej fredzie to powoduje, że akapity w ogóle nie są widoczne. To znaczy nie widać wcięcia i nie ma też żadnego odstępu. Wydaje mi się jednak, że to by trzeba robić indywidualnie w każdej książce. Zrobiłem to testowo w herbarzu Strona:PL Boniecki - Herbarz Polski (1).djvu/17. Wadą jest to, że początek strony będzie zawsze wcięty. Być może jakoś sekcjami dałoby się to rozwiązać. Ew. css można dodawać na koniec. W ramach Distributed Proofreaders takie było założenie, że w pierwszych fazach nie dodaje się formatowania i skład tekstu robi się później... Tylko to jest trochę problem, czy byłoby wystarczająco dużo osób, żeby to robić. Nux (dyskusja) 11:05, 24 lis 2022 (CET)

Klas `infobox` i `messagebox` nie ma... A przynajmniej nie bezpośrednio [42]. Był jakieś jedno użycie. Oczywiście nieprawidłowe, ale na Wikipedii też się takie zdarzają jeszcze czasami. Jest trochę ambox itp, więc to pewnie trzeba zostawić. Nux (dyskusja) 22:00, 23 lis 2022 (CET)

Pamiętaj, że mamy także wiele tekstów non-proof - więc raczej tak - co nie zmienia wyniku :) Zdzislaw (dyskusja) 22:15, 23 lis 2022 (CET)

• Co jakiś czas przychodzi na Wikiźródła jakaś nowa techniczna osoba, która chce wszystko zmienić pod siebie, "bo według niej tak jest lepiej". Czasami może i faktycznie byłoby lepiej, ale... wszystkie te zmiany wymagają żmudnej pracy nad tekstami, które już są wprowadzone. Mam już dosyć ciągłego poprawiania już raz zrobionych stron. Jeżeli ktoś z Was podejmuje się przejrzenia i poprawienia wszystkiego, co już mamy, to niech wprowadzi zmiany, proszę bardzo... Ale zazwyczaj jest tak, że technicznym osobom praca z tekstami szybko się nudzi, więc stąd uciekają... zostawiając cały bałagan po sobie i jego sprzątanie zwykłym przepisywaczom. A zwykli przepisywacze sprzątają, sprzątają, sprzątają... poprawiając wciąż i wciąż to, co już kiedyś zrobili... i nie mogąc się zająć nowymi tekstami. A kiedy już trochę jest ogarnięte, to przychodzi następna techniczna osoba, która znów pragnie nas uszczęśliwić...
  

Tak więc zgadzam się na zmiany tylko pod warunkiem, że WPROWADZAJĄCY te zmiany SAM poprawi WSZYSTKO, co już zostało kiedyś zrobione. Wieralee (dyskusja) 01:33, 24 lis 2022 (CET)

Tak, z tego co widzę z tej dyskusji, to ciężko to będzie zmienić, żeby zachować zgodność wsteczną. Myślę, że można by botem poprawić wybrane książki, ale to pewnie tylko na zasadzie jakiegoś przełącznika (takie opt-in dodawane przez osobę przepisującą czy właściwie wydającą daną książkę).

Nie jestem pewien czy takie rzeczy da się zrobić w istniejących mechanizmach. Pewnie mogę wykorzystać Sylwandirę do testów tego, ale to już głębsza zmiana, to Wydartego bym musiał spytać jak to widzi... W każdym razie waham się między jakąś formą dodania jakiejś opcji w indeksie, a nowym szablonem. Nie wiem czy by się tak dało, ale może sam indeks mógłby dodawać określoną klasę typu "standard-2023" (zdaje się, że fr.ws już tak było kiedyś). Ew. jakiś bot mógłby chodzić i po wykryciu tego w indeksie mógłby wykonywać zmianę (nieco ryzykowne, ale wykonalne). Ew. ten nowy szablon mógłby dodawać określoną klasę paragrafom lub całym sekcjom (nie jestem pewien czy sekcje mogą tak działa na ws przez wiele stron)...

W każdym razie tak czy inaczej kontrolę miałby skryba-wydawca. Nux (dyskusja) 15:11, 24 lis 2022 (CET)

• P. S. Jeszcze kilka myśli, które plączą mi się po głowie po mojej wczorajszej, niewątpliwie dość emocjonalnej wypowiedzi...
  • nie każdy Wikiskryba jest informatykiem, edytowanie Wikiźródeł powinno być dostępne dla każdego, także i dla osób, które urodziły się w erze pre-IT;
  • css jest na WŹ stosunkowo nowym rozwiązaniem, większość Wikiskrybów nie mających do czynienia z informatyką go po prostu nie czuje/nie rozumie
  • pojedyncza linia przerwy zamiast br-a nie jest zła... sęk w tym, że co jakiś czas — zupełnie od nas niezależnie — ktoś "na górze" postanawia coś zmienić w proofreadzie i uszczęśliwia nas odgórnie rozwiązaniami, w wyniku których strony się nam rozsypują... w mojej wieloletniej praktyce edytora odstępy te mocno się zmieniały... czasami były niewidoczne, a czasami dawały odstępy nawet do 1,5 wiersza. Dawno już nie edytowałam na en.ws czy na multi, ale wydaje mi się, że tam nie robią stron całości... i nie przychodzi im nawet do głowy, że na stronie całości teksty nam się całkiem sklejają. Zawsze też jest problem na złączeniu stron, trzeba tam sztucznie coś wklejać, bo oprogramowanie automatycznie wycina wolne linie na początku i na końcu strony. Można wtedy wklejać właśnie br-a, ale to nie takie proste, bo odstęp wynikający z br-a na przestrzeni czasu także się zmienia. Kiedyś br=1em, teraz ktoś to "sobie" zmienił i jest to dużo więcej, więc niektóre teksty zaczęły wyglądać dziwnie;
  • wprowadzenie tab-ów i br-ów umożliwiło sztywne formatowanie tekstu, uniezależniające nas od kolejnego "widzimisię" osób, które zajmują się proofreadem, chociaż w zasadzie na co dzień nie edytują na WŹ i nie mają wyobrażenia, jak ich zmiany mogą wpłynąć na niektóre strony;
  • o ile sprawa jest prosta w zwykłej prozie, o tyle na stronach tytułowych, okładkach, w poezji i dramatach tab-y i br-y są często niezbędne, żeby tekst przypominał pierwowzór;
  • mnie też podobają się parametry "przed=" i "po=". Sęk w tym, że proste edytory tekstu po prostu ich "nie widzą" (tak jest na moim telefonie, do przeglądania epubów zalecana jest tam bezpłatna aplikacja ReadEra, która po prostu skleja tekst bez odstępów robionych za pomocą br-ów)... więc odeszłam od przed= i po= i wróciłam do używania br-ów w miejscach, gdzie odstęp wydaje mi się bardziej potrzebny;
  • rozumiem, że powinniśmy, mimo utartych przyzwyczajeń, iść jednak z postępem... dlatego wprowadzenie nowych rozwiązań w nowo tworzonych tekstach/indeksach w formie nowych szablonów, istniejących OBOK starych, wydaje się dobrym pomysłem. Jeśli coś jest lepsze i łatwiejsze, to się samo przyjmie ;) starzy edytorzy w końcu kiedyś wymrą, a nowi będą już robić po nowemu ;))) Wieralee (dyskusja) 16:43, 24 lis 2022 (CET)

  Dzięki za szczegółową odpowiedź. Poirytowanie szczylami o wątpliwym długoterminowym zaangażowaniu w projekt, chcącymi wprowadzać radykalne zmiany, takimi jak ja, jest całkowicie zrozumiałe i sympatyzuję :). Chciałobym tylko wyjaśnić kilka nieporozumień które się tu wkradły

• • nie każdy Wikiskryba jest informatykiem, edytowanie Wikiźródeł powinno być dostępne dla każdego, także i dla osób, które urodziły się w erze pre-IT;
  • css jest na WŹ stosunkowo nowym rozwiązaniem, większość Wikiskrybów nie mających do czynienia z informatyką go po prostu nie czuje/nie rozumie

• Zaproponowane zmiany nie mają na celu wymuszać (ani nawet zachęcać) do korzystania z CSSa, to wciąż pozostaje w kwestii osoby przepisującej. Style indeksu pojawiają się w dyskusji, ponieważ są wykorzystywane do eksperymentów z nowymi rozwiązaniami, ale dyskusja dotyczy zmian CSSa ogólnostronowego, którego przeciętny skryba nie rusza. (Jest tu też poruszany problem jednostek CSS, które "przeciekają" do pracy przeciętnego skryby np. przez szablon {{f}}, ale tu się już mleko rozlało i najprościej będzie po prostu edukować skrybów by wykorzystywali tam tylko em albo %.)

• • pojedyncza linia przerwy zamiast br-a nie jest zła... sęk w tym, że co jakiś czas — zupełnie od nas niezależnie — ktoś "na górze" postanawia coś zmienić w proofreadzie i uszczęśliwia nas odgórnie rozwiązaniami, w wyniku których strony się nam rozsypują... [...]
  • wprowadzenie tab-ów i br-ów umożliwiło sztywne formatowanie tekstu, uniezależniające nas od kolejnego "widzimisię" osób, które zajmują się proofreadem, chociaż w zasadzie na co dzień nie edytują na WŹ i nie mają wyobrażenia, jak ich zmiany mogą wpłynąć na niektóre strony;

• Ta "sztywność" formatowania akapitów jest właśnie tym czego chciałobym się pozbyć. Rozumiem i popieram chęć uzyskania spójnego wyglądu, jednak nie kosztem dostępności, a takie akapity są źle obsługiwane przez screen readery, niestandardowe przeglądarki i niektóre czytniki.

• • o ile sprawa jest prosta w zwykłej prozie, o tyle na stronach tytułowych, okładkach, w poezji i dramatach tab-y i br-y są często niezbędne, żeby tekst przypominał pierwowzór;
  • mnie też podobają się parametry "przed=" i "po=". Sęk w tym, że proste edytory tekstu po prostu ich "nie widzą" (tak jest na moim telefonie, do przeglądania epubów zalecana jest tam bezpłatna aplikacja ReadEra, która po prostu skleja tekst bez odstępów robionych za pomocą br-ów)... [...]

• Zaproponowana zmiana nie miała na celu całkowitego pozbycia się br-ów z wikiźródeł. Mają one swoje miejsce tam gdzie autor faktycznie złamał wiersz i nie mam nic przeciwko okazjonalnemu nadużyciu do wstawienia pionowego odstępu. Podobnie szablon {{tab}} można by śmiało wykorzystywać do pozycjonowania tekstu i wstawiania dłuższych spacji (chociaż tutaj lepiej wprowadzić nowe szablony z lepszymi wartościami domyślnymi i bez historycznego bagażu). Problemem jest kombo br tab do wstawienia akapitu. (Sam fakt, że tab ma dwojakie użycie jest problematyczny. To tak jakby {{inicjał}} wykorzystywać do powiększenia liter w tytule. Jak rozumiem, z tego wynikają problemy ze zmianą domyślnego rozmiaru wcięcia akapitowego na jednostki względne, ponieważ nie chcemy zepsuć jego użytku tam gdzie był wykorzystywany do pozycjonowania.)

  Na zakończenie chcę powiedzieć, że zgadzam się z twoją propozycją rozwijania na razie tego formatu równolegle do starego. Pozwoli to wykorzenić ewentualne problemy, które, tak jak wspomniałaś, być może wyjdą choćby przy tworzeniu charakterystycznych tutaj stron całości. Alnaling (dyskusja) 09:44, 25 lis 2022 (CET)

Join the Coolest Tool Award 2022: Friday, Dec 16th, 17:00 UTC

The fourth edition of the Wikimedia Coolest Tool Award will happen online on Friday 16 December 2022 at 17:00 UTC!

This award is highlighting software tools that have been nominated by contributors to the Wikimedia projects. The ceremony will be a nice moment to show appreciation to our tool developers and maybe discover new tools!

Read more about the livestream and the discussion channels.

Thanks for joining! -Komla

MediaWiki message delivery 19:53, 5 gru 2022 (CET)

Problem z szablonem Dane tekstu

Hej.

Postanowiłem spróbować swoich sił, tłumacząc dla Wikiźródeł Carmillę (to klasyka, a jeszcze jej nie ma). Niestety, nie mogę odpowiednio sformatować linku do źródła, którym są angielskie Wikisources :( Czy ktoś może looknąć na moją stronkę i powiedzieć mi, co zrobiłem źle?

LINK: click

Z góry dzięki za pomoc! ;-) --Kaworu1992 (dyskusja) 05:06, 10 gru 2022 (CET)

Hej, żeby linkować do wikisource musisz użyć odpowiedniego prefiksu (w tym przypadku s:). Samo en: jest niepoprawnym prefiksem, więcej informacji znajdziesz tutaj. Alnaling (dyskusja) 16:53, 10 gru 2022 (CET)

Filtr nadużyć na stronie Strona:Agnieszka Pilchowa - Kilka obrazków chorób umysłowych.djvu/15

Nie wiem, do kogo się zwrócić... Ktoś założył na WŹ błędnie działające filtry nadużyć i nie podał, jaki to filtr, gdzie się go wyłącza i kto się nim opiekuje.

W każdym bądź razie nie mogę edytować tej strony — wyświetla się komunikat "Uwaga: Twoje działanie zostało automatycznie zidentyfikowane jako szkodliwe. Status tej strony był już przez ciebie zmieniany. Nie należy robić tego ponownie" — i nie mogę zapisać strony.

Nie wiem, dlaczego ktoś uznał, że bezmyślny skrypt "wie lepiej", niż administrator z wieloletnim doświadczeniem — i wyłączył administratorom możliwość pracy.

Co dalej? Tak ma już teraz być? Wieralee (dyskusja) 00:43, 30 wrz 2024 (CEST)

Hej, wyzwoliłaś filtr nadużyć 6 (a widać to tutaj). Filtr nie jest zapewne doskonały i został zmylony twoją (wcześniejszą) edycją żółty→czerwony. Myślę, że rozsądnym nakładem środków nie da się go przed takimi przypadkami zabezpieczyć. Możesz go czasowo wyłączyć, możesz po prostu poprosić kogoś o edycję. A filtr napisał dawno temu @Ankry:. Pozdrawiam Draco flavus (dyskusja) 21:55, 30 wrz 2024 (CEST)

Potwierdzam, co napisał Draco: skoro uznałaś, że należy stan korekty cofnąć do stanu czerwonego, to ponowne zażółcenie należy zostawić komu innemu. A poprawki możesz zawsze nanieść nie zmieniając stanu korekty. Mamy ustalenie, że osoba, która nadaje stan czerwony nie powinna zażółcać: i ten filtr to egzekwuje. Jeśli się z tym nie zgadzasz, masz uprawnienia by wyłączyć filtr. Ankry (dyskusja) 22:20, 30 wrz 2024 (CEST)

Interwiki na stronie Ostatnich zmian

Dzień dobry. Od kilkunastu dni na stronie Ostatnich zmian w skórce nowego Vectora przestały się pojawiać interwiki (lista rozwijana w prawym górnym narożniku, w linii tytułu strony). Po przejściu na stary Vector wszystko jest w porządku (lista u dołu menu bocznego po lewej stronie strony). Na innych stronach (np. autorzy, utwory) wszystko jest w porządku. Czy ktoś zna przyczynę? Wygląda to na odgórną decyzję deweloperów bo na ukraińskich Wikiźródłach jest identycznie? Czy można coś na to poradzić? To była przydatna funkcjonalność. Mahnka (dyskusja) 00:25, 15 sty 2023 (CET)

Tak, wygląda na bardziej ogólny problem, dotyczący wszystkich przestrzeni poza przestrzenią główną:

Uexpected "Page contents not supported in other languages" in non-article namespace

Dopisałem o ws. Na razie pozostaje czekać... może naprawią :) Zdzislaw (dyskusja) 13:20, 15 sty 2023 (CET)

@Mahnka Linki w innych przestrzeniach wróciły, na OZ ich brak w v2022 - wygląda na inny problem. Czy możesz potwierdzić, że przed kilkunastoma dniami w nowym vector-2022 linki językowe się wyświetlały? Zdzislaw (dyskusja) 18:36, 17 sty 2023 (CET)

@Zdzislaw na 95% widziałem te interwiki działające na OZ w v2022 w styczniu 2023, a na 100% w grudniu 2022. Mahnka (dyskusja) 07:59, 18 sty 2023 (CET)

"Ulepszenia" w zoomie skanów

Po ostatnich zmianach, ustawiony zoom jest automatycznie przeniesiony na inne, otwarte już okna, co nie pozwala na płynną pracę. Funkcja jest fatalna... wszystko mi się rozjeżdża :(( otwieram zazwyczaj 10 okien i pracuję na nich po kolei. A teraz, jak na pierwszym skanie czegoś nie dojrzę i powiększę fragment kilka razy, to potem 9 okien jest automatem powiększonych na maksa. I nie szkodzi, że potem 9 razy zmniejszam, system pamięta tylko pierwszy manewr — więc strach cośkolwiek powiększyć, już lepiej niech zostanie błąd :(( Wieralee (dyskusja) 21:38, 18 sty 2023 (CET)

Przez cały dzień sprawdzam zachowanie obrazków skanów w czasie pracy i... Na razie jestem na NIE co do powyższej zmiany.

Być może to rozwiązanie jest przydatne bardziej w cyklu: przepisywanie — podgląd — przepisywanie, bo pozwala na powrót do miejsca skanu tam, gdzie się go zostawiło. Teoretycznie, bo nie zawsze. Raczej w "świecie idealnym" lub przy "niedzielnych" edycjach to może komuś spasować.

Przykładowo: kończę pracę na stronie ze skanem przesuniętym max. do góry (czyli do połowy jego wielkości — to też już pewnie zostanie na zawsze!), zapisuję stronę. I kolejną, albo 10 kolejnych, otwieram i mam wszędzie zamiast powiększenia domyślnego — powiększenie ostatnie "robocze", które tu mi już tylko przeszkadza.

Nawet gdy ostatnio otwarte okno edycyjne będzie miało skan w powiększeniu domyślnym, to kolejne otwierane strony (powiedzmy dziesięć) już niekoniecznie... Wystarczy, że strony będą miały inne wymiary (wiem, że w książkach są zazwyczaj podobne) to każda strona wyświetli ten skan w innej pozycji.

Przy zmianie powiększenia strony to też działa na opak: z roboczego powiększenia strony w przeglądarce (u mnie 150%) przechodzę na 100%. Skan zmniejszył się w okienku, więc kolejną stronę (albo 10 kolejnych) mam po otwarciu takich: https://i.imgur.com/jn5o1Wq.png

W praktyce rozpoczęcie pracy u mnie wymaga zazwyczaj każdorazowego kliknięcia lupki, aby przywrócić powiększenie domyślne.

Bardziej obiektywnie patrząc, uważam, że ta zmiana powinna mieć opcję włączania i wyłączania (z naciskiem na to ostatnie), bo nie każdy będzie z niej zadowolony.

Seboloidus (dyskusja) 22:24, 18 sty 2023 (CET)

Nadchodzi nowa zmiana w Wektorze 2022

Cześć!

W przyszłym tygodniu (zaczynającym się 6 lutego), zespół Web z Wikimedia Foundation przeniesie część linków z menu bocznego ("sidebara") do nowego menu bocznego po drugiej stronie ekranu.

Dzięki temu korzystanie z linków widocznych w interfejsie będzie bardziej intuicyjne. Spis treści będzie wyświetlał się trochę wyżej na ekranie, ponieważ sidebar będzie krótszy. Ta zmiana będzie ważna głównie dla edytorów. Czytelnicy korzystają z sidebara o wiele rzadziej.

Dlaczego to zmieniamy

Dotychczas nie było rozróżnienia między linkami związanymi z całą wiki i tymi dotyczącymi pojedynczych stron. Do pierwszej grupy należą: strona główna, losowy tekst, czy ostatnie zmiany. Do drugiej z kolei należą: linkujące, zmiany w linkowanych, czy cytowanie tego artykułu. To pomieszanie było niezrozumiałe dla czytelników. Także nowi edytorzy nie wiedzieli, do czego służą poszczególne linki. Brak logicznego podziału utrudniał naturalne odkrywanie dostępnych narzędzi.

Ta zmiana jest również związana z uwagami na temat położenia spisu treści. Słyszeliśmy od edytorów używających Wektora 2022, że spis treści pojawiał się zbyt nisko, jako że był poniżej długiego sidebara. Teraz sidebar będzie krótszy i w ten sposób spis treści będzie wyżej. Ponadto ta zmiana zmniejszy ilość białej i pustej przestrzeni na ekranie.

Kompatybilność gadżetów

Być może techniczni wikiskrybi będą musieli zaktualizować jakieś gadżety czy skrypty. Niektóre z nich mogą stać się zbędne lub przestarzałe. Pomożemy skrybom, którzy będą chcieli utrzymać kompatybilność. Zachęcamy do przeczytania sekcji w naszej dokumentacji dotyczącej kompatybilności gadżetów.

Współpracujmy

• Zasubskrybuj nasz newsletter, żeby otrzymywać powiadomienia o nowościach.
• Podziel się pomysłami i zadawaj pytania na naszej stronie dyskusji.
• Twórz zadania na Prabricatorze i dodawaj tag Desktop Improvements (Vector 2022) lub napisz do nas, jeśli zauważysz jakiś błąd.
• Przetłumacz dokumentację na MediaWiki.org.

Dziękujemy! SGrabarczuk (WMF) (dyskusja) 21:55, 3 lut 2023 (CET)

Usterka w gadżecie związana z niedziałaniem opcji "Zmień układ na poziomy lub pionowy"

W Preferencjach w "Gadżetach" podmenu "Edycja stron" jest opcja: "Przeniesienie narzędzi z grupy Narzędzia proofread na podstawowy poziom rozszerzonego paska narzędzi". Jest ona domyślnie wyłączona. Zauważyłem, że przy włączeniu jej nie działa w toolbarze opcja "Zmień układ na poziomy lub pionowy".
Sprawdzane na skórce "Stary Wektor". Seboloidus (dyskusja) 17:30, 11 lut 2023 (CET)

tak, proof został mocno zmodyfikowany, zajmę się niebawem poprawieniem gadżetu. Zdzislaw (dyskusja) 18:47, 11 lut 2023 (CET)

@Seboloidus Opcje powinny już funkcjonować poprawnie. (wymagane poprawki przygotował Msz2001, za co mu serdecznie dziękuję) Zdzislaw (dyskusja) 23:15, 12 lut 2023 (CET)

@Zdzislaw, @Msz2001: Działa. Dziękuję! Seboloidus (dyskusja) 12:17, 13 lut 2023 (CET)

Kategoria:Pages transcluding nonexistent sections

Pewnie to już widzieliście. Pojawiło mi się przy transkluzji z parametrem "onlysection" w <pages ...>. Po zamianie na "fromsection" + "tosection" nie wystąpiło. Seboloidus (dyskusja) 16:13, 18 lut 2023 (CET)

Nowy filtr nadużyć

Jest nowy filtr nadużyć uruchomiony - uniemożliwia wpisywanie {{bwd|...}}. W razie problemów i uwag proszę pisać, najwyżej się wyłączy lub wymyśli coś innego. Szablon jest przestarzały i nie powinien już być stosowany. Warto by było też kiedyś stopniowo ponaprawiać te 3000+ jego dotychczasowych wywołań... Draco flavus (dyskusja) 19:11, 25 mar 2023 (CET)

Zmiana w widoku Wektora 2022 dla użytkowników niezalogowanych

Cześć wszystkim.

Jakiś czas temu wprowadziliśmy menu z narzędziami strony w widoku dla niezalogowanych użytkowników. Zalogowani widzieli to menu od stycznia 2023.

Menu to wprowadza podział między narzędziami związanymi z całą wiki i tymi związanymi z daną stroną. Do pierwszej grupy należą, na przykład, Strona główna i Losowy tekst. Z kolei do drugiej należą, na przykład, Linkujące, Zmiany w linkowanych i Informacje o tej stronie. Ponadto to menu zbiera wszystkie linki do narzędzi związanych z daną stroną. Poprzednio niektóre z tych linków były w sidebarze (po lewej) lub w menu Więcej (na górze, obok Historii). Celem zmiany jest ułatwienie nowym czytelnikom i edytorom zrozumienia, czym te linki są i do czego służą.

Menu może być przypięte do boku lub odpięte. Jest też przyczepione na określonej wysokości, więc nie rusza się mimo przewijania strony. Dodatkowo dla użytkowników zalogowanych przypięcie i odpięcie są stałe. Oznacza to, że zalogowani widzą menu tak, jak wybrali (przypięte lub odpięte) mimo odświeżania strony lub przechodzenia między stronami. Jednak w widoku użytkowników niezalogowanych menu nie ma tej cechy stałości. Mamy nadzieję, że w przyszłości to się zmieni.

Wprowadzenie tej zmiany ma też wpływ na spis treści, który jest widoczny trochę wyżej na ekranie. Obecnie użytkownicy niezalogowani muszą więcej przewijać, żeby do niego dotrzeć. Była to jedna z uwag, jakie słyszeliśmy w ciągu ostatnich dni i mamy nadzieję, że nowa zmiana rozwiązuje ten problem.

Pracujmy razem

• Zasubskrybuj nasz newsletter, by otrzymywać powiadomienia o nowościach.
• Podziel się pomysłami i zadawaj pytania na stronie dyskusji.
• Twórz zadania na Phabricatorze i dodawaj tag Desktop Improvements (Vector 2022) lub pisz do nas, jeżeli zauważysz buga.
• Tłumacz dokumentację na MediaWiki.org.

Dziękujemy! SGrabarczuk (WMF) (dyskusja) 03:15, 8 kwi 2023 (CEST)

Zablokowane rozszerzenie od wykresów

Wczoraj Wikimedia Foundation poinformowała, że w celu ochrony bezpieczeństwa użytkowników rozszerzenie Graph zostało wyłączone. Oznacza to, że na stronach, które zawierały wykresy, pojawi się tylko niewielki pusty obszar. Aby pomóc czytelnikom zrozumieć, co się dzieje, społeczność może teraz zdefiniować komunikat do wyświetlenia w każdym miejscu, gdzie powinien znaleźć się wykres. Wiadomość tę można zdefiniować lokalnie na każdej wiki na stronie MediaWiki:Graph-disabled. Personel Wikimedia Foundation analizuje możliwości rozwiązania tego problemu. Aby śledzić nowe informacje na ten temat, odwiedź zadanie na Phabricatorze: T334940.

--MediaWiki message delivery (dyskusja) 19:36, 19 kwi 2023 (CEST)

Pietraszek mi się pietrasi... coś się sypie

Zerknijcie proszę na Przewodnik praktyczny dla użytku maszynistów/całość - w poszczególnych rozdziałach wszystko działa, lecz gdy scalę wszystko razem to powyżej strony 620 się sypie na solidnie. Jak to naprawić? Jacek Fink-Finowicki (dyskusja) 22:13, 1 lip 2023 (CEST)

@Jacek Fink-Finowicki: Dwie sprawy. Robimy raczej Przewodnik praktyczny dla użytku maszynistów/całość – to jest quasi-standard teraz. Więc raczej (póki nie ma jakichś linków) sugeruję zmianę nazwy. Drugi problem – ten podstawowy, i dla Ciebie ważniejszy: wszedłeś w tzw. limit transkluzji, strona jest zbyt duża. Jeśli chcesz, mogę Ci prawdopodobnie ją przerobić na działającą, choć trochę technicznie gorszą – będzie wymagała okresowego odświeżenia przez bota, ale jeśli jest tekst gotowych, to OK. Draco flavus (dyskusja) 23:05, 1 lip 2023 (CEST)

Zastanawiam się, czy nie lepiej zrobić podziału na dwa. Np.: "treść" oraz "dodatki" bo wówczas podzieli się z grubsza na pół. Nie wiem jak wówczas będą działać wszelkie narzędzia typu eksportu treści itd. Po prostu nie mam doświadczenia i proszę o rady praktyczne. Jacek Fink-Finowicki (dyskusja) 05:02, 3 lip 2023 (CEST)

PS. A czy /Przedmowa , /Wstęp itd... też z małej? Jacek Fink-Finowicki (dyskusja) 05:05, 3 lip 2023 (CEST)

Przedmowa, Wstęp – wielkimi literami (= tak jak w tekście, tak się tytułuje rozdziały), całość robimy małą – może po to by zaznaczyć, że to nasza strona (specjalnie utworzona, niejako obok zwykłego podziału). Strony całość robimy tradycyjnie, by czegoś móc szukać w tekście. Czy sztuczny podział na dwie części ma sens? Nie wiem, ja bym raczej szedł w kierunku tej pół-statycznej strony całość odświeżanej przez bota, jeśli chcesz, to zrobię ją. Draco flavus (dyskusja) 17:05, 3 lip 2023 (CEST)

Jeszcze jedna drobna uwaga, do wstawiania erraty używamy szablonu {{errata}} zamiast {{kor}} – efekt jest zbliżony wprawdzie, ale podkreślony jest oficjalny charakter poprawki. Draco flavus (dyskusja) 17:17, 3 lip 2023 (CEST)

Erraty jednak już nie transkludujemy w tekście jako osobnego rozdziału (po prostu jest już uwzględniony). Na stronie całości zazwyczaj nie dawaliśmy też spisu treści. Być może w tym wypadku taki spis treści możemy dać - jeśli przepisany spis przez ciebie spis treści nie ma funkcji odnośników wewnątrz Draco flavus (dyskusja) 22:23, 3 lip 2023 (CEST)

No i brakuje wreszcie strony głównej Przewodnik praktyczny dla użytku maszynistów – robiliśmy ją właśnie jako taki punkt ze spisem treści do poszczególnych rozdziałów. W miarę możności spis był transkludowany, jeśli to niemożliwe (bo spisu nie ma), to tworzony przez nas. Strona /całość to tylko taka pomocnicza strona do szukania czegoś itp. – w gruncie rzeczy zbędna teoretycznie. Draco flavus (dyskusja) 22:29, 3 lip 2023 (CEST)

Okładek nie dajemy na podstronach, tylko na głównej i /całość Draco flavus (dyskusja) 22:31, 3 lip 2023 (CEST)

Tej strony głównej na razie celowo nie ma, bo dopracowuję spis treści - niby mam już gotowy, ale jeszcze coś muszę poprawić i przy chwilowym natłoku roboty nie mam na to chwili.

Dzięki za pozostałe uwagi - dokonam odpowiednich korekt zgonie ze wskazówkami.

Odnośnie podziału - w ramach czytania treści zauważyłem, że podział na treść i dodatki będzie w miarę naturalny i nie będzie utrudniał przeszukiwania. Są to bowiem części dość wyraźnie rozdzielne - zaleta tego będzie też taka, że po prostu każda część będzie lżejsza. Jacek Fink-Finowicki (dyskusja) 23:59, 5 lip 2023 (CEST)

@Jacek Fink-Finowicki: Widzę, że włożyłeś dużo pracy i serca w tę książkę, także wszystko to tylko miękkie sugestie. Co do całości zrobiłem taką stronę na próbę (technicznie jest to "szkielet" - szkielet i właściwa strona wynik. Są tam jeszcze na pewno drobne szczegóły do poprawy (np. dodatnie kategorii). Natomiast jestem raczej za taką całą całością. Po prostu wydaje mi się, że najlepiej, gdy układ, podział tekstu u nas jest technicznie wszędzie taki sam. Najłatwiej drugiemu skrybie to przejrzeć i przerobić w razie potrzeby. Ciągle też mam nadzieję, że na przykład limit post-expand include size (w który "wdepnąłeś") za jakiś czas będzie podniesiony. Wtedy raczej się nie pozbędziemy tych "połówek", które utworzysz (bo będą już "zasiedziałe"). Co do spisu treści: jeśli "martwy" - tj. bez linków - może mieć rację bytu na stronie /całość, nie nadaje się raczej na stronę główną. Na odwrót jeśli będzie "żywy" - to jest z linkami, jest bardzo pożądany na stronie głównej ale technicznie nie nadaje się na stronę /całość. Są triki może - ale to dużo pracy. Piszę to, ponieważ z jednej strony jest teraz spis treści na stronie /całość ("martwy"), z drugiej strony dopracowujesz spis treści pod kątem głównej, jak piszesz... Draco flavus (dyskusja) 07:53, 6 lip 2023 (CEST)

@Draco flavus - rzuć proszę okiem czasem. Zasadniczo zrobiłem wedle Twoich sugestii. Jeszcze dorzucę do strony głównej spis treści dodatków (teraz brak) oraz zaktualizuję spis treści na indeksie, bo część jest linkowalny, zaś część nie (powstawał sukcesywnie).

Do tego spis treści oraz erratę wywaliłem z "całości" - w razie czego pozostaną jako osobne rozdziały oraz w indeksach.

Z innej beczki - zastanawiam się nad tym czy w całości skoro i tak się generuje treść ze stron, to czy tam nie poscalać tabel, które w druku ciągną się przez kilka stron (temat dotyczy zasadniczo dodatków. Tyle tylko, że chyba powinno się zrobić po tym gdy stosowne strony indeksu zostaną zazielenione. Jacek Fink-Finowicki (dyskusja) 21:33, 15 lip 2023 (CEST)

@Jacek Fink-FinowickiHej, przejrzę, dokładnie. Na szybko mi się rzuciło w oczy, że używasz pola Pochodzenie -- jego używamy w zbiorach np. różnych autorów i w przypadkach wstępów (inny autor, coś, co nie należy do reszty). Pole Pochodzenie powinno zostać puste, link, powinien być w Tytuł. Długie tabele scalamy trikiem, i raczej ich nie przenoś do "szkieletu". Trik polega na umieszczaniu końca tabeli w stopce i początku tabeli w nagłówku. Zrobiłem Ci wzór na str. 542 i 543 oraz 544. Efekt możesz zobaczyć na części Tablice. W razie czego, pytaj. Draco flavus (dyskusja) 14:13, 16 lip 2023 (CEST)

I jeszcze dodatek, 1. na każdej z podstron (i stronie głównej - tej jeszcze nie ruszałem) licencja (mixPD...), 2. kategoria (klucz sortowania wg numeru rozdziału I = P01, II = P02 itd, itp., 3. Lista autorów jest konieczna/wskazana, gdy jest więcej autorów niż jeden, 4. pochodzenie i tytuł -- patrz wyżej. Stronę główną zrobimy, gdy się wyklaruje, jak chcesz ją utworzyć (transkludować spis z przestrzeni Strona:, czy tworzyć na stronie (raczej tak obszerne nie są praktykowane w ten sposób). Zrobiłem na razie Przedmowę, Wstęp, Rozdział I Draco flavus (dyskusja) 14:46, 16 lip 2023 (CEST)

5. W rozdziałach, gdzie występują przypisy dajemy na koniec {{Przypisy}} - wygląda nieco porządniej.

Zrobiłem (jak sobie wyobrażam) do trzeciego rozdziału. (Zostawiam Tobie a. pozostałe rozdziały, b. te długie tabele - wzór masz, c. dopracowanie spisu treści. Draco flavus (dyskusja) 20:34, 31 lip 2023 (CEST)

Poprawki na ręcznie pisanych tekstach

Uwierzytelniam Dwóch Frontignacych. Przepisane z ręcznie napisanego egzemplarza teatralnego. Wszystko w miarę w porządku aż do strony 120, gdzie ręcznie skreślono słowo "siostrzenicę", zastąpione "narzeczoną". Na przepisanej stronie użyto szablonu korekta, za poprawne uznając "narzeczoną". Ma to sens zgodnie z treścią. Ale zdałem sobie sprawę, że w tekście wcześniej było mnóstwo innych podobnych poprawek, przy których, za osobą przepisującą i korygującą (@Nawider, @Gniewko, syn rybaka:), uznawałem za nadrzędną oryginalną wersję, ignorując poprawkę ołówkiem – tylko, że tam to chyba były bardziej poprawki stylistyczne. Teraz zastanawiam się nad ujednoliceniem podejścia.

I tu moje pytanie: jak do tego typu zjawisk podchodzić? Uznać wszystkie poprawki za obowiązującą wersję tekstu (nawet jeżeli byłaby w sprzeczności z np. drukowanymi egzemplarzami)? Zaznaczyć je jako erratę (co wydaje mi się lepszym szablonem niż korekta, bo poprawka pochodzi od tłumacza/wydawcy, a nie od nas)? Brać zawsze oryginalną wersję? Czy może to zależy od przypadku? Lord Ya (dyskusja) 11:02, 10 wrz 2023 (CEST)

W przypadku tego tekstu wydaje mi się, że faktycznie używanie szablonu errata do tych korekt byłoby dobrym rozwiązaniem, odróżniło by "nasze" korekty od tych naniesionych na skanach. A skoro to tekst ręcznie przepisany, a nie drukowane wydanie, to można uznać że poprawki pochodzą od wydawcy. Joanna Le (dyskusja) 12:21, 10 wrz 2023 (CEST)

• Errata wydaje się lepsza. Wieralee (dyskusja) 16:31, 10 wrz 2023 (CEST)
• też jestem za erratą Nawider (dyskusja) 21:21, 10 wrz 2023 (CEST)

Konta tymczasowe dla niezarejestrowanych edytorów

Przeczytaj w innym języku • Pomóż przetłumaczyć na Twój język • Poinformuj innych użytkowników o tych zmianach

W przyszłym roku niezarejestrowani edytorzy zaczną korzystać z kont tymczasowych.

W 2024 edytorzy, którzy nie zarejestrowali konta, automatycznie zaczną korzystać z kont tymczasowych. Edytorzy ci są czasami nazywani "edytorami IP" lub po prostu "IP", ponieważ adres IP jest wyświetlany w historii strony.

Zespół produktowy ds. zaufania i bezpieczeństwa przedstawił na Wikimanii prezentację na temat tej zmiany. Można ją obejrzeć na YouTube.

Więcej informacji można znaleźć na stronie Edytowanie IP: Zwiększanie prywatności i ograniczanie nadużyć.

SGrabarczuk (WMF) (dyskusja) 04:05, 30 wrz 2023 (CEST)

Problem ze zdjęciami z Wikidata w szablonie Autorinfo

Znalazłem 3 strony autorów z brakiem zdjęć: Autor:Elizabeth Gaskell, Autor:John Bunyan, Autor:Joséphin Péladan. Może to być problem z pobieraniem zdjęć z Wikidata do szablonu {{Autorinfo}} w przypadku dostępnych kilku zdjęć na WD. Seboloidus (dyskusja) 23:34, 19 paź 2023 (CEST)

Tak pewnie tak jest, wywołanie {{#invoke:wikibase|prop|property=P18}} na którejś z tych stron daje ciąg nazw plików ilustrujących daną osobę oddzielonych przecinkiem. Mnie brakuje wiedzy, połatać to pewnie mogę (doskonalej lub mniej), ale dobrze by było wiedzieć, czy taka powinna być odpowiedź z Wikidata? Czy w innych miejscach kodu nie będzie to przeszkadzać. @Ankry: @Zdzislaw: Draco flavus (dyskusja) 11:05, 22 paź 2023 (CEST)

Połatałem, jak umiałem. Jeśli coś się rzuca w oczy, proszę o informację Draco flavus (dyskusja) 13:20, 22 paź 2023 (CEST)