Problem: Stub editing can be a very repetitive process
Who would benefit: Anyone who patrols and categorizes stubs
Proposed solution: Extend HotCat functionality to allow for adding stub templates or more specific stub templates
More comments: I've been using a nice script located here, but the tool is (understandably) not as slick as HotCat. It would be of great help if HotCat could be extended to easily add and remove stub templates. I already made a request for this on the HotCat talk page.
Furicorn Hi! I renamed this proposal to clarify the ask. We will not necessarily extend HotCat but we can make a similar (or better!) feature to do the same thing. I hope that's okay. Thank you. -- NKohli (WMF) (talk) 19:05, 13 November 2018 (UTC)[reply]
@Quiddity (WMF): Thanks for pointing me to that Userscript list page, lots of good stuff to review there! The usability for that particular script is unfortunately very low. One great thing is that it pops up at the top of the page. However, since it summons the entire stub list tree as you move deeper, it get very long and make it difficult to locate a stub. Contrast with HotCat functionality, which allows you to type in a category, and the search will dynamically drill down to a category. I currently use this one w:en:User:Danski454/stubsearch which has search and allows me to replace stubs using the tool, but I really want the HotCat functionality where you can click on a (+) or (-). I think I would want the tool to (1a) make stub templates appear at the top, (1b) with (+) or (-) and (2) have a search function similar to Danski454's script, but maybe with the popup menu UI style like HotCat's. I am a little loopy right now, so apologies if this is unclear. -Furicorn (talk) 05:34, 14 November 2018 (UTC)[reply]
Stub templates should die, and articles given tracking categories according to number of codepoints in content text. — Jeblad08:18, 18 November 2018 (UTC)[reply]
Problem: Students struggle with the same issues class after class. Often it is simple stuff:
They place references before punctuation
They use a LOT of capital letters in headings
They link to the inside net of their university library (1,300 instance yet to be cleaned up) -> we have an abuse filter that now stops these
They use books but do not provide page numbers
Who would benefit: Those involved with educational efforts on Wikipedia.
Proposed solution: Build a user script that those involved with teaching classes can opt to install on their students accounts. When the student hits "Publish page" the script will analyse their edit for basic concerns and provide direct feedback for the issues it finds. The student will than have the chance to make the correction and hit save again or hit ignore and publish anyway. If no issues are detected than the edit will publish normally. Each issue to be analysed should be a module within the tool so that projects and languages can easily customize for the issues they most commonly deal with.
You build it out of modules. People than select which modules they want in the version of the script they wish to activate. In Japanese the punctuation goes after the reference for example so they would have a module that would request people to do the opposite. Modules would also be potentially different for classes working on different topic areas. Doc James (talk · contribs · email) 01:31, 31 October 2018 (UTC)[reply]
Hi Doc James. This is an interesting idea and I can see it being useful. Thanks for proposing it. I have a concern about the modules you mention above. Since different languages have different rules about punctuations and different wikis may have different rules about what text is allowed and what isn't etc - the only good way to make this work would be to allow people to define their modules and define what the module checks and how. We don't have a database of punctuation issues across languages - we're quite far from having anything like that. :) This then turns into a much bigger project because user scripts are not as flexible. Do you have ideas on how to go about this? -- NKohli (WMF) (talk) 02:21, 1 November 2018 (UTC)[reply]
For the 'references before punctuation', User:Magioladitis had Yobot cover this functionality with Wikipedia:Bots/Requests_for_approval/Yobot_34. His bots are currently inactive as a result of admin/arbcom proceedings, but reimplementing this functionality with another bot should be possible, and may well be a better use of time than developing a guidance bot which serves only a small subset of editors.Dialectric (talk) 20:00, 21 November 2018 (UTC)[reply]
I imagine this could look something akin to GuidedTours: a framework that handles the UI and editing integration, and provides hook points for Javascript callbacks which contain the actual logic of parsing the wikitext, proposing a modified version, and providing text for explaining the changes. --Tgr (talk) 05:49, 25 November 2018 (UTC)[reply]
Support This sounds as if it would be helpful. If we could test what effects the prompts have, that would be good, too. HLHJ (talk) 21:07, 17 November 2018 (UTC)[reply]
Support Potentially, as a userscript, this kind of thing could be installed automatically by the Wiki Education Dashboard when a student editor joins a course. It'd be a nice way to validate the concepts of just-in-time feedback that we (Wiki Education) want to build into the core editing experience eventually. Sage (Wiki Ed) (talk) 23:17, 20 November 2018 (UTC)[reply]
Problem: enwiki Twinkle is really powerful tool, but it requires Javascript knowledge to port to other wikis (not talking about translating UI) - knowledge, that's not available in many small/medium projects (or devs, who doesn't have time for that), who would really want to use it.
Who would benefit: RC patrollers, powerusers
Proposed solution: Create a gadget with some basic(?) functionality, that is easily customizable.
It doesn't nessecarily does have to be called Twinkle, it can be a completely new product. Most wikis won't need all those very specific modules, that enwiki has. I would propose such "modules":
propose deletion of page - most wikis simply add {{delete}}-like template on the page. No daily subpages, PROD, speedy etc.
with option to add a notification on user's talk page
Basically, yes, but... As it was previously stated (phab:T110148#4024151), Community Tech team wouldn't take this as a task to fully rewrite Twinkle, so I'm trying not to put it as that. It doesn't have to be Twinkle, doesn't have to be called Twinkle, doesn't have to have all functionality of Twinkle. Edgars2007 (talk) 16:33, 5 November 2018 (UTC)[reply]
Tools like Twinkle have been associated to the drop-off in editor retention innumbers of active editors since 2007. Does anyone have any estimates as to what this proposal might do to editor retention in smaller wikis? HLHJ (talk) 04:04, 14 November 2018 (UTC)[reply]
Yes, it's argued in Research:The Rise and Decline, which also discusses other possible reasons; if anyone has a more definitive discussion of the problem, please post. Graphs below.
Proportion of newcomers that are reverted using a tool (reverted newcomers are less likely to stay, editors who get personal criticism/assistance like having their edits tagged or corrected are more likely to stay).
Proportional plot of first messages sent to users, by tool used. Note that the first tools start being used at the start of 2006, Twinkle becomes dominant in 2007, and Huggle starts a year later. The pale gray background is messages hand-written by humans.
Number of active editors and percent 1-year editor retention (which falls from 40% to 10%). Both rapid changes occur during 2005 and 2006
These are all just the English Wikipedia. Graphs for all other languages are available; some show the same 2007-ish change in editor growth, others do not. I have not seen an analysis of these changes by the rate and nature of automated tool use on each of these wikis. MMiller (WMF), do you know of any? If this proposal is accepted, I would strongly suggest that the rollout be used as an experiment to better characterize the effects of Twinkle (and the way in which Twinkle is used) on editor retention. Twinkle provides a lot of useful abilities to editors, especially for fixing vandalism. But I think it would be a missed opportunity not to study its effects. We might learn ways to improve it.
By "improvement", I mean something like this excellent proposal for tagging fixable additions. Or adding a new-user flag when users are reverting a newbie so they can respond as they see fit (maybe by linking jargon and giving more encouragement in the message). Or a way to tag excellent edits and exemplary new editors as models for newbies. Or whatever editor-retention aids the Twinkle community wants to try; some readers will almost certainly have better ideas, and I hope they will post them on en:Wikipedia talk:Twinkle. HLHJ (talk) 19:51, 17 November 2018 (UTC)[reply]
@HLHJ: I'm sorry for the long delay on my response. The "Rise and Decline" paper that you linked to is the definitive source on how automated tools have impacted the experience of new editors, with the theory being that the impersonal bureaucratic experience that newcomers get from those tools makes it difficult for them to find their place in the wikis and learn comfortably. That said, I think it is quite possible for automated tools to be designed with care such that they retain a "human touch" and do not alienate newcomers. As you said above, perhaps this proposal could be an opportunity to try out different wording and functions that could lead to better outcomes. -- MMiller (WMF) (talk) 00:56, 29 November 2018 (UTC)[reply]
Problem: When hovering over links from the references section that return to a citation's inline anchor, the text previewed is always a snippet from the article's lead, regardless of where the reference is anchored inline. It would be better if the snippet displayed text that the reference was inline to support instead.
Who would benefit: Both editors and readers would benefit from the increased functionality (when verifying an article's content) and Wikipedia would benefit, as well, as her stature, as a trusted tertiary source, began to increase.
Proposed solution: Instead of displaying a snippet of the article's lead, return a prescribed block of text immediately preceding the reference's inline anchor where the cursor returns.
More comments: I believe that this can be done without a great deal of technical difficulty.
Phabricator tickets: I am not aware of any such "Phabricator tickets".
This is a pretty hard problem to solve, as the gadget Navigation Popups uses its own wikitext parser from 2005. it also has no idea how to parse from arbitrary starting points and the whole gadget is very hard to adapt as its very old code. oh and this is a gadget, so it is not available to ppl withou an account.—TheDJ (talk • contribs) 19:51, 30 October 2018 (UTC)[reply]
Thank you for sharing these important considerations. I need to disclaim any notions of technical prowess on my part — this is truly a wish from me, and not a suggestion.
Being lay, I did not mention a few things (for not knowing the lingo, or the ropes) but I do remember that our developers released an enhancement similar to pop-ups, but editors could only use one or the other, not both. Before wishing this, I did disable pop-ups, and evaluate the version developed in house. It would be that version where I hold my best hope of seeing it come to pass. I thought that I heard it called "reference tooltips", or "h-cards", but don't really know. Nevertheless, when hovering with pop-ups disabled, our software engine produces similar information when hovering from the inline anchor, but it produces no output from the reference side. I understand that pop-ups is difficult to maintain, but hope our in house team can do something with our version. If this is a technical impossibility, like trisecting angles with compass and straight edge, the proposal would best be withdrawn. I'll yield to the powers that be, to that end. Thank you again for your interest, and your reply.--John Cline (talk) 03:14, 31 October 2018 (UTC)[reply]
Support Moral support — per TheDJ's concerns, I'm not certain this is likely or the best use of time, but it would certainly be quite nice. ~ Amory(u • t • c)11:42, 18 November 2018 (UTC)[reply]
Original title: Dans l'historique d'un article, afficher TOUTES les vrais différences vert/rose ligne par ligne
Problem:
English (translation): In the article history, the pop-up window which opens when the cursor touches “diff” only displays a small part of the differences in green/pink (except if the differences are very small) because of “truncated differences…” OR it displays entire paragraphs of text in pink strikethrough (cancelled) text, followed by same paragraphs, as edited in the new version, in green, without any way of knowing where the differences are located.
French (original): Dans l'historique d'un article, la fenêtre pop-up qui s'ouvre au contact du curseur sur DIFF n'affiche qu"une petite partie des modifications vert/rose (sauf si les modifications sont peu nombreuses) pour cause de "différences tronquées..." OU met en rose barré (= annulé) des paragraphes entiers suivis des mêmes paragraphes en vert donc modifiés selon la nouvelle version, sans qu'on sache où ont porté les modifications.
Who would benefit:
English (translation): Contributors who don’t have time to click on “diff” for each article among hundreds they monitor.
French (original): Les contributeurs qui n'ont pas le temps de cliquer sur le DIFF des centaines d'articles qu'ils surveillent.
English (translation): If this proposal is accepted and technically implemented, it would save contributors like me hours of time. Thank you in advance.
French (original): Si cette proposition est acceptée et techniquement mise en place, cela ferait gagner des heures aux contributeurs comme moi. Merci d'avance.
@AKlapper (WMF): It's asking for NavPopup diffs like this to be improved: (mouseover "← Previous edit" at...) test page, and screenshot. I don't know how complicated changing/replacing the diff parser would be, or if it's possible to change personal configuration for what the performance-truncation cutoff is (I couldn't see anything appropriate in w:en:WP:NAVPOP#Configuration (optional)). @TheDJ: quick thoughts? (is this applicable for wishlist voting?) Quiddity (WMF) (talk) 19:09, 9 November 2018 (UTC)[reply]
Merci Pols12 mais je ne sais pas ce qu'est un "commons.js" et ce qu'on peut y faire quand "Navigation popups/popupDiffMaxLines" a juste écrit : "100, an integer". Oui, ok, mais ça veut dire quoi ? il faut faire quoi ? - Mylenos (talk) 17:22, 23 October 2019 (UTC)
Perhaps, as in the mouseover for a link to an article, there should be a more…-button to replace the current display by the full difference. PJTraill (talk) 01:15, 27 November 2018 (UTC)[reply]
Problem: Available 2FA for all concerned editors. Everyone should have additional security on their account if they so desire. Why is it just limited to users with advanced permissions?
Who would benefit: Currently these user group's still vulnerable (Template editor,Mass message sender,Ipblock-exempt,Edit filter managers,Pending changes reviewer,rollbacker,autoreviewer,patroller). And all the concerned editors who dont like to be hacked.
Proposed solution: First, enable the "existing" 2 factor authentication for these user groups. Then make "Toolforge" enough capable so that it can provide "2fa" service for all editors.
I support this wholeheartedly. I even duplicated it here before realizing this had been started. But, better security should be for everyone on Wiki, not just a selected few groups. 2FA should be available to everyone. DaneGeld (talk) 19:32, 10 November 2018 (UTC)[reply]
This needs better ways to revoke and reset credentials, and also being able to test the solution to see if the user fully understands how it work. No, it is not a real solution to email a reset link or to SMS additional codes, but it could be sufficient during a one-day or one-week training phase. — Jeblad08:15, 18 November 2018 (UTC)[reply]
When my phone with authenticator on it died, I lost the ability to access my account. Will I agree all functionaires should use 2FA would need to check to see if there is resources to support all editors. Doc James (talk · contribs · email) 03:58, 20 November 2018 (UTC)[reply]
What Doc James said is the exact reason this has not happened yet: 2FA reset can currently only be done by developers, which does not scale. The problem is being worked on and 2FA for everyone who wants it is definitely the end goal. Until then, if you feel particularly unsafe, you can request membership in the oathauth-tester global group as a temporary workaround (example). --Tgr (talk) 22:30, 25 November 2018 (UTC)[reply]
Hi Tisza Gergő . I've seen your contribution at phabricator. Highly appreciate it. Please give me some info. What's the current status of phab:T195207 ; phab:T180896 & Special:DisableOATHForUser ? What's it actually mean? Does it mean we implemented a "Special page" but it wont work until some specific criteria is fulfilled (triage)? Am i missing something?
whats the most viable solution for these problems, you think?
@Ahm masum: the special page works but there is no limitation on its usage so only extremely highly trusted users can be given access to it (stewards, at best; maybe just staff). IMO that's not good enough for wide deployment and the page needs to be made less powerful (I'm not really involved in the decisionmaking about OATH though so that's just my personal opinion). But understandably people are more worried about making sure that the user who already can use 2FA actually do (since the hijacking of a privileged account is much much more problematic than the hijacking of a couple or even many non-privileged ones), so fixing the special page is lower priority. --Tgr (talk) 18:34, 27 November 2018 (UTC)[reply]
Anyone can already get 2FA access by asking on SRGP. We could make a separate page for requesting 2FA access if needed, maybe one that's simpler where you just add your username (or click a fancy js button that does it for you) and then stewards can assign based on that. The page could also include all the required reading and warning to save the scratch codes. – Ajraddatz (talk) 01:43, 26 November 2018 (UTC)[reply]
Just a heads up that SMS 2FA will not be implemented, it's been against best practices for years because it's very insecure [2], never mind having to deal with saving personal information such as peoples mobile phone numbers. Reedy (talk) 23:33, 6 December 2018 (UTC)[reply]
I understand , as a question of better security , "foundations" current focus is the "advanced user groups". Of course; the hijacking of a privileged account is much much more problematic than the hijacking of a couple or even many non-privileged ones. So here's some idea that i got (inspired from TheDJ) so that both parties could be happy & it won't cost WMF stuff's valuable time.
proposed solution for advanced user groups (just thoughts):
In the "simple 2fa" make a option so that advance users can save their "Emergency tokens/scrath codes" in another location/device (it can be dropbox , lastpass or Keeper). As a additional security give them the ability to "make their own security question & answer's ". It could be stored in the same location. It'll only required when he'll make a "reset" request.
Give them a web interface to request a reset . it could be a special page like "Special:ResetRequest" (SP:RR), similar to Special:DisableOATHForUser or it could be a "pop up" similar to those of fb/googles (as a part of mediawiki software). it could have a "dropdown menu" so that he can select his netive wiki & known admins. it could also have a "textbox area" where the user will write down something & try to prove his identity.
Make that "interface/pop up" conditional , similar to those of fb/googles so that most of the hacker couldn't even make a request.
User needs to enter his name and password to initiate request.
Check if user knows his password
Check if verified email address and password were not changed recently (last 30 days?)
Check if user knows his correct "security answer".
Log if user was still logged in when making the request
Log if request was initiated from known device's,browser or ips.
After all these criteria is fulfilled , the request will be automatically posted in two different place's . one will be the village pump (his netiv wiki) & the other will be the META (Steward_requests/Permissions#Removal_of_access). only after the the local community confirmed his identity , the local admin will ping a steward & he'll made the decision (by executing Special:DisableOATHForUser).
Proposed solution for all the non privileged editors (just thoughts):
Like all the other popular web entity's (Fb/G) , we could make a SMS based authentication as a "Optional Beta Features". Though it's not the most secure way but we must agree that it make the user feel more safer then before.
Like all the other popular web entity's (Fb/G) , we could make a "Saved Device & Login Notification" feature as a "Optional Beta Features". when someone try to login from a unknown device user will get a login notification & SMS.
We could make a cryptographic feature similar to Fb's "Encrypted notification emails" . as a "Optional Beta Features" it'll make the reset & notification email more secure even when the email is compromised. mediawiki could have a function to generate "OpenPGP Public Key" like the way "igolder" do & it could be saved in another location/device (it can be dropbox , lastpass or Keeper).
Most of the suggestions here have nothing to do with the actual wish as stated up top, but FWIW, SMS notification is T150902, and encrypted emails is T12453. --Tgr (talk) 07:04, 10 December 2018 (UTC)
Oppose I think that as it is 2FA is not really robust enough to be allowed for everybody, we still have issues with people getting locked out of their accounts. That and I am generally wary of security measures that require a lot of instructions to follow. Jo-Jo Eumerus (talk, contributions) 10:07, 17 November 2018 (UTC)[reply]
Strong oppose Per Jo-Jo Eumerus, primarily. 2FA over here is hands-down the worst of all I've been used and an aggressive pushing of 2FA (though optional) will lead to more registrations and consequently, more lock-downs. If anybody has a profound interest, he/she can easily request at Steward's Noticeboard (over Meta) to install 2FA on his/her account.Winged Blades of Godric (talk) 15:42, 17 November 2018 (UTC)[reply]
Support Better security should be a priority for all of us, not just those with specific tasks to undertake or roles to fulfill. Every user should be able to choose to use 2FA DaneGeld (talk) 22:47, 18 November 2018 (UTC)[reply]
Oppose While this is a great idea in a security aspect, unless they make a better system to reset 2FA if the scratch codes are lost, I say dont do this. As of right now (as far as I recall) the Wikimedia operations team has to reset 2FA if scratch codes are lost therefore giving anyone access to 2FA could lead to a huge backlog of requests to reset 2FA Zppix (talk) 22:18, 28 November 2018 (UTC)[reply]
Problem: Wikipedia Press coverage is currently tracked manually and haphazardly across individual language wikis, or not at all in many cases. For example on Enwiki, the news stories are first listed in one place (manually) then listed on the article talk pages (manually) and often not in sync or consistent formatting and limited to Enwiki.
Who would benefit: Anyone interested in knowing when Wikipedia is mentioned in the press. Such as for gathering statistics, making reports, academic studies.
Proposed solution: A central database and interface for listing notable mentions of Wikipedia in the Press, in any language. It would have an API so that bots and tools can access the data. An example bot application would be to update article talk pages that they were mentioned in the press (the bots would be language-specific and not part of this proposal). The database would have standard fields such as for a regular cite-web eg. "url", "title", "work", "language", "date", "author" etc.. a field for related Wikipedia articles, and a quote. The database interface would support multiple languages.
@GreenC: I think this would be suitable for Wikidata, since items may qualify as notable if they are structurally useful (e.g. if they are used as sources). An item could be created for each source, and then the query service could be used to find articles about e.g. the Croatian Wikipedia, or WMF projects other than the Wikipedias. I'm not sure if that would be a good task for Community Tech, though, since the item creation could be done by a single user. Jc86035 (talk) 15:16, 30 October 2018 (UTC)[reply]
Yeah it might make sense to use Wikidata as a backend database, but what about a front-end page where users can enter the data and be landing point with instructions. -- GreenC (talk) 15:25, 30 October 2018 (UTC)[reply]
@GreenC: I don't really understand what this proposal is asking for. Would this be a database of Wikipedia articles about news stories or news stories about Wikipedia? On English Wikipedia, "In the News" is the former and "In the Media" is the later. Kaldari (talk) 04:40, 31 October 2018 (UTC)[reply]
@GreenC: I'm not sure if it would be useful to have a front-end page specifically for adding sources. Usually Wikidata items are imported in the QuickStatements format (Q12345|P31|Q5707594|P50|Q5568842), and I'm guessing it could be difficult for users not experienced with Wikidata to fill out something like this. Given that it's fairly likely that this proposal (or any given proposal) won't end up in the top 10, I think the easiest solution would be to have a wikitext table with columns for each Wikidata property, where users can add new articles, and then once in a while a Wikidata user comes along and imports the whole table into Wikidata. Jc86035 (talk) 05:46, 31 October 2018 (UTC)[reply]
That solution might work but it has problems with languages because a user who only speaks Bulgarian might have trouble editing a wikitable that is in English. If the suggestion is each wiki-language have its own table that is kind of what we already do and it's not very good and it would be very hard to co-ordinate across 300+ wikis to make them all consistent for import into Wikidata. The idea is a single universal front end for adding these sources into a database that can generate reports, export via API etc..
@GreenC: But then you would have to translate the front-end into all those languages? I think if you were to host the table on Wikidata itself it would largely take care of the translation problem, since the property template is already automatically translated based on the user's interface language (and the existing translations for each property's name). Most of the table itself probably wouldn't need translation (e.g. dates, URLs, authors' names, published in, relevant Wikimedia projects). You could also use d:User:ListeriaBot or something like that to auto-generate tables of relevant articles. Jc86035 (talk) 17:18, 31 October 2018 (UTC)[reply]
Ok your saying use Wikidata because of this, but don't use Wikidata because it's too complex for most users. I tend to agree Wikidata probably wouldn't be widely used if that was the main interface for adding links. Wikidata is basically a database level it has limits, it's fine to use Wikidata as a backend database. -- GreenC (talk) 21:03, 31 October 2018 (UTC)[reply]
IMHO there isn't really anything inherently wrong with setting up a whole database to store new data, although if Community Tech doesn't do it then someone else would have to write the code (you would probably have to set up a project on Tool Labs with an OAuth web interface), and then someone else would have to deal with monitoring it for junk and uploading the data to Wikidata every few weeks. An alternative would be extending one of the existing Wikidata user scripts (for filling in item data) to work for news articles, but generally Wikidata script UIs are designed with the expectation that the user knows exactly what they're doing so it would again have the learning curve issues and would probably result in input errors. Jc86035 (talk) 10:24, 1 November 2018 (UTC)[reply]
Support It's definitely a problem. I'm not technically literate enough to really judge your proposed solution, but as a layman I'll support any proposed solution of this problem until something better comes along. Bobnorwal (talk) 13:46, 18 November 2018 (UTC)[reply]
Problem: The problem is the time it takes to update the properties of a series of established articles that are linked by a specific property, e.g. an infobox property on the James Spence Medal article series and need to update to add additional that content.
Who would benefit: Anybody who would like to update a series of articles quickly with additional properties, without doing it manually, which is a real joy killer and completely unproductive, or having to go outwith Wikipedia to use it.
Proposed solution: A Microbot for Mundane Tasks, which can be quickly configured to select a series of articles, perhaps via a category, if available, or by manual selection, select the property that is needed updated and apply the property.
Manual update to article properties, e.g. adding an infoboxes property and value, or a category for articles in a series is extremly unproductive, slow and prone to mistakes. There is other methods to achieve the same result within WP, of course, the Bot process/and manufacture and AWB. Both have their limitations and specialisms. The Bot process/manufacture/release/test cycle is slow and bureaucratic, and is designed for large changes, across hundreds of articles. AWB can accomplish the same process, but is outside wikipedia, is also complex, and designed for very large scale updates in the thousands. Whereas the AWB work on the large scale, and bot framework works works on the mid to small, there is truly no small scale utility that update <50 articles at time, and that is an upper bound.
The whole point of the system is would be limited functionality. Ideally it would be quick to configure, to use and to check the work has been completed.
The ideal utility would have a collection of predefined scripts that would have to be approved upfront.
For example, adding the honorific tag to the James Spence Medal articles and interrogating each article in turn to determine if each one was Professor Sir, or Professor, or Sir, and adding to the infobox. Fundamentally a regexp search, then a write to the infobox to place the attribute with result. Tiny script.
Stuff like awards is probably more waiting for Wikidata support of queries on the clients as well as perhaps better integration of bots between Wikidata and the other wikis. --Izno (talk) 02:31, 6 November 2018 (UTC)[reply]
Oppose I don't understand what exactly is sought over here.This can be easily done via AWB which can be made to run on any number of articles without an upper/lower bound. I'm willing to look at the case and make an AWB run, if the OP approaches me over en.wiki.Winged Blades of Godric (talk) 15:33, 17 November 2018 (UTC)[reply]
Support I'd support a web-based AWB. But, that might be too big for a single Wishlist task, and also comes with a need for long-term maintenance that would need to be accommodated somewhere, in WMF, or with multiple active volunteer software engineers. Krinkle (talk) 01:29, 22 November 2018 (UTC)[reply]
Problem: Twinkle is a very nice tool that can be used for many convenient operations. However it cannot be used in the mobile web interface, users who would like to use Twinkle on their mobile device now would need to switch to "desktop view" which have small font size and is difficult to read. Hope that a mobile version Twinkle can be made in upcoming future.
@Jimmyshjj: Currently gadgets (such as Twinkle) are not supported on mobile (mainly because of the catch-22 that most gadgets aren't written with mobile support in mind). Thus it's unlikely that Twinkle itself will be made available in mobile. It's entirely possible, however, for the WMF to build something similar to Twinkle that would work in mobile (and hopefully not be limited to English Wikipedia). Twinkle does a million things though. Please specify which Twinkle functionalities you want the most so that those could be prioritized. Kaldari (talk) 17:47, 2 November 2018 (UTC)[reply]
@Jimmyshjj:翻譯信息：現在Twinkle等小工具因為編寫時沒有考慮到流動版本支援，並且反之亦然，所以其本身現在並不支援而未來也不大可能支援流動版。但是可以做的是，另建一個可以在流動版上用的類似Twinkle的新工具。在這情況下，由於Twinkle本身有很多不同的功能，所以請指明你最想要用的Twinkle功能是什麼以便在實行時可以安排優先順序。翻譯由C933103 (talk) 21:01, 6 November 2018 (UTC)提供[reply]
@Kaldari:Thanks for responding.@C933103:（谢谢您的翻译，帮忙再翻译下，英语不好，谢谢）如果说优先顺序的话，那么提存废讨论，提报关注度，提报侵权，快删等除了在页面上挂相应模板外还必须在其他的相应进行编辑（中文维基是这样，英文维基应该差不多吧），需要经常切换，十分不方便，希望能先出（其实感觉twinkle的功能都很常用）。但如果有其他比较容易移植到移动版的功能能先出也是可以的。-Jimmyshjj (talk) 04:45, 7 November 2018 (UTC)[reply]
TL @Kaldari:: In term of priority, operations like submitting articles to deletion discussion/notability/copyright violation/speedy deletion that requires additional edits on top of putting templates onto relevant pages are rather inconvenient without Twinkle as editors would have to switch between different pages to complete the process, and thus it would be nice if they can be supported first. But if there are other functions that can be ported to mobile edition more easily then it's also okay to have them first. TL by C933103 (talk) 05:22, 7 November 2018 (UTC)[reply]
It would be very nice if Twinkle can be internationalized. However, doing that with the current code seems difficult to say the least. A complete overhaul of the code would be required to make twinkle in it's entirety workable for all wikis. Discussion on the topic can be found at issue 129 on github and T110148 at phabricator. As far as I can see, a kind of framework may be created allowing GUI based creation of Twinkle modules which offer separate functionality. The GUI could be along the lines of the current Twinkle Preferences panel, and would allow to edit/create javascript objects corresponding to Twinkle modules. The underlying code to do the actual work could be created and maintained centrally (at meta maybe?) and the module JSON objects could be wiki-specific or user-specific. Then for a wiki to migrate Twinkle would be as simple as importing the JSON object page from another wiki and edit it using the GUI to customize the module to their wiki's needs. A fresh project using conceptual elements from the current Twinkle would probably be easier than rewriting the current code.--Siddhartha Ghai (talk) 07:32, 4 November 2018 (UTC)[reply]
@Gryllida:I have tried the timeless skin(using Chrome browser on my android mobile phone), however, I found that the font size is really small(if it' necessary, I can upload the screenshot.). I don't think it is convenient to use it, for I need to zoom in or out from time to time. By the way, I'm sorry that I didn't reply immediately, cause I didn't get the mention, if it's necessary, please {{ping}} me, thank you very much.-LabMem No.SHJJContact Me10:27, 24 November 2018 (UTC)[reply]
I note there are likely four parts to this request:
Determine the "machine readable" format that will be used. Is there an existing standard that could be used, or do we have to invent something?
Create a DiffFormatter subclass that generates that format.
Update the wikidiff2 extension to be able to output structured diff data, either in a format that can be handled by DiffFormatter or in the "machine readable" format directly.
Adjust exiting code to expose the structured output via the API.
The problem I want to solve is that I want to perform analysis on the content added or removed. As for the output - I can work with something like this, although the text of the initial revision should also be returned for completeness. The refactoring required for this task will also knock out the technical debt preventing phab:T104072, phab:T117279 and phab:T38902 (moving MobileDiff into core, and making it available through the API) so there are more use cases than that given here. MER-C (talk) 19:39, 31 October 2018 (UTC)[reply]
On benefit: Yeah, various applications would need such an interface to inspect and analyse edits.
In rECHO/DiscussionParser.php the interpretDiff() might enjoy a robust access rather than current scraping.
On output format:
JSON or XML or best both, when on workbench anyway.
The contents will be ruled by current wikidiff structure. Other systems would be possible, if collected information is not directly sent to output stream.
Simply an array of difference groups, each containing the same information as visible by two column output today.
Each group consisting of two objects, before and later.
Each object with line range, recently suggested: last detected headline, and Array of paragraphs.
Each paragraph with +/- state, and single line content, if any.
Each line content as an Array of tupels, each tupel of changed/unchanged flag and string (escaped according to output format).
The same as HTML today, just in different syntax according to JSON or XML.
The diff itself needs to be wrapped by some informative data:
Both revID involved.
Method/structure, currently constant wikidiff2 but may be subject to changes over decades.
The wikiID (can be derived from request URL, but for sake of completeness).
Other information, if present anyway, like pageID or nick or timestamp or page name, but these may be derived from revIDs later.
On special features:
An API request might provide control information, like number of paragraphs ahead and after, which are constant values for HTML special pages, but parameter values numContextLines already.
A research application might drop paragraphs around which are helpful for human readers to identfy the context.
On implementation efforts:
Unfortunately the 15 years old procedure does not create a complete diff object first, then starting output formatting.
Formatted output is collected immediately when each diff is found.
Otherwise the entire output object could be just thrown into a serializer for JSON or XML.
The two column output is formatted by TableDiff.cpp today.
Two copies of this need to be made, JsonDiff.cpp and XmlDiff.cpp.
Then appropriate atomic syntax is to be generated like HTML, with proper encoding of some " and < characters.
The stream needs to be wrapped into output head and termination, and usual administrative business.
Note that the diff engine should not generate JSON or XML directly. It should generate a data structure built out of PHP associative arrays and other PHP native types, which the API will then turn into JSON, XML, or serialized PHP based on the 'format' parameter as it does for every other API request. Anomie (talk) 15:54, 5 November 2018 (UTC)[reply]
Support as it seems to have a lot of applications. Anything that makes the Community Tech Team's future work easier (not to mention other people's) seems like a good idea. It might promote some bad reuses, too, not sure if anything can be done about that. HLHJ (talk) 04:01, 22 November 2018 (UTC)[reply]
Support Liuxinyu970226 (talk) 03:42, 17 November 2018 (UTC)
Oppose Ciao • Bestoernesto • ✉ 00:59, 28 November 2018 (UTC)
Proportion of newcomers that are reverted using a tool (reverted newcomers are less likely to stay, editors who get personal criticism/assistance like having their edits tagged or corrected are more likely to stay).
Proportional plot of first messages sent to users, by tool used. Note that the first tools start being used at the start of 2006, Twinkle becomes dominant in 2007, and Huggle starts a year later. The pale gray background is messages hand-written by humans.
Number of active editors and percent 1-year editor retention (which falls from 40% to 10%). Both rapid changes occur during 2005 and 2006
.jpg)
Strong oppose Per Jo-Jo Eumerus, primarily. 2FA over here is hands-down the worst of all I've been used and an aggressive pushing of 2FA (though optional) will lead to more registrations and consequently, more lock-downs. If anybody has a profound interest, he/she can easily request at Steward's Noticeboard (over Meta) to install 2FA on his/her account.Winged Blades of Godric (talk) 15:42, 17 November 2018 (UTC)
