Wikipedia:Officina/Archivio/2019 maggio

Nuovi codici per lingue cinesi?

Adesso invece di "zh-CN", "zh-HK" e "zh-TW" abbiamo "zh-Hans-CN‏‎", "zh-Hant-HK" e "zh-Hant-TW‏‎"? Cfr. Speciale:CategorieRichieste. Dove si può controllare un eventuale aggiornamento per verificare qual è la dicitura corretta? --Superchilum^(scrivimi) 10:27, 29 apr 2019 (CEST)

User:Barbaking ci puoi dare una mano? O sai a chi rivolgersi?--Pierpao.lo (listening) 10:52, 29 apr 2019 (CEST)

User:Barbaking ripingo--Pierpao.lo (listening) 10:53, 29 apr 2019 (CEST)

ciao [@ Superchilum], [@ Pierpao]; se ho capito la domanda, per standardizzare i codici io userei quelli ISO; per le lingue cinesi dovrebbero bastare quelli dell'ISO 639-3, a tre lettere , quindi cmn per il cinese mandarino, yue per il cantonese eccetera (l'ISO 639-2 a due lettere non è sufficiente, perché zh è troppo generico per quello che volete fare). Qua c'è l'elenco per le varie lingue cinesi (per la cronaca, questi sono i codici utilizzati sul wikizionario inglese per generare le categorie linguistiche) --Barbaking scusate la confusione!! 11:09, 29 apr 2019 (CEST)

[@ Barbaking] no, sono codici automatici decisi dal software mediawiki mediante #babel, quindi dobbiamo solo capire cosa hanno deciso dall'alto :-\ --Superchilum^(scrivimi) 11:10, 29 apr 2019 (CEST)

ah, allora alzo le mani :P --Barbaking scusate la confusione!! 11:29, 29 apr 2019 (CEST)

Dato che ora MediaWiki identifica quei codici così, non abbiamo molta scelta se non spostare le categorie al rispettivo nuovo nome. Forse è semplicemente la dicitura più corretta o precisa.--Sakretsu (炸裂) 11:50, 29 apr 2019 (CEST)

Non proprio, ha ragione Barbaking dentro mediawiki si usa zh per indicare il cinese mandarino che non è corretto. Si legge qui Phab:T51274 per esempio. Bisognerebbe discuterne là. Nel frattempo ci dobbiamo adeguare anche perchè oggettivamente da quanto ho capito è un leggero miglioramento--Pierpao.lo (listening) 08:21, 3 mag 2019 (CEST) - Ripingo Barbaking--Pierpao.lo (listening) 08:22, 3 mag 2019 (CEST)

Pagina delle prove

Ciao a tutti. Mi sa che da ieri ci sia qualche problema nella pagina delle prove, con una specie di edit war tra bot prima e tra vari utenti e il bot di [@ .avgas] dopo :D--Parma1983 18:48, 2 mag 2019 (CEST)

Risolto: [@ Pierpao] ricreandola non l'aveva riprotetta dagli spostamenti :D--Parma1983 20:04, 2 mag 2019 (CEST)

Grazie mi ero chiesto il senso del template protetta e se il mio intervento avesse a che fare col bot, la combinazione era troppo strana, ma non ho pensato proprio alla protezione dagli spostamenti. Scusate--Pierpao.lo (listening) 20:09, 2 mag 2019 (CEST)

Bisogna ammettere però che la cronologia era esilarante, specialmente per gli insulti rivolti ai bot (: --goth nespresso 21:42, 2 mag 2019 (CEST)

Cambio indirizzo email

Salve, purtroppo non possiedo più l'indirizzo email col quale feci la registrazione e vorrei sostituirlo. Come posso fare?

Grazie --Romanescando (msg) 03:51, 3 mag 2019 (CEST) Diana

Dopo esserti loggata clicca su preferenze, in alto, e poi su cambia email e quindi su salva. A quesl punto avrai inserito il nuovo indirizzo email.--Burgundo (msg) 08:06, 3 mag 2019 (CEST)

���

Oggi noto che in alcune modifiche di Leo0428 compaiono questi segni a punto interrogativo bianco in rombo nero �. Lui sostiene di non saperne nulla. Purtroppo a me non capita, quindi preferirei intervenisse lui, detto questo sarei anche io interessato a sapere se voi sapete qualcosa della comparsa "dal nulla" di questi simboli. Secoli fa erano usati in alcuni siti al posto di caratteri speciali o accentati, es. Perch� Nicol� ha mangiato tre tiramis�?, ma non mi sembra questo il caso. Ne sapete qualcosa? --Mice, и добър вечер! 23:34, 4 mag 2019 (CEST)

Confermo! Questi simboli vengono fuori dal nulla e solo dopo aver salvato le modifiche. --Leo0428 (msg) 23:39, 4 mag 2019 (CEST)

...Dunque? Si sa nulla a riguardo? --Mice, и добър вечер! 14:34, 6 mag 2019 (CEST)

Sembrano in effetti i tipici caratteri che appaiono quando viene usato un carattere non riconosciuto dalla codifica unicode, magari proveniente da una codifica diversa, ma senza ulteriori dettagli è difficile comprenderne il motivo. [@ Leo0428] Usi qualche software, browser, script o preferenza particolare? --Titore (msg) 23:10, 6 mag 2019 (CEST)

[@ Titore] Ciao! Uso Microsoft Edge come browser senza script o preferenze particolari. Questi simboli non vanno a sostituire dei caratteri nel testo ma si aggiungono dopo aver pubblicato le modifiche. --Leo0428 (msg) 16:18, 7 mag 2019 (CEST)

Filtro anti abusi

È qui che si fanno queste segnalazioni? Credo di no, nel caso spostate pure. Ho notato per caso che l'utente Antonio durso83 è stato bloccato dal filtro anti abusi per questo edit (Filtro a punteggio). L'unica roba strana che vedo, a parte la mancanza di firma, è quel "far" seguito dal numero 3, che è vicino alla "e" nella tastiera. Possibile che basti così poco per finire bloccati? --Lepido (msg) 19:04, 5 mag 2019 (CEST)

[@ Lepido] A dire il vero è stato bloccato per questo edit; si tratta comunque di un falso positivo, ma direi che è molto più facile capirne il motivo. C'era comunque un parametro decisamente sballato nel filtro, al quale ho apportato una correzione immediata. --Daimona Eaytoy (Scrivimi!) 19:16, 5 mag 2019 (CEST)

Ah, ops... giusto. Avevo sbagliato mira ed era difficile che capissi i motivi... :-) Grazie di tutto. --Lepido (msg) 19:27, 5 mag 2019 (CEST)

