Wikipedia-diskussion:WikiProjekt Check Wikipedia

¬

Tegnet ¬ er en fejl i næsten alle sammenhænge - det er vist en "blød bindestreg" fra Word? --Palnatoke 10. okt 2008, 10:25 (CEST)

Hvilken fejl? der er mange forskellige slags fejl? --Broadbeer, Thomas 23. okt 2008, 16:07 (CEST)

Flertydige og sletteforslag

En "top prioritet" for WikiProjekt Check Wikipedia er åbenbart at udskifte første overskrifter, der starter med flere end tre "=" med niveau-2 overskrifter. Dette er imidlertid en regel, der er meget dårligt forenelig med alle de mange flertydige artikler vi har. Dvs. artikler, der med vilje er meget korte, og hvor en overskrift - fx en 'se også' overskrift - ser meget grim ud som en niveau-2 overskrift. Alternativet er at gøre overskriften fed i stedet, men også her kommer problemet, at dette på et tidspunkt kan være en for lille overskriftstype, hvis den flertydige artikel vokser sig bare en anelse større. Jeg har skrevet om dette problem før: Se Wikipedia-diskussion:Stilmanual#Format af flertydige artikler, Brugerdiskussion:Amjaabc#Overskrifter med stor skrift og Brugerdiskussion:Moeng#Typo i flertydig. Det er derfor at jeg forslår, at denne "top prioritet" udgår fra WikiProjekt Check Wikipedia. Jeg håber dette er muligt. Mhv. --Anjoe (Anders) 22. okt 2008, 23:45 (CEST)

Jeg synes måske en sletning af affsnittet er lige i overkanten, men jeg kan da godt følge dig, og vil da tage det til efterretning, hvis jeg laver en fixerunde til senere. --Broadbeer, Thomas 23. okt 2008, 00:41 (CEST)

Det ville være fint, hvis det kun var dig der skulle tage dette til efterretning, men mange andre (som det ser ud - fx Amjaabc og Moeng) bruger også dette projekt, og hvis man ikke bare slavisk kan stole på anbefalingerne, så ser jeg ingen grund til nogen automatisk liste over dem. Alternativet til sletning ville være at rense listen for alle sider, der inderholder skabelonen {{flertydig[|...]}}. - Hvis dette var muligt - og det faktisk blev gjort, hver gang - ville jeg trække mit foreslag om sletning tilbage. Jeg har af en eller anden årsag arbejdet en del med flertydige igennem tiderne, og det er stærkt demoraliserende at se dem forringet på række. --Anjoe (Anders) 23. okt 2008, 22:24 (CEST)

Sletningsforslaget slettes hver dag når en ny version af rapporten indsættes. Ville bare nævne det. Desuden retter jeg stadig denne fejl, men jeg retter flertydige sider tilbage. --Broadbeer, Thomas 23. okt 2008, 22:29 (CEST)

Det er fint at lige at nævne problemstillingen her Anjoe, men det er lettest hvis et emne bliver diskuteret ét sted. Jeg kan forstå, at der er diskuteret 4 (?) steder. Jeg vil foreslå, at diskussionen foregår under stilmanualen. --MGA73 23. okt 2008, 22:33 (CEST)

Hello I don´t understand danish, but we have also discuss this problem in de. We fix this error because the W3 Consortium has write this down in his documents. See [1] and also [2]. Best regards -- sk 23. okt 2008, 22:46 (CEST)

Thanks for the input. --Broadbeer, Thomas 23. okt 2008, 23:32 (CEST)

Det er en uskik at begynde at bruge semantisk forkerte HTML-elementwer, her <h3> for at opnå en bestemt visuel effekt. Hvis udseendet skal rettes, er den korrekte løsning at style overskriften, så den kommer til at se knap så dominerende ud. Der vil ikke være de store ben i at oprette en skabelon til overskrifter til "Se også", "Kilder", "Eksterne henvisninger", og hvad der ellers er af afsnit der semantisk skal være en level-2 heading, men visuelt skal nedtones. De øvrige forslag der har været på banen amdre steder hvor dette problem blæiver diskuteret er efter min mening lige så forkerte, da de også indebærer misbrug af html-elementer med en anden semantik, for at opnå et bestemt visuelt udseende. -- Bruger:Wegge 17. dec 2008, 10:33 (CET)

Hvis det for nogle brugere er meget vigtigt at denne overskrift nedtones synes jeg hurtigst muligt den skal oprettes så vi kan få den korrekte syntaks i disse artikler. --Broadbeer, Thomas 17. dec 2008, 12:12 (CET)

Jeg har lavet nogle forskellige muligheder:

Se også

Som === Se også ===

Se også

Som ==== Se også ====

Se også

Som ===== Se også =====

Se også

Som ====== Se også ======

Det ser fint ud. Jeg er bare bekymret over, hvad det fører til. Hvis det er hensyn til layout, der bestemmer hvad så med andre skrifttyper og brug af farver? Så jeg synes der skal være så få valgmuligheder (undtagelser) som muligt. --MGA73 17. dec 2008, 17:39 (CET)

Det her er bare et hurtigt eksempel for at vise de muligheder der er. Jeg vil på det kraftigste anbefale at den konkrete implementation bliver lavet ved hjælp af en serie skabeloner, der indsætter eksempelvis <h2 class="se_ogsaa">Se også</h2>, og så bestemme markup af den CSS-klasse i det centrale stylesheet. På den måde kan folk der har lyst til et andet udseende selv rode med det i deres personlige stylesheet. -- Bruger:Wegge 17. dec 2008, 17:48 (CET)

