Keskustelu Wikipediasta:ORES/Arkisto 2

Tämä sivu on arkisto. Älä muokkaa tätä sivua.

Käännös

Kävin suomentamassa tuon Revision scoring jutun läpi. Jonkun muun pitäis ilmeisesti vielä käydä lukemassa ne suomennokset läpi, ja hyväksyä ne. --4shadoww (keskustelu) 1. huhtikuuta 2017 kello 16.06 (EEST)

Tarkistan termien käännöksiä: Onko label varmasti etiketti, workset varmasti työarkki?--Olimar 1. huhtikuuta 2017 kello 19.04 (EEST)

Wikification wikisointi?--Olimar 1. huhtikuuta 2017 kello 19.09 (EEST)

En ole varma. Nuo oli joku muu kääntänyt valmiiksi niin käytin niitä. Wikisointi on ihan itse keksimäni käännös Wikificationille. Jos jollain on parempaa ideaa miten nuo pitäisi suomentaa niin ne ovat tervetulleita. --4shadoww (keskustelu) 1. huhtikuuta 2017 kello 19.17 (EEST)

Minulla meni oikeastaan kuukausia siihen, että hioin Merkittyjen versioiden suomennokset kuntoon sellaisiksi, että ne ovat vähintään tyydyttävät ja eivät ole ristiriidassa muiden termien kanssa. Jos tämä on suomennettu hutaisten sinne päin, niin tulos voi olla vaikka kuinka huono. Kannattaa siis käyttää aikaa hyvän suomennoksen laatimiseen. Itse keksityt termit eivät ole ongelma. Kokonaisuuden hahmottaminen suomentamisurakassa vaatii aika paljon kääntäjältä. --Pxos (keskustelu) 5. huhtikuuta 2017 kello 14.36 (EEST)

Muutin Wikioinnin wikitykseksi jota oltiin käytetty jo aikaisemmin ja pari muuta kohtaa. Label = etiketti on ihan hyvä käännös. Toinen mikä tulee mieleen on leimaus. Sitten taas merkintä, merkkaus jne ovat huonoja käännöksiä labelille, koska ne ovat käytössä muualla. Workset=työarkki onhuono käännös ja parempia voisivat olla tehtäväkirja, tehtäväaineisto, tehtäväryhmä, tehtäväjoukko jne. --Zache (keskustelu) 7. huhtikuuta 2017 kello 16.52 (EEST)

Muutin työarkin tehtäväaineistoksi. Mikä mahtaa olla tällä käännöksellä kun sitä ei voi hyväksyä? --4shadoww (keskustelu) 7. huhtikuuta 2017 kello 19.53 (EEST)

Tutkitaan. Sellainen ajatus tuli mieleen, että sanan damaging käännös voisi olla vahingoittava tai vahingollinen joka tavoittaisi tuon työkalun kehittäjän ajatuksen paremmin kuin haitallinen. (Why use the term "damaging" instead of "vandalism"? "Vandalism" is just a subset of what we want to catch when we're doing RC Patrolling. The word "vandalism" implies deliberate malicious intent. However, a patroller's job is to look for damaging edits whether the damage was actually intended or not. Therefore, referring to the edits that the review tool flags as "damaging" is more true to the kind of work the system is designed to support.) [1] --Zache (keskustelu) 7. huhtikuuta 2017 kello 20.00 (EEST)

@4shadoww: Näetkö sen all -välilehdellä arvioitavien joukossa? (minä näen, mutta en pysty hyväksymään, koska olen muokkaaja) [2] --Zache (keskustelu) 7. huhtikuuta 2017 kello 20.09 (EEST)

Ei toimi minullakaan, vaikka en ole koskenut siihen.--Olimar 7. huhtikuuta 2017 kello 20.18 (EEST)

Näkyy myös siellä. --4shadoww (keskustelu) 7. huhtikuuta 2017 kello 20.20 (EEST)

@Nikerabbit: Osaatko sanoa miksei tuota pysty hyväksymään? --Zache (keskustelu) 7. huhtikuuta 2017 kello 20.23 (EEST)

Pistin kysymyksen [[3]] supporttiin, mutta kyse lienee aika lailla bugista joten tuskin kannattaa tuon hyväksymistä jäädä odottelemaan. --Zache (keskustelu) 9. huhtikuuta 2017 kello 20.45 (EEST)

phab:T132197 eli huono käännösavain. Ratkeaa projektin/koodareiden toimesta varmaankin vaihtamalla avaimen nimi toiseksi --Zache (keskustelu) 10. huhtikuuta 2017 kello 12.21 (EEST)

@Pxos:, haluatko tsekata käännöksiä läpi ennen kuin pistetään tiketille, että käännökset on tehty ja että sen osalta voidaan edetä? Sinänsä tämän jälkeen käännökset näkyvät käyttöliittymässä ja voidaan tehdä kääntämiskierros sen perusteella miltä ne siellä vaikuttavat. --Zache (keskustelu) 9. huhtikuuta 2017 kello 20.45 (EEST)

Ajattelin että huomenna tai viikonloppuna merkkaisin tikettiin, että käännökset on valmiit, vai tarviiko niitä vielä muuttaa. --4shadoww (keskustelu) 13. huhtikuuta 2017 kello 14.29 (EEST)

Siitä vain. Minun puolestani voit pistää jo aikaisemminkin ja todennäköisesti se muutos tarve tulee sitten kun nähdään tekstit käyttöliittymässä. Lisäksi voi olla, että tuo phab:T132197 on blokkaava tiketti eli meidän käännöstiketti ei etene ennen kuin se on korjattu. --Zache (keskustelu) 13. huhtikuuta 2017 kello 14.41 (EEST)

Näköjään Halfak omatoimisesti merkitsi käännökset valmiiksi. Nyt tarvitaan käännös tuolle "Edit quality (20k sample)". Mikäköhän olisi ymmärrettävä käännös tuolle? Mulla tulee vaan mieleen "Muokkausten laatu (20k näyte)". --4shadoww (keskustelu) 13. huhtikuuta 2017 kello 19.10 (EEST)