Evoluzione voci in categoria

Buonasera! Qualcuno conosce uno o più tool che permettano di conteggiare, o ancora meglio di elencare, tutte le voci che sono state inserite in o rimosse da una categoria in un determinato arco di tempo? Preciso che mi interesserebbero non tanto le categorie inserite manualmente nelle voci a fondo pagina, quanto quelle legate a dei template, es. Categoria:P648 multipla letta da Wikidata senza qualificatore o Categoria:Voci con template Controllo di autorità ma senza codici. Non so se si tratti di un dato troppo volatile che nessun tool riesce a registrare, ma una funzione del genere se esistesse potrebbe essere molto utile per statistiche (se fornisse soltanto il conteggio) o anche per la gestione di vari lavoretti (se fornisse anche una lista delle voci). Grazie mille! --Epìdosis 19:16, 7 mag 2019 (CEST)

Allineamenti da mobile

Nella versione mobile, probabilmente in seguito all'ultimo aggiornamento, sono sorti dei problemi con gli allineamenti degli elenchi numerati. Si veda per esempio la resa grafica del template {{Tracce}}. --Ignazio (msg) 22:15, 2 mag 2019 (CEST)

[@ Sakretsu]? --Ignazio (msg) 15:40, 9 mag 2019 (CEST)

Quali problemi?--Sakretsu (炸裂) 20:00, 9 mag 2019 (CEST)

[@ Sakretsu] il distacco dal bordo. Posso capire che sia voluto nei sinottici, ma dubito che lo sia per gli altri casi. --Ignazio (msg) 22:26, 9 mag 2019 (CEST)

Ho controllato, è voluto. I task sono phab:T150377 e phab:T208102. C'erano problemi di visualizzazione coi numeri grossi e il VisualEditor.--Sakretsu (炸裂) 00:27, 14 mag 2019 (CEST)

Capisco, grazie. --Ignazio (msg) 01:13, 14 mag 2019 (CEST)

Multilingual Shared Templates and Modules

Hello it-wiki community! (Aiutaci a tradurre nella tua lingua)

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

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

Elementi di una categoria

È un po di tempo che controllo il totale degli elementi di una categoria grossa e trova una strana differenza che non riesco a spiegarmi. Usando le API di Mediawiki chiedo il totale della categoria:BioBot ed ottengo (oggi) 372.264. Poi, sempre con le API Mediawiki chiedo la lista ed ottengo 372.176 voci. Curiosamente la differenza di 88 voci è sempre la stessa da parecchio tempo (sicuramente da più di qualche mese, prima non saprei non avendo controllato). Qualche idea? --Gac 18:20, 14 mag 2019 (CEST)

Per questioni di performance, i metadati delle categorie (tra cui numero di pagine, sotto-categorie e file appartenenti alla categoria) vengono stoccati a parte in una tabella apposita (chiamata, con grande fantasia, "category"). Ogni volta che a una pagina viene aggiunta/tolta una categoria, questa informazione viene salvata in due posti distinti:

• Nella tabella "categorylinks" viene aggiunto/tolto un record che tiene traccia dell'appartenenza.
• Il corrispondente conteggio del record riassuntivo in "category" viene incrementato/decrementato di 1.

Come in tutti i casi di ridondanza in una base di dati, questo significa che le tabelle possono andare fuori sincronia: il numero di pagine riportato nel campo di category (e a sua volta riferito dalla API query/categoryinfo) può differire dall'effettivo numero di record in categorylinks che si riferiscono a quella categoria (e che sono utilizzati per rispondere alla richiesta, molto più lenta, query/categorymembers).

Una volta che si è instaurata una discrepanza, la differenza tra i due valori viene mantenuta costante proprio dalla logica che avrebbe dovuto mantenere quella differenza costantemente nulla: il conteggio viene incrementato/diminuito "correttamente", preservando l'entità dell'esistente discrepanza. :-)