Okay. Det jeg personligt ville være mest interesseret i var en løsning, hvori alle overskrifttyper i en flertydig artikel, som standard for alle brugere, visuelt blev sat 2 niveauer ned. Dvs. h2 -> visuelt h4, h3 -> visuelt h5 osv. Jeg kan udmærket se ideen i at adskille semantikken fra syntaksen. Ville dette være muligt? --Anjoe (Anders) 13. jan 2009, 16:45 (CET)

Støtter så godt og vel Anjoes sidste forslag. Jeg tror bare umiddelbart der kan opstå en del forvirring blandt skribenterne, så ved ikke om det er en god idé. Desuden løser det vel ikke helt vores problem, da den så stadig reagerer på overskrifter med h3 ("Se også"). Kunne man ikke implentere i scriptet, at hvis denne fejl hedder "=====Se også=====", skal den forkastes. Jeg går ud fra at der ikke er nogle normale artikler, som indeholder denne syntaks --Anigif 22. jan 2009, 08:40 (CET)

Begrundelsen for at scriptet har det som fejl er hensynet til blinde/svagtseende. Hvis de også "læser" flertydige artikler, så er denne løsning jo ikke optimal. --MGA73 6. feb 2009, 19:12 (CET)

Se venligst Wikipedia-diskussion:Stilmanual#Afsnitsoverskrifter i flertydigartikler hvor jeg stiller et konkret forslag som jeg håber kan danne basis for en løsning. Byrial 10. mar 2009, 15:32 (CET)

Taget i betragtning af, at de flertydige artikler ikke længere dukker op i skanningen, går jeg ud fra, at der er blevet enighed, og at de alle nu er rettet?

Bør vi da ikke fjerne den lille "advarsel" om, at "de fleste artikler herunder er flertydige artikler"?

~ Mads Ren`ai 26. mar 2009, 15:56 (CET)

Ja, de er rettede, så teksten kan godt "normaliseres". Byrial 26. mar 2009, 18:26 (CET)

DEFAULTSORT

På siden står der p.t.:

"Undgå venligst at bruge specieltegn i DEFAULTSORT.

   * i de: ä → a, ö → o, ü → u, ß → ss
   * i fi: ü → y, é → e, ß → ss, etc.
   * i sv og fi er ÅÄÖåäö tilladt
   * i cs er čďěňřšťžČĎŇŘŠŤŽ tilladt
   * i da, no, nn er ÆØÅæøå tilladt
   * i ro er ăîâşţ tilladt
   * i ru: Ё → Е, ё → е"

Var det ikke bedre at skrive at på dansk skal følgende tegn oversættes således:

• ä → æ, ö → ø, ü → y, ß → ss, mens alle andre former blot oversættes ved at fjerne "dimsen" over bogsatavet, fx Ё → Е, ё → е og čďěňřšťž til cdenrstz

Hvis det ellers er korrekt forstået :-) --MGA73 2. nov 2008, 13:18 (CET)

På tysk sorteres ä, ö og ü som anvist, så det vil jeg ikke mene, der skal laves om på --Anigif 22. jan 2009, 08:30 (CET)

Anigif, dvs. du tolker teksten således, at hvis der er tale om et tysk navn, så skal vi på den danske wikipedia rette "München" til "Munchen" og når der er tale om en svensk artikel, så skal vi bare lade tegnene ÅÄÖåäö blive stående i DEFAULTSORT? --MGA73 22. jan 2009, 09:01 (CET)

Nej, bestemt ikke. Hvis DEFAULTSORT ikke kan tage de specialtegn, skal det selvfølgelig gøres for resten af sprogene. Men det lød bare til at det også skulle gælde for tysk, hvilket jeg ikke vil mene er korrekt ;) Så ja, den første del af det du siger, er hvad jeg mener! --Anigif 22. jan 2009, 22:28 (CET)

Lidt sent, men det korte af det lange er, at jeg bare synes, at det ville være rart, hvis det stod et sted hvordan man oversatte de forskellige tegn til noget "dansk". Mht. München så ville jeg jo nok have oversat til y i stedet for u, men hvis det er korrekt med u skal det jo være sådan. Men altså en vejledning i "danskificering" for dummies :-) --MGA73 28. jan 2009, 11:06 (CET)

Ja, det kan jeg godt følge dig i, for lige nu kan der da godt opstå nogle "huller", hvor man ikke ved hvad man skal. Og jeg er bestemt heller ikke sproglig, så skal ikke kunne udtale mig om det, men husker bare lige det her fra tyskundervisningen --Anigif 28. jan 2009, 11:12 (CET)

Når vi skriver på dansk, skal der naturligvis sorteres efter danske regler. --Palnatoke 28. jan 2009, 11:33 (CET)

Det giver bare ikke mening i forhold til hvordan det er lavet i gyldendals leksikon (tysk), hvor det gælder at ü → u. Men det lyder da umiddelbart fornuftigt og kan da være smart at have en hel ren linje, så man ikke tænker på hvor et navn er fra osv. --Anigif 28. jan 2009, 12:16 (CET)

Ja Palnatoke det ville være rart. Så skal vi bare lære "kategorisorteringen" at sortere korrekt, jf. fx følgende Kategori:Virksomheder_fra_Danmark og Kategori:Fremstillingsvirksomheder_fra_Danmark. --MGA73 28. jan 2009, 14:58 (CET)

-> MGA73: https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --Palnatoke 28. jan 2009, 15:25 (CET)

Jeg har nu rettet teksten jf. mit oprindelige forslag. --MGA73 5. feb 2009, 15:47 (CET)

Hvis listen skal være komplet mangler: ð → d, þ → th, œ → oe jf. retskrivningsreglerne i Retskrivningsordbogen, § 4.3. Byrial 16. feb 2009, 11:12 (CET)

Korrekt XHTML syntaks

Vedrørende Artikel med forkert <br/>, jeg vil bare lige gøre opmærksom på at eneste korrekte syntaks for XHTML er <br /> altså <br mellemrum skråstreg>. -Zilotte 19. nov 2008, 17:25 (CET)

Small - ny skabelon

Jeg ved godt det er et ikke så højt prioriteret afsnit, men jeg synes alligevel der er så mange fejl fundet ved <small> at der bør gøres noget ved det. Hvis der overhovet bør gøres noget? Men jeg synes stadig den lille skrift bør blive, da den er meget fin i mange eksempler. Jeg vil foreslå at man lavede en skabelon der hed noget ala {{small}} hvor på der står noget lig <span style="font-size: smaller;">{{{1}}}</span>. Dermed bliver det stadig småt (det virker i hvert fald her), og denne kode burde være "lovlig" - selv om man bruger lidt mere CSS --Anigif 28. jan 2009, 10:31 (CET)

Jeg kunne også bare prøve at lave den? :P Jeg tænker bare mest, at det kunne være smart at gøre - evt med en bot (?) - hvis folk intet problem ser i det --Anigif 6. feb 2009, 18:46 (CET)

Ok med mig. Prøv at lave skabelonen og så kan vi se om det virker efter hensigten. --MGA73 6. feb 2009, 18:51 (CET)

Det virker egentlig (endeligt!) fint efter hensigten. {{small|lille skrift}} giver lille skrift :) (tilføjede lidt fra den engelske diskussionsside, som jeg er lidt i tvivl om hvad gør, men det blev anbefalet og det virker efter hensigten jo ;)) --Anigif 7. feb 2009, 03:10 (CET)

Fint forslag.

Den ekstra kode bestemmer linje-højden for teksten (hvis det ellers er "line-height" du mener), og jeg må sige at jeg synes resultatet ser fint ud. :-)

Så mangler vi bare at en bot tager sig af resten, ik'?

~ Mads Ren`ai 11. feb 2009, 09:13 (CET)