Tai "Muokkauksen laatu (20k otos)". Näytti muilla kielillä olevan "k" pelkkänä kirjaimena, ei oltu avattu enempää sitä. Stryn (keskustelu) 13. huhtikuuta 2017 kello 21.15 (EEST)

Tuo "Muokkauksen laatu (20k otos)" lienee ihan hyvä käännös. Pistän sen sinne käännökseksi. --4shadoww (keskustelu) 13. huhtikuuta 2017 kello 21.28 (EEST)

Työkalu on nyt näköjään käytettävissä: http://labels.wmflabs.org/ui/fiwiki/ --4shadoww (keskustelu) 14. huhtikuuta 2017 kello 19.28 (EEST)

Tuonne tuli pari uutta käännettävää teksitä tuon korjauksen myötä, niin käänsin ne. Joku toinen voisi tsekata ne läpi ja merkitä oikoluetuiksi. --Zache (keskustelu) 15. huhtikuuta 2017 kello 10.04 (EEST)

Käännöksethän ovat nyt ihan kamalia kun, pilkut ovat, ihan miten sattuu. Voisiko edes vähän yrittää pitää laatutasoa yllä? Ja minä en sitten jaksa käydä satoja virheellisiä käännöksiä läpi, vaan energia riittää vain moittimiseen. --Pxos (keskustelu) 12. toukokuuta 2017 kello 00.04 (EEST)

Toivottavasti en tee etikettivirhettä (heh), kun esitän labelin käännökseksi omaan korvaani suomalaisemmalta tuntuvaa nimikylttiä, nimilappua tai vastaavaa. Joskus sen voisi kääntää (tuote)merkiksi. Aiemmin koodariryhmässä XYZ toimiessani olisin siinä yhteydessä voinut suomentaa termin vaikkapa (tehtävä)nimikkeeksi. Nyt en siis mennyt katsomaan MediaWikiin, millaisissa yhteyksissä sanat siellä esiintyvät, vaan lauon näin mansikkakauden "mansikkahillopurkinmakuisella etikettiterminologialla". --Paju (keskustelu) 21. heinäkuuta 2017 kello 07.15 (EEST)

Vakautusbotti

@4shadoww: vakautusbotista, idea on ihan hyvä ja jos kerkeät kokeilla moisen tekemistä nyt viikonloppuna niin sekin olisi hienoa :) Spekseistä sen verran, että kannattaa lähteä koodissa siitä, että se voisi toimia muissakin wikeissä ja, että tekstit on käännettävissä. --Zache (keskustelu) 20. toukokuuta 2017 kello 12.46 (EEST)

Tee tunnukset Toollabs:iin ja kokeile kirjautua sinne ssh:lla noin tulevaisuutta ajatellen. --Zache (keskustelu) 20. toukokuuta 2017 kello 12.47 (EEST)

On jo tunnukset tuonne ja tuo nykyinen arkistointi botti pyörii tolla palvelimella. Tallensin vahingossa keskeneräisen viestin tuonne sinun keskustelusivulle, mutta nyt kun jätin sinne koko viestin, niin olitkin ehtinyt käydä kommentoimassa tänne. --4shadoww (keskustelu) 20. toukokuuta 2017 kello 12.57 (EEST)

Jatketaan vaikka täällä. --Zache (keskustelu) 20. toukokuuta 2017 kello 13.00 (EEST)

Ajattelin että sinulla voisi olla jotain kommentoitavaa tähän ja ideoita, että millä säännöillä botti voisi artikkeleita vakauttaa. Vai onko tuollaiselle edes tarvetta? Jonkinlainen yhteisön suostumus tähän loppujen lopuksi tarvitaan, jos aiotaan joskus ottaa käyttöön . Esimerkiksi ihan sellaiset säännöt voisivat olla ok, että mikäli ORES arvioi muokkauksen hyvin todennäköisesti pahantahtoiseksi, kumottavaksi tai vahingoittavaksi, niin botti vakauttaa sen tietyksi ajaksi, esimerkiksi 8 tunnin ajaksi mikäli artikkeli ei ole jo vakautettuna. Muita harkittavia vakautusperusteita voisi olla esimerkiksi väärinkäyttösuodattimen osumat ja mahdollisesti se mistä muokkaus on tulossa eli jos muokkaus tulee ip-avaruudesta josta tulee muutenkin paljon sotkemista, niin vakautus tapahtuisi nopeammin. --Zache (keskustelu) 20. toukokuuta 2017 kello 13.19 (EEST)

Pitää tutustua tuohon että miten mediawikin api:sta saa tietoa ulos noista väärinkäyttösuodattimista. Meinasitko muuten että jo yhden muokkauksen perusteella aletaan tekemään vakautuksia, eikä yritetä tunnistaa toistuvan vandalismin kohteeksi joutumista? Olin jo tuossa aikaisemmin tehnyt sellaisen testi algoritmin tuohon tunnistamiseen, että jos tietyn ajan sisällä artikkelissa kumotaan tietty määrä muokkauksia, ja toinen osapuoli kumoamisissa on hyväksymätön käyttäjä, niin vakautetaan artikkeli. Ensi viikolla yritän keretä tehdä muutaman lisää noita algoritmeja, ja hyödyntää myös ORES:ia vakautus perusteissa. --4shadoww (keskustelu) 21. toukokuuta 2017 kello 18.28 (EEST)

Miten / millä toi on tehty? Ts onko se cronjob tyyppinen komento vai pysyykö se käynnissä koko ajan? Jos jälkimmäistä niin googleta mediawikin eventstreamia. --Zache (keskustelu) 21. toukokuuta 2017 kello 18.36 (EEST)

Jatkona vähän. Se miten olet toteuttanut vaikuttaa aika paljon asioihin eli jos käytät pywikibot:ia pohjana, niin kannattaa varmaan käyttää mahdollisimman pitkälle sen funktioita ja jos ne ei nopeuden takia riitä niin tehdä suoria sql-kutsuja. Jos taas node.js:ää, niin silloin mediawiki-api:a ja evenstreamia. Mikäli systeemi on tehty php:llä ja mikäli php:llä, niin silloin lukea jutut mahdollisimman pitkälle suoraan tietokannasta.

