While deleting one of the the Topic pages on Commons, I came across this error:
[b81ebde5-b932-404b-8f19-0dd5929528a0] 2024-12-24 11:03:36: Fatal exception of type "MediaWiki\Page\PageAssertionException"

We have had some good improvements today, during the first day of Indic MediaWiki Hackathon in Bhubhaneswar. For the sake of transparency, I have asked for ideas/suggestions on TA noticeboard's on Wikimedia Commons, Meta-Wiki and Wikidata.

A test-page to help improve created at:
https://meta.wikimedia.org/wiki/User:Aafi/Test_for_Bhubaneswar_Hackathon

I have been looking around this since my conversation with Gopavasanth at Wikimedia Technology Summit in Hyderabad. It is a good start. Has there been any improvement since then?

@Hamishcn, a resized version of the logo has been uploaded. Could you please take a look if it works?

Closing as resolved per the latest usage updates by Usage Bot.

In T378262#10264757, @Aklapper wrote:

Hi, this does not sound like a bug in the MediaWiki code for Categories, thus removing that project tag. This sounds like a support request (how to change settings, questions how to do something, etc.). As Wikimedia Phabricator is for bug reports, enhancement requests, and planning work, please check https://www.mediawiki.org/wiki/Communication. Probably https://meta.wikimedia.org/wiki/Tech is the best place where to bring this up. Thanks for your understanding!

I am re-opening this task given that it doesn't appear to work. Having updated to the latest master branch from Git/ran update.php commands as well - it doesn't seem that the files are being marked as used. For example: this and this. I have also tried removing the residuals of the previously installed extension and then purging - it doesn't seem working. Could you please take a look and see what is missing? Both of the files are used here.

@Samwilson , do we have anything new in this?

@Samwilson , I don't think a two-column display would do any good (3 might be an idea to try). I feel we should try with the same format as it comes on the desktop view.

In T359764#9618373, @Koavf wrote:

If you use your Wikimedia credentials via OAuth, just see here: https://meta.wikimedia.org/wiki/Global_rename_policy

Possibly related: https://phabricator.wikimedia.org/T49918

Since WMAU skin does not look like regular Wikimedia skins, we can use any extension that allows enabling comments at the bottom of any given article. However, by default, I am not sure if pages such as About, and others, require any kind of public comments through a talk page, or even generic comments at the bottom.

Please find the community consensus here.

I have initiated a local Village pump discussion and will get back here once there appears to be a community consensus.

The note by Base makes sense. The number of active admins on ur-wiki has fallen below 7 (afaics). Please consider this request withdrawn. We might revisit this at a later time.

The removal of administrator flag would remain subject to community discussions, and a crat' should be able to do that. ur-wiki is not that much small wiki. I could see successful local discussions for CU's such as this, but I'm not sure why Urdu Wikipedia doesn't have any CU yet.

This appears to be fixed for me. See this and this for reference. The "Marked.... for translation" does not remain unpatrolled anymore.

Although I agree with @Pols12 that translation admins are not supposed to be translation reviewers but I feel it to be alright if they have ability to mark translations as "published", for example, in the languages that they know. I know Urdu and if I believe a translation is perfect and should me marked as published, I should be allowed to do it, instead of me waiting for someone else to do it, stewards? I am not sure if we have one knowing Urdu language.

In T345890#9152022, @Soda wrote:

@TheAafi Also reported this error previously

@Ladsgroup, could you please make this mailing list as a private one? Over the last few months, we have had some discussions internally and we felt that keeping the list private would serve us in a better way.

@matmarex, I checked out with what you said in b and I see that I've similar options opted in both 1 and 2. When I checked the same with clicking the "keyboard like button" in scenario 1, it displayed "Use personal keyboard is active". The same is with discussion tools. I am sorry for not understanding Does the "ENG / IN" layout indicator change to reflect the Urdu input when that happens? In scenario one. I am able to write in Urdu without having to change from ENG/IN to Urdu but this doesn't work on the other areas that I have indicated. I'd definitely ask some other friends to check with this and see if the face this problem as well or is it just me.

If you can take a look at these images, you might be able to notice what I am asking for. We do not face such issues while writing articles or posting on talk pages by going through the "edit" option. Without having to change the keyboard layout from English to Urdu, we by default are able to write as such with a phonetic keyboard as I indicated in scenario 1 above, and also shared an image. I don't feel this is an issue with translations.

@matmarex, what I mean is that if I directly post a message using "edit" button at the top of any page, I am able to write in Urdu without having to changing my system's keyboard layout etc. from English to Urdu. However, this doesn't happen with posting a message by option "New section" button. In that if I want to write in Urdu language, I have to change my system's keyboard layout to Urdu unlike the first scenario. That's to say, if Urdu language can be typed without having to change the keyboard stuff (scenario 1) why is there a problem in the scenario two?

In T330594#8646873, @Esanders wrote:

You can provide translations here:

https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-discussiontools&language=ur&filter=%21translated&action=translate

In T322996#8391475, @Ladsgroup wrote:

do you want it public or private?

I just faced this again on Wikidata. This shows Invalid value for parameter mcgroup.

Hmm, I did encounter this bug much earlier than you but I wasn't in hurry to bring this to Phab and instead asked @Pols12 that what went wrong. Waiting for a while sorted out all the problems even without purging the cache. That's to say, this was perhaps a temporary bug.

Given the criteria set forth by AffCom, I'm currently taking this request down and will come back on this once we feel we are ready for this. Thanks!

I got a follow up from MKaur and she said that, AffCom is actively passing an internal resolution on process related to such requests. You will hear from them soon.

@Ladsgroup You're right but I'm not able to understand why AffCom is moving away from the discussion. The email I had sent them received a weird response in a language that I don't know. Let me reproduce it here for you:
Affiliations Committee Google Группы Логотип Google Групп
Запись, которую вы недавно отправили в группу Affiliations Committee, отклонена ее владельцем или менеджером.
Возможные причины отклонения:
Ваша запись лучше подходит для другой группы или обсуждения.
Ваша запись нарушает правила группы.
Запись недостаточно информативна.
Дополнительную информацию об инструментах модерации можно найти в Справочном центре Google Групп.
В Google Группах можно создавать и посещать онлайн-форумы, а также группы, общение в которых происходит по электронной почте. Делитесь с другими участниками документами, изображениями, календарями, приглашениями и прочими материалами. Подробнее…/

I received a follow up from AffCom's Twitter handle. The response is from Camelia who says, "Hello, AffCom never managed the sites or had any decision making on this. And as the discussion went on that thread, only in the past chapters had this." But, I'm still waiting for MKaur's response because she just said two days back that she commits to sharing the update in the coming week. Lets see what happens. My question on this much is that, when AffCom had no decision making in this, why are we forcing them to have any?

MKaur has said that she will follow up with AffCom on Monday and commits to sharing the update in the coming week.

In T313151#8082200, @Ameisenigel wrote:

Stalled per T271539#6733959

In T271539#7171803, @Aklapper wrote:

Hmm, any news from AffCom here?

@Dereckson, following our conversation on Meta-Wiki, here is the request. Please let me know if you need any further information. Once the wiki is created, please make me the initial bureaucrat. Thanks!

@Aklapper Please see the community consensus.

In T307029#7885859, @Aklapper wrote:

@TheAafi: Please see https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes and provide a link to community consensus. Thanks!

In T301491#7701810, @4nn1l2 wrote:

@TheAafi, please confirm that admins should be able to add and remove users to and from patroller usergroup. Otherwise, only 'crats will be able to do that.

In T281274#7092402, @Urbanecm wrote:

Should work now.

Pinging @Urbanecm after having received no response from 9 May 2021.

It has been around a week since this proposal was posted on the village pump of Urdu Wikipedia, at https://ur.wikipedia.org/wiki/ویکیپیڈیا:دیوان_عام/تجاویز#ویکی_بان_اور_آبشاری_حفاظت_کے_حامل_صفحات

In T281274#7050794, @Urbanecm wrote:

In T281274#7050793, @AaqibAnjum wrote:

In T281274#7050792, @Urbanecm wrote:

Could you announce this on the project's village pump? Then, if there are no objections within some time, I think we can go ahead.

Done. I've posted a message and I'll revert here after a week perhaps? Thanks.

I guess you meant "report" rather than "revert"?

Would you mind posting the link here, so I can monitor the discussion? Thanks.

In T281274#7050792, @Urbanecm wrote:

Could you announce this on the project's village pump? Then, if there are no objections within some time, I think we can go ahead.

Do we have any update on the request?

In T281274#7039311, @Umherirrender wrote:

In task description:

the "protect" right i.e. "Change protection levels, edit and move protected pages, and edit cascade-protected pages"

That is no longer true, it is now: "Change protection levels and edit cascade-protected pages"

In T281274#7038928, @AaqibAnjum wrote:

https://ur.wikipedia.org/wiki/ویکیپیڈیا:ویکی_بان rightly says (1), be able to edit pages that are subject to cascade protection.

Maybe there is a understanding problem. Cascade protection always is on the top of a protection, not a protection by its own.
Saying that someone should be able to edit cascade protection pages needs to specify which level of protection. Adding editprotected to the group allows to edit all protected pages (expect interface and user js) including the casade protected pages. The protect right is additional needed for cascade protected pages to avoid that everyone can protect pages by transclude them from the cascade protected page. It is not the only right needed for them.