Esiste uno script di manutenzione apposito che può essere usato per chiedere al database di utilizzare il metodo lento (ovvero rifare tutti i conteggi a partire dai record della tabella categorylinks) per sovrascrivere i contatori in "category" e ripartire da valori corretti. -- Rojelio (dimmi tutto) 18:59, 14 mag 2019 (CEST)

Risposta chiara ed esauriente. In realtà io uso la lista che, mi sembra di capire, contenga i dati aggiornati ed uso query/categoryinfo solo per controllare di avere recuperato tutte le pagine. D'ora in poi eviterò il controllo. Oppure lo mantengo e controllo che la differenza sia sempre 88 :-) --Gac 20:14, 14 mag 2019 (CEST)

Conflitto di edizione

Sono convinto di essere già passato di qua per questo motivo, ma forse non avevo avuto risposta: come mai talvolta il sistema non avvisa del conflitto di modifiche, ottenendo così che la modifica avvenuta appena prima viene "cancellata" a causa della modifica appena dopo? Es. mi è appena successo in Discussioni utente:158.148.198.56, dove, battuto però sul tempo da Leo0428, ho apposto un avviso di vandalismo per una modifica a Cristiano Malgioglio. Ne sapete qualcosa...? --Mice, и добър вечер! 20:23, 14 mag 2019 (CEST)

[@ Micejerry] vedi qui per la risposta della scorsa volta. Oggi il caso è un po' diverso. Se avete modificato la pagina nello stesso millisecondo, è presumibile che il sistema non sia riuscito a trovare una versione precedente con cui identificare un conflitto.--Sakretsu (炸裂) 21:00, 14 mag 2019 (CEST)

[@ Sakretsu] Ah, allora ero io che non ci avevo più guardato. Riguardo ai millisecondi, è possibile che sia andata così, effettivamente, visto che in Ultime modifiche le due modifiche risultavano l'una subito dopo l'altra. Grazie. --Mice, и добър вечер! 22:23, 14 mag 2019 (CEST)

Testi che si sovrappongono

Come far sì che gli elementi con il nome troppo lungo non si sovrappongano alla colonna alla loro destra, o addirittura escano dal template, in pagine come Utente:Superchilum/UP/templatecreati? --Superchilum^(scrivimi) 10:22, 14 mag 2019 (CEST)

[@ Superchilum] Purtroppo è una "feature" espressamente cercata e voluta dal template Navbox (stile "nowraplinks"): remargli contro potrebbe non essere facilissimo. -- Rojelio (dimmi tutto) 01:45, 15 mag 2019 (CEST)

Non proprio. Il nowraplinks rende solo più evidente un problema che è insito nel {{Colonne}}, cioè la sovrapposizione di contenitori div qualora sullo schermo non ci sia abbastanza spazio--Sakretsu (炸裂) 02:20, 15 mag 2019 (CEST)

Quindi essendoci il "nowraplinks" viene forzato il non andare a capo, giusto? Quindi o uso un altro template/codice o me lo tengo così, se non ho capito male. --Superchilum^(scrivimi) 09:56, 15 mag 2019 (CEST)

[@ Superchilum] ho bisogno di fare qualche altro test e accorgimento, ma in sostanza il Colonne va aggiornato per distribuire le colonne in modo reattivo e non statico (vedi esempio, la differenza si nota meglio provando a rimpicciolire la finestra del browser). Il nowraplinks - che occupa più spazio in orizzontale, ma migliora la leggibilità delle liste - dovrebbe solo rendere più facile che una colonna sfili più giù. Comunque il navbox si può sostituire con un normale cassetto--Sakretsu (炸裂) 00:51, 16 mag 2019 (CEST)

Edit counter

Ciao. Ho notato che, mentre il mio edit counter si "ferma" a "year counts", quello di altri utenti (per esempio questo e questo) è "completo". Qualcuno saprebbe spiegarmi il motivo? Grazie. --FeltriaUrbsPicta (msg) 14:50, 16 mag 2019 (CEST)

[@ FeltriaUrbsPicta] Le informazioni nelle sezioni seguenti (Month counts, Time card, Top edited pages) sono nascoste, a meno che l'utente in questione non decida di mostrarle creando il file Utente:NomeUtente/EditCounterOptIn.js (le istruzioni dicono che va bene qualsiasi contenuto). In mancanza del file, ognuno può sempre vedere le proprie informazioni (incluse quelle nascoste) loggandosi su Xtools.--Equoreo (msg) 15:03, 16 mag 2019 (CEST)

Aggiungo che puoi anche fare l'opt-in per tutti i progetti creandoti su MetaWiki la pagina meta:User:NomeUtente/EditCounterGlobalOptIn.js (es. meta:User:Epìdosis/EditCounterGlobalOptIn.js). --Epìdosis 15:06, 16 mag 2019 (CEST)

[@ Equoreo] Il file Utente:FeltriaUrbsPicta/EditCounterOptIn.js l'ho creato nel 2015. --FeltriaUrbsPicta (msg) 15:11, 16 mag 2019 (CEST)

[@ FeltriaUrbsPicta] Ciao. A quanto vedo tu hai creato una pagina vuota. Probabilmente serve anche un minimo di contenuto, come il punto aggiunto da Epìdosis--Parma1983 15:14, 16 mag 2019 (CEST)