Tuohon mitä mietin, niin minusta artikkelin voi vakauttaa lyhyeksi ajaksi jo silloinkin jos väärinkäyttösuodatin on varoittanut muokkauksesta tai estänyt muokkauksen ja käyttäjä muokkaa artikkelia heti sen jälkeen. Voi olla, että olisi fiksua vakauttaa kaikki muutkin artikkelit joita käyttäjä muokkaa jos suodatin on ollut sellainen, että siitä näkee että yritetty muokkaus oli sotkemista. Muutenkin minusta lyhyttä vakautusta voi käyttää jo silloin jos väärinkäyttösuodattimen/ORESin/IP-osoitteen/muokatun sivun yms perusteella voidaan ajatella muokkauksen olevan epäilyttävä, mutta mieluusti niin että kahden eri säännön tulee toteutua yhtä aikaa. --Zache (keskustelu) 21. toukokuuta 2017 kello 19.24 (EEST)

Pywikibot:ia olen tuossa käyttänyt, ja on koko ajan päällä oleva. Pitää tutkia noita väärinkäyttösuodattimia mitä voisi tuossa käyttää hyväksi. --4shadoww (keskustelu) 21. toukokuuta 2017 kello 21.13 (EEST)

ks. https://wikitech.wikimedia.org/wiki/EventStreams ja tuolta käsittääkseni saa myös logieventit. Mikäli on mahdollista, niin toteutuksen vois tehdä siten, että jollain wikisivulla on lista suodattimista ja siitä miten niiden kanssa toimitaan esim json:na ja kun botti käynnistyy, niin se lukee configuraation wikisivulta ja mikäli sivu muuttuu, niin se päivittää asetukset. --Zache (keskustelu) 21. toukokuuta 2017 kello 21.27 (EEST)

Tuo voisi olla ihan kätevä systeemi. Pitää vaan koodi puolella sitten vähän rajoittaa, ettei ihan kuka tahansa kadunmies pääse niitä asetuksia muuttamaan. --4shadoww (keskustelu) 22. toukokuuta 2017 kello 09.18 (EEST)

Tai lähteä siitä, että sivu on suojattu wikissä jollain tavalla. Esimerkiksi jos se on bottitunnuksen alasivulla js -päätteellä, niin ainoastaan kyseinen käyttäjätunnus tai ylläpitäjät pääsee muokkaamaan sitä. Jos se on muualla, niin sivu voidaan suojata muuten. Sellainen ajatus tuli mieleen, että tuo vakautusbotti on sellainen, että muutkin wikit voivat haluta ajaa moista, niin teksteistä kannattaa varmaan tehdä valmiiksi sellaiset, että ne ovat lokalisoitavissa helposti. --Zache (keskustelu) 22. toukokuuta 2017 kello 09.25 (EEST)

Olen saanut tehtyä nyt botin siihen pisteeseen, että se tunnistaa milloin vakauttaa artikkeli hyödyntäen ORES:ia, väärinkäyttösuodattimia ja muokkaushistoriaa. Myös asetusten lataus onnistuu nyt wiki-sivulta (Käyttäjä:4shadowwBOT/config.json), ja asetukset voidaan päivittää lennosta, eli ei vaadi uudelleen käynnistystä. Tiedätkö muuten jotain väärinkäyttösuodattimia jotka voisivat olla hyviä sotkujen jne. tunnistamiseen? Tuonne json:iin olen jo listannut joitain suodattimia. --4shadoww (keskustelu) 26. toukokuuta 2017 kello 23.09 (EEST)

Suodattimet 124,125,126 varmaan voi lisätä listaan myös ja katson tarkemmin vielä noita nykyisiä suodattimia. ORES-pistetyksistä tuon "reverted"-suodattimen voi ottaa minusta pois (esim konfiguraatiolla), koska se kaiketi perustuu yhä hyvin pitkälti siihen sanalistaan ja on muutenkin aika epätarkka. Saanko muuten tehdä todo-listan vakautusbotille tuohon projektisivulle? Taskit joita tulee nopeasti mieleen ovat koodi githubiin, englanninkielinen readme, mikäli koodin funktiot/muuttujat/kommentit ovat suomeksi niin niiden kääntäminen englanniksi, tuki ip-harmaalistalle jossa määritellään epäilyttävät ip-osoitteet (=oppilaitokset suomessa) joka toimisi yhtenä vakautusperusteena. Osin nuo ovat asioita joita en itse välttämättä ole tehnyt, mutta seulontaan liittyvissä jutuissa voisi tähdätä siihen, että työkaluja voisi käyttää muissa wikimedian wikeissä myös. --Zache (keskustelu) 27. toukokuuta 2017 kello 10.26 (EEST)

Voit tehdä todo-listan. Koodi on jo githubissa, funktiot/muuttujat/kommentit on englanniksi, mutta tosin kommentteja on todella vähän, että niitä varmaankin pitäisi kirjoittaa vähän lisää. --4shadoww (keskustelu) 27. toukokuuta 2017 kello 10.53 (EEST)

Suodattimia 124 ja 126 ei voi muuten käyttää kun ovat yksityisiä. --4shadoww (keskustelu) 27. toukokuuta 2017 kello 11.41 (EEST)

Mikäs nimi voisi olla hyvä tuolle bottitunnukselle? Olisiko VakautusBot tai VakauttajaBot hyvä? Lisäksi vielä pitäisikö tämä github repo siirtää jollekkin havainnollisemmalle nimelle?[4] Nyt tuo on kuin joku koodinimi jonka perusteella ei osaa kukaan sanoa mitä se tekee. --4shadoww (keskustelu) 28. toukokuuta 2017 kello 13.05 (EEST)

VakauttajaBot on minusta ihan hyvä nimi ja kriteeri varmaan on, että nimi pitää voida kirjoittaa 7-bittisillä aakkosilla ja siinä on teksti "bot". Repon nimen tosiaan voisi vaihtee joksikin selkeämmäksi josta näkee suoraan mistä on kyse. (stabilizerbot tai jotain)--Zache (keskustelu) 28. toukokuuta 2017 kello 13.30 (EEST)

