Page MenuHomePhabricator
Search Advanced Search

Advanced Search
Use Results
Hide Query

Use the application-specific Advanced Search to set additional search criteria: Tasks, Commits. (More information)
  • T206451: Special:Watchlist does not refresh Chrome browser cache any more
    • Task
    Hi. # Open Special:Watchlist. # Close the browser. # Wait a while. # Reopen the browser on the same tab. Expected: an updated version of the watchlist. Got: the same version as in paragraph 1, from the browser cache. Started on last deployment. Recognized on Lollipop Chrome 68. Thank you.
  • T204298: When editing "raw watchlist", not all entries are loaded
    • Task
    I recently tried to edit my ~6,000 entries Watchlist on en-wiki using the raw watchlist editor feature. Unfortunately, I did not notice that only half of the entries were loaded and when I clicked save, ~3,000 entries were gone. I checked Phabricator but couldn't find a bug report about it. Since my watchlist is now smaller, I cannot reproduce it either.
  • T202632: Provide a link that opens all pages with changes since last visit in new tabs
    • Task
    [[https://www.mediawiki.org/w/index.php?title=Topic:Uj7w62a5lforw4i2|Based on this feedback on mediawiki.org]] The goal is to have a way to open all pages displaying changes that have happen after the last visit.
  • T200972: Modal for result and period control on new Watchlist/RCFilters missing bottom padding
    • Task
    The bottom part feels a bit short on margin. Made me think that the modal panel was actually clipped and I could scroll for more, but alas, there is not more, just a bit of missing padding/margin. {F24434289}
  • T200130: Wikibase-rc-wikibase-edit-title rendering
    • Task
    (Coming at this from English Wikipedia.) The special flags that are shown on watchlist and recent changes (r, N, m, b, !, D) are rendered with tooltips, and with a legend box. For the other flags, the tooltips are rendered with source message ([[ https://translatewiki.net/wiki/MediaWiki:Recentchanges-legend-minor/en | e.g. ]]), whereas the legend box shows the local MediaWiki message ([[ https://en.wikipedia.org/wiki/MediaWiki:Recentchanges-legend-minor | e.g. ]]). In the case of Wikidata however, both the legend box and the tooltips are rendered from the [[ https://en.wikipedia.org/wiki/MediaWiki:Wikibase-rc-wikibase-edit-title | local message ]], and not from [[ https://translatewiki.net/wiki/MediaWiki:Wikibase-rc-wikibase-edit-title/en | source ]]. Previously it contained a wikilink, which was removed per T98703. Now the tooltips is rendering html codes. So we have ``` Edit made at Wiki<span style="text-decoration: underline;">d</span>ata ``` Is there any way of fixing this so the legend box still has the markups, but not when the message is showed as a tooltips?
  • T199920: Changed preferences are not detected when opening/refreshing the watchlist with previously used settings
    • Task
    It is slightly confusing that when you change your preferences and refresh your watchlist, that these changed preferences do not take effect. This is because your previous settings are reflected in the URL, and these take preference over the defaults. It might be a good idea to track the integrity of the previously used defaults, and inform the user when a 'conflict' is detected. "Your preferences have changed since you last visited. Would you like to reload this page with your new preferences?" Would required some sort of edittimestamp being passed in the url params or something and conflict detection. Might be a good idea to apply this somewhat wider into the core of the preferences, as with the increase in dynamic content, this might start popping up in other areas with dynamic/single page logic too.
  • T199513: 'Restore default filters' on Watchlist may be no-op
    • Task
    Steps to reproduce: # make your preferences not exclude anything from your watchlist (ie. don't hide minor edits, bots, Wikidata edits etc. by default) # go to Special:Watchlist # ('Active filters' area should be empty) # notice there is 'Restore default filters' in the right bottom corner of 'Active filters' area If you click that button, nothing happens.
  • T198208: Change visible in article history, but not in extended watchlist
    • Task
    I'm using the extended watchlist (that shows all edits and not just the last one) and for one talk page there is a revision missing. This is what my watchlist shows for that page today: {F22681547} This is what the history of the page says: {F22681597} Affected page: https://nl.wikipedia.org/wiki/Overleg:Klavarskribo Missing revision: https://nl.wikipedia.org/w/index.php?title=Overleg:Klavarskribo&oldid=51861003 The affected revision is also missing from the recent changes
  • T194453: Spaces instead of css margin/padding in new Related changes
    • Task
    It seems a little strange to use spaces to align the lists in 2018. {F18162664} {F18162567}
  • T191832: Link MediaWiki.org Toolbar "Watchlist" to Special:EditWatchlist
    • Task
    I just want to see my open cases on [[Project:Support_desk]]. The "Watchlist" link in toolbar links to Special:Watchlist, which is sorted by date, like an activity log. Cases are repeated for each update, like an activity log rather than subscription list. At the least, the toolbar link should be more correctly called "Activity Log", not "Watchlist". It would be even more helpful if toolbar linked to Special:EditWatchlist instead, because that lists each case only once. Would be even more helpful if Special:EditWatchlist showed Open/Closed status. thx
  • T190003: Allow users to know why/how a page was added to their watchlist
    • Task
    Watchlist entries do not have history of how they were added or why. Some people put effort into identifying a reason for each of their watchlist entry, and in some cases do not see why it was added. I'd suggest to log watchlist changes: when and why a page was added to watchlist. For example April 3, 2011 Foo was added to your watchlist because you created the page April 12, 2011 Bar was added to your watchlist because you edited the page April 14, 2011 Baz was added to your watchlist because you added it to watchlist yourself
  • T187680: New watchlist/recent changes: Have an option to hide Wikidata edits by experienced and/or flood-flagged users
    • Task
    {F13874938} Sometimes my English Wikipedia watchlist (I'm using the new version) gets flooded by experienced Wikidata editors and/or bots using QuickStatements. I can't turn this off by excluding edits by "experienced" (500/30) users. It would be nice to be able to hide them, or alternately, to be able to hide all edits by specific users.
  • T186951: Show articles' size on Special:EditWatchlist
    • Task
    @Misibacsi [[ https://hu.wikipedia.org/wiki/Wikip%C3%A9dia:Kocsmafal_(m%C5%B1szaki)#Cikkm%C3%A9ret_a_Figyel%C5%91list%C3%A1n | would like to see ]] the size of the pages on Special:EditWatchlist. It would be useful to find the short ones. Special:ShortPages lists the shortest ones, but most of the time the results aren't relevant (hard to find one which would interest the user). Is it possible?
  • T186506: Opening a Thank notice marks unread revisions of watched page as seen
    • Task
    Hello. I strongly recommend High priority, despite it is not page content lost, but still, the user loses a lot of information. # User A has page X in their watchlist. # There are a couple (one is enough, but let's say 5) unseen revisions of X. # Before revision 1 there was their own revision of X. # User C thanks to user A for that revision. # User A gets notification about this thank. # User A clicks on notification and opens the thanked revision. # Unexpected result: Revisions 1-5 marked as seen. Recognized many times, including five minutes ago. But at least once it worked as expected. Thank you.
  • T186217: Wikidata changes in watchlists should order by time added rather than time change happened
    • Task
    This ticket comes from the RFC mentioned in T184000 This is how I interpret the issue: For users with very large watchlists, lag in changes being dispatched to clients can apparently cause 'new' changes for watched items to appear fairly far down the watchlist view. For example: - User is watching article A - Item Q1 is edited on wikidata (linked to an article watched by the user on the wikipedia) - 15 other articles are editing on the wikipedia the user uses and their changes appear in their watchlist - Dispatching of the change finally occurs 5 minutes later - The edit for Q1 / the linked page appears on line 16 in the watchlist? and can easily be missed? This should probably be tested and confirmed. A solution would be to order the entries in the watchlist by time added rather than time that the change actually occurred on wikidata.
  • T184278: Subscribing to the Atom feed of "Watchlist" for the first time requires resetting token?
    • Task
    === What happened? **TL;DR **: I had to reset my //Watchlist token// to subscribe to the Atom feed of my Watchlist for the first time. I just recently discovered from [[https://en.wikipedia.org/wiki/Wikipedia:Syndication#Watchlist_feed_with_token|Wikipedia:Syndication#Watchlist_feed_with_token]] that I could subscribe an Atom feed of my watchlist even when I'm logged out, cool! Anyways, it wasn't a "Follow the steps to get the desired results" thing. The step 3 seems to have become outdated. Anyways, I managed to discover the link to subscribing to the Atom feed in the left bar on my Watchlist page. I thought I could subscribe to the Watchlist at last. Unfortunately, I wasn't successful yet. I got the following error, ``` Error (bad_wltoken) Incorrect watchlist token provided. Please set a correct token in [[Special:Preferences]]. ``` Then I digged a little bit and found a link to //reset the Watchlist token// on my Preferences page. Only then was I able to successfully subscribe to the atom feed! == What's the issue? **TL;DR**: Requiring the user to reset the //Watchlist token// before he could subscribe to the Atom feed of his Watchlist for the first time. Now, coming to the issue, it doesn't seem to be a UX that every user should reset their //Watchlist token// to subscribe to the feed. Of course, I also suspect this is not intentional. ==== What do you expect? I expect to subscribe to the Atom feed of my Watchlist for the first time on different wikis without having to reset the //Watchlist token// on each of them manually. BTW, sorry in case the tag is the wrong one! I couldn't find a better one!
  • T182297: Provide user-curated tags on watchlist to ease user triage
    • Task
    From [[https://www.mediawiki.org/wiki/Topic:U3bpqd8mzypo5hb7|that idea]]. **Problem** At the moment, it is not possible filter pages on a watchlist by a personal key: article I'm working on now, community pages about sport, pictures that I have changed the description... **Possible solution** Have a way to tag pages added to the watchlist with some personal tags. Those tags are unique to the user and would complete other filtering options very well. Users can then filter by personal tags (and categories, namespaces type of edits... by potentially excluding them (T174349)) and [[ https://www.mediawiki.org/wiki/Help:New_filters_for_edit_review/Bookmarking | save those filtered queries ]]. This would also solve the need of {T3492}, a community whishlist item in 2015, 2016 and 2017.
  • T182220: Special:EditWatchlist/raw shows misleading message when trying to watch talk page without subject page
    • Task
    I was trying to watch a talk page without watching the corresponding subject page (which, I have been informed, is not currently supported). If I add just the talk page `Talk:Q42` on [[Special:EditWatchlist/raw]], the message is: >Your watchlist has been updated. 1 title was added: > >* Talk:Q42 (talk) But in fact `Q42`, both subject and talk, have been added, and opening [[Special:EditWatchlist/raw]] again shows that the actual added entry is just `Q42`. If I then change that to `Talk:Q42` (i. e., the content is the same as with my previous edit), the message is: >Your watchlist has been updated. 1 title was added: > >* Talk:Q42 (talk) > >1 title was removed: > >* Q42 (talk) But in fact, the watchlist again contains `Q42`. The behavior seems to be more or less intended (if you don’t want to support watching talk pages independently of subject pages), but the messages misleadingly suggest that this might actually be supported.
  • T181781: FOUC on line height in Recent Changes/Watchlist with combined items
    • Task
    While loading Recent Changes/Watchlist with combined items, the line height shifts, making content after the first or second collapsed item to slightly shift up, while the rest of the page is stable during load. See the screenshots (from https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Letzte_%C3%84nderungen?hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=30&enhanced=1&urlversion=2): {F11103322} {F11103324} Starting with the entry from 10:50 the contents slightly move up during load. This happens with disabled RC filters, too. It's also visible on the watchlist.
  • T181664: Highlight an item on hover on recent changes and other cases
    • Task
    [[ https://www.mediawiki.org/w/index.php?title=Topic:U2rt9ptfmwc31vwd | Initial report. ]] **Issue** As a user, I can't easily determine the beginning and end of a recent change item. It often has to struggle to see where the entry ends when there are a lot of very verbose changes. **Proposed solution** Add css to highlight the specific line on mouse hover, e.g.: ``` .mw-changeslist-line:hover { background: lightgray; } ```
  • T181220: Timeless watchlist and recent changes grouped edits have different font size
    • Task
    Hello. Opt in grouping by page in preferences. * In recent changes, grouped edits font is smaller than single. * In watchlist, grouped edits font is larger than single. Checked with safemode. Recognized on Android.
  • T180906: Add a deeplink from Special:Watchlist to watchlist in Special:Preferences
    • Task
    As a user, when I'm visiting my `Special:Watchlist` page it would be good to know about the existence of `Special:Preferences#mw-prefsection-watchlist` as these settings effect the behaviour of `Special:Watchlist`. There are already several links to editing your watchlist from `Special:Watchlist` but there is no mention of the watchlist configuration in `Special:Preferences` which effect the behaviour of `Special:Watchlist`. For example, settings under `Advanced Options` control what defaults are set on `Special:Watchlist` and settings under `Display options` can stop any results from loading on `Special:Watchlist` at all (although this doesn't appear to be intended behaviour - see T176033). This deeplink could be added to `mw-watchlist-toollinks` at the top of the page so instead of displaying: > For username (View relevant changes | View and edit watchlist | Edit raw watchlist | Clear the watchlist) It might instead display: > For username (View relevant changes | View and edit watchlist | Edit raw watchlist | Clear the watchlist | Edit watchlist preferences) For the discussion on what caused this enhancement request see: T176033.
  • T179010: [C-DIS][SW] Re-enable Wikidata Recent Changes integration on Commons
    • Task
    Injecting recent changes from Wikidata is currently disabled on Commons: ```lang=php,name=wmf-config/InitialiseSettings.php 'wmgWikibaseClientInjectRecentChanges' => [ 'default' => true, 'commonswiki' => false, // T171027 'testcommonswiki' => false, // T171027 ], ``` With T177707 and T173194 being solved it should be ok to re-enable Wikidata Recent Changes integration on Commons. Let's reenable it and monitor if everything is ok.
  • T178038: Rebuildrecentchanges.php should regenerate CatWatch entries
    • Task
    When running rebuildrecentchanges.php, the script should regenerate CatWatch entries if the feature ($wgRCWatchCategoryMembership) is enabled. Page moves are followed, so that if the entry previously said "A added to category" or "A removed from category" and A was moved to B, the entry would instead say "B added to category" or "B removed from category" after running the script.
  • T177697: Text size on Watchlist repeatedly changes in desktop mode using mobile Safari
    • Task
    When I open my watchlist in Desktop Mode on my iPhone, the text will sometimes oscillate between two different sizes. This is reproducible, but intermittent, and it usually goes away after a refresh. Example: {F10056681} This happens with MobileSafari on an iPhone SE running iOS 11.0.2. It has happened for a while, but I hadn't gotten around to filing a bug report.
  • T176064: Add method to WatchedItemStore to retrieve all watchers of a page
    • Task
    While this won't be useful for Wikipedia, it will help people who write extensions that run on corporate wikis. As far as I can tell there is no standard method to get the watchers and this is useful information for tools like CategoryWatch.
  • T174256: Move watchlist unwatch link away from grouping expand triangle
    • Task
    Hi. There is a new unwatch "x" button in watchlist. Great job, but could you please move it elsewhere in the line? It's too close to group mode "expand group" button, and can't be pressed unintentionally, especially in mobile touchscreens. For example, after the timestamp before the page name, or some another position. Thank you.
  • T174176: Special:Contributions should indicate which items are already on your watchlist
    • Task
    In Preferences, users will eventually discover [] Add pages and files I edit to my watchlist They will say that is a great idea, and enable it. But then they will say "what about all those pages I edited when it was unchecked? I wish Contributions had (solid) stars next to pages that are in my watchlist, so I can tell which of my Contributions aren't in my watchlist already (and perhaps even click on empty stars right there in Contributions to add them to my watchlist!)"
  • T173121: Rank wikidata changes for patrolling by usage
    • Task
    Patrollers on client wikis will likely want to prioritize patrolling of changes to Wikidata entities that are most relevant to their client wiki (e.g. used a lot). Similarly, Wikidata patrollers will likely want to prioritize patrolling changes to Wikidata entities that affect many pages on many client wikis. We can use nuanced entity usage information to help prioritize these changes for patrollers.
  • T173119: Implement more nuanced patrolling relevant changes in Wikidata based on usage
    • Task
    Once we have (LINKME: more nuanced usage tracking), we should be able to use it to direct patrollers' efforts more effectively. E.g. we can make sure that only changes that affect the rendering of a page show up on a users' watchlist (T90436) and we can direct patrollers' attention to changes that affect the rendering of a lot of pages across client wikis (T173121).
  • T173089: Watchlisting confirmation dialog interrupts editing
    • Task
    In old wikitext editor, I am in middle of editing and I want to mark the page for watchlisting. I click on the "star" icon. Expected behaviour: the star is coloured , the page is watchlisted, I can continue editing. Actual behaviour: a dialog is opened and I am asked to confirm the watchlisting. After confirming, the page is reloaded, **all my editing progress is lost**. This must be a new behaviour, I cannot remember this from past. I don't know who invented this, but this is not a progress, this is a serious drawback. I would gladly pass about confirmation of watchlisting in spite of uniterrupted editing. Especially when "un-watchlisting" can be done in one click too.
  • T172352: Consolidate Preferences: New UX on RC AND Watchlist (option #1)
    • Task
    This version of preferences is displayed to users who have the new UX on RC page and Watchlist (either because they've opted into the beta or, down the road, because these are standard or, in the interim, a combination of the two). The many small changes made in the new design to wording and layout are too numerous to note individually. So, for layout of the page, see the screenshot below, under "**Layout**." To get correct wording, copy and paste the text in the "**Wording**" section. (Copy and paste is safest because so many, many small wording changes have been made.) For all old-style preferences, see T172757 for details about how to convert to equivalents in the new UX. =Layout, Option #1 Please consult this graphic for details about grouping and order of items, indentation and variation among text styles - All styles in the mockup are meant to indicate existing styles on the Preference page - Please note that as now, to help users distinguish among page sections more easily, vertical spacing between the last item in a section and the following section title is greater than spacing between the first item in a section and that section's own title. {F9102789} =Wording Copy final wording from [[ https://docs.google.com/document/d/1P68RN3hiQ3veKVQvhqa9suzIfBJymNYZBvwXfXfoggo/edit#heading=h.bfzo6p4c8tok | section #1 of this document ]]. =Functional Changes, Option #1 This section will single out for description only the functions and behavior which change in the preference consolidation. I.e., unless discussed, functionality will be the same as previous to consolidation. Some significant layout changes are mentioned, though you should check the Layout section below for further details. It's important to read each item carefully, because even elements that appear to be the same from one version to the next may have slightly different behavior (or titles) in different versions of these preferences. All such differences have been noted. ====Number of edits to show section - Number of edits becomes a section of its own. - As before (though it was not fully stated), this control sets the default number of changes to show on History, Contributions & Logs pages. RC page, however, is no longer covered by this control (and WL always had a separate setting). - We will set a new maximum number for all these pages of 500. - The header reads "Number of Edits to show on History, Contributions & Logs" ====Revision Scoring on Contributions page section - On ORES wikis, Revision Scoring becomes its own section, - This section, which controls the "classic ORES" features, appears on ORES-enabled wikis only. - The controls apply to all pages on which Classic ORES is available. On this version of preferences, this is Contributions only. - The section title reflects that: "Revision Scoring on Contributions page" - A new subline describes the controls. The subline contains the word "ORES," which links to https://www.mediawiki.org/wiki/ORES - The functions in this section have been re-ordered for clarity, and the small gray instruction text for the menu has been reworded. ====Watchlist section - All Watchlist preferences that pertain to filter settings have been removed. - The following option is defunct and is also removed: "Reload the watchlist automatically whenever a filter is changed (JavaScript required)" - Note: as now, the option "Always add pages I review to my watchlist" appears only for users who have the reviewer right. This option has been reworded, however. - [After Watchlist beta graduation, a New Filters opt-out will be added to the section; this is handled in T173542] ====Recent Changes section - PRIOR TO RC PAGE GRADUATING FROM BETA -- The Recent Changes preference section contains no preference options. -- It includes only a notice to users that "Recent Changes filter preferences can now be managed on Recent Changes itself...." [see "Wording" document, link below, for full and final wording]. --- If possible, this notice will be preceded by a bookmark icon. - AFTER RECENT CHANGES BETA GRADUATION -- The notice about how preferences are managed on RC page itself is still displayed. -- In addition the New Filters opt out language and check box (T168376) are displayed. ====Pending Changes - No changes were made to this section. - (As now, there is a preference that shows u only if you have the reviewer right: Show the difference between the accepted and latest revisions when viewing the latest pending revision)
  • T172350: Consolidate preferences for all 'Change Monitoring' pages
    • Task
    As part of completing the New Filters for Edit Review project, it's desirable to consolidate the preferences currently spread across the Watchlist and Recent Changes preference tabs into one tab, named "Monitoring changes." Two main considerations recommend this course: # The current arrangement is disorganized and illogical. The two tabs already control behavior on an odd mixture of pages for which no tabs exist, including History, Logs and Contributions. A consolidated tab with sections named for the relevant pages will more accurately reflect the functionality presented. # The New Filters UX enables users to save default page settings directly on RC page and Watchlists—a clear win for usability. When this capability is fully in place, having a parallel system for setting defaults on the Preferences pages is confusing and messy. Once such duplicative preferences are removed, however, the relatively small number of Watchlist and RC page preferences that validly remain aren't numerous enough to justify two separate Preferences tabs. In addition to being more logical, a unified tab enables us to more neatly manage the four possible states that a user can move through with respect to Watchlist and RC page. These four states and the functionality that pertains to them are described on the following four tickets. In addition, a fifth ticket describes the rules that will govern migration and conversion from the old system to the new: - {T172352} - {T172349} - {T172468} - {T172474} - {T172757} =Requirements - When a user moves to the New Filters UX, all user preferences from the old system will be transferred to their equivalents in the new UX for that user (see T172757 for details of old-to-new translation). - When New Filters users bookmark settings to the Saved Filters menu, and declare those settings Default (using the "Set as default" option), the default on-page settings override any existing page preferences that were set on the Preferences pages. - Many existing user preferences will no longer be visible on the consolidated "Change Monitoring" preference page (as detailed in the four subtasks above). However, all such hidden preferences will be stored for each user. - In the event a user opts out of the New Filters on RC or WL or both, all their old preferences, including the hidden ones, will be restored. (Their OLD preferences will be restored; i.e., we don't need to send on-page defaults "upstream" to be stored as hidden preferences).
  • T171717: Allow seeing the diff of all changes since last visit directly from Special:Watchlist
    • Task
    **Current steps to see the diff of all changes since last visit of some watched page** # Go to Special:Watchlist # Click on history (`hist`) next to a page you want to compare # Click on current (`cur`) next to a revision which is the first **not** marked with limegreen highlighted `changed since last visit` label **Proposed steps to see the diff of all changes since last visit of some watched page** # Go to Special:Watchlist # Click on some link or button to see it directly from watchlist
  • T171527: [minor] Watchlist: when "Expand watchlist to show all changes ..." option is not enabled, the counter for last changes still counts all changes
    • Task
    1. In Preferences - Watchlist do not enable "Expand watchlist to show all changes ..." 2. Make several changes to a page that's on a user's watchlist. 3. The Watchlist will display the real count (i.e. the count of multiple changes on the watched pages), though UI displays only the most recent changes: In the screenshot, UI says: "Below are the last 20 changes in the last 168 hours", but only 7 changes displayed {F8837963} Another example - "Below are the last 13 changes in the last 72 hours" and only two changes are displayed. {F8837945}
  • T168527: Popular Pages in Watchlist
    • Task
    Similar to the list of popular pages in WikiProjects, I would like a ranking of the popularity of pages on my watchlist. This is helpful to me as a contributor to know which of the articles I have worked on and am interested in will have the greatest impact if improved further.
  • T166976: Watched Talk/Discussion subpages of deletion requests should be shown in watchlist
    • Task
    When a deletion procedure is engaged in fr.wikipedia, a Talk subpage is created with the name Discussion:<Titre d'article>/Suppression. Subpages for a watched page appear in the watchlist in the main name domain. They do not in the Talk (fr : Discussion) name domain. They should, if possible. Presently, contributors must add the delete (fr : Suppression) subpage to their watchlist after the deletion tag in the main page warns them, in although this subpage should be short-lived.
  • T165771: AJAX Watchlist: can re-trigger after button is hid
    • Task
    With the AJAX-based "mark all as read" button (T150045), the button is hidden after it's clicked. It's still possible to trigger it again i.e. by just hitting the enter key when the button is hidden but still focused from the click. This makes it more likely to accidentially mark never shown changes as read.
  • T164232: Provide "RC Filters" functionality on all pages that show sets of changes (or consolidate them as filtered views of RecentChanges?)
    • Task
    [x] RecentChanges [x] RecentChangesLinked [X] Watchlist [] Contributions [] NewPages [] NewFiles [] Special Logs [] …?
  • T163098: Fix the Watchlist visual layout
    • Task
    Problem: the hopelessly inefficient use of space in the Watchlist (below is relative to enwp, but the issue is general to Mediawiki across projects). On a brand spanking new high-end laptop with a high-res 15" screen, the usable space of the Watchlist is as follows: {F7588789} That's a hell of a lot of wasted space that could have been used for the content I actually care about with a few simple changes (bonus points for hiding/minimizing the left sidebar, but politics will shoot that down even as a user preference off by default): {F7588790} The effect on usable space would be pretty dramatic (especially if you could move the article title, "Watchlist", up above the tab bar, "Special", or where "Read"/"Edit"/etc. are for mainspace articles): {F7588791}
  • T162833: Special:Watchlist creates wrong diff links for watched revisions
    • Task
    Hello. There is an example below, but for now, some explanations. You have two revisions for the same page. The first is old_revid=1000, revid=2000. The second is old_revid=2000, revid=3000. You want to see them both at once, so you need old_revid=1000, revid=3000. You definitely don't want to replace them axidentally, taking the start and the end from the wrong revision, so you'll get old_revid=2000, revid=2000. You'll see that there are no changes, because it's the same version, and will miss these two revisions. Now the example: # Login to hewiki. # Open preferences. # Remove all the watchlist view limitations, as bots and categorizations, so you can see all. # Turn on watchlist grouping. # Turn off show last revision only. # Save preferences. # Add the page [[https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%AA%D7%91%D7%A0%D7%99%D7%AA:%D7%94%D7%A1%D7%A8%D7%AA_%D7%94%D7%9E%D7%99%D7%9C%D7%94_%D7%AA%D7%91%D7%A0%D7%99%D7%AA|*]] to the watchlist. # Open Special:Watchlist. # See this page at April, 12, 2017. # It was edited twice. # See the http address of "2 changes" link. # It's [[https://he.wikipedia.org/w/index.php?title=%D7%A9%D7%99%D7%97%D7%AA_%D7%AA%D7%91%D7%A0%D7%99%D7%AA:%D7%94%D7%A1%D7%A8%D7%AA_%D7%94%D7%9E%D7%99%D7%9C%D7%94_%D7%AA%D7%91%D7%A0%D7%99%D7%AA&curid=1294108&diff=20532942&oldid=20532942|*]]. And if you want to know why does this happen, see T149558 I filed in October, it can help.
  • T157070: Watchlist token doesn't work in API
    • Task
    Per [[ https://www.mediawiki.org/wiki/Topic:Tk8pb7y7k49ac2v6 | this discussion ]], the default watchlist token presented to the user is not actually saved in the database and will therefore not work. See Anomie's final comment in that discussion for more detail on the specifics.
  • T154196: Watchlist entries are sometimes shown as bold/unread even when the edit was made by the user
    • Task
    Sometimes, your own edits appear in your watchlist as "unread". Reported at https://www.mediawiki.org/wiki/Topic:Thzvj31bl432n0a4
  • T153536: AJAX Watchlist does not completely work with expanded Watchlist: Ignores single changes from sequential ones
    • Task
    The new behaviour of "mark everything read" from T150045 does not affect the single changes from sequential ones (CSS-Class mw-enhanced-rc-nested) in the extended watchlist. They stay marked as unread until reload.
  • T153533: AJAX Watchlist does not refresh
    • Task
    The new behaviour of "mark everything read" from T150045 does actually take more time for users, as they need to manually refresh the page afterwards. Even if this would be done automaticly it would propably take longer than just one request for marking as read and refreshing. Also this still marks everything read, even changes new enough to not yet beeing shown. In combination with this issue, this makes it even more likely than before for users to accidentially mark changes as read without even noticing.
  • T151165: Increase the number of entries shown on the watchlist (wllimit)
    • Task
    Problem: Restricted limits on watchlist views, make it hard to keep up with changes, if we're not continuously active on a wiki. Two proposals in the 2016 community wishlist, propose increasing the "1,000" page limit currently given in wllimit as shown in `Special:Preferences#mw-prefsection-watchlist` e.g. https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-watchlist I'm filing this to get a technical response on: * Are there performance concerns with increasing this limit? ** If so, could they be resolved by only increasing the limit for certain user-groups (and how complicated would that be)? * Are there any other concerns? -------- Suggested in: * https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Watchlists#Quickly_open_a_diff_for_the_changes_since_one_last_checked_a_page (comments) * https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Watchlists#Watchlist_drop-down_options_with_less_restrictive_defaults See also: * {T210897} * {T20228}
  • T149558: Watchlist and recent changes edits in the same minute are sorted wrong.
    • Task
    Hi. If there are two edits in the same minute (**removed**: of the same page), they can be sorted wrong. Here is an example, in regular and grouped mode, of some page where its creation edit appears after the next one: {F4679780} {F4679775} And here are four examples in recent changes, same timestamp: {F4679803} Thank you. **Edited**: It happenes anywhere, not just with the same page. The sorting is in opposite direction.
  • T148649: Display an entry for page in watchlist when page protection expired; Display an entry in user page when user blocking expired
    • Task
    Hello. When some page is protected, the user that watches it can see the logger entry in the watchlist. But when the protection expired, there is no message, because it is done automatically. Think about this example: autopatrolled level page gets sysop protection for a year. After that it changes to nothing. And nobody knows it should be protected as autopatrolled again. Could you please create a dummy user that will "remove" the protection when it expires? So there will be new entry in watchlist: "loggerboy changed page protection from sysop to nothing at date", and it will appear in watchlist? And the same for user blocking expiration in user page. Less important, but a notification for the sysop that made protection or blocking in the first place can improve the previous part, but not replace it. Thank you.
  • T148533: Categorization in watchlist different in nongrouping mode: "(diff | hist)" are plain text and no links
    • Task
    Hi. Something strange. I allways use grouping mode for watchlist and recent changes in preferences. Today I removed it for a couple of minutes to check something, and saw that all categorigation entries do not have diff links. The words "( diff | history )" are just a plain text, without links. As I know it works well in grouping mode, so I'd like to understand: Was it done in purpose? Thank you.
  • T146574: Watchlist emails should be sent in the user's language
    • Task
    Currently, watchlist emails (i.e. [[https://translatewiki.net/wiki/MediaWiki:Enotif body/en | MediaWiki:Enotif body]]) are sent in the wiki's default language. It would be better if they were sent in the user's preferred language, like Echo emails. ----- **See Also:** {T146147}
  • T146558: Unify watchlist categorization behavior: "mw-watchlist-line-not-watched" vs. "mw-watchlist-line-watched"
    • Task
    Hi. Could you please unify the behavior of categorization edits in watchlist. Every day a half of them gets css mw-watchlist-line-not-watched and another half mw-watchlist-line-watched. I don't know what is the right one, but it is hard to work in such a dilemma. Thank you in advance.
  • T145562: "MediaWiki:Enotif body" should support GENDER
    • Task
    Currently, **[[ https://translatewiki.net/wiki/MediaWiki:Enotif body/en | MediaWiki:Enotif body ]]** does not support GENDER. In some languages, the text of this e-mail varies according to the gender of the receiver, so this is very important for GENDER to work.
  • T144179: Marking notifications about Flow topics/boards as read should also unbold them on Special:Watchlist
    • Task
    Hi. If you have flow notice (I believe, any kind of it) and use blue point to mark it as read, it does not change the "mw-changeslist-line-watched" css style to "mw-changeslist-line-not-watched" on Special:Watchlist refresh. Thank you.
  • T142329: Can't access large watchlist on nlwiki: 503 error
    • Task
    I can't access my watchlist on nlwiki. When I go to [[https://nl.wikipedia.org/wiki/Speciaal:Volglijst]] I get either a 503 message or a blank page. This is the extra information provided by the 503 page: Request from 89.98.115.38 via cp1066 cp1066, Varnish XID 964164997 Error: 503, Service Unavailable at Sun, 07 Aug 2016 08:40:29 GMT I can access my Watchlist on Wikidatawiki and enwiki ----- See Also: {T123213}
  • T140214: Make e-mail notifications clearer and more precise on page renames
    • Task
    If you get a notification about a page move, it may be accompanied by a link-look-alike to the page, so the wording, but link fails. In order to get to the page with its new name, you have to go through some loops and hoops on the target wiki. Even more so, when things were changed after the e-mail generation and you were not notified because you were not quick enough to read the e-mail and respond to it keeping the notification process. Readers of the message are not informed whether watching and/or notifications would continue with the old page and its old name, even if it does not exist any more, or it is inherited by the new page and the new name, which of those they need to open at least once to keep being notified. Yes, one can look all that up in the wiki, if one is inclined and knows the details. I want notification messages that state every aspect clearly, that have links to the previous and the new pages names. The rest is a sample message making clear that it is sub-optimal in the sense mentioned above :-) > Dear Purodha, > > The MediaWiki page Translations:Help:Notifications/77/ksh has been moved > on 12 July 2016 by Trizek (WMF), see > https://www.mediawiki.org/wiki/Translations:Help:Notifications/77/ksh > for the current revision. > > Editor's summary: - > > Contact the editor: > mail: https://www.mediawiki.org/wiki/Special:EmailUser/Trizek_(WMF) > wiki: https://www.mediawiki.org/wiki/User:Trizek_(WMF) > > There will be no other notifications in case of further activity unless > you visit this page while logged in. You could also reset the > notification flags for all your watched pages on your watchlist. > > Your friendly MediaWiki notification system > > -- > To change your email notification settings, visit .....
  • T138236: Open flow link from notification popup doesn't affect watchlist
    • Task
    Hello. If you open the blue notifications popup and then press on the notification to flow change, the change opens, but the edit is not marked as read. I do not know if it happens in all kinds of flow notifications, but it does happen in new topic on watched board, and at least in one more, do not remember each one.
  • T135000: RevisionDelete entries on Special:Watchlist should link to Special:Diff and Special:RevisionDelete
    • Task
    Entries on Special:Watchlist for revision deletion events currently look (to those with sufficient viewing privileges) like this: > 12:00 (Deletion log) Admin (talk | contribs | block) changed visibility of a revision on page Example: content hidden ‎(Reason) The equivalent entry on Special:Log/Delete for "Example" is: > 12:00, 10 May 2016 Admin (talk | contribs | block) changed visibility of a revision on page Example: content hidden ‎(Reason) (diff | more...) "diff" is a link to Special:Diff, "more..." is a link to Special:RevisionDelete.
  • T133609: Watchlist gives gives extra/empty lines when expanding nested changes from topics on a flow board
    • Task
    Strange extra empty lines appears when expanding the nested changes in topics. See illustration. First reported onwiki at https://no.wikipedia.org/wiki/Topic:T2sg1u8770i4x00h {F3930193}
  • T132569: [Task] Refactor Special:RecentchangesLinked to use WatchedItemStore
    • Task
  • T132568: [Task] Refactor Special:Recentchanges to use WatchedItemStore
    • Task
  • T130888: Category addition/removal should be displayed in the watchlist independently of further edits on articles
    • Task
    Currently, a user watching a category sees an addition/removal in the category only if the change in the last edit on the article (I assume that the preferences "Hide categorization of pages" and "Expand watchlist to show all changes, not just the most recent" are not checked). This was originally reported on [[https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/24_mars_2016#Suivi_des_mouvements_dans_les_cat.C3.A9gories|fr.wikipedia.org/wiki/Wikipédia:Le_Bistro]]. Steps to reproduce on test.wikipedia.org: - Watch "Category:Test category" - Add this category to any page ([[https://test.wikipedia.org/w/index.php?title=Sandbox&diff=265632|edit 1]]) => the addition of the category is visible in the watchlist - Edit the page again ([[https://test.wikipedia.org/w/index.php?title=Sandbox&diff=next&oldid=265632|edit 2]]) => the addition of the category is not visible anymore. Expected behavior: editing an article after changing categories should not hide its addition or removal from a category in the watchlist. Instead, not enabling the preference "Expand watchlist to show all changes, not just the most recent" could have the effect of showing only the last change for a each watched category (although I am not sure whether such a restriction is desirable as long as there is no other place to view the history of those changes for a specific category). The current behavior has the drawback that a significant fraction of additions are never shown, for instance new articles created in multiple edits.
  • T130504: Some users are recognized as bots in recent changes and watchlists
    • Task
    Hello. Something I can see again and again last week (don't know if was earlier): there are some edits marked by "b" (bot) in recent changes and watchlists for regular users. I saw this only in catwatch (don't know if can be in other edits), only in tracking categories of commonsmetadata (as [[Category:Files with no machine-readable license]], don't know if can be in other categories). I asked one of our admins: "You just uploaded two files, only one of them as a bot. Was there any difference in your work? Different tools, different parameters and so on", and the answer was "All the same". Here is an example from today: The User:Avi1111 is a medicine doctor, I don't believe he can also be a robot, the patients will scream and run away. {F3677177} Could you check this, please?
  • T130134: Watching (only) categorization (additions and removals) of an arbitrary category
    • Task
    Watchlist can show you all category changes of a watched category. What I really miss is a possibility to only watch additions and removals of an arbitrary category (I don't want to add a category to my watchlist to see recent changes). Using RelatedChanges/RecentChangesLinked is not useful because it shows only additions because when a page is removed from the category, it is no longer linked, ~~and options don't allow you to only have categorization changes shown~~.
  • T129710: Allow e-mail notifications about changes of watched pages without having to log in and load the entire pages again.
    • Task
    e-mail notifications about changed wiki paged are halted until a user downloads a newer version of the page while logged in. If one has seen the page already while not logged in as this user, or if one does not want to have he entire page transferred over the net when reading his e-mail, etc., one should have a lightweight link in the e-mail body telling the wiki to return the watched page to the "seen" state. ("continue notifying me") Likely, this could be had similarly to the mechanism putting a page on ones watchlist via the star icon of the vector skin, which also does not reload the page.
  • T129478: Refactor watchlist related code to use WatchedItemStore
    • Task
    The list of places that could be refactored into a WatchedItemStore include: See subtasks for items that still require action
  • T129255: [Bug] Email notification of a Wikidata page change should contain relevant links
    • Task
    As an editor who has: * a page watchlisted (e.g. on metawiki) * the Preferences setting enabled for `Email me when a page or a file on my watchlist is changed` * the Preferences setting //disabled// for `Show Wikidata edits in your watchlist` If the (metawiki) page's associated Wikidata item is changed, then Current results: * I receive an email saying that the (metawiki) page was changed, without any clue about what actually changed. Expected results: * If the preference is //disabled// for `Show Wikidata edits in your watchlist` - then don't send an email at all * If the preference is enabled - then send an email with a clear description/link for what changed and where. ----- For example: I just got the following email. > Dear Elitre (WMF), > > The Meta page VisualEditor has been changed on 8 March 2016 by > anonymous user 99.244.30.79, see > https://meta.wikimedia.org/wiki/VisualEditor for the current revision. > > See > https://meta.wikimedia.org/w/index.php?title=VisualEditor&diff=next&oldid=15293484 > to view this change. > > See > https://meta.wikimedia.org/w/index.php?title=VisualEditor&diff=0&oldid=15293484 > for all changes since your last visit. > > Editor's summary: Language link added: [[:cy:Wicipedia:Y Golygydd > Gweladwy]] This is a minor edit > > Contact the editor: > mail: No email address > wiki: https://meta.wikimedia.org/wiki/User:99.244.30.79 > > There will be no other notifications in case of further activity unless > you visit this page while logged in. You could also reset the > notification flags for all your watched pages on your watchlist. > > Your friendly Meta notification system I couldn't find any traces of that edit though, so I checked on Wikidata, and [[ https://www.wikidata.org/w/index.php?title=Q11168190&type=revision&diff=311105113&oldid=306616087 | found it there instead ]]. The message is confusing.
  • T129199: CatWatch does not recognize logger actions like deleting pages
    • Task
    The new catwatch feature does not show deleted pages as excluded from category and undeleted pages as included back to category.
  • T128352: RfC: Need to merge Notifications and Watchlist or lack thereof
    • Task
    ## Summary Proposal to merge Notifications and Watchlist into one * Show items pertaining to both public events (edits) and personal events (thanks). * Have a settings pane, similar to what Notifications currently has, except * a 'watchlist' column would be added to indicate whether I'd like to get these events piped to my watchlist, and * a 'watchlist edits' row would be added so that they could be mailed or "nagged on the web" for me. Some benefits: * Filtering Watchlist like people can filter a Recent Changes list when it's got too many items; * Adding and removing pages to watchlist; * Filtering a watchlist by namespace; * General simplification of our infrastructure ## Details See <https://www.mediawiki.org/wiki/Requests_for_comment/Need_to_merge_Notifications_and_Watchlist_or_lack_thereof>
  • T126851: [CatWatch] Find a unconfusing/specific way how to display CatWatch changes
    • Task
    The current displaying of CatWatch items as regular edits on various places(*) is rather confusing as it looks like the regular edit. - {T126428} - {T126849} - They mix up with regular edits to such category. - On IRC feed it's totally impossible to distinguish if it was an edit or CatWatch action. (*) - RecentChanges - WatchList - IRC feed - RCStream Find a different way how to display CatWatch changes on various changes list. Logged activities have their own log action format, both on changes list as well as on IRC feed. CatWatch actions should have their own as well. Based on the IRC chat: A flag "C" (like !NMbD) was considered, but it would be only solution for IRC feed to distinguish CatWatch actions from regular edits, however it would not remove the mixing of CatWatch actions and regular edits on on-wiki changes lists. Logbook won't work either since it would group all CatWatch actions to single one on enchanced RecentChanges/Watchlist, while the purpose is to see each category (but not single CatWatch actions in it) separately. Thus some kind of third way should be found.
  • T126486: Adding to Watchlist sometimes opens two additional windows
    • Task
    Adding to Watchlist sometimes opens two additional windows: https://commons.wikimedia.org/wiki/File:Watchlist.jpg [[:File:Watchlist.jpg]] https://commons.wikimedia.org/wiki/File:Watchlist-1.jpg [[:File:Watchlist-1.jpg]] P.S. It happens while sending thanks as well: [[T118865]]
  • T125657: Gray used in .autocomment in RC and watchlist is not accessible against background and hinders link discovery
    • Task
    This was originally brought up at [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_129#Darker_section_titles_in_page_history | en.WP VP proposals#Darker section titles in page history]]. A subsequent commenter noted that the text was [[http://snook.ca/technical/colour_contrast/colour.html#fg=808080,bg=FFFFFF | not even AA compliant against the background]] (except with 18pt font). We think we've found an acceptable AAA-compliant color with [[http://snook.ca/technical/colour_contrast/colour.html#fg=585858,bg=FFFFFF | #585858]]. My recommendation would be the lightest-gray that achieves AAA compliance, and #585858 just happens to be the color on which we settled. One of the issues with increasing the autocomment's contrast to the background is with the following .comment text, which is the edit summary-proper. We've been exploring ways of increasing the contrast between these two texts also: * Change .autocomment to straight letters * Change .comment to straight letters, setting CSS for .autocomment to italics * Change .autocomment to use font-weight: lighter (seem to work against desire to increase contrast). There may be other styles to explore in that regard. {F27379168 size=full}
  • T125293: Expose logid in logbook query and watchlist
    • Task
    With T71107 we got the capability to link to a particular action. This is great, thank you. Now, how shall poor users guess the //logid// from GUI? Currently that can be retrieved by API only. === Request === Expose //logid// in every related entry of * //Special:Log// query result * //Special:Watchlist// (+RC, same code) Best place might be in brackets after datetime before executing nick for :Log, and close to the log name in :Watchlist. * //2016-01-30T01:23:45 (#12345) PerfektesChaos (talk|contribs) nuked the www// * //(Block log #12345); 12:34 . . SuperUser (talk|contribs) blocked TheVandalismHimself// Format the ID ##12345## as link like #[/wiki/Special:Redirect/logid/12345 12345] – giving users the opportunity to grasp and save that URL somewhere, or to extract easily ##[[Special:Redirect/logid/12345]]##.
  • T122762: Problematic usage of the wikibase-rc-hide-wikidata message
    • Task
    This message is also used as checkbox label on Special:Watchlist, and its $1 is empty. About Japanese translation, the checkbox label "Wikidataを" is inconsistent with other labels and is incorrect. Correct translations: - "Wikidataを表示” (with "show" link) - ”Wikidataを非表示" (with "hide" link) - "非表示: ... □Wikidata" ("hide:" and checkboxes) ---- **URL**: [[https://translatewiki.net/wiki/MediaWiki:Wikibase-rc-hide-wikidata/en]]
  • T120093: Remember user settings in the watchlist
    • Task
    Now the watchlist does not remember the settings the user specifies during a session (Show last, Hide, Namespace, etc). Please implement the remembering of user settings.
  • T118540: Allow adding pages to the watchlists of new accounts, either by default or during manual account creation
    • Task
    For better integrating/onboarding newcomers, it would be useful to pre-populate their watchlist with a handful of important pages, such as village pumps and their equivalents. E.g. All new self-created accounts on a wiki could have the local village pump (and helpdesk, or anything) watchlisted, by default. E.g. When a new [chapter board member, or developer on a specific team] has a new account created, the [[https://www.mediawiki.org/wiki/Project:Account_creators |account creator]] could add a list of pages like "other board members' userpages and the village pump", or "other team members userpages and relevant extension pages" to that newcomer's watchlist. (The current manual alternatives are: Create a list, and ask each newcomer to either copy&paste that list to their own [[Special:EditWatchlist/raw]], or to visit and watchlist the pages one by one.)
  • T117282: watchlist notification should say if other pages will still have notifications
    • Task
    Regarding the notification: "There will be no other notifications in case of further changes unless you visit this page. You could also reset the notification flags for all your watched pages on your watchlist." It is not clear if you mean "no other notifications for any page on your watchlist for this entire site" or just "no other notifications for just this page, but still notifications for other pages on this site on your watchlist". Also you might want to emphasize they must be logged in for their visit to count. And if just visiting the site counts, or must they really visit the page, and not the Talk page, etc.
  • T116971: Special:Watchlist takes 23 seconds to start loading on mediawiki.org
    • Task
    Since several days (perhaps a few weeks), https://www.mediawiki.org/wiki/Special:Watchlist takes many seconds to load (23 seconds time to first byte right now), every single time I attempt to open it. As I removed all "Thread" pages from watchlist before the LQT conversion, I only have 3300 pages in watchlist. I use 0 days, 1000 changes, extended watchlist and enhanced watchlist in https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-watchlist , which is arguably the heaviest configuration possible, but hardly extraordinary with so few pages. On all other wikis, things are still fine, hence I suspect this has to do with Flow. Can someone provide a script or trick to remove all pages with a Flow talk page from my watchlist, to verify?
  • T109759: [CatWatch] Request for blocklist/allowlist feature for category addition watchlist
    • Task
    I'm glad that a watchlist page switch was added so soon. Me and some other Wikimedia Commons users with high-traffic cats on their watchlist are hoping for a feature that enables separate opt-in/opt-out choices (whitelist/blacklist) for specific categories. Preferably one that does not require copy-pasting or typing every cat name by hand. Commons deals with entirely different levels of category traffic than the text-based projects, and "power users" typically have massive watchlists with a lot of categories they follow in order to know if someone is making edits that need attention or editing the cat talk. As things are now, users must choice either unwatching some of our highest-traffic, most central categories, or opt out of the Wikidata watchlist feature entirely.
  • T109103: Enhanced recent changes - add a method to Auto-expand all entries, without requiring user.js changes
    • Task
    Enhanced recent changes - I've loved the feature ever since adding this code to my [[Special:MyPage/common.js]] (or global.js) // Auto-Expand all grouped RC/Watchlist entries. $( function () { $('.mw-enhancedchanges-arrow').click(); } ); It auto-expands all the groups (as if auto-clicking all the arrows/triangles), in RC/Watchlist. I consider it integral/necessary. Request: Could (something like) that be added as either: * a new user-preference * a toggle button on the RC/Watchlist pages (so that we only have to click once, instead of once-per-item) * something else?
  • T106739: Misleading email notification on user rights change
    • Task
    I received the following, I think due to the action of James [promoting me to sysop](https://www.mediawiki.org/w/index.php?title=Special%3ALog&type=&user=&page=User%3AMattflaschen-WMF&year=&month=-1&tagfilter=&hide_tag_log=1&hide_thanks_log=1) on MediaWiki: ``` Dear Mattflaschen-WMF, The MediaWiki page User:Mattflaschen-WMF has been changed on July 10, 2015 by Jdforrester, see https://www.mediawiki.org/wiki/User:Mattflaschen-WMF for the current revision. Editor's summary: MW developer who needs to fix pages from time to time. Contact the editor: mail: https://www.mediawiki.org/wiki/Special:EmailUser/Jdforrester wiki: https://www.mediawiki.org/wiki/User:Jdforrester There will be no other notifications in case of further activity unless you visit this page while logged in. You could also reset the notification flags for all your watched pages on your watchlist. Your friendly MediaWiki notification system -- To change your email notification settings, visit https://www.mediawiki.org/wiki/Special:Preferences To change your watchlist settings, visit https://www.mediawiki.org/wiki/Special:EditWatchlist To delete the page from your watchlist, visit https://www.mediawiki.org/w/index.php?title=User:Mattflaschen-WMF&action=unwatch Feedback and further assistance: https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents ``` It's very misleading to receive this as a watchlist notification. Also, there is a separate Echo user rights notification, so maybe this should be blocked by an Echo hook (but it's confusing in its own right for a standalone install).
  • T100905: Watchlist entries from the logs cannot be marked as visited
    • Task
    Block log entries that appear in a watchlist (usually because the user's talk page is being watched) remain marked as unvisited even after visiting the blog log and the user page and talk page of both the blocked editor and the blocking admin. It seems the only way to clear it is the nuclear option of "mark all pages visited". It is not always useful to clear them in this way as other unread items could be lost. I am told the same problem exists for other logs such as the move and deletion logs although I haven't confirmed this myself. Ideally, it should be possible to mark ANY entry as visited without actually visiting the page (it is often possible to tell from the edit summary that a visit is not needed). But if not, there should at least be a method of clearing individual log entries without affecting anything else.
  • T99256: Convert non-JS version of Special:Watchlist to HTMLForm (OOUI or Codex)
    • Task
    Only use case remaining after RCFilters grew out of beta is for non-modern supported browsers/non-JS clients. Checkboxes should be inline. Make sure to have this preference enabled to see the form: {F41649908} Example migration: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/249386/8/includes/specials/SpecialAllPages.php#136
  • T98941: Watchlist "Mark all visited" synchronization
    • Task
    Currently, the Special:Watchlist button on en.wikipedia "Mark all pages visited" does so for all pages at the time of the press, thus marking as visited all pages newer than the currently displayed list, but which the user has not yet seen on the watchlist. This forces the user to manually note whether new pages were added in the process. The obvious solution is to mark as viewed only up to those pages already displayed on the watchlist - i.e. that were last updated before the watchlist was created. It should not be difficult to include a hidden timestamp in the button for transmitting back, to be used in choosing up to when the "marked as visited" should take effect.
  • T98724: Flow topics in mobile watchlist should be human readable
    • Task
    Flow topics in mobile watchlist show a title like > [[ https://ca.m.wikipedia.org/wiki/Topic:Sgscgw8yfyx5axor | Topic:Sgscgw8yfyx5axor ]] {F163438} The same entry in desktop watchlist shows > [[ https://ca.wikipedia.org/w/index.php?title=Topic:Sgscgw8yfyx5axor&fromnotif=1#flow-post-sh3dadmfezfegpog | Gastronomia de l'Empordà ]] a [[ https://ca.wikipedia.org/wiki/Viquip%C3%A8dia:La_taverna/Novetats | Viquipèdia:La taverna/Novetats ]]
  • T98379: Make "Email me when a page or file on my watchlist is changed" findable
    • Task
    The option "Email me when a page or file on my watchlist is changed" is hidden in a location that might have been logical to put it 10 years ago, but now isn't any more. I wanted to enable email notification on some WMF wiki. I don't usually use that so I had to look * I first looked at notifications. Lot's of stuff about notifications, also email options, but no option to enable watchlist notifications * Second I looked under the watchlist tab. Plenty of boxes to tick, but no email box * Third I clicked on the first tab ("user profile") to just go through all the tabs one by one. Luckily I found the option there This isn't a very nice user interface experience. I don't have a ready made solution. I see two directions: * Move the box somewhere else * Duplicate the same option on multiple locations so users can find it in multiple ways Probably best to have the user interface people have a look at this.
  • T97885: Bold the watchlist link in personal tools when there are updates
    • Task
    Similar to LiquidThread's Special:NewMessages link in the personal tools, the link to Special:Watchlist should be bolded when there are updates, as defined by the update markers (i.e. when there are bolded items in Special:Watchlist). Optionally, there could also be a number showing the count of pages with updates, which could be helpful to spot //new// unvisited changes (by noting the increase in number). This was proposed somewhere else already, but I couldn't find a report; I was reminded by [[http://stackoverflow.com/questions/23343979/is-there-a-way-to-notify-me-whenever-someone-edited-a-page-i-made#comment35753068_23343979|mateeyow]]. Note the proposal to do the converse at T92112, for which however I don't remember past demand/discussions. See also {T8510}, {T94350}
  • T95575: Empty parentheses are shown near red "Topic" titles in Special:EditWatchlist. Additionally the link text looks to be incorrect.
    • Task
    {F110627}
  • T94350: Watchlist number count in personal tools
    • Task
    It'd be nice to have a number count next to "Watchlist" in the header, quite similar to the number count next to the username. Since this number could be kinda large, we could do something like display "99+" when the notifications exceed 99. See also {T97885}
  • T92947: Allow marking watchlist entries as unread
    • Task
    It would be great if there was a possibility to mark a certain page version as unread (so that it is displayed bold in the watchlist again after watching).
  • T92117: Guided Tour of the watchlist feature
    • Task
    See proposed feature requirement: http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Watchlist_Guided_Tour This feature would be developed by E3 and spearheaded by Steven Walling, and will work in connection with these other related features: * How to use your watchlist: http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#How_to_use_your_watchlist * Add pages to new user watchlists: http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Add_pages_to_new_user_watchlists -------------------------- **Trello card**: [[ https://trello.com/c/HDADHYoI/336-watchlist-guided-tour | HDADHYoI ]] * column: Bucket o' Mess * labels: UI & UX Design (purple)
  • T91192: Show new versions of files (and possibly separately description changes) made on WikimediaCommons on the Watchlist
    • Task
    Currently, an edit made on [[ https://www.wikidata.org/ | Wikidata ]] is visible to users on other Wikis as well. To understand what this means, visit the [[https://meta.wikimedia.org/w/index.php?title=Special:RecentChanges&hideWikibase=0 | RecentChanges page on meta-wiki]]. Observe the edits shown on this page with the letter "D"; it indicates that these edits were made on Wikidata. Now on every wiki, there is an option for the user to add pages to a watchlist that they can use to see changes made to wiki pages they have chosen to track. If you are on meta-wiki, you can see your watchlist here https://meta.wikimedia.org/wiki/Special:Watchlist. On MediaWiki replace [https://meta.wikimedia.org] in the previous URL with [http://mediawiki.org], on Wikipedia with [http://wikipedia.org], etc. The goal of this project is to show new versions of files (and possibly also file description changes, with a separate rc_source and filtered separately) made on [[https://commons.wikimedia.org | Wikimedia Commons]] on the Watchlist in a similar way it is currently possible for Wikidata as explained above.  New versions of files (e.g. a crop, rotation, other change to the actual image/video) are much more relevant to Wikipedia than description edits (since they affect the content of the article). Thus, either it should only cover new versions, or new versions and file description changes should be separate, so you can opt into neither, one, or both. (However, a file description change could be relevant in allowing a better caption.) See sample image below and try on all other wikis; {F9708570} Steps; 1. To view changes on any wiki, go to the Wiki and navigate to “Recent changes” then uncheck the “Wikidata” box so that changes on Wikidata related to that wiki will not be hidden. A sample link can be found here: https://meta.wikimedia.org/w/index.php?title=Special:RecentChanges&hideWikibase=0 (when `hideWikibase=0`, Wikidata edits will show but then `hideWikibase=1`, Wikidata edits will be hidden. Actually, it's hidden by default). 2. Select any Wikidata entry for the recent change (after step 1) and add the entry to your watchlist. Then edit the item and check your watchlist on that wiki, you should see the change available on your watch list or if someone else edits the Wikidata entry, it will show on your watchlist as well. Above are the two steps to reproduce the task (for Wikidata use case) and understand what is to be done for this project. The project will be to show edits made on Wikimedia Commons on the Watchlist (globally). For example: edits on transcluded files, etc. {T171027} should be resolved before this is enabled in production. * Primary mentor: @Legoktm * Co-mentor: @D3r1ck01 * Other mentors: @Bawolff maybe * Skills: Database (SQL), Knowledge about MediaWiki job queue, Knowledge about how Recentchanges work in MediaWiki, particularly "external" changes. * Estimated project time for a senior contributor: 2-3 weeks (I think this is closer actually to 1-2 weeks. I'm not sure if scope of this is big enough --@Bawolff) * Microtasks: Any subtask of {T90435} * Some useful links; ** https://tools.wmflabs.org/crosswatch/ (tool no longer maintain). ** https://www.wikidata.org/wiki/Wikidata:Watchlist_integration_improvement_input. ** https://meta.wikimedia.org/wiki/Wikidata/Preventing_unwanted_edits#Show_Wikidata_edits_in_the_Wikipedias. ** https://meta.wikimedia.org/wiki/Community_Tech/Cross-wiki_watchlist.
  • T90435: [Epic] Wikidata watchlist improvements (client)
    • Task
    Changes on wikidata that affect a page on the client wiki should be visible on user's watchlist just like local edits. However we should be careful to: * avoid showing changes to connected item(s) that do //not// affect the local page (labels in other languages, etc) * be consistent across different interfaces (API query module, RSS feeds, RC, etc). * provide correct links to diffs and user pages on Wikidata * allow filtering out external changes
  • T86195: A Special page to move users from watching one page to watching another should be created
    • Task
    Use case: Administrators need to merge one page (Acronyms) with another (Abbreviations), but they want watchers on the old page (Acronyms) to end up on the new page. Normally this would happen when the page is moved, but merging it doesn't do that.
  • T86159: Improve visibility of transcluded changes
    • Task
    Changes in templates and other transcluded content often go unnoticed because often, specifically with templates, the transcluding page is added to the watchlist, but the transcluded page is not. This makes changes relevant to a transcluded pages escape the attention of interested parties. I'm not sure what the best technical solution is, hence the untechnical title of this issue, but a reasonable approach to me seems to be that when a user adds a page to their watchlist, all pages transcluded on that page are added to the users watchlist as well. Another solution that seems less technically viable (but what do I know) is to display all changes to watched pages or pages transcluded in watched pages in the watchlist.
  • T78631: Watchlist feed should show diffs between versions
    • Task
    MediaWiki 1.24.0 PHP 5.4.4-14+deb7u14 (apache2handler) MySQL 5.5.38-0+wheezy1-log Why the watchlist feed doesn't show differences between versions? The recent changes feed does it. The watchlist feed show only the username and not the content that has changed. Is it possible to display the changed content in the watchlist feed, like the recent changes feed? Thanks in advance! Best regards, Stefan.
  • T78376: Email me only when some specific pages or files on my watchlist are changed
    • Task
    I have many pages on my watchlist, but only some of them are so important to me that I would like to receive an email whenever they are changed. It would be great to have an option to follow only some pages by email.
  • T78323: Option to hide minor bot edits from watchlist
    • Task
    We can hide bot edits, we can hide minor edits, but we cannot hide edits that are marked as both minor and bot. This would be very useful because : - hiding minor edits is quite dangerous because registered vandals can mark their edits as minor, and rollbacks are minor too, yet they indicate the edit has been dealt with and is no longer a concern - hiding bot edits can be counter-productive since often bots perform edits that we should know about, for example page tagging, removing reported users at vandalism boards (which indicates they have been dealt with), etc (I can give more examples if you want), and sometimes edits we don't need to know about (adding date parameters, archives, etc). Generally, a bot will mark the edit as minor if we don't need to know about it, and not mark it as minor if we should know about it, and also mark it as non-bot if it's an atypical bot task (minor, e.g. vandalism reverts or non-minor, e.g. vandalism reports). So, for a lot of people (admins in particular), the only edits that should be hidden are minor bot edits.
  • T76528: Cannot read watchlist feed if mediawiki is private, even using the watchlist token
    • Task
    I have a wiki (1.24.0) which is only readable to authenticated users: ``` $wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['*']['edit'] = false; $wgGroupPermissions['*']['read'] = false; ``` Unfortunately this also makes it impossible to access the watchlist feed. ``` <?xml version="1.0"?> <api> <error code="readapidenied" info="You need read permission to use this module" xml:space="preserve"> ``` IMO this is wrong. There's watchlist token exactly for that. In the #mediawiki channel on IRC I was told to open a bug report.
  • T76299: Option to group consecutive edits by a single user in expanded watchlist
    • Task
    For increased readability, an option to consolidate together all the consecutive edits by a single user could be added to watchlists. The appearance would remain the same except for a notification of the number of edits, and the edit summary would be the one for the last edit. If an edit has been marked as visited in between, the edits should be split in two groups (one before visit, one after visit).
  • T76067: Display in watchlists only a specified number of already visited edits for each page
    • Task
    There are two extreme options in watchlists : either only the latest edit to pages are shown (default), or all edits are shown (expanded watchlist). It would make sense to have a middle ground, and be able to specify in options the number of already visited edits to each page that should be displayed on one's expanded watchlist. If I choose 0, then only unvisited edits would be displayed, while if I choose 1, the last visited edit for each page would also be shown, and so on. When the option suggested in T76299 is enabled, a group of consecutive edits by a single user should count as one.
Prev
1
2
3
Next
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL