Bona vesprada @Coet! Sembla que la llista fa una setmana que no funciona... T'ho pots mirar, si us plau? Estaria bé que a la pàgina es mostrés l'enllaç al Github on hi ha el codi, per si en futures situacions no te'n pots ocupar. Gràcies!
Viquipèdia Discussió:Llista de viquipedistes per nombre d'edicions
El tinc executant-se en un ordi personal que només l'utilitze per al bot, de tant en tant les actualitzacions del Windows fan que es reinicie i s'ature. Solució: No permetre actualitzacions automàtiques...
De totes forme m'he de reenganxar, per,ò em costa m'és del que pensava, tinc altres mil tasques extres de lleure.
Bon dia @Coet! Hi ha la possibilitat de crear llistes com aquestes de viquipedistes per nombre d'articles creats (del total de viquipedistes) i per antiguitat (aquí només que llisti els actius)? Mercès!
La meua premissa és: No hi ha res impossible, les limitacions són els propis coneixements. Ara bé, també tenim limitacions tècniques, ara per ara una tasca com la primera que demanes seria més viable tenint accés a la base de dates. I no és que no en tinga ja que s'hi pot accedir per toolforge. Tot i que de moment m'estic limitant a fer i refer bots fora d'eixe àmbit.
Tot és plantejar-se-ho, crec que amb l'API també es possible, no obstant això, resulta més costós, és a dir, menys eficient, carregant molt més el servidor. Però bé, crec que puc fer ambdós.
Ja tinc un prototip del primer els resultats serien:
- Walden69 78359
- Jordicollcosta 18928
- Paucabot 12777
- Lohen11 11104
- Xavier Dengra 787
- Coet 371
Moltes gràcies! Diria que aquests, segons el Toolforge, són els articles totals incloses redireccions, pot ser? Potser la columna principal hauria de ser sense redireccions i, depèn de si carrega molt el servidor o no, excloure'n la que inclou redireccions. Crec que són dos llistes que es poden enllaçar amb molt bé amb l'existent.
De fet, en tinc una darrera en ment que trobo important però que potser costa més i és a partir de les dues que et dic: llista d'usuaris per articles creats vs nombre d'aquells articles que tenen una plantilla d'avís (fins i tot articles creats Content Translate vs plantilla d'avís). De manera que pot generar una ràtio de qualitat de viquipedistes els quals podrien no estar fer servint l'eina com toca i deliberadament. Què en penses? Sense cap pressa, però! Són només dades que ens poden ajudar quan sigui que estan disponibles. Salut i gràcies un cop més!
Això que he publicat és l'opció més ràpida, és a dir, la que inclou redireccions, ja que en una sola consulta (recursiva, per a cada usuari) s'obté el nombre de pàgines creades no esborrades. Tota millora posterior requerix més consultes servidor-client i això són dades amunt i avall. Amb el pywikibot, sense accés a la base de dades, per mitjà de l'API suposa una quantitat considerable que dificulta el rendiment. Però es pot mirar des d'un altre punt de vista, si eixes estadístiques estan disponibles en un lloc concret i es fan només una vegada al dia suposa reduir el nombre de consultes que poden fer tots els usuaris. De fet no les faria diàries, potser quinzenals seria suficient.
Ara bé he de trobar la manera més eficient que supose que l'execució de l'script no trigue massa. Només per al nombre d'edicions mitjançant l'API la seua execució triga uns 9 minuts. Això amb la base de dades no suposaria tanta càrrega. He de dir que tot el que proposes per API és totalment factible però consumiria molts recursos a tots els nivells. Per això, quan ja m'implique de nou a executar scripts des del Toolforge ho veig més viable ja que tindria accés directe a la base de dades.
Per exemple, per API, és impossible demanar en una sola consulta la primera revisió d'una pàgina, la de la creació on consta el creador, i la darrera, la que ens donaria el contingut actual de la pàgina per saber si hi ha una plantilla o altra. Això ja suposa dos consultes, per cada pàgina, en cas de Walden69 amb 78.359 creacions suposa 156.718 consultes, les de Jordicollcosta: 37.856 consultes, Paucabot: 25.554 consultes, Lohen11: 22.208 consultes, és a dir, 242.336 consultes només per a 4 usuaris, imagina't per a 5.000, o 1.000 si decidim reduir el nombre d'usuaris per a que no supose tanta càrrega, encara així estaríem parlant d'una execució d'script que duraria potser alguna que altra hora depenent de com s'enfoque.
Però jo pense que es pot buscar alguna manera de fer l'execució més eficient. Se m'acut una macroconsulta d'usuaris (recursiva) cadascú amb una subconsulta per obtenir articles creats (també recursiva) i una altra d'articles independentment de l'usuari (perquè de moment encara estic pensant en fer-lo funcionar per consultes a l'API), així obtenim el nombre de creacions i el nombre d'articles sense plantilla. Però encara així no suposa un avanç important. Potser si algú s'interessa pel tema pot aportar una opció tècnica que per ara no se m'ha acudit.
- Tot és buscar un mode d'obtenir els millors resultats en el menor temps possible.
@Coet gràcies per l'aclariment en llenguatge planer pels menys entesos en els requeriments tècnics!
Aquí pots trobar el nombre de pàgines creades per cada usuari excloent-ne redireccions i pàgines eliminades. Només caldria creuar, si fos possible i sense sobrecarregar el temps d'execució, d'eliminar-ne les que tenen la plantilla de desambiguació per extreure'n el nombre exacte. Això, limitat als 250 viquipedistes actius (excloent-ne els inactius), permetria potser optimitzar el procés.
Aquesta llista, creuada amb el nombre d'articles creats via Traductor ens pot donar llistes amb equacions de la qualitat de creació:
Articles traduïts del Content Translate/Articles totals creats = ràtio de 0 a 1 (articles inèdits)
Si un viquipedista té una ràtio de 0,25 (1 de 4 articles són traduïts, xifra rellevant), posar-lo en una categoria de "Viquipedistes traductors"
Articles traduïts amb avisos/Articles traduïts del Content Translate = ràdio de 0 a 1 (qualitat de les traduccions d'aquest viquipedista)
Si un viquipedista té una ràtio superior a 0,1 vol dir que més del 10% dels que fa acaben mal fets, per tant és quelcom a vigilar. I si té una ràtio del 0,3, ressaltar-ho en vermell a la llista com un viquipedista susceptible al qual se li prohibeixi o limiti temporalment l'eina.
Són idees, però al cap i a la fi simples llistes que ens poden ajudar moltíssim a autoavaluar-nos la nostra qualitat de la feina i també de cara als administradors a prendre decisions fonamentades en cas de mal ús de l'eina. Ja diràs què en penses. També @Paucabot i @Pere prlpz, que en aquests temes sou bons coneixedors de l'assumpte i segur que podeu aportar més coses.
Si jo volgués treure el nombre d'articles per usuari amb diferents plantilles, el que faria és:
- Baixar-me la llista d'articles creats per cada usuari. Això crec que hi ha més d'una manera de fer-ho.
- Buscar els articles que tinguin cada una de les plantilles que ens interessi o que estiguin en les categories que ens interessi. Això també hi deu haver més d'una manera de fer-ho, inclòs el PetScan.
- Creuar les dues dades i ja tenim quants articles amb FR, FVA, MT, etc. hi ha entre els creats per cada usuari.
Hi afegeixo que una altra manera d'accedir a la base de dades és baixar-se un dump. No sé gaire com es fa servir però sé que fa anys ho vaig fer amb Wikidata i me'n vaig sortir.
Un problema de tot plegat és que els articles creats per cadascú poden ser una cosa poc significativa. Jo creo pocs articles, però segons les estadístiques n'he creat centenars perquè me'n compten molts que quan els vaig crear eren redireccions o desambiguacions i després algú altre ha convertit en article. Si molts d'aquests articles meus són de qualitat o són traduccions a millorar, això té poc a veure amb que siguin meus. Espero que per als editors que sí que creen molts articles aquests falsos positius tinguin relativament menys pes.
I el que ja no sé és si el temps esmerçat en tot plegat no tindria aplicacions més profitoses. Tot i que som voluntaris i cadascú pot dedicar el seu temps al que li vingui de gust, ara mateix em sembla molt més urgent aconseguir que el bot arxivador torni a funcionar regularment, per alleugerir algunes pàgines quilomètriques que tenim.
@Pere prlpz, en resposta al darrer paragraf, sobre ArxivaBot, m'ho varen suggerir ahir i m'he posat en marxa. Supose que per a finals de setmana el tindré de nou actiu.
Bé, ara intentaré contestar la resta de temes...
@Xavier Dengra, no acabava d'entendre del tot la teua primera intervenció, ara ja em queda més clar i sembla interessant. Analitzant la situació amb el que comenta en @Pere prlpz, veig que es pot no considerar creadors aquells que creen un article com a redirecció. Conec ben bé el dump, però no me fa massa gràcia descarregar-me al meu ordinador personal la base de dades i fer-li unes consultes que el deixaran plegat i malferit en unes quantes execucions. Les consultes SQL les deixarem per al Toolforge quan es puga. He vist que el PetScan pot tornar dades en format json, això és una bona aportació. I les equacions seran molt valuoses. Si estes estadístiques van més enllà del simple fet d'acumular dades i establir el pòdium del mèrit al millor creador d'articles i ens pot revelar l'ús que fan els usuaris d'una eina, llavors l'utilitat n'esdevé la causa i el motiu. Crec que puc implicar-me gaire, així que tota aportació i tots els detalls seran benvinguts.
Avisa'm a mesura que vagis tenint cosetes al teu ritme i ens anem mirant quines dades valen la pena i com les exposem per tal que no es vegin com (bé dius) un podi, sinó en matèria d'autoexigència o decisions consensuades sobre regulació o consells de l'eina.
@Xavier Dengra:, crec que he trobat una manera prou més ràpida per a realitzar esta bugada :) Aniré fent algunes proves i haurem de puntualitzar els detalls. Si vols aportar algun esquema del que s'ha parlat fins ara, em seria molt útil i faria que es mantinguera este projecte abans que algun altre m'absorbisca. :P
És a dir, en un principi s'ha dit, i afegisc atenció per a @Pere prlpz @Paucabot:
- Que es considera que un usuari ha creat un article:
- Quan al moment de crear-lo no ha estat per a fer una redirecció
- Que l'article és computable si no té les següents plantilles:
- (enumereu-les)
- Que l'article és computable si té les següents plantilles:
- (enumereu-les, si s'escau, això no s'ha parlat)
- Que per al còmput d'articles creats s'ha de tenir en compte:
- Articles traduïts del Content Translate/Articles totals creats = ràtio de 0 a 1 (articles inèdits).
- Articles traduïts amb avisos/Articles traduïts del Content Translate = ràdio de 0 a 1 (qualitat de les traduccions d'aquest viquipedista)
Ara diria que tots són computables (excepte la creació de redireccions, que s'hauria de computar per aquell que convertix l'article amb contingut i aleshores mirar si el contingut actual és rellevant)
Bé ja em diueu quelcom ;)
Les plantilles no computables en un article deficient que provingui del ContentTranslate haurien de ser les mateixes que les computables, com a mínim 1 de les següents: {{falten referències}}, {{FVA}}, {{millorar traducció}}, {{millorar bibliografia}}, {{no s'entén}}, {{imprecís}}, {{millorar ortografia}}, {{expert}}, {{segona llegida}}, {{millorar introducció}}, {{prosa}}, {{millorar}}, {{millores múltiples}}, {{condensar}}, {{biaix de gènere}}, {{fonts primàries}}, {{error de gènere}}, {{currículum}}, {{massa vegeu també}}, {{millorar format}}, {{millorar estructura}}, {{duplicat}}, {{Moure}}, {{Moure a Viccionari}}, {{Moure a Viquidites}}, {{Moure a Viquillibres}}, {{Moure a Viquinotícies}}, {{Moure a Viquitexts}}, {{Moure a Wikidata}} i {{Recerca original}}.
Com a cortesia, però sense oblidar-les, afegiria que tingui com a mínim 2 vegades la mateixa plantilla {{cal citació}}, {{Font qüestionable}}, {{imprecís}}, {{Verifica la citació}}, {{Format ref}} o {{tinv}}. O que sumi 3 cops qualsevol d'aquestes alhora.
@Coet seria fantàstic perquè en el futur podríem arribar a distingir els usuaris que pitjor rànquing de traduccions tenen i segregar-ho per fer-los veure i pedagogia segons si són dels qui no posen referències, nivell de llenguatge, errors continus de formatació dels articles o què. I personalitzar una mica a l'hora d'encoratjar a millorar o, fins i tot, si fos convenient restringir l'eina.
Gràcies per anar mirant-ho.
Llista de viquipedistes per nombre d'articles creats: https://ca.wikiscan.org/?usort=new_main&bot=0&detail=0&menu=userstats
També es podria aprofitar aquesta llista per fer-ne de pròpies sobre articles llargs, curts, AdQ o amb mancances respecte al total creat per cada usuari. Al final la idea és poder autovalorar la qualitat vs quantitat de cadascú.
Ja tinc el bot completat a nivell de recopilació de dades (queda pendent la fase de mostrar-les). Els resultats que s'obtenen divergeixen prou dels que mostra l'xtools del ToolForge. Entre altres coses és degut a que esta eina només té en compte el contingut actual de l'article, de manera que s'estalvia una consulta sobre el contingut de l'article al moment de crear-lo. Com que es pretén descartar les creacions que es fan com a redireccions, nosaltres no les comptarem com a article creat, mentre que l'xtools el computa només si actualment és una redirecció, no si es va crear com a redirecció.
He volgut considerar que si l'usuari crea una pàgina de desambiguació tampoc s'ha de computar. No sé si estic enganyat, però ja que mirem la intencionalitat a l'hora de crear una pàgina a l'espai principal, si no hem de computar una pàgina per ser una redirecció se'm feia estrany considerar una plana de desambiguació com a article. Però és fàcil teure-ho si creieu que no cal filar tant prim.
També es pot diferenciar entre articles creats de zero, sense l'eina del Content Translate i aquells que l'han emprat, esta característica és essencial per a les fòrmules. Les enumere de nou:
- Articles traduïts del Content Translate/Articles totals creats = ràtio de 0 a 1 (articles inèdits).
- Articles traduïts amb avisos/Articles traduïts del Content Translate = ràtio de 0 a 1 (qualitat de les traduccions d'aquest viquipedista)
Entenc que si el propòsit és obtenir l'ús que es fa de l'eina la segona equació hauria de ser més bé:
- Articles traduïts del Content Translate amb avisos/Articles traduïts del Content Translate totals
És a dir, el ràtio seria relatiu a l'eina, d'altra manera es desviaria amb dades que no són propies de l'ús d'esta eina, tot i que no sé si eixa és la intenció.
Per reduir una mica el nombre de consultes a fer, agafe els usuaris actius dels darrers 90 dies, si un usuari no és actiu, la recopilació de les seues dades no seria necessària, crec jo.
No sé si els usuaris no actius serien interessants, però si els vols incloure sense gaire feina de bot pots guardar les dades i cada cop que actualitzis actualitzar només els actius des del darrer cop. Les dades dels inactius es poden recuperar de l'actualització anterior.
Sembla bona idea, potser també perquè mostrar els inactius permet saber si tenim cap usuari amb unes contribucions de traducció preocupants i de les quals n'hauríem de fer seguiment.
Em sembla molt correcte! Efectivament la segona equació que dius té més sentit, però ambdues columnes (cadascuna amb la ràtio de cada equació) hi hi haurien de ser. De manera que es puga filtrar els usuaris més prolífics amb l'eina, i quins d'aquests acumulen millor i pitjor ràtio.
En primera la primera columna (1a equació, ràtio de traductor), marcaria en rosa o lila aquells que tinguin una ràtio superior a 0,5 (és a dir, 50% d'articles són del Content Translate). No sé si el resultat serà sorprenent o no i si tindrem una part majoritària de la comunitat que tradueix o no, a partir d'allà podrem corregir els colors.
I en la segona columna (2a equació, qualitat de la traducció), marcaria les caselles en groc i en carbassa seguint el comentari de fa unes setmanes: Si un viquipedista té una ràtio superior a 0,1 vol dir que més del 10% dels que fa acaben mal fets, per tant és quelcom a vigilar. I si té una ràtio del 0,3, ressaltar-ho en vermell a la llista com un viquipedista susceptible al qual se li prohibeixi o limiti temporalment l'eina. Si algú té una ràtio de 0,5, es pot marcar en roig.
Com ho veus? Boníssima feina i moltes gràcies per considerar-ho una bona proposta i oferir-te a programar-la!!
Entesos, farem una primera passada amb tots els usuaris, sense resctriccions. Després ja podríem limitar-nos als usuaris actius.
Per cert se m'ha passat un detall, la consulta inicial i el títol de l'assumpte del fil: llista per antiguitat. A la pròpia llista es pot afegir una columna que ens indique la data i hora de la primera edició de l'usuari de manera que es puga ordenar. Dic la data de la primera edició ja que els usuaris més veterans no compten amb una data de registre. Com a molt l'altra solució és afegir també una columna amb l'ID de l'usuari, que una vegada més en cas d'usuaris veterans, crec que no tenien realment una ID, crec recordar que esta ID ve del moment en que es va implementar el concepte d'usuari global.
Ara bé, no hi ha cap problema per crear una nova llista que per defecte ordene per antiguitat. De fet podrien aparéixer quatre columnes al respecte: posició, ID usuari, data registre, data primera edició. A part, les habituals de nom d'usuari, edicions, data darrera edició i increment respecte a la darrera actualització.
Desafortunadament, l'script no acaba de funcionar. He utilitzat multiprocessos per anar fent més d'una consulta a l'hora i aplega un moment que els processos acaben saturats i el fil principal no pot continuar. Això m'obliga a canviar d'estratègia per intentar solucionar-ho. Les primeres proves estaven fetes amb pocs usuaris i pareixia que funcionaria, però quan he volgut provar només amb els usuaris actius (amb un mínim de 1000 edicions, que eren 691 usuaris) el codi no ha pogut gestionar tanta dada.
No hi ha res impossible i es tracta de canviar la forma tractar les dades. Sols he de millorar la forma en que s'agafen i s'alliberen estes dades, he de dir que per a un altre script he gastat el mateix sistema que ara i ho ha resolt en 1 dia i 17 hores (més exactament és el de wanted_pages.py que agafa els enllaços vermells de cada article i ha pogut analitzar els 700K articles i més de 2M d'enllaços vermells), quan la normal és que puguera trigar fins a 5 dies, si més no. En este cas esperava que ho puguera resoldre en una nit (8h), però diria que l'asimetria de les dades (uns usuaris amb més de 1000 articles creats i altres amb menys de 100) causa este embús de moment irresoluble.
Es tracta de cercar un nou enfocament, potser un canvi de paradigma, un llenguatge com Rust, dissenyat per a la concurrència... Ja vorem.
Gràcies un cop més pels esforços, @Coet! Un dia i mig sembla raonable per eixes llistes que només cal mostrar quinzenalment o mensual. És una gran celebració la teva tornada al projecte per donar un copet de mà en eines així que són molt útils.
Abans de fer qualsevol canvi dràstic, se m'ha ocorregut llegir una mica més sobre concurrència en Python i modificar el codi, hi ha molts factors a tenir en compte, entre altres els intercanvis d'informació entre usuari - servidor. He reduït també el nombre de fils que pot executar a l'hora, de moment no pinta malament, però el resultat com a molt prompte, si tot va bé, podrà estar sobre les 22 o 23... Potser més ja que he reduït els fils i els càlculs no són els mateixos. Feliç dimarts!
Ja està clar, el bot carregava per a cada usuari els milers d'articles i cada article les desenes o centenars de plantilles, això al final feia que els fils no pogueren suportar tota la informació. He reduït la llista dels articles de cada usuari a nombres i ara sí que ja corre a la velocitat del so en atmosfera terrestre. Supose que demà es podria tindre els primers resultats almenys que confirmen que tot ha anat bé.
La publicació de les primeres dades seria per al dijous. Aniria bé crear una pàgina per a l'efecte. Havia pensat en Viquipèdia:Llista d'usuaris per creació d'articles, a mes potser caldria unes planes o una amb diferents seccions de configuració on deixar aquelles plantilles que s'han de tindre en compte per a que siga més fàcil actualitzar-les.
Proposo Viquipèdia:Llista de viquipedistes per nombre d'articles creats i Viquipèdia:Llista de viquipedistes per ús de l'eina de traducció i Viquipèdia:Llista de viquipedistes per antiguitat, per mantenir la coherència de noms.
Quan en tinguem algunes, ja crearé una pàgina que les agrupi totes.
No ha pogut ser, hi ha alguna cosa que impedix que els multiprocessos aguanten més d'una hora. Provaré una altra estratègia.
requests.exceptions.SSLError: HTTPSConnectionPool(host='ca.wikipedia.org', port=443): Max retries exceeded with url: /w/api.php (Caused by SSLError(OSError(12, 'Not enough space')))
Li pose 20 fils, i s'atura quan en té 29, no té molt de sentit. Python no és el rei de la concurrència.
Ànims! Creuem dits perquè funcioni!
Al final serà tot cosa de concurrència asincrònica (que un procés no comence fins que no acabe un altre, que els processos que vull que facen la tasca es vagen rellevant) quan m'hi puga ficar, en dos hores pot estar preparat l'script definitiu.
He canviat a concurrència asincrónica i els resultats no varien. He de buscar una alternativa. Són les consultes successives que embussen el búfer de les dades que apleguen del servidor. LA millor seria fer consultes SQL dins del servidor, però de moment preferisc seguir des de fora.
Com que no estic disposat a claudicar, i part del problema és cosa del pywikibot que no gestiona bé el buffer del socket, se m'occorre alliberar el socket cada 50 usuaris, no he vist/llegit res més aprop d'este problema i no l'havia tractat mai. Si algun més avesat gosa tirar-me una maneta i veu alguna solució més eficient, endavant!
ping @Townie, @Forat Negre, @Wecoc, @Amadalvarez, @KRLS, @Joutbis per si se us acut alguna manera d'ajudar el Coet.
Jo també ho faria així, més o menys. Com que només estàs retornant un valor (nombre d'articles creats) per cada usuari, es pot emmagatzemar asincrònicament en un diccionari esquivant el límit del buffer, i finalment ordenar el diccionari segons aquest valor. Si el buffer no dóna l'abast, s'augmenta el temps entre lectures successives. Diria que és el mètode que dius.
Ara bé, com que estàs esperant el buffer entre lectures i és el que et genera la pèrdua principal d'eficiència, es pot aprofitar aquest temps "perdut" per fer un filtratge del diccionari actual agilitzant així el darrer pas. Si saps que només t'interessa obtenir els millors 500 usuaris i el diccionari en conté més, pots filtrar els que tenen valor més baix mentre estàs esperant el següent call al buffer, truncant així la mida del diccionari a cada pas i fent el procés més eficient.
La qüestió és que no volem descartar ningú en un primer moment, no es tractaria d'una llista de 500 traductors, sinó una llista que servisca de referent amb totes les dades disponibles.
No tenia clar si fer alguna pausa abans de carregar de nou més dades serviria, vaig a intentar calcular les dades que hi ha a cada fil i les alliberades per saber el temps que ha d'esperar aquell que ha acabat amb les seues.
Gràcies, @Forat Negre.
Si ve algú més el codi actual és a creators.py, tot comentari i crítica serà d'agrair.
Vaig a provar de desvincular-me del pywikibot i saber en cada cas com circulen totes les dades. De moment no hi ha una altra estratègia...
Ja tinc el nou codi en proves, encara no ha estat sotmés a l'stress dels multiprocessos, però en cap moment té problemes amb el servidor, cosa que ja passava amb l'script utilitzant pywikibot. De moment he de comprovar que no tindrà cap error en carregar algun article, després ja el podré sotmetre a l'stress xD
Bé, sembla que tenia raó, sense pywikibot, això va com el llamp: a 1,68 usuari per minut. Supose que en 5 hores més podrien estar els primers resultats, els que des d'un principi havia volgut obtindre, els dels 691 usuaris actius (amb una activitat recent en els darrers 90 dies, de ja fa dos setmanes, crec). Ara bé no veig clar que els usuaris antics apareguen, els anterior a la introducció del Content Translate, vull dir. Ara bé, antigament es feia servir altres mitjants de traduccions i se solia insertar al comentari i em sona que hi havia una plantilla a l'estil de {{traduït de}}. No ho veig clar, no inclore'ls els situa en una ràtio de 0,00 i incloure'ls desvirtuaria els resultats ja que no han emprat realment l'eina del Contaent Translate.
Per a una llista dels usuaris totals: són 100.468, crec que la cosa no trigarà molt més de 9 o 10 hores com a màxim ja que la majoria no tenen més de 10 edicions i potser fins i tot cap creació d'article. Ho dic sense fer càlculs, però com que ja de per si va baixant l'índex dels 691 supose que es pot situar sobre 1,4 usuaris per minut i en el cas dels 100.000 diria que serà el doble 2,89 com a molt.
Boníssima feina! Vejam a veure els primers resultats. Les plantilles que esmentes van bé com a cortesia per i traçabilitat de la llicència i l'origen de l'article, però per detectar les edicions que són via traductor de contingut cal anar a Especial:Etiquetes i comptar les que són "ContentTranslation2", "traducció de contingut" i "SectionTranslation". Això permet acotar molt i molt bé les xifres exactes.
Ups, només agafa les etiquetes de "ContentTranslation2", bé més exactament les que li he posat són: CONTENT_TRANSLATION_TAGS = ("contenttranslation", "contenttranslation-v2") que són les que torna l'API, ara mire les que corresponen a "traducció de contingut" i "SectionTranslation" en l'API, si és que m'aclarisc...
Segons això, que supose correspon a això altre, diria que només m'ha faltat afegir "sectiontranslation", però si entenc bé està no s'origna en crear un article, només en modificar-lo, i ara mateix estem mirant només creacions d'articles.
Tens raó, millor deixar fora sectiontranslation però estar a l'aguait per si influeix (tot i que crec que via el traductor deu ser residual).
He vist que ha saltat 4 vegades.
He publicat les dades a resultats, passar-les a taula no serà cap problema, però encara no m'hi he posat.
Hosti fot molt bona pinta. Veig que les ràtios pinten prou bé. Un cop tinguem els resultats nets podrem veure com polir el recompte o quines altres mètriques poden valer la pena. Mil gràcies, com mola això!
He creat:
- Viquipèdia:Llista de viquipedistes per nombre d'articles creats
- Viquipèdia:Llista de viquipedistes per nombre d'articles creats/capçalera
- Viquipèdia:Llista de viquipedistes per nombre d'articles creats/peu
- Viquipèdia:Llista de viquipedistes per ús de l'eina de traducció
- Viquipèdia:Llista de viquipedistes per ús de l'eina de traducció/capçalera
- Viquipèdia:Llista de viquipedistes per ús de l'eina de traducció/peu
El text és un esborrany, canvieu-lo com més convinga i s'entenga.
A Viquipèdia:Llista de viquipedistes per nombre d'articles creats si no tenen articles creats, no surten
A Viquipèdia:Llista de viquipedistes per ús de l'eina de traducció si no tenen articles creats amb CT, no surten. No sabia molt bé com ordenar-los.
Les dades definitives estaran segurament pel matí. Al final sembla que trigarà 10 a 11 hores (691/1.07) ja que seguix baixant la tasa d'usuaris per minut.
Moltes gràcies! Me les miro amb més calma, però la d'articles creats és errònia segur. Hi falten usuaris prolífics i històrics com en Walden69, Jordicollcosta, Kippelboy, MarisaLR.. de fet jo en tinc més de 200 i no m'hi he trobat, hehe.
És que encara no ha acabat, justet Walden o tu, sereu del últims, va per ordre alfabètic, igual que Kippelboy o MarisaLR. Pensa a més que els prolífics triguen hores en eixir, un dels primers, Claudefà, en entrar ha trigat 5h, té 10.020 articles creats.
Demà provo de fer una pàgina d'explicació més precisa per la de l'eina de traducció, amb una mena de semàfor i anar polint detallets menors. La ràtio, ara que hi penso, millor en percentatge potser perquè la gent s'aclarisca millor. Com ho veus?
Encara no ha acabat, com dic al resum dels resultats, en té 677 de 692. Podria ser que algun fil s'haja quedat penjat. Ja du des de les 8:19 (són les 9:28) sense alliberar cap dada més, en total a les 8:19:32 duia 15h 33m 46s en marxa. Crec que és hora que l'ature i que comence de nou sense aturar-se amb els que ja ha fet, però m'ho estic repensant. He estat arreglant alguna cosa del codi, i van aparéixer alguns errors (tres: per enumerar plantilles, perquè no té comentari, perquè és revisió única, i una més aliena al codi: perquè el servidor no respon) que solen aturar el fil.
Diguem que he programat 20 fils per als 692 usuaris. Gràficament seria com en un hipermercat amb una fila única i 20 caixes, conforme acaba una caixa s'advertix que la caixa X ha quedat lliure i s'hi presenta un nou usuari.
L'script va agafant els usuaris per ordre alfabètic, va mirant les contribucions de cada usuari, una a una, filtrades amb el flag de new per a només processar articles de nova ccreació, si l'article té més d'una revisió, agafa la primera i la darrera. Amb la primera sabem quin tipus de plana ha creat l'usuari: article en sí, redirecció o desambiguació. Si es tracta d'un article el programa obté les plantilles de la darrera i determina si és un article traduït pel CT (això apareix a l'etiqueta) i aleshores avalua si l'article té alguna plantilla de manteniment de la forma que es va establir més amunt. Quan ja tenim l'usuari analitzat este passa a la llista d'usuari enllestits que és la que he anat publicant als resultats i de la que es nodreixen les dues pàgines de les taules.
He tingut tres errors al codi, que han saltat en 9 ocasions (i també ha ocorregut un error de servidor timeout), ja estan corregits però no s'executaran correctament fins un nou reinici. La qual cosa vol dir que de 20 fils, 10 s'han quedat inutilitzats, per tant va a mig gas i això explica que la tasa haja disminuit a 0,7 usuaris per minut i supere les 7 hores previstes. Mentre he estat redactant este text s'ha alliberat un nou usuari, per la qual vol dir que seguix actiu. Tot això ho dic perquè hui esperaré que acabe fins les 16:00, després he d'aturar-lo si no haguera acabat. Quan el torne a engegar sempre tindrà les dades d'enllestits i la llista de pendents que seran pocs.
De nou du una hora sense alliberar cap usuari més. Vaig a aturar-lo. Supose que pot tindre usuaris prolífics en la majoria de fils, però provaré d'engegar-lo de nou per a acurtar el temps per als 20 usuaris que li queden.
LOADED usrs: 691 check_users: 679 FILTERED users: 12 [11:11:02] >>>> Bestiasonica [11:11:02] >>>> AntoniBM [11:11:02] >>>> Jolle [11:11:02] >>>> Leptictidium [11:11:02] >>>> Griba2010 [11:11:02] >>>> Mcapdevila [11:11:02] >>>> Manlleus [11:11:02] >>>> Pinshiulo [11:11:02] >>>> Pallares [11:11:02] >>>> Panellet [11:11:02] >>>> Vallue [11:11:02] >>>> Walden69
Evidentment en bona part, queden els més prolífics, potser no era una idea tan bona... Tot i que no sé si algun estava en un fil aturat.
Ja n'ha alliberat quatre: Griba2010, Vallue, AntoniBM, Pinshiulo. Així que ara queden els prolífics supose...
- Bestiasonica
- Jolle
- Leptictidium
- Mcapdevila
- Manlleus
- Pallares
- Panellet
- Walden69
Per la lletra diria que s'ho emportarà en Bestasonica, serà l'últim en surtir.
Aix queden cinquanta minuts abans que ature el bot. Després no el posaré en marxa fins el dijous... Encara en queden 4...
- Jolle
- Leptictidium
- Panellet
- Walden69
Té pinta que no sortiran tots perquè en Walden69 és el que més. Per què l'aturaràs en 50 min i no el faràs servir fins dijous? Des del desconeixement absolut, hehe.
Estic en el tren cap a Barcelona
Bé, ahir no vaig engegar el bot, l'acabe de fer ara. Es quedarà tot el dia, supose que amb quatre hores com a molt hauria de ser suficient, tot i que el Walden69 a ell sol deuria aprofitar algun fil més per retallar el temps d'execució. Estem encara en proves la qual cosa vol dir que no són dades definitives. Quan es comprove que de veres pot funcionar d'un sol cop, ja es podrà considerar com a dades reals.
Potser que una vegada tenim dades de tots els usuari podem canviar eixe ordre alfabètic per un ordre que tinga en compte el nombre d'articles creats de forma descendent (de més creacions a menys), i que isquen primer els usuaris més prolífics. I de fet, hauria de programar-lo de manera que un usuari prolífic puga fer-se amb més d'un fil de manera que en lloc de revisar-les en un sol, posem-ne 20000 creacions d'articles, es determine de fer-ho partit en 4 fils, de manera que cada fil reba 5000 articles creats i s'adjunte al final de cada resultat a un sol usuari. Així amb el temps que triga per un usuari amb només 5000 creacions, s'obté un usuari amb 20000 i is s'alliberen pràcticament 4 fils a l'hora per deixar pas a un altre o altres. Bé, és només un pensament que al deixar per escrit em vaig fent els meus esquemes mentals per a poder dur-lo a terme, no sembla una mala idea...
Et vaig llegint amb molt d'interès, no cregues que els missatges són debades. De moment, jo vaig també escrivint i pensant com aplicar els resultats i com mostrar-los perquè siguen més entenedors i se'n puguin extreure més conclusions.
Sí, clar que vaig deixant missatges pensant que algú els llig xD
Bé du des de les 12:01:01 actiu i encara segueix amb els 4 prolífics... No se n'ha eixit cap, això vols dir que cal fragmentar les seues edicions per a que els fils acaben abans. De moment a vore quan acaba que no sé ni el nombre de creacions que tenen segons els criteris que hem triat, que no són els que agafa l'eina de l'xtools del Toolforge. Només en que s'agafen quatre fils per cadascun d'estos quatre usuaris estariem paralnt de reduir el temps molt significativament i només emprant 16 fils, deixant-ne 4 per a usuaris amb poques creacions que són molts més.
Per cert, cap problema en mostrar percentatges en lloc de ràtios (es tracta de multiplicar per cent ;) ).
Pel que he vist en Lepti està a punt d'acabar. Després li deuria de tocar el torn a Panellet, Jolle i Walden, amb un sistema d'un fil per usuari igual són 12 hores, si més no, per al Walden. Estic preparant el codi per a partir un usuari entre diversos fils quan les seues creacions superen 5000 registres. I també que serien 45 usuaris dels 691 els que s'haurien de partir per reduir el temps d'execució de l'script.
Acabe d'actualitzar els resultats, he aconseguit que es complete Walden69 en només 2 h 8 m 6 s. Quan l'anterior (Jolle) amb un sol fil, i 14959 creacions menys, li va costar 15 h 4 m 25 s. He de fer algun reajustament més però la cosa ja sembla que s'acosta a un resultat òptim.
He transformat aquests resultats a un .csv per si voleu fer-hi coses amb un full de càlcul: https://www.dropbox.com/s/c9pk7bfa74ejnh5/Articles.csv?dl=0
El top ten:
- Walden69 62438
- Jolle 39642
- Pcm 15955
- Asfarer 14824
- Victor M. Vicente Selvas 12742
- Felato 10634
- Mcapdevila 10328
- Nelo 10298
- Leptictidium 10104
- Claudefà 10020
Per cert, que hi troba faltar Panellet, que segons això, va crear 36000 articles ...
Sí Pau, estem en proves i el Panellet el tenia en pausa. Tenia interés en mostrar com canvia d'utilitzar un sol fil per a un usuari a utilitzar-ne diversos. Estic encara arreglant els canvis necessaris per a poder obtenir els resultats en el menor temps possible. Però, la cosa va molt bé.
En el cas de Panellet que l'eina que proporciones li concedix 36.710 articles, segons els criteris que hem tingut en compte nosaltres en serien 35.857. Afegisc el seu recompte als resultats.
S'està executant una versió que primer mira el nombre de creacions en cruc que té un usuari, per saber quantes peticions s'ha de fer sobre eixe usuari i ordenar per nombre de consultes que s'ha de realitzar per a un mateix usuari (en lloc d'utilitzar l'ordre alfabètic preliminar). Ho faig sobre els famosos 691 actius.
A vore si ja està finalment enllestit tot el codi! Esta serà la prova que ens servirà per saber quant pot trigar en obtenir els resultats de 691 usuaris, xifra aproximada del nombre d'usuaris actius. Quan tot estiga en ordre es podrà executar ja la dels usuaris totals.
A la nit, si tot ha anat bé tindria els resultats. De fet esta vegada sí que espere que es resolguen en 9 hores màxim.
Ha trigat quinze hores i això que he eliminat aquells que no contaven amb una sola creació, la majoria eren bots sense marca, havien passat de 691 a 649. El nombre de consultes realitzades ha estat de 3.221.995. Per acurtar més se m'ocorre engegar dos a l'hora, un per als prolífics i un per als moderats aquells que no arriben a les 5000 creacions. Crec que és important que no supere les set hores.
Bé, la part dels moderats triga quatre hores i mitja. I la dels prolífics en són 10h 30m. Crec que vaig a engegar ja el bot per a tots els usuaris, no tinc ni idea del que pot arribar a trigar. Però a partir d'ara tinc un dispositiu fixe connectat 24h. Quan acabe, publicaré les dades i inclouran els colors, per reduir la tasca done com a vàlid les dades del 691 usuaris actius que m'han servit per a les proves.
Ahir a les 17:40, vaig engegar el primer procés per a tots i totes els i les usuaris i usuàries de cawiki. Va en ordre alfabètic i està fent la P, es quedarà amb usuàries/aris que tinguen almenys una creació del tipus que siga (article, redirecció o desambiguació). Estem parlant d'una llista en el seu moment de 100700 ± 80 usuaris/àries. Estic veient que la majoria no entrarà al segon procés, el d'extreure les dades per a les taules. No sé exactament de quants estem parlant ja que no sé de cap estadística que ens done el percentatge entre usuaris que només editen i aquells que creen articles.
Aplicant una regla de tres de les dades que teníem fins ara estaríem parlant que de 691 només s'han escorcollat 651 (94%) i d'estos 45 eren prolífics (7%), a més que a la taula de traductors només entren 267 (41%), tot i que el biaix serà més gran. En qualsevol cas per a obtenir les dades el més aviat possible hauré una vegada més de partir en diversos processos, però això també suposa fer massa sol·licituds a l'hora, igual estem parlant de fer 250 consultes per segon al mateix servidor i pel mateix usuari, cosa que no sé si ho suportarà. He de mirar si d'alguna manera es podria fer consultes a diferents servidors per diferents usuaris. I l'altra possibilitat es deixar que només hi haja dos processos amb 20 fils cadascun, però aleshores estaríem parlant d'una execució de, potser, dies per a algun dels dos processos.
S'ha de tindre en compte que això només es farà una vegada ja que estem parlant de recopilar dades d'usuaris inactius però que en algun moment van crear algun article. Així que potser l'únic que cal és una mica de paciència.
Ja està engegada la segona part, de 1.000.700 usuaris, n'ha de comprovar 100.020. No hi ha usuaris prolifics, potser tot quede en 15 hores... Espere...
El procés dels 22000 usuaris, al final sobre 1.000.780 només eren 22.000 amb almenys una creació d'article es va executar en només 3 hores. El que passa es que ara comptem amb 22.000 registres, una mica difícil de gestionar i mostrar en una sola taula. No sé com ho veieu, com ho hauríem de presentar, es poden fer diverses pàgines de 1000 usuaris, tot i que no en veig la utilitat real, crec que si es tracta d'usuaris inactius deuríem fer alguna cosa més resumida, la majoria han creat només un article, diria que són alumnes que ho han fet per a alguna assignatura, algun taller o alguna cosa semblant. A més que no han utilitzat el Content Translate ja que majoritàriament són comptes antics.
Publicar totes les dades em sembla excessiu. No sé quina solució donar-li.
M'hi pose este cap de setmana. Volia rebre alguna opinió més aprop de com visualitzar els 22.000 usuaris amb una sola creació, crec que resumir-lo és el millor per no haver de fer tanta pàgina.
Cap novetat, @Coet? T'ho has pogut mirar? Salut!
Seguisc endavant... La cosa es va aturar en el moment que vaig preguntar què havíem de fer amb els 22.000 usuaris amb una sola creació...
Evidentment establiria un llindar, que poden ser 100 contribucions (sovint de referència per a poder votar) o, si encara dona problemes, 500.
Bé, encara estic amb l'arxivador dels AdQ. Però este cap de setmana miraré d'obtenir resultat per als usuaris amb 100/500 contribucions, estem parlant de contribucions, no de creacions.
Iep @Coet, com anem? Els hi vas poder pegar una ullada als temes?
Des del 22 d'octubre que no actualitza
Certament... @Coet? Gràcies!
Ep, li miro de donar un cop d'ull. Caldrà actualitzar el codi possiblement.
Gràcies @Toniher!
Ep! Ho tinc present, però malauradament no ho he pogut enllestir. Us n'informo aquí quan comencin a córrer proves...
Ben aviat torne, espere aplegar a temps. A poc a poc aniré arreglant coses. Dirigiu-vos a la meua pàgina de discussió si trigue en actuar sobre este tema.
Merci @Coet! No crec que m'ho pugui mirar d'ací a poc. Si hi ha res que et pugui donar un cop de mà, em dius...
Des del 22 de març el bot no actualitza la llista, què passa?
@Coet
Vaig, paciència... :)
Des del dia 1 de Gener no funciona, està aturat?
Notifico @Coet @Gerardduenas.
Jo ara mateix no puc arreglar-ho. Potser algú d'ells pot... @Alchimista, Anskar, Arnaugir, Castor, Joancreus:@KRLS, Lluis tgn, Nknudsen, Toniher, Unapersona:
Però hi ha el codi en algun lloc?
Miro si el tenim al mateix lloc des d'on corro altres coses de Especial:Contribucions/CobainBot i miro d'executar-lo...
Arreglat https://phabricator.wikimedia.org/R2136:495c7689b0b7 Ha estat amb el canvi de decada. Els que teniu accés al repo, podreu veure-ho...
Des del 25 de març que no s'actualitza.... algun motiu?
Relacionat: Tema:Uvlr4ckohofwwwkf. Sembla que el bot està aturat.
M'he preguntat moltes vegades com es compten les edicions. Suposo que si edito un article traient una "s" de "pallissa" i ho guardo, compta com una edició. Si m'adono de l'error, torno a editar afegint la "s" a "pallisa" i guardo, compta com una altra edició. Total 2 edicions. Si és així, comprenc la poca utilització de les pàgines de proves.
Les edicions a pàgines de proves també computen per la llista.
Aquesta pàgina ha deixat d'actualitzar-se. Algú s'ho pot mirar? Hi diu: Darrera actualització: 00:03, 18 juny 2015 (CEST)
Ja ha estat comentat a Usuari Discussió:CobainBot.
Cap més tema anterior