Wikipédia:Kocsmafal (műszaki)

(WP:KF-M szócikkből átirányítva)
Kocsmafal – műszaki problémák szekciója

A műszaki szekcióban vitathatod meg a MediaWiki szoftverrel, HTML/CSS/JS/... kóddal, böngészőkkel stb. kapcsolatos ötleteidet, problémáidat. A már megoldódott problémákról szóló szakasz elejére az áttekinthetőség érdekében illeszd be a {{megoldva|~~~~}} sablont. Hibák jelzésekor írd meg a böngésződ típusát, és hogy kaptál-e hibaüzenetet!
Amennyiben nem a Wikipédiához vagy a MediaWikihez kapcsolódó műszaki kérdésed van (például különböző számítógéppel kapcsolatos problémák), azt ne itt tedd fel, hanem keress fel egy, az ilyen kérdésekre szakosodott fórumot.

  • Új témát mindig a lap alján kezdj! Vagy használd a következő linket: Új szakasz nyitása!
  • Ne felejtsd el aláírni a hozzászólásodat (a ~~~~ jelek begépelésével vagy a szerkesztőablak fölötti aláírás gomb használatával)!
Tippek a Kocsmafal hatékonyabb használatára
  • Ha egy jó ötletednek nem akad pillanatnyilag megvalósítója, de többen helyeslik, vedd fel a később megvalósítandó Jó ötletek tárházába, nehogy elsüllyedjen a kegyetlenül falánk archívumban!
  • Ha azonnali válaszra van szükséged, és/vagy élőben szeretnél értekezni a többi szerkesztővel, lépj be a Wikipédia IRC-csatornájára!
  • Ha személyes segítőtársat szeretnél, akivel megbeszélheted szerkesztési problémáidat, akkor ide kattintva kérhetsz mentort magadnak.
  • Ha nem tudod eldönteni, hogy valamely speciális probléma/feladat kire tartozik, nézz körül a különleges szerkesztői jogokkal felruházott Wikipédia-munkatársak feladatkörét ismertető lapon!
  • Ha valamilyen enciklopédikus információ után kutattál a cikkekben, de nem találtad meg, fordulj a Tudakozóhoz.


Képlicencek legördülő menüje képfeltöltésnélSzerkesztés

  Függőben Bináris ide Kelt: Wikipédia,  2017. május 3., 11:02 (CEST)

Szeretnék megkérni egy arra jogosult műszaki szakit, hogy a Speciális:Feltöltés-nél a választható képlicencek legördülő menüjébe a Saját készítésű képekhez tegye be a CC BY 3.0 és CC BY 4.0 licenceket, a Szabad képekhez a CC BY 4.0 és Szabad képernyőkép licenceket, a Nem szabad fájlokhoz pedig a Jogvédett képernyőkép licencet. Köszönöm! – Sasuke88   vita 2017. április 29., 16:54 (CEST)

Most egymás alatt duplán felsorolva szerepel a CC-BY-SA 3.0, CC-BY-SA 4.0, CC-BY-3.0, CC-BY-4.0, anélkül, hogy bármi utalna a lényegükre, az egymás közti érdemi különbségre (mikor melyiket?). Szerintem ebből csak a vérprofik igazodnak el. Akela vita 2017. április 30., 09:29 (CEST)

@Sasuke88, Akela:  kérdés, illetve javaslat: az elavult 3.0-ás licenceket szerintem nyugodtan ki lehetne venni (félreértés ne essék, lehet ezzel licencelni, sőt akár 1.0-val is csak nem nagyon érthető, hogy ezt ajánljuk a korszerűbb, aktuálisabb helyett (vagy ebben az esetben mellett)) és akkor nem lenne ilyen hosszú a lista. A 4.0-ás licenc körül-belül annyiban újabb, hogy egyrészről kompatibilitása van a Free Art license 1.3-mal, és egyirányú kompatibilitása a GPLv3-mal (GNU General Public License version 3). Az egyirányú kompatibilitás itt pontosan azt jelenti, hogy a BY-SA 4.0 anyagok publikálhatóak a GPLv3 alatt, de nem járul hozzá a GPLv3 projekteknek a BY-SA 4.0 szerinti módosításához. Ezen kívül a 4.0 szélesebb jogi környezetben használható, mert több nyelvre lefordították (ezt nem úgy kell érteni természetesen, hogy valaki leült és lefordította mondjuk még öt nyelvre, hanem több, helyi jogi környezettel kellett harmóniába hozni), így értelemszerűen hatékonyabban támogatja a szabad tartalom terjesztését. Ugyan a 3.0-ás verzió átlicencelhető 4.0-ra, de szerintem érdemesebb lenne arra ösztönözni a felhasználót, hogy egy modernebb, széleskörűbben használható licencre kattintson inkább. Mi a véleményed? --Pallerti the cave of Caerbannog 2017. április 30., 09:47 (CEST)
@Akela: a szám a verziószámot jelöli (erről a fentebbi behúzásban írok röviden), a betűjelek pedig korlátozó attribútumok, amiket mindjárt fel is oldok. A CC (Creative-Commons) szabad licencek nagy előnye, hogy nagyon kevés korlátozást írnak elő a felhasználás során, de ezek közül kettő benne van abban az ajánlásban a Wikimedia projektek használnak, védendő a szerzőt. Az első betűjel ugye a CC=Creative-Commons a licenc kibocsájtója, a BY (Nevezd meg!) attribútum pedig előírja, hogy a szerzőt megfelelően fel kell tüntetned, hivatkozást kell létrehoznod a licencre és jelezned ha a művön változtatást hajtottál végre, a SA (Így add tovább! Share-alike!) írja elő, hogy ha feldolgozod, átalakítod vagy gyűjteményes művet hozol létre a műből akkor a létrejött művet ugyanazon licencfeltételek mellett kell terjesztened mint az eredetit. Vannak ezeken kívül is attribútumok (például a nem kereskedelmi, NC= non-commercial), de mivel ezek már nem szabad licencű attribútumok, ezekbe nem mennék most bele. A CC licencek egyik legnagyszerűbb tulajdonsága az átlátható használhatóság. --Pallerti the cave of Caerbannog 2017. április 30., 09:57 (CEST)

@Pallerti: Köszönöm szépen! Esetleg még a kettős licencnél nem lehetne frissíteni 4.0-ra? (Meg a jogvédett képernyőképnél a kis j kezdőbetűt át kéne írni nagyra.) Én a 3.0-át nem venném ki, mert még sok helyen előfordulhat. Vagy, ha valahol mondjuk CC-BY 3.0-át jelölnek meg, azt feltölthetem CC-BY 4.0-ával is? A politikai beszéd részlete jogilag mennyire tér el más jogvédett hanganyagok részletétől, van valami alapja a megkülönböztetésnek? @Akela: Nem kell vérprofinak lenni ehhez a pár betűhöz: BY = Nevezd meg a szerzőt!, SA = A származékos művedet az eredeti mű licencével tedd közzé!, NC = Kereskedelmi forgalomba nem hozható, ND = Nem módosítható.   – Sasuke88   vita 2017. április 30., 10:53 (CEST)

@Sasuke88: Válaszolok egyesével: a kettős licencnél szerintem lehet frissíteni, de a pontos válaszhoz egy kis türelmet kérek, mert ott a GFDL kompatibilitást meg kell néznem, viszont őszintén szólva maga a kettős licenc is egy kicsit értelmét veszti a CC-BY-SA-4.0-val, mert CC-BY-SA-4.0 tartalmakat felhasználhatsz GPLv3 alatt (fordítva nem!) így nem szükséges külön is nyilatkozni a GNU licencről. A J kezdőbetűt átírom. a 3.0-át pont azért lehetne kivenni, mert át lehet licencelni 4.0-ra, tehát ha egy 3.0 alatti képet találsz, azt nyugodtan feltöltheteted 4.0-val (vagy ha majd lesz, későbbi verzióval, a CC licencek visszafelé kompatibilisek). A politikai beszédet, vagy a napi eseményekhez kapcsolódó, időszerű gazdasági vagy politikai témákról megjelentetett cikkeket a SZJT egy kicsit szabadabban engedi idézni az egyéb jogvédett műveknél – egészen konkrétan a nyilvánosan tartott előadások és más hasonló művek részletei, valamint politikai beszédek tájékoztatás céljára – a cél által indokolt terjedelemben – szabadon felhasználhatók. --Pallerti the cave of Caerbannog 2017. április 30., 11:12 (CEST)
@Sasuke88: közben agyaltam a kettős licencen, de annyira egyszerű a válasz, hogy nem is kell kompatibilitást nézni: nem kell átírni, sőt értelme sincsen, mert – ahogyan írtam fentebb – a 4.0 eleve kettős licenc, gyakorlatilag így önmagában az eddigi {{kettős licenc}}(?) upgrade-je, ezért nem kell külön nyilatkozni a GNU licencről. Mivel azonban a 3.0 önmagában nem kompatibilis a GNU licenccel, ezért ott külön is nyilatkozni kell, hogy mindkettő licenc alatt érvényes a szerző engedélye. én inkább azt javaslom, hogy a CC-BY-SA-4.0 kerüljön az eddigi ajánlott, kettős licenc helyére, a régi 3.0-val összefűzöttet meg nyugodtan ki lehet venni. Persze továbbra is a kettős-licenc érvényes az eddig licencelt művekre, csak ne arra ösztönözzük a feltöltőt, hanem inkább a modernebb 4.0-ra, különösen, hogy át is licencelhető a kettős-licenc a 4.0-ra, mivel az kettő licencre ad engedélyt, a CC-BY-SA-ra, ami kompatibilis az új változatra, meg a GFDL 1.2, ami meg szintén kompatibilis a 4.0-val ősszefűzött GNU 1.3-mal. A fentieket összeségében tekintve semmi nem szól amelett, hogy akár a kettős licencet, akár régebbi CC licenceket használjunk a jövőben feltöltött képekhez – tökéletesen kiváltja ezeket a CC-BY-SA-4.0 --Pallerti the cave of Caerbannog 2017. április 30., 11:25 (CEST)
@Pallerti: Köszönöm a válaszokat és, hogy utánanéztél mindennek. A fentiek tükrében én is   támogatom, hogy a CC-BY-SA-4.0 legyen az ajánlott. Esetleg, ha időd engedi, majd tudnál segíteni a Wikipédia:Képek licenceinek megadása lap aktualizálásában is? Tegnap nekiálltam frissíteni, bővíteni, javítani, de ahogy látom, te egy "kicsit" jobban értesz ezekhez a licenc dolgokhoz, mint én  . – Sasuke88   vita 2017. április 30., 11:38 (CEST)
@Sasuke88: persze, segítek aktualizálni, holnap, holnapután szánok rá időt, megnézem mit tudok tenni. --Pallerti the cave of Caerbannog 2017. április 30., 15:18 (CEST)

Most nincs időm beleásni magam ebbe, de a képfeltöltési útmutatónkat is szükséges lehet aktualizálni. Bináris ide Kelt: Wikipédia,  2017. április 30., 12:15 (CEST)

Bocsánat, függőre cseréltem a megoldva sablont, mert a feladat félig van megoldva. A dokumentációnak együtt kéne járnia a műszaki megoldással, hogy elkerüljük a káoszt. A Sablon:Képekkel kapcsolatos oldalak sablonban van egy egész sornyi licencekkel kapcsolatos oldal. Akkor lesz megoldva ez a feladat, ha valaki jelenti, hogy átnézte és szükség esetén aktualizálta az összeset. Bináris ide Kelt: Wikipédia,  2017. május 3., 11:02 (CEST)

HTML hibák javítása (Tidy csere)Szerkesztés

  Függőben Bináris ide Kelt: Wikipédia,  2017. december 28., 20:47 (CET)

Mint talán hallottatok róla, a Wikipédia HTML-kódjának generálásában részt vevő Tidy szoftvert hamarosan lecserélik egy okosabbra. A Tidy a HTML szabványosságát biztosította, vagyis ha egy szerkesztő szabálytalan HTML-t írt be, akkor kitalálta, hogyan lehet ebből úgy szabályosat csinálni, hogy az jó eséllyel megfeleljen a szerkesztői szándéknak.

