Wikipédia:Kocsmafal (műszaki)/Archív122

A Wikipédiából, a szabad enciklopédiából

Elavult segédfüggvények eltávolítva

Sziasztok! Vettem a bátorságot, és teljesen töröltem három JavaScript-segédfüggvényt (addLoadEvent, getCookie és setCookie). Ezek a függvények évek óta elavultnak vannak jelölve, a három függvény együttvéve mintegy másfél tucatnyi lapon szerepel a magyar Wikipédián, többségében tesztnek tűnő és/vagy rég nem látott szerkesztőkhöz tartozó allapokon. Ha valaki rendellenességet tapasztal (és nem tudja magának megoldani), annak természetesen segítek a javításban. A keresési eredmények alapján potenciálisan érintett lehet az aktív szerkesztőtársak közül Gaja, grin és Máté, mindhármójuknál a monobook.js allap a problémás (bár egyik esetben sem ez az első vagy legdurvább hiba…). – Tacsipacsi vita 2019. április 16., 19:55 (CEST)

Processzorok

Sziasztok! Remélem sok informatikus is olvassa ezt a lapot! :) A Q1065726 és a Q725524 ugyanaz lenne? B.Zsolt vita 2019. április 18., 19:26 (CEST)

Az első az Intel 80188 (egy változata az Intel 80186-nak), a második az Intel 80186. Vépi vita 2019. április 18., 19:32 (CEST)

A hibás címkéket javítottam. Bencemac A Holtak Szószólója 2019. április 18., 19:48 (CEST)

Köszönöm! – B.Zsolt vita 2019. április 18., 19:57 (CEST)

Elég sok processzor cikkből hiányzik az infobox, de más területeken is vannak gondok. Ha valakinek van kedve, nézegetheti a processzoros cikkeket. :) – B.Zsolt vita 2019. április 18., 21:42 (CEST)

Román név

Valaki meg tudja mondani hogy ebben a cikkben a térképen miért ez szerepel: {{{román név}}}? – XXLVenom999 vita 2019. április 18., 20:22 (CEST)

Nem volt román név paraméter. – B.Zsolt vita 2019. április 18., 20:56 (CEST)

Ilyenkor el lehet gondolkodni, hogy vajon tényleg a szócikk-e a hibás, vagy esetleg a sablon tesz kötelezővé teljesen feleslegesen egy paramétert. A szócikk címéből alapesetben tökéletesen ki lehet következtetni, hogy hogyan akarjuk megnevezni az adott települést, használjuk bár a magyar vagy a román nevet, csak nagyon ritka esetben (ha egyáltalán) van ténylegesen szükség a név paraméterként való megadására a szócikknévtérben. – Tacsipacsi vita 2019. április 18., 22:54 (CEST)

Nézettségi statisztika saját MediaWikibe

Sziasztok! Van egy saját MediaWiki wikim, amibe szeretném betenni a nézettségi statisztikát. Hogyan tudom ezt megcsinálni? Mit és hová kell írnom? A segítséget előre is köszönöm. – Dodi123 vita 2019. április 16., 12:13 (CEST)

mw:Extension:Google Analytics Integration a legegyszerűbb megoldás. --Tgrvita 2019. április 16., 19:09 (CEST)

@Tgr: Köszönöm. Megpróbálom. Ha működik, ez is jó lesz. Bár én az itteni laptörténetekben használatos nézettségi statisztikára gondoltam. Annak a beillesztése bonyolultabb? – Dodi123 vita 2019. április 16., 19:27 (CEST)

Szerintem a fejlesztőiben fel sem merült ennek az igénynek a lehetősége. A GitHubon lévő leírás alapján telepítettem, és tökéletesen működik is – a Wikimédia-oldalak statisztikáival. A saját wikimével már nem. (Egyébként a MediaWikiben már nincs beépített nézettségi statisztika? A Wikipédián már jó ideje nem működik, de attól még saját wikiben nem kizárt, hogy használható.) – Tacsipacsi vita 2019. április 16., 19:38 (CEST)
A régi beépített statisztika a HitCounters kiterjesztésbe költözött, de nem sokat tud/tudott. --Tgrvita 2019. április 20., 21:03 (CEST)

Köszönöm. Akkor marad a Google Analytics. Az általam használt MediaWikiben (a legfrissebb stabil változat) nincs beépített nézettségi statisztika. – Dodi123 vita 2019. április 16., 19:59 (CEST)

Köszönöm a segítséget. A Google Analytics működik, bár eléggé "fapados". Csak összesített nézettségi adatot ad, nem naponkéntit, és így grafikon sincs benne. Nekem jobban tetszik ami itt a Wikipédián van. – Dodi123 vita 2019. április 18., 21:43 (CEST)

[1] --Tgrvita 2019. április 20., 21:03 (CEST)

Ez hasznos. Kérdés, hogy hogyan tudom hozzáilleszteni a wikihez. Lesz mivel molyolnom :) – Dodi123 vita 2019. április 21., 09:23 (CEST)

Azonnali törlésre váró lapok

Miért jelez már megint eggyel több tételt a kategória az FV-n, mint amennyi ténylegesen van benne? Napok óta ezt csinálja, most pl. 0 darab van benne, a jelzés viszont 1. Régebben is rakoncátlankodott, de aztán nagy sokára megjavították. – Pagony foxhole 2019. április 21., 18:43 (CEST)

Sablon:Ország infobox

Az ország infobox-ban jó lenne becsukni a tagság részt, mert iszonyú hosszú listák jelennek meg, és a box jelentősen megnyúlik, alatta meg csúszik minden. Én próbálkoztam a becsukásával, nem sok eredménnyel. – M. V. 2019. április 21., 20:50 (CEST)

Nézd majd meg, hogy így gondoltad-e. – balint36 🚌 buszmegálló 2019. április 21., 23:00 (CEST)

Szuper. Kösz. – M. V. 2019. április 22., 05:15 (CEST)

2019. április 23., 21:07 (CEST)

infobox hiba

A {{zenés színmű infobox}}(?) infoboxban néha megjelenik egy furcsa hiba az eredeti nyelv paraméternél. Az egyik aposztróf külön sorba kerül, pl.: itt. De máshol meg jó... Aki sejti, hogy mi lehet a gond, az kérem javítsa vagy jelezze, én nem találom az okát. – B.Zsolt vita 2019. április 23., 22:13 (CEST)

Nem csak az eredeti nyelvnél fordult elő, de most már sehol se kéne ilyen hibának lenni. – balint36 🚌 buszmegálló 2019. április 23., 22:45 (CEST)

2019. április 30., 00:28 (CEST)

Nézettségi statisztika

Mindig van valami jó, most meg a laptörténet nézettségi statisztikája nem akar bejönni. – Pagony foxhole 2019. május 1., 18:11 (CEST)

Szösszenet az azonnal látható ellenőrizetlen változtatásokhoz

Habár a vonatkozó szakasz úgy látom már elarchiválódott, azért megjegyzésnek hagynék itt egy apróságot azok számára akik továbbra is pártolják hogy kikapcsolva maradjon az a fukció, miszerint az ellenőrizetlen változtatások nem látszanak az olvasóknak. Épp most vontam vissza egy ökörséget járőrözés során, amit egy anon írt be tegnap reggel 09:35-kor a Bosszúállók (film, 2012) (vitalap | történet | hivatk | log | dellog | szerkesztés | figyel | lapinfo | töröl | levéd) cikkbe. Az egy dolog hogy apróságról van szó, nem eget rengető vandalizmusól, de ezzel együtt is szeretnék rámutatni, hogy a Topviews Analysis statisztikája szerint ez a lap tegnap a 32. legnézettebb cikk volt, 1109 megtekintéssel. Ma 20:40-kor vontam vissza, tehát ma is majdnem egy teljes napon át látható volt benne (habár mai statisztika még nincs, a téma aktuális népszerűsége miatt, valamint ünnepnap lévén még nyugodtan legalább ugyanennyi megtekintést fel lehet számolni szerintem a mai napra is – de számoljunk mondjuk a két napra kerek 2000 össz megtekintéssel). Ha csak minden negyedik ember tekert le a cikkben a stáblistáig (ami azért szerintem teljesen életszerű, még lehet kevés is), akkor is 500 ember látta ezt a humoros beírást. Most 500 ember fogja ennyivel "komolyabban" venni a Wikipédiát. Csak gondoltam itt hagyom ezt. – XXLVenom999 vita 2019. május 1., 20:52 (CEST)

Jogosultsag beallitas - UserAdmin

Üdv Mindenkinek.

