Talk:Community Tech/Who Wrote That tool/Archive 1

Add topic
Active discussions


Hi! I like the proposed mookup; it's simple and easy to understand. The only thing I don't like is «On a given page, the user can click a button to enter the "Who Wrote That" mode»; this will be the first button on a content page (at least that I cas see now). Instead of this, in order of preferences:

  1. a link in the "Tool" sidebar
  2. a button on the "History" of the page
  3. a tab at the top of page (near "Edit", "History", "Move", ...)

--β16 - (talk) 08:50, 21 February 2019 (UTC)

@Beta16:, thanks for your feedback. We still haven't decided what the best way for activating the feature will be. There are several options, as you mentioned. A link under the "Tools" section is indeed our top choice right now (see mock design). I didn't want to distract from the actual feature so I did not post that mock here. Once I get feedback about the key features, then I will gather feedback from our designers and engineers about the best placement for that and share on the project page. Thank you. -- NKohli (WMF) (talk) 21:10, 21 February 2019 (UTC)
Pretty much as aboive - this is actually a lot better than I was expecting, given how clumsy the old tool was. JzG (talk) 23:42, 21 February 2019 (UTC)
I agree with both of the above. Also, please keep in mind that JavaScripts and CSS can operate on "objects" in the left and top toolbars, to arrange them as people want, so this is the most flexible approach. Anyway, I want to be clear that I agree also with "this is actually a lot better than I was expecting", not just that I agree with ideas on how to implement it. Good work!  — SMcCandlish ¢ >ʌⱷ҅ʌ<  03:52, 22 February 2019 (UTC)
Like the new name. Mockup looks reasonably intuitive. A dropdown option in the "view history" tab seems a good place to activate from. Information in popup looks useful, but it is not clear whether the highlighted text is from the diff (all the changes made in that edit) or only the surviving text from that edit.
The amount of information looks OK. If you have the Username, links to talk and contributions should be trivial. If you have the diff, the timestamp should be trivial. Without the username and diff the whole thing seems pointless, so I don't see how less information is really an option. Also dont see what additional information might be useful, but accept that you might find some.
Would this tool work on historical versions, or only on latest version? Reason is that if somene had corrected a spelling error in the selected word, the corrector of the spelling error is not generally the user one would be looking for. · · · Peter (Southwood) (talk): 04:54, 22 February 2019 (UTC)
@Pbsouthwood: The idea is that we highlight all the text by that same user in the article. The darker text is from the edit which added the specific word the user clicked on. The lighter text is from other edits by the same user. About the latest versus past revisions, I am not sure I understand the reasoning. How would one find out the spelling error if it was already fixed? Do patrollers normally go to old revisions to find problems which have been fixed in the latest revision? I am not familiar with their workflow so understanding this would be helpful. Thank you. -- NKohli (WMF) (talk) 17:31, 25 February 2019 (UTC)
Suppose editor A adds some content that I want to check up on, but misspells the word I want to check. Editor B comes along and fixes the spelling error berore I look for who wrote the contentious word. Do I get only the word that editor B corrected, or can I go back to the version before the correction and find out who put in that word and what else they wrote? Cheers, · · · Peter (Southwood) (talk): 19:50, 25 February 2019 (UTC)
@Pbsouthwood: Ah, okay. My understanding of the API is that it doesn't let us find the history of a specific word but it does give us something called a "conflict score" which can tell us if a word has been edited by multiple people. I will look into whether it will be able to give us the info we are seeking. -- NKohli (WMF) (talk) 23:26, 25 February 2019 (UTC)

Language and time

Hello, will the tool be available only in English, or some work can be done to provide other interfaces?

I see time in UTC, for me it would be better to use my local time. Is is possible? --Dalka (talk) 05:22, 22 February 2019 (UTC)

I assume the tool will work with text strings. The language should not make any difference, and the user-interface should be trivial to translate, so I would be surprised if it is not made available in any/all left to right languages. For right to left languages I do not know enough to comment. Local time setting should also be a minor tweak. Getting the tool to do what it says in the specification is the main job. · · · Peter (Southwood) (talk): 09:01, 22 February 2019 (UTC)
Cool tool! Can't wait till it's available on as many wikis as technically possible. @Peter S: why it would only work on LTR-languages? If designed, developed & tested well enough there should be not much (if any) difference in working for all supported languages. Klaas `Z4␟` V:  11:29, 22 February 2019 (UTC)
If you read what I said you will see that I have no idea if RtL languages would be a problem or not, so specifically excluding them from my opinions. Cheers, · · · Peter (Southwood) (talk): 12:28, 22 February 2019 (UTC)
@Dalka, Pbsouthwood, and KlassZ4usV: Hello. The tool will rely on an external API service and the wikis we can make it available on will depend on that. Currently, the API only supports five projects and we are in conversation to expand it to be available on other projects. This will be a gradual process and we will be reaching out to wikis to gauge interest over time. As for the interface language itself, there are a few different possibilities. I will be updating the project page as we talk about the project in the team and the details become clearer. -- NKohli (WMF) (talk) 00:26, 23 February 2019 (UTC)
@NKohli (WMF):, Thanks for clearing that up. Are there any other known limitations/constraints that might be useful to make clear at this point? Cheers, · · · Peter (Southwood) (talk): 07:13, 23 February 2019 (UTC)
@Pbsouthwood: I believe there are some other technical limitations that will surface as we narrow down on our implementation approach on this project. I will be sure to flag them as they come up. -- NKohli (WMF) (talk) 17:34, 25 February 2019 (UTC)
That usually happens. So nothing that is known that you think we should know? · · · Peter (Southwood) (talk): 19:54, 25 February 2019 (UTC)
@Pbsouthwood: I can't think of anything else right now. Not a lot of details about the project are known or well understood at the moment. -- NKohli (WMF) (talk) 23:27, 25 February 2019 (UTC)

Search "Who Deleted That"

Is it possible, having an old revision, find who deleted a quote - between that and actual revisions? --Dalka (talk) 11:02, 24 February 2019 (UTC)