Jo hvis ingen protesterer meget snart, så burde det være en opgave at sætte den nye {{small}} på :-) Evt. kunne den stolte forfatter skrive en lille henvisning på brønden om at hvis ingen protesterer, så bliver det rettet. Og hvis nu der går for lang tid inden nogen retter, så kan man prøve Wikipedia:Botformidlingen - man kan jo overse sådanne opgaver i farten, hvis man ikke lige kigger forbi her jævnligt :-) --MGA73 11. feb 2009, 09:36 (CET)

Nu er det nok bare mig, der har overset noget, men hvorfor skal de fjernes? Der står, at vi ikke har brug for HTML-tags, men så er <span /> vel ikke bedre end <small /&gt? --Pred (diskussion) 11. feb 2009, 10:25 (CET)

Ja, det er jeg også kommet til at tænke lidt over siden det blev nævnt på skabelonens diskussionsside. Så vidt jeg ved, er <small> okay i forhold til W3C. Jeg kunne forestille mig at den er med i det her projekt fordi det kan blive misbrugt, men jeg synes bare det er godt nok at have en mulighed for mindre skrift til fodnoter eller andet mindre skrift. Men i så fald - hvis <small> er lige så fin som <span> skal denne vel fjernes fra vores tjek? (Selv om jeg er ked af at sige det når jeg nu lige fik den skabelon til at virke...) --Anigif 12. feb 2009, 12:47 (CET)

Hmm, ifølge projektets hovedside er det mere korrekt XHTML-syntaks. (Jeg ved godt, at der der bliver foreslået et andet kompromis, men synes mit (egoistisk nok) er bedre, så længe det virker) --Anigif 13. feb 2009, 22:43 (CET)

Tja er enig med Pred. Skulle vi ikke bare deaktivere den fejltype? Det har mig bekendt ingen praktisk betydning så synes ærlig talt, at det er lidt spild af tid. Det belaster systemet at finde "fejlene" og det "generer øjet" at vi har så mange af den slags "fejl" og hvis nogen retter det så fylder det også bare unødigt op i historikken og seneste ændringer. Vi plejer ikke at rette stavemåder hvor der er valgfrihed, så jeg synes vi skal bruge samme betragtning her: Ret ikke kosmetiske ting, der ikke har nogen betydning. Tager jeg fejl? --MGA73 3. mar 2009, 20:20 (CET)

Tjo. Jeg er selv delvis (u)enig, men jeg har ingen argumenter imod en deaktivering.

Så for min skyld må denne fejltype gerne deaktiveres - om ikke andet, så i hvert fald indtil nogen kommer med nogle gode modargumenter. :-)