Tein pienen taulukon artikkeleista mitä botti olisi halunnut vakauttaa Käyttäjä:4shadoww/Vakautusbotti. Tuo data on eilisestä päivästä lähtien tallennettua. --4shadoww (keskustelu) 31. toukokuuta 2017 kello 19.02 (EEST)

Aika hyvin tuo näytti tuon taulukon perusteella toimivan ja ehkä suurin yllätys oli, että väärinkäyttösuodattimet toimivat virheellisesti noiden salkkariartikkeleiden kohdalla. Sellainen juttu, että tein vakautusbottia varten tool labsiin sivun josta voi kysyä onko sivun versio kumottu ( http://tools.wmflabs.org/fiwiki-tools/pendingchanges/?lang=uk&action=reverted&family=wikipedia&rev_id=15556107 ). Tuo ei tue tällä hetkellä kuin yhtä revid:tä kerrallaan, mutta periaatteessa voisi olla hyödyllistä seurata sitä tuleeko vakauttamisen aiheuttanut versio kumotuksi vai ei ja siten seurata virheellisten positiivisten määrää. --Zache (keskustelu) 11. kesäkuuta 2017 kello 15.11 (EEST)

Hyvin näyttäisi toimivan. Sellainen ehdotus tuli mieleen, että yhteenvedossa voisi olla sen muokkauksen revid joka aiheutti vakautuksen sekä linkki revid:stä diffiin. --Zache (keskustelu) 17. kesäkuuta 2017 kello 12.05 (EEST)

Tuo voisi olla ihan hyvä lisäys. --4shadoww (keskustelu) 17. kesäkuuta 2017 kello 12.14 (EEST)

Tein nyt Wikipediaan botilla kerran päivässä päivittyvät sivut user:Fiwiki-tools-bot/IP-graylist.js (Quarry:20107) ja user:Fiwiki-tools-bot/page-graylist.js (Quarry:20109). Näistä ensimmäinen pitää sisällään listan ip-osoitteista joista tulee todennäköisesti vandalismia ja jälimmäinen listan usein vandalisoiduista sivuista. Lisäsin myös pendingchanges API:iin mahdollisuuden pyytää listan käyttäjätunnuksista/IP:stä jotka ovat laukaisseet edellisten 24h aikana väärinkäyttösuodattimen "disallow" -toiminnon. (Quarry:20110)

• http://tools.wmflabs.org/fiwiki-tools/pendingchanges/?lang=fi&family=wikipedia&action=graylist

Ajattelin, että noita voisi kokeilla käyttää muokkausten pisteytyksessä tyyliin mikäli sivu tai ip löytyy listalta, niin se on 1 piste. En osaa ennalta sanoa kuinka hyvin tuo toimii. --Zache (keskustelu) 8. heinäkuuta 2017 kello 11.08 (EEST)

Pitää pistää kokeiluun. Varmaankin tässä viikonloppuna kerkeän sen tekemään. --4shadoww (keskustelu) 8. heinäkuuta 2017 kello 11.20 (EEST)

Nyt on greylist käytössä. Lisään vielä myöhemmin testiksi tuon listan artikkeleista. --4shadoww (keskustelu) 9. heinäkuuta 2017 kello 11.01 (EEST)

IPv6 osoitteista, niin 2001:14BB:* ja 2001:999:* alueet lienee sellaisia, että ne voisi harmaalistata kokonaisuudessaan myös. Nuo ovat mobiiliverkkoja ja tällä hetkellä niiden sisältö sillä rajoilla, että kannattaako ne estää ja syksyllä ne ovat selkeästi estettäviä, koska niistä tulee niin paljon sotkua. --Zache (keskustelu) 17. heinäkuuta 2017 kello 12.40 (EEST)

Harmaalista lisätty: Käyttäjä:VakauttajaBot/ip-space.js, ja sain myös viimein pistettyä artikkelien harmaalistan käyttöön. --4shadoww (keskustelu) 17. heinäkuuta 2017 kello 15.10 (EEST)

Tarkastelin hiukan botin lokia ja vakautuksia, niin näyttäisi aika hyvin tarkkuutta lisäävän uudet harmaalistat. --4shadoww (keskustelu) 23. heinäkuuta 2017 kello 13.44 (EEST)

Miksi botti näyttää odottavan viisi minuuttia, ennen kuin se vakauttaa artikkelin huonon muokkauksen jälkeen? -kyykaarme (keskustelu) 10. heinäkuuta 2017 kello 21.59 (EEST)

Koska bottihakemuksen yhteydessä pyysin siihen tuollaista ominaisuutta niin pitkäksi aikaa kuin botin toiminta häiritsee palautustyökalun käyttöä. –Ejs-80 10. heinäkuuta 2017 kello 22.03 (EEST)

Rollback

Tämä vakauttajabotti taitaa aiheuttaa sen, että palautus ei enää poista sitä ensimmäistä sotkua, jonka jälkeen botti vakautti sivun. (Savir) [5]. Tämähän johtuu siitä, että kumous kumoaa viimeisimmän käyttäjän muutoksen ja tässä tapauksessa se viimeinen on vakauttava botti. Cenariumilta voisi kysyä toimiiko tämä samoin deferred changes -systeemissä samoin ja näkyykö siinä vakautukset ylipäätänsä artikkelin versiohistoriassa ja logimerkintöinä. Jos Cenariumilla ei ole mitään hyvää ideaa miten tämän kanssa pitäisi toimia, niin voisi miettiä pitäisikö tästä tehdä bugi/improvement -tiketti rollback:n alle. --Zache (keskustelu) 22. kesäkuuta 2017 kello 06.48 (EEST)

Jotain tuolle voisi yrittää tehdä. Nykyinen systeemi toimii vähän hölmösti noiden vakautaus- ja suojausmerkintöjen suhteen. --4shadoww (keskustelu) 22. kesäkuuta 2017 kello 11.27 (EEST)

Ainakin näiden mukaan [6][7] näyttäisi ettei tuosta jää muokkaushistoriaan merkintää. Mutta mikä näin muuten mahtaa olla tuon deferred changes -lisäosan tila, kun näyttää nopeasti katsottuna olevan aika hidasta tuon kehittäminen? Luulisin että tuo rollback toiminto olisi jotenkin korjattavissa. --4shadoww (keskustelu) 22. kesäkuuta 2017 kello 15.20 (EEST)

Vaatisi code reviewin jotta se etenisi ja se koskee aika moneen juttuun. Enemmän olen kiinnostunut siitä, että onko cenariumilla ehdotusta ratkaisuksi kuin että odottaisin deferred changesin etenevän. Rollbackin muuttaminen vaatii myös sen että katsotaan koodista mitä pitää muuttaa ja, että tehdään ehkä myös patch sille. --Zache (keskustelu) 22. kesäkuuta 2017 kello 17.14 (EEST)

Luin näköjään huolimattomasti tuon ensimmäisen kommenttisi. Minäpä kysyn häneltä tuosta asiasta. --4shadoww (keskustelu) 22. kesäkuuta 2017 kello 17.47 (EEST)

Tutkin koodia sen verran, että palautus-työkalu menee rikki, koska vakautuksen yhteydessä tehdään "null"-edit jonka yhteenvetona on vakautuksen yhteenveto jotta vakautus näkyisi historialistassa. Tätä on hiukan hankala käsitellä rollback-työkalun koodissa, koska tuo muokkaus ei varsinaisesti eroa muista muokkauksista. Lisäksi koko rollbackin idea ja ohjeet perustavat siihen ajatukseen, että tuoreimman muutoksen tehneen muokkaajan muokkaukset kumotaan ja jos tätä rupeaa sekoittamaan, niin sitä on hankala selittää käyttäjille.

1. Nollamuokkaus itsessään tehdään seuraavassa funktiossa:
   • business/PageStabilityForm.php: updateLogsAndHistory() ja siinä kohta "Insert a null revision..."
     • Tätä kutsuva funktio doSubmit() olettaa saavansa tehdyn revision takaisin joten tätä pitää muokata myös. Käytännössä luodun revision käsittelyn voi kokonaan jättää pois.
2. Edelleen jos katsoin oikein koodia, niin deferred changesin vakautusasetusten resetointi arvioinnin jälkeen on seuraavassa funktiossa:
   • business/RevisionReviewForm.php: doSubmit() ja tässä rivi 341... "if ( $config['autoreview'] === 'defer' ..."

tuo "defer" on oikeasti käyttäjäryhmä jossa käyttäjän tulee olla jotta hän voi voi automaattisesti/manuaalisesti arvioida sivun (vakautusasetukset sivulla kohta: "Seulonnan ja automaattiseulonnan rajoitukset" ja API-kutsussa parametri "autoreview") johon on luotu maaginen käyttäjäryhmä joka voi tehdä juttuja ja niitä voi määrittää conffeilla lisää. Eli kaikista yksinkertaisin muutos olisi, että muutetaan funktioita updateLogsAndHistory() ja doSubmit() ja configuroidaan jokin defer:iä vastaava käyttäjäryhmä.

Huono puoli tässä on se, että käyttäryhmien toiminnan kovakoodaaminen tällä tavoin on rumaa ja mieluummin lisäisin vakautuksen kestoarvoon jokin uuden avainsanan joka kertoisi vakautuksen kestävän seuraavaan arviointiin saakka Korjaus Expiryn toiminnallisuus on säilytetty normaalina, jotta odottavalla muutoksella on maksimiaika jonka jälkeen se automaattisesti hyväksytään. --Zache (keskustelu) 23. kesäkuuta 2017 kello 00.40 (EEST)

@4shadoww:: Kokeillaanko tehdä patchiä tähän. Se, että pääsee historaan tulevasta versiosta eroon on koodimielessä aika suoraviivaista (kohta #1), mutta se MILLOIN historiaan ei pitäisi luoda uutta versiota on jo hiukan monimutkaisempaa ja vaatii ajattelutyötä. Yksinkertaisin vaihtoehto olisi tehdä vain jokin asetus joka on tyyliä wgFRSilentStabilization tai wgFRSilentBotStabilization jolla voisi poistaa bottien tekemät vakautukset versiohistoriasta. Hiukan monimutkaisempi olisi tehdä jokin defer-tyyppinen systeemi jossa asetus resetoituu automaattisesti kun arviointi tehdään. Periaatteessa tuo ylläolevat kaksi kohtaa riittää siihen, mutta se missä pitää tehdä ajattelutyötä on, että miten tuo 'defer' taso asetetaan ja käytetäänkö siihen erillistä API kutsua ja sanotaan arvon olevan varattu sana jota ei saa käyttää muuhun (kuten deferred changesissa) vai luodaanko erillinen käyttäjäryhmä johon pistetään esimerkiksi kaikki autoreview käyttäjät. Tällöin käyttäjäryhmän luominen onnistuu asetuksilla, se näkyy käyttöliittymässä ja sen asettamiseen voi käyttää nykyisiä API-kutsuja. --Zache (keskustelu) 23. kesäkuuta 2017 kello 12.57 (EEST)

Aloitin tälläisen Wikiprojekti:ORES/Mediawiki ja flaggedrevs asennus jos kiinnostaa katsoa tarkemmin miten kooditasolla jutut toimii. Kirjoitan paremmat ohjeet myöhemmin, koska nyt pitää huomioida se, että julkinen liikenne lopettaa kl 14 toimintansa, mutta ehkä tuokin auttaa alkuun. --Zache (keskustelu) 23. kesäkuuta 2017 kello 13.12 (EEST)

Voisi kokeilla tehdä. Luulen vain ettei minun php osaamiseni ihan riitä tuon tekemiseen, kun on jo vuosia viime kerrasta kun php:ta käytin. Mutta pitää ihan mielenkiinnosta tuota koodia tutkia. Olisi kyllä hienoa, jos tuohon saataisiin jokin ratkaisu. --4shadoww (keskustelu) 23. kesäkuuta 2017 kello 13.41 (EEST)

Jes, jos edetään niin, että kokeile sinä asentaa paikallisesti tuota mediawikiä+flaggedrevs:iä mw:Gerrit/Getting started ohjeilla (ks. mw:gerrit), niin minä teen jonkinlaisen patchin tuonne jossa systeemi tekee sen mitä halutaan. Katsotaan sen jälkeen mitä tehdään seuraavaksi. En ole myöskään itse aikaisemmin asentanut tai tehnyt mitään tuon gerrit:n kautta tai ylipäätänsä lähetellyt patchejä mediawikille, mutta kerta se on ensimmäinenkin. --Zache (keskustelu) 23. kesäkuuta 2017 kello 14.44 (EEST)

Minkälaisen muuten meinasit tehdä siitä patchista? Tuolla yksinkertaisella tavalla vain jotenkin hienostuneemmin? --4shadoww (keskustelu) 25. kesäkuuta 2017 kello 00.26 (EEST)

Niin sillä vain meinasin kysyä, kun jos ajattelit tehdä sellaisen, joka vain yksinkertaisesti jättäisi esim. bottien vakautukset merkitsemättä artikkelin historiaan, ja et ole vielä kerennyt sitä tekemään, niin periaatteessa minäkin pystyisin silloin sen patchin lähettämään. --4shadoww (keskustelu) 26. kesäkuuta 2017 kello 20.14 (EEST)

Aika lähellä tuota yksinkertaisuudessaan. Olin aikeissa tehdä sellaisen, että mikäli vakautuksen tasona on "defer", niin sitä ei merkitä artikkelin historiaan JA mikäli mikäli sivun vakautustasona on arvioitaessa "defer", niin se vakautusasetukset palautetaan arvioinnin yhteydessä vakiotasolle joka oli sama kuin tuossa yllä oleva RevisionReviewForm.php:n doSubmit():n muutos jolloin se olisi yhteensopiva Cenariumin patchien kanssa. Periaatteessa tuo toimii niin kuin pitäisi, mutta patchin ja branchin tekeminen jäi odottamaan sitä, että olisin ehtinyt lukemaan niitä ohjeita joita linkitin sinulle. Jos haluat ja ehdit tekemään muutoksen niin siitä vain. --Zache (keskustelu) 26. kesäkuuta 2017 kello 21.07 (EEST)

Tuon vakautus tason lisääminen näyttäisi olevan vähintään hankalaa tai mahdotonta. Yksi tapa tehdä tuo on se, että lisätään kaikille käyttäjille joilla on "autoreview" oikeus myös "defer" oikeus, ja asetettaisiin sivun vakautusasetuksiin, että vain "defer" oikeuksilla saa arvioida muutoksia, eli asetetaan "autoreview" arvo. Jotenka tuota "autoreview" arvoa voitaisiin käyttää tuohon tunnistukseen, kuten aikaisemmin taisit jo selittää. Tuo olisi helppo tehdä, mutten tiedä sitten onko tuollainen viritelmä sitten vähän liian "hacki". --4shadoww (keskustelu) 27. kesäkuuta 2017 kello 00.31 (EEST)

Juu, niihän se taitaa olla. Tuo "deferred changes" tekee sisäisesti sen nimenomaan noin. Sillä erotuksella, että siinä ei ole asetuksissa määritellä oikeutta "defer" jolloin suojaustasoa ei näy käyttöliittymässä ja suojaus tehdään omalla API-kutsulla. Joka tapauksessa, niin jos tuo ratkaisuni on jo sinusta liian hack, niin se todennäköisesti ammuttaisiin alas code reviewissä myös, niin se voidaan varmaankin unohtaa ja voidaan siirtyä tuohon sinun ehdottamaasi. Jos tuon käyttäjäoikeustasolla tunnistuksen haluaisi tehdä oikein, niin varmaan kannattaa tehdä se siten, että lisää uuden käyttöoikeuden kuten vaikka "silentstable", tunnistaa koodissa sen ja antaa tämän configuraatiolla kaikille botti-tunnuksille. Vakautusoikeus jäisi yhä "stablesettings" käyttöoikeuden taakse ja "silentstable" vaikuttaisi ainoastaan tuohon tehdäänkö nulledittiä vakautuksen yhteydessä. --Zache (keskustelu) 27. kesäkuuta 2017 kello 04.58 (EEST)

Tein nyt sellaisen, että jos käyttäjällä on "silentstable" oikeudet, niin jätetään null-edit tekemättä. Ja tuo pistettäisiin päälle globaalilla "$wgFRSilentStabilization" muuttujalla. Pitää vielä lukea hiukan noita ohjeita, että tuo täyttäisi jotenkin perusvaatimukset. --4shadoww (keskustelu) 27. kesäkuuta 2017 kello 14.00 (EEST)

Lähetin muuten tuon muutoksen gerritiin jonkin aikaa sitten: gerrit:361894. --4shadoww (keskustelu) 28. kesäkuuta 2017 kello 21.24 (EEST)

Hjyvä. Koodi näytti OK:lta eikä myöskään mikään tuntunut hajonneen kun naksuttelin käyttöliittymällä kautta vakautusta pois ja takaisin. Jos muutat tuota, niin if ( $this->reviewThis && !$frev ) -kohtaan voisi lisätä kommentin siitä mikä tuo reviewThis on, koska sitä ei oikein voi mitenkään koodista päätellä. Toinen on, että tuossa toisessa samoihin tiedostoihin koskeneessa branchissa oltiin tehty muutos 18n/flaggedrevs/qqq.json -tiedostoon, niin voisi varmaan varmistaa tarvitseeko lokalisointisysteemi myös sen. --Zache (keskustelu) 29. kesäkuuta 2017 kello 07.06 (EEST)

Selkeytin hiukan kommenttia, joka sitä edellä oli. 18n/flaggedrevs/qqq.json -tiedostoa käytetään dokumentaatioon, mikä näkyy translatewikissä. Olin unohtunut lisätä sinne dokumentaation minkä kävin nyt sinne lisäämässä. Lisäsin sinut reviewers listalle, niin voit käydä arvioimassa sen. Se saattaisi hiukan nostaa todennäköisyyttä, että patchi hyväksyttäisiin. --4shadoww (keskustelu) 29. kesäkuuta 2017 kello 23.01 (EEST)

Lisäsin nyt sitten checkboxin ja muutin api:a, että pystyy valitsemaan milloin jätetään nollamuokkaus tekemättä, kun ei ollutkaan kovin hankalaa edes toteuttaa. Pitää vielä testata kunnolla tuota toimintoa, ja tutkia vielä hiukan koodia varmuuden vuoksi. --4shadoww (keskustelu) 30. kesäkuuta 2017 kello 11.04 (EEST)

Jätin tuonne kommentin. En kokeillut muuten koodia ja nuo kommentit tuli diffien katsomisen perusteella ja ehkä avaan niitä hiukan tarkemmin. Eli tällä hetkellä se mikä tuossa osui eniten silmiin on se, että $wgFlaggedRevsSilentStable:a tarkistellaan niin useassa paikassa, että se ei ole koodin ylläpidättyvyyden kannalta hyvä juttu ja jos kaikki ominaisuudet tekisivät samaa, niin on hankalaa enää tietää mitä koodi tekee. Helpompaa on vain tehdä ominaisuudesta sellainen, että se on aina käytössä. Vastaavasti, niin formin:n submit:n sekä API-kutsun parametrien vastaanottamisessa voitaisiin lukea aina tuo silent-parametri ja vasta itse vakautuksen yhteydessä (PageStabilityForm.php ja siinä doSubmit()) tarkista onko silentStable sallittu ja jos ei ole, niin palauttaa virheilmoitus.

Mitä tulee itse tuohon patchin arviointiin ja sen läpi saamiseen, niin luulen, että voidaan pyytää Niklasta tekemään code review:n. Se mitä voitaisiin kuitenkin tehdä on, että patchin selityksessä voisi olla maininta vakautusbotista ja siitä, että se automaattisesti vakauttaa juttuja AbuseFilter:n ja ORES:n perusteeella. Lisäksi voisi ehkä tehdä muutokselle ihan tiketin phabricatoriin jossa on tarkemmin myös linkit vakautusbot:n koodiin sekä asiaankuuluviin logeihin. --Zache (keskustelu) 1. heinäkuuta 2017 kello 04.18 (EEST)

Kävin nyt muuttamassa sitä siten, että on aina päällä, ja nyt api antaa virheen, jos oikeudet eivät riitä. --4shadoww (keskustelu) 1. heinäkuuta 2017 kello 14.24 (EEST)

Näköjään unohtui muuttaa patchin selitystä. Pitää vielä käydä se muuttamassa. --4shadoww (keskustelu) 1. heinäkuuta 2017 kello 14.28 (EEST)

Koitin jotain selittää siitä vakautusbotista. Minkälainen tuosta tiketistä pitäisi tehdä? Niinkun mitä tageja siihen pitäisi lisätä? --4shadoww (keskustelu) 1. heinäkuuta 2017 kello 16.09 (EEST)

Jos teet jonkun muutoksen tuohon koodiin, niin samalla voisi muuttaa tätä sen verran, että tekee tuossa vain tarkistuksen if ( $this->getSilentThis() ), koska käyttöoikeudet on nyt tarkistettu jo alussa. Samalla voisi kääntää true/false autoreview edit:t päinvastoin jolloin vertailusta jää myös NOT pois.

if ( !$this->getSilentThis() || !$this->canSilentStable() ) {
    $ok = FlaggedRevs::autoReviewEdit( $article, $this->user, $rev, $flags, true );
 } else....

--Zache (keskustelu) 2. heinäkuuta 2017 kello 04.42 (EEST)

Testasin toimintaa naksuttelemalla käyttöliittymää ja tekemällä API-kutsuja. Näytti toimivan hyvin, mutta olit ilmeisesti jättänyt tarkoituksella protection-modesta tuone silentStable:n pois? Toinen minkä huomasin on, että jos yrittää vakauttaa sivua API:n avulla silentstable:a käyttäen, niin tulee virheeksi "code:unknownerror" kun siinä pitäisi kaiketi olla "code": "permissiondenied" joka tulee silloin kun yrittää vakauttaa sivua ilman vakautusoikeutta. --Zache (keskustelu) 2. heinäkuuta 2017 kello 07.30 (EEST)

Meinasin aluksi tehdä myös protection-modelle tuon, mutta en sitten tehnytkään, koska se ei periaatteessa ole vakautus. Minkälaisen kutsun teit, kun en saannut uudelleen tuotettua "code:unknownerror" virhettä, vaan tulee "code:silent_stabilize_denied", "info:Permission denied."?

Parametrit: Special:ApiSandbox#action=stabilize&format=json&default=stable&autoreview=sysop&expiry=infinite&reason=&token=&title=testing2&silent=1 (linkki on localhost:iin,) ja virhe tulee kun käyttäjällä ei ole "silentstable" -oikeutta ja silent=1. --Zache (keskustelu) 2. heinäkuuta 2017 kello 10.42 (EEST)

Onkohan sinulla vanha patchi asennettuna tai jotain, kun en saanut tehtyä tuota virhettä edes uudella mediawiki asennuksella, uusimalla patchilla gerritistä ja samoilla parametreilla. Vai voikohan php versio vaikuttaa tähän? Olen käyttänyt versiota 7.1.6.

Kokeilin tehdä virhettä näillä eri asetuksilla:

• silentstable = true, stablesettings = false
• silentstable = false, stablesettings = true
• silentstable = false, stablesettings = false

--4shadoww (keskustelu) 2. heinäkuuta 2017 kello 11.41 (EEST)

Ratkaisin tuon ja näemmä se on ominaisuus. Mikäli virhe käsitellään api/actions/ApiStabilize.php doExecute() { ... }, niin virhe on muodossa {"error":{"code":"unknownerror","info":"Permission denied.","*":"See http://localhost/mediawiki/api.php for API usage"}} ja jos se tulee jo api/actions/ApiStabilize.php execute() -funktiosta, niin se tulostuu muodossa {{"error":{"code":"permissiondenied","info":"Permission denied","*":"See http://localhost/mediawiki/api.php for API usage"}} . Ne virheet jotka palautuvat PageStabilityForm.php:n doSubmit():sta tulostuvat tuossa doExecutessa. Eli virhe sinänsä ei näemmä ole virhe vaan "ominaisuus". lisäys:. Koska se on "ominaisuus" ja se on toiminut jo aikaisemmin noin niin ei lähdetä korjaamaan sitä tässä, mutta voidaan tehdä siitä tiketti kyllä. --Zache (keskustelu) 2. heinäkuuta 2017 kello 12.26 (EEST)

siellä on muuten aikaisempi typo business/PageStabilityForm.php:doSubmit():ssa. return 'stablize_denied'; . Typo ei tule esille ainakaa API:n kohdalla, koska ko. käyttöoikeus on käsitelty jo aiemmmin. --Zache (keskustelu) 2. heinäkuuta 2017 kello 12.21 (EEST)

Ja olit oikeassa, että kyse oli jostain muusta kuin koodissa olleesta ongelmasta. Tuo minun mediawiki core -versioni oli kuukauden vanha snapshot ja tuo virheilmoitukseen liittyvä ongelma ratkesi kun otin kaiken git-reposta. --Zache (keskustelu) 2. heinäkuuta 2017 kello 13.31 (EEST)

Phab-tiketti: Make null-edits optional

Finnish Wikipedia is currently testing a bot which stabilizes the pages which are detected as harmful using ORES or AbuseFilter with a 24 hour stabilization. Currently when page is stabilized the system will duplicate the stabilization log comment to the page history using null-edit. However a side effect of this is that when the page is vandalized there will be at least three edits in the page history 1.) vandalism itself, 2.) stabilization of the page and 3.) the revert and which will flood the page histories.  Second problem about null-edits are that they will "break" rollback feature because rollback will try to revert the latest edit which is after the null-edit, the stabilization. 