Looking at all existing cascade protection - https://ur.wikipedia.org/wiki/%D8%AE%D8%A7%D8%B5:%D9%85%D8%AD%D9%81%D9%88%D8%B8_%D8%B5%D9%81%D8%AD%D8%A7%D8%AA?namespace=&type=edit&level=0&wpfilters%5B%5D=cascadeonly&size-mode=min&size=&uselang=en
It says fully protected, cascading or semi protected, cascading

In T281274#7039192, @Urbanecm wrote:

In T281274#7038928, @AaqibAnjum wrote:

[...]
Thanks for this much. Yes, fine in "semi-protecting" pages (I didn't see any other option while protecting any page i.e. eliminators aren't able to fully protect any page and this seems legit). https://ur.wikipedia.org/wiki/ویکیپیڈیا:ویکی_بان rightly says (1), be able to edit pages that are subject to cascade protection.

If we grant eliminators the ability to edit fully protected page, they will be able to also fully protect pages (unless we revoke protect from them, but that will also mean they will not be able to semiprotect pages).

In T281274#7038892, @Urbanecm wrote:

In T281274#7038726, @AaqibAnjum wrote:

Nonetheless, I'm also unable to change protection of that page that I've linked above

protect only allows you to (un)protect pages you are able to edit. That is for security purposes: for instance, meta.wikimedia.org has pages that can be edited only by central notice admins (CNAs). Most admins aren't a CNA, but if they were able to unprotect that page, the CNA-only protection level would be useful – it would let admins in anyway :-).

and that's just cascade-protected but semi-protected on its own?

Cascade protection takes precedence. Right now, https://ur.wikipedia.org/wiki/%D8%B3%D8%A7%D9%86%DA%86%DB%81:%D8%AE%D8%A8%D8%B1%D9%88%DA%BA_%D9%85%DB%8C%DA%BA is effectively fully protected. You can see it by trying to edit the page in an anonymous window. https://ur.wikipedia.org/w/index.php?title=%D8%B3%D8%A7%D9%86%DA%86%DB%81:%D8%AE%D8%A8%D8%B1%D9%88%DA%BA_%D9%85%DB%8C%DA%BA&action=edit&uselang=en shows this to me:

Alternatively, you can see it via the API: https://ur.wikipedia.org/w/api.php?action=query&format=json&prop=info&titles=%D8%B3%D8%A7%D9%86%DA%86%DB%81%3A%D8%AE%D8%A8%D8%B1%D9%88%DA%BA_%D9%85%DB%8C%DA%BA&inprop=protection. This API call shows:

"protection": [
{
"type": "edit",
"level": "autoconfirmed",
"expiry": "infinity"
},
{
"type": "move",
"level": "autoconfirmed",
"expiry": "infinity"
},
{
"type": "edit",
"level": "sysop",
"expiry": "infinity",
"source": "صفحۂ اول"
},
{
"type": "move",
"level": "sysop",
"expiry": "infinity",
"source": "صفحۂ اول"
}
]

As you can see, the page is now protected two times for editing/moving. One is the semiprotection that was applied on that page individually, second is the protection that comes from the cascade.

In similar cases, MediaWiki picks the strongest protection (in this case, full protection), which means it requires editprotected to be able to edit it.

How do we see that? Shouldn't protect be enough here then? Troubling issue indeed.

No, because the page is now fully protected, and editing fully protected pages requires editprotected. Protect should never be enough for you to edit pages, it should only allow you to (un)protect pages (which you are able to edit).

I don't know about other wikis but since our policy has maintained that eliminators should be able to edit pages that are cascade protected, and if it requires to have editprotected, then they should have it.

Could you link to a policy that says this, please? Then I can change the right assignments :).

By the way, should eliminators be able to protect pages?

Nonetheless, I'm also unable to change protection of that page that I've linked above and that's just cascade-protected but semi-protected on its own? How do we see that? Shouldn't protect be enough here then? Troubling issue indeed.

In T281274#7038689, @Urbanecm wrote:

AFAICS, urwiki eliminators only have protect right, not editprotected right. That means they're able to (un)protect pages, but not edit pages that are protected.

Cascade protection is a special kind of protection, and I think it makes sense to require editprotected rather than protect (the string description is a bit confusing, and I would agree it should be clarified).

Should editprotected be granted to eliminators as well?

In T278350#6948386, @Urbanecm wrote:

In T278350#6948384, @Polyamorph wrote:

In T278350#6948370, @Urbanecm wrote:

https://en.wikipedia.org/w/index.php?title=Special:Log&logid=116619886: 11:45, 26 March 2021 Martin Urbanec talk contribs block moved page User talk:TheAafi/Help talk to Help talk:Getting Started (sysadmin action: fixing phab:T278350) (revert). moveBatch.php appears to did the trick! Closing, we should probably have a follow-up task to fix the cause of this.

Unfortunately that is not the correct page, it should be moved to Help talk:Getting started - note the lowercase "s"

Damn, I swear I copy pasted the title. Fixed with https://en.wikipedia.org/w/index.php?title=Special:Log&logid=116619997.