~ Mads Ren`ai 9. mar 2009, 16:25 (CET)

Titel med specialtegn og ingen DEFAULTSORT

Det nye tiltag tager ikke højde for {{FD|1623|1678|Ovens, Jyrgen}} der har samme effekt som DEFAULTSORT. --Villy Fink Isaksen 7. feb 2009, 21:33 (CET)

Fejltype 2 - Artikel med forkert <br/>

Denne fejltype står som høj. Umiddelbart har jeg svært ved at se hvorfor den skal have høj prioritet. Der er massere af andre vigtige opgaver, så jeg synes, at det er synd, at lokke folk til at bruge tiden på at rette dette, når (hvis?) der er er tale om en nærmest ubetydelig bagatel.

Fejltypen kan iøvrigt rettes automatisk med bot, så jeg synes umiddelbart blot, at den skal nedklassificeres som lav, og så fixer botterne det når de alligevel kommer forbi. Og hvis man ikke vil vente på det, så kan alle fejltyperne med lav prioritet (der rettes automatisk af en bot) rettes på en gang med en enkelt botkørsel. --MGA73 12. feb 2009, 13:38 (CET)

En forkert <br/> kan betyde et manglende linjeskift hvor der skulle være et. Det kan føre til misformatering i tabeller (især infobokse) hvor der er flere oplysninger i samme tabelcelle. Det synes jeg da er en forholdsvis alvorlig fejl. Og er der i øvrigt ikke så få af denne type fejl, at det ikke er noget stort problem at rette dem som de opstår? Byrial 12. feb 2009, 13:49 (CET)

Hvis linjeskiftet ikke virker, så ser man/forfatteren det formentlig med det samme. I alt fald er jeg ikke stødt på eksempler på en defekt "br", hvor den ikke virker. Men jeg synes bare at der findes alvorligere fejl end et manglende (eller "forkert") linjeskift :-) Men det er heldigvis let at rette. Jeg synes dog stadig, at det bør fremgå, at det kan rettes med bot, så brugerne kan vurdere om de vil bruge tid på at rette manuelt, eller om de vil lade en bot fixe det. --MGA73 12. feb 2009, 23:20 (CET)

Det kommer an på ens browser hvordan forkert HTML-kode vises. Måske ser forfatteren ikke at der er noget galt, og retter det derfor ikke, mens andre læsere kan se det forkert. Byrial 12. feb 2009, 23:35 (CET)

Personligt er jeg delvis enig med jer begge to.

Jeg kan godt se hvad Byrial mener med browser-forskellene, men samtidig også godt følge MGA73 i, at "høj prioritet" er lige i overkanten.

Hvad om, at vi går på kompromis og sætte det som en "middel prioritet" fejl, samt tilføjer at sådanne fejl eventuelt kan rettes af en bot?

~ Mads Ren`ai 13. feb 2009, 00:17 (CET)

Jeg synes de forskellige prioteter er ret ligegyldige. Det er alle fejl der bør rettes. --Broadbeer, Thomas 13. feb 2009, 02:19 (CET)

Hvis alle fejl bør rettes, så ville det være en god idé at køre Cosmetic_changes.py på alle artikler. Så bliver fejl rettet automatisk.--MGA73 13. feb 2009, 23:21 (CET)

Så forstår jeg ikke helt. Hvis det virkelig er så simpel, hvorfor så lave alt det her? --Anigif 14. feb 2009, 02:02 (CET)

Nej ikke alle fejl kan rettes, det var vist bare ment som at alle
fejl kan. --Broadbeer, Thomas 15. feb 2009, 18:29 (CET)

HTML-listeelementer

Ifølge teksten til fejltype 012 er MediaWiki tilstrækkelig fleksibel til at undgå brug af HTML-listeelementer. Det er jeg uenig i. Se for eksempel de mange eksempler på en:Help:List på hvad man udelukkende kan gøre med HTML. Jeg foreslår at vi undlader at rette disse "fejl" når HTML bruges til funktioner som MediaWiki-kode ikke muliggør. Byrial 20. feb 2009, 15:15 (CET)

Skaberen af er allerede blevet gjort opmærksom på, at hans ordvalg ikke var det bedste, og har siden ændret det. (Har lige opdateret vores oversættelse)

Fejlbeskrivelsen lyder nu således:

I de fleste tilfælde kan der bruges mere simple wikitags i stedet for HTML-tags.

Som du ganske rigtigt siger, så er MediaWiki ikke helt fleksibel nok til, at tage sig af lister med speciel formatering, som det f.eks. ses i Napoleonskrigene.

For nu, bør vi nok bare lade sådanne eksempler være.

Om ikke andet, så kunne man jo altid foreslå manden bag scriptet, at få skanningen til at overse specielle lister så som <ol style="list-style-type:lower-alpha">, hvis ellers det kan lade sig gøre. :-)

~ Mads Ren`ai 26. feb 2009, 10:45 (CET)

Jeg har nu foreslået Stefan Kühn at få skanninen til at overse disse lister. Byrial 26. feb 2009, 11:57 (CET)

Stefan har indvilliget, så Napoleonskrigene vil nok snart forsvinde fra listen. Byrial 27. feb 2009, 00:00 (CET)

Det er altid en god idé at foreslå Stefan Kühn rettelser hvis noget ikke kan erstattes. Ellers vil det jo skabe evig frustration. Samtidig er det jo også lettere at finde og rette overflødig kode, hvis dem der ikke skal rettes bliver sorteret fra. Så 10 point fra mig :-) --MGA73 27. feb 2009, 08:25 (CET)

Deaktiveringsforslag for fejltypy 18

Jeg foreslår at vi deaktiverer fejltype 018 (småt første bogstav i kategorinavn). Det er totalt ligegyldigt og har ingen betydning for sidernes udseende og funktion, så hvorfor bruge tid på det? Byrial 20. mar 2009, 14:41 (CET)

Aktiveringen af fejltypen skete højst sandsynlig da vi ændrede på alle "-1"'erne. Altså, ved et uheld.

Så tja. Jeg støtter forslaget, med begrundelsen, at det ser ud til at være en fejl at den overhoved er aktiv her på daWiki.

Den ser desuden ikke ud til at registrer halvdelen af de artikler hvor "fejlen" er i, (?) så den er nok blevet deaktiveret med god grund.

~ Mads Ren`ai 20. mar 2009, 14:48 (CET)

Det er hermed gjort. Byrial 20. mar 2009, 15:01 (CET)

Det er nu ganske rart, at første bogstav står med stort ligesom det er rart, at det er uden mellemrum mellem : og teksten og at det er på dansk. Men jeg er enig i, at det ikke er noget vi behøver rettes "hele tiden". Det bliver automatisk rettet, når en bot kommer forbi og ellers kan det rettes hver gang, der er kommet et dump. --MGA73 21. mar 2009, 16:53 (CET)

Ja, det er ganske rart, og jeg synes også at disse ting skal rettes når man alligevel retter i en artikel. Men jeg synes ikke at det er værd at redigere en artikel udelukkende for disse ting. Byrial 22. mar 2009, 03:37 (CET)