[@ Epìdosis] Facendo l'opt-in per tutti i progetti non dovrei più avere problemi? --FeltriaUrbsPicta (msg) 15:24, 16 mag 2019 (CEST)

[@ Parma1983] Provo ad inserire un "minimo di contenuto"? --FeltriaUrbsPicta (msg) 15:24, 16 mag 2019 (CEST)

[@ FeltriaUrbsPicta] Controllando anche questa e questa, esattamente come quella (globale) di Epìdosis sono state create con un minimo di contenuto, perciò presumo che il motivo possa essere quello. Tenta, al limite puoi sempre tornare indietro--Parma1983 15:33, 16 mag 2019 (CEST)

Sì non può essere vuota perché il controllo avviene sulla risposta, il 404 sarebbe intercettato probabilmente a monte quindi che la pagina non ci sia o che sia vuota sarebbero la stessa cosa. --Abisys (msg) 15:44, 16 mag 2019 (CEST)

[@ Equoreo, Epìdosis, Parma1983, Abisys] Problema risolto! Bastava inserire un "minimo di contenuto". Grazie davvero a tutti. --FeltriaUrbsPicta (msg) 17:50, 16 mag 2019 (CEST)

Tool per patrolling

Ultima modifica alla pagina non verificata

Carissimi, recentemente mi è capitato di notare (come del resto mi era già capitato in passato) che su alcune Wikipedie, es. de.wiki o id.wiki o ru.wiki e altre, in cui è attivo il sistema secondo il quale solo l'ultima versione verificata di una pagina viene mostrata al lettore (l'introduzione di questo sistema qui è già stata dibattuta in passato, ma non di questo voglio qui discutere, ovviamente), l'utente, nel momento in cui modifica una pagina, se l'ultima versione (o le ultime versioni) della pagina non sono state verificate riceve un avviso. Ora, la mia domanda è: sarebbe possibile (o, per caso, esiste già) ideare un gadget, attivabile volontariamente dagli utenti registrati, che permetta loro, quando modificano una pagina (penso soprattutto all'ns0, ma può benissimo valere per tutti i namespace), di ricevere una qualche sorta di avviso riguardo al fatto che l'ultima versione (o le ultime versioni) della pagina non sono state verificate? Credo che un gadget del genere sarebbe potenzialmente utile per il retropatrolling: ad esempio, quando trovo una pagina relativa all'antica Grecia che non avevo mai notato, faccio qualche piccola modifica e la aggiungo ai miei OS, può capitare che non noti la presenza di un vandalismo se non consulto dettagliatamente la cronologia ... con un gadget del genere ciò non accadrebbe. Oppure, anche se mi capita di modificare una pagina non di mio generale interesse, è possibile che la mia modifica vada a "coprire" un vandalismo passato inosservato, contribuendo a preservarlo per tempi anche lunghi ... e così non accadrebbe. Spero che non si tratti di un compito eccessivamente complesso! A presto, --Epìdosis 09:29, 24 gen 2019 (CET) P.S. Se avete tempo, date anche un'occhiata alla mia richiesta più sopra relativa a Speciale:PagineNonOsservate :)

Mi permetto di riacciuffare questo thread sperando in una risposta, visto che l'argomento mi sembra rilevante! Segnalo anche al Progetto:Patrolling. --Epìdosis 18:31, 27 feb 2019 (CET)

Per dare un'occhiata e una risposta a Speciale:PagineNonOsservate sarebbe opportuno dare le autorizzazioni all'accesso.... --Skyfall (msg) 18:50, 27 feb 2019 (CET)

[@ Skyfall] Lo so, secondo me dare l'accesso a Speciale:PagineNonOsservate anche agli autoverificati non sarebbe male ... comunque, riguardo alla mia proposta di cui sopra, è vero che bene o male con PetScan ci si arrangia. --Epìdosis 18:42, 28 feb 2019 (CET)

[@ Epìdosis] credo che sarebbe un'implementazione piuttosto complessa da mettere in pratica, dal momento che gli utenti autoverificati non riceverebbero nessun avviso e gli altri non potrebbero verificare se stessi. Dovrebbe essere creata una sorta di categoria che raggruppi tutte le versioni ancora da verificare (o esiste già e io non lo so?) e sarebbe impossibile gestirle tutte quante.

A margine, anche secondo me potremmo estendere l'accesso a Speciale:PagineNonOsservate agli autoverificati. --Ignazio (msg) 22:14, 28 feb 2019 (CET)

[@ Ignazio Cannata] Non capisco perché "gli utenti autoverificati non riceverebbero nessun avviso e gli altri non potrebbero verificare se stessi": cioè, se il gadget segnala che le ultime X modifiche non sono verificate (esattamente come accade su de.wiki, id.wiki e ru.wiki: esempio), l'utente, che sia autoverificato o non autoverificato, può controllare la correttezza di quelle modifiche (verificandole se corrette, annullandole in caso contrario) ed evitare così che la sua modifica vada a coprire magari un vandalismo passato inosservato. La soluzione non credo sia una categoria, quanto piuttosto un sistema, magari un po' meno raffinato, modellato su mw:Extension:FlaggedRevs (quella implementata in de.wiki, id.wiki e ru.wiki). --Epìdosis 22:49, 28 feb 2019 (CET)