Előre is koszonom az epito jellegu valaszokat. Most bocsanatot kerek ha nem jo helyre irok. Wikipedia engine-t telepitettuk a cgenel ahol dolgozom, MediaWiki 1.31 Egy kozponti oldalt szeretnenk csinalni, amire a mediawiki tokeletes lenne. Tobb temakorben, tobb szerkeszto. Viszont vannak olyan temakorok, postok amiket csak adott felhasznalok szerkeszthetnek es nagyon fontos hogy csak ok olvashatjak ezeket. Be lehet allitani a mediawiki-nek a lathatosagat, jogosultsagat ha igen hogyan?

Userek kezeleset sem teljesen ertem. UserAdmin ha jol ertelmeztem 1.31-en nem mukodik mar...?

Ati73 vita 2019. április 26., 11:16 (CEST)

@Ati73: Teljesen jó helyre írtál. A MediaWiki láthatóságát be lehet állítani, azonban egyes lapokét nem nagyon – lásd mw:Manual:Preventing access#Restrict viewing of certain specific pages. Egyébként ha nem akarnál laponkénti láthatóságot, a hitelesítésre – a valóban igen döcögős UserAdmin helyett – tudnám ajánlani az LDAP Authentication kiterjesztést: ez többé-kevésbé működik a legfrissebb MediaWikivel is, és a cég LDAP-adatbázisával lehet összekötni. (Ha van a cégnél Windows-tartomány, akkor szinte biztosan van LDAP is.) Másik weboldalszoftver keresésekor is érdemes lehet szem előtt tartani az LDAP-kompatibilitást (már ha van a cégnél LDAP, és a weboldal használói nagyjából egybeesnek az LDAP-felhasználókkal): ebben az esetben egyáltalán nem kell foglalkozni a weboldalon a felhasználók kezelésével, eggyel kevesebb felhasználónév/jelszó párost kell megjegyezniük a munkatársaknak, sőt egy tisztességesen elkészített LDAP-támogatás esetén akár közvetlenül szervezeti egységekhez (LDAP-könyvtárakhoz) lehet kapcsolni az egyes oldalak láthatóságát. – Tacsipacsi vita 2019. április 26., 22:48 (CEST)

Ha hobbiszintű hozzáféréskezelést akarsz, az AccessControl pl. elvileg tud olyat, és jól karbantartottnak tűnik (de nem próbáltam). Ha business-critical feltétel, hogy jogosulatlanul ne tudjanak a felhasználók olvasni lapokat, akkor elkerülném nagy ívben a MediaWikit. Amúgy az #mwstake-extensions Mátrix csatornán a legesélyesebb olyan embereket találni, akik sokat használtak MediaWikit céges környezetben. --Tgrvita 2019. április 27., 08:49 (CEST)

Köszi. Megnézem, remelem segiteni fog a leírtak. Írtad, h elkerülnéd a MediaWikit Business-critical feltételkor. Mit használnál helyette? Ati73 vita 2019. április 29., 08:31 (CEST)

Foswiki? Sose próbáltam, de elvileg az a második legnagyobb szabad forrású wiki szoftver, és tud részletes jogosultságokat kezelni. --Tgrvita 2019. április 29., 08:33 (CEST)

Köszi megnezem és azt is tud magyarul v sem, mert sajnos elvarás. Ati73 vita 2019. április 29., 08:37 (CEST)

Esetleg több párhuzamos MediaWiki-telepítés, amikhez különböző csoportok kapnak hozzáférést? Samat üzenetrögzítő 2019. április 29., 09:07 (CEST)

Samat, igen ezen mar gondolkodtam en is. (Hogy kell itt valaszban megjelolni valakit?) Ati73 vita 2019. április 29., 09:32 (CEST)

@Ati73: így, ahogyan most én téged pingellek, a ping sablonnal: {{ping|a szerkesztő neve}}. A sablon az értesítő rendszer Echo nevű kiterjesztését használja, egyszerre hét usert tudsz vele pingelni (| elválasztójelekkel), ha többet szeretnél, akkor több sablonba kell beilleszteni, illetve az aláírásodnak (~~~~) is benne kell lenni a hozzászólásban, hogy értesítést küldjön. --Pallertithe cave of Caerbannog 2019. május 5., 07:25 (CEST)
2019. május 6., 18:27 (CEST)

Rosszul működik az Azonnali törlésre váró lapok kategória

Pár hete beírtam már, de az archívumban sem találom, úgy elsüllyedt. Szóval előbb 1 törölni való tételt tartalmazott, holott egy sem volt benne, újabban meg már 2-t tartalmaz (holott egy sincs benne). Nem új probléma ez, egyszer már megjavították. Jó lenne most is csinálni valamit, hogy az adminok ne kattintgassanak fölöslegesen. – Pagony foxhole 2019. április 30., 21:19 (CEST)