Az, hogy az új szoftver okosabb, azt is jelenti, hogy máshogy működik, így egyes szabálytalan wikikódoknak megváltozik a kimenete. Ez néha jó dolog, de nem mindig; a fejlesztők kigyűjtötték azokat az eseteket, amikor valószínűbb, hogy nem. Ezeket kézzel ki kellene javítani. A Special:LintErrors oldalon találhatóak; a nagy részük valószínűleg sablonból jön és csak egyszer kell javítani. A WPCleaner (lásd Ellenőrzőműhely) tudja a legtöbb hibát javítani (kézi segítséggel). Jó lenne felosztani és nekiállni.

Érdekel ez valakit? (Ne adj isten már foglalkozik vele valaki?) Szívesen írok részletesebb útmutatót arról, mit kell csinálni, ha van aki olvassa. --Tgrvita 2017. december 11., 07:21 (CET)

Ahogy elnézem, a legtöbb esetben sablon okozza, így a munka kevesebb, mint elsőre látszik. Néhány hibához írhatnál egy kis útmutatót, hogy mit is kell keresni. – B.Zsolt vita 2017. december 11., 10:13 (CET)

Én már foglalkozgatok vele, de elég lélekölő az ötödik teljesen felesleges francia megye infoboxban kicserélni a <font color="white">[[…]]</font> kódot [[…|<span style="color:white;">…</span>]]-re vagy a huszonharmadik <small>…<small/>-t javítani. Útmutatóra nincs szükségem, legfeljebb az érdekel, hogy a hiányzó lezáró címke mint hiba azt jelenti-e, hogy az archívumok szét fognak esni a HTML5-nél. Meg hogy ki fog az életben kijavítani 294 543 elavult HTML-címkét, mikor a teljes szócikkszám ennek kevesebb mint másfélszerese… – Tacsipacsi vita 2017. december 11., 20:09 (CET)

Én is szívesen beszállok pár (tíz)ezer javítással majd. Samat üzenetrögzítő 2017. december 12., 00:18 (CET)

Én még csak ismerkedem a WPCleanerrel és csak automatikusan javítható hibákat tudok vele javítani. -- ato vita 2017. december 12., 09:08 (CET)

Lehet nem érdemes kapkodni a kezdéssel. Nem várható egy frissebb AWB? Más wikiken is biztosan van tennivaló bőven. – B.Zsolt vita 2017. december 12., 10:16 (CET)

Kezdeti állapotSzerkesztés

Magas prioritás

  • Table tag that should be deleted (796 hiba)
  • Misnested tag with different rendering in HTML5 and HTML4 (4 574 hiba)
  • Paragraph wrapping bug workaround (0 hiba)
  • Önzáró címkék (209 hiba)
  • Tidy bug affecting font tags wrapping links (23 102 hiba)
  • Tidy whitespace bug (4 hiba)

Közepes prioritás

  • Bogus file options (13 201 hiba)
  • Fostered content (1 034 hiba)
  • Misnested tags (25 156 hiba)
  • Multi colon escape (93 hiba)

Alacsony prioritás

  • Hiányzó lezáró címke (183 895 hiba)
  • Elavult HTML-címkék (391 363 hiba)
  • Stripped tags (72 236 hiba)

Csak hogy lássuk, honnan indultunk és hova jutunk! :) – B.Zsolt vita 2017. december 12., 10:46 (CET)

Hogy lássuk, honnan indultunk: tegnap este még mintegy százezerrel kevesebb elavult HTML-címke volt… – Tacsipacsi vita 2017. december 12., 11:43 (CET)

Most is nagyjából ezek a számok, némelyik nőtt, sőt még újabb típus is megjelent. @Tgr: mit jelent a hamarosan, és milyen katasztrófa várható a javítás elmaradása esetén? Illetve mennyire gyorsan frissül a speclap? (Mert láttunk már olyant, ami évekig nem...) Bináris ide Kelt: Wikipédia,  2017. december 28., 20:47 (CET)

Az elavult HTML-címkék most megint nagyjából 300 000-en vannak a fent látható 400 000 helyett, a fontos <font>-os ( ) hibából pedig sikerült nagyjából 6000-et ledolgoznom (ötszáz elemű navboxok módosításával könnyen megy, csak azt nem tudom, hogy ki a fene használja őket…). A lap teljesen vállalható idő alatt frissül, tapasztalataim szerint öt-tíz perc alatt van a szintidő. – Tacsipacsi vita 2017. december 28., 22:11 (CET)


Új számokSzerkesztés

You have made a lot of progress! Special:LintErrors shows only ~1,000 HTML errors in articles (mainspace/namespace 0) at the Hungarian Wikipedia now. Here are the biggest categories:

Error type Error count Articles
deletable-table-tag 493 list
html5-misnesting 258 list
multiple-unclosed-formatting-tags 302 list

The "list" shows the articles and a special "edit" link that will highlight the area of concern. Please see mw:Help:Extension:Linter for information. You can ask for help at mw:Help talk:Extension:Linter or w:en:WT:Linter. You are nearly finished! Thank you for your awesome work. Please keep up the good work. Whatamidoing (WMF) vita 2018. május 31., 20:58 (CEST)

Sok hiba a Sablon:Nyelvből és leszármazottaiból adódik, amikor valahol dőlten, dupla aposztróffal van meghívva. Pl. az ''({{ny-de|Stille Nacht}})'' eredménye: (németül: Stille Nacht). Itt misnested span tag lesz az eredmény. Nem is teljesen egyértelmű számomra, mi itt a tervezett végeremény, azaz az eredeti terv szerint ilyen esetben minek kéne dőltnek lennie, és minek nem.– Pzgulyas vita 2018. június 10., 21:31 (CEST)

Hamis keresett sablonok a JavaScriptekbenSzerkesztés

  Függőben Bináris ide Kelt: Wikipédia,  2019. október 27., 21:57 (CET)

Kiemeltem a #Sablonbeszúráskor szóköz helyett + szakaszból, mert csak egy egyforma karakter köti össze a két problémát, de műszakilag nincs közük egymáshoz. Bináris ide Kelt: Wikipédia,  2019. október 19., 08:16 (CEST)

Nem teljesen ugyanott mutatkozó, de szintén + jeles hibajelenséget én is találtam: a szerkesztők js oldalában és egy Mediawiki js-ben is sok helyen van '+' jel (az aposztróffal együtt) a kódban. Azt nem látom, hogy ez okoz-e hibát bárhol másutt, vagy hogy az adott szerkesztőt zavarja-e, mindenesetre a Speciális:Keresett_sablonok listában van belőlük pártucatnyi. Példának néhány:

Ezeket nem lehet valahogy felszámolni? A .js lapokba más szerkesztő nem tud belenyúlni, de a fent említett listában van egy csomó ilyen. Palotabarát vita 2019. október 18., 10:06 (CEST)
A pluszjel itt a JavaScript szöveg összefűző operátora, szándékosan van ott. – BáthoryPéter vita 2019. október 18., 10:24 (CEST)
És ha még több lenne belőle, leválasztva a szögletes zárójelet, akkor nem lehetne elkerülni a hamis keresett sablonok létrejöttét? Bináris ide Kelt: Wikipédia,  2019. október 18., 21:51 (CEST)
@Bináris: Elvileg a ['+'[Sablon: eltünteti őket a piroslink-listákról (a [['+'Sablon: csak a szócikkek közé teszi „'+'Sablon” prefixszel). – Tacsipacsi vita 2019. október 19., 01:05 (CEST)

Nem szögletes, hanem kapcsos zárójelek voltak halmozva. Ahol találtam, megszüntettem. Legalább már használtam a felületadminisztrátori jogomat, és nem hiába kértem. Sajnos elszomorítóan kevesen vagyunk. @Palotabarát: most nem lehet keresni, mert a lista gyorsítótárból jön, meg kell várni a következő frissítést. Ha találsz még ilyen hibát a következő frissítés után, akkor légy szíves, ne a lapokat, hanem a feleslegesen hivatkozott sablonokat sorold fel itt a {{cikk2}}(?) sablonnal, mert abból már rá tudok kattintani a hivatkozásokra. Bináris ide Kelt: Wikipédia,  2019. október 19., 09:41 (CEST)

@Bináris: rendben, figyelem majd, és kijegyzetelem ide, ha lesz ilyen Palotabarát vita 2019. október 19., 09:44 (CEST)

@Bináris: akkor itt az október 19-i frissítés szerinti lista. Kösz előre is, Palotabarát vita 2019. október 20., 00:59 (CEST)

Születéskori név hibásan jön át a WikidatárólSzerkesztés

  Függőben Gaja    2019. október 29., 15:03 (CET)

A {{személy infobox}}(?) sablonnak van egy születéskori név paramétere, ami szokás szerint megjeleníti a Wikidata megfelelő paraméterének (P1477) értékét. A Wikidatán ehhez a paraméterhez kötelezően meg kell adni a nyelvet is (hiszen ugyanazt a nevet különbözőképpen írhatjuk különböző nyelveken), és az ember azt várná, hogy a sabon a huwikin a magyar névváltozatot jelenítse meg (ha pedig ilyen nincsen, inkább ne jelenítsen meg semmit). Ehelyett az történik, hogy az infoboxban a P1477 valamennyi nyelvi változata megjelenik. Aki nem hiszi, nézze meg a Vlagyimir Konsztantyinovics Bukovszkij cikket.

Nyilván meg lehet kerülni a problémát úgy, hogy az infoboxba beírjuk a kívánt értéket, de azt szeretném, ha a mechanizmus rendesen működne. Tud ebben valaki segíteni?

(A probléma fentebb felmerült már a Peter Capaldi cikk kapcsán, de nem született igazi megoldás.)

Malatinszky vita 2019. október 29., 14:06 (CET)

Oroszszovjetként nincs magyar születési neve, töröltem; a tulajdonságot nem így használjuk. Bencemac A Holtak Szószólója 2019. október 29., 14:12 (CET)

Ebben az esetben nem kell megadni az eredeti nevét, mert az ugyanaz. Wikizoli vita 2019. október 29., 14:15 (CET)

Nézd, ha nagyon fontos, keresek egy férjezett nőt, akinek van a jelenlegi nevétől különböző leánykori neve, de nyilván enélkül is érted a lényeget, ami az, hogy a személy infobox sablon rosszul kezeli azt a helyzetet, hogy egynél több alakban van megadva a cikkalany születési neve. --Malatinszky vita 2019. október 29., 16:16 (CET)
Firstölhetjük, és akkor csak az első jelenik meg, de szerintem jobb ez így, mert így látjuk, hogy a Wikidatából törölni kell a felesleget. Kivéve persze, ha valóban több szuletési neve is van az illetőnek, amely bizonyos esetekben előfordulhat. Régebben volt egyetlenérték-kikötés a tulajdonságon, de közben pont az utóbbi esetek miatt lekerült. Lehet javaslatként vissza lehetne tenni. – Máté (vitalap) 2019. október 29., 16:25 (CET)

A konkrét problémára ez megoldást jelent(het), de mint Malatinszky kolléga jelezte, már Capaldinál én is belefutottam a hibába. Globális megoldás továbbra sincs a problémára. Ezért tettem rá egy függőben sablont, nehogy elússzon... - Gaja    2019. október 29., 15:03 (CET)

A nem latin betűs nevek magyaros átírását a magyaros átírás (P2719) minősítővel kell megadni, már csak a sablont kell megtanítani, hogy ha meg van adva, akkor hozza át. – Máté (vitalap) 2019. október 29., 16:08 (CET)

Ugyanúgy Capaldinál a cirill betűs változatnak minősítőként kellene szerepelnie megfelelő tulajdonsággal. – Máté (vitalap) 2019. október 29., 16:15 (CET)

Beépített Google docsos forrás archíválásaSzerkesztés

  Függőben Xia Üzenő 2020. február 11., 21:53 (CET)

@Tgr részére hagyom itt ezt a kérést. A http://www.mozinet.hu/hu/beveteli_adatok forrást nem tudom archiválni, mert Google Docsban töltik fel az adatokat és ezt sem az archive.org, sem az archive.is nem tudja szépen kezelni. A táblázatot ráadásul időnként lecserélik az aktuális filmekre. Tgr említette, hogy talán tud erre egy wikidatás megoldást nézni valahol és kérte, hogy véssem ezt fel ide. Köszönet előre is a segítségért. Xia Üzenő 2020. február 11., 21:53 (CET)

Első körben meg kéne kérdezni a Wikidatán, hogy beleférnek-e az (amúgy elég laza) nevezetességi kritériumukba az ilyen adatok, illetve vannak-e jogi aggályaik (a laikus véleményem szerint ez egy spin-off adatbázis, úgyhogy nem jogvédett); illetve ha nincs kifogásuk, akkor mi lenne az ideális adatstruktúra. Műszaki szempontból, látatlanban az OpenRefine tűnik a legalkalmasabb eszköznek; abba be tudsz tölteni CSV-t, automatikusan összeegyezteti a filmneveket a wikidata-elemekkel, kézzel összekapcsolhatod vagy létrehozhatod a hiányzókat, és utána fel tudja töltni az egyéb adatokat.

Ha a Wikidata nem működik, akkor a második legjobb megoldás letölteni, CSV-be konvertálni és feltölteni a Commons-ra (nem túl közismert, de a Commons tud CSV-t és más adattábla-formátumokat kezelni).

Esetleg meg lehet próbálni az Internet Archive-val felvenni a kapcsolatot, az automatikus weboldal-archiválón kívül egy csomó más módon is mentenek le dolgokat. (Hátránya, hogy ugyan alapvetően jóindulatúak, de egy nagyon kis csapat üzemelteti az IA-t, úgyhogy esélyes, hogy nincs energiájuk egyedi problémákkal foglalkozni.) --Tgrvita 2020. február 13., 07:05 (CET)

Szerkesztési ütközésSzerkesztés

  Függőben Szalakóta vita 2020. február 23., 18:56 (CET)

Mi lehet annak az oka, hogy egy wikiben nem működik úgy a szerkesztési ütközés úgy, mint a Wikipédiában? Ami történik: elmentődik mindkét szerkesztés, a győztes szó nélkül felülírja a vesztest. Hogy lehet ezen változtatni? Szalakóta vita 2020. február 21., 21:42 (CET)

Valószínűleg ősrégi MediaWiki változatot használsz. --Tgrvita 2020. február 26., 09:10 (CET)
Nem olyan ősrégi, igaz, nem is a legújabb. Tudtommal 1.30-as verzió. Csak a vitalapokon van szerkesztési ütközés. Szalakóta vita 2020. február 26., 20:35 (CET)
Én mostanában folyamatosan szerkesztési ütközésbe keveredek saját magammal, de ha figyelmen kívül hagyom és kilépek, ugyanúgy elmentődnek a szerkesztéseim. – HG vita 2020. március 18., 10:42 (CET)

Beszúrható IPA karakterek cseréjeSzerkesztés

  Függőben Gaja    2020. április 22., 13:18 (CEST)

Lehetséges lenne az, hogy valaki hozzáértő a szerkesztőrész alatti beszúrható karaktereknél, az IPA résznél az elavult „ʣ, ʤ, ʥ, ʦ, ʧ, ʨ” karaktereket rendre „d͡z, d͡ʒ, d͡ʑ, t͡s, t͡ʃ, t͡ɕ” alakokra cserélje? Ezen kívül valahová a karaktersor végére be kéne még tenni ezt a felső „ ͡ ” összekapcsoló jelet is, valamint jó lenne, ha a diakritikus jelek (pl.: „n̩, ʊ̯, ɔ̃” stb.) nem betűhöz lennének kapcsolva, hanem önálló gombot kapnának? Köszönöm! - Gaja    2020. április 5., 11:34 (CEST)

Bocs, most nincs rá időm, de a MediaWiki:edittools lapon módosítható (ezt csak adminok és felületszerkesztők szerkeszthetik). – Tacsipacsi vita 2020. április 6., 04:05 (CEST)
@Gaja: Az IPA-t megcsináltam, kérlek próbáld ki te is. A diakritikus karakterekhez még várnék ötleteket (konkrétan miképp legyen a megvalósítás). Bencemac A Holtak Szószólója 2020. április 6., 09:12 (CEST)

@Bencemac: Köszönöm. A diakritikus jelek összeolvadó karakterek, nem tudom, hogy gombra lehet-e őket csak úgy rakni. Ha igen, az IPA karakteres fájlban benne van az összes a „DIACRITICS” táblázatban. Szerintem egy külön blokkban lehetne mind a két IPÁ-s sablon előtt. Esetleg egy külön blokkban lehetnének még a tónusjelölő ékezetek is („TONES AND WORD ACCENTS”), de ha ez nincs, az sem baj. Nem tudom, hogy elég-e ez neked így, ha nem, kérdezz! - Gaja    2020. április 6., 11:26 (CEST)

@Gaja: Nem felejtettelek ám el, viszont van egy kis bibi; nem tudom kimásolni a karaktereket a fájlból (vagy valamit nagyon rosszul csinálok). Megtennéd, hogy beszúrod őket ide? Amúgy a blokkos megoldás kivitelezhető, szóval ha segítesz, secperc megcsinálom. Bencemac A Holtak Szószólója 2020. április 11., 09:31 (CEST)

A hivatkozott táblázat nem igazán másolható. Ezt tudnám felajánlani (a félkész állapotért elnézést kérek; itt szakadt meg a gondolkodásom):

IPA-jel Dec.
kód
Unicode IPA-
szám
Leírás
Tónusok külön
◌̏ 783 U+030F (516) Nagyon mély tónus ld. még (523)
◌˩ 745 U+.... (523) Nagyon mély tónus ld. még (516)
◌̀ 768 U+.... (515) Mély tónus ld. (522) is
◌˨ 744 U+.... (522) Mély tónus ld. (515) is
◌̄ 772 U+0304 (514) Normál tónus ld.(521) is
◌˧ 743 U+.... (521) Normál tónus ld.(514) is
◌́ 769 U+.... (513) Magas tónus lásd 742 is
◌˦ 742 U+.... (520) Magas tónus Lásd 769 is!
◌̋ 779 U+030B (512) Nagyon magas tónus ld. (519) is
◌˥ 741 U+.... (519) Nagyon magas tónus ld. (512) is
◌᷅ 7621 U+1DC5 (527) Mély emelkedő tónus ld. még (532)
◌˩˨ 745 744 U+.... (532) Mély emelkedő tónus ld. még (527)
◌̌ 780 U+030C (524) Emelkedő tónus ld. még (529) is
◌˩˥ 745 741 U+.... (529) Emelkedő tónus ld. még (524)
◌᷈ 7624 U+1DC8 (528) Emelkedő-eső tónus lásd még (533)
˧˦˧ 743 742 743 U+.... (533) Emelkedő-eső tónus lásd még (528)
◌᷄ 7620 U+1DC4 (526) Magas-emelkedő tónus lásd még (531)
◌˦˥ 742 741 U+.... (531) Magas-emelkedő tónus lásd még (526)
◌̂ 770 U+0302 (525) Ereszkedő tónus
◌˥˩ 741 745 U+.... (530) Ereszkedő tónus

Garamond vita 2020. április 11., 14:20 (CEST)

Köszönöm Garamondnak a segítségét, és itt vannak a hiányzó diakritikus jelek is: ◌̥◌̬◌̹◌̜◌̟◌̠◌̩◌̯◌̤◌̰◌̼◌̝◌̞◌̘◌̙◌̪◌̺◌̻◌̊◌̈◌̽◌̃◌̚◌˞◌̴ Remélem így megfelel. Ha mégsem, itt tudod őket generálni (a Diacritics gomb választása után): www.i2speak.com - Gaja    2020. április 11., 17:43 (CEST)

@Garamond, Gaja: Ha minden igaz, mindegyik megvan. Kérlek próbáljátok ki! Bencemac A Holtak Szószólója 2020. április 11., 18:21 (CEST)

Egy próba: [dɐ◌̰d͡ʒɘ◌˥t͡ɕɪ◌̺ʊ◌̯s] Na most ezzel csak az a baj, hogy az a szaggatott vonalas körnek nem kellene benne lennie, csak az összeolvadó karakternek..., pl. így: [dɐ̰d͡ʒɘ˥t͡ɕɪ̺ʊ̯s] - Gaja    2020. április 11., 19:36 (CEST)

@Bencemac, Gaja, bocsánat, a szaggatott körnek persze, hogy nem kell benne lenni, csak helykitöltő (hogy mutatni lehessen: alá teszi, fölé teszi, mellé teszi a diakritikust). Elnézést, azt hittem, természetes. (Én nem dolgozom ennyire gyorsan, tutymékolva rájön az ember.) De ott van mellette (mondjuk), hogy 745 741, akkor azt megbízható módon lehet írni, hogy &#745;&#741; és így néz ki: ˩˥. Én úgy csinálnám (bocsánat a más pennájával történő csalán-editálásért), hogy a címkéje a kattintandó karakternek tartalmazná a szaggatott kört, a letett kód meg nem.
Az alsó összekapcsolót ki kellene javítani, mert az igazából nem a &#8255;-ös kellene legyen, hanem az &#530;-as, mert utóbbi a kombinálódó jel, a mostani egy szélességgel rendelkező szimbólum. (A felső az stimmel úgy, ahogy Gaja írta, az valóban egy &#865; kódú jel.)
Azt megkérdezném még, hogy egyéb karakterek nem szoktak-e szükségesek lenni, mint ami amúgy is használatban volt eddig is, például valahol hozták a lengyel ryba [rᵻbɑ] esetét, amiben van egy ilyen hang: . (Decimális 7547-es kódpont.) Garamond vita 2020. április 11., 20:27 (CEST)

@Garamond: Igen, egyetértek. Ami a ryba-t illeti, utánanéztem. Eredetileg [ɨ]-vel írták le a hangot, de állítólag a jelenlegi kiejtését jobban írja le a [ɘ] hang. Nemt'om, nem beszélek lengyelül...   - Gaja    2020. április 12., 11:16 (CEST)

@Garamond, Gaja: Frissítettem a tónusokat. Sajnos nem látom módját, miképp lehetne „címkét” (kört) adni a karaktereknek. Biztos Ȓ (530) lesz az alsó összekapcsoló (csak biztos ami biztos kérdezem)? Bencemac A Holtak Szószólója 2020. április 16., 17:54 (CEST)
Ördögöt! Hogy lenne már 530! A közelében sincs, se decimálisan, se hexában, de még az IPA-száma sem annyi.
De legalább sejtem, hogy hogyan adhattam meg rosszul: nem másoltam valahonnan, hanem kézzel írtam be. Mégpedig úgy, hogy véletlenül egy sorral lejjebb billentyűztem (a kis numerikus billentyűzeten), 860 helyett 530-at! Mert hogy igazából 860! Mint könnyen ellenőrizhető. &#860; tehát  ͜ 
Bocsánat. Így jár aki nem elég lusta. Fujj. Kérem, legalább fél évre tiltsanak ki.
A címkézést nem tudom, hogyan lehetne megoldani. Az IPA-segédeszköz két helyen tud megjelenni, a szöveg fölött, meg alatt. Amikor felül próbáltam, akkor a következőt csináltam. Az IPA billentyűzetre rákattintottam és jobb gombbal kértem, hogy Vizsgálat. (Magyar rendszerem van és Chromium a böngésző, amiben ez történik.) Erre megjelent egy felsorolás, ami ilyenekből állt:
<span rel="ɧ">ɧ</span>
<span rel="x">x</span>
és így tovább. Ebben a rel utáni adja meg, hogy mit írjon be a rendszer a billentyűre kattintáskor, az utána következő pedig (a két kacsacsőr között) az jelenik meg a billentyű mezőn. Tehát például, ha átszerkesztettem ott helyben, akkor
<span rel="ɧ">hj</span>
<span rel="x">x</span>
esetén azt látom, mintha hj lenne a betű, de azt teszi le, hogy ɧ. (Ékezettel nem lett jó, nem olvasztotta össze!)
Amikor alul jelenik meg a billentyűzet, akkor is kipróbáltam, itt ilyen sorokat adott elő:
<a data-mw-charinsert-start="ʌ" data-mw-charinsert-end="" class="mw-charinsert-item" href="#">ʌ</a>.
Ez esetben is megnéztem, hogy a jobb oldali jelet kicseréltem a szaggatott kör (9676) és breve (774) jelpárosra (ezt már teszteltem, nehogy megint hülye legyek, és rossz számokat írjak, &#9676;&#774; tehát   ◌̆  ).
És ez viszont úgy néz ki, de mintha nem azt csinálná. (Nem teszi le a kódot.) Ne persze ez hályogkovács barkácsolás, igazi tini programozói stílusban. Egyébként azt is át kell gondolni, hogy tényleg célszerű lenne-e. Elég pici jelecskék ezek, nem jól látszanak a szaggatott karika alatt-fölött. Azért szoktam én folyó szövegben előszeretettel a {{Times}} sablonnal megjeleníteni őket, mert abban elő lehet írni nagyítást. – Garamond vita 2020. április 16., 20:32 (CEST)

Alakulgat, de a Ȓ tényleg nem jó. Talán ez: ‿ A többire meg lehet, hogy találsz megoldást az angol en:International_Phonetic_Alphabet cikkben, vagy itt, de talán ez is egész jó lehet... - Gaja    2020. április 17., 10:39 (CEST)

Tényleg ennyire rosszul fogalmazok? Írtam, hogy nem 530, hanem 860. És ott a példa. Amit bemásoltál, az nem az a jel. Csak hasonlóan néz ki. Ilyen különben van egy tucattal. A Wiki különféle szócikkeiben és segédleteiben söprögettem őket. Csak sajnos nem tudtam energiát fordítani rá, nem csak a vírushelyzet miatt, hanem egyébként is bonyodalmas. A munkaanyagaim megvannak, de nem adok rá linket, mert több energia megérteni, hogy mi jó benne, mi javítandó, mint nélküle boldogulni.
A legutolsó hivatkozást, amit írtatok, nem ajánlom. A Unicode ugyan igen sok fonetikai jelet szerepeltet az erre a célra szolgáló kódmezőben, de ezzel két baj van. 1) Jó néhányat nem fogadtak még el, csak javaslatként merült fel, vagy egy szakember egyéni megoldásaként. Ennél fogva túl sok haszna nincs a jelnek. 2) A leírásmódjuk többnyire gyökeresen eltér a fonetika gondolkozásmódjától, ők nem azt mondják egy jelről, hogy nazalizált n, hanem hogy kis latin n betű fent tildével. Tehát teljesen formai megközelítést használnak, nem tudni, mennyire lehet szükséges a jel, mire való, és hová célszerű csoportosítani. Viszont megkérdezni hagyom magamat, mert szerintem eléggé az összes szóba jöhető jelet kigyűjtöttem. – Garamond vita 2020. április 17., 14:17 (CEST)

Angol nyelvű kategóriaSzerkesztés

  Függőben Palotabarát vita 2020. június 30., 12:21 (CEST)

Sziasztok, jött megint egy angol nyelvű kategória: Kategória:Pages that use a deprecated format of the math tags. Nem találom a nyomkövető kategóriák közt (de az németben és az angolban sem), de nem látom a Mediawiki és a translatewikiben sem, legalábbis a magyar fordításban. Hol kell átírni, hogy magyar legyen? Palotabarát vita 2020. június 26., 09:28 (CEST)

A szócikkben? – Burumbátor Súgd ide! 2020. június 26., 10:22 (CEST) Nem szóltam. – Burumbátor Súgd ide! 2020. június 26., 10:25 (CEST)

Nem tudom, hogy a nyomkövetőben miért nincs benne, de itt kell majd átírni. – balint36 utaspanasz 2020. június 26., 11:12 (CEST)

Mert elfelejtették hozzáadni, phab:T256468. – Tacsipacsi vita 2020. június 26., 12:44 (CEST)
Az szerintetek miért van, hogy a Translatewikibe már a második regisztrációmmal nem tudok belépni? Nemcsak el vannak mentve a jelszavaim, de a másodikra még emlékszem is. Ráadásul míg az első regisztrációmmal vélhetően szerkesztettem, legalábbis a vitalapomra kaptam üdvözlő üzenetet, mégis azt írja, hogy nincs ilyen felhasználó, és nem is lehet kilistázni a korábbi szerkesztéseimet. Tudom, hogy nem Wikimédia projekt, de elég nehéz átírni bármit is, ha nem én felejtem el a regisztrációs adataimat, hanem ők. Na mindegy is, ha valakinek van annyi ideje, magyarítsa légyszi ezt a kategórianevet, most fél órányi küzdés után felforrt az agyvizem. Palotabarát vita 2020. június 26., 13:11 (CEST)

És azt lehet tudni, h mi az, ami elavult a <math> tag formátumában? – Winston vita 2020. június 26., 16:18 (CEST)

Ami nem (La)TeX. Az mw:Extension:Math#Tracking categories szakaszban van egy példálózó felsorolás; nem tudom, van-e még azon kívül elavult szintaxis. —Tacsipacsi vita 2020. június 27., 01:31 (CEST)

Úgy tűnik, hogy a minap "átért" a fordítás a Translatewikiből, így már magyar nyelvű kategóriában, a Kategória:Lapok elavult formátumú matematikai tagekkel nevűben gyűlnek a cikkek. (Ha valakinek nem tetszik a magyar kategórianév, bátran javítsa). Hát, mit ne mondjak, jó sokáig tartott, pont egy hónap volt. Kicsit még rajtahagyom a függőben jelzést, mert egy másik magyarításnak is "át kell érnie ide", de figyelemmel kísérem a változásokat, és ha rendeződik az ügy, átállítom megoldvára. Mindenkinek kösz a segítséget! Palotabarát vita 2020. július 30., 12:16 (CEST)

< br >Szerkesztés

  Megoldva

Sziasztok, kérdésem: mi a baj a html sortöréssel (< br >), hogy vandálkodásnak minősíti egy robot? Volt erről korábban megegyezés, hogy tilos? Ha igen, mit használjak helyette (pl. infoboxban)? Üdv Szkari vita 2020. július 19., 23:07 (CEST)

A < br >-rel nincs baj, bár újabban ajánlottabb a < br/ >. Amit nálad a robot törölt, az < /br > volt. Azt nem szereti. – Dodi123 vita 2020. július 19., 23:18 (CEST)

Kedves Dodi123, valami félreértés van. Nem használtam és nem is ismerem a < /br > -t, csak a sima < br > -t. A robot pedig nem törölte (most is ott van, enyém volt a szócikk utolsó változtatása), hanem "felcímkézte". – Amúgy mi a különbség a 3 féle br változat között? Üdv Szkari vita 2020. július 20., 01:02 (CEST)
Én itt találtam egy bot által törölt < /br >-t. Melyik szócikkben van az általad említett "felcímkézett" < br >? Vagy arra gondolsz, hogy a laptörténetben jelzi, hogy html-sortörés volt? Ezt nem tudom, miért jelzi, de számunkra semmi jelentősége nincs. Nem kell vele foglalkozni. A < br > helyett a < br/ > alakot egy fejlesztés miatt ajánlják, mert valójában ez a szabályos, de mindkét alak működik egyébként. A < /br > alak hibás, de bajt nem okoz. – Dodi123 vita 2020. július 20., 09:07 (CEST)
@Dodi123: Ez az a szócikk, de az nem az én szerkesztésem volt. Én 2 napja szerkesztettem, és csak a sima < br > sortörést használtam. Igen, a laptörténetben jelzi, a vandálszűrő naplóban, hogy "felvandálozta", és ettől megijedtem, hogy úristen, mit tettem :) Tacsipacsi válasza alapján szólni kéne a robinak, hogy ezután ne ijesztgessen senkit. Üdv: Szkari vita 2020. július 21., 04:35 (CEST)
@Dodi123: Ezt a fejlesztést, ami miatt a <br /> alakot ajánlották (XHTML), évekkel ezelőtt elvetették. A HTML5-ben, amit egy ideje már a Wikipédia is használ, ismét a <br> a szabványos.
@Szkari: A <br> listák készítésére nem való, ugyanis maga a kód kevésbé írja le, hogy mit akarunk, így pl. képernyőolvasó programmal nehezebb megérteni. Helyette használható a {{plainlist}}(?) sablon, ami ugyanúgy jelenik meg, csak a háttérben értelemtükrözőbb, így akadálymentesebb HTML-kódot generál. – Tacsipacsi vita 2020. július 20., 13:26 (CEST)
@Tacsipacsi: Ez nekem túl magas... Infoboxon belül használtam a < br > -t, hogy az alany 3 gyermeke új sorba kerüljön. Itt sem jó? Sablonon belül is lehet sablont használni? Üdv: Szkari vita 2020. július 21., 04:35 (CEST)
@Szkari: Sehol sem jó a <br> felsorolásként, ugyanúgy megzavarja a képernyőolvasót infoboxban, mint máshol. Igen, sablonban is lehet sablont használni (egy bizonyos mélységig, de általában előbb válik teljesen áttekinthetetlenné a kód, mint hogy az ember beleütközne a korlátba). – Tacsipacsi vita 2020. július 21., 23:29 (CEST)
@Tacsipacsi: köszönöm, cseréltem. Üdv Szkari vita 2020. július 22., 01:34 (CEST)
@Tacsipacsi: Bocs, ránéznél erre? Az infoboxban a plainlist sablonon belül használtam sortörést vizuális céllal, asszem helyesen. Ha megerősítesz, akkor tényleg értem a dolgot. Üdv Szkari vita 2020. július 29., 17:40 (CEST)
@Szkari: A HTML-kód helyes, bár szerintem ebben az esetben teljesen felesleges a sortörés, sőt, mobilon kifejezetten csúnyán tud kinézni (mobilon nem fix az infobox mérete, hanem akkora, amekkora a képernyő). – Tacsipacsi vita 2020. július 30., 13:10 (CEST)
@Tacsipacsi: Köszönöm szépen. A mobilverzióhoz sajnos nem értek, de asztali monitoron csúnya volt, hogy a New / York két sorba tört. Most megoldottam nem törhető szóközzel. Nagyon jó lenne, ha ezek a kódok és szerkesztést könnyítő elemek egy könnyen megtalálható helyen volnának összegyűjtve a Wikin, hogy segítsetek vele a gyakorlatlanabb szerkesztőknek. Amiről hallomásból tudok vagy Wordből ismerem, a wikikódját hosszas nyomozással vagy megtalálom, vagy nem... Üdv: Szkari vita 2020. július 31., 02:46 (CEST)
Az ideális megoldás, gondolom, egy olyan listasablon lenne, ahol minden listaelem külön sablonparaméter, és akkor könnyen készíthető belőle valamilyen szemantikus HTML, mondjuk egy <li>, ami aztán formázható normál listaként vagy egy sorba (de listaelemen belüli sortörések nélkül), akár képernyőmérettől függően is. --Tgrvita 2020. augusztus 5., 12:45 (CEST)
@Tacsipacsi: Köszönöm. Hogy ismét a <br> a szabványos, ezt nem tudtam. – Dodi123 vita 2020. július 20., 13:42 (CEST)

Hiányzó keretSzerkesztés

A vasútvonalakról és metróvonalakról szóló szócikkek infoboxának a tetejéről hiányzik egy kb 1 pixel vastag keret. Nem lenne baj, ha az alatta lévő táblázatnál viszont nem lenne. Valaki tudna varázsolni egy keretet az infobox tetejére? Példa rá: Madrid–Valladolid nagysebességű vasútvonal.

Valószínűleg a {{BS-daten}}(?) sablonban kell keresgélni. – B.Zsolt vita 2020. július 27., 17:49 (CEST)

@B.Zsolt: Ott van az a keret, csak éppenséggel fehér, nem sötétszürke. A {{BS-daten}}-nek semmi köze ehhez, az csak a cím alatti (sötétszürke keretű) táblázatrészért felelős, a cím keretét a {{Vasút fejléc}}(?) és a {{BS-header}}(?) együtt(nem)működése készíti, és az infoboxok jelenlegi felépítésével praktikusan nem javítható. Az kéne, hogy a {|{{Vasút fejléc}} helyett egyetlen sablonhívásból álljon a táblázat eleje, azaz a {| kódot sablon generálja, és ne közvetlenül a cikkben legyen benne. Ezt sablonoldalról szívesen megcsinálom, viszont botozást is igényel, ami saját bot nélkül nekem nem megy. – Tacsipacsi vita 2020. július 28., 12:11 (CEST)

Újabban egész jó az osztrák net (lásd közreműködéseim szakasz gyarapodását), a szabadidővel még problémák vannak. Ha nincs jelentkező, a botozást vállalom, de pontos időpontot nem tudok ígérni. A vasútvonalak infoboxainak kezdete valóban elég érdekes, 10+ éves "egyszermajd megcsináljuk" hátralék. Talán összeköthető lenne a paraméterek magyarításával is, ha már a sablon támogatja a magyar neveket. De azért a német nevek is maradjanak működőképesek. – B.Zsolt vita 2020. július 28., 23:13 (CEST)

A típusosság hiánya a magyar wikipédiánSzerkesztés

Korábban felvetettem, hogy a régi default beállításom miatt egy csomó magyarral azonosnak látszó, főleg fonetikai jel (pl. egy : -hoz teljesen hasonló fonetikai jel, vagyis ":" helyett "ː") került az általam írt cikkekbe. De egyrészt kaptam segítséget ennek a régebben default beállításnak az átállítására, másrészt meggyőztek, hogy az ilyen hibák könnyen megkereshetők és kijavíthatók. És nincs is olyan sok belőlük. Illetve kevés szerkesztő kapott defaultként ilyen beállítást mint én.
De:

  • 1. Azóta is találkozom rejtélyes hibákkal. A helyesírás ellenőrző bepirosozza a helyesnek látszó szót. Leggyakrabban az előtte lévő szóköz helyett van valami szóközzel teljesen azonosnak látszó karakter, mert amikor átírom, akkor eltűnik a piros aláhúzás.
  • 2. Egyes szavaknál még mindig betűhiba van, mert át kell írnom a teljes szót, és csak akkor tűnik el a piros aláhúzás.
  • 3. Pl. ma a Kóti Árpád szócikkben találtam egy, a "Liberté ‘56 (2007)" a szövegben láthatatlan karaktert.

Az utóbbi időben írtam pár olyan cikket a magyar wikipédián, ahol speciális idegen karaktereket, kínait, hébert, arabot, stb. kellett használnom, és azt vettem észre, hogy a magyar wikipédián gyakorlatilag nincs vagy nem használt a nyelvi típusosság, vagyis az idegen karakterek minden jelzés nélkül vannak beágyazva a magyar szövegbe. Ennek azonban az a következménye, hogy gyakorlatilag a magyar wikipédián megállapíthatatlan, hogy:

  • 1. Mely szócikkben vannak a magyar szövegben hibás külföldi vagy egyéb nem magyar szövegbe való karakterek. (például beszkennelt szövegfelismerős változatból bekerült hibák.)
  • 2. Nem állapítható meg, hogy vannak-e olyan magyar oldalak, amikben mondjuk a kínai szövegbe hiba folytán japán karakter is szerepel, vagy mondjuk héber szöveg karakterei közé keveredett más jel.


Szerintem már most is borzasztó feladat lenne helyreállítani az erős típusosságot, de minél tovább várunk ezzel, annál nagyobb lesz a baj. Ráadásul nekem úgy tűnik, a magyar wikipédián most nincs is meg ennek a feltétele. Vagyis nincs meg minden karaktertípushoz az idegen szöveg beskatulyázáshoz hasonló wikipédia elem (lang-jp, lang-he, stb. skatulyázható változata kapcsos zárójelek között precízen). Köszi: ZorróAszter vita 2020. július 29., 18:38 (CEST)

Pl. Atobot 2020. július 25., 15:10‎ -kor a Azázél az irodalomban, filmművészetben és a kultúra egyéb területén szócikkben a "horrorfilmben" szóban talált valamit, mégpedig 6 bájtnyi fölös valamit. ZorróAszter vita 2020. július 29., 20:12 (CEST)

Az Autowikibrowser sok ilyen hibát képes javítani, de mivel ezek apróságok sok ember szemében, nem nagyon támogatott az efféle tisztító-karbantartó munkálatok végzése. – B.Zsolt vita 2020. július 29., 23:32 (CEST)

Igen, de ez a keresésből is kiejti a hibás formát. Például valószínűleg a "horrorfilm"-es hiba miatt azt a lapot nem találja meg a kereső a "horrorfilm" szóra keresve. Közben az ugrott be, hogy lehet, hogy a szóban két betű nem UTF-8-al hanem utf-16-al lett kódolva? Az pont 6 bájt különbség ha jól számolok. Vagy nem lehet mivel nincs benne ékezetes betű? ZorróAszter vita 2020. július 30., 07:01 (CEST)
Hogy mi? Mióta? – balint36 utaspanasz 2020. július 30., 00:37 (CEST)
Azt hiszem 2019. október 14-n jeleztem itt, de nem találtam az archivumban. Lehet hogy nem "A szövegszerkesztőm hibája?" címet adtam neki annak idején. ZorróAszter vita 2020. július 30., 07:01 (CEST)

A számos Unicode ellenőrző valamelyikébe (pl.) átmásolva az érintett szót jobb képet kapsz arról, hogy mi történik. --Tgrvita 2020. július 30., 15:01 (CEST)

Köszi. Megnéztem. Két "U+200B : ZERO WIDTH SPACE [ZWSP]" karakter van láthatatlanul az elején, de az Atobot állítólag 6 bájtot távolított el, ez meg csak négy. De nem is a konkrét példák az érdekesek, hanem hogy a magyar wikipédián minimális típusosság sincs, aminek az a következménye, hogy az esetek többségében lehetetlen megmondani, hogy egy oldal helyes-e, vagy hibás, csak első pillantásra hasonló karakterek vannak benne. És ez megakadályozza a hibás oldalak listázását és persze a javítást is. ZorróAszter vita 2020. július 30., 15:52 (CEST)
Az U+200B UTF-8-ban három bájt. Az idegennyelvű szövegrészletek megjelölésének hasznosságát nem vitatva, itt azért nem az látszik az alapproblémának. --Tgrvita 2020. július 31., 12:53 (CEST)
(Akkor megvan a 6 bájt.)
"itt azért nem az látszik az alapproblémának" : Valóban. Ezek olyan hibák, amik sima kereséssel is megtalálhatók, mert ezek az idegen karakterek valószínűleg minden szövegben idegenek. Amit feszegetni szerettem volna azok olyan hibák, amik csak akkor kereshetők, ha a szövegben a nyelvek el vannak különítve és meg vannak nevezve. ZorróAszter vita 2020. július 31., 18:24 (CEST)
Úgy értem, ha a szerkesztőfelületed véletlenszerűen láthatatlan karaktereket szúr a szövegbe, akkor az alapprobléma nem az, hogy ezek a karakterek nehezen kereshetőek, hanem hogy el van állítódva a szerkesztőfelületed. --Tgrvita 2020. augusztus 1., 22:06 (CEST)
Kb. egy éve is mondtam, hogy nem szoktam piszkálni a beállításaimat. Az egy évvel ezelőtt jelzett hiba is pár hónappal korábban jelentkezett. Erre a mostani hibára is több mint egy hónapja de hogy mennyivel, arra nem emlékszem. Lehet hogy három.
És azt hiszem, előbb volt az a hiba, hogy át kellett írnom a szót kézzel, hogy eltűnjön a piros aláhúzás. És mintha azután jött volna elő az, hogy a szóközt kellett átírni. Bár most hogy ezt írom, az az ellentmondás van benne, hogy hogyan jöttem rá, hogy most már elég csak a szóközt átírni. De a lényeg, kizártnak tartom, hogy a hiba nálam lenne. Szerintem valami változtatás volt a wikipédia jávás szövegszerkesztőjében és azzal jött elő a hiba. Méghozzá két változtatás is. ZorróAszter vita 2020. augusztus 2., 09:02 (CEST)

Hiányzik egy betű a görög ábécébőlSzerkesztés

Az alsó legördülő karaktermenü újgörög átírásási táblájáról hiányzik a C és a c latin betűkhöz hasonló karakter. A bizánci ortográfiában (igaz, ez nem új-, hanem középgörög) rendszeresen megjelenik a szigma helyén, de manapság is használják, főleg ha csupa nagybetűvel írnak valamit, ekkor szummaként. Bele kéne tenni, hogy ne latin betűsként jelenjen meg egy ilyen feliratban egy karakter: ΒΑCΙΛΕΥC. – LA pankuš 2020. július 30., 10:40 (CEST)

Megoldódott, @Laszlovszky András:? Amiatt kérdezem, mert itt semmi sem lett linkelve, hogy honnan hiányzik. Én pedig csak a görög ábécét néztem, de abban az újgörög szó nem szerepel. Szép napot kívánok! Apród vita 2020. augusztus 2., 13:13 (CEST)

@Apród: Azért nincs linkelve, mert azt nem tudom linkelni, ezért csak leírtam, hogy a szerkesztőablak bal alsó sarkában lévő legördülő menüből kiválasztható fontkészletekről van szó. Az újgörög ábécében nem szerepeltetik maguk a görögök sem, miközben egyébként használják. – LA pankuš 2020. augusztus 2., 13:30 (CEST)

Ja, így értem már melyikről van szó. Apród vita 2020. augusztus 2., 13:38 (CEST)

Különben nem a műszakira jöttem volna. – LA pankuš 2020. augusztus 2., 14:03 (CEST)

Rejtélyes piros linkké válás a Sportműhely/Új cikkeink oldalonSzerkesztés

Az elmúlt hetekben ez már vagy a tizedik alkalom, hogy egy megmagyarázhatatlan jelenségbe futok bele. Van ez az oldal: Wikipédia:Sportműhely/Új cikkeink, ahová a legfrissebb sporttal kapcsolatos szócikkeket szoktuk felvésni. Az utóbbi időben rendre előfordul (velem legalábbis), hogy ha bemásolok egy cikkcímet, akkor az átlag 10-ből 1 alkalommal piros lesz. Ezt még akkor lehetne magyarázni, ha kézzel írnám be (elgépelés, billentyűzet más karaktert használ, akármi), de itt nem erről van szó, hanem arról van szó, hogy kijelölés, másolás, beillesztés. Ha ugyanígy kijelölöm a címet még egyszer és újból beillesztem, akkor meg jó szokott lenni, pedig semmin nem változtatok, de csak akkor, ha az egész sort átírom, tehát a kapcsos zárójeleket is, ha csak azt ami közte van, attól nem lesz jó, akkor sem ha kézzel írom át (tehát gyanítom hogy a zárójelek is ludasak lehenek). A legfrissebb hiba, és a javított változat. Bár szemre nincs különbség, minden esetben 3 bájttal csökken a lap mérete. Valakinek van tippje ez miféle bug és mi okozza? – XXLVenom999 vita 2020. július 31., 14:47 (CEST)

@XXLVenom999: Ebben a példában a záró zárójel elé egy (két szakasszal fentebb is emlegetett) U+200B Zero Width Space karakter került. Hogy honnan, arra ötletem sincs, de úgy lehet észrevenni, hogy a rossz változatban ha a nyílbillentyűkkel végigmész a link kódján, a bezáró zárójel előtt látszólag kétszer kell lenyomni a billentyűt ahhoz, hogy egyszer odébb menjen. A javításhoz egyszerűen ki kell törölni ezt a karaktert ugyanúgy, ahogy bármilyen látható karaktert is törölnél – ha a kurzor közvetlenül a zárójel előtt van, akkor backspace-szel, ha a ZWSP karakter előtt, akkor meg a Delete-tel. (Vagy átmásolod a szöveget egy olyan programba – pl. Vim –, ami láthatóvá teszi ezeket a láthatatlan karaktereket.) – Tacsipacsi vita 2020. július 31., 15:48 (CEST)
@Tacsipacsi: Köszönöm az infót! Kíváncsi vagyok kiderül-e mi okozza ezt. – XXLVenom999 vita 2020. július 31., 18:54 (CEST)

Sok hibakeresést segythetne, ha a Wiki szerkesztője is ki tudná írni ezeket a láthatatlan karaktereket. Nincs efféle javaslat a fejlesztők felé? – B.Zsolt vita 2020. augusztus 2., 00:47 (CEST)

Ha bekapcsolod a szintaxiskiemelést (ceruza ikon az eszköztáron), az tesz oda egy piros pöttyöt. Ha nincs szintaxiskiemelés, akkor a szerkesztő egy egyszerű HTML <textarea>, aminek a megjelenéséhez a MediaWikinek nem sok köze van, de talán még böngészőkiegészítő sem tud mit csinálni vele, csak magában a böngésző C++-kódjában lenne módosítható. – Tacsipacsi vita 2020. augusztus 2., 12:48 (CEST)
Kellemetlen dolgok ezek. Például a Wikipédia szoftver (magyar felületen) a Figyelőlista előállítása során szisztematikusan elhelyez ezekbe a listáiba LEFT-TO-RIGHT MARK szimbólumokat (U+200E, decimálisan 8206). Nem is keveset, minden sorba négyet. Ugyancsak nem láthatóak. (Gondolom, valamilyen algoritmus úgy volt egyszerű, hogy akár van jobbról-balra szövegrészlet, akár nincs, időnként visszaállítják az alap kiírási irányt. Visszaélve azzal, hogy a böngészők nem jelenítik meg ezt a karaktert.)
Jegyzettömbben sem látszik. De megfigyelhető az említett jelenség, hogy „kétszer kell a jobbra nyilat billentyűzni, hogy egyszer tovább lépjen”. Én magam is csak úgy vettem észre, hogy sokszor a FAR manager szövegszerkesztőjét használom. Mert az viszont megjeleníti! – Garamond vita 2020. augusztus 2., 14:46 (CEST)
Gondolom, egyedi fonttal meg lehetne oldani, hogy láthatóak legyenek. Vannak böngészőkiegészítők, amik valamilyen módon kezelni próbálják ezt (pl), bár kétlem, hogy a gyakorlatban jól használhatóak lennének. Azt nem lenne túl nehéz megoldani, hogy előnézetben vagy akár szerkesztés közben mutasson a szerkesztőablak alatt/felett valami figyelmeztetést, ha láthatatlan karakterek vannak (kérdés, mennyire gyakoriak a legitim láthatatlan karakterek). Az érdekesebb kérdés persze az, honnan kerülnek elő ezek a karakterek? --Tgrvita 2020. augusztus 5., 12:38 (CEST)
Vandálszűrővel lehetne még próbálkozni, de megint csak a hamis pozitívok gyakorisága a kérdés. --Tgrvita 2020. augusztus 5., 14:48 (CEST)

Hogy honnan kerülnek elő? Erre sok rossz megoldás létezik. A legegyszerűbb lehetőség, hogy valahonnan kijelölök egy szöveget és szimpla Ctrl-C, Ctrl-V útján beszúrom. Tekintve, hogy bizonyos karakterek nem látszanak vagy nem megfelelően látszanak, észre sem fogom venni.

Kereséssel, nem szisztematikusan, de megnéztem a magyar Wikipédia szövegét, hogy hol és hányszor fordul elő például az emlegetett U+200B jel.

Hát elég sokszor. A továbbiakban néhányat mutatok az így találtakból, a jel elé beszúrok egy téglalapot, mert maga az említett szimbólum ugye nem látszik, sem szerkesztési, sem megjelenítési nézetben. (Elnézést, nem voltam nagyon pedáns, inkább az olvashatóságra helyeztem a hangsúlyt. De meg lehet találni ennek alapján a tényleges szövegeket.)

Budapest–Székesfehérvár-vasútvonal [[Magyarországi vasútvonalak listája|30a]]█‎
Budapest–Székesfehérvár-vasútvonal ''iparvágány az [[█‎Budafoki Élesztő és Szeszgyár Rt.|Élesztőgyár]] felé ({{vvr|40a|40a}})''
Magdalena Eriksson [[Kategória:A Hammarby IF női labdarúgói‎█]]
Magdalena Eriksson [[Kategória:A Djurgården női labdarúgói‎█]]
Réseau Ferré de France logó = <!-- Commented out because image was deleted: [[Kép:Rff.gif‎█]] -->
A Szerelem-sziget, a Fejes-völgy és a Veszprémvölgy <!--Fájl:Jezsuita templom oldalról.jpg|A jezsuita templom oldalról █‎-->
Wikipédia:Felküldési útmutató Érdemes jelezned, hogy a szöveg átolvasásra, lektorálásra szorul (lásd: [[Wikipédia:Sablonok listája/Karbantartás‎█|karbantartási sablonok]]).
Vita:Kincsem (versenyló) Egyszerűen a »macska« néven szerepel most már a szócikkben. 2016. szeptember 25., 17:06-kor‎█ volt az utolsó szerkesztés, ezt az állapotot kezdtem bővíteni.
Wikipédia:Táblázatok A Lásd még alatt: *[[█‎█‎HTML-színkódok]][1]
Vita:Tartós állapotú meghajtó Ne járjunk ezzel is úgy, mint a "véletlen elérésű tár" kifejezéssel. {{ai|217.21.16.26}} 2012. május 11., 11:13█‎
  1. Igen, két ilyen kód is van a sorban egymás mellett, a HTML rövidítés előtt!


A válogatás nem arányos. Például két kikommentezett részlet is szerepel benne. Továbbá a Vita névtérben lényegesen több előfordulás van, mint máshol.

Még egyet. De ez más. A szócikknél a 2. jegyzetben van egy római Ⅳ számjegy. Ezt igen ritkán használjuk, csak a Unicode-elegancia fanatikusainak célszerű. Mert például egy I és V egymás után írásával keresve nem találják meg a keresők. (Ellentétben például a repülő ékezetes betűkkel, amelyeknél az algoritmusok összerakják az összevont betűt.) Azért került ide, mert ez a karakter is kívül esik a szokásosan használt kódtartományon (8547-es a decimális kódja).

Hej, Dunáról fúj a szél Ⅳ Allegretto scherzando. Kousuke Takahashi█‎

Ezek a találatok adnak tippet, hogy honnan kerülhettek rejtélyes kódok a legális szövegek belsejébe. De nem mondanám, hogy értem a dolgot. Mégis csak az lenne a jó, ha szerkesztés közben látnánk, amit most eldug előlünk az informatikai környezet. – Garamond vita 2020. augusztus 5., 16:15 (CEST)

@Tgr: A vandálszűrőben az a jó, hogy nem is feltétlenül kell úgy csinálni, hogy a szerkesztő lássa. Lehet azt, hogy egy darabig csak címkéz, és aztán megnézzük, hogy mennyi a hamis pozitívok aránya. Ha elég kicsi, akkor onnantól figyelmeztethet is. Ha sok a hamis pozitív, akkor meg maradhat a címkézés állandóra, ahogy pl. a <br> esetében is van. – Tacsipacsi vita 2020. augusztus 5., 17:53 (CEST)

@Tacsipacsi kolléga ugyan nem szólt hozzám, de mégis az az érzésem, hogy látta a megjegyzéseimet. Az adott szempontból tekintve mindegyik talált példa a jel tartalmilag hibás alkalmazását mutatja, mert nem volt semmi ok a bal-jobb és jobb-bal írásirány jelzésére. (Formailag viszont teljesen hibátlanok!)

Én, gondolom, a régimódi kisebbség vagyok. Aki forrásalakban szeret szerkeszteni, de még ott is szeretné látni, hogy mi az, ami a keze között van. Most ugye nem látom. Még nem olyan régen folyt egy eszmecsere olyan, illetéktelenül a szövegekbe került jelekről, mint például a kettőspontnak („:”, kódja 58) látszó „ː” jel, ami valójában a hosszú hangokat jelző fonetikai szimbólum (kódja 720). (Van persze két különbség: az egyik, hogy az általam bemutatott esetek, mint mondtam is, helyesek. Legfeljebb néha vagy gyakran zavaróak. A kettőspont-szerű jel viszont tévesen került a valódi kettőspont helyére. A másik különbség, hogy az egyik fajta extremitást forrás és megjelenített formában egyaránt jól látom, a másik fajta rejtőzik.) – Garamond vita 2020. augusztus 5., 22:12 (CEST)

Megjegyezném, hogy ezek eddig olyan hibák voltak, amiket a piros aláhúzás jelzett. De rengeteg olyan hiba lehet, amit nem jelez a helyesírásellenőrző, de például működési zavart okoz. Például miatta kiesik a lap a keresésből. Vagy például a Kóti Árpád szócikkben találtam egy, a "Liberté ‘56 (2007)" a szövegben lévő láthatatlan karaktert. Pontosabban google Chrome jelzi egy fekete téglalappal, a Mozilla viszont nem. A helyesírásellenőrzőt viszont láthatóan nem zavarja. Az ember azt hihetné, hogy csak a "Liberté" nem tetszik neki. ZorróAszter vita 2020. augusztus 6., 08:06 (CEST)

Elfelejtettem mondani, hogy ez egy "U+0090 : <control> DEVICE CONTROL STRING [DCS]"
ZorróAszter vita 2020. augusztus 6., 08:25 (CEST)

Én meg harmadszor állítom le magamat, hogy ne javítsam ki a Kóti Árpád szócikket. De aztán eszembe jut, hogy hiszen pont most hozzuk fel példának, már nem is először. Akkor inkább ott hagyom. (Megkérhetlek, @ZorróAszter, hogy majd Te javítsad, hogy nekem ne jusson többet eszembe a nyüzsgés?)
A Liberté utáni jelet a Firefox is megjeleníti, csak nem téglalapként. Ha kijelölve a szöveget átmásolom egy jobban átnézhető fájlba, akkor látszik, hogy ott van az a karakter, csak a renderelő eldugja, a képernyőn nulla a szélessége. (Mármint ez olvasási nézetben történik így, szerkesztő felületen feltűnően mutatja.) Ez a hiba egyébként szerintem súlyosabb, mint a többi szóba került, mert a DCS karakter szemantikailag nincs ott helyén. (Akár látszik, akár nem.) A balról-jobbra vezérlő és hasonlók lehetnek a talált helyeken, csak jobb lenne, ha nem lennének. (Viszont hajlok arra, hogy az említett szócikkben tényleg csak a véletlenek kölcsönhatásából jött létre az U+0090.) – Garamond vita 2020. augusztus 6., 13:58 (CEST)

A Garamond által hozott példákban szócikkcím vagy dátum mellett van a ZWSP, úgyhogy ezeket nyilván valamilyen szoftverfelület generálja, csak be kell azonosítani, hogy melyik az. (A friss változtatások listája lenne a kézekfekvő tipp, de az csak LRM-eket szúr be, ZWSP-t nem.) A DCS weboldalakon nem igazán használatos, gondolom onnan ered, hogy terminálból másolsz valami színes szöveget, és a clipboard szoftver nem elég okos ahhoz, hogy az escape karaktereket eltávolítsa. --Tgrvita 2020. augusztus 6., 12:39 (CEST)

Nem tudok hozzászólni, ugyanis ez a DCS nem az én szerkesztésemmel került bele a szövegbe.
Viszont szerintem hemzseghetnek a magyar wikipédián az ilyen vagy hasonló hibák, és ha továbbra is úgy marad a magyar wikipédia, hogy az idegen nyelvű és egyéb karakterek egyszerűen be vannak inzertálva a magyar szövegbe minden jelzés nélkül, akkor ezek a hibák csak tovább szaporodnak és kiszámíthatatlan, hogy mikor üt vissza végképp például kereséseknél otrombán hiányos találati listák formájában. Ezeknek a hibáknak egy része persze sima kereséssel megtalálható, azonban az utf-8 karakterkészlete túl nagy ahhoz, hogy ilyen jellegű hibákat ilyen módon szűrjünk. Tehát el kellene kezdeni áttérni egy erős nyelvi/karakterkészleti típusosságra. ZorróAszter vita 2020. augusztus 6., 12:57 (CEST)

A Más nyelveken lista és a Wikidata-adatlap link nem jelenik meg a szócikk oldalánSzerkesztés

Kedves Valaki!
Tegnap feltettem a Namagiri Thayar cikket, és a wikidata oldalon is beírtam a magyar változatot. De a magyar változatnál nem jelenik meg sem a wikidata link, se a külföldi változatok listája. Míg pl. az angol változatnál (https://en.wikipedia.org/wiki/Namagiri_Thayar) ott a listán a magyar változat. Köszi: ZorróAszter vita 2020. augusztus 3., 07:17 (CEST)

Ugyanez a helyzet itt is: Jönnek a kacsák. – Vépi vita 2020. augusztus 3., 07:30 (CEST)

Hmmm, én mind a két oldalon látom a teljes listán. Nem lehet, hogy korábbi változat bentmaradt nektek a gyorsítótárban? – balint36 utaspanasz 2020. augusztus 3., 10:07 (CEST)

@Vépi, ZorróAszter: elég gyakori, hogy kell csinálni egy nullszerkesztést (megnyitni a cikket szerkesztésre, majd változtatás nélkül elmenteni) ahhoz, hogy átvegye a Wikidatában véghezvitt változásokat. Ez vonatkozik mind a nyelvközi linkekre, mind mondjuk az infoboxban látható változásokra (illetve a nullszerkesztésig nem látható változásokra). Palotabarát vita 2020. augusztus 3., 10:16 (CEST)

Most már mindkét cikkben látható, anélkül, hogy bármit csináltam volna. Viszont korábban hiába nyomogattam a „frissítőgombot”. Engem ez az egész arra emlékeztetett, amikor nem is olyan rég egyáltalán nem jelent meg a Más nyelveken, azaz nem lehetett onnan hozzáadni egy cikket a WD-hoz. – Vépi vita 2020. augusztus 3., 10:19 (CEST)

@Vépi: vigyázz, mert a frissítés gomb megnyomása és a nullszerkesztés nem ugyanaz! Feltehető, hogy miután ide kiírtátok a problémát, valaki csinált egy nullszerkesztést, és azóta látod te is. Vagy csak felülíródott a számítógépeden/internetszolgáltatód cache-ében a korábbi változat egy újabbal. Szóval nem kell feltétlenül aktív közreműködőnek lenni, hogy módosuljanak az adatok, csak éppen nem tudod kiszámítani, hogy mikor látszanak a friss adatok. Ezért tanácsos saját magadnak egy nullszerkesztést csinálni, ha a Wikidatában javítottál valamit. Ez nem újkeletű, elég régóta így van, vagyis nem a közelmúltban romlott el valami. Palotabarát vita 2020. augusztus 3., 10:45 (CEST)
Kedves Palotabarát!
Szerintem biztosan nincs így. Én most találkoztam ezzel a hibával először, pedig elég sok cikket tettem fel az utóbbi időben is. Még sosem fordult elő, hogy fél napig ne látszódjon a változtatás. A max. öt perc volt. Különösen hogy az angol változatban látható volt a nyelvi linkek között a magyar változat. ZorróAszter vita 2020. augusztus 3., 10:55 (CEST)
Lehet, hogy valami más gond is van. Nálam nagyon régóta ilyen, de a nullszerkesztés mindig megoldotta, az újratöltés nem mindig. Palotabarát vita 2020. augusztus 3., 12:13 (CEST)
Azért nem szokott olyan túlságosan sűrűn előfordulni, ezért lehetséges az is, hogy most láttad először. Egyébként van egy óra segédeszköz, amit ha használsz, ugyanúgy frissíti a gyorsítótárat, csak nem kell megnyitni szerkesztésre a lapot/szakasz, még nullszerkesztésre se. – balint36 utaspanasz 2020. augusztus 3., 12:22 (CEST)
Kizártnak tartom a cache problémát. Annál is inkább, mert amikor Vépi olvtárs csatlakozott, megnéztem az általa mondott oldalt és ott sem voltak meg a linkek, pedig azt ezelőtt nem nyitottam meg. ZorróAszter vita 2020. augusztus 3., 13:08 (CEST)
Mellesleg a nullszerkesztés szerintem hályogkovácsolás. Ha ugyanis a szerkesztő úgy működik, mint minden rendes szerkesztő, akkor nem szerkesztés esetén, tehát mondjuk egy x betű beírása és törlése esetén nem menti le a teljesen azonos tartalmú fájlt, hanem kilép anélkül, hogy bármit csinálna. Következésképpen a modify dátum/idő nem változik, tehát a cache nem frissül, ha a cache úgy van beállítva, hogy az oldalt ne kérje le csak a módosítás dátumát.
Szerintem mindezekkel ellentétben az utóbb jelzett hibák - ez és a kettővel fentebbi - oka, hogy valaki barkácsolja a szerkesztőt és/vagy a wikipédia megjelenítőt (kimenő html szűrőjét), de nem vallja be, ha hibázik. Ami roppant bosszantó. ZorróAszter vita 2020. augusztus 3., 13:17 (CEST)
A Wikipédia szoftvere úgy működik, hogy a szerkesztés akkor is végigmegy a rendszeren, ha egyébként nem történt változás, csak ekkor nem születik laptörténet-bejegyzés (így utólag nem látszik a nullszerkesztés ténye, de például a szerveroldali gyorsítótárat üríti). Valószínűleg a kliensoldali gyorsítótárat ez nem érinti, de a böngészők amúgy sem szoktak olyan agresszíven gyorsítótárazni, mint a szerverek. (A böngészőnek nem nagyon fáj még egyszer lekérni az oldalt, a Wikipédia szerverei viszont rövid úton bedobnák a törölközőt, ha minden egyes olvasónak újra és újra le kéne generálniuk az HTML-t, a wikiszöveg HTML-lé alakításától kezdve a bélyegképek újragenerálásán át a matematikai képletek újraszedéséig.)
Azt azért megjegyezném, hogy a Wikipédián futó szoftver döntő többségét nem az itt jelen lévők készítik, ebből adódóan nyilván nem is várható, hogy itt bejelentsenek minden hibát. A szoftverfejlesztés a Phabricator oldalon követhető leginkább; attól még, hogy itt nem jelentkezik a „bűnös”, simán lehet, hogy ott van ilyen hibákról hibajegy, ahol látható, hogy mitől romlott el a dolog. – Tacsipacsi vita 2020. augusztus 3., 14:08 (CEST)
Amit a nullszerkesztésről mondtál az szerintem elvben lehetséges ugyan, csak éppen nem valószínű. Konkrétan hogy nullszerkesztésnél a szerkesztés ténye nem kerül be a laptörténetbe, de mégis azonos tartalommal való mentésnek minősül és átírásra kerül az utolsó módosítás dátum/idő valahol máshol.
2. Nekem valami azt súgja, hogy a magyar wikipédián saját szerkesztő működik. És hogy valakik reszelgetik is rendesen itt a magyar wikipédián. Azt nem tudom, hogy a kódba is belenyúlnak vagy csak a konfigokba, de mintha valamit viszonylag gyakran változtatnak. És akkor jönnek be ezek a hibák. (Ezek a nullspace típusú hibák szerintem nem jöhetnek be konfig változtatással. Szerintem ez a kódba való belepiszkálásra jött be.) ZorróAszter vita 2020. augusztus 3., 20:26 (CEST)
Régen én is nullszerkesztéssel oldottam meg a problémát. És mindig sikerült. Egyszer valaki írta, hogy elég ha az ember rákattint a felső-jobb sarokban lévő (digitális) órára (már akinél ez be van állítva). Ez nagyon jól működik. Wikizoli vita 2020. augusztus 3., 20:51 (CEST)
@ZorróAszter: Valóban, a nullszerkesztés hatásossága nem valószínű. Hanem biztos. Évek óta használom, sikerrel. Konkrétan a csillagok megfelelő állása esetén (pl. a fordító kiterjesztés hibáinak következtében) olyan is előfordul, hogy a szerkesztett lap laptörténetébe nem kerülök bele, de egy másikéba igen – ez tuti nem véletlen egybeesés, hiszen annyira azért nem hibás a kiterjesztés, hogy random kipécézzen engem a nullszerkesztéstől függetlenül, ráadásul több tucatnyiszor mindig véletlenül engem. (És igen, a szoftver valahol átír egy módosítási dátumot: egészen pontosan a PageUpdater.php 1160. sorában.)
Az a súgás téved, a magyar Wikipédia pontosan ugyanazt a szerkesztőt használja, mint az angol Wikipédia vagy a francia Wikiszótár. Ezt a minden Wikimédia-wikin futó szoftvert folyamatosan fejlesztik, így bekerülhetnek hibák, bár én a ZWSP esetében nem látok semmi olyat, amiből egyértelműen lehetne következni arra, hogy valami elromlott a Wikipédián – számos más dolog is elronthatja (a böngésző vagy annak egy kiegészítője, egyéb program a gépen stb.), és nem olyan gyakori a hiba, hogy az valószínűsítené a Wikipédia szoftverének hibásságát.
@Wikizoli: Általában elég. A nullszerkesztés és az óra között az a különbség, hogy előbbi a kapcsolódó lapokat (kategóriák tartalma, Mi hivatkozik erre? és társai) is frissíti, míg utóbbi nem. Erre általában nincs is szükség, így többségében elég az óra, de néha kell a nullszerkesztés. – Tacsipacsi vita 2020. augusztus 4., 00:11 (CEST)
@Tacsipacsi: A nullszerkesztéses hókuszpókusz ezek szerint évek óta fennálló szoftverhibákat fed el. Tehát egyrészt egy update-elési hibát, aztán hogy a nullszerkesztés egyik adatbázisban rögzítésre kerül, a laptörténetben viszont nem, és egy harmadikat, ami szerint néha más laptörténetbe történik bejegyzés.
2. "a magyar Wikipédia pontosan ugyanazt a szerkesztőt használja, mint az angol Wikipédia". A látható különbségek, például listáról beinzertálható speciális karakterek egyáltalán nem látszanak konfig különbségeknek. Ezek bizonyosan kódbeli különbségek. ZorróAszter vita 2020. augusztus 4., 06:38 (CEST)
@ZorróAszter: Az, hogy a nullszerkesztés nem kerül bele a laptörténetbe, máshova viszont igen, az nem hiba, hanem szándékos tervezési döntés. Az sem hiba, hogy más laptörténetbe bejegyzés történik, ez a fordító kiterjesztés működési módja, bár tény, hogy az sok esetben hiba eredménye, hogy úgy történik változás az egyik lapon, hogy a másikon nem (azonban ez még mindig csak az ilyen esetek elenyésző hányada, általában ez a normális működés része) – ez egyébként viszonylag új keletű hiba, nem évek óta áll fenn, és dolgoznak a javításán a fejlesztők. Az, hogy nem frissül a lap a Wikidata változásával, szintén hiba (erről nem tudom, hogy a hibajavítási folyamat hogy áll). Két választási lehetőség van: vagy engedi a szoftver a nullszerkesztést ebben a formájában, és ezzel fennáll annak a kockázata, hogy a felhasználók nem jelentik a hibákat, csak eltüntetik; vagy nem engedi a szoftver, és akkor ha valami félrement, akkor rendes szerkesztést kell végezni a javításhoz (valószínűleg ekkor sem lesz belőle hibajelentés, de legalább tele lesz szeméttel a laptörténet). Biztos, hogy az utóbbi a jobb?
A karakterbeszúró a MediaWiki:Edittools lapon konfigurálható (nem programozható), és magát a karakterbeszúrást egy központi kód végzi – ez sem nyert. Most nem fogom neked kikeresni ezt a központi kódot, hiszen úgyis csak egy újabb csomót fogsz látni vélni a kákán. Sőt, részemről le is zárom ezt a sehova sem vezető beszélgetést, úgyhogy ne is várj több választ tőlem ebben a szakaszban. Remélem, a jövőben ennél konstruktívabban is együtt tudunk működni. – Tacsipacsi vita 2020. augusztus 4., 19:38 (CEST)
Kákán csomóra és egyebekre: :o) ZorróAszter vita 2020. augusztus 4., 20:28 (CEST)

Régen is előfordult ez, vagy mostanában kezdődött? Csak akkor nem látod, amikor a Wikidatából visszatérsz, vagy a lapot újratöltve (Ctrl-F5) sem? --Tgrvita 2020. augusztus 4., 15:21 (CEST)

Tacsipacsi és mások szerint (lásd fentebb) évek óta. Erre találták ki a nullszerkesztés elnevezésű trükköt. Én most találkoztam vele először, hogy kb. fél napig nem jelent meg a wikidata és a nyelvi felsorolás. Szerintem nem frissítési/cache probléma. Mikor láttam Vépi olvtárs hozzászólását, megnéztem a lapot és akkor még azon se voltak meg pedig azt az oldalt először töltöttem le. Legalábbis úgy emlékszem. ZorróAszter vita 2020. augusztus 4., 20:28 (CEST)
Akkor szerinted milyen probléma? – balint36 utaspanasz 2020. augusztus 4., 20:34 (CEST)
Update hiba. A wikidata kitöltése után nem történik meg a html oldal alapjául szolgáló adatok átadása. Bővebbet a részletek ismerete nélkül nem tudok mondani. Az is lehet, hogy ez egy lekérdezés lenne valamilyen központi, nyelvek közötti szerverről, ami néha nem működik. Például nagy ottani terhelésnél leidőzít. De nem szeretnék találgatni. A lényeg, hogy nagy valószínűséggel nem cache probléma. ZorróAszter vita 2020. augusztus 4., 21:29 (CEST)
Pedig catch. A datás kitöltés után semmi se frissíti/üríti a tárat, ami szimplán a gyorsabb oldalbetöltést szolgálja. Ha nem így lenne, akkor se az óra, se a Ctrl+Shift+R, se a Ctrl+F5, se a nullszerkesztés nem működne. Bízz bennem 4 évig ilyen területen tanultam. – balint36 utaspanasz 2020. augusztus 4., 21:42 (CEST)
És mivel magyarázod, hogy megnéztem Vépi által említett oldalt, és ott se látszott a wikidata link és nyelvi felsorolás? Azt az oldalt nem nyitottam meg korábban, tehát nem is kerülhetett cache-be. Továbbá milyen cache-elés az, ami még 12 óra elteltével se kérdez rá az oldalra, hogy nem változott-e meg? És hogy lehet hogy 12 óra múltán a hiba jelzését követően röviddel már el is múlt a cache probléma és hirtelen jó lesz? ZorróAszter vita 2020. augusztus 5., 07:25 (CEST)
Nálam nem 12, hanem 24 óra: a kacsás cikket aug. 1-jén este töltötték fel a Wikipédiára és a WD-ra, én aug. 2-án vettem észre, egész nap nyomkodtam a Ctrl F5-öt, de még 3-án reggel is, hiába, és csak utána jött helyre. (Ezt, hogy egy napig várok, hogy „ürüljön a cache”, akkor szoktam alkalmazni, amikor átnevezek egy cikket, utána kékítem a hivatkozásokat, s mindig a sablonokkal kezdem, aztán várok másnapig, amíg aktualizálódnak. Persze nem mindig, néha.) – Vépi vita 2020. augusztus 5., 07:34 (CEST)
Te megnézted az én szócikkemet? Mert ha nem látszódtak a linkek, akkor az bizonyosan nem lehetett cache probléma, hiszen akkor nyitottad meg először. Vagy akkor már látszottak? ZorróAszter vita 2020. augusztus 5., 09:15 (CEST)
Mindegy, hogy 12, vagy 24 óra, én egy Wikipédián kívüli oldalon 8 napja várok ilyen miatt. De hát akkor nem catch, felőlem lehet az is, hogy Tacsipacsi összeszövetkezett az illuminátussal, és átprogramozta a huwikit, hogy 5G-vel dihidrogén-monoxidot keverjenek az emberek ivóvizébe, de a dolgok alapvető működésén nem változtat, hiába tagadod. Beszéltem volna ilyen-olyan lagokról, de akkor úgyis fölösleges. – balint36 utaspanasz 2020. augusztus 5., 09:39 (CEST)
Valahogy ismeretlen okból megint eleresztetted a füled mellett a kérdésemet de akkor megismétlem: Mivel magyarázod, hogy megnéztem Vépi által említett oldalt, és ott se látszott a wikidata link és nyelvi felsorolás? Azt az oldalt nem nyitottam meg korábban, tehát nem is kerülhetett cache-be. ZorróAszter vita 2020. augusztus 5., 10:56 (CEST)
Már elmondtam. Tacsipacsi elmondta. Te azzal kezdted, hogy legalábbis nem emlékszel, hogy meglátogattad volna (és mi van, ha mégis?) Most meg azt, hogy biztosan? Mi változott meg azóta? Megváltoztattad, hogy a kákán is csomót keress? Sántít rekonstrukciód. – balint36 utaspanasz 2020. augusztus 5., 11:39 (CEST)
De ne nekem kelljen már bizonyítgatom, hogy catch. Leírtam, hogy mivel lehet javítani, ha azok közül valamelyik nem működne, akkor, de csakis akkor más a probléma. – balint36 utaspanasz 2020. augusztus 5., 11:51 (CEST)
Az NEM változott, hogy veled ellentétben nem szoktam kategorikusan fogalmazni ha nem vagyok 100%-osan biztos a dolgomban. Különösen nem mellébeszélés keretében. Hiába ajánlgatjátok ugyanis a nullszerkesztéses hókuszpókuszt, a kettő logikailag üti egymást. Tehát vagy a cache a probléma, vagy update probléma van, amin a nullszerkesztés állítólag segít. De a kettő együtt végképp nem stimmel. ZorróAszter vita 2020. augusztus 5., 13:35 (CEST)
@Vépi: Te megnézted az én szócikkemet mielőtt 3-án reggel csatlakoztál a kommenteddel? És ha igen, mit láttál? ZorróAszter vita 2020. augusztus 5., 13:52 (CEST)
Én 100% biztos vagyok benne. Azt, hogy a te nézetedbe nem fér bele, és inkább hókuszpókuszolni kezdesz itt, az már nem az én hibám, a catch tulajdonságait pedig végképp nem fogja megváltoztatni. Továbbiakban kellemes varázsolgatást, én kiszálltam, mert hiába írok le egy tényt, te ragaszkodsz a meggyőződésedhez, aminek (szori, hogy így fogalmazok, de) nincsen valóság alapja. – balint36 utaspanasz 2020. augusztus 5., 14:18 (CEST)
Ez egy hiba, amin évek óta ültök ezek szerint, és ahelyett, hogy megpróbálnátok elháríttatni ezt a hibát, helyette nyúllábbal és egyéb népi gyógymódokkal kísérleteztek és meggyőzitek magatokat, és győzködtök másokat is arról, hogy ez nem is hiba, hanem ez a természetes működése a rendszernek. ZorróAszter vita 2020. augusztus 5., 15:52 (CEST)

Tudtok olyan példát, ahol most is látható a hiba? --Tgrvita 2020. augusztus 5., 14:51 (CEST)

Jelenleg nem. Olyan, mintha 3-án reggel miután látta valaki ezt a bejegyzést, helyrehozta volna amit 24 órával korábban elszúrt, elkonfigolt vagy kitudja mit csinált. ZorróAszter vita 2020. augusztus 5., 15:52 (CEST)
Oké, ha látsz még ilyet, jelezd (és ne csinálj rajta null editet), és akkor talán be tudom azonosítani, hogy melyik cache nem frissült. --Tgrvita 2020. augusztus 6., 11:41 (CEST)

Válasz a hozzám intézett kérdésre (nem tudom, hova írjam): te aug. 2-án este töltötted fel a cikked, én 3-án reggel léptem be, észrevettem itt a beírást, megnéztem a te cikked is, a kacsásat is, akkor még egyiknél sem látszott. Később valamikor rendeződött, amikor Balint36 írta, hogy nála minden ok. – Vépi vita 2020. augusztus 5., 16:45 (CEST)

Köszi szépen. Én is úgy emlékeztem, hogy rákattintottam az általad adott linkre és még én sem láttam még a hiányzó linkeket. De már nem emlékszem, az mikor volt. ZorróAszter vita 2020. augusztus 5., 18:14 (CEST)
@Balint36: Itt van ami cáfolja azt amit írsz. Ez ugyanis azt bizonyítja, hogy nem lehet cache probléma, mert olyan lapnál jelentkezett, ami korábban nem lett lekérve. ZorróAszter vita 2020. augusztus 5., 18:25 (CEST)

@ZorróAszter: Kedves Eszter meg tudod mondani nekem, miért olyan fontos ez a hiba, hogy ily végtelen sok karakteren át foglalkozol vele. Tényleg élet-halálkérdés hogy 1 másodperc vagy fél nap alatt frissül egy lap? Ajánlom figyelmedbe the-difference-between-a-bug-error-and-feature gondolom sokkal fiatalabb vagy nállam, de azért érdekelne a konkrét válasz is. Texaner vita 2020. augusztus 5., 18:44 (CEST)

Kedves Seduxen!
Egyrészt nem foglalkoznék vele, ha nem kapnék valószínűtlen és egymásnak is ellentmondó válaszokat. Amiért pedig érdekel az az, hogy amíg a hibás állapot fennáll, addig nem tudok továbblépni, mert várom hogy végre történjék valami 12 óra alatt. Mert ugye új cikkeknél elvárt, hogy az ember betegye a cikket a wikidata adatbázisba.
Azt hogy ki a fiatalabb, ahhoz pedig ugyebár tudnom kellene, hogy te hány éves vagy. Nem tudom, gondoltál-e erre. :o) Üdv.: ZorróAszter vita 2020. augusztus 5., 19:15 (CEST)

Tech News: 2020-32Szerkesztés

2020. augusztus 3., 17:42 (CEST)

SzürkSzerkesztés

Nálam a Wikipédia napok óta értelmetlenül szerkesztési ütközést jelez mentés helyett. Nem lelem a hiba okát (Firefox, Linux Mint). OsvátA Palackposta 2020. augusztus 5., 10:05 (CEST)

Biztos, hogy szerkesztési ütközés, nem valamilyen elveszett munkamenet hiba? --Tgrvita 2020. augusztus 5., 14:48 (CEST)
Nagyon különböző esetekben fordul elő. OsvátA Palackposta 2020. augusztus 5., 15:57 (CEST)
Most is, a válaszom írásánál. Nem is mentettem el, csak bezártam. A válasz mindennek dacára ott van. Ha új cikket írok, akkor is előfordul, ha valamit javítok, akkor is. Nem mindig, de gyakorta. Reltélyes továbbra is. OsvátA Palackposta 2020. augusztus 5., 16:02 (CEST)
Saját magaddal ütközöl, vagy valaki mással? --Tgrvita 2020. augusztus 6., 11:43 (CEST)
sajátmagammal. OsvátA Palackposta 2020. augusztus 6., 14:48 (CEST)