Forslag om at deaktivere alle "kosmetiske" ændringer

Jeg foreslår at alle ændringer, der primært er kosmetiske, bliver deaktiveret. De kan så enten rettes med AWB eller ved at man laver en botkørsel efter hvert dump. Desuden rettes mange af fejlene automatisk, når en bot kommer forbi. Det drejer sig om fx:

• 2 Artikel med forkert <br/>
• 9 Flere kategorier på en linje
• 18 Småt første bogstav i kategorinavn
• 21 Kategori på engelsk
• 22 Kategori med mellemrum
• 50 N-tankestreg eller M-tankestreg
• 51 Interwiki før sidste overskrift
• 52 Kategori før sidste overskrift
• 53 Interwiki før sidste kategori

Samt evt.:

• 20 Symbol for død (formentlig)
• 55 Udeladelsesprikker
• 56 Pile som ASCII
• 57 Overskrifter med kolon

Derudover kan dette sikkert også rettes hvis det er et stort ønske jeg synes ikke vi bør rette disse "fejl" da jeg ikke kan se hvorfor det skulle være bedre at bruge en anden kode end fx <i>:

• 38 HTML tekst stilelement <i>
• 39 HTML tekst stilelement <p>
• 40 HTML tekst stilelement <font>
• 41 HTML tekst stilelement <big>
• 42 HTML tekst stilelement <small>

Så vidt jeg kan se, så finder WPCW ikke alle fejlene på en gang, men tager dem lidt ad gangen. Det gør at man bruger unødigt meget tid på "en fejl". Der er "kun" 26 så det kan jeg godt lige rette. Dagen efter er der så 15 mere osv. Fx viste WPCW at der var 26 overskrifter med kolon men min bot endte med at rette ca. 1.200 artikler! --MGA73 21. mar 2009, 16:53 (CET)

Jeg støtter dette forslag.

Dog med en enkelt kommentar: Jeg mener ikke at vi bør bruge <i> når vi har en udmærket wiki-version, '', til samme formål.

Men bortset fra det, har idéen grønt lys fra mig, med mindre nogen kan komme på gode modargumenter. :-)