@Dalka: My understanding from the existing api is that it does not allow look up for deleted text. This might change, as we talk with the API maintainers. I will keep you posted. Thanks Dalka. -- NKohli (WMF) (talk) 17:36, 25 February 2019 (UTC)


  • When I look at edits on my watchlists the time of the edits is shown in my local time. I see no reason to show the UTC time in the blame tool.
  • It's not immediately clear whether clicking talk brings you to the talk page of the user in question or whether it brings you to the talk page of the edit. I would prefer the text in the popup to be "Foo(talk|contribs‎) created the edit on 08:50, 15 February 2019. Show diff"
  • In cases where the edit in question was reviewed I would want to see that information "Alice(talk|contribs‎) created the edit on 08:50, 15 February 2019. Bob(talk|contribs‎) reviewed the edit on 11:50, 15 February 2019. Show diff" (For Wikis like dewiki that have approval, that information should be shown analogous by replacing reviewed with approved.
  • I don't think that the button/link should be placed on a regular page. I would add the button in the edit mode of the page. ChristianKl❫ 15:13, 3 March 2019 (UTC)
@ChristianKl: Thanks for the feedback! Replies below:
  • I will look into showing the local time. We put UTC in the mock because I am not fully certain what the API returns to us. Hopefully it is not a lot of work to offer the local time.
  • Good point about clarifying the text to indicate it will take you to the user talk page. I will relay that to the designer.
  • Showing review status for an edit is going to be challenging, to say the least. That information is not stored in a way that is easily accessible by this tool. In addition, pulling that data will make this tool slower - i.e. the popup will take longer to load. I'm afraid it's not straightforward include that information.
  • About placing the button on the edit mode of the page - do you mean that the popups should be shown when a user clicks on a word in the VE/standard editor? Note that in the editor there are already tools like syntax highlighting that "take over" the wikitext and to add one more JS tool to the mix there will be problematic.
Thanks again. This is very helpful. -- NKohli (WMF) (talk) 20:42, 6 March 2019 (UTC)
I don't get why it's complicated to get the review data. I would expect there to be a database that can be queried with the edit-id and that then returns the data. Would that take longer then say 50ms? I think it's beneficial to show who reviewed an edit given that a person should be partly responsible for the content they reviewed.
I would put a button in the edit-mode to toggle blame mode being activated/deactivated. The benefit would be that it doesn't add complexity to the page that displays articles. ChristianKl❫ 10:02, 8 March 2019 (UTC)
ChristianKl The complication with review data is that it's only stored for recent-changes so there won't be data for revisions older than 30 days. I talked with other people on the team and their opinion is that different wikis also have different workflows around revision patrolling. Customizing this to work for specific projects will be a very big task.
About putting the button in edit mode - do you imagine the text highlighting happening inside the editor when a user wants to see who added a piece of text? Do you think that will interfere with syntax highlighting?
Thanks. -- NKohli (WMF) (talk) 19:07, 14 March 2019 (UTC)


Hope there will be an API interface so bots can access this information. They currently search revision by revision, but it is not easy and expensive. A hook to this tool would be fantastic. Either way looks really great and wish you the best of luck. -- GreenC (talk) 15:52, 9 March 2019 (UTC)

@GreenC: The way this tool will work is that it will utilise existing WikiWho APIs. This is a third-party API maintained by the GESIS – Leibniz Institute for the Social Sciences. The APIs are freely available for everyone to use so bots can already access this information if they want to. -- NKohli (WMF) (talk) 19:11, 14 March 2019 (UTC)

More feedback

Hi. I like the mockup. I look forward to a working tool.

I also wonder how "what's wrong with existing solutions" is still an "open question". To the best of my knowledge there are no working existing solutions. (There were, in the past.) So, are you actually still wondering what's wrong with existing solutions, or is the "open questions" section just out of date and in need of editing? Ijon (talk) 15:00, 18 March 2019 (UTC)

@Ijon: Hello. It's not an open question anymore. I didn't get around to updating that section yet, like you guessed. To my knowledge, there are a couple of solutions that currently work to some extent including WikiBlame and WikiWho/WhoColor scripts. We will be building this project off of the latter service. -- NKohli (WMF) (talk) 20:11, 18 March 2019 (UTC)
Great, thanks! (WikiBlame did not work at all, when I last tried it, about half a year ago.) Didn't know about WikiWho. Ijon (talk) 20:20, 18 March 2019 (UTC)

See also for reference; [[:de:Benutzer:Atlasowa/edit history visualization. I especially like and use de:Benutzer:Atlasowa/edit_history_visualization#Schnark_artikel-statistik:

Schnark artikel-statistik zu Artikel Inversor von Peaucellier, ältere Version des Skripts)

Hope this helps, NKohli (WMF). Would love to have this in default wikipedia! --Atlasowa (talk) 21:26, 29 March 2019 (UTC)

That is helpful. Thanks, Atlasowa! -- NKohli (WMF) (talk) 00:39, 30 March 2019 (UTC)

Feedback - Alsee

Multiple people have mentioned time. In order to match timestamps from history and elsewhere you need the time based on Preferences/Appearance/Time_offset setting. I'd presume the API gives you that automatically.

Your rough mockup looks like it's based on the article-read view. I'd also like to be able to search from the wikitext editor. There's a lot of content in an article that isn't accessible from read-view. In fact earlier today I was manually hunting down who added __NOSECTIONEDIT__ - that text isn't visible anywhere except wikitext view. Alsee (talk) 15:14, 21 April 2019 (UTC)

@Alsee: Sorry for the delayed reply. While this feature will only work on the article page (time constraints), I know that MusikAnimal has plans to make a version for the editor that would work for your use case! -- NKohli (WMF) (talk) 22:40, 19 June 2019 (UTC)

Case sensitive?

Will it be possible to toggle between case sensitive or not? Thanks in advance, Ottawahitech (talk) 15:26, 9 May 2019 (UTC)

@Ottawahitech: It will work by clicking on the text on the page so it doesn't matter whether it is case sensitive or not. :) -- NKohli (WMF) (talk) 22:38, 19 June 2019 (UTC)

Help us test the prototype

Hey 👋🏽 I am the designer for the Who Wrote That tool, and I've been working on a prototype based on the wireframes and the feedback we've received for it. We'll be doing a round of usability testing using these prototypes and we'd would love to get your feedback on it.

We'll be using to get structured feedback and reactions on the prototype. We'll also be posting the prototype here for open feedback. If you're interested in participating in the usability test (it would be really helpful for us if you do), you can leave your email address using this [ form]. We'll use it only to invite you to the test. Thanks! --PSaxena (WMF) (talk) 10:49, 22 May 2019 (UTC)

Looking for feedback

@Beta16, JzG, SMcCandlish, Pbsouthwood, Dalka, KlaasZ4usV, ChristianKl, GreenC, Ijon, Atlasowa, Alsee, and Ottawahitech: Pinging everyone who has participated on this page in the past. My apologies if I missed anyone. I recently posted a link to the interactive prototype we have for this tool on the project page. To activate it, follow the pop-up box and click on the Who wrote that link under the Tools menu in the sidebar. Then either click on the word Henry (middle of second paragraph) or Mother (last line of second paragraph) to see how it will work. In implementation, clicking on any word will show you authorship information, but for the mockup we couldn't do it for every word. The prototype is only to give you an idea for how it will work. There is definitely scope for improvement. Note that the tool will be enabled as a browser extension. Looking forward to hear your feedback on the prototype and activation/deactivation process for the tool. Thank you. -- NKohli (WMF) (talk) 22:48, 19 June 2019 (UTC)

  • Works for me. Easy to initiate, easy to understand, functional. If it highlights the block of text in orange, what does clicking on the word do that is already visible? -- GreenC (talk) 01:18, 20 June 2019 (UTC)
  • I have a few fewback items:
    • The blue bar should not block access to the History, View_source, and other links. In particular I might want to right-click one of those links to open in another tab, to better investigate and understand the situation.
    • Having the date (instead of the usual timestamp) in the popups immediately struck me as odd. Having the standardized timestamp everywhere is a very familiar visual pattern for editors. Just showing date is shorter and in most cases it would be fine, however for example if I am working from the History page in another tab then I need the full timestamp to easily locate that edit in the history sequence. There could be a hundred edits on that date, with fourty randomly intermingled edits by the named person.
    • The popup doesn't feel complete. I compared the popup info to the pattern of info&links appearing on a row of the History page, as well as the pattern of info&links appearing at the top of a diff:
      • The username on the popup should follow the standard pattern: Name (talk | contribs). This is the familiar pattern, and the contribs link is particually significant for IP edits.
      • Both other locations I looked at include the edit summary. Adding edit summary to the popup seems reasonable. It's probably not important in most cases, but sometimes it might add helpful context when hover-scanning parts of the page.
      • The Undo and Thank links could theoretically be included on the popup and it might even seem tempting to add them, however I would suggest those links stay off the popup. At this point the user sees an incomplete and possibly misleading view of the edit they would be thanking or undoing. I think it makes more sense to access those actions from the diff link, where the entire edit is displayed in the proper context.
    • I'm not sure if there is difficulty with the available tools, but searching page-source is a very relevant use case. (Who added or changed an http:// link, or other content not directly visible in read-view?) I suspect this is also a problem if the content is inside a collapse template or if am trying to find who added-or-modified non-text content like a template or an image.
    • I'm not sure if there is difficulty with the available tools, but searching from an old version of the page is a significant use case. There are a lot of ways that the desired search-content can end up buried and only searchable from History. The simplest and most obvious case is when someone just deleted bad-content off the page. (May *I* am even the person who rushed to delete abusive or otherwise bad content off the page.) I need to find who added that content, but it appears the tool would be useless?? Another example: The article claims "John Q. Random" did something evil, the tool might show me that user Foo made a trivial edit changing "john q. random" to "John Q. Random". I still need to find out who is responsible for putting that name in the article. Pbsouthwood gave another example involving a spelling correction. Finding an edit that made a trivial spelling fix is unhelpful, we need to find the person who added the (mispelled) content in the first place. This is also an issue if someone does a copy-edit, changing the word order an/dor replacing words with synonyms may leave none of the original edit accessible though the tool. We need to find who added the conceptual-content, not the person who merely improved the grammar or clarity of that content. It's an annoying gap if the tool is unable to handle these use cases. (Of course a tool with an annoying gap is better than no tool at all, chuckle.) Alsee (talk) 11:37, 20 June 2019 (UTC)
  • Not sure I am seeing what I am supposed to be seeing. I am using a mobile device at the moment (I would rather not give particulars publicly). Ottawahitech (talk) 02:34, 23 June 2019 (UTC)
  • NKohli (WMF) That hover action doesn't work at all for me in the prototype. There is no way for me to progress from step 3 to beyond. —TheDJ (talkcontribs) 13:06, 24 June 2019 (UTC)
  • NKohli (WMF) Looks good to me. The hover doesn't work for me either. Is it supposed to? Ijon (talk) 10:08, 29 June 2019 (UTC)

Response to Feedback

@Beta16, JzG, SMcCandlish, Pbsouthwood, Dalka, KlaasZ4usV, ChristianKl, GreenC, Ijon, Atlasowa, Alsee, and Ottawahitech:

Hello, everyone! My name is Ilana, and I’m the new product manager for the Community Tech team. I’ll be managing the Who Wrote That project from now on, though I’ll be regularly consulting with Niharika. Below, I have provided some general questions, followed by responses to your feedback on the interactive mockup. Thanks for your feedback so far, and I look forward to further insights from the community.

General Questions & Updates:

  • We’re excited to share the findings of the usability tests. Please check out the slides and let us know your thoughts.
  • We plan to release the tool as a browser extension for Chrome and Firefox only (for technical reasons). If this tool isn’t available on other browsers, would this cause significant issues for users? Why/why not?
  • In the current mockup, the tool is activated and accessed under Tools in the sidebar. However, would you prefer to access the tool via a tab at the top (for example, refer to the position of the “WhoColor” tab in the screenshot below) — and why/why not?


Responses to User Feedback:

@GreenC: Great to hear! As for the block of text in orange, the current interactive mockup displays the following on Slide 6 (see screenshot below):

Who Wrote That mockup, slide 6

When you click on the word, a pop-up appears, which provides details about the contribution (i.e. name of contributor with link to user page, link to user talk page, date of contribution with link to diff, and percentage of the article written by contributor). However, we’re changing certain elements of this display (see our response to Alsee). If you’re having difficulty viewing the pop-up, check out the advice at the end of this update.

@Alsee: Thanks for the detailed feedback, which I’ve responded to below:

  • Yes, we (product and design) agree that the blue bar should not block access to any links, including History and View Source. We'll incorporate this change (i.e. no blocked links) into our design.
  • Yes, we agree that the timestamp should be displayed instead of the date. Great point about cross-referencing the History page. We’ll incorporate this change into our design.
  • You wrote that the pop-up doesn’t feel complete. We agree that the pop-up should follow general standards of information display. Now, regarding your specific points:
    • Yes, we agree that username should follow the standard pattern: Name (talk | contribs). The design will be updated to reflect this change.
    • You suggested the inclusion of edit summary in the details pop-up. We’ll investigate this suggestion and later share our findings.
    • Yes, we agree that the Undo and Thank You links should not be included in the pop-up because it excludes the full context of the edit.
  • We plan to develop this tool for Read only mode for two primary reasons: 1) The majority of use cases are for Read mode, and 2) The technical work to support the tool in Edit mode is beyond the capacity of the team, especially if we want to complete other 2019 wishes.
  • We’ll look into the feasibility of enabling Who Wrote That for older versions of an article. To properly investigate this issue, we have two follow-up questions:
    • You discussed the following use case: Someone deleted bad content from the page, and you want to know which author wrote the bad content. Can you let us know a common example of how/when you would identify the bad content on an old page without knowing the author?
    • You discussed the following use case: Someone corrected a grammar or spelling error on the page, and you would like to find who added the error. Can you let us know a common course of action/next steps you would take when you identify the author of a grammar or spelling error?