Proposed solution in LINK TO GERRIT to fix this is to make null-edits optional. To perform stabilization without null-edit the user must have "silentstable" rights and set the silent = true

Links
* VakauttajaBot's stabilization logs
* Village pump discussion
* bot request and comments about the broken rollback feature
* link to the bot source code

---

Tiketistä, niin tageista varmaankin MediaWiki-extensions-FlaggedRevs, Patch-For-Revieẅ́ (napattu phab:T118696) ja selitystekstiksi voisi pistää jotain tämän tyyppistä (pistin oman otsikon alle. Yllä olevaa tekstiä saa tässä vapaasti editoida) --Zache (keskustelu) 2. heinäkuuta 2017 kello 04.42 (EEST)

Tein tiketin: phab:T169457 --4shadoww (keskustelu) 2. heinäkuuta 2017 kello 17.13 (EEST)

Linkitys tiketin ja gerritin välillä taitaa vaatia vielä sen, että gerritin commit-viestissä on rivi Bug: T169457 (ks. esimerkki ja mw:Gerrit/Cross-repo dependencies) --Zache (keskustelu) 2. heinäkuuta 2017 kello 19.53 (EEST)

Vakautustilastoja

Tein kerran päivässä päivittyvän tilaston. Jos tulee mieleen jotain mitä haluaisit tuohon niin sano ja yritän varmaan saada siihen lisäksi kumotut vakauttamattomat muutokset jos keksin miten saan tehtyä sen fiksusti. --Zache (keskustelu) 6. heinäkuuta 2017 kello 20.47 (EEST)

Hyvältä näyttää. Muokkauksen yhteenvedossa taitaa olla virhe, kun se käyttäjätunnus botilla oli "VakauttajaBot" eikä "VakautusBot". --4shadoww (keskustelu) 6. heinäkuuta 2017 kello 20.59 (EEST)

Tilastossa on näköjään jokin ongelma, kun Karhu artikkelissa tämä muutos olisi listan mukaan hyväksytty eikä kumottu. --4shadoww (keskustelu) 9. heinäkuuta 2017 kello 11.04 (EEST)

Lista on päivittynyt ennen kumousta, mutta on siinä jokin vika. Se aikaisempi, Jarkko Haukijärvi, on vihreä siksi, että käyttäjä itse kumosi sen muokkauksen ja olen perinteisesti suodattanut oman muokkauksen kumoukset pois. --Zache (keskustelu) 9. heinäkuuta 2017 kello 12.31 (EEST)

Päivitin tuon tilastoinnin SQL-koodia joka hakee nuo tiedot ja nyt sen pitäisi toimia paremmin. Kysely nykyisellään on vähän turhan monimutkainen ja se pitäisi pilkkoa osiin jotta ymmärrys pysyisi sen perässä mitä se tekee. Jos siinä tulee vastaan lisää ongelmia, niin kirjoitan sen uusiksi. --Zache (keskustelu) 16. heinäkuuta 2017 kello 21.00 (EEST)

Vakautustilaston perusteella näyttäisi siltä, että graylistat lisäsivät virheellisten positiivisten määrää joten voisi jossain välissä yrittää selvittää tarkemmin mikä niitä aiheuttaa ja saada tuota vakautusta taas tarkemmaksi. Toinen mitä ehkä voitaisiin yrittää tsekata on se, että miten vakautukset menisivät jos käytetään pelkästään ORES:ia vakautusperusteena eli olisiko lopputulos parempi kuin nyt vai huonompi. --Zache (keskustelu) 29. heinäkuuta 2017 kello 12.21 (EEST)

Epäilisin että ORES:in nykyinen tarkkuus ei oikein riitä siihen, että se olisi ainoana vakautus perusteena, kun se näyttäisi tekevän tällä hetkellä suurimman osan virheistä. Nostan kokeiluksi hiukan ORES:in vaadittuja pisteitä ja poistan ip-avaruus harmaalistan käytöstä, kun näyttäisi olevan enemmän haitaksi. --4shadoww (keskustelu) 29. heinäkuuta 2017 kello 13.43 (EEST)