See T355639: Move "Changetags" right only for bots and administrators by default in Wikimedia production.

I didn’t see this task when creating my own, I apologize. Since work is already underway in that task, I will close this one as a duplicate :) Thanks!

@Jdforrester-WMF hi! :) Have we any blockers for your patch?

In T355161#9715739, @DannyS712 wrote:

@Iniquity if you fill in the

Link to scc output for general sizing of codebases (https://github.com/boyter/scc):

part of the task description it might be easier for the security team to prioritize given just how *tiny* this extension really is (120 lines of PHP total and by my count 57 of those are comments and 14 are blank, so really 49 lines of PHP; no JavaScript)

In T355161#9715544, @sbassett wrote:

In T355161#9715467, @Iniquity wrote:

Is there any time frame for when this task will be taken on?

Not officially, no. As a team, we basically have a look at all requests that we've accumulated during a given quarter and then prioritize and distribute those across the limited resources Security Team AppSec has available for reviews each quarter. We try to accommodate every request as best we can, but sometimes there are re-prioritizations, delays, etc.

In T355161#9715419, @sbassett wrote:

In T355161#9708335, @Iniquity wrote:

@sbassett Hello! I see you have already created a pool of extensions for testing? Are we missing this quarter too? How long should we wait? Are there any criteria or something like that?
https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Security_Review_Planning/2024-04-08

Yes, unfortunately we had a few other reviews to accommodate at this time and due to our limited resources, this one wasn't able to be officially scheduled this quarter. Please also refer to our AppSec Review SOP: https://www.mediawiki.org/wiki/Security/SOP/Application_Security_Reviews#How_are_these_requests_prioritized?

@matmarex thanks for the info :) I think yes, this solves the case!

@sbassett Hello! I see you have already created a pool of extensions for testing? Are we missing this quarter too? How long should we wait? Are there any criteria or something like that?
https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Security_Review_Planning/2024-04-08

Thanks! I added a clearer case :)

In T177596#9671874, @Pppery wrote:

You have to write {{#babel:nocat=1|ru}} not {{#babel:ru|nocat=1}}. This will be addressed if T327847 ever goes anywhere.

Oh, nice! Thanks :)

Does not work :( https://ru.wikipedia.org/wiki/User:Iniquity/test2

Haha, oops, but the main thing is that we found the problem :)

Hi, @Pppery, I have taken setting's name here: https://www.mediawiki.org/wiki/Extension:Babel#Configuration :)

In T31272#9667744, @Bugreporter wrote:

In T31272#9666669, @Iniquity wrote:

Hello! Question/Idea: Can we use the GrowthExperiments-CommunityConfiguration "framework" for gadgets?

We need to first productionize it. Community configuration has multiple potential usages (described in T323811), but there are little we can do before that task is resolved.

Hello! Question/Idea: Can we use the GrowthExperiments-CommunityConfiguration "framework" for gadgets?

You can also see this bug on special pages: https://ru.wikipedia.org/wiki/Служебная:Версия?uselang=en

In T358424#9657188, @ovasileva wrote:

I’ve been wanting to ask for a long time, do we have any analytics for line length in different languages? :)

Do you mean recommendations for optimum line length?

In T358424#9657196, @ovasileva wrote:

In T358424#9651992, @Jdlrobson wrote:

In T358424#9651593, @Iniquity wrote:

In T358424#9651579, @Jdlrobson wrote:

Just FYI: Win10, Chrome

I can replicate that on Chrome only between 1200-1237px. I think to address this a more significant refactor of the Watchlist design would be needed to move it away from table-based layout (and that would be out of scope for the web team - as this is not a product we maintain). If we wanted a quick fix we could make the header scrollable.

My feeling is this is acceptable for now, particularly given the sidebar can be collapsed.

It also seems to me that this is not critical, this resolution is extremely rare. But this is a bug and it seems to me that it should be “remembered” for the future.

Totally. @ovasileva let me know if you need help creating a new ticket capturing the "correct" way to address this. This would be a task for the Growth-Team

I can't seem to replicate at that resolution. @Iniquity - do you have a screenshot?

I decided to check languages with long words and this is what I found:
https://meta.wikimedia.org//wiki/Special:Watchlist?hidepreviousrevisions=1&hidecategorization=1&hideWikibase=1&limit=250&days=3&urlversion=2&uselang=ml
https://meta.wikimedia.org/wiki/Special:Watchlist?hidepreviousrevisions=1&hidecategorization=1&hideWikibase=1&limit=250&days=3&urlversion=2&uselang=tyv
https://meta.wikimedia.org/wiki/Special:Watchlist?hidepreviousrevisions=1&hidecategorization=1&hideWikibase=1&limit=250&days=3&urlversion=2&uselang=bci

Hello! Could you please advise? :) I have two tasks T348410: 'Property' text size too small on IP info page and T356574: Too small a text size when replying by DiscussionTools, are they part of this one?

In T358424#9651579, @Jdlrobson wrote:

Just FYI: Win10, Chrome

