[Wikidata-bugs] [Maniphest] T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles
Alsee added a comment. Is there a reason for this task to still be open? Is there some aspect that is not 100% complete? TASK DETAIL https://phabricator.wikimedia.org/T248457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Alsee Cc: Count_Count, Muchiri124, CASSIOPEIA, Xaosflux, mdaniels5757, TheDJ, eprodromou, Pigsonthewing, GhostInTheMachine, Iniquity, DannyH, ppelberg, MichaelMaggs, Dreamy_Jazz, taavi, kaldari, Certes, Xeriphas1994, Mathglot, Bencemac, Galobtter, Tgr, Trialpears, Jonesey95, RexxS, QEDK, Pppery, Lydia_Pintscher, JJMC89, DannyS712, Aklapper, Alsee, Liuxinyu970226, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, lucamauri, 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
[Wikidata-bugs] [Maniphest] [Commented On] T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles
Alsee added a comment. The current mainspace search count <https://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=hastemplate%3A%22short+description%22&ns0=1> of about 2,250,000 matches up well with the category count when you include non-article mainspace pages, primarily disambiguation. Category:Pages_with_short_description <https://en.wikipedia.org/wiki/Category:Pages_with_short_description> currently reports approximately 1,939,000 articles, approximately 312,000 disambiguation pages, plus some thousands of pages of other types in and out of mainspace. TASK DETAIL https://phabricator.wikimedia.org/T248457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Alsee Cc: QEDK, Pppery, Lydia_Pintscher, Mike_Peel, JJMC89, DannyS712, Aklapper, Alsee, Liuxinyu970226, darthmon_wmde, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles
Alsee updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T248457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Alsee Cc: Pppery, Lydia_Pintscher, Mike_Peel, JJMC89, DannyS712, Aklapper, Alsee, Liuxinyu970226, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles
Alsee added a comment. In T248457#6003779 <https://phabricator.wikimedia.org/T248457#6003779>, @Mike_Peel wrote: > I really hope this never happens There was repeated consensus on this, and if you recall you participated in one <https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_145#RfC:_Populating_article_descriptions_magic_word>. The Foundation handled things badly, but committed to terminating wikidata descriptions when we reached 2 million local descriptions. I expect the result would be Bad all around if the Foundation were to renege. > There are 2.8+ million infoboxes on Commons that are using the English descriptions from Wikidata, and there is currently no way that they can access the enwp descriptions. Should we open a different task for English article-descriptions to replace the English field on wikidata? TASK DETAIL https://phabricator.wikimedia.org/T248457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Alsee Cc: Mike_Peel, JJMC89, DannyS712, Aklapper, Alsee, Liuxinyu970226, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T187285: Magic word on English WP to replace Wikidata short descriptions
Alsee removed a subtask: T248457: Fully terminate use of Wikidata ITEM-DESCRIPTIONS as short ARTICLE-DESCRIPTIONS for English Wikipedia articles. TASK DETAIL https://phabricator.wikimedia.org/T187285 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Alsee Cc: TheDJ, DannyH, MZMcBride, Alsee, Aklapper, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T187285: Magic word on English WP to replace Wikidata short descriptions
Alsee added a subtask: T248457: Fully terminate use of Wikidata ITEM-DESCRIPTIONS as short ARTICLE-DESCRIPTIONS for English Wikipedia articles. TASK DETAIL https://phabricator.wikimedia.org/T187285 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Alsee Cc: TheDJ, DannyH, MZMcBride, Alsee, Aklapper, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T159678: [Bug] Special:Nearby isn't showing thumbnails on Wikidata
Alsee added a comment. The default behavior of PageImages is Free-only for good reason. The Board of Trustee's Resolution:Licensing_policy <https://foundation.wikimedia.org/wiki/Resolution:Licensing_policy> says that unauthorized use of copyrighted content (non-free content) must be "minimal" and subject to EDP (Exception Doctrine Policy), and that this **may not be circumvented, eroded, or ignored by Wikimedia Foundation officers or staff nor local policies of any Wikimedia project**. The reasons and explanations are lengthy, but in short we have a free-content mission. Our exceptions for non-free content are deliberately more restrictive than what copyright law might permit. We allow some non-free images in articles (and partial-article previews) with significant restrictions, and they may appear in maintenance categories for work purposes such as investigating and cleaning up copyright issues. We don't allow non-free images to decorate links. It looks nice and it's nice to have, but "looks nice" and "nice to have" are exactly were we don't use non-free content. Special:Nearby should not be requesting or serving non-free images. Setting Special:Nearby to actively request that non-free images be included is definitely wrong. If Special:Nearby is returning non-free images then that needs to be fixed. If Special:Nearby only returns images from commons(?), then it shouldn't find any non-free images to return. However in that case the code would either be wrong and doing the right thing by accident, or it would be deliberately requesting the inclusion of non-free images as an ugly hack. Either way it is a very bad practice to leave this sort of misleading landmine in the code. It creates an impression that non-free images are supposed to appear here, and a significant risk that some future change will cause them to appear. TASK DETAIL https://phabricator.wikimedia.org/T159678 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aude, Alsee Cc: Alsee, gerritbot, Sjoerddebruin, Viveksr96, Jdlrobson, hoo, aude, Jonas, thiemowmde, Aklapper, Lydia_Pintscher, darthmon_wmde, Ayesh1234, Dibya, 94rain, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, Antohabio, QZanden, Zoranzoki21, LawExplorer, DatGuy, Devwaker, Niklitov, _jensen, Urbanecm, rosalieper, JEumerus, Ananthsubray, Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, Wikidata-bugs, Snowolf, Dcljr, Jdforrester-WMF, Matanya, Mbch331, Rxy, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
Alsee added a comment. There is a very serious error pervading this discussion. Everyone is working on the presumption that Wikidata is importing pure facts. This is false. Wikidata often imports creative works of authorship. I went to Wikidata and clicked random item, it took me a matter of seconds to find an example of Wikidata copying creative work licensed under CC-BY-SA, specifically from English Wikipedia. An item popped up for a geographical feature, listing coordinates. When I checked it on a map, the contributor selected an arbitrary and highly unusual coordinate to represent the geographical feature. In particular, the coordinates consisted of 16 digits. Approximately 6 digits of that information was factual (within the geographical feature), and approximately 10 of the 16 digits were a creative work of authorship of the contributor. I could very easily make a series of edits, adding valid coordinates to articles, and embed a watermark in my creative selection of precise location. A bot would soon come by and import my work into Wikidata. I could then prove my creative authorship in court by explaining how to read the watermark. The watermark spread across those contributions could contain the hidden text "Copyright by al...@wikipedia.org licensed under Creative_Commons_Attribution-ShareAlike_3.0_Unported_License https://creativecommons.org/licenses/by-sa/3.0/ ". Furthermore many text fields contain creative work. (In case anyone has difficulty with the concept of authorship of a string of digits, or of watermarks.) A more accurate question for the lawyers is this: Can you comment on the practice of bulk extraction from Wikipedia articles, of factual information AS WELL AS individually-short works of creative authorship licensed under CC-BY-SA , and publishing it in Wikidata under a claim of CC-0? In addition, I'd like to specifically ask: Could the assertion of CC-0 constitute Slander_of_title? Slander of title might be more serious than the direct concerns of license infringement.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, Aklapper, Huji, ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, AndrewSu, Mateusz_Konieczny, Maxlath, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193857: Support 'noreplace' keyword in {{SHORTDESC}}
Alsee added a comment.
@Pbsouthwood, I also originally thought the simple and obvious answer was to use the first description. I definitely see some ugly and backwards aspects of using noreplace. However on deep thought, noreplace is probably the right answer. Consider an infobox that tries to add an automatic description, and an editor adds a short description template somewhere below that infobox. Yes yes, that's unthinkably gross and bizarre. The reason I did think of it is because I've already seen it. The description was either below the infobox, or it was below the infobox & below the lead. Gross... but it's a wiki we gotta expect stuff like that. If we use "first description" then we'd get the infobox-auto-description. If we use noreplace then the human description can be given priority. I think noreplace is probably what we want, even if it is a bit ugly.
There's an ugly corner case though. If an article has more than one {{short description|}} template, it's going to use the last one. It may be painful trying to figure out why the description is broken if you only notice the top description.TASK DETAILhttps://phabricator.wikimedia.org/T193857EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, Tgr, RexxS, JJMC89, Aklapper, Liuxinyu970226, Pbsouthwood, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, bearND, aude, Jdforrester-WMF, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T184000: Magic word on English WP to override display of Wikidata short description
Alsee added a comment. According to the API info, it looks like a pageterms API call is doing the correct thing, returning a Wikidata value. That probably shouldn't be broken. It appears the issue is the bits of code making the API calls. They are explicitly requesting Wikidata values. It looks like the magic word description belongs under pageprops. However returning Wikidata descriptions though here would be just as wrong as returning the page description via the Wikidata API call. It looks like the options are: Abuse the Wikidata API call to return a value from either source; Abuse the page properties to return a value from either source; Have the calling code deal with both API calls; Have a new API call somewhere that isn't explicitly tied to a source; or Open a discussion on Meta and/or some of the other big wikis to consider the likely case that "silent" wikis have the same concerns and the same position as EnWiki. Then all calling code could be changed to use a pageprops API call. 1 and 2 are basically broken APIs. I hope we can veto broken APIs. 3 is gross, and should be scratched as well. Assuming I didn't miss anything, I think that pretty much leaves 4 or 5 as credible options. And in regard to #5, the fundamental reason for mess here is the plan to use one source for 50% of pageviews, and use a second source for the other 50%. (I checked the stats, EnWiki is in a close ballpark of 50%.)TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AlseeCc: TheDJ, Fjalapeno, Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T184000: Magic word on English WP to override display of Wikidata short description
Alsee added a comment. @Tgr thanks for catching my sloppy hatmaking example. Hatmaking is an illustration for a completely different serious bug - interwiki links are badly broken. 75% of the interwiki links are missing from the English article , and 75% of languages with an article are missing interwiki links to English version. However the seesaw/swing example still proves the fundamental point. Wikidata descriptions are descriptions of Wikidata items, for Wikidata purposes. Trying to put a Czech article-description in the Wikidata-description would be flat-out wrong. And using a Wikidata description as the Czech article description is going to be wrong. Wikidata descriptions commonly have a passable resemblance to article descriptions, and some clients may sloppily or carelessly use them for that purpose, but Wikidata descriptions are not article descriptions. They never were. Whoever started using Wikidata descriptions as article descriptions either made a deliberate decision that a convenient and sloppy-resemblance to "right" was better than nothing; or they were careless and didn't think through what they were doing. Either way, it's the 100th case where we could have saved a lot of headaches if the WMF had talked to the community before building the code. Can someone post a link to the relevant API documentation page?TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AlseeCc: TheDJ, Fjalapeno, Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T184000: Magic word on English WP to override display of Wikidata short description
Alsee added a comment. I'm not familiar with all of the API issues, but if this helps: The magicword Shortdesc: is actually a description of the article. The Wikidata label is a description of the Wikidata item. Someone thought Wikidata labels could conveniently be re-used as if they were an article description. But they aren't article descriptions. For example, some Wikipedia languages have an article on "Hatmaking", other languages may have an article on "Hatmakers". They are all linked to the same Wikidata item, and it's pretty much random whether the Wikidata item is "Hatmaker" or "Hatmaking". Another example, Wikidata has items for "Seesaw" and "swing". However the Czech language has a single word that covers both, and Czech Wikipedia has a single article that covers both. (The Czech article is linked to one of those two Wikidata items at random, because of a Wikidata design flaw that can't handle the correct dual-linkage.) So aside from the issue that the EnWiki community wants local control of what is functionally EnWiki content, the Wikidata label is not, and never was, a description of an article.TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AlseeCc: Fjalapeno, Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T184000: Magic word on English WP to override display of Wikidata short description
Alsee added a comment. @DannyH, if you dispute the close result then this is not the way to handle the situation. Corrected merged task.TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AlseeCc: MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, TheDJ, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T184000: Magic word on English WP to override display of Wikidata short description
Alsee updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTIONCreate a magic word to be used on English Wikipedia as an override for the display of the(and possibly elsewhere) to replace Wikidata short description in all of the places where the description is paired with English Wikipedia content, including on thebut not limited to apps, in search, and in Visual Editor's link moduleThe new magic word should be {{SHORTDESC:1946 film by Howard Hawkes}}
When displaying the short description, the display should check to see if the magic word is filled in (not blank) in the English Wikipedia article. If there is a description on English Wikipedia, then that description should be used.
If the magic word isn't used on the page, or if the description is blank, then it should show the description from Wikidata.
"Blank" means:
-- not having any description in the field {{SHORTDESC:}}
-- just blank spaces {{SHORTDESC: }}[[ https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVillage_pump_%28proposals%29&type=revision&diff=824285679&oldid=824238838 | RFC consensus acceptance criteria:]]
-- just punctuation {{SHORTDESC:.}}# **"starting with blanks, and allowing them to be filled in manually and/or by bot"**
-- just non-breaking space {{SHORTDESC: }}
In those cases, it should pull the description from Wikidata.
Once this override is live, Wikipedia editors will populate the magic word on pages where they want to override the description. If/when they write enough descriptions that it's roughly comparable to the number of existing Wikidata descriptions, we will change the system again, to only pull from the Wikipedia descriptions, and not use the descriptions on Wikidata as the default/fallback. At that point, on pages that don't have the magic word (or on pages where the description is left blank), there will be no description to display.
We're still talking about when that switch will happen -- the current plan is to switch when there are non-blank descriptions on 2 million article pages. That might happen quickly, or it might take a long time, depending on how the community chooses to use the magic word.
# **"Show no description where the magic word does not exist"**TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AlseeCc: MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, TheDJ, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T187285: Magic word on English WP to replace Wikidata short descriptions
Alsee added a subscriber: DannyH.Alsee added a comment. @MZMcBride, I'd like to first note that this task is not about "what I want". Half of the text here is copied from T184000 written by @DannyH. The other half reflects an RFC community consensus. In fact I supported DannyH's version during the RFC. I am submitting the consensus result on behalf of the community. There is clear community consensus against using Wikidata descriptions for EnWiki articles. It appears in apps, search, Visual Editor's link module, and formerly appeared at the top of articles in mobile web. There have been various suggestions for technical improvements to how Wikidata descriptions work, however the consensus is that enhancements to Wikidata descriptions would not adequately resolve the issues of using external content. Hopefully I can skip the wall-of-text summary of that debate? The RFC is linked, that RFC links to an earlier RFC, and there are months of discussions at EnWiki name Wikidata/2017_State_of_affairs and EnWiki name Wikidata/2018_State_of_affairs. There is agreement between the WMF and community to build a magicword which allows the community to define article descriptions locally. The dispute is how to get there. T184000 insists that Wikidata descriptions continue to appear on articles that lack the magicword. T184000 insists that articles with the keyword, but lacking a description value, shall continue pulling descriptions from Wikidata. T184000 also orders the creation of filters to prevent editors from creating a blank description. If we decide to blank a useless description, or we need to blank it during a BLP dispute, we would have to blank at Wikidata. And a Wikidata Admin can revert, BLOCK the EnWikiAdmin for the edit, and apply full protection on the item. T184000 says Wikidata descriptions will only be turned off once two million descriptions are created. During the RFC I opened a section explicitly to propose that approach. I supported it. I pinged all discussion participants to that proposal. That proposal tanked. DannyH disregarded the outcome and opened a task that was not requested.TASK DETAILhttps://phabricator.wikimedia.org/T187285EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: DannyH, MZMcBride, Alsee, Aklapper, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, Zoranzoki21, LawExplorer, JJMC89, DatGuy, B20180, Devwaker, Urbanecm, JEumerus, Samwilson, Tulsi_Bhagat, Wong128hk, Luke081515, Nakon, SimmeD, biplabanand, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, Snowolf, bearND, aude, Dcljr, Ricordisamoa, -jem-, Jdforrester-WMF, Matanya, Mbch331, Rxy, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T187285: Magic word on English WP to replace Wikidata short descriptions
Alsee added a comment. Not in scope of this task: It's hard for EnWiki editors to see vandalism or changes to Wikidata content: Showing Wikidata changes on EnWiki watchlists is not in scope. Locally defined descriptions resolves this issue natively. Editing Wikidata content requires going to another site: Providing a remote-editing UI to modify Wikidata content from the Wikipedia site is not in scope. Locally defined descriptions resolves this issue natively. Edits to Wikidata bypass EnWiki page protection: Removing Wikidata-Admin userrights to add/remove edit-protection on Wikidata English-descriptions and effectively assigning these rights to EnWiki Admins is not in scope. Locally defined descriptions resolves this issue natively. Wikidata content is subject to Wikidata policies and Administrative enforcement: Removing Wikidata-Admin userrights to block EnWiki users&Admins from editing Wikidata English-descriptions and assigning these rights to EnWiki Admins is not in scope. Locally defined descriptions resolves this issue natively. (Any alternate proposal for the above item(s) should be sure to include all four.)TASK DETAILhttps://phabricator.wikimedia.org/T187285EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, Aklapper, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, Zoranzoki21, LawExplorer, JJMC89, DatGuy, B20180, Devwaker, Urbanecm, JEumerus, Samwilson, Tulsi_Bhagat, Wong128hk, Luke081515, Nakon, SimmeD, biplabanand, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, Snowolf, bearND, aude, Dcljr, Ricordisamoa, -jem-, Jdforrester-WMF, Matanya, Mbch331, Rxy, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T184000: Magic word on English WP to override display of Wikidata short description
Alsee added a comment. Closed as invalid. There is no request for this task. See T187285 However to address aspects of the proposed task: The community can and will run a bot to put this keyword on all articles. Designing this to display Wikidata when the keyword is absent is little more than symbolic. That symbolism is hostile. The aggressive efforts to preemptively filter "blank" descriptions only sends an even more hostile message of active combat to thwart consensus. And it is equally pointless. There are a multitude of ways to easily circumvent the filter. It would be better if the community could just focus on eagerly getting these descriptions filled. You want people approaching this as a solution, not a foe.TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AlseeCc: Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, TheDJ, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T184000: Magic word on English WP to override display of Wikidata short description
Alsee closed this task as "Invalid". TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AlseeCc: bearND, Mike_Peel, Tgr, JKatzWMF, TheDJ, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T187285: Magic word on English WP to replace Wikidata short descriptions
Alsee created this task.Alsee added projects: Wikimedia-Site-requests, Community-Tech, Wikidata, MediaWiki-extensions-WikibaseClient, Reading-Infrastructure-Team-Backlog (Kanban).Herald added a subscriber: Aklapper.
TASK DESCRIPTIONCreate a magic word to be used on English Wikipedia (and possibly elsewhere) to replace Wikidata short description in all of the places where the description is paired with English Wikipedia content, including but not limited to apps, search, and in Visual Editor's link module.
The model for this is the defaultsort magic word -- {{DEFAULTSORT:Big Sleep, The}} -- which is used in the wikitext on the article page to determine where the page title appears on category pages.
The new magic word should be {{SHORTDESC:1946 film by Howard Hawkes}}
RFC consensus acceptance criteria:
"starting with blanks, and allowing them to be filled in manually and/or by bot"
"Show no description where the magic word does not exist"
TASK DETAILhttps://phabricator.wikimedia.org/T187285EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, Aklapper, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, Zoranzoki21, LawExplorer, JJMC89, DatGuy, B20180, Devwaker, Urbanecm, JEumerus, Samwilson, Tulsi_Bhagat, Wong128hk, Luke081515, Nakon, SimmeD, biplabanand, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, Snowolf, bearND, aude, Dcljr, Ricordisamoa, -jem-, Jdforrester-WMF, Matanya, Mbch331, Rxy, Jay8g, Krenair, MarcoAurelio___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T145522: [feature request] how to clean up redirects in sitelinks
Alsee added a comment. In an ealier post here, matej_suchanek posted a link to Wikilinks_and_redirects. As someone experienced in closing RFCs, I'd like to note that the linked discussion is a pretty clear informal consensus that some Wikidata links to redirects are valid and appropriate. If anyone got an impression to the contrary, there key here is to cut through the bombardment of the discussion by a single persistent critic. By my count the discussion was two people opposed to such links, and all six other participants supporting them. It wasn't a formal RFC, but 75% support is generally a pretty clear consensus. When redundant Wikidata items are directly or indirectly pointing to the same place, obviously they should be cleaned up. However it would be destructive to "clean up" distinct Wikidata items that deliberately point to redirects. The real fix here is to fix Wikidata's broken restriction preventing two pages from linking to the same Wikidata item, and preventing a Wikidata item from linking to more than one page. You can't arrogantly assert that English gets to define concepts. A structure-X (Houpačka) may be one concept with one word in one language , whereas another language may consider horizontal-structure-X (seesaw) and vertical-structure-X (swing) to be two different concepts. The English articles for seesaw and swing both need an interwiki links to the Czech article Houpačka, and the Czech article Houpačka needs interwiki links to both seesaw and swing. Until we can create those links, the closest thing we can do is have one of the English pages link to a redirect to the Czech page.TASK DETAILhttps://phabricator.wikimedia.org/T145522EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, matej_suchanek, PokestarFan, thiemowmde, Lea_Lacroix_WMDE, Liuxinyu970226, TomT0m, Lydia_Pintscher, Alphos, Aklapper, Esc3300, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, Zoranzoki21, LawExplorer, Wikidata-bugs, aude, TheDJ, Jackmcbarn, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T145522: [feature request] how to clean up redirects in sitelinks
Alsee added a comment. In an ealier post here, matej_suchanek posted a link to Wikilinks_and_redirects. As someone experienced in closing RFCs, I'd like to note that the linked discussion is a pretty clear informal consensus that some Wikidata links to redirects are valid and appropriate. If anyone got an improession to the contrary, there key here is to cut through the bombardment of the discussion by a single persistent critic. By my count the discussion was two people opposed to such links, and all six other participants supporting them. It wasn't a formal RFC, but 75% support is generally a pretty clear consensus. When redundant Wikidata items are directly or indirectly pointing to the same place, obviously they should be cleaned up. However it would be destructive to "clean up" distinct Wikidata items that deliberately point to redirects. The real fix here is to fix Wikidata's broken restriction preventing two pages from linking to the same Wikidata item, and preventing a Wikidata item from linking to more than one page. You can't arrogantly assert that English gets to define concepts. A structure-X (Houpačka) may be one concept with one word in one language , whereas another language may consider horizontal-structure-X (seesaw) and vertical-structure-X (swing) to be two different concepts. The English articles for seesaw and swing both need an interwiki links to the Czech article Houpačka, and the Czech article Houpačka needs interwiki links to both seesaw and swing. Until we can create those links, the closest thing we can do is have one of the English pages link to a redirect to the Czech page.TASK DETAILhttps://phabricator.wikimedia.org/T145522EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, matej_suchanek, PokestarFan, thiemowmde, Lea_Lacroix_WMDE, Liuxinyu970226, TomT0m, Lydia_Pintscher, Alphos, Aklapper, Esc3300, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, Zoranzoki21, LawExplorer, Wikidata-bugs, aude, TheDJ, Jackmcbarn, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T54564: Allow sitelinks to redirect pages to fix the 'Bonnie and Clyde problem'
Alsee added a comment. I believe discussing this as a "Bonnie and Clyde problem" has led to flawed examination and flawed arguments, due to the example cited. Wikidata was largely designed, and largely operated by that community, on the theory that there is supposed to be a 1-to-1 relationship between concepts and wikidata items, as well as a 1-to-1 relationship between wikidata items and the related articles. The flaw is that it's an invalid model. The flaw is being swept under the rug with an implicit (and arrogant) presumption that English defines reality, that English takes precedence over other languages. For example: English Wikipedia (and Wikidata) have items for "see-saw", a children's playground seat attached horizontally to a pivot point. English Wikipedia (and Wikidata) also have items for "swing", a children's playground seat attached horizontally to a pivot point. However some other languages do not consider vertical and horizontal arrangements to be different concepts. Those Wikipedia have a single article, under the single language-concept which covers both orientations. The English article for see-saw and the English article for swing both need to link to the same foreign article. And that foreign article needs to link to both English articles. Wikidata's faulty insistence on 1-to-1 realtionships causes problems for both editors and readers. An even more clear example is colors. Colors are literally continuous. It is impossible to objectively define one "right" answer for how many there are, and it is impossible to objectively define one "right" answer for where the dividing line is between colors. For example some languages do not distinguish between "blue" and "green". The English equivalent would be comparing "orangish-red" to "purplish-red". They are both "red", and the English language does not recognize them as distinct fundamental concepts. And even within English, the dividing line between "concepts" is often arbitrary or fuzzy. Within English you get the "Bonnie and Clyde problem". Is the duo the significant concept? Or do you subdivide and deal with the one story in two different places? Different Wikipedia can reasonably have one article for the duo, or two articles for the individuals, or three articles for the duo and each individual. That is a judgement call, and the right answer may be different for different purposes and contexts. The problem is fundamentally impossible to solve while enforcing a 1-to-1 relationship rule. Allowing Wikidata to link to redirects is better than nothing, but it is still a badly dysfunctional workaround. It still doesn't give readers the right interlanguage links. Having Wikidata support non 1-to-1 relationships makes things more complicated, but the world is complicated.TASK DETAILhttps://phabricator.wikimedia.org/T54564EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, Capankajsmilyo, Eugene, PokestarFan, ArthurPSmith, Pasleim, StudiesWorld, daniel, Metamorforme42, JEumerus, Harmonia_Amanda, Ash_Crow, DannyH, Agabi10, Choomaq, IKhitron, QZanden, thiemowmde, Toto256, Acer, Elitre, Sylvain_WMFr, Lea_Lacroix_WMDE, Schlum, TomT0m, Thryduulf, Rich_Farmbrough, Zppix, ChristianKl, Mike_Peel, Wittylama, Liuxinyu970226, SebastianHelm, MisterSynergy, Oliv0, JanusTroelsen, Blahma, MGChecker, MSGJ, Izno, Nnemo, bzimport, Unknown Object (MLST), DanielFriesen, Gymel, Denny, jeblad, Abraham, Addshore, SamB, Toru10, Wikidata-bugs, JAnD, Nemo_bis, He7d3r, -jem-, ValterVB, Filceolaire, Micru, JanZerebecki, matej_suchanek, Ricordisamoa, MZMcBride, Aklapper, Tgr, kaldari, Laddo, Lydia_Pintscher, Jane023, Ltrlg, JohnLewis, Fomafix, Zellfaze, Lahi, Gq86, GoranSMilovanovic, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis
Alsee added a comment. In T171027#3673060, @Lydia_Pintscher wrote: This is a hugely political issue. It doesn't matter whether Political Issues come from the community, a project manager, or President of the Planet. They wait in line when a database administrator declares an emergency: we are close of running out of space on several main database servers, breaking all of Wikipedia.TASK DETAILhttps://phabricator.wikimedia.org/T171027EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: jcrespo, AlseeCc: Alsee, awight, Matthewrbowker, Noella94, Nirmos, Stryn, Mike_Peel, Capankajsmilyo, Elitre, Risker, Peachey88, Stashbot, Finavon, WMDE-leszek, saper, Masti, Lydia_Pintscher, D3r1ck01, matej_suchanek, Ankry, Ladsgroup, Lsanabria, Josve05a, Bawolff, greg, Dominicbm, Vriullop, Jmabel, Fae, IKhitron, Johan, Herzi.Pinki, jmatazzoni, Mattflaschen-WMF, KTC, Framawiki, zhuyifei1999, Marostegui, aaron, Andrei_Stroe, Turbojet, Rsocol, Strainu, Jwh, Pyb, Darwinius, Arbnos, Jdforrester-WMF, TheDJ, gerritbot, VladXe, Kf8, Liuxinyu970226, Jay8g, TerraCodes, Iniquity, jcrespo, Reedy, Catrope, Vicpeters, Demidenko, MaxBioHazard, Aklapper, Waytogoeducation, Lordiis, GoranSMilovanovic, Adik2382, Abiyoyo, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Vali.matei, Jack_who_built_the_house, Lewizho99, Minhnv-2809, Maathavan, Poyekhali, Volker_E, Wong128hk, Luke081515, Wikidata-bugs, Base, aude, GWicke, El_Grafo, Gryllida, putnik, Steinsplitter, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T87686: Categories are metadata
Alsee added a subscriber: Jdlrobson.Alsee added a comment. @Jdlrobson: I definitely didn't assume any bad faith here, and I didn't mean to "blame" anyone in particular. Consider this my attempt to stir concepts into the idea sessions :) The reason I wound up here was from Multi-Content_Revisions (MCR), which cites this as a possible use case. I do understand why MCR (and use cases) seem like good ideas, but I think MCR is floating on a swirl of bad ideas. The key is why it's a good or bad idea. From the developer point of view it's very tempting to look at the various stuff editors do and think "I can build an app for that!". You can build a great app that does the exact task great, and efficiently, with a great interface for that exact task, and having separate structured data makes things much easier on the software side. But that turns the wiki into a big complicated pile of complicated apps. Any powerful system is going to have complexity. The question is where that complexity is located, and how it's presented. The wiki model is that everything is a page, and pages are dead-simple text files. The journey is learning the various neat things you can write in that text file. A six year old can click EDIT and start typing away. A six year old can accomplish virtually anything with a blind copy-paste from an existing page. They don't need to understand what they copied. Maybe the community has a weird attachment to that approach, but it's the approach that made wiki so successful.TASK DETAILhttps://phabricator.wikimedia.org/T87686EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Jdlrobson, Alsee, Izno, Matanya, Quiddity, Jheald, Lydia_Pintscher, Tgr, Aklapper, Acer, D3r1ck01, Wikidata-bugs, Base, matthiasmullie, aude, Deskana, Ricordisamoa, Fabrice_Florin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T87686: Categories are metadata
Alsee added a comment. Why edit in the page when you can edit outside it? Wow. That comment is so backwards. I really wish we had more overlap between the dev community and the editing community. Why would we want to turn a wiki into a big complicated hard-to-use app when we can simply edit inside the page? A wiki is just a bunch of pages, and a page is just a text file with a name and history. Dead simple. All of the complexity lies in rendering the page all of the complexity lies in learning what you can write in the text file. I can 100% write an article in notepad.exe, CTRL-V it in the edit window, and save. Why would I want a complicated app glued onto the side of the page, forcing me to do categories separately?TASK DETAILhttps://phabricator.wikimedia.org/T87686EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, Izno, Matanya, Quiddity, Jheald, Lydia_Pintscher, Tgr, Aklapper, Jdlrobson, Acer, D3r1ck01, Wikidata-bugs, Base, matthiasmullie, aude, Deskana, Ricordisamoa, Fabrice_Florin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T122806: Wikidata items for articles in the Draft namespace
Alsee added a comment. Holy crap. Wikidata should not be linking to our draft space at all. They definitely should not appear on other language wikis, as public links to a supposed English Language version of the article. Draft pages are intended as an internal workplace. Drafts can contain inappropriate content. We want draft pages to be as "hidden" as any publicly-accessible page can be. The are listed as NOINDEX for any search engines or other external scanning. Links to draft space should only be created as part of internal workflows, to develop, review, or otherwise manage the the draft.TASK DETAILhttps://phabricator.wikimedia.org/T122806EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, Matanya, JEumerus, aude, hoo, Lydia_Pintscher, Aklapper, MSGJ, StudiesWorld, Urbanecm, D3r1ck01, Tulsi_Bhagat, Izno, Matiia, Luke081515, biplabanand, Wikidata-bugs, Snowolf, Mbch331, Rxy, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions
Alsee added a comment. In T107595#2666114, @RobLa-WMF wrote: In T107595#2666094, @Alsee wrote: Did anyone consider that it might be a bad idea to start building a radical change to the editing environment without investigating whether the editing community wants this? Each of the use cases have had quite a bit of discussion, and has had quite a bit of investigation by the people proposing it. So the answer is no, no thought of investigating whether the editing community wants this. In T107595#2667512, @daniel wrote: What I take away from @Alsee's comment is that we should provide a more comprehensive and detailed overview of the use cases. So the answer is no, no thought of investigating whether the editing community wants this. You've got two editors who stumbled across (*) this project, both waving red flags that there may be a problem here. The WMF has been working on a Technical Collaboration Guideline as part of the Software Devlopment Process. In part, "establishing best practices for inviting community involvement in the product development and deployment cycle". Most development goes smoothly and everyone is happy with a lot of what the WMF develops, but there is a long history of occasional projects that result in conflict. There have been cases where the WMF believed something was obviously a good idea, but where editors had a very different perspective. The editing community may weigh the pros and cons very differently than you have. The idea of pulling categories, templates, and other things of out the wikitext is a pretty radical change. I understand you have use-case-proposals and the reasons you think they're good ideas. I'm not here to directly debate that. I'm here to alert you to the fact that this is a Big Deal. I am here to alert you that the Community may have a very different perspective, that this may be highly controversial. The proposed use cases may start evaporating if the community considers them unwanted or disruptive. I'm saying it would be a good idea to post the template-use-case and/or category-use-case and/or others at EnWiki Village Pump to find out how it will be received. (EnWiki is nearly half the global community, you can certainly post elsewhere as well if you feel broader input is needed.) The response could range from "we love it", to identifying must-have design requirements to support various workflows, to "hell no". Whichever way it goes, the time to get that information is before something is built.TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, AlseeCc: ggellerman, Alsee, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions
Alsee added a comment. My apologies, my intent wasn't to try to prove a case against MCR here. (Although I do understand why replies focused in that direction). Perhaps it would help if I shortened my previous comment: Did anyone consider that it might be a bad idea to start building a radical change to the editing environment without investigating whether the editing community wants this? Is there anyone who believes that point requires debate?TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, AlseeCc: Alsee, Pppery, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions
Alsee added a comment. Did anyone consider that it might be a bad idea to start building a radical change to the editing environment without investigating whether the editing community wants this? Ripping categories and templates and other stuff entirely out of the page? Wiki operates on an extremely simple, powerful, and flexible paradigm. A page is simply a text file. We can trivially copy-paste a page into any text editor, possibly close the browser or go offline, do anything and everything, then just paste it here and save. This is proposing turning Wikipedia into a gigantic complex app.TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, AlseeCc: Alsee, Pppery, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95026: PageImages should be able to pick Wikidata's P18 as chosen image
Alsee added a comment. Taking control of this off of local wiki would be bad. In the few cases I checked this would have either been no help, or made things worse. It's hard to imagine many cases where Wikidata would have a suitable image that couldn't/shouldn't be in the article itself.TASK DETAILhttps://phabricator.wikimedia.org/T95026EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlseeCc: Alsee, phuedx, JKatzWMF, Ltrlg, -jem-, T.seppelt, Mholloway, Anomie, MartinK, aude, MaxSem, Krenair, Ricordisamoa, Smalyshev, TheDJ, Nemo_bis, Aklapper, Winter, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
