On second thought, this may not have to do with namespace. I'm not very familiar with what does or doesn't cause notifications to fire (which can make communication a little difficult). The example I cited above seems to have to do with requirements of using proper signature code...and using an updated signature. See task T66778.

Just a brief note, this issue is a problem for seasoned Wikimedia project editors as well as non-Wikimedia users of MediaWiki software. For instance, several experienced Wikimedians designed the Wiki Global Check-In, an event organized for community members during the COVID-19 pandemic. The original instructions had users "pinging" one another on a page in the main namespace on Meta Wiki; but even these seasoned wiki editors did not notice until far into the planning that the "pings" were not resulting in notifications. (See the talk page as well.) https://meta.wikimedia.org/wiki/CheckIn

@Xover That's a plausible theory, though I was interpreting "abuse" in plain English, not in any jargony way; if you're right about the intent, I'd have expected a more straightforward construction like "misuse" or simply "the priority system is not the appropriate tool for expressing a preference." At any rate, not much use our speculating about James' intent...if he wishes to comment that will surely settle the matter.

I'd also point out, @Aklapper, this is not merely "some issue in one of the literally thousands of projects." As @Koavf noted above, OCR is fundamental to how Wikisource operates. Something coded by a volunteer who has since become less available has become quite important to a very important Wikimedia project's success. This would not be the first time; volunteer innovation has always been an important, and complicating, factor in how Wikimedia has grown. While I do not pretend to know how WMF staff like the "importance" feature to be used, and I have no opinion on whether or not "unbreak now" is an appropriate or useful status, I would strongly urge WMF staff to avoid minimizing the significance of the problem, or scolding users who are trying to help get something important fixed.

Agreed, @Koavf - when WMF staff have used terms like "abuse" in the past, it has sometimes been accompanied by punitive action. It's worthwhile to point out when WMF staff use sensational language like this directed toward users. @Jdforrester-WMF, any chance you could comment or retract the use of that loaded word? In addition, it would be helpful if you could provide some guidance about how you would like users to indicate preferences around task priority.

OK, I (sort of) understand. I also don't see how something described as an "evolution" constitutes a "reply..." but I suppose if there were a clearer answer available, it would have been mentioned by now.

@Aklapper, after I posted the comment above, I see you have marked the page @Qgil had identified as constituting a "reply" as "historical/obsolete". https://www.mediawiki.org/w/index.php?title=Technical_Collaboration_Guidance/Community_decisions&diff=3555787&oldid=2534515 Could you explain?

For posterity, three points seem worth noting:

• In this 2015 essay, I considered what the results of the letter were: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-11-11/Op-ed#Was_the_letter_finally_successful? In particular, I cited five reasons (as expressed by those signing the letter) why the Wikimedia Foundation's response was considered inadequate. It seems strange to me that these five reasons were never discussed here, when WMF staff determined that this task had been "resolved"...I'm including the link so that others may draw their own conclusions from the original text.
• This item is titled "Provide a reply to Letter to Wikimedia Foundation: Superprotect and Media Viewer." However, on the page linked, there is no mention of any letter. Quite odd, for something to be characterized as a "reply" to something whose existence it doesn't mention.
• As of December 2019, the page linked is still marked as a "draft." Also odd for a draft document to be considered a "reply."

Thank you @Aklapper ! I did not realize it was possible to create private image files here. I believe I have now updated the image to allow all to view. Please let me know if you still have problems (and I will watch out for this in the future).

What @Xover said makes sense -- it's not a problem with ProofreadPage, but a problem made *visible* by ProofreadPage. In that case, my initial title is incorrect, and may be preventing the right people from seeing this. Does anybody know what part of the software is supposed to generate thumbnails? Can somebody retitle this or recategorize it in a way that makes more sense? @Aklapper ?

Note, I don't think Phe is tracking this here. He responded only after I left a note on his github page, which Aklapper linked above.

Replying to this from the original report: "Bonus points if the code is smart enough to only do it to redlinks."

@Samwilson : I'm still getting inconsistent results -- sometimes the Google OCR button shows up, other times it doesn't. Here's the console output from the last time it *did* show up (after turning off the regular OCR button, and using the enhanced toolbar).

