Taylor added a comment.
> Do you believe that if someone opens a Wikidata item with 100 > sitelinks, Wikidata should query all 100 Wikipedia projects every time? Of course NOT. Do you believe that if someone opens a Wikipedia page with 200 templates and modules. Wikipedia should process all those 200 things every time? That's why caching has been available and used for a long time. ;-) It is already available even on WikiData. > what we mean by "valid redirects" Those that have a WikiData Q-item to connect to. A concept sufficienty notable to have a Q-item but not having a page on that wiki at the moment. If the redirect is turned into a primary topic or vice versa then the link to wikidata remains functional. What we should autodetect besides presence of the `__VALIDREDIRECT__` magic word is: - target page of the redirect exists - target page of the redirect is NOT a redirect - target page of the redirect is non-empty (or above some sane minimal size) - target page of the redirect is connected to wikidata > Wikidata policy on which redirects we want to list on Wikidata > Spelling mistakes are for example not valid redirects according to our Wikidata policy Good, but this does not interfere with my proposal. > should not put VALIDREDIRECT on their redirect pages with spelling mistakes > has the potential for a lot of conflicts Not really. It's easy to understand to >>> Connect a redirect to wikidata only if the redirect is about an at least slightly different >>> topic and has a Q-item. If you connect a redirect to wikidata, use >>> the `__VALIDREDIRECT__` magic word, otherwise don't. > A couple of minutes runtime per day would be sufficient to keep this synced > with little delay for all client wikis. I will be happy to see this working. :-) > they are not supposed to put VALIDREDIRECT on redirects that are not eligible > for an independent Wikidata item? If I would be a Wikipedia editor and see > VALIDREDIRECT on one redirect page, my natural impression would be that > VALIDREDIRECT is supposed to be put on all redirect pages that conform with > the redirect policy of the Wikipedia Well ... maybe call the magic word `__REDIRECT_WORTHY_Q-ITEM__` instead? > explain to the enWiki audience that they are supposed to respect Wikidata policy Until year 2013 we had trillions of global bots that placed intewiki link junk on all wikipedia pages and edited those again and again. On wiktionary this insanity lasted until year 2017. The enWiki audience does not have to do so much. Just let a global bot go though all wikis and perform this technical change essentailly invisible on the local wiki in question. > "Don't do anything that has a potential for starting conflicts with > other Wikimedia projects" is useful Very good. Both the interwiki bots before 2013 and 2017, and the current "solution" requiring to trash the redirect in order to be able to connect to WikiData have or had potential for starting conflicts or the WWIII. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Taylor Cc: Manuel, karapayneWMDE, Dexxor, CennoxX, Tagishsimon, William_Cheselden, Pokechu22, ExE-Boss, Ameisenigel, amy_rc, Mohammed_Sadat_WMDE, Bugreporter, Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Astuthiodit_1, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