~ Mads Ren`ai 21. mar 2009, 17:10 (CET)

Nåe nej det har du ret i :-) Jeg tænkte mere på de andre. --MGA73 21. mar 2009, 17:19 (CET)

Gruppe 1: Jeg støtter deaktivering af fejltyperne 9, 18, 21, 22, 50, 51, 52, 53 som ingen betydning har for en sides udseende eller funktion. Disse kan alle rettes automatisk ved lejlighed. Man skal dog være opmærksom at tilstedeværelse af disse fejl ofte er sammenfaldende med andre og mere alvorlige fejl, hvilket kan være en grund til at kigge på dem. Jeg er usikker på fejltype 2 som jeg ikke ved præcis hvad dækker over.

Gruppe 2: Jeg vil gerne bevare fejltype 20, 55, 56 og 57. Der er en vist pædagoisk værdi i at rette med det samme.

Gruppe 3 (HTML): Jeg vil gerne bevare fejltype 38 ("i" er overflødig), 39 ("p" kan bruges i listeelementer med flere afsnit og måske andet, men lad os se eksempler før vi tager stilling til deaktiverering), 40 ("font" bør generelt erstattes af CSS) og 41 (jeg kan ikke noget formål med "big"). Fejltype 42 (small) kan godt forblive deaktiveret. Byrial 22. mar 2009, 13:10 (CET)

Fint med mig. Jeg så bare en besparelse i at rette alle fejlene på en gang i stedet for at rette lidt manuelt løbende. Men hvis vi sætter en bot til at rydde op efter næste dump, så burde det jo også være begrænset hvor mange fejl der kommer løbende. Jeg kan også sætte botten igang med at rette ud fra seneste dump - det tager 20 sekunder og så klarer botten resten. --MGA73 22. mar 2009, 17:16 (CET)

Fejlene 9, 18, 21, 22, 50, 51, 52, 53 alle deaktiveret. --MGA73 21. apr 2009, 23:39 (CEST)

Jeg burde have set dette tidligere. Men fejl 51 og 52, samt evt 53 bør være i Byrial gruppe 2 - de fleste er gamle fejl som rettes i et hug når næste vel kommer om en uge tid. Fejl 51 og 52 mærker man når man skal rettet interwiki og kategorier

Til gruppe 1 tilhører fejl 11 - Bogstaver skrevet som HTML - det ligner fejl 50 meget. Scriptet fanget mange af den slags nu. --Steen Th 22. apr 2009, 16:25 (CEST)

Det er rigtigt, at man ser det hvis man retter i artiklen. Men efter min opfattelse så er der forskel på at rette noget når man alligevel kommer forbi og så lede systematisk efter det.

Efter min opfattelse er der stadig ingen grund til at bruge tid på at rette dette ved hjælp af denne side. Der er jo massere af andre ting som fx Wikipedia:Projekter og Wikipedia:Oprydning/Prioriteter.

Hvis fejlene skal være aktiveret så bør det efter min opfattelse stå beskrevet over fejlene at de ikke kan ses på skærmen og at de alligevel bliver rettet automatisk, for at undgå at nogen bruger tid på at rette det i den tro at der er tale om noget der er vigtigt at få rettet. --MGA73 6. maj 2009, 07:39 (CEST)

Ok, ved godt det kom til at lyde forkert på en eller anden måde. Dette projekt er meget synligt og har meget fokus. Det er ikke noget der er igangsat fra den danske Wikipedia og det kører selvstændigt udenom kvalitetsoffensiven. Projektet er skam fint nok, men prioriteringen høj, middel og lav er ikke indpasset i forhold til de andre prioriteringer på Wikipedia. Så selvom noget har høj eller middel prioritet på WPCW, så behøver det ikke betyde at det er noget der i den samlede prioritering vil få mere end "lav".

Efter min opfattelse er det vigtigere at få interwiki og kategorier på artikler uden, end at flytte rundt på placeringen på de artikler, der allerede har. Det sidste kan vi jo gøre automatisk, mens det første kræver at nogen sidder og laver et arbejde manuelt.

Så meningen var ikke at forbyde folk at rette det, men blot at signalere at det ikke var det højstprioriterede projekt på Wikipedia. Ikke for at nedgøre arbejdet, men for at undgå at nogen fravælger andet arbejde fordi de tror, at "vi" hellere vil have at de retter her.

Hvis der er stemning for det, så kan vi lave en botkørsel, der retter disse kosmetiske fejl på alle artikler som en engangskørsel og så efterfølgende kører rettelsen på nye artikler. Men det belaster systemet, og fylder i historikken, så hvis der er ønske om det, så synes jeg at det bør tages op på brønden først. --MGA73 6. maj 2009, 09:32 (CEST)

Fejl 61

Jeg kan ikke finde det, men jeg mener, at det har været diskuteret. Wikipedia:Stilmanual#Noter siger note efter punktum, men jeg mener at have hørt argumentet, at hvis noten er til ordet og ikke til sætningen, så bør den være før punktum. Hvis det er korrekt, så bør teksten justeres. --MGA73 2. apr 2009, 14:35 (CEST)

Tidligere diskussioner: Wikipedia:Landsbybrønden/Spørgsmål om fodnoter/referecer og Wikipedia-diskussion:Stilmanual/arkiv2#Fodnoter. Nogle vil nok argumentere anderledes, men her er der vist konsensus om, at vi har en norm, der siger, at noter altid skal efter et evt. komma eller punktum. Så jeg ser ingen grund til at ændre på noget.-Qw345 2. apr 2009, 18:47 (CEST)

Der er nogen, der protesterer på min brugerside - blot til orientering. --MGA73 15. apr 2009, 22:28 (CEST)

(nu ved jeg så ikke om jeg skal fortsætte diskussionen her eller på din brugerside..) De eksempler i stilmanualen er på bøger der står i bunden af en artikel! Men det ser misvisende hvis man bruger det i selve teksten. Se Nordisk religion der følger stilmanualen, det er svært at gennemskue om referencen hører til sætningen før eller efter punktummet. Og der bliver ikke sat punktum før kildehenvisninger i bøger og rapporter - Zilotte

Det bør ikke være på min side, så enten på stilmanualens diskussionsside eller på brønden. Det gør det lettere at finde diskussionerne igen. Om der så skal startes nye diskussioner eller om de gamle skal genoptages ved jeg så ikke helt :-) --MGA73 15. apr 2009, 23:05 (CEST)

Jeg kan til orientering oplyse, at endnu har ingen taget initiaitiv til at få ændret stilmanualen, dvs. indtil videre er reglen stadig note efter punktum. Dem der måtte være uenige opfordres til at rejse en debat på fx stilmanualens diskussionsside og evt. henvisning fra landsbybrønden hvis man synes. --MGA73 19. apr 2009, 22:41 (CEST)

Jeg har nu gjort et forsøg på at tage initiativ, men kom til at fortsætte en diskussion der var arkiveret. Kan diskussionen fortætte der (hvor den startede) eller skal jeg forsøge igen ? - Zilotte

Tja, der er ikke sket så meget, så nu har jeg reklameret for det på brønden. Nu hvor diskussionen er aktiv, så burde den nok ikke ligge i arkivet. Uanset hvad så bliver det lidt rodet. Men pyt, bare der er de relevante henvisninger. --MGA73 28. apr 2009, 15:44 (CEST)

Har nu kopieret den arkiverede diskussion til Wikipedia-diskussion:Stilmanual#Fodnoter. --MGA73 28. apr 2009, 15:48 (CEST)

Det ser ud til, at stemningen er, at der godt kan være punktum både før og efter en note, så hvis ingen protesterer, så foreslår jeg, at fejlen deaktiveres. Der er jo ingen grund til at bruge tid på det, hvis det ikke er en fejl alligevel. --MGA73 12. maj 2009, 21:28 (CEST)

Fejltype 75 - Indented list

For mig gør det ingen forskel om en indrykning i en punktliste er med :'er eller med *'er. Er der nogen, der har gode argumenter for en ensretning? Ellers foreslår jeg, at "fejlen" deaktiveres. --MGA73 19. apr 2009, 22:46 (CEST)

68 - Link to other language

Der er nogen holdning til den "fejl"? Brude vi være ligeglad med det? Nogen gange linker man til en xxwiki istedet for at oprettet artikler som muligvis ikke er relevant ud fra et dansk synvinkel.--Steen Th 22. apr 2009, 15:46 (CEST)

Normalt bør vi have vores egne artikler, men der kan vel godt være undtagelser. Det var måske bedre at spørge Byrial om han kan lave en liste, for så kan man slette efterhånden som man retter og notere på listen, at linket bør være der, på dem, der ikke bør slettes. Altså lave en "positivliste". --MGA73 22. apr 2009, 16:07 (CEST)

Jeg kan ikke umiddelbart lave en liste, for interwiki-henvisninger gemmes ikke i databasen. (Der er en tabel med sproghenvsininger, men ikke nogen for generelle interwikihenvisninger). Byrial 22. apr 2009, 22:47 (CEST)

Så har jeg fået lavet en liste over denne observation: Wikipedia:WikiProjekt Check Wikipedia/Fejl68 - så er der et overblik. Jeg forøger p.t. mængden ved at konvertere http-urler til andre wikipedia'er til wiki-syntaks.

Jeg har prøvet at gruppere observationerne:

• Hvor linket til den anden wiki peger sammen artikel som er er interwiki-link på.
• Hvor linket peger en artikel som vi selv har i dansk udgave.
• Og hvor der ikke matcher. Det er vel en stor ønskeliste.

Og der er også en mindre rest-gruppe.

Gruppe 2 - de links bør vel bare konverters til et dawiki-link. Gruppe 1 har jeg ingen ideer til. --Steen Th 6. jul 2009, 16:00 (CEST)

Skabelon til Fejlagtige ISBN

Jeg har oversat og oprettet en skabelon til ISBN - Skabelon:Fejlagtigt ISBN - som er fejlagtig til de tilfælge, hvor der er checkcifferfejl og det er registret i de biografiske databaser. Normalt bliver ISBN korrigeret med den rigtige checkciffer og praksis at man normalt bruger det i databaser i stedet for det, der er trykt i bogen. --Steen Th 28. apr 2009, 16:06 (CEST)

Fejl 82 - Link to other wikiproject

Er der nogen som er interesseret i der skal gøres noget ved denne observation? Det jeg kan se er der er mange links til bruges profiler i commons, når det bliver krediteret for billeder, henvisninger til Wiktionary, osv. Hvis ikke er interesse for det synes jeg at denne fejl kunne deaktiveres. --Steen Th 6. jun 2009, 00:45 (CEST)

nye obs 86-91 - sortering og andet

Først det andet

• fejl 86 - [[http:www.eksempel.com Eksempel]] finder den - der ca. 150 stk. Dem få jeg fjerne enten manuel eller med bot - jeg er gang. Det er synlig
• fejl 87 - ikke fejlfri - så den er trukket tilbage.

Og så er der sortering.

• fejl 88 - betyder mindre blanktegn for meget i DEFAULTSORT - kan bot'tes let - men betyder ikke noget.
• fejl 89 - stor bogstav midt i ord - fx McDonalds - der 2757 artikler med det.
• fejl 90 og 91 - der er allerede omkring over 33000 obs, hvor der er lille startbogstav i et ord i en sorteringsnøgle med/uden DEFAULTSORT. Mit skøn er der ca. 50000 obserationer.

De her 4 typer - burde det ikke ikke deaktiveres indtil at der er en bot, som kan håndtere tilføjelse af DEFAULTSORT eller rettelse af DEFAULTSORT. Det vil være umulig at håndtere dem i hånden. Jeg har fundet omkring 1200 steder hvor det reelt har mindre betydning for sortering. En eksempel det kan ses er i Kategori:Afghanistan. Dog har vi en andet national sortering problem - aa som å det er mere synlig. --Steen Th 9. jun 2009, 16:01 (CEST)

Jo deaktiver endeligt. Hvis det ikke har praktisk betydning synes jeg ikke vi skal bruge tid og ressourcer på at rette det. Når vi engang får en bot, der kan sætte/rette defaultsort på, så kan vi jo altid tage det op igen.

Bare fordi "forfatteren" til projektet får en ny idé betyder det jo ikke, at vi skal rette det. --MGA73 9. jun 2009, 22:41 (CEST)

New interface

New interface -- sk 1. sep 2009, 08:55 (CEST)

Hej alle der læser. Jeg har prøvet at bruge det nye system og selv om det lige pt er på engelsk (forstår ikke helt hvorfor den gamle oversættelses-side ikke virker, men det er trods alt også en alpha). På den måde kan man nemmere se (eller rettere ikke se) hvad der allerede er lavet i stedet for at folk ikke altid får det slettet fra denne side --Anigif 2. sep 2009, 13:45 (CEST)

Jeg har også lige prøvet det nye interface. Men det er et problem at man ikke kan afmærke en klup af gangen og det er ikke lige til at bruge funktionen "Relaterede ændringer". --Steen Th 2. sep 2009, 22:06 (CEST)

Nyeste udgave

Burde stå øverst i en boks:

Nyeste udgave findes her: http://toolserver.org/~sk/checkwiki/dawiki/ og det er denne fil: http://toolserver.org/~sk/checkwiki/dawiki/dawiki_output_for_wikipedia.txt Christian75 20. jan 2010, 11:48 (CET)

Tjaa - er det ikke lige meget... se også i lyset af dette fra den 22/1: de:Benutzer:Stefan Kühn/Check Wikipedia. --Steen Th 24. jan 2010, 22:44 (CET)

WikiCleaner

Hi,

Interface for Check Wikipedia

Announcing a tool to help with Check Wikipedia, WikiCleaner, with a new interface dedicated for this project.

--NicoV

There was a bug in the previous version : the Check Wiki interface was available only if the Experimental features were enabled in the Options. It's fixed in the new version. --NicoV

Status på de store "fejl"

Efterhånden der meget få type af fejl, hvor der er store mængder af observationer. Så synes det kunne være tid til, at vende hvad der skal prioriteres og finde ud hvem vil gøre hvad.

Der er i øjeblikket 4 stk., hvor der er mange observationer tilbage. Jeg har talt dem og se hvordan nogle af andre wiki'er prioritere det:

nr	beskrivelse	antal	da	de	en	fr	sv	no
30	Billede uden beskrivelse	4902	høj	høj	deaktiveret	deaktiveret	lav	høj
84	Sektion uden indhold	593	høj	høj	høj	deaktiveret	lav	mellem
62	Ensom overskrift	2819	mellem	mellem	deaktiveret	deaktiveret	deaktiveret	deaktiveret
68	Link til andet sprog	1224	mellem	mellem	deaktiveret	mellem	deaktiveret	mellem

Tallene er fra den 18. september.

Billede uden beskrivelse

Her er for mange observationer p.g.a. navn på billed angives inde i en skabelon sammen med angivelse af størrelse. Billedtekst bliver tilføjet af skabelonen.

Der er er gruppe af billeder - flagiconer - Bruger:Gorbi tog ad dem på et tidspunkt sammen med Bruger:LA2. Jeg har fundet en del af dem, som jeg vil gerne have rettet - gerne med bot.

Min indstilling er at vi beholder den aktiv indtil videre, men gør ikke noget ved det, andet end hvis en alligevel er ved at kigge på en artikel, så kan man alligevel indsætte den manglede billedtekst.

Sektion uden indhold

Den er jeg ved at kigge på. En del gange er det fordi en artikel ikke er gjort færdig at der er en tom sektion. Andre gange er data som p.t. mangler. Der er følgende muligheder for rettelse:

• Kommentere sektion ud - så er den til det tidspunkt hvor der er brug for den
• Indsæt en skabelon {{tom sektion}} for at angive at en sektion skal fyldes ud.
• Ændre hierarki - nogen gangen er det fejlen at en overskrift har samme niveau som den efterfølgende.

Min indstilling er, at det er et problem, som vi gør noget ved.... det er fleste tilfælge halvfærdig artikler, der skal kigges på.

Se Wikipedia:Sletningsforslag/Skabelon:Tomt afsnit --MGA73 17. sep 2011, 15:52 (CEST)

Ensom overskrift

Efter min meningen er det et mindre problem, da der er kun en overskrift mellem andre med et andet niveau. Er der nogen uenig med det? Min indstilling den fejl bliver deaktiveret.

Link til andet sprog

Jeg prøvet at kigge på det - men det er meget omfangsligt. Men jeg vil opdele følgende:

• De fleste gange er det referencer til artikler, der ikke findes på dawiki. Jeg kan godt lave en ønskeliste til at refusere det problem. Men det kræver del kræfter for at gøre noget ved det.
• Der hvor der findes en danske artikel, som kan linkes til i stedet, vil de i fleste tilfælge er det bare at ændre link til dawiki. Andre tilfælge skal teksten rettes til.
• Der hvor der linkes til samme eller anden artikel på et andet sprog; disse links kan gemmes bag en skabelon.

Eksempler: Største byer i EU, Frankrigs provinser, Apotekspersonale, Senantikken

Efter jeg har kigget på det, synes jeg denne observation ikke er vær at kigge på. Min indstilling denne fejl bliver deaktiveret. Hvis der skal gøres noget ved det, skal nogen tage hånd om det.

Generelt

Vi er kommet langt ned. Jeg har kigget på nogle af de fejl, som er deaktiveret. En som jeg har kig på er link til andre wikiprojekter. Min bud det er en lille sag, hvor der allerede er skabeloner som kan erstatte linket. --Steen Th 21. sep 2010, 18:11 (CEST)

Jeg synes det er fint at have WPCW til at finde fejl og mangler, men jeg synes ikke altid, at prioriteringen er rigtig. Fx står mange som "høj" hvor jeg ville sige, at det har mindre betydning. Fx anser jeg en POV-artikel som betydeligt værre end at der blot er en iw 2 gange.

Fejl, som rettes automatisk næste gang en bot kommer forbi alligevel, burde vi efter min opfattelse ikke ofre den store opmærksomhed. Hvis vi alligevel vil bruge ressourcer på at rette det, så bør det ske med botter, der klarer det automatisk, så almindelige brugere ikke fristes til at bruge kræfter på at arbejde med det manuelt. Dvs. det bør stå som lav prioritet og så skjult som overhovedet muligt.

Mht. iw-links i artikler, så er det interessant. Men der er nok ikke nogen anden udvej end at tage listen manuelt. --MGA73 17. sep 2011, 15:47 (CEST)

De er nogle af fejlen som kunne prioriteres anderledes, som du har observeret. Men når jeg tager en runde er det kun manglede billedtekst, som ikke kommer i bund i øjeblikket.

Det med at vente på at et bot kommer forbi holder ikke - jeg har par gange set andre brugere netop rette de observationer - specielt fordi de er meget lette at rette. Så jeg tager en bot-runde med dem, så de er væk i et hug, så der kun er de dem tilbage hvor det skal rettes semimanuelt med Wikipedia Cleaner eller helt manuelt. --Steen Th 17. sep 2011, 16:25 (CEST)

html-tags versus span style

Jeg vil gerne at alle følgende redigeringer fra Steenthbot fra idag bliver rullet tilbage.

• WPCW fejl 33 <u>'''tekst'''</u> versus <span style="text-decoration:underline">tekst</span>
• WPCW fejl 41 <big>'''tekst'''</big> versus <span style="font-size:larger">'''tekst'''</span>

Selvom det er nyttigt i tabeller at ændre disse koder, har det intet betydning i brødteksten, det er faktisk sådan at det gøre det mere vanskeligt at forstå for nye der vil bidrage i teksten. Derfor en forværring i stedet for en forbedring. Meget har ændret sig i disse mange år, og som jeg kan se, er projektet på disse punkter forældet.

Og følgende redigeringer må gerne ændres:

• WPCW fejl 69 ISBN 978-87-992958-2-1 til {{ISBN |978-87-992958-2-1}}

I slutning af året bliver Magic Name "ISBN" nemlig slået fra i Wikisoftwaren. Derfor skulle der oprettes en skabelon til det. (Der ligger en meddelelse om det på Phabricator)

 •   Rodejong   💬 ✉️ ☑ 10. jul 2017, 12:17 (CEST)

Enig, denne omend teknisk fine kode er helt korrekt, er den ekstremt bruger fjendtlig, og hvis den kan afskaffes bør det ske så hurtigt som muligt. Den kan kun tjene til at skræmme folk væk. -- Mvh. Vrenak (diskussion) 10. jul 2017, 16:03 (CEST)