[@ Epìdosis] premetto che probabilmente mi sfugge qualcosa, ma credo che le modifiche non siano solo o da verificare o da annullare. Il fatto è che un utente non autoverificato, sia che annulli una modifica, sia che la revisioni, otterrebbe sempre un'altra modifica da verificare. --Ignazio (msg) 00:17, 1 mar 2019 (CET)

[@ Ignazio Cannata] Secondo la casistica è: se è sbagliata, si annulla; se è imprecisa, si verifica e poi si sistema; se è corretta, si verifica; se si è in dubbio, si segnala al progetto competente (vedi proposta sottostante). Ovvio che un utente non autoverificato lasci una modifica da verificare, però ciò nulla toglie al fatto che, se scopre che l'ultima modifica alla voce è sbagliata e l'annulla, quest'ultimo fatto sia positivo. --Epìdosis 14:48, 1 mar 2019 (CET)

[@ Epìdosis] questo ci riconduce al nocciolo della questione: per quanto possa essere raffinato il sistema di tracciamento, una novità del genere determinerebbe un ingente carico di lavoro, perché almeno per quanto mi riguarda è importante che le nuove modifiche siano presto visibili. In poche parole è un'implementazione che non mi convince, sarei tendenzialmente contrario. --Ignazio (msg) 16:01, 1 mar 2019 (CET)