I can replicate that on Chrome only between 1200-1237px. I think to address this a more significant refactor of the Watchlist design would be needed to move it away from table-based layout (and that would be out of scope for the web team - as this is not a product we maintain). If we wanted a quick fix we could make the header scrollable.

My feeling is this is acceptable for now, particularly given the sidebar can be collapsed.

Great! Thanks! :)

In T358424#9645826, @Edtadros wrote:

Test Result - Beta

Status: ✅ PASS
Environment: rubeta
OS: macOS Sonoma
Browser: Chrome
Device: MBA
Emulated Device:NA

Test Artifact(s):

QA Steps

Steps to replicate the issue (include links if applicable):

Open on mobile or with devtools https://ru.wikipedia.org/wiki/Служебная:Список_наблюдения?uselang=ru on beta https://ru.wikipedia.beta.wmflabs.org/wiki/%D0%91%D0%B5%D0%BB%D1%8B%D0%B9_%D0%BC%D0%B5%D0%B4%D0%B2%D0%B5%D0%B4%D1%8C
Look at filters
✅ AC1: Buttons should be wrapped on a new line

Related: T330068

In T355639#9574560, @IKhitron wrote:

In T355639#9561700, @IKhitron wrote:

One more question, please. If we "write it as a task on the Phabricator", as mentioned above, what are our chances to leave it on our wiki as is? You said nothing about this.

While we're waiting for the answer, one more question, please. When you say in the Tech News that "Your community can ask to retain the old configuration on your wiki before this change happens.", what do you expect? A local concensus? A request from random user? A request from somebody that actualy used this? Thank you.

Considering that there has been no movement for a year and a half, we need to translate it ourselves and create a 'fork'.

In T355639#9573621, @UOzurumba wrote:

Future change: The right to change [[mw:Special:MyLanguage/Manual:Tags|edit tags]] (<code>changetags</code>) will be removed from users and bots by default in Wikimedia sites. Your community can ask to keep the old configuration on your wiki before this change happens. This needs to be done by [insert date] at T355639.

@Iniquity
For Tech News, what date should I put in the [insert date]?

In T355639#9572603, @Iniquity wrote:

In T355639#9570311, @UOzurumba wrote:

Future change: The right to change [[mw:Special:MyLanguage/Manual:Tags|edit tags]] (<code>changetags</code>) will be removed from users and bots by default in Wikimedia sites. Your community can ask to keep the old configuration on your wiki before this change happens. This needs to be done by [insert date] at T355639.

@Iniquity
For Tech News, what date should I put in the [insert date]?

Hi :) This is hard question, @Jdforrester-WMF, can you help with it?

I put before the end of March. Hopefully, this is fine. Thanks!

@Pppery Hello! Don't know where you can add new levels? I couldn’t find it, apparently it’s in the database somewhere?

In T355639#9570311, @UOzurumba wrote:

Future change: The right to change [[mw:Special:MyLanguage/Manual:Tags|edit tags]] (<code>changetags</code>) will be removed from users and bots by default in Wikimedia sites. Your community can ask to keep the old configuration on your wiki before this change happens. This needs to be done by [insert date] at T355639.

@Iniquity
For Tech News, what date should I put in the [insert date]?

In T354501#9440126, @brion wrote:

Should work on iOS 12 and up iirc, I'll have to run more tests

In T355639#9561710, @stjn wrote:

Better wording to reflect what’s happening:

Future change: The right to change [[mw:Special:MyLanguage/Manual:Tags|edit tags]] (<code>changetags</code>) will be removed from users and bots by default in Wikimedia sites. Your community can ask to keep the old configuration on your wiki before this change happens. This needs to be done by [insert date] at T355639.

Thanks!

In T275155#9471138, @KStoller-WMF wrote:

Thanks, @Iniquity! There might be a few more related tasks that need to wrap up first: T354459: [Epic] Support conditional defaults for user properties to help address user_properties table bloat, but hopefully we can work on this soon.

It seems to me that for now we can warn the community and ask if there are any cases where this is used:

Can reproduce, latest Chrome, Win11. Perhaps this is due to T290706

In T355258#9550309, @thiemowmde wrote:

The arguments we collected in T213066: Proposal to remove all version numbers from all WMDE maintained extensions might help, in case you need some.

Thanks a lot! :)

It seems to me that there will be no more work on this task and it can be closed, right? :)

To simplify, we just need to create new categories, then there will be no confusion.

In T353365#9521095, @CCiufo-WMF wrote:

Now the buttons, if they are located under each other, stick together and there is no empty space between them.

I don't have historical context on this, but are you saying there used to be a space, or that this was always an issue and continues to be?

@Jdlrobson Hello! <s>Are you sure this is the same task? :) It seems to me that destroying an object when you click outside it and destroying an object when you hide the sticky header are slightly different things.</s> I have found the right task :)

This can be solved through translateiki.net and discussion on the forum; it has nothing to do with the developers :)

Everything is fine in Chrome, it seems to me that this is a problem with Edge.

Have you considered removing the tagline altogether? Or write it in plain text not image?