@Ottawahitech, TheDJ, Ijon, and GreenC: You experienced difficulty viewing the mockup. Here are some possible solutions:

  • Some users reported difficulty viewing the mockup via mobile. We recommend you view it on a desktop browser.
  • If you’re stuck on Slide 1, click “Got It.”
  • If you’re stuck on Slide 2, click on “Who Wrote That” under Tools in the sidebar.
  • If you’re stuck on any slide, click on the right arrow key (on a desktop device) or swipe right (on a mobile device) to proceed to the next slide.
  • If these recommendations don’t resolve your issues, please let us know. We want to ensure that everyone can access and comment on the mockup.

Thank you and I look forward to hearing from you! IFried (WMF) (talk) 00:39, 10 July 2019 (UTC)

Thanks for the update. Can you clarify whether the browser extensions would be available in mobile versions of Chrome and Firefox as well? Ijon (talk) 17:31, 10 July 2019 (UTC)
@Ijon: Thanks for your response! The browser extension will be for desktop only. This is because mobile browsers don't generally support extensions. We may look into making the tool more accessible later on, if we have the resources. However, the current version will be desktop only. IFried (WMF) (talk) 01:47, 11 July 2019 (UTC)
@IFried (WMF): Thanks for clarifying. In that case, to your question "would this cause significant issues for users", my answer is yes, very significant issues. I have the privilege of contributing mostly from desktop (laptop) devices, but we have numerous communities, especially in low-income countries, where a majority of our contributors only have access to mobile devices (phones, tablets, ChromeBooks) and are practically never contributing from desktop devices. Excluding them from ever using this tool would greatly diminish its usefulness for very large swaths of our contributor base. I urge you to reconsider this product decision. Thank you. Ijon (talk) 17:08, 11 July 2019 (UTC)
@IFried (WMF): Firefox for Android does support extensions. The supported technology is WebExtensions, the same as what’s used by Firefox and Chrome (and Opera and Edge) desktop. Writing the extension to work in all these five browsers wouldn’t require much more work, but it would greatly improve the number of reached users—especially the Firefox for Android availability (although Chrome is much more popular, and installing yet another browser just for this is a bit overkill, but much more realistic than buying a PC, and at least we can say we did our best, and recommend users to install Firefox). —Tacsipacsi (talk) 19:02, 11 July 2019 (UTC)
@IFried (WMF): It would really be apreciated if support for mobile is added/given same attention as desktop. Indeed many volunteers in the Sub-Sahara region for example access and edit wikipedia via low-end/tech smartphones tablets/phablets and chromebooks. This feature would definitely improve and enrich their reader/editor experience. I hope that you will reconsider, at the very least the suggestion by Tacsipacsi, to make it available on firefox browser.--Thuvack (talk) 15:32, 12 July 2019 (UTC)

Regarding use case examples: While I recall there were several times I had to dig history to find who added something, it's hard to recall specific details. I'll offer a fictional example that hopefully answers the questions. Let's say there's a conflict at the biography of John Q. Random, and I add the page to my watchlist. The next day and edit shows up on my watchlist, someone either deleted the word "politican" or spelling-corrected it to "politician". Either way, the original word no longer appears on the page. The discovery of the problem and the workflow have begun from a version in history. I'm pretty sure John Q. Random was never a politician, so I want to find who added the "politican" claim to the article. Maybe it was a respected long term editor, and I can ask them if they have a source for the politican claim. Or maybe it was a short-history account and I need to check to see if every edit by that account was stealth vandalism. (Stealth vandalism: deliberately false information that looks plausible and which can easily slip common causual reviews.) If it's vandalism then I probably need to revert every edit made by that account, and have the account blocked. Alsee (talk) 20:24, 14 July 2019 (UTC)