[@ Ignazio Cannata] Adesso capisco che forse mi sono spiegato male: la mia proposta non è introdurre in toto mw:Extension:FlaggedRevs (credo ci siano state discussioni in proposito in passato, che avevano espresso parere negativo appunto per l'enorme mole di lavoro che ciò comporterebbe, e concordo con questa argomentazione), cioè non propongo di far sì che le modifiche non verificate non vengano visualizzate dal lettore fintantoché non sono state verificate; al contrario, propongo di introdurre questo sistema parzialmente, cioè semplicemente di far sì che l'utente, quando modifica, possa vedere le modifiche non verificate "in sospeso" (dove però "in sospeso" non indica "non visualizzate dal lettore", bensì indica "potenzialmente problematiche") senza dover per forza aprire la cronologia e controllare lo stato delle ultime modifiche ... così da risparmiare qualche clic. Secondo me un sistema del genere, attivabile nelle preferenze (dunque non abilitato di default), potrebbe essere giovevole. Cosa ne pensi? --Epìdosis 16:39, 1 mar 2019 (CET)

[@ Epìdosis] tutta un'altra storia, in questo caso ben venga. --Ignazio (msg) 17:36, 1 mar 2019 (CET)

Facilitare la segnalazione di modifiche dubbie ai progetti

Carissimi, anche se vedo che le mie due ultime proposte sembrano essere troppo complesse, provo a farvene un'altra: spesso mi è capitato in questi anni di vedere nei miei OS modifiche che non ero sicuro se annullare o meno e che nel dubbio ho lasciato correre ... ora, mi chiedevo se sarebbe possibile creare un'infrastruttura, fondata sui progetti, di questo genere (ci stavo pensando soprattutto visto il gran lavoro di pulizia che sta compiendo in queste settimane [@ Pallanz]):

• creare in ogni progetto una sottopagina "/Modifiche dubbie" (es. Progetto:Antica Grecia/Modifiche dubbie; comunque si accettano suggerimenti per titoli migliori)
• e creare un gadget che permetta all'utente, quando si trova su un diff dubbio (o possibilmente anche dalla cronologia, in modo da poter prendere diff multipli), di inviare una segnalazione di "modifica dubbia" compilando nome del progetto (es. "Antica Grecia") e aggiungendo eventualmente un commento (es. "aggiunta plausibile ma priva di fonte").

La mia fonte di ispirazione più prossima è d:User:Bene*/iwconflict.js, che permette di segnalare problemi di interwiki su Wikidata; ovviamente è un po' diverso, direi più semplice (soprattutto perché lì la pagina è unica, mentre qui avremmo a che fare con più progetti).

Non so quanto sarebbe complesso creare un gadget del genere, però penso che in tal modo molti utenti, che come me vedono modifiche dubbie e le lasciano passare (o, magari, ogni tanto le segnalano a qualche utente di conoscenza o al progetto competente), con a disposizione un gadget così comodo potrebbero invece segnalarle al progetto competente e così farle adeguatamente annullare oppure sistemare. Spero di non essere stato troppo confuso. A presto, --Epìdosis 10:15, 28 gen 2019 (CET)

Sicuramente è un'ottima idea. Automatizzerebbe fortemente l'ecosistema dei progetti e renderebbe di gran lunga più facile controllare modifiche che, per un motivo o per l'altro, risultano dubbie. Tuttavia non so quanto sia complessa da realizzare. --Pallanz_msg 17:31, 29 gen 2019 (CET)

Ragazzi, nessuna idea? Segnalo anche questo al Progetto:Patrolling. --Epìdosis 18:32, 27 feb 2019 (CET)

Mi piace molto questa idea… permetterebbe oltretutto di dividersi meglio il lavoro da fare, in base alle nostre competenze/interessi --Torque (scrivimi!) 01:01, 28 feb 2019 (CET)

Taglio tecnico

Carissimi, visto che le due proposte hanno ricevuto alcuni pareri positivi, nessuno avrebbe voglia di provare a immaginare possibili sviluppi tecnici? Grazie mille, --Epìdosis 18:56, 22 mar 2019 (CET)

Per quanto riguarda la prima proposta: non è esattamente quello che chiedi, ma attivando l'accessorio ScoredRevisions compare una bandierina rossa/arancione sulla linguetta "cronologia" in alto se vengono rilevate potenziali modifiche problematiche secondo ORES. --Titore (msg) 00:39, 23 mar 2019 (CET)

[@ Titore] Grazie per il suggerimento, effettivamente diciamo che il tool risponde parzialmente alla mia domanda (ora l'ho attivato, su Wikidata ce l'ho ormai da anni); la cosa che più mi disturba è che preferirei si applicasse solo alle modifiche non verificate ... cioè, una volta che una modifica è stata verificata vorrei che non venisse in alcun modo "colorata", soprattutto se a verificarla sono stato proprio io. Comunque, ripeto, è una risposta complessivamente buona, grazie ancora. Spero invece che la seconda proposta non cada nel vuoto! Buona notte, --Epìdosis 01:21, 24 mar 2019 (CET)

<OT>Per caso c'è un luogo dove si può chiedere che ORES "scolori" le modifiche che l'utente stesso ha verificato?</OT> --Epìdosis 21:47, 21 apr 2019 (CEST)

Oppure perché non creare una pagina qui su Wikipedia per la proposta di nuovi gadget/tool? Permetterebbe di non intasare l'Officina e di tenere traccia delle idee in modo più ordinato. --Epìdosis 12:15, 21 mag 2019 (CEST)

PHP7

Va controllato come vengono attribuite le etichette, temo, visto che una persona normale non inserirebbe mai il PHP7 per fare una singola modifica quando sia la modifica precedente sia quella appena successiva non sono contrassegnate come PHP7. Siccome io sono una persona normale che non inserirebbe mai il PHP7 per fare una singola modifica, qualcosa mi dice che è il sistema che ha errato. In ogni caso, lo dico solo come promemoria: finché non fa danni IMHO non è così problematico. E dubito che l'etichetta PHP7 possa fare danni. --Mice, и добър вечер! 14:55, 9 mag 2019 (CEST)

Aggiorno: ha preso a segnarmi come PHP7 tutti gli spostamenti. Sì, c'è qualcosa che non quadra. --Mice, и добър вечер! 15:38, 9 mag 2019 (CEST)

Non c'è niente che non vada, vedi mw:Special:MyLanguage/Beta Features/PHP7. Se non ricordo male (non riesco a ritrovarne traccia, ma ero sicuro di averlo letto da qualche parte), al momento PHP7 viene attivato casualmente con finalità di test, indipendentemente dall'utente. --Daimona Eaytoy (Scrivimi!) 20:52, 9 mag 2019 (CEST)

Ah, non sapevo. In ogni caso per ora non mi è mai cambiato nulla, con o senza PHP7, quindi facciano come vogliono. --Mice, и добър вечер! 22:37, 9 mag 2019 (CEST)

Daimona Eaytoy non è che viene attivato casualmente e che non tutti i server hanno a bordo PHP7 anche se dal 31/12/2018 il PHP5 è deprecato. Quindi dipende da dove ti ridirige varnish, a mio avviso, poi non tutto è disponibile su PHP7 ieri ad esempio non riuscivo a modificare Bureau Veritas perché non vedevo la spaziatura corretta tanto che ho fatto più edit e con due browser diversi problema che non esiste da sloggato ne sono riuscito a fare un debug preciso perché non espone la versione di PHP installata, oggi mi sono messo a leggere questa pagina per vedere se trovavo riscontri.

[@ Micejerry] se vuoi resettare il binding che varnish ti fa con un server penso che dovresti cancellare i cookie relativi a wikipedia.org, più specificamente penso WMF-Last-Access e WMF-Last-Access-Global. --Abisys (msg) 21:24, 16 mag 2019 (CEST)

[@ Abisys] Probabilmente perché sono poco esperto in merito, ho capito la metà di quel che hai scritto. Detto questo per il momento non mi ha mai dato problemi... se ne avrò ripasserò. --Mice, и добър вечер! 21:32, 16 mag 2019 (CEST)

[@ Micejerry] scusami, mi rifacevo a quello che chiedevi sul TAG PHP7, non è una cosa che mettiamo noi o che possiamo gestire, è il risultato di come vengono processate le operazioni di backend dei server WMF. Noi possiamo scegliere se provare la nuova implementazione con PHP7 ma poi sta ai server decidere se usare il vecchio PHP5, che è l'ambiente di produzione, o il nuovo PHP7 che è in test. Tu hai detto che per un po' non ti metteva quel TAG, io ti ho dato un suggerimento su come fare a riforzare il ricalcolo che fanno i server per associare un singolo utente ad un determinato server perché avevo capito che tu volessi sempre il TAG abilitato, ovvio che ti funzionava tutto perché diciamo che se non c'è PHP7 siamo sicuri che tutto sia perfetto, il tag serve proprio a dire attenzione che stai utilizzando una funzionalità in test non che stai utilizzando la funzionalità migliore. Quindi tu puoi decidere di permettere a WMF di farti testare la nuova implementazione in PHP7 i modo che loro possano terminare l'analisi, non di usare solo PHP7. Non è una questione come quella di monobook o vector che sono gestiti lato utente e quindi tu puoi effettivamente scegliere quale utilizzare da cosa ho capito e posso vedere. --Abisys (msg) 22:00, 16 mag 2019 (CEST)

[@ Abisys] E' che io almeno un mese e mezzo fa avevo attivato per qualche giorno PHP7 dalle preferenze, e me lo segnava per tutte le modifiche. Sinceramente non vi trovavo tutta sta grande differenza, così decisi di rimuoverlo e rimanere come prima (quindi, secondo quello che dici tu, PHP5); tuttavia a inizio maggio mi sono accorto che mi aveva segnato una modifica come PHP7 nonostante non l'avessi attivato; cosa più strana, la modifica prima e la modifica dopo quella modifica così come le ultime 50 modifiche da me in quel momento effettuate non erano segnate PHP7. Ed ecco come mai sono passato di qui. Successivamente mi sono accorto che me lo faceva più spesso, specie con gli spostamenti (ormai me li segna praticamente tutti come PHP7). Volevo semplicemente sapere come mai e se c'era un modo per evitarlo. Detto questo, se non c'è no problem, tanto le mie modifiche sono sempre le stesse e che siano in PHP5 o PHP7 poco cambia. --Mice, и добър вечер! 22:11, 16 mag 2019 (CEST)

Ma... un momento, però adesso è sparita la possibilità di attivarlo e disattivarlo da di lì... evidentemente è come diceva Daimona(?) --Mice, и добър вечер! 22:15, 16 mag 2019 (CEST)

[← Rientro][@ Abisys] Senz'altro è attivo solo su alcuni server, e altrettanto probabilmente la redirezione viene fatta al livello di caching layer. Però intendevo dire che, appunto, il campionamento è randomizzato; quindi per ogni richiesta c'è una probabilità X che venga servita con PHP7. La versione di PHP utilizzata al momento è visibile da Speciale:Versione, in sostituzione della riga "HHVM". A margine, se sospetti di aver avuto un problema con PHP7, posso dare un'occhiata ai log per verificare se effettivamente dipenda da quello; nel caso, sarebbe molto importante segnalarlo. Comunque, ripeto che sul campionamento casuale non sono certo: erano state fatte varie modifiche in tal senso e mi sembrava di aver visto l'aggiunta del codice per campionare, ma naturalmente potrei sbagliarmi. La beta feature invece è stata rimossa 2 giorni fa (cfr. T219128 e gerrit:510430) perché ci sono abbastanza dati. Guardando la patch, tra l'altro, si direbbe che il cookie in questione sia PHP_ENGINE. Ma in ogni caso, non mi sembra necessario cancellare cookie o in generale cercare di evitare la beta feature. Per gli utenti ([@ Micejerry]) non deve cambiare nulla, l'idea è quella. Al massimo le richieste con PHP7 dovrebbero essere più rapide, ma si parla comunque di piccole differenze. Comunque, il team SRE ha in programma il completamento dello switch entro fine giugno 2019, quindi è ancora questione di poco. --Daimona Eaytoy (Scrivimi!) 10:15, 17 mag 2019 (CEST)

Ciao Daimona Eaytoy grazie, mi ero fatto uno screenshot del problema, in giallo gli errori dove vedi che mancano gli spazi ma poi sono ricomparsi nella voce salvata senza che io facessi nulla e le operazioni di salvataggio sono state lunghissime dell'ordine dei 20 secondi. Se vuoi veder cosa è successo fai pure. Per quanto riguarda PHP_ENGINE direi che non contiene i dati di sessione utili a varnish per indirizzarti al server che stai usando, ma solo i dati all'engine a cui sei assegnato, se lo rimuovi quindi rimani, a mio avviso, sullo stesso server. HHVM comunque è il JIT realizzato da FB molto più veloce dello Zen Engine nel processare il codice PHP solo che con l'uscita di PHP7 si sono create delle incompatibilità con HHVM e due anni fa gli sviluppatori di HHVM hanno deciso di non supportare più PHP e quindi la necessità di passare a PHP7 per chi deve gestire codice PHP. Quindi non ci da la versione del codice PHP ma solo dell'interprete. Per le prestazioni direi che HHVM è il 120% in media più veloce di Zen Engine di PHP5, il PHP7 il 100% questo usando i test standard di WordPress, quindi penso saremo leggermente più lenti ma di sicuro allineati come sicurezza, poi con PHP8 ci sarà anche un JIT nativo ma non uscirà prima di due anni. Ci potrebbe però essere un beneficio ulteriore nella gestione del Unicode che in PHP7 è stato completamente rivisto, quindi se teniamo conto anche di questo possiamo avvicinarci ancora di più alle prestazioni di HHVM ma non penso superarle. --Abisys (msg) 12:48, 17 mag 2019 (CEST)

[@ Abisys] Dunque, cerco di rispondere per punti. Intanto, il bug su bureau veritas: ho dato un'occhiata, ma non ci sono log interessanti in proposito. Ci poteva essere speranza con il tempo di salvataggio elevato, ma in tal senso viene loggato solo il superamento dei 60 secondi (che è il tempo massimo impostato per una richiesta). Riguardo al PHP_ENGINE, in realtà a quanto vedo (non solo dalla patch linkata) sembra essere l'unico cookie relativo alla scelta HHVM/PHP7; ovviamente quel codice da solo non basta, ma ci sono vari altri punti in cui viene usato. A margine, riguardo al campionamento casuale di cui parlavo, effettivamente c'è ed è gestito dalla variabile WMEPhp7SamplingRate (cerca), che al momento indirizza un utente su 20 a PHP7. Riguardo ad HHVM, forse era più veloce qualche anno fa, quando iniziarono ad usarlo per MediaWiki, e aveva senz'altro una performance migliore di PHP5.x. A quanto ho visto, lo switch back to PHP7 è dovuto in parte, come dicevi, al fatto che le ultime versioni di HHVM supportano soltanto Hack, e in parte perché i vantaggi in termini di velocità sono venuti meno; ci sono alcuni dati in proposito qui. Speciale:Versione può dare due tipi di informazioni: con HHVM dà effettivamente la versione dell'interprete; in ogni caso, la versione di PHP riportata sui log è php-5.6.99-hhvm. Con PHP7 però, se non erro, dà esattamente la versione di PHP; anche in questo caso, posso dirti con precisione che si tratta della 7.2.16. PHP8 avrà senz'altro delle feature gustose (il JIT in particolare!), ma oltre ai tempi necessari perché esca, ci sono anche quelli di aggiornamento di MW, che potrebbero essere lunghi. Infine, riguardo a Unicode, il fatto che la gestione di PHP7 differisca da quella di HHVM porta alcuni problemi con le pagine che contengono caratteri particolari (phab:T219279). In generale, queste sono le incompatibilità note, e dovrebbero essere gli ultimi blocker prima che possano droppare HHVM. --Daimona Eaytoy (Scrivimi!) 13:21, 17 mag 2019 (CEST)

Richiesta filtro - Taijiquan

La voce Taijiquan è soggetta da mesi a edit di questo^105042020 tipo (possibili varianti: "macchinine" invece di "automobiline", "comandate" invece di "radiocomandate"): sarebbe possibile arginarli con un filtro invece di semiproteggere la pagina? --Dan Kenshi (msg) 13:27, 22 mag 2019 (CEST)

Aiuto formattazione su due voci

Ciao a tutti, mi servirebbe una mano a fare pulizia ma non vorrei fare danni.

• Coppa Italia IBL 2017: ci sono elementi di programmazione nella sezione Ottavi di finale. La voce è anche farcita in varie parti di elementi HTML tipo <td colspan="2" style="border:1px solid #aaa;border-bottom: 0px;background-color:#f9f9f9;padding-left:0.3em;" >. Si tratta principalmente di convertire la tabella nella nostra sintassi.

• Cristianesimo nel mondo: ci sono elementi di programmazione nella sezione Stati sovrani e territori dipendenti.

Grazie a chi volesse contribuire. --Torque (scrivimi!) 17:29, 22 mag 2019 (CEST)

XTools WMFlabs

Qualcuno sa come mai non si riesce più ad accedere (e quindi a visualizzare, per es., l'editcount mensile)? --Mice, и добър вечер! 13:26, 24 mag 2019 (CEST)

Nulla, dopo aver riacceduto due o tre volte è andato a posto. Bah... spero fosse un bug momentaneo. Buon proseguimento. --Mice, и добър вечер! 13:31, 24 mag 2019 (CEST)

Ogni tanto si blocca temporaneamente. Non è la prima volta [@ Micejerry]. --Torque (scrivimi!) 13:52, 24 mag 2019 (CEST)

[@ Torque] Non mi era mai capitato e quindi non sapevo. Ok --Mice, и добър вечер! 13:53, 24 mag 2019 (CEST)

Collegamenti a Wikidata

Non sono sicuro di dovermi rivolgere qui, ma nel dubbio...

Segnalo che c'è da correggere la notifica dei collegamenti a Wikidata. Nello specifico "La pagina <nome della pagina> è stata collegata a l'elemento Wikidata" dovrebbe diventare "La pagina <nome della pagina> è stata collegata all'elemento Wikidata". Buon proseguimento --Mice, и добър вечер! 19:43, 26 mag 2019 (CEST)

Ho sistemato la traduzione, dovrebbe essere integrata prossimamente. --Titore (msg) 20:09, 26 mag 2019 (CEST)

Bene. --Mice, и добър вечер! 20:44, 26 mag 2019 (CEST)

I segni �

Ripropongo discussione di qualche tempo fa; anche se non ho più notato questo simbolo in delle modifiche né di Leo né di altri, mi piacerebbe saperne di più, se è un bug wikipediano o se è causato da qualcos'altro. La vecchia discussione si chiamava "���" ed è poco più in alto. Se qualcuno sa... faccia un fischio. --Mice, и добър вечер! 20:44, 26 mag 2019 (CEST)

Ripetizione nel menu

Segnalo che nel menu della colonna di sinistra è ripetuto 2 volte “Scarica come PDF”. --151.49.118.146 (msg) 22:03, 26 mag 2019 (CEST)

Grazie, se ne stanno occupando. --Elitre (WMF) (msg) 18:28, 27 mag 2019 (CEST)