@Samwilson : When I turn on the "enhanced toolbar" I don't know where to look to find the Google OCR button. I see the regular OCR button, but not Google OCR.

I doubt it matters, but just in case, it's on this page:

When I click the (small/compressed) button, I get this:

OK, here we go -- it failed again. (yay!) (And FWI, I've never turned on the new gadget, so that has not been interfering.)

Hmm, I don't see a Javascript console, but I see a Browser Console -- is that what you mean? There's all kinds of stuff in there, but now the OCR button has decided to work for the last few pages. I'll let you know what it says when I get another problem. (But, I'm not sure how far back to go, it doesn't appear to indicate in any obvious way when it's talking about a new page...?)

@Samwilson Thanks -- results are mixed. In Firefox on Ubuntu Mate (on a new but bargain-basement, slow laptop), it worked on the first page I tried it on, but failed on the second one. The button size is still correlating with success/failure.

It may be that it works in Chrome, and does not work in Firefox. I *think* it has worked for me in Firefox in the past, but I can't be sure -- I use a variety of browsers. But I've tried it on Firefox under Windows 10 and Ubuntu Mate 18.04 today, and it's not currently working in either. However, I am not currently having trouble under Chrome on Windows 10.

Hi @Mpaa , just noticed your reply. Yes, if you're able to fix the file, I'd appreciate it! I'm also curious what the process looks like, if you're able to describe.

@Tpt I just cleared my cache and tested a few pages, and so far, it seems to be working! I hesitate to give a definitive answer just now, as the problem has been somewhat sporadic...but I just checked three pages in a row, and previously, it's almost certain at least one out of three would have failed. Thank you for your efforts!

I've been contending with this for some time, but thought it was specific to my computer. As Slowking4 said, this is an issue that "strike[s] at the purpose of this site." It's difficult to do the *single most important* thing on Wikisource. The longer it's a problem, the bigger the negative impact on recruitment and retention of Wikisource editors. If there's a way I can help identify a solution -- more specific info about what causes the problem, or something else -- please let me know.

Perhaps helpful in troubleshooting: IAupload offers the opportunity to remove the first page of a book (intended, I believe, for the kind of misleading rights claims typically introduced on a leading page by Google and others). On this one, it offered that option, but I declined. However, the interesting part: the image it showed me was of PAGE 2, not of the one that actually came through as PAGE 1. In other words, the actual cover [https://en.wikisource.org/w/index.php?title=Page:Atlantis_Arisen.djvu/2] rather than the registration page, or whatever it is, used by the Internet Archive [https://en.wikisource.org/w/index.php?title=Page:Atlantis_Arisen.djvu/1]. Since the offset of this unexpected behavior was also one page, it seems possible it might be connected...

Thanks Mpaa, I'll keep track of the ticket. Like I said on Wikisource, no urgency on my end with regard to this particular file (Atlantis Arisen).

That's: https://commons.wikimedia.org/wiki/File:Luella_Clay_Carson.png

Seems to work fine. I'm not marking this "resolved," in case there is still hope of solving the underlying problem...but this file is now good to go! Thanks again @brion.
-Pete

Thank you Tgr, I'm sure that is the issue. Appreciate the response.
It's especially helpful to know that the Outreach Wiki is handled somewhat differently, as I have noticed that one gives me slightly different behaviors -- I had neglected to mention that in my initial report, as I have not been active there recently.
-Pete

Thanks @brion -- I'll try it, I suppose by just uploading it at Commons. I take it what you used was a webapp? I should have thought of that. I believe Wikisource prefers DJVU anyway, so it's a helpful workaround in this instance.

Thanks for all the efforts. Until a full general fix is worked out, is there a way to get this file working? If the JPEG 2000 source is the issue, is there perhaps a way to convert the pages one-by-one, and then rebuild a PDF or DJVU? I'd be happy to try doing that, but if there's an imminent (possible) general solution, let me know and I'll hold off.

+1, would be tremendously useful to be able to specify namespace. Here is a news article that could have been much more informative if there were an easy/obvious way to narrow down the links to whitehouse.gov domain from *Main* namespace: https://theoutline.com/post/959/whitehouse-gov-switch-broke-wikipedia

A point I left out:

In T155273#2946129, @FilipGCI wrote:

@Qgil @01tonythomas Maybe just add user option to choose he/she want to be logged?

I also have a personal view on this, but I will not bring it into the discussion, as I do not believe the personal views of a few individuals should impact the decision. Making subscriber lists private represents a change from the status quo. Evidence that should be considered would include:

• Requests from users, accompanied by discussion leading to a clear consensus for change
• Academic research about expectation of privacy around subscriptions
• Polling of a representative sample of users

In T155266#2938862, @matmarex wrote:

... but that page is not equivalent ...

In T155266#2938803, @matmarex wrote:

This already works the way you're describing for me. When I visit https://meta.wikimedia.org/wiki/Help:Redirection, I see <link rel="canonical" href="https://meta.wikimedia.org/wiki/Help:Redirect"/>.

If this is valid and leads to a change, we should also consider cases where a redirect page carries additional information. I would imagine we'd want to treat these like any other redirect page, but more expert folks than myself should probably think it over. Example:

Elegant solution, @QuimGil. One tiny adjustment, I'd remove the word "been," so it reads simply:

@Dereckson, soon would be nice, but if another couple days without objection will more clearly establish consensus, I don't mind waiting. Thank you.

If this ticket has gone too far in the direction of discussion (rather than mere task-tracking), then I am to blame for that. I agree with @Nemo_bis that Meta Wiki is the best place for public discussion. For anyone who believes this can be handled at the executive level rather than the board level, the page you linked does not make sense; this is one of the reasons I have suggested the Superprotect Letter's talk page. https://meta.wikimedia.org/wiki/Talk:Letter_to_Wikimedia_Foundation:_Superprotect_and_Media_Viewer#November_2015_poll:_Has_the_letter_achieved_its_goal.3F Speaking for myself, I am watching both pages.

Apparently a 2012 Meta vote rejected enabling WikiLove: https://meta.wikimedia.org/wiki/Meta:Babel/Archives/2012-05#Proposal:_Enable_WikiLove_on_Meta

For what it's worth, I looked on Meta Wiki, and asked about enabling WikiLove, here: https://meta.wikimedia.org/wiki/Meta:Babel#Enable_WikiLove_here.3F

I see three possible outcomes, any of which would be good. The first, I think, is ideal:

(Note -- my earlier closure of this ticket was a mistake, and I didn't realize I had done it until Quim pointed it out to me today. Apologies for any confusion this caused.)

In T128976#2098849, @MZMcBride wrote:

Awesome! Is this task now resolved, then? If so, could you please mark it as such?

Now done. I had been planning to bake a cake and find a party hat first ;)

It works -- thank you all for your efforts! It's tremendously useful for wiki-gnoming, and will permit me to do a bunch of long-deferred organizing on wmf wiki. If what you just did is easily transferrable to Meta Wiki, I could use it there for some projects too...but I don't want to wear out my welcome on requests :)

@MZMcBride , first -- I think my own issue is now resolved (I copied text from my common.js file on Commons to WMF Wiki) -- but this is probably worth tracking down in case somebody else wants to use the gadget. In other words, I think I was able to manually change my preferences by putting the file there myself -- but the interface to the Preferences screen still doesn't work on WMF Wiki.

Thanks for taking a shot at that, @MZMcBride . Unfortunately I'm still not able to see the preferences screen. @Rillke , do you know anything about how Cat-a-lot uses Javascript, and how we could get it working on another wiki?

@MZMcBride, sorry if this is more complicated than it first seemed. In order to be useful on WMF Wiki, this will need to permit categorization of pages. That's an option in the Cat-A-Lot preferences, which is not checked by default:

Many thanks, MZMcBride!

@Qgil Thank you for the update. I appreciate your efforts, and I agree that trying to push this through in this particular month might not have been the best idea.

