Hi @JBaldwin, I just want to confirm that I understand what type of page you're talking about. Is this the page you mean by "last year"? https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2018-2019/Final --
If yes, I can do that.
If it's something more complicated, then I'd appreciate example-links or clues about what kind of formatting you mean. Thanks!

Thanks! Do you happen to still have the underlying database query and could post it here so we could re-run it?

In T18691#5024680, @alexhollender wrote:

[...] At first this idea was exciting, but as I started to mock it realized that it is perhaps awkward to have some actions ("Edit" and "Edit source") be persistent, and have "Share" be visible only on hover.

@EvanProdromou Hi, Did you have any questions about the research and recommendations that I wrote about above? Thanks.

(minus the root page, and minus /de because I already created those 2 at [[wmania:]])

Is there an example of it live in action? If yes, please add it to the task description (for easy visibility) and maybe also the Tech News items? Thanks!

Hi, If I understand correctly from your IRC comments, you want to take over the tool yourself. (Hence I'm removing "maintainer needed" and moving it to the "Adoption requests" column on the parent tag).
If that is correct, then please: Update the task description by checking the process described at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Abandoned_tool_policy (try clicking the "file a task using this link" to see what it would've provided (but don't make a duplicate task!)). You can also see this similar task for comparison: T196396. I'll mark this task as 'stalled' for now; please change that back after 14 days have elapsed, post-notification. Thanks.

Hi @OriHoch, I've updated the task description with the other required parts of the process. Please do replace those "LINK" items with the links once you've completed each of them. Then after 14 days change the status from 'stalled' back to 'open'. - This is to make completely sure that all methods have been tried for contacting the existing maintainer(s), and there's always a possibility that you can convince them to return to help you with a little bit of advice if you ask nicely! Thanks.

In T18691#4994518, @osorio-juan-microsoft wrote:

I like the idea of the share button, even though it adds an extra click to a relatively simple action. However, what are we doing to address the earlier concern of placing more actions next to the Edit action, when Edit is the most important action on a wiki? Also, do we need to consider the mobile case as well (i.e. creating a solution for mobile browsing parallel to a desktop version)?

In T18691#4994518, @osorio-juan-microsoft wrote:

I like the idea of the share button, even though it adds an extra click to a relatively simple action. However, what are we doing to address the earlier concern of placing more actions next to the Edit action, when Edit is the most important action on a wiki? Also, do we need to consider the mobile case as well (i.e. creating a solution for mobile browsing parallel to a desktop version)?

In T18691#4994195, @dbarratt wrote:

What if, it just updated the address bar in your browser (i.e. it went to anchored link) and you could copy it from there?

I cannot reproduce with a clean redirect link. (in Firefox 65.0.1 (Linux) nor in Chromium 71)
You can Test it at https://en.wikipedia.org/w/index.php?title=User:Quiddity_(WMF)/sandbox&oldid=885582095
My result is a proper HTTP 302, and fully functional PagePreview:

Re: Right / Left

• Right-floating is what I currently use (via a personal Stylus user CSS) because I find it too distracting next to the headers,
• That's what all the Wikimedia sites originally/previously used (from 2004–2013) but it was globally changed (in Vector) to be next to the headings in 2013. (after failed attempts to do so (?) in 2007 and 2009).
  • See the detailed research that led to the 2013 change, linked at T96515#1219109 and T13270 and other links within those.
• Some other people (like me) also disliked the change and they float it back with user CSS. E.g. A search for ".mw-editsection {float: right;}" on Enwiki (but this search only finds people using this exact string/spacing/etc, so there are probably many more)

When this bug occurs it is severely impacting the functionality of this tool and causing a lot of extra work for MassMessage senders. Triaging to 'high'.

Note: This is now possible to do in normal searches via tweaking the search URL, per work on T40403. I've mentioned it in the docs.
It would be great to have (some? all?) of these Help:CirrusSearch#Explicit sort orders features added to the Advanced Search interface for easy access. Cheers!

In T40403#4930284, @EBernhardson wrote:

@Quiddity I already hacked in a query parameter, sort, that is usable in Special:Search. I'm not sure how much work it would be to wire up AdvancedSearch with this, but there is a ticket already: T197525

• https://www.mediawiki.org/wiki/?search=meaning&sort=last_edit_asc

contentadmin can edit normal protected pages, and seems reasonable for anyone with deploy access. The page there even gives a handy form for requesting it ;-)

All seems clear on the lists I subscribe to and admin. Thanks for the work here!

I looked at the existing documentation details, and some in-practice examples. My conclusion is:

• I recommend that you just make this change on the wikis which do not use RCPatrol.

