Today

• No visible events.

Tomorrow

• No visible events.

Saturday

• No visible events.

User Since

Nov 8 2014, 4:24 PM (626 w, 4 d)

Availability

Available

IRC Nick

Base, Base-w, Cladis, Esuba, Voiced

LDAP User

Base

MediaWiki User

Base [ Global Accounts ]

Well, perhaps it makes sense to have such behaviour when there are several edit boxes, although it is counter-intuitive to have one tool panel for several fields to begin with, tbh I didn't even realise it could be so not being a particularly active Wikisource contributor, but when there is one text field having to explicitly choose 1 out of 1 elements is annoying. Especially for new pages where it is also clear where the cursor would go whatever the usecase.

Was there a community consultation about removing it? Fwiw there are tonnes of unmaintained extensions deployed that do have a lot of bugs and feature requests open, what is a reason to touch one that does not really require any maintenance at all?

Doesn't outreachwiki already cover this scope?

This one feels like some API design flaw to me. It should not matter whether you are using action API or REST API to access info about the very wiki you are linking from.

Asking to see if these pages are actually needed

Ah, I guess https://phabricator.wikimedia.org/T234155 is already it, me being slow.

So basically we kinda need a new level of "view protection" for the abuse filters? I guess it is worth filing it as a separate task and making it a blocker?

In T385346#10881544, @Jdlrobson-WMF wrote:

https://www.mediawiki.org/wiki/Manual:Interface/Sidebar#Extending_the_TOOLBOX

If it is client side then why is it a 5xx error and not a 4xx error such as HTTP 408?

Were we to do this, we would prioritise the visual editor, which is fully supported for new features, and not the 2010 wikitext editor, which is not.

This is because the toolbox is intended for tools relating to the current page, not tools relating to the site.

I am not sure filtering out plain blocked users is a good idea. Someone might have a 1 day block for getting a bit too worked up in a discussion, but it would be a valid use case to ping them in a bunch of places.

I am not sure if I caught everything, probably need to reread the description a couple more times again, but it feels like you are basically proposing to improve security for the case when the password gets changed by the attacker … but drastically worsen security for the case where the attacker gets access to the email account, as even if you do catch that and manage to change the email the attacker would have token that lets them now lock you out of your account completely?

@Aklapper , added the new project to the task.

If you do do this, it would be good to only remove the older runs results, but leave the most recent run result for each query, or as a less desirable alternative to keep those for only published queries (but I am one of the people who rarely publishes queries even when they are finished). My queries often refer to some article contest, or some on wiki investigation, or just a bit of curiosity that does make sense to be kept for many years and is sometimes linked with the assumption of some stability from on-wiki. Re-running queries every 90 days would be an unnecessary burden, might lead to corrupted results, such as a query that was used to determine a contest winner will no longer should that person as winner because of some things happening in between, and because of schema changes it might also be a maintenance burden (I still have a lot of query results active from the pre-multi-DB select cancellation times, or from the pre actor migration times) that either require a tweak or are even impossible to rewrite, but the results of their older runs are somewhat useful to this day.

It's not much more complex than commenting on a task. There are reasons why there is often more than one single catch-all task for each software project. :P

In T191156#10019825, @Ladsgroup wrote:

.mw-content-subtitle > .cdx-message :not(.mw-revision) {
  whatever you like;
}

I'm sorry but a wiki can't have consensus to revert a software patch as it impacts all wikis not just yours.

I'm sorry but a wiki can't have consensus to revert a software patch as it impacts all wikis not just yours.

Reopening, the details on this are sent in the "Votewiki setup for Wikimedia Ukraine AGM votes 2024 summer" thread.

As a reader, I want to use the same skin across all wikis so that my experience is cohesive

How many freeform javascripts do you get to install in your Facebook or Instagram page again?

Another additional work paid "improved" vector WMF staff is putting on unpaid projects' volunteers.

Allow the same list be included in different pages

As a random rant, perhaps it is my myopia speaking, but I would really love to have bigger default sizes across Wikipedias for the images. In fact it is in my todo list to propose increase for default Infobox sizes on Ukrainian Wikipedia, and come to think of it making default thumbnail sizes bigger would be a boon too. That said I feel like desktop "improvements" are a thing that is making this a thing that would likely want people to stick with those inadequately smaller images as now you have to work with so much less width available.

Now there is the only fast way to receive translated messages - through gerrit.

I see that there are also

{
    "propname": "translate-has-languages-tag"
},
{
    "propname": "translate-is-translation"
},

page props.

whether or not it makes sense to add Special:MyLanguage/ in front of it) via the API

I am confused what this task is about. Gadgets do support messages. It is possible to commit messages to Wikimedia-messages and use them from gadgets at any wiki.

But also more prone to vandalism than I18n in translatewiki

In a way this is a variation on security through obscurity. As in more people know how to edit Wikidata than how to edit TWN (or rather that TWN exists). Yes, TWN requires editors to be pre-approved, but this has never stopped low quality translations and vandalism (I mean it has surely stopped some, but it has also not stopped a lot other)

299 active users, 10 admins (including abuse filter). If not for an explicit decision to opt out it would still be a GS wiki. No need was demonstrated in the discussion. Definitely a no.