This task was not completed; the wiki was closed, and (as Angela stated) pages were exported to Meta (and perhaps other wikis), but (at least some?) source pages were not deleted, no note was made about the new address, etc. What is the best way to handle this? It seems to me the best approach would be to reopen the wiki, create soft redirects for every page, and re-close it. See, for instance: https://advisory.wikimedia.org/wiki/Meeting_August_2007/Notes and https://wikimediafoundation.org/w/index.php?diff=104869

Absolutely helps, Quiddity -- thanks. And I'm glad to hear that WMF product dev process aims to document all this stuff better. Every time I ask about something like this, I seem to get a nugget of useful information...but nobody's ever pointed me to a document that (e.g.) describes the proper/intended use of sites like phabricator, bugzilla (which I do understand is now history), trello, gerrit, github, or even mediawiki.org or the tech email lists or IRC channels, and perhaps other sites/lists I'm not aware of. Any effort to create high-level documentation of that stuff would be tremendously useful to the movement. (Detailed documentation is good too, but IMO some kind of overview is more pressing.) Anyway, I appreciate this good explanation -- it makes sense.

It's my understanding that bugs entered here are supposed to have consensus first -- rather than generating consensus here on phabricator. Is that accurate? If so, where is the consensus for this substantial change on the various projects it will affect?

Another example: http://www.oregonlive.com/portland/index.ssf/2015/08/portland_police_investigating_80.html (photo is public domain, by USGS -- all I did was crop it.) I noted it in the comment thread, so perhaps the Oregonian will correct the problem.

Unsubscribing -- if you find you need me for something, please reach out directly.

Funny thing -- the exact same thing happened to me last night. I was even fooled about the photo -- my memory played a trick on me, and I initially believed that the publication that (falsely) attributed a photo to me (since I had taken some similar, but vastly inferior, photos). See here: https://www.facebook.com/phorzaith/posts/702609043778

Why is the uploader's name shown at all, in cases where the "Author" field is filled in, or when the image is in the public domain? I thought the purpose of Media Viewer was to remove less relevant clutter for the reader. How is the uploader's username interesting at all, if it's not necessary for attribution?

Thank you for creating this item, Quim. If and when it's established that senior leadership at WMF wishes to put this issue behind them, I am willing to have some focused discussion on what a realistic answer to this provision might look like, over a year after the letter was written. I think any reasonable person would agree that no consensus established in 2014 should be regarded as unequivocally binding a year later, so this is an open question. I am happy to share my thoughts on this, and my speculations about what would be acceptable to those who signed the letter. I'd rather not get into that discussion in the absence of a clear expression of intent from senior leadership, however.

In T69082#1168572, @Anomie wrote:

<snip>

Unless I've forgotten, it's not easily possible to implement such buttons as the "request authorization" flow doesn't allow the app to request only a subset of the grants that it is registered to be able to ask for. If someone actually wanted to do that instead of requesting permission for all the app's registered grants up front, it could probably be done easily enough.

In T69082#1164512, @MarkTraceur wrote:

<snip>

Patch incoming, thanks!

In T69082#1167473, @Ricordisamoa wrote:

In T69082#738278, @Peteforsyth wrote:

• Perform administrative actions Rollback changes to pages; Delete pages, revisions, and log entries

I think Bartosz has a good suggestion here: if possible, it would be nice if this item could simply be removed for non-administrators. "Rollback" might be a right that a non-admin has, but in many cases she will not even know what "rollback" means. As an admin, I've granted this right to people without discussing it much, and I've seen other admins do this as well. So if there's a way to avoid the jargon "rollback" and instead describe what will actually be done, that would be ideal.

If a user has rollback rights without knowing what that means, they probably shouldn't have them.

@Maryana, your description above includes this suggestion: "A longer-term fix might be to create a way to flag/blacklist pageimages on certain pages somehow, since they'll also be the problematic ones in the app, in search, etc."

In T90801#1069935, @MZMcBride wrote:

I don't think we want to break existing links to Special:UserProfile/<user>. One option might be to make Special:UserProfile an alias of Special:Contributions, at least temporarily. This is a constructive and actionable idea. What are your thoughts?

In T90510#1061691, @Aklapper wrote:

Is this about http://tools.wmflabs.org/commonshelper/ ? Exact links are always welcome.