Pontosítanék, mert nem biztos, hogy mindenkinek leesik: nem ott van a hiba, hanem az FV-n az egyéb hasznos hivatkozások dobozban és nem a kategória működik rosszul, hanem a dobozban az az eszköz ami zárójelbe téve hivatott jelezni az FV-n, hogy mennyi azonnali törlésre váró lap van. --Pallertithe cave of Caerbannog 2019. április 30., 23:05 (CEST)
Itt található a hibajelenség (aztán, hogy itt kell -e megjavítani, azt nem tudom): MediaWiki:Recentchangestext. --Pallertithe cave of Caerbannog 2019. április 30., 23:08 (CEST)
Infóként, hátha közelebb jut a megoldáshoz, aki foglalkozna vele: a következő elemzőfüggvény jeleníti meg az azonnal törlendőre jelölt lapok számát: [[:Kategória:Azonnali törlésre váró lapok|azonnali ({{#expr:{{PAGESINCATEGORY:Azonnali törlésre váró lapok}}-{{PAGESINCATEGORY:Azonnali törlésre váró lapok|subcats}}}})]], ennek az eredmény ebben a pillanatban: azonnali (1). Ez így egyrészről jónak tűnik, másrészről a környezetében semmi olyan új szerkesztést, változtatást nem látok, ami indokolná, hogy miért mutat rossz eredményt. --Pallertithe cave of Caerbannog 2019. április 30., 23:20 (CEST)
Valamiért – az alkategóriákkal együtt – összesen nyolc lapot számol a {{PAGESINCATEGORY:Azonnali törlésre váró lapok}} és ebből vonja le az elemzőfüggvény a hat darab alkategóriát, innen jön a szumma kettő, de arra egyelőre nem találok magyarázatot, hogy miért nyolcat számol. --Pallertithe cave of Caerbannog 2019. április 30., 23:37 (CEST)

Elvileg a {{PAGESINCATEGORY:Azonnali törlésre váró lapok|pages}} kiadná az azonnali törlésre váró lapok számát, de az se jó, mert az az eredménye, hogy 1. Malatinszky vita 2019. április 30., 23:59 (CEST)

@Malatinszky: Igen ezt én is próbáltam már, Bináris tette be annak idején így az expr parserral – valami oka biztosan van, hogy így oldotta meg. --Pallertithe cave of Caerbannog 2019. május 1., 00:13 (CEST)

@Pallerti: Kösz, eredetileg én is ezt írtam be (mármint a régi panaszomba), de úgy gondoltam, most szakszerűbb leszek, hátha azt nem értették a techguruk. Hát nem lettem. :) – Pagony foxhole 2019. május 1., 00:18 (CEST)

 megjegyzés A Phabricatoron több jegyet is találtam a PAGESINCAT-tal összefüggésben az „Incorrect count in category” témakörben, azonban eddig csak olyan következtetéseket láttam, hogy nagyon nagy, sokelemű (több száz, ezer elemet tartalmazó) kategóriáknál nem megbízható. A mi azonnali kategóriánk gyakorlatilag üres a maga hat állandó és egy-két hozzáadódó elemével, ráadásul jónéhány kategóriát ellenőriztem itt a huwikin, amelyek mindegyikében pontos, azokban is, amik több tucat elemet tartalmaznak – ebben az egy katban nem működik. --Pallertithe cave of Caerbannog 2019. május 1., 05:22 (CEST)

Információt csak azoknak nyújt, akik törlünk, mi meg automatikusan nézzük ezt a három-négy törlős oldalt. Lehet, hogy vegyük ki? – Burumbátor Súgd ide! 2019. május 1., 08:29 (CEST)

@Burumbátor: Én meghagynám, mert egészen biztos, hogy valamilyen triviális a probléma és láthatóan kifejezetten az adott kategóriában nem működik csak, ugyanoda több kategóriatartalom számoló is be van illesztve és mind hiba nélkül megy – kiszeretném deríteni, hogy mi okozza a problémát és el szeretném hárítani. Ilyen kevés elemű kategóriákban nem szokott problémás lenni. Mivel konstansan kettővel többet mutat ezért most elég suttyó módszert alkalmazva beletettem, hogy vonjon le kettőt a végösszegből – ez nyilvánvalóan nem megoldás, de arra az átmeneti időre, amíg meg nem oldjuk, addig nem bántja a szemet az FV-n (feltéve, hogy addig is nem módosul valamilyen okból ez a titokzatos plusz kettő, mert akkor nyilván megint nem lesz jó). Ha valaki időközben esetleg megoldaná, akkor vonja vissza a szerkesztésemet nyugodtan, én azért addig is agyalok a dolgon. --Pallertithe cave of Caerbannog 2019. május 1., 13:28 (CEST)

@Pallerti: lehet, hogy most kettőt mutat, de heteken át egyet mutatott, mostanában emelkedett. – Burumbátor Súgd ide! 2019. május 1., 14:21 (CEST)

A 2018. májusi újraszámolás során javítottuk ideiglenesen a problémát, T170737 és T18036 lehet a végleges megoldás. Utóbbi a holnap–holnapután települő 1.34.0-wmf.3 verzióval érkezik; „small categories (up to 100 pages) should be once again recounted whenever a page is removed from them”. Bencemac A Holtak Szószólója 2019. május 1., 17:30 (CEST)

Hurrá! – Pagony foxhole 2019. május 1., 18:05 (CEST)

 megjegyzés Az 1.34.0-wmf.3 verzióval nem oldódott meg, állítólag ez lett volna a mentőöv, bár szerintem ez nem az ilyen méretű kategóriák problémáját javítja. A roadmap szerint a 1.34.0-wmf.4 május 9-én jön majd, de én abban nem látok semmi olyasféle javítást, ami ilyen irányú lenne, így azt gondoltam, hogy arra nem érdemes várnunk. Úgy döntöttem, hogy megpróbálok egy nagyon egyszerű módszert: rámruházott hatalmamnál fogva kikapcsoltam a 67-es szűrőt, töröltem a kategóriát, nyomtam egy purge-öt és aztán visszaállítottam a kategóriát az utolsó állapotára és egyből megjavult. Túl gyakran szerencsére nem jelentkezik ez a hiba (talán egy év alatt ez volt a második ilyen eset), most már tudjuk, hogy így könnyedén javítható. --Pallertithe cave of Caerbannog 2019. május 8., 04:18 (CEST)

Nagyszerű, köszönöm! – Pagony foxhole 2019. május 8., 10:41 (CEST)

Kereső a Segítség oldalon

Üdv! Látom, más wikik Segítség oldalán van szövegdoboz kereséshez a Segítségben, viszont a magyar wiki Segítség oldalán nincs. Vajon nem lenne jó, ha lenne? Amator linguarum vita 2019. május 7., 18:25 (CEST)

Olvasott-olvasatlan keveredés

Sziasztok! Chrome 74.0.3729.131 (Hivatalos verzió) (64 bites) -t használok PC-n, és Chrome minit mobilon... mindekettőn zavar van a Figyelőlistámon... összevissza mutatja, hogy mit láttam és mit nem (azaz mi vastagított és mi nem), ugyanez a laptörikben... már egy ideje fennáll, de gondoltam biztos valami frissítés, de most már kezd bosszantó lenni... Esetleg más is tapasztalt már ilyet? Fauvirt vita 2019. május 4., 12:43 (CEST)

Phab:T218511, dolgoznak az ügyön. Bencemac A Holtak Szószólója 2019. május 4., 13:09 (CEST)
Ah, ez jó hír, köszönöm, @Bencemac! Fauvirt vita 2019. május 4., 13:17 (CEST)

Most akartam szólni emiatt. Nálam úgy jelentkezik, hogy

  • megjelölöm olvasottként a Figyelőlistát
  • megszűnik a vastagítás minden cikken
  • a Figyelőlista újbóli behívásakor megint vastagítja azokat, amikről korábban a vastagítás eltűnt
  • tehát a "megjelöl olvasottként" funkció megint hatástalan

Érdekes, hogy ilyen szorgalmasak a fejlesztők, hogy mindig új hibákkal állnak elő. Ez jobb, mintha lustálkodnának. Vigyor misibacsi*üzenet 2019. május 4., 20:00 (CEST)

Ne tételezz fel szándékosságot! Minden módosítás (még a legártatlanabb is) okozhat ott hibát, ahol nem is várnád. Ilyen a programozás! Wikizoli vita 2019. május 4., 20:04 (CEST)

Én nem tételeztem fel szándékosságot. Te ne tételezz fel rosszindulatot. Vigyor misibacsi*üzenet 2019. május 5., 07:09 (CEST)

Operánál is ez volt, de úgy tűnik, már helyreállt. Ogodej vitalap 2019. május 4., 20:57 (CEST)

Nekem úgy tűnik, hogy eltűnt a hiba, most már megmarad az "olvasottnak jelölés". misibacsi*üzenet 2019. május 9., 17:33 (CEST)

Én továbbra is tapasztalom. – Regasterios vita 2019. május 9., 20:46 (CEST)

Multilingual Shared Templates and Modules

Hello hu-wiki community! (Segíts lefordítani a saját nyelvedre)

I recently organized a project to share templates and modules between wikis. It allows modules and templates to be “language-neutral”, and store all text translations on Commons. This means that it is enough to copy/paste a template without any changes, and update the translations separately. If someone fixes a bug or adds a new feature in the original module, you can copy/paste it again without any translation work. My bot DiBabelYurikBot can help with copying. This way users can spend more time on content, and less time on updating and copying templates. Please see project page for details and ask questions on talk page.

P.S. I am currently running for the Wikimedia board, focusing on content and support of multi-language communities. If you liked my projects like maps, graphs, or this one, I will be happy to receive your support. (any registered user group can vote). Thank you! --Yurik (🗨️) 2019. május 11., 08:17 (CEST)
2019. május 14., 02:48 (CEST) 2019. május 20., 15:04 (CEST)

Vitalap személyre szabása

Szép napot mindenkinek! Megköszönném, ha valaki segítene a vitalapomon. Az a gond, hogy én a szerkesztői főcímet alulra szeretném írni Napkirály postaládája néven, az olyan mint az alcím (lásd például Bennó vitalapját). Napkirály postaláda 2019. május 25., 17:09 (CEST)

2019. május 27., 17:34 (CEST)

Könnyen másolható szakaszlinkek

Ez nálam nem látszik működni, másnál rendben van? Nem a szakaszhoz, hanem a cikk tetejére ugrik linkként. – Pagony foxhole 2019. május 27., 20:52 (CEST)

Közben rájöttem az okára, bocsánat: a kérdéses szakaszcímhez lábjegyzet van rendelve, és ezzel nem tud mit kezdeni a rendszer. – Pagony foxhole 2019. május 27., 21:10 (CEST)
@Pagony: Most? (Ha még ébren vagy, akkor lehet, hogy a gyorsítótár ürítési ideje miatt egyelőre a rossz változat jön be, de holnap reggelre jónak kell lennie.) – Tacsipacsi vita 2019. május 27., 23:42 (CEST)
@Tacsipacsi: Príma, köszönöm! – Pagony foxhole 2019. május 28., 00:04 (CEST)

Cite book sablonban fontos paraméterek nem jelennek meg

Sziasztok! Ezt már korábban is tapasztaltam, hogy a {{Hivatkozás/Könyv}}(?) sablonban fontos paraméterek nem jelennek meg, ilyenek például a last1, first1, last2, first2 (ezek a szerzők nevei), vagy a volume (kötet). A sablon leírását olvasgatva feltűnt, hogy sem first1,2,3 last1,2,3 paramétereket nem ír, sem volume paramétert, azonban én a sablonmesterrel refToolbarral töltöm ki a sablont, mert ez jóval felhasználóbarátabb módja a sablon használatának (gondolom nem szorul magyarázatra, hogy nem kell fejben tartani az egymillió paraméter nevét, meg nem kell őket legépelni). Nem tudom, hogy a sablonmesternek refToolbarral van -e valami gond, vagy maga a sablon hibás -e, vagy a leírás elavult -e, esetleg ezeknek a tetszőleges kombinációja, de azt szeretném megkérdezni, hogy megjavítható -e, hogy ezek a fontos információk is láthatóak legyenek. Idemásolok egy példa sablont feltöltve, alább pedig az alszakaszban megmutatom, hogy hogyan néz ki. – Pallertithe cave of Caerbannog 2018. május 28., 23:15 (CEST)

 megjegyzés Közben javítottam, mert nem a sablonmestert használom erre, hanem a refToolbart, fogalmam sincs, hogy miért ezt írtam tegnap, csak most ide visszanézve vettem észre. --Pallertithe cave of Caerbannog 2018. május 30., 02:42 (CEST)

<ref>{{Cite book|last1=Barth|first1=Jürgen|last2=Büsing|first2=Gustav|title=Das große Buch der Porsche-Typen|volume=Modelle mit Mittel- und Frontmotor|date=2010-11-30|publisher=© Motorbuch|language=német|isbn=3613032414|pages=186, 187}}</ref>

Így néz ki működés közben

Ez egy forrásolandó példamondat.[1]<

  1. Das große Buch der Porsche-Typen (német nyelven). © Motorbuch, 186, 187. o. (2010. november 30.). ISBN 3613032414 

A segédeszközben van a hiba, mert olyan paramétert hív meg, ami nem létezik. A {{CitLib}}(?) rendelkezik több |szerző= paraméterrel is, ezért azt lenne érdemesebb használnunk. Bencemac A Holtak Szószólója 2018. május 30., 08:55 (CEST)

A mechanikus, kézzel kitöltős megoldást ismerem, ezt meg tudnám oldani a Citebookkal is, mivel kézzel az is feltölthető, például tisztában vagyok vele, hogy ha egy szerző van, akkor a first/last paraméter betöltődik. Pont azt lenne jő elkerülni, hogy fejből köpjem a paraméterek neveit, és mivel a Citlib nem használható a refToolbarral így ez nem nem megoldás. --Pallertithe cave of Caerbannog 2018. május 31., 16:50 (CEST)
 @Bencemac: kérdés: látom, hogy nagyon bonyolult sablon a cite book, nagyon cifra lenne beleoperálni ezeket a paramétereket? --Pallertithe cave of Caerbannog 2018. június 2., 11:58 (CEST)
Mint írtam, célszerűbb (és egyszerűbb) lenne, ha a segédeszköz a {{CitLib}}(?) sablon használná. Szívesen megcsinálom, ha más is rábólint. @Tacsipacsi: Esetleg tudod, miért van két hasonló JS-fájl (újabb, régebbi)? Bencemac A Holtak Szószólója 2018. június 2., 12:44 (CEST)
A régebbi valószínűleg csak itt maradt. Most helyrepofoztam a meglévőeket,[1] hamarosan megcsinálom a Cit…-sablonokat is. @Bencemac: Egy hete még nem akartál JavaScript-lapokat szerkeszteni; szeretném, hogy ez így is maradjon, mert JavaScripttel csúnya dolgokat lehet csinálni akár csak azáltal, hogy valamit véletlenül elírsz. – Tacsipacsi vita 2018. június 2., 17:01 (CEST)
  1. Büsing, Jürgen Barth ; Gustav. Das große Buch der Porsche-Typen, 1. Aufl., Stuttgart: Motorbuch-Verl. (2010. április 4.). ISBN 3613032414 

Könyvforrások – bookline 404

úgy tűnik, a bookline-nál változott a kereső, mert a Könyvforrások oldalon található link 404-et ad. ami most működik: https://bookline.hu/search/search.action?searchfield=9789639971141 Torzsmokus vita 2019. május 30., 14:51 (CEST)

@Torzsmokus: Javítva. Legközelebb te is átírhatod a Wikipédia:Könyvforrások oldalon, szabadon szerkeszthető. (A MAGICNUMBER helyére kerül az ISBN a speciális lapon.) – Tacsipacsi vita 2019. május 30., 23:43 (CEST)
@Tacsipacsi: köszi!! nem találtam/emlékeztem, hogy hol tudnék szerkeszteni egy speciális lapot. Torzsmokus vita 2019. május 31., 09:33 (CEST)
„Egy speciális lapot” nem is lehet szerkeszteni. A speciális lapok lényege, hogy a tartalmuk többé-kevésbé a szoftverbe van kódolva; a Könyvforrásoké éppen kevésbé. A döntő többségük esetében csak a megjelenő szövegeket lehet módosítani (a szerkezetet, hivatkozásokat nem), általában a translatewiki.net oldalon. – Tacsipacsi vita 2019. május 31., 12:04 (CEST)

átirányító egyértelműsítő lapok

Tudomásom szerint az egyértelműsítés normál esete az, hogy egy xy alapalak átirányít az xy (egyértelműsítő lap)ra, amiből számomra az következik, hogy az utóbbi laptípusa nem lehet átirányítás, azaz page_is_redirect=0. Ezzel szemben találok jó néhány esetet, amikor a rendszer egyért sablonnal szabályosan ellátott lapot átirányításnak tud a típusa alapján. Hogyan lehet ez, nem okoz-e ez valamilyen zavart?

Pl.

  • Reisenbüchler_Sándor_(egyértelműsítő_lap)
  • Chorényi_József_(egyértelműsítő_lap)
  • Szerelmes_szívek_(egyértelműsítő_lap)

– Porrimaeszmecsere 2019. május 31., 17:49 (CEST)

Hol találtad? Mert nálam jók. – Tacsipacsi vita 2019. május 31., 18:33 (CEST)

A vitalapjukat jelöltem azonnalira. Van még? Vépi vita 2019. május 31., 18:34 (CEST)

Aha, akkor valószínűleg Porrima SQL-lekérdezésében kimaradt az összekapcsolási feltételek közül a névtér. Íme az átirányító egyértvitalapok: 185 darab. – Tacsipacsi vita 2019. május 31., 18:44 (CEST)
@Tacsipacsi: Talán megint tanultam valamit, mint a jó pap! Bár én csak a 2-3 hónapja letöltött page táblát gondoltam nézni, de eszerint a vitalap bekavart. Ezt a 185 vitalapot rendezi valaki? – Porrimaeszmecsere 2019. május 31., 22:16 (CEST)

Látom, hogy Vépi közben kérte az AÜ-n ezeknek a lapoknak a törlését. Nekem nem fognak hiányozni, és értem, hogy a szerkesztők egy részének a rendszeretetét zavarja ezeknek a vitalap-átirányításoknak a létezése, úgyhogy akinek van kedve a törölgetéssel foglalkozni, az hadd töröljön. Ezzel együtt maradt két kérdésem:

  1. Okoznak ezek az átirányító vitalapok valamilyen tényleges, objektív problémát?
  2. Egy törölt átirányító lap így néz ki. Szerintetek ez rendesebb, mint egy meghagyott átirányító lap?

Malatinszky vita 2019. június 1., 16:56 (CEST)

@Malatinszky:Az első kérdésedre nem tudok válaszolni: ha ezek az értelmetlen és félrevezető átirányító vitalapok okoznak problémát, akkor meg kell szüntetni, azt nyilván Te is így gondolod. A második kérdésedre minden jóérzésű szerkesztőnek az a válasza, hogy a törölt állapot nem rendesebb, mint a megelőző. Én viszont találtam egy másik, szerintem elfogadható megoldást: az egyért lappá átalakult vitalapokról simán le kell törölni a hamis átirányító utasítást; azért hamis, mert az egyért lap vitáját annak egy tételére vonatkozó vitájára irányítja át. Mint botgazda, vállalom is ezeknek a hamis és szükségtelen átirányítási utasításoknak a törlését; két esetnél már meg is csináltam. – Porrimaeszmecsere 2019. június 1., 23:23 (CEST)

További kérdés

Miután a fenti probléma szerencsésen és gyorsan megoldódott, lenne egy kisebb horderejű kérdésem. Egy példa:

  1. Van Feketedoboz (egyértelműsítő lap)
  2. Van Feketedoboz átirányítás az előzőre
  3. Van Fekete doboz átirányítás UGYANODA
  4. Mi szükség van Fekete doboz (egyértelműsítő lap) ÁTIRÁNYÍTÁSRA ugyanoda, ami átnevezés következtében jött létre? Hivatkozás nincs rá, és értelem szerűen nem is lehet.

– Porrimaeszmecsere 2019. június 2., 17:37 (CEST)

Szerintem semmi szükség a Fekete doboz (egyértelműsítő lap)-ra. Nyilván nem is árt semmit, és a törlésével sem nyerünk semmit, de ha téged zavar, nyugodtan tegyél rá egy azonnali-sablont. Malatinszky vita 2019. június 2., 18:48 (CEST)
Köszönöm a hozzászólásodat; engem az ilyen esetekben az zavar, hogy az Internet sok terabájtnyi fölösleges szöveget is elbir, de ha fölösleges? Egyébként a fenti csak egy példa, száznál kevesebb társa is van. A fő kérdés inkább az lenne a jövőre nézve, hogy egyértelműsítő lap átnevezésénél meg kell-e tartani átirányításként a korábbi, legtöbb esetben hibás címet, hiszen azért történik az átnevezés, mert a régi cím nem megfelelő. – Porrimaeszmecsere 2019. június 2., 19:03 (CEST)
Van, amikor hasznos dolog megtartani az átirányítást egy átnevezés során. Például ha a (hibás helyesírású) *Margit-híd szócikket átnevezzük a helyes Margit híd alakra, akkor érdemes megtartani a hibás című lapot átirányító lapként, már csak azért is, nehogy valaki, látván hogy nincs Margit-híd néven cikkünk, nekiálljon megírni azt. Egyértelműsítő lapok esetében viszont nemigen tudok elképzelni olyan szituációt, ahol értelme volna az átirányításnak. Ha egy egyértelműsítő lapon nincs legalább két link, akkor az vagy hiányos és kiegészítésre szorul (mint a Britannia (egyértelműsítő lap) volt, amikor a minap kérted a törlését), vagy fölösleges.
Hogy egy fölösleges, de amúgy problémát nem okozó lapot kell-e törölni, arról, úgy látom, különbözik a véleményünk. Hogy megértsd az enyémet, abba gondolj bele, hogy amikor „törlünk” egy lapot, akkor valójában annyi történik, hogy a lap tartalmát egy admin elrejti a nem-adminok elől, és a lap eredeti tartalma helyett a nem-adminok csak a törlési napló odavágó bejegyzését láthatják (valamint a lapra mutató linkek pirossá válnak). A lap azonban továbbra is benne marad az adatbázisban, és a törlés nem szabadít föl tárhelyet, sőt a törléssel kapcsolatos információ maga is elfoglal egy kis további helyet az adatbázisban. Mármost azt gondolom, hogy a „Kosút lalyos” című, „Petőfi Sándor gatyába táncol” tartalmú lapot hasznos dolog így elrejteni, de arról nehezen tudsz meggyőzni, hogy a Fekete doboz (egyértelműsítő lap) törlése bármi haszonnal járna, vagy bármilyen objektív problémát elhárítana. - Malatinszky vita 2019. június 2., 19:40 (CEST)
A lényegben szerencsére egyetértünk, a kezdőmondat példáját is megtanultam már. A második részben valóban eltér a véleményünk. Noha az általam felhozott indok nem áll, mégis az a véleményem, hogy fölösleges, haszontalan dolgot elég ha az adminok látnak, a törlési napló odavágó bejegyzésével ezer évben egy halandó ha találkozik - az átirányító egyért lapok esetében. Örülök, hogy Te sem tudsz kapásból olyan esetet, amikor szükség lenne rá. – Porrimaeszmecsere 2019. június 2., 21:39 (CEST)

Szerkesztői lap

Szervusztok! Én leírhatom a szerkesztői lapomra a családfámat? Az őseimet szeretném. Napkirály postaláda 2019. június 2., 18:45 (CEST)

@Napkirály: Személyes adatokat felelősséggel kell megosztani, főleg az interneten (+elég fiatalnak tűnsz). Szerintem a Wikipédia szerkesztéséhez a családfád nem szükséges. Csuja 2019. június 2., 18:54 (CEST)

Értem, köszönöm! Napkirály postaláda 2019. június 2., 19:02 (CEST)

2019. június 3., 17:24 (CEST)

Álegyértelműsítő

Ez a szócikkcím miért rózsaszín itt? Nem egyértre mutat. – Pagony foxhole 2019. június 8., 21:42 (CEST)

Volt benne egy varázsszó, ami azt mondta a szoftvernek, hogy egyértelműsítő lapról van szó. – Máté (vitalap) 2019. június 8., 21:47 (CEST)
Köszönöm, de hogyan kerülhetett bele? – Pagony foxhole 2019. június 8., 22:09 (CEST)
@Pagony: Bogya Anna tette bele, feltételezem nem tudta, hogy mi a hatása. --Pallertithe cave of Caerbannog 2019. június 8., 22:37 (CEST)
@Pallerti: Köszönöm, több kérdésem nincs, azt hiszem, elmegyek aludni. :) – Pagony foxhole 2019. június 8., 22:54 (CEST)

Keresett lapok frissítésének SQL-lekérdezése

Sziasztok, próbáltam a Wikipédia:Legtöbbször hivatkozott lapok oldalt befrissíteni az ott talált SQL-kód felhasználásával a quarry.wmflabs.org oldalon, de ezt a hibaüzenetet kapom vissza:

You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'as title, count(pl from) as requests
FROM page p JOIN pagelinks ON p.page id = p' at line 1

Sajnos én nem értek hozzá, csak a kézimunka részét tudom elvégezni, de ha a kódot javítaná valaki, megköszönném.

SELECT pl title as title, count(pl from) as requests
FROM page p JOIN pagelinks ON p.page id = pl from LEFT JOIN page x ON pl title = x.page title AND x.page namespace=0
WHERE p.page namespace = 0 AND pl namespace = 0 AND x.page title IS NULL
GROUP BY title
ORDER BY requests DESC
LIMIT 5000;

(az eredetit lásd itt) Palotabarát vita 2019. június 8., 22:04 (CEST)

Most próbáld meg. Valamiért a bemásoláskor az összes alávonásjelből szóköz lett, mintha csak szócikkcímeket szépített volna a bemásoló. SQL-ben viszont közel sem ugyanaz a kettő… – Tacsipacsi vita 2019. június 9., 01:16 (CEST)
Tacsipacsi köszi. Most futtatja, a kód tehát jó lett, de 30 perc után kilövi (This query took longer than 30 minutes to execute and was killed). Próbáltam úgy is, hogy eléírtam:
USE huwiki_p;
de akkor is meghaladta a 30 percet. Hogy sikerült vajon ezt korábban frissíteni? Annyival több lett a szócikkünk egy év alatt, hogy már nem tudja lefuttatni 30 percen belül? Palotabarát vita 2019. június 9., 09:14 (CEST)
Az ide bemásolt kódot tesztelendő én is lefuttattam tegnap este, nálam közel 2 perccel belül maradt a harmincon. Szóval igencsak feszegetjük a határokat, lehet, hogy hamarosan mégiscsak le kell tölteni az adatbázist, és a MySQL-ben nagyobb időlimitet beállítani a helyi gépen. – Tacsipacsi vita 2019. június 9., 14:37 (CEST)
Tacsipacsi kösz, sikerült befrissíteni. Szerinted, ha a limitet visszavesszük 4000-re (vagy 3000-re stb.), akkor belefér a 30 percbe? Nem próbáltam, de talán legközelebb már így indítom, ha van valami jelentősége a limit csökkentésének. Palotabarát vita 2019. június 9., 15:02 (CEST)

Én régebben foglalkoztam ezzel a dologgal, de ahogy az SQL lekérdezés megjegyzésében leírtam, nálam sokkal tovább tartott a folyamat, holott egyszerűsítettem rajta. A teljességhez tartozik, hogy akkor még jóval gyöngébb gépem volt, szóval ez a 30 perces futási idő nekem még teljesen szuper lett volna. – Porrimaeszmecsere 2019. június 9., 17:20 (CEST)

@Palotabarát: Minden bizonnyal a limit csökkentése is megoldás. De a saját gépen futtatás is, nekem van olyan linuxos szerverhez (=olyan géphez, ami így is, úgy is 7/24-ben fut, de nem a hálószobámban zörög éjszaka) hozzáférésem, amire minden bizonnyal kérhetek MySQL-t, onnantól pedig akár az is megoldható, hogy minden dump megérkezésekor automatikusan letöltse azt, lefuttassa a lekérdezést, majd feltöltse a frissített változatot a Wikipédiára. Egyetlen probléma, hogy a saját szerkesztésemet nem emeli ki a figyelőlistám. :-)
@Porrima: Azért a hatékonyság sem utolsó. Emlékszel még, hogy mi volt az a bizonyos másik tábla, amit használtál? Hátha megvan még. – Tacsipacsi vita 2019. június 9., 22:34 (CEST)

Remélem egyre gondolunk: amit a megjegyzésben említettem másik táblát, azt én állítottam elő az aktuális pagelinksből, tehát csak összességében nyertem időt, mert két lekérdezéshez is használhattam, tehát nem a dumpban egyébként is megtalálható tábláról van szó. – Porrimaeszmecsere 2019. június 9., 23:06 (CEST)
Igen, arra gondoltam. Akkor azzal nem megyünk sokra, mert a Quarryn szerintem nézetet sem lehet létrehozni, nemhogy táblát. Ebben az esetben marad a saját gép. – Tacsipacsi vita 2019. június 10., 00:52 (CEST)
2019. június 10., 19:06 (CEST)

Elavult cikkek táblázata

Itt valami umbulda van: [35]. – Burumbátor Súgd ide! 2019. június 13., 08:51 (CEST)

Phab:T225276. Bencemac A Holtak Szószólója 2019. június 13., 09:12 (CEST)
Köszi! Akkor lehet, hogy nincs messze a megoldás. – Burumbátor Súgd ide! 2019. június 13., 09:14 (CEST)

Twinkle

Mit gondoltok, nem lenne hasznos ezt az gadgetet integrálni a huwikire? Ha valaki vállalná, hogy közreműködik a honosításában, akkor feldobom a javaslatos KF-re is. Azt írják, hogy elvileg nem túl bonyolult a honosítás, csak némely modul az enwikire van optimalizálva – át tudná esetleg valaki nézni, hogy a gyakorlatban hogyan is nézne ez ki? --Pallertithe cave of Caerbannog 2019. június 14., 12:16 (CEST)

Ell. stat

A Speciális:Ellenőrzési statisztika oldalon az egyik táblázatban kétszer szerepelnek a (fő)-, fájl- és sablonnévtérbeli adatok. Ez szándékosan van? – BenKor üzenet 2019. június 14., 13:25 (CEST)

@BenKor: Lásd kettővel fentebb az Elavult cikkek táblázata szakaszban. – Dodi123 vita 2019. június 14., 13:51 (CEST)

Státuszindikátor konfliktus

T197912

A MediaWikibe nemrég bekerült egy hasznos feature, a státuszindikátor szintaxis (egy standard szintaxissal lehet az olyan ikonokat, mint a védett lapok lakatja vagy a kiemelt csillag, elhelyezni); nálunk ez ütközik a jelölt változatok információs dobozával, aminek az elhelyezését módosítottuk (ha jól emlékszem, azért, mert az meg a koordinátasablonnal ütközött): [36][37]. Jó lenne ezt valahogy megoldani, és az indikátorsablonokat használni a kiemelt/védett/stb. cikkek jelzésére. --Tgrvita 2015. május 19., 22:56 (CEST)

Sajnos a fájlokat csak te láthatod, de szerintem azt kéne, hogy a jelenlegi ikonokhoz hasonlóan egyszerűen áttoljuk a bal oldalra (az .mw-indicators { float: left; } már nagy vonalakban jó, emellett a szöveget kéne eltüntetni, de ehhez, ha jól látom, bele kell nyúlni a PHP-ba is). Ha ezentúl jobb oldalra raknánk az ikonokat, akkor a jelölt lapváltozatok megoldásán kívül szerintem szavazni is kéne róla, mert minimum teljesen általánossá vált, hogy ott van, de azon sem lepődnék meg, ha találnék szavazást róla. --Tacsipacsi vita 2015. május 19., 23:58 (CEST)

Az is egy megoldás, hogy a flaggedrevs dobozt nem a firstHeading-be tesszük át, hanem az mw-indicators osztályú div-be egy mw-indicator osztállyal, és akkor megszűnik a konfliktus. --JulesWinnfield-hu vita 2015. július 12., 01:28 (CEST)

Viszont az a probléma akkor is fennáll, hogy több dolognál is megszavaztuk (a jó cikkeknél emlékszem konkrétan), hogy a cím előtt legyen az ikon. Ennek megfelelően újra meg kéne szavazni, ha a jobb oldalra raknánk. (Persze ettől még jó ötlet, és azt is lehet, hogy az egyes, megszavazott indikátorokat egyenként toljuk át balra CSS-sel.) --Tacsipacsi vita 2015. július 12., 01:36 (CEST)

A kiemeltcsillag és a lakat már jó ideje indikátorral van, JavaScripttel áttolva balra. Viszont a jelölt lapváltozatok doboza továbbra is összecsúszik a súgóhivatkozással. Mi lenne, ha megkérném a fejlesztőket, hogy legyen egy PHP-beállítás, hogy eleve indikátorként (és annak megfelelő dizájnnal) jelenjen meg a jelölt lapváltozatok doboza? (Mivel a kocsmafal teteje felé elég alacsony az aktivitás, jelzem: hallgatás – beleegyezés.) – Tacsipacsi vita 2018. június 2., 20:42 (CEST)

Logikus változtatásnak tűnik, de általában nehéz olyan fejlesztőt találni, aki hajlandó a jelölt változatokhoz nyúlni. --Tgrvita 2018. június 3., 11:49 (CEST)

Szaklektorálást kérő vitalapi sablon (2)

Sziasztok! Korábbi, szaklektorálással kapcsolatos felvetésem a nyári uborkaszezonban túl hamar, válaszok nélkül learchiválódótt. Nem tudom, hogy ennek az érdektelenség, vagy az inaktivitás az oka. Röviden összefoglalva a lényege a következő:

  • A szerkesztők kérhetik bizonyos szakmai témakörökben szócikkek létrehozását a vitalapi {{Lektorkérő}}(?) sablonnal
  • Ez megfelelő technikai sablonokkal látja el a szócikket.
  • Akik szeretnének lektorálni, témakörönkénti feliratkozással követhetik, ha valaki egy általuk figyelt témakörben lektort kér.
  • A műhelyek könnyen listázhatják a hozzájuk kapcsolódó lektorálási témaköröket, így a műhelytagok könnyebben összetalálkoznak a szakmai feladatokkal.

A dolog először a Zenei műhely egyes szakismeretet igénylő munkáival kapcsolatban merült fel, célja az lenne, hogy elkészülés vagy nagyobb átdolgozás után a szócikkek több szerkesztő figyelmét megkapják, így lecsökken annak az esélye, hogy a szaknyelvet használó szócikkekbe hosszú ideig beragadnak esetleges szakmaiatlan állítások. Nem célja a javasolt szaklektorálásnak a szerkesztők minősítése, de cél az egyes szerkesztők birtokában levő szakmai készség érvényre juttatása.

Ha a közösség a műszaki megvalósításban nem lát hibát, felvetném a javaslatos kocsmafalon a szaklektorálás megkezdését. Cvbncv Vince(érveljünk) 2016. augusztus 14., 10:03 (CEST)

Akik szeretnének lektorálni, témakörönkénti feliratkozással követhetik, ha valaki egy témájukba vágó új lektorkérés -

Ezt magyarul légy szíves megismételni. misibacsi*üzenet 2016. augusztus 14., 12:02 (CEST)

@Misibacsi: Figyelmetlen voltam. Kérésedre, a mondat így hangzik magyarul: "Akik szeretnének lektorálni, témakörönkénti feliratkozással követhetik, ha valaki egy általuk figyelt témakörben lektort kér." Cvbncv Vince(érveljünk) 2016. augusztus 15., 13:22 (CEST)
Köszönöm, így már jó. misibacsi*üzenet 2016. augusztus 15., 14:09 (CEST)

Nem lenne egyszerűbb jó szócikknek jelölni? – B.Zsolt vita 2016. augusztus 14., 23:56 (CEST)

@B.Zsolt: Ezt fejtsd ki kérlek, mert a jószócikk-jelöléssel és a kiemelési eljárással kapcsolatban nincs sok tapasztalatom. Mi a köze annak ahhoz, hogy egy új szócikket a keletkezése után lektorálunk? Esetleg a lektorálás vége jónak jelölés lehetne, ha erre gondolsz.
Nézetem szerint amikor például egy fontos zeneelméleti szócikk megszületik, de szakmai tartalma még nem éri el a megfelelő szintet, akkor ott nem lehet semmit jó szócikknek jelölni, ellenben érdemes lenne értesíteni más műhelytagokat, hátha lenne valaki, aki ránézne. Így a cikk esetleg nem válik szakmaiatlan tartalmakkal együtt évekre elhagyatottá. Cvbncv Vince(érveljünk) 2016. augusztus 15., 13:22 (CEST)
Arra gondoltam, hogy a Jó szócikk jelölés is több ember közös munkája. A jó szócikknek is megvannak a minimális tartalmi és formai követelményei. Több szem többet lát alapon gondolom, hogy előnyére válik a cikknek, ha minél többen elolvassák. Persze a bonyolult szakmai hiányosságokon nem biztos hogy ez segít.
Régen volt a magyar Wikin referálás nevezetű ellenőrzés. Talán érdemes lenne azt is megnézni, hát ha vannak benne jó ötletek. – B.Zsolt vita 2016. augusztus 15., 21:13 (CEST)

 támogatom a javaslatot, szerintem jó ötlet. Nem ugyanaz, mint a "jószócikk-jelölés", hiszen ezzel az új sablonnal még nem létező témáról is lehetne cikket kérni, illetve születő cikkekről van szó. misibacsi*üzenet 2016. augusztus 15., 14:09 (CEST)

"Lap figyelése" nem működik

A szerkesztési ablak alatt van egy üres kocka "Lap figyelése" felirattal. Ezt hiába pipálom be, a lap figyelési állapota nem változik, azt kézzel kell megtennem, ha figyelni szeretném.

Úgy emlékeztem, hogy "Gyors előnézetet" használok a Beállításoknál (ami betöltés nélkül mutatja a módosított lapot). Most megnéztem, és nincs bekapcsolva. misibacsi*üzenet 2019. június 13., 18:49 (CEST)

Ha az alsó „A lap figyelése” négyzetet bepipálja a szerkesztő, akkor alapvetően csak a változtatások közzétételekor kerül fel a figyelőlistára. Ennek elméletileg mindenkinél jól kell működnie, az előbb ellenőriztem. – balint36 🚌 buszmegálló 2019. június 13., 19:14 (CEST)

Biztos, hogy nem változik a figyelési állapot? Én számtalan alkalommal észrevettem (csak még nem vettem rá magam a jelentésére), hogy ugyan felkerül a lap a figyelőlistámra, de közvetlenül a lap mentése után ez nem látszik. Ha frissítem a lapot, akkor már látszik, hogy a figyelőlistámon van. (Egyébként én használom a (Szerkesztés fülön bekapcsolható) gyors előnézetet.) – Tacsipacsi vita 2019. június 13., 19:42 (CEST)

Most újból megnéztem, és közvetlenül az adott lap mentése után még nem mutatta a figyelési állapot változását, a lap későbbi frissítésénél azonban már igen. Lehet, hogy eddig is így működött, csak nem vettem észre. Bocs, ha figyelmetlen voltam. misibacsi*üzenet 2019. június 15., 05:50 (CEST)
2019. június 17., 22:37 (CEST)

Jelszó

Ha jól értem, Partmosó műszaki problémát jelzett illetve itt: Szerkesztővita:Partmoso#Újrakezdés (vagyis nem tudja a jelszavát). Apród vita 2019. június 18., 00:49 (CEST)

Zárójelezés

Érdeklődni szeretnék, miért van az, hogy ha e-mailben szeretnék wikis cikket belinkelni, ha zárójelet tartalmaz, a zárójeles részt nem kékíti be, azaz csak az azelőtti részt veszi be, és arra irányít. Ha van alapalak (Kertész András), akkor arra irányít, pl. egyért lapra, ez még hagyján, de ha nincs, akkor olyan, mintha nem létezne még a lap. Hangsulyozom, ez e-mailes küldésre érvényes, mert itt úgy látom, elvisz a normális helyre, mi lehet az oka:

Sőt ha pl. pont van a végén, pl. egy kft. esetében, ott sem linkeli be teljesen, mi lehet ennek az oka, hogy lehetne megoldani, hogy ne kelljen ilyenkor e-mailben magyarázkodni, vagy csak akkor tudja megnézni normálisan, ha beírja inkább a Google keresőben, de ez meg túl boyolult, miért kell linkeléshez fél oldal nettó magyarázat, és lehetne közvetlenül e-mailben is belinkelni. Ha csak a freemailre jellemző, ettől még nem fogok más e-mailt választani, de azért jó lenne, ha lenne rá valami megoldás vagy az e-mailszolgáltató tehet róla, hozzájuk kéne fordulnom. Köszönöm a figyelmet!Peadar vita 2019. június 17., 18:22 (CEST)

Ha HTML formátumú e-mailt használsz, akkor elvileg nem kéne problémát okoznia (nem ismerem a Freemailt, de normális szerkesztőprogramban el tudod dönteni, hogy a pontot is a linkbe teszed-e). Ha egyszerű szöveges e-mailt használsz, akkor a címzett levelezőprogramjától függ, nálam pl. a mobilomon lévő levelezőprogram a fenti linkből a Kertész András (nyelvész cikket hámozza ki (bezáró zárójel nélkül), a https://hu.wikipedia.org/wiki/Kft. szöveget pedig nem tudja linkként értelmezni; a Thunderbird Kertész Andrást rendesen felismeri, a Kft.-ből pedig pont nélküli Kft lesz (ahogy egyébként a wikiben is). A megoldás az, ha ezeket a karaktereket kódolod: a nyitó zárójelből %28, a záróból %29, a pontból pedig %2E lesz (ha nem jegyzed meg a kódokat, rá is kereshetsz az interneten: „parentheses/dot hexadecimal code” kell, és a kétjegyű hexadecimális számban elé URL-ben egy százalékjelet kell írni). Azért van ilyen kavarodás, mert igazából mindkettő értelmezés helyes lehet, a levelezőprogramok viszont nem gondolatolvasók: te pont egy olyan hivatkozást akarsz küldeni, ami pontra/zárójelre végződik, de simán lehet, hogy egy mondatzáró pontról vagy egy zárójeles megjegyzés lezárásáról van szó, ami ugye nem része a hivatkozásnak. – Tacsipacsi vita 2019. június 17., 19:04 (CEST)
Köszönöm, de nekem ez túl bonyolult, olyan kis túlzással, mintha a kinyomtatott szöveg után még tollal is be kéne toldani szöveget, a nyomtatás önmagában nem lenne elég, ez nonszensz. Ezt a rendszernek kéne megoldani, vagy akkor nem tökéletes, fejleszteni kéne, persze a kritika nem neked szól, csak kicsit nevetségesnek tartom, hogy ezt nem tudja megoldani egy fejlettnek mondott technika, hiszen az lenne a dolga, hogy ezt a hibát később kijavítsa, ha felmerül a probléma, A facebooknak nem okoz gondot felismerni ezt, akkor egy sima e-mailben nem értem, miért nem lehet normálisan linkelni. Én csak simán bemásolom az URL-ját, amit nem én változttok meg, mindkettőt informatikusok, kibernetiksok alkottak, nem értem, miért nem lehet őket összedolgozni. Azt se értem, de azt még ki lehet totőzni, mikor kell www is, mikor http és mikor https, hogy jó legyen a link. Sajnos, az informatiksok nem mindig értik az egyszerű felhasználó lelkét. A tévé működési elvét sem kell ismernem, hogy használni tudjam, viszont elvárom egy tévészerelőtől, hogy meg tudja javítani, ha valami hiba van. Annyit viszont tudok, hogy én linket nem keverek semmi mással, mindig külön sorba teszem, más szavaktól és karakterektől is távol, nehogy azok bekavarjanak, és csak azt kékítse be, amit kéne, mégis a zárójeles, pontos részt kihagyja. E-mailcímnél is vigyázok, nem teszek utána semmi mellékjelet, vesszőt, pontot, még ha a helyesírás ezt kívánná, vagy csak kicsit távolabb írom tőle, hogy azt önálló egységként felismerhesse, viszont érdekes módon e-mailcímnél minden mellékjelet pontosan felismer benne, egy URL-nál akkor miért nem teszi.Peadar vita 2019. június 17., 19:56 (CEST)
Az a helyzet, hogy ez a probléma azért van, hogy a mezei felhasználóknak könnyebbé tegye az URL-ek értelmezését. A gépnek tökéletesen megfelel a https://hu.wikipedia.org/%77%69%6B%69%2F%4B%65%72%74%C3%A9%73%7A%5F%41%6E%64%72%C3%A1%73%5F%28%6E%79%65%6C%76%C3%A9%73%7A%29 forma is, amivel semmilyen hivatkozásfelismerési problémád nem lesz, de mennyivel olvashatóbb a https://hu.wikipedia.org/wiki/Kert%C3%A9sz_Andr%C3%A1s_(nyelv%C3%A9sz) változat? (Jó, az ékezetes karaktereket én sem tudom dekódolni benne fejből, de azt azért oda lehet tippelni közé.) Egyébként tudtommal az URL közepén sincs gond a felismeréssel, valószínűleg az e-mail-címek végén is – lenne, ha lenne ilyen karakter az e-mail-cím végén; de az e-mail-cím mindig országkódra (vagy országkódszerűségre, pl. .com) végződik, így ott fel sem merül a probléma. – Tacsipacsi vita 2019. június 17., 22:14 (CEST)

Esetleg próbáld meg a "Hivatkozás erre a lapváltozatra" funkciót. Ott van oldalt, az interwikik felett, az eszközök között. – B.Zsolt vita 2019. június 17., 22:34 (CEST)

Hát köszönöm, de így meg plusz még többe kerül a leves, mint a hús, egyszerűbb, hogy inkább írja be a Google-ben vagy megadni a wikidata oldalt, mert a Google sem mindig akarja kiadni, és aki kevésbé járatos, az nem vacakol ezzel. De minden jót lerontanak, mert most meg a Ctrl F-es keresést nehezítették meg, csak egész szavakat, de azt is bonyolultan ad ki, szórészleteket már nem lehet keresni, így a ragozott szavak nem jönnek elő. Ezt miért csinálják, nem tudom.Peadar vita 2019. június 19., 07:26 (CEST)

Sziasztok! Az infoboxban Lua-hiba van, de nem tudom, hogy miért. Nekem a WD-n jónak tűnnek az adatok a székhely propertynél (lásd: Közös Halmaz Alapítvány (Q63926182)), de persze tévedhetek is. Kérem, hogy egy hozzáértő Lua-tudor véleményezze a bajomat. Köszönöm szépen előre is! Cvbncv Vince(érveljünk) 2019. június 19., 11:43 (CEST)

Javítva. (Egyébként teljesen felesleges azzal a lendülettel kirakni a függőben sablont, amikor a szakaszt megnyitod. Ez arra van, hogy ha láthatóan nincs aktivitás, de itt akarod tartani a szakaszt, akkor ne archiválódjon. A szakasznyitáskor még nem tudod, hogy lesz-e aktivitás.) – Tacsipacsi vita 2019. június 19., 17:39 (CEST)
Szia! Köszönöm szépen a gyors reakciót! Azért tettem rá rögtön a függőbent, mert jártam már úgy, hogy archiválódott, mielőtt válasz jött rá. Ez pedig olyan hibának tűnt, ami jobb, ha nem felejtődik el. Igérem viszont, hogy később sem fogom automatikusan kitenni, csak ha kimondottan indokolt: hogy ne növeljem feleslegesen a nyitott témák számát. További jó szerkesztést! Cvbncv Vince(érveljünk) 2019. június 20., 09:24 (CEST)

Javascript kérés a jegyzetelő sablonokhoz

Egy korábbi, pár szakasszal feljebbi azonos kéréssel összevonásSamat üzenetrögzítő 2014. november 1., 21:45 (CET)

Az alábbiakat időnként megkérdezem, Tgr szokott rá válaszolni miszerint megoldható. Aztán a kérés újra meg újra eltűnik a süllyesztőben. Talán most kedvet kap valaki, és megcsinálja. Ez a script lehetne ötletadó: http://www.mediawiki.org/wiki/Extension:HarvardReferences/Scripts.
A {{hely|param}} sablon nyilacskájára való kattintás az első olyan helyre ugrat és azt kisárgítja, ahol a horgony a back:param. Az lenne jó, ha nem csak az elsőt, de az összes olyan helyet kisárgítaná, aminek ez a horgonya. Ezek a horgonyok valamennyien a class="dokulink"-hez tartoznak.
Ahhoz kellene, hogy lássuk hány helyről és hol hivatkozták a cikkben az illető forrást.
Fontos lenne.
 Karmela posta 2011. november 22., 23:20 (CET)

Fontos lehetne bizony. Én támogatom. --Pagonyfoxhole 2011. november 22., 23:23 (CET)

+1. Talán segít. Samat üzenetrögzítő 2014. november 1., 21:42 (CET)


Ezt a javascriptet régóta kérem, emlékeztetőnek írom ide:
Jelenleg a forráslistában az egyik { {hely} } sablon kis nyilacskájára kattintva az első olyan hivatkozásra ugrunk, ami ehhez a forrásleírást használja, és az a refhely ebbe bele is sárgul.
Ugrani persze csak az első hivatkozásra lehet (sajnos), de legalább be kéne sárgítani mindent, ami ide mutat.
Ez a script lehetne ötletadó: http://www.mediawiki.org/wiki/Extension:HarvardReferences/Scripts.
Ezeknek a linkeknek azonos az id-je, az id-k prefixe a forrásleírás előtt „hely:”, a cikktörzsben pedig „back:”, a linkek kölcsönösen egymásra mutogatnak.
A class="dokulink" fogja össze őket.
--Karmela posta 2013. május 24., 21:00 (CEST)

+1 Már nekem is eszembe jutott, hogy ennek így kellene működnie... JSoos vita 2016. január 19., 09:20 (CET)

Óhaj-sóhaj. --Karmela posta 2016. november 6., 11:27 (CET)

Az a probléma, hogy horgonyt (id) használ, márpedig a böngészők nem szeretik, ha egy horgony többször is szerepel ugyanazon a lapon, és úgy tűnik, azzal reagálnak rá, hogy a :target pszeudoosztályt csak az első kapja meg. Tehát a jelenlegi, pusztán CSS-re épülő megoldással nem lehetséges, JavaScript kell hozzá, valamint az, hogy a megfelelő helyeken (a szövegközi linkeknél) legyen egy megfelelő CSS-osztály, ami alapján JavaScripttel meg lehet oldani. Nem kéne olyan dolgokra építeni, amik egyértelműen ellenjavalltak (többszörös horgony), a HarvardReferences allapjához meg több mint hat éve nem nyúltak, nagy részére minimum van jobb megoldás, de van mára teljesen megbízhatatlanul működő része is. Szerencsére azzal nem kell törődni, hogy mobilon működni fog-e, mert a jelenlegi megoldás se jó… – Tacsipacsi vita 2016. november 6., 16:14 (CET)

@Tacsipacsi: A szövegközi linkeknél van már egy CSS-osztály: class="dokulink". Jó lesz ez a javascripthez?

--Karmela posta 2016. november 6., 17:43 (CET)

Nem, kvázi a horgony helyett (a hivatkozás miatt mellett) kéne, csak a horgony (elvileg) nem tartozhat több elemhez egyszerre. – Tacsipacsi vita 2016. november 7., 18:21 (CET)

Ezt most már el kell engednem, nyilván. --Karmela posta 2019. június 22., 19:39 (CEST)

Lassulás

Másnál is belassul időnként a Wikipédia az elmúlt 1-2 napban? Nálam gyakran akadozva, félig, vagy egyáltalán nem töltődik be egy-egy oldal. – Regasterios vita 2019. június 19., 10:32 (CEST)

Nálam is, csak pörög-pörög. Chrome. Olyannyira, hogy itt most meg se jelenik az ablak fölött a szerkesztési menüsor. Pagony foxhole 2019. június 19., 10:34 (CEST)

Igen. Vépi vita 2019. június 19., 10:38 (CEST)

Én is Chrome-ot használok. Most az Operát próbálgatom, de ott is ugyanez van. Csak a Wikipédia mindenhol, más oldalak nem. – Regasterios vita 2019. június 19., 10:48 (CEST)

Érdekes, én csak tegnap tapasztaltam ilyet, ma még nem volt probléma. – balint36 🚌 buszmegálló 2019. június 19., 10:51 (CEST)

Nálam most már teljesen szétesik. Megint tarhálás lesz? – Pagony foxhole 2019. június 19., 16:03 (CEST)

Nálam is. Néha a stílusok sem töltenek be. – Tacsipacsi vita 2019. június 19., 17:36 (CEST)

Nálam is van ilyen. Ma pl. volt hogy azonnali sablont sem tudtam normálisan felhelyezni, mert alul a karakterekre hiába kattintottam nem reagált rá. – XXLVenom999 vita 2019. június 19., 17:43 (CEST)

Nálam most sok idő után csak formázatlan szöveg jelent meg. – Porrimaeszmecsere 2019. június 19., 23:21 (CEST)

Tegnap egész nap ezt csinálta, böngészőfüggetlenül. Ma egyelőre jónak tűnik. Samat üzenetrögzítő 2019. június 20., 08:42 (CEST)

T226048 --Tgrvita 2019. június 20., 11:21 (CEST)

Nem látszanak kiigazodni a problémában. – Pagony foxhole 2019. június 20., 11:26 (CEST)

Nálam ez mostanában a Wikipédia:Kocsmafal (egyéb)en volt néhányszor - de mivel egyrészt nem folyamatosan, csak időnként merült fel és mert tudom, hogy 300 ezer bájt felé közelít a kocsmafal (egyéb) mennyisége, ezért nem jeleztem a hibát. Apród vita 2019. június 21., 23:34 (CEST)