I just encountered this bug whilst editing https://wikimania.wikimedia.org/wiki/Travel_guide#By_plane (in the long list of links to cities)

I've fixed some issues on the current Main Page, and requested Admin and Translation-admin mops on the Volunteer page so that I can help with related and other things.

In the API this is now partially working!

• old https://www.mediawiki.org/w/api.php?action=query&list=search&srsearch=meaning
• new https://www.mediawiki.org/w/api.php?action=query&list=search&srsearch=meaning&srsort=last_edit_asc

In T215251#4928519, @herron wrote:

Thanks for the patch! As mentioned in https://gerrit.wikimedia.org/r/488022 a reject rule is now in place based on this subject.

Me, I offered to help genericize the existing template to make it easier to re-adapt in the future. I asked Sherry to file a task so that I could remember later without having yet another entry in my todo.txt notes... :)

In T213771#4879327, @Catrope wrote:

What's especially strange about this is that [...] persistently returns a 429. [...]

I just noticed this in action. Great tweak! Thanks :)

In T202929#4658008, @Qgil wrote:

About scope, one task to challenge our assumptions:

Find, gather and centralize documentation about best practices concerning replying to newcomers on Help Desks.

Would this piece of documentation be within scope or not, and why?

See the tag. (Mostly it's morale-building whimsy) (It's also getting more confusing, because "dragons" were declared to be the 'new' animal at the 2018 hackathon... But I'm staying out of it!)

Interesting external example of a "Help and feedback" footer section: 4 tabs, each with 2-3 entries - https://docs.gitlab.com/ee/development/i18n/translation.html#help-and-feedback

Thank you! (yeah, I saw the empty sections, but didn't know how to clearly describe it, and I figured you'd see it :)

@Nuria thanks for the reminder of that! I've added it to the page. (Docs or it didn't happen! ;-)
That helps us see some of the information, but it leaves out, e.g. users with no-JS extensions enabled, or users behind a corporate intranet that blocks JS, or users who had their page-load interrupted midway. I don't know how those wider circumstances are best technically captured, or if this is the right task to ask for it, or how much info we could get with minimal/feasible efforts? I'll leave it up to you though. :-) Also I've filed the related T213215: Improve Dashiki defaults for Browser selection.

Moving to backlog workboard, until work resumes.

I believe it would be very useful to get more accurate statistics on our non-JavaScript users (both readers and editors if separable), for the purposes of product planning and task prioritization and generally for understanding our users.
The notes we've compiled at https://www.mediawiki.org/wiki/No-JavaScript_notes have very unclear/inconclusive #Metrics and nothing new for the last few years.
I don't know whether this task is the best place to request that, or if somewhere else should be used.

Some related links (maybe put some of these in the task description?).

• https://meta.wikimedia.org/wiki/Glossary

In T13271#158724, @Aklapper wrote:

Is there a specific example for a template inclusion on some Wikimedia site that this request could be (re)tested with?

I just found this lovely related notes page https://wikitech.wikimedia.org/wiki/Action_paths and hence I came looking for why this task idea, or the alternative T14619: Use article path URLs for editing, previewing skins, etc., hadn't been made default since I last looked at them (idk!?).

Thanks for the merge, @JAllemandou ! What are the next steps to complete this task?
IIUC the 2 steps that Milimetric described above have now been completed, but pageviews are not yet visible for wikitech (example1, example2). Perhaps it just needs to wait for the deployment train to do a circuit? (There's no rush, I just want to make sure it's moving forward :)

I believe (and personally hope) the plan is to keep the RGB version for community logos. Per https://meta.wikimedia.org/wiki/Brand#Using_the_Wikimedia_mark and https://meta.wikimedia.org/wiki/Logo#Current_logos it's the main logo for the movement.

In T190560#4846240, @Qgil wrote:

[...] I don't know what is the state of the art of displaying related search results, but as a user I think I remember seeing results from other projects in a separate column. The equivalent here would be to see Discourse results in a separate column when showing the results of a query in MediaWiki.org.

I have the same frustration but with the opposite (default) preferences. I love the feature, but usually disable it because this issue is too annoying.

If you do merge it, I suggest changing the title of that task to: Differentiate between internal, sister-wiki, interwiki, and external links visually

In T211827#4824638, @MusikAnimal wrote:

@Quiddity Do you plan on [...]

@Nuria Yes, sorry that my description was ambiguous! We want separate lists for each Wikipedia. I.e. various Chapters want language-specific lists, to share/answer with their own press contacts.

@TBolliger Please could you (or someone who knows the latest details) update the task description above, to contain an uptodate description of the change(s) that will be implemented? (The Tech/News item points here for more info, but this thread is long). Thanks!