@Alsee: Thanks for walking us through this scenario. Also, I apologize for the late response. This information was very helpful. We’ll think about this request, and we’ll update the community when we have updates. IFried (WMF) (talk) 21:41, 30 July 2019 (UTC)

Technical response regarding mobile

Hi everyone, I'm the technical lead for CommunityTech; thank you for all the feedback — it's super useful for us as we start planning the implementation stages of the project. I wanted to specifically respond to the requests for a mobile behavior.

We are, at the moment, planning to output the code for a desktop browser (Chrome and Firefox). There's some preliminary consideration to see if we can make this a gadget, but there are some concerns that we're looking into regarding loads, security implications of pulling from an external domain, and others. So while we're keeping the option open, it's not yet clear if we can go that route. A browser extension is what we are concentrating on, both in terms of development and testing.

As some of you pointed out, Firefox for Android can run browser extensions, but Chrome cannot. It is likely that we can make the mobile browser run the code. However, running the code is not the only consideration that we have to have in order to deliver a workable mobile product — and this is where the challenges lie. On desktop, you have a clear distinction between 'hover' and 'click' — on mobile, you do not. Everything is a tap or swipe action. Making this product a mobile experience doesn't just mean running it on the mobile device, it also means rethinking the UX and interactions when the user uses the mobile device. This is just one example; in our experience, there tend to be quite a number of them.

We aren't eliminating the possibility of delivering a mobile experience. We are still in the preliminary stages of exploring what some of the development aspects mean and how long they take. There are pieces of the current interaction (even in the browser version) that need to be implemented from scratch. Each addition to that takes more time. As the Community Tech team, and unlike most other teams at the Foundation, our work covers multiple products in the Wishlist, so our focus is to deliver to you the best product interaction we can — within a limited scope and time.

My recommendation is this: We start with a desktop experience that is responsive, making sure that technically speaking the code is ready to run on mobile. We concentrate our efforts, first and foremost, on delivering a working and robust product to you on the two browsers, with an exploration of making it a gadget, either now or in the future.

Alongside that, we will explore what it requires to provide a workable UX for the mobile experience, so that we can estimate this work properly and provide better insight into whether it's feasible for us. If it is — all the better! :) if it's not, we will have to scope it down. And, as always, and with great pleasure — patches are always welcome! :)

MSchottlender-WMF (talk) 19:43, 12 July 2019 (UTC)

I like the current slides, but I don't understand the decision to go for a browser extension. I don't think any regular features are currently provided via browser extensions Providing features via a browser extension means that the feature isn't easy to discover for new users. That's especially import for users that only use Wikidata irregularly. ChristianKl❫ 08:08, 15 July 2019 (UTC)
Yep, this is much better done as a MediaWiki "gadget" that we can turn on via Preferences. As for placement, I would say to put it up top, since I rarely use stuff in the left-hand menu, but others may prefer the opposite, so some kind of preferences/options choice would be good.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  18:11, 24 August 2019 (UTC)

Looking for Survey Participants (to determine link location)

@Beta16, JzG, SMcCandlish, Pbsouthwood, Dalka, KlaasZ4usV, ChristianKl, GreenC, Ijon, Atlasowa, Alsee, and Ottawahitech: We are now considering the location of the Who Wrote That tool link. To do this, we would like to collect some feedback regarding how you find information about pages. For this reason, we would love if you could answer two brief questions in our survey. Thanks! IFried (WMF) (talk) 17:52, 26 September 2019 (UTC)

  •   Done· · · Peter (Southwood) (talk): 18:03, 26 September 2019 (UTC)
  •   Done --β16 - (talk) 08:12, 27 September 2019 (UTC)
  •   Done Klaas `Z4␟` V:  08:25, 27 September 2019 (UTC)
@Pbsouthwood, Beta16, and KlaasZ4usV: Thank you! Also, if anyone still wants to participate in the survey, there is still time & we would love your feedback. Thanks! IFried (WMF) (talk) 01:33, 29 September 2019 (UTC)
Thank you so much for the feedback! Based on your responses we'll be checking the technical feasibility of some solutions, and then deciding where this tool would be accessed from. The survey is still open if you'd still like to leave your answers. PSaxena (WMF) (talk) 13:00, 3 October 2019 (UTC)
  •   Done, since it still seems to be open.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:57, 28 October 2019 (UTC)

Gadget, tool, extension?

I'm trying to understand how is this developed exactly and I can't find an answer on this page: As a gadget whose code is maintained on wiki pages? Or as a MediaWiki extension? Or as an external tool?

Tagging User:PSaxena (WMF)], User:MusikAnimal (WMF), User:IFried (WMF). --Amir E. Aharoni (talk) 18:53, 31 December 2019 (UTC)

As far as I understand, this is going to be a browser extension for Firefox and Chrome, although I don’t see it yet on Wikimedia’s AMO account. —Tacsipacsi (talk) 23:50, 31 December 2019 (UTC)
It is here on AMO. The CT team have their own account. – Ammarpad (talk) 07:15, 2 January 2020 (UTC)
Why yet another place to keep track of, without a single link from Meta… At least we should have a status update on this page (not the talk page) with steps how to install the beta version in Firefox (and Chrome, if it’s available there). —Tacsipacsi (talk) 14:46, 2 January 2020 (UTC)
User:Amire80, User:Tacsipacsi, and User:Ammarpad Hello! WWT is being developed as a browser extension for Chrome and Firefox, available on desktop browsers. We shared our plan to make it a browser extension in June 2019. We later discussed some of the technical details regarding desktop vs. mobile support, as well as potential future plans, in July 2019. Since that time, we have been working on developing the tool as a browser extension. The beta version is currently being tested and improved (there are some bugs to fix). For this reason, we have not publicly announced or shared the tool yet. However, we plan for it to be generally available soon. We’ll definitely update everyone when that’s the case. Thank you, and more updates should be coming soon!--IFried (WMF) (talk) 18:52, 2 January 2020 (UTC)
I don’t think posting an update on Community Tech/Who Wrote That tool would count as a “public announcement”. This page is mainly for people specifically interested in this tool, and the more people test the knowingly beta version, the less bugs remain in the stable one. —Tacsipacsi (talk) 19:27, 2 January 2020 (UTC)
Tacsipacsi I will not only be posting on Meta-Wiki. I will be sharing on many channels when the tool is available.--IFried (WMF) (talk) 21:18, 2 January 2020 (UTC)
I understand that. But could CommTech right now post an update only on Community Tech/Who Wrote That tool so that important information and URL could be found on the content page, and people ignoring talk pages get a chance to notice them? —Tacsipacsi (talk) 22:29, 2 January 2020 (UTC)
Tacsipacsi We'll be posting an update with links to the extension (and request for feedback) very soon. There are just a few critical bugs that we would like to fix first. Once they are resolved, we'll widely share the tool. We just returned from our holiday break today, so we're catching up with some work over the next few days. You can expect an update regarding WWT in the next few weeks. Thanks for your patience, and we look forward to posting further updates soon. Thanks! --IFried (WMF) (talk) 00:11, 3 January 2020 (UTC)
Tacsipacsi Who Wrote That? is now available as a Chrome and Firefox browser extension. You can check out the details in the section below. We would love your feedback. Thank you! --IFried (WMF) (talk) 23:44, 14 January 2020 (UTC)

Bug in display of wikilinks

I found a bug in the way the bug displays "automatic plural" wikilinks. For example, in Albert Einstein, under the "Patent Office" setting, there is a wikilink written as [[patent application]]s. Normally, this would display as w:patent applications, automatically including the trailing "s" as part of the link. However, activating the tool causes the "s" to display as regular text instead of part of the wikilink. (Pretty minor issue—overall, this is a great tool, and I can already think of several ways I'll be using it.) Seraphimblade (talk) 03:29, 25 January 2020 (UTC)

Confirmed in Firefox. Another, seemingly related issue: the German version of the article (de:Albert Einstein) displays the <onlyinclude> tags in the lead when using WWT. This means a bit more information, but also more confusion because of the difference between the normal and the WWT view. —Tacsipacsi (talk) 10:30, 25 January 2020 (UTC)
@Seraphimblade and Tacsipacsi: Thanks for reporting this issue. Yes, there are times that wikilinks display in unexpected ways. I believe this is due to the data we receive from the WhoColor API (but I'll check with the engineers to the confirm). In such cases, the bug isn't something we can fix from our end. It would need to be fixed by the maintainers of WhoColor. With that being said, we have discussed similar bugs as a team, and we hope that it can be fixed in the future. --IFried (WMF) (talk) 22:07, 3 February 2020 (UTC)

Not recognising templated content

On en:Molly Blake, for example, the Firefox version of the tool (I've not tested using Chrome) does not recognise the bulleted entries under "Publications", which are templated.

Similarly, it does not recognise anything in the templated "Works" section of en:Mark Renn.

Other than that, it's great! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:30, 25 January 2020 (UTC)

@Pigsonthewing: Thanks for the feedback, and we're glad you're enjoying the tool! Unfortunately, the tool doesn't work on templates. We receive data and analysis from the WhoColor API, which does not cover templates. In the future, we hope that the API is extended to include templates, but this would need to be determined by WhoColor maintainers. For more information, you can check out Who Wrote That?#Current Limitations of the Tool. Thanks! --IFried (WMF) (talk) 22:17, 3 February 2020 (UTC)

Thank you

Many times I've tediously gone through list of diffs on an article trying to find where a specific bit of text was added and by whom so I could ask them about it or to help me track down context. This tool might not be perfect (I noticed above that it might miscredit authorship when someone deleted then self-reverted) but it's leaps and bounds ahead of the manual investigation method. Thanks for building it! Schazjmd (talk) 18:38, 29 January 2020 (UTC)

@Schazjmd: Thank you for your feedback and your supportive words! Your explanation ("...I've tediously gone through list of diffs...") is exactly why we're so excited about this tool; there are so many complex processes that we hope to simplify. We look forward to seeing the tool become more widely adopted, and thank you again! --IFried (WMF) (talk) 22:27, 3 February 2020 (UTC)


First of all, thank you for this tool. I've only had a few minutes to test it so far, but I think it will save me huge amounts of time. My one suggestion so far is to include references, because I can't seem to highlight those with the tool at this time. Hopefully that's a capability in the API, or might be in the future. Thank you!! --Secundus Zephyrus (talk) 18:13, 31 January 2020 (UTC)

@Secundus Zephyrus: Thanks for the feedback, and I'm glad that the tool will be a time-saver! Unfortunately, we can only display what is covered by the WhoColor API, which often does not include references. In the future, we hope that the API does expand its coverage, which would need to be done by the API maintainers. In the meantime, we're glad that tool improves your experience on Wikipedia, and thanks again! --IFried (WMF) (talk) 22:36, 3 February 2020 (UTC)

Beta Tool Released: Ready for Feedback

Note: Apologies if you were pinged twice! The first ping did not seem to go through due the 50+ ping limit, so I've updated the message blocks to be separate edits. Thanks!

@Tim.landscheidt, Strainu, Tgr, Ijon, Jenks24, Dvorapa, HHill, Beta16, Oscar ., Liuxinyu970226, Jc86035, YFdyh000, Stryn, Arkanosis, Draceane, Yiyi, Rcsprinter123, Laboramus, Gripweed, Iliev, Kurt Jansson, Thomas Obermair 4, Bawolff, PKM, Bspf, Simon Villeneuve, Ottawahitech, TheDJ, Ermahgerd9, Luan, ZellmerLP, He7d3r, Putnik, Nocowardsoulismine, Furfur, DMacks, JzG, Pbsouthwood, Nizil Shah, Defender, OrsolyaVirág, Dromedar61, ThePlatypusofDoom, Barcelona, Hogne, and Eug: --IFried (WMF) (talk) 06:26, 15 January 2020 (UTC)

@TerraCodes, Gnom, Wostr, Cybularny, Wolbo, Tom Ja, Emir of Wikipedia, TheCatalyst31, Noyster, Winged Blades of Godric, Kostas20142, FULBERT, Paucabot, Mz7, Giraffedata, Gryllida, SMcCandlish, Jpcomic, ChristianKl, MOs810, Nabla, Doc James, Epìdosis, Ca2james, Shock Brigade Harvester Boris, B25es, Anthere, -glove-, Kudpung, The wub, Kolurpen, PamD, KlaasZ4usV, 15zulu, Tacsipacsi, Pipetricker, and Fano: --IFried (WMF) (talk) 06:26, 15 January 2020 (UTC)

@MichaelMaggs, NaBUru38, Ldorfman, Perrak, Spinster, Jack who built the house, Serhio Magpie, Ле Лой, Sleeps-Darkly, Dispenser, Manu1400, Psychoslave, Niklem, Infovarius, Ilya, Ragesoss, NickK, Gikü, Martin Kraft, Semmendinger, and Downtowngal: --IFried (WMF) (talk) 06:26, 15 January 2020 (UTC)

@Superchilum, Laurentius, and Bryanrutherford0: --IFried (WMF) (talk) 06:40, 15 January 2020 (UTC)

Hello, everyone! I have pinged you because you voted on the 'blame tool' in the 2017 Community Wishlist Survey. We are now very excited to share Who Wrote That?, available as a Chrome and Firefox browser extension. With Who Wrote That? (WWT), you can find authorship information directly on Wikipedia articles. When you hover over content, the tool highlights all content by the same author. When you click on content, the tool identifies the author of the revision, along with revision details. Currently, the tool is in beta mode, and we would love your feedback. There are still some minor bugs to fix (and please let us know if you find any!), but the tool is already functional. You can download the Chrome and Firefox extension, and documentation on the tool is available on the MediaWiki WWT page. The data and analysis in WWT come from the WhoColor API, developed by WikiWho, and the MediaWiki API. Thank you, and we look forward to hearing your feedback! --IFried (WMF) (talk) 22:00, 13 January 2020 (UTC)

I like where this is heading! Main concerns, and apologies if I'm repeating things that have already been said – I've not had the time to properly read through the entire discussion:
  • I'd be concerned if this would be opt-in for more wikis – being added upon request. They tend to miss those opportunities exist, and then when individual editors find out about the tool they have no idea how to get it to their wiki.
  • It seems to understand reverts, but if I accidentally remove something while adding content, and then reinstate it using copy and paste (because reverting would remove what I added earlier), I get credited as the author of that piece.
  • I'd love for this to work in the Wikipedia namespace, so I could try to follow who added which piece of policy or guideline.
Nice work. /Julle (talk) 04:40, 14 January 2020 (UTC)
(Or Commons namespace et cetera once it works beyond the Wikipedias, of course.) /Julle (talk) 06:48, 15 January 2020 (UTC)
@Julle: Thank you so much for the feedback! We are currently conducting an investigation to see if it is possible to expand accessibility of Who Wrote That? (both in terms of making it a gadget/extension and extending support to other wikis). Your question about the Wikipedia namespace is interesting, so I've added that question to the investigation as well. Regarding the accidental removal + copy/paste issue, I'm not sure if there is anything that can be done, but we can certainly take a look. Ideally, what behavior would you like in such a scenario, as a WWT user? Thanks! --IFried (WMF) (talk) 20:16, 22 January 2020 (UTC)
@Julle: Also, I should add that we're currently displaying the data that we get from the WhoColor API. This means that we can ask WhoColor folks to add support for the Wikipedia namespace, but we can't add that support directly. --IFried (WMF) (talk) 20:37, 22 January 2020 (UTC)
User:IFried (WMF) I love the fact that it gives the diff that added the edit in question :-) I would love this to also work on references and external links as that will make it faster to find people who are spamming these. Great work by the way. Doc James (talk · contribs · email) 10:55, 15 January 2020 (UTC)
@Doc James: Thank you for the feedback! I'm glad that you find the diff link to be a useful part of the tool. As for including references and external links in the analysis, we unfortunately can only display the data we get from the WhoColor API. Currently, the WhoColor API does not include references and external links in its analysis. However, if this changes in the future, we would happily extend that support to the tool as well. Thanks! --IFried (WMF) (talk) 20:42, 22 January 2020 (UTC)
At first glance and test of this, it seems an amazing tool. Thanks for sharing the initial version of this and happy to begin testing it. --- FULBERT (talk) 12:07, 15 January 2020 (UTC)
@FULBERT: Thank you for the supportive words, and we're happy that you like the tool so far. We look forward to any feedback that you have to share! --IFried (WMF) (talk) 20:44, 22 January 2020 (UTC)
I understand that there are technical limitations and that it's far more difficult to handle manual removals and re-inserts than reverts, but ideally, it wouldn't differentiate between what was "reverted" manually and what was reverted using the revert functionalities, since, in effect, they amount to the same thing in this particular case. I worry about the future where this is used externally and we see newspaper articles, papers and so on miscredit editors as the writers of things they simply copied and put back. /Julle (talk) 20:25, 22 January 2020 (UTC)
@Julle: Great point. I'm not sure what is possible, but I agree that it's at least important for the team to discuss (and see if we can support/improve the situation in any way). I've made a note for us to discuss it during an upcoming meeting. Thank you for bringing this to our attention. --IFried (WMF) (talk) 20:51, 22 January 2020 (UTC)
I'm also impressed with it, and mostly look forward to it expanding in applicability over time. That said, I would discourage a focus on bringing it to the project namespace. I would suggesting doing that as a final step (and an optional one), after people have gotten used to the tool, and after some norms evolve against misusing it to cast aspersions and make other bogus, battlegrounding arguments. The "fallacy of the revelation of policy" is already a recurrent problem, and having this tool usable in projectspace right from the beta period will simply worsen it.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  12:46, 15 January 2020 (UTC)
How? People will notice that the essay you cited is one that you wrote yourself? I think the more useful case would be people being able to find out when a given bit of a guideline was added, and therefore have an easier time finding any related discussions in the archives. Those discussions can often be useful in understanding whether the people writing it had considered the situation at hand. "Oh, hey, that was written several years before our policy about BLPs" can be a valuable revelation. WhatamIdoing (talk) 03:30, 16 January 2020 (UTC)
@SMcCandlish and WhatamIdoing: Thanks for providing perspective on some of the pros/cons of allowing WWT in the project namespace. At this point, we cannot implement this support either way, as we do not get such data from the WhoColor API. However, this conversation will be very useful for us to revisit if such support ever does change in the API. Thank you! --IFried (WMF) (talk) 20:55, 22 January 2020 (UTC)
Wow, it's strange to have someone prove my point for me so stunningly, WhatamIdoing (nor does your "observation" even relate to how this tool works or what it does). Imagine fallacious arguments like that coming up every single day, nitpicking to death every item in our policies based on whose digital hands touched its wording. No thank you. Use of this in project space (at least before some "arguments to avoid" and other norms are laid out organically through experience of use and misuse in mainspace) is basically a recipe for perpetual BATTLEGROUNDing. It'll be a tool for grudge-bearers to wield against their "enemies" in tracking down everything they've had a detectable effect on and challenging it all simply to get back at them. PS: When something was written (i.e. "Oh, hey, that was written several years before our policy about BLPs") is already something one can figure out pretty easily from page history, and has nothing to do with who made the edit, other than you're liable to see that in the course of diffing it out, if you even want to be that specific. Generally, it's entirely sufficient to take the date of what you want to compare (e.g. the date that w:en:Wikipedia:Biographies of living people received a {{Policy}} tag), then go look in the history of the other page, at the day before that happened, and see if what you're concerned about still appears (in some version) in that specific snapshot of the page. Has nothing to do with the "Who Wrote That" tool.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  21:51, 23 January 2020 (UTC)
Will this become a mediawiki extension, or will this stay as a browser extension? Also why does the browser extension need my browsing history? --Terra  (talk) 12:24, 15 January 2020 (UTC)
I would also like to know why it needs my browsing history, and more importantly, what it does with it. · · · Peter (Southwood) (talk): 07:02, 19 January 2020 (UTC)
Hi @TerraCodes and Pbsouthwood:, thank you for your concern. Can you tell me where do you see that the extension asks for the history permission? We explicitly only ask for two permissions:
  • activeTab (info here): Provides access to the contents of the current tab the user is on (we do not request information about all tabs)
  • storage (info here): Provides access to the internal browser storage so we can save the state of whether to present the "Welcome" popup to you.
We do not ask for the history permission. On top of that, the "manifest" file (that defines where and how the extension runs and under what permissions), is specifically defined to only run the script within the approved wiki domains. You can see that file -- and the permissions we're requesting -- in this link.
Has the browser requested the history permission from you when installing the extension? If so, could you please tell me what browser store, and if possible, what it is that the warning stated? Thank you! MSchottlender-WMF (talk) 21:21, 22 January 2020 (UTC)
Can that file be modified to use the browser extension on other Wikis? Potrod (talk) 20:20, 24 January 2020 (UTC)
The technical prevention to work on other wikis is not really the manifest file; if it's changed, the extension would load background files on any wiki -- but the service itself (operated by WhoColor) only works on the given wikis for the moment. We have an investigative ticket on phabricator where we're attempting to see whether we can request WhoColor to support more wiki languages. MSchottlender-WMF (talk) 21:00, 10 February 2020 (UTC)
@MSchottlender-WMF: It was from chrome, but I'm not getting it now, so I wonder if it was related to the tabs permission that was removed. Also, is this going to stay a browser extension, or will it become a MW extension? --Terra  (talk) 23:32, 7 February 2020 (UTC)
Ah, yes, thank you for that; we added the tabs permission temporarily as an attempt to see if we need to save preferences in a different way than we do right now; it is no longer needed, though, so we removed it. That permission, interestingly, is not supposed to give us (or any developer) the ability to see your history, it's only meant to give us the ability to request the data of a tab (we were considering allowing for work across tabs, which is why we experimented with this permission) but I think the language that Chrome uses to warn users is a bit misleading. Either way, it's not used. Thank you for raising this concern!
As for the second question -- There were several technical and social reasons why we chose to work on this as a browser extension, which is why this product is just that for now. One of the biggest issues is that the product relies on an external service (WhoColor). We send all the data through a proxy for anonymity, but the requests to tool-labs (for the proxy) are not allowed to be done from a MediaWiki extension. It may be allowed to be used from within a mediawiki gadget, but may require user-specific permissions, which we were concerned about. Also, a gadget means anonymous/non-logged-in users cannot use it unless the wiki itself decides to activate it for all readers. These are some of the issues that were originally raised when the extension was written. We do have an investigation at the moment where we're checking whether making this product into a gadget is feasible and doable, and whether we can migrate it to be a gadget on wikis that are supported. MSchottlender-WMF (talk) 21:00, 10 February 2020 (UTC)
Thank you for doing that work. This is going to be an extremely useful tool! I've found just one bug so far (using the Firefox extension): sometimes it breaks the display of image galleries. Try it for example on the Father Christmas article, and watch what happens to the gallery named Old Father Christmas in folk plays part way down the page. MichaelMaggs (talk) 13:08, 15 January 2020 (UTC)
@MichaelMaggs:Thank you for your feedback. I'm glad that you find the tool be useful. As for the bug you reported, I believe this is due to the data we receive from the WhoColor API, which means that it's not something we could fix from our end. But I'll have the engineers take a look to confirm. Thank you! --IFried (WMF) (talk) 20:05, 24 January 2020 (UTC)
I'm disappointed that this wasn't implemented as a gadget. It seems that the wishlist of next year needs a wishlists item for "Gadget that provides the blame functionality" so that there's a possiblility for users to discover the functionality. ChristianKl❫ 17:27, 15 January 2020 (UTC)
@ChristianKl: Thanks for sharing your feedback. We are currently conducting an investigation to see if it is possible to expand accessibility of Who Wrote That? (including making it a gadget or extension). Hopefully, we'll be able to make it more accessible to users in the future. Thanks! --IFried (WMF) (talk) 20:10, 24 January 2020 (UTC)
Unfortunately, can't use this due to the fact that I don't use any of these two browsers. Wostr (talk) 17:33, 15 January 2020 (UTC)
@Wostr: Thanks for the feedback. We hope that we can make WWT accessible to more users in the future, if time and resources are available. --IFried (WMF) (talk) 20:14, 24 January 2020 (UTC)
Very nice! I use the WikiWho tool very often, so I'm glad to see this work on making something that's easier to install. A few things that could be improved: Being able to highlight multiple people at once has been pretty useful (e.g. when looking at what a group of students have added to a page). It's also be useful to have a authorship summary stats graph ( pop up when clicking the header, or even just a link to it. Having the breakdown for each section when the seciton header is clicked would be similarly useful. WhikiWho always had problems when printing the page to PDF with annotations shown, and this tool overall does much better, with the exception that the WWT header bar floats in the middle of the page. Obviously, working with references would definitely be very valuable, since that's also something WikiWho wasn't able to do. Overall I like the interface aesthetic improvements over WikiWho. It also seems to avoid the issue that WikiWho has where sometimes it'd stop tracking sections below the first table. Eventually it may even be useful to have as a default part of the history tab. T.Shafee(Evo﹠Evo)talk 07:01, 16 January 2020 (UTC)
@Evolution and evolvability: Thank you so much for these thoughtful and detailed suggestions. It's especially interesting to read some of your comparisons of the WikiWho vs. WWT user experience. We'll think about these suggestions, as well as other suggestions in this talk page, if we have the time and resources to further improve the tool in the future. Thank you again, and we hope you enjoy using the tool! --IFried (WMF) (talk) 20:17, 24 January 2020 (UTC)

I do not use those browsers by default :( Anthere (talk)

@Anthere: Thanks for reaching out and sharing this feedback! We hope in the future that we can expand accessibility of this tool for more users, if time and resources permit. --IFried (WMF) (talk) 20:20, 24 January 2020 (UTC)

I've added this to Firefox and Chrome, and on heaps of pages the link doesn't appear in the menu. (In both browsers, on Windows, and different pages.) How could I go about debugging why that is happening? pfctdayelise (talk) 22:53, 16 January 2020 (UTC)

@Pfctdayelise: We issued a fix yesterday, which may resolve the issue you have been experiencing. In that case, I recommend that you go to the Chrome and Firefox web stores to uninstall and then re-install the extension (click "Remove" and then immediately click to add the extension again). The extension should then appear under "Tools" if you're viewing it on Wikipedia articles in read mode on a desktop browser (English, German, Basque, Turkish, or Spanish Wikipedia only). Let me know if you still encounter the issue or if the issue is resolved. Thank you! --IFried (WMF) (talk) 20:19, 17 January 2020 (UTC)

Using it on Chrome and loving it so far. What a cool gadget! Clayoquot (talk) 06:51, 17 January 2020 (UTC)

@Clayoquot: That's great to hear. We're so happy that you're loving it! Please feel free to share more feedback or suggestions as you continue to use the tool. Thanks! --IFried (WMF) (talk) 20:21, 24 January 2020 (UTC)
  • Works for me on Chrome. Have not yet tried it in Firefox. It appears to have to reload each time one goes to a new page, and takes several seconds to do so. Is this normal? (My internet is very slow at the moment, and Wikipedia edits take several seconds to open or save, and occasionally crash, so it might not be the tool). Also does not allow "show" function in collapsed navbox, but that is not a crisis. · · · Peter (Southwood) (talk): 10:11, 17 January 2020 (UTC)
    The blue bar seems unneccesarily large.
    Seems to work the same on Firefox.
    There is no popup until I click on a word. It takes several seconds for the popup to resolve, but that might just be my crappy internet, as currently it is taking several seconds to open an edit window, when it actually finds the server. There is no darker highlight on the selected word, and no indication of the user in the blue bar as shown above.
    The tool does not appear to work with any templates.
    When it reports X has written Y% of the page, what does this mean? The number appears to be somewhat unrealistic. Cheers, · · · Peter (Southwood) (talk): 06:53, 19 January 2020 (UTC)
@Pbsouthwood: Thanks for the feedback, and we're glad that it's working for you on both Chrome & Firefox! The pop-up is meant to only load when you click on a word (that's expected behavior). The pop-up tends to load very quickly whenever I test it, but I understand that different people may have different experiences. If the issue persists, and it seems to only happen with the WWT pop-ups (as opposed to other wiki tools and pages), then please do let us know. As for templates, we get data analysis from the WhoColor API, which currently doesn't include templates. If the WhoColor API expands to include templates, we would happily include templates in WWT as well. The percentage in the pop-up is calculated based on tokens rather than on characters, and it does not necessarily take into account every part of the page. However, the percentage can provide a general approximation of the author’s imprint on the page overall. For more information on the tool, you can find many answers to such questions on the MediaWiki page for WWT. Thank you! --IFried (WMF) (talk) 20:30, 24 January 2020 (UTC)

I'm disappointed. Wikipedia should work from everywhere with every device and without a special app or extension. Not just with two specific browsers and after downloading and installing an additional tool, which I might not even be allowed if it is not my computer. So what you produced was explicitly NOT my wish. And proof that its possible in a different way is de:Benutzer:Schnark/js/artikel-statistik. Obviously I'm not going to test your tool, because I'm not going to install it. Fano (talk) 13:29, 17 January 2020 (UTC)

@Fano: Thanks for your feedback. We're currently conducting an investigation to see if it is possible to expand accessibility of Who Wrote That?. If time and resources permit, we would be interested in seeing if this can be done in the future. --IFried (WMF) (talk) 20:34, 24 January 2020 (UTC)

I can immediately think of two things to improve this tool

1. Allow the revision of the text that you are hovering over to be a different colour to all other text by the same author. (The tool shows the diff of only the hovered text, and this is different for each yellow text by that author that you click. I propose that the text associated with the diff be a different colour.)

2. Prevent the selection from being abandoned when you use the middle mouse button to scroll down the page in Chrome. (Click some text to bring up the popup, then click or hold the middle-mouse button to scroll. The selection disappears. This shouldn't happen. Such scrolling doesn't have any different effects (that I know of) to regular scrolling in regular Chrome usage.)

Thank you. SUM1 (talk) 09:51, 22 January 2020 (UTC)

@SUM1: There is one important difference between the behavior of the regular scroll and the middle-button scroll (so-called autoscroll) on Windows (there is no autoscroll in Chrome for Linux and Mac at all): when you press the middle button over a link, it doesn’t start scrolling, as the middle button is not only the autoscroll button, but also the button to open links in new tabs. This shows that the two don’t behave exactly the same even without any JavaScript; however, it doesn’t mean that closing the popup with middle click cannot be prevented. I don’t know which way is it more intuitive, though. —Tacsipacsi (talk) 18:30, 23 January 2020 (UTC)
@Tacsipacsi: That's strange, Chrome updated and it suddenly doesn't want to hold on to any selection at all when I scroll with the middle-mouse button. I could swear it did before. It still does in Firefox. Still does in word processors too. SUM1 (talk) 18:51, 23 January 2020 (UTC)
@SUM1: I’m afraid I can’t help you: I use neither Chrome nor Windows on a daily basis. I suggest you to find another support forum for your problem. Or use Firefox, like me! ;) —Tacsipacsi (talk) 19:06, 23 January 2020 (UTC)
@Tacsipacsi: I made the preparations to file a Chromium bug report, as I've roughly located the version where the behaviour changed. I abandoned Firefox around 2012; it doesn't have the resources to manage the hundreds of tabs I usually have open. But this is still probably a different issue, since this tool's highlighting is not text selection and thus shouldn't necessarily behave like it. So I believe it still can and should be fixed. SUM1 (talk) 20:41, 23 January 2020 (UTC)
@SUM1: Thank you for the feedback & detailed suggestions! Right now, you can access the revision-specific information by clicking on the timestamp (which links to the diff). However, I understand that it would be even easier to see the revision information highlighted in some way on the article page as well. In the future, if we have time and resources to improve the tool, we'll definitely consider your suggestions. Thank you! --IFried (WMF) (talk) 21:11, 24 January 2020 (UTC)
@IFried (WMF): Do you have any opinion about point 2? For me the current way seems more natural, but it looks like not for everybody; it would be good to hear a clear statement from the team. —Tacsipacsi (talk) 21:19, 24 January 2020 (UTC)
@Tacsipacsi: Thanks for bringing up this question! I've forwarded the idea in point #2 to the UX designer (to see what opinion he may have). I'll consult with him and provide updates on our discussion afterward. Thanks! --IFried (WMF) (talk) 20:02, 3 February 2020 (UTC)
@Tacsipacsi: @IFried (WMF): I'm investigating this right now. It may seem more intuitive because it's been the default Chrome way for roughly half a year now, but it's not the default way in other browsers like Firefox or word processors. But the issue is slightly even more nuanced than that, because middle-clicking outside of a text paragraph has always deselected, but this happens on the mouse click, not on release. Since this Chromium version, which I'll identify, it deselects even within the paragraph, on mouse release. I'll detail all of this in a Chromium comment or bug report. There is a similar issue in VisualEditor which seems to be unrelated. I got distracted and didn't finish locating the exact Chromium version of the change, but I will now. · • SUM1 • · (talk) 10:37, 21 February 2020 (UTC)
I've identified the Chromium version. It was Chrome Chrome 79.0.3909.0 (64-bit), base position 695389, from 11 September 2019 (bug report). Here's a video of the issue in action with both Chrome versions, Firefox and the Who Wrote That? extension/addon: This proves the Who Wrote That? behaviour is independent of selection and can still be fixed. · • SUM1 • · (talk) 18:54, 21 February 2020 (UTC)


First and most obviously, this is super-amazing. Thank you for making it available. This is incredibly useful. Could it be made to work with pages not in article space? For example, I'm looking at en:WP:G5 and want to know when the last bullet point was added. WWT would be the perfect tool for that. RoySmith (talk) 22:18, 31 January 2020 (UTC)

@RoySmith: "Super-amazing" is maybe the best thing that a team can hear (thank you!). We're so happy that people are liking and using the tool. As for the including the tool outside the article space, we have included this question in our current investigation into the potential expansion of the tool. Overall, this request may be beyond the capacity of WhoColor API maintainers or the Community Tech team, but it's a great idea that is definitely on our radar. Thanks! --IFried (WMF) (talk) 22:49, 3 February 2020 (UTC)

Availability in other languages

Hi, What is needed for it to be available in other languages? Is it only translation? Seems to work really nicely, and it will allow individual authors to better present their work to the outside world. Good job? GoEThe (talk) 12:32, 7 February 2020 (UTC)

@GoEThe: Thanks for reaching out, and we're happy to hear that you enjoy using the tool! We conducted an an investigation to see if it is possible to expand accessibility of Who Wrote That? (both in terms of making it a gadget/extension and extending support to other languages/wikis). We found that there may be some challenges in expanding the tool to other languages (mostly due to lack of resources, at this point). For now, the Community Tech team needs to focus on other projects in our backlog, but we hope to see if we can expand WWT accessibility in the future. Thank you! --IFried (WMF) (talk) 17:56, 25 February 2020 (UTC)
I came to ask you the same question. Thanks for having developed such a tool which seems excellent for finding old problems (vandalism, copyvio...) in articles.
I just regret that it is not available on wp-fr. I am on a case of multiple copyvio of a contributor over more than 4 years hidden betwenn more than 3000 contributions... Such a tool would have been perfect.
Best regards,
Hesan (talk) 14:55, 7 November 2020 (UTC)

New feature request: rev number

Very nice. Please add revision number, as follows:


  • ExampleUser (talk | contribs) added this on [[Special:Diff/123456789|21 June 2018 5:28 AM]].


  • ExampleUser (talk | contribs) added this on [[Special:Diff/123456789|21 June 2018 5:28 AM]] (rev [[Special:Permalink/123456789|123456789]]).

Justification: the point of this request, is to expose the rev number in the clear in the pop-up. Anyone using this tool is very likely already experienced and probably hand-rolls their own permalinks and Diffs. Please help make this tool even more efficient for us, by not making us extract the rev number from the timestamp, and just display it. Adding the permalink is a nice-to-have, to see what context was like at that time; but for me at least, what's important here is a copy-pasteable rev number in the clear. Thanks; nice tool.

P.S. The idea was inspired by script w:User:BrandonXLF/ShowRevisionID.js, which I heartily recommend. Mathglot (talk) 21:49, 22 November 2020 (UTC)

Getting an error message

Hi, I'm getting an error message when I try to use the tool. Thanks MassiveEartha (talk) 18:16, 12 April 2021 (UTC)

Same here, at this time. Mathglot (talk) 19:51, 12 April 2021 (UTC)
@MassiveEartha: What error message do you get? What browser and browser version are you using? The operating system and the extension version may also help debugging, although it looks like the extension hasn’t been updated for a while. —Tacsipacsi (talk) 20:14, 12 April 2021 (UTC)
I'm also getting an error (and thank you for creating the tool, I find it very useful). I'm using Firefox version 82.0.3, though am just installing 87.0 to see if that helps (edit: no difference with version 87.0). The error message I get is "Error: Refresh or try again later. If the issue persists, contact us". Tacyarg (talk) 20:20, 12 April 2021 (UTC) (edit: working again for me Tacyarg (talk) 20:06, 15 April 2021 (UTC))
Ditto, newest version of Google Chrome and on OSX catalina. Same error message. Sennecaster (talk) 20:25, 12 April 2021 (UTC)
I wasn’t able to reproduce the issue. I tried three random articles on German Wikipedia, each with a different browser (Firefox 78.9.0, Firefox 88, Chromium 89) on Debian GNU/Linux 10 “buster”, all of them seem to work. However, I’m not a developer of this tool, just wanted to collect some basic debugging data, so maybe a developer can find out what’s going on. —Tacsipacsi (talk) 23:20, 12 April 2021 (UTC)
@MassiveEartha, Mathglot, Tacyarg, Sennecaster, and Tacsipacsi: Thank you all for either reporting or testing the issue! I just conducted some basic tests of the tool, and it was working for me. In that case, can someone write a ticket on Phabricator with full steps to reproduce the bug (including the specific pages where this error occurred)? Once a ticket is written, we can investigate the root cause as a team. Thank you in advance! --IFried (WMF) (talk) 20:22, 15 April 2021 (UTC)
Seems to have been transient, as I cannot reproduce it now. Fwiw, I was using Vivaldi 3.5 (64-bit) on Windows 10. Mathglot (talk) 20:35, 15 April 2021 (UTC)
Okay, thanks for letting us know! We'll continue to monitor the situation, and please feel free to write a Phabricator ticket if the issue arises again. Thanks! --IFried (WMF) (talk) 20:38, 15 April 2021 (UTC)
The SSL certificate used by (the external service that powers Who Wrote That?) expired and that was the cause of this outage. It was fixed sometime around 00:00 UTC on April 13. MusikAnimal (WMF) (talk) 21:46, 15 April 2021 (UTC)
IFried Yes, it was transient and started working again, thanks. But unfortunately, now it's broken again. Mathglot (talk) 08:01, 14 July 2021 (UTC)
A-a-a-a-n-nnd, working again. Don't you just love transient problems? Mathglot (talk) 08:04, 14 July 2021 (UTC)
Mathglot Thanks for letting me know! I'm no longer on the Community Tech team, which manages the tool. So, in the future, if you experience issues, you can write a ticket in Phabricator and tag the Community Tech team in the ticket. Thanks! --IFried (WMF) (talk) 15:08, 14 July 2021 (UTC)
Return to "Community Tech/Who Wrote That tool/Archive 1" page.