Deployed

In T391009#11248622, @Superpes15 wrote:

Please open a new task with the details (similar to T369264 ) and indicate the projects from which you want to import. Thanks.

In T391009#11239186, @saper wrote:

Would a complete database import be an option?

This problem is caused by an improper handling of non-ASCII characters. Likely, there's missing call to urlencode when constructing the Wikipedia API query.

In T398939#10984862, @Pppery wrote:

You're using DPL in a weird way there - you're not passing a valid category name but instead an undefined parameter. While it shouldn't GIGO like this that's hardly an important issue.

This is a problem with enwiki override of the message MediaWiki:Searchmenu-new. The default shipped with MediaWiki works fine.

Thanks for taking care of it!

The change has been merged. MediaWiki may now need some time to reprocess the pages.

I have to point out that the "Mark as favorite" button is visually imbalanced with the "Watch" button. The latter uses a 16x16px icon, whereas the former is 20x20px.

Apparently, the relevant page at plwiki was somehow missed. I've just moved it manually, as users reported that options for creating a citation disappeared from VE.

In T393473#10809468, @Pppery wrote:

Looking at the enwiki abuse logs: https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=autocreateaccount&wpSearchActionTaken=disallow&wpSearchFilter= filters blocking autocreation happen a few times a month.

And the community is well aware of the consequences that entail: https://en.wikipedia.org/wiki/Wikipedia:Edit_filter_noticeboard/Archive_9#Filters_887_and_890_and_autocreateaccount

In T391096#10802420, @Zabe wrote:

Without any deeper look, this sounds like https://m.mediawiki.org/wiki/Extension:AbuseFilter#Emergency_throttling.

I can help with Polish

It's now merged

In T393353#10791327, @Bunnypranav wrote:

Hey @Msz2001, in your patch, you have set the perm to false, which basically restricts them from seeing the private filters. Is that what you want?

$wgGroupPermissions['sysop']['abusefilter-view-private'] = false;

Oh, right. I completely forgot about that.

Oh, now I see that this behavior is intended: https://meta.wikimedia.org/wiki/Tech/News/2025/16

I've fixed a similar issue on plwiki by just throwing away the hardcoded background value in the styles in favor of CSS variables: https://pl.wikipedia.org/w/index.php?title=MediaWiki:Citethispage-content&diff=prev&oldid=75405133 (this changed the bluish bg to gray but I don't think it's a big issue, especially that in general Wikimedia wikis are nowadays using color scarcely in the UI; by the way, the template I've removed there was also outdated, that's why it got removed).

In T391009#10711709, @Msz2001 wrote:

In T391009#10711288, @Superpes15 wrote:

@Msz2001 Are you sure you don't need local file upload? Other private wikis have enabled it (u4cwiki, ombudswiki, arbcom_itwiki and so on). If ArbCom needs to upload files locally it can do so.

Over the last 18 years there have been only a few files uploaded to the current plwiki's arbcom wiki. All of them were taken from Commons and used for decorational purposes. Thus, I didn't ask for local upload so as not to introduce additional complexity into the wiki creation process when it's apparently not needed.

In T391009#10711288, @Superpes15 wrote:

@Msz2001 Are you sure you don't need local file upload? Other private wikis have enabled it (u4cwiki, ombudswiki, arbcom_itwiki and so on). If ArbCom needs to upload files locally it can do so.

I've just checked and the flickering effect is gone. Thanks for working on this!

In T388049#10657996, @egardner wrote:

1. Roughly how many items are contained in these dropdown menus that are flickering and jumping around? Is it a very large number of items (like more than could fit on the screen)?

That makes sense to me. (I can update the task description Saturday morning UTC, as I'm now on mobile - or if anyone wants to do it earlier, feel free to :) )

If I count correctly, it's 15 messages (my contribs on TranslateWiki, starting with Logentry-, ending with /pl).

In T369466#10535070, @Lakejason0 wrote:

Adverbials like "unchanged" would have to be after the object (groups here). Since the lego messages are split into "granted $1" "revoked $1", all the commas are added in codes using the common translated messages of punctuations, maybe just write "{{GENDER:$2|kept}} $1 without changes" or "{{GENDER:$2|kept}} $1 unchanged"?

Maybe "kept unchanged"? It would still be shorter than the current "kept without changes" and I still feel it fits somehow better (at least for me).

The idea behind kept without changes was to have a parallel structure of this message, where every part is introduced using a verb

I've submitted a patch that drops colons after granted, revoked and changed expiration of. The colon is still after kept without changes to signify that it isn't a next part of this "list of changes" but rather on the same level as "Sysop changed group membership for User:"

When preparing the log message I inspired myself with the use of punctuation as in gblrights/setmodify log (see on Meta), that has this double colon as well

In T385086#10517159, @Tchanders wrote:

@Msz2001 Thanks for sharing this. Is it possible to copy the comment over to T376612, which is the original task for using a central page on metawiki?

(as asked by @Tchanders at T385086#10517159, I'm pasting this comment here)

In T385086#10514854, @Msz2001 wrote:

What will be the effect of this task after temp accounts are rolled out everywhere? Will people still be directed to the central wiki or will they see the page on their home wiki?

I'm asking because this redirect will mean that:

• people by default will see the page in English instead of their language;
• already-set preferences will not take effect -- e.g. format of displaying dates (incl. timezones), light/dark mode and content width (for Vector 2022) -- I'm not sure how many people set that in their global preferences but rather not many;
• gadgets and user scripts people are used to will not be loaded;
• there may be troubles with linking to the page, as one will need to create an interwiki link perhaps using an alphabet/language foreign to them (at least in a scenario like now where the special page does not exist locally);
• the return path is hard, as all the links in the UI lead to a different wiki than the user went from

I've submitted patches that make the rights log like in comment T369466#10500632. I didn't, however, change the messages in the IRC format, as it would make the code much more messy and I'm not sure who would benefit from that.

What will be the effect of this task after temp accounts are rolled out everywhere? Will people still be directed to the central wiki or will they see the page on their home wiki?

I've prepared patches with the grammar rules. However, I've noticed two things that stem rather from the LanguageConverter behavior:

• W is not converted to В, e.g. Wikipedija is rendered as Wикипедија
• Wikirječnik is converted into Викирјечник (with ј)

In T369466#10502069, @Nemoralis wrote:

I would prefer "Admin granted bureaucrat to LoremIpsum" format

I've came up with messages like these:

In T332467#10490146, @jhsoby wrote:

In T332467#10479641, @Msz2001 wrote:

Grammar support in MediaWiki works based on a dictionary lookup, so it can support a limited pre-defined set of words and cases. […]

Some grammar functions work like that, but not all. The limiting factor is the complexity of the language's rules. Two examples:

• LanguageFi.php: Several cases, but made to support sitenames only because the language's rules are complex
• grammarTransformations/nb.json: One case, but supports basically everything, because the rules for this are easy and straightforward

In T378872#10486561, @SomeRandomDeveloper wrote:

Apart from overriding the color in the extension's CSS (which I could provide a patch for), is there a better solution for this? This is the same problem as T381316, both are anchor elements with the button role and thereby excluded from the selector that applies the correct color

I can help with adding these. But, as I don't speak this language, could you please provide me a table of words and their grammar forms that you'd like to have implemented?

As I was giving the rights to Vaughn, I've spotted an issue with the group name. It doesn't display in a localized form, but rather uses the internal code-string event-organizer (no matter whether the page language is set to Polish or English). It happens both on the Special:UserRights and Special:ListGroupRights. I'd expect that the extension provides some translatable defaults.

Yeah, I agree that disabled "Continue" button would also be confusing (as it would suggest that they cannot proceed from the initial state).

I've tested it on beta cluster and it appears to work: https://en.wikipedia.beta.wmflabs.org/wiki/User:Msz2001/sandbox

In T378833#10377353, @ppelberg wrote:

Per offline discussion with @Trizek-WMF, Flow will be set to read only at Phase 1 wikis (see task description), this Thursday.

In T346348#10404504, @Nardog wrote:

per-wiki, using $wgPhonosButtonClasses, which can be set to eg. [ 'noexcerpt' ] to preserve the current behavior;

What if you made this a message instead? That way not only devs but interface admins can configure it.

Since I've stumbled upon this thing again when cleaning up things on wiki, I've submitted a patch that makes it configurable what (additional) CSS classes are present on the PhonosButton element (noexcerpt included). This can be done in two ways:

• per-wiki, using $wgPhonosButtonClasses, which can be set to eg. [ 'noexcerpt' ] to preserve the current behavior;
• per-instance, passing class attribute to the <phonos .../> tag, which overrides (is not merged with) the above, eg. <phonos class="" ... /> will suppress extra classes that are added by default on the given wiki and <phonos class="lorem-ipsum" /> will make Phonos button with only lorem-ipsum as the custom class.

It appears that the mass message hasn't been delivered to some pages (eg. pl:Pomoc:Pytania_nowicjuszy), with an error code saying "This page will be moved and archived" to Pomoc:Pytania nowicjuszy was skipped because target was in a namespace that cannot be posted in. This seems to be the case also for ptwiki help desk.

Unfortunately, fix to T379218: New pages are not autoreviewed despite creator having autoreview right doesn't fix this issue, so moved pages still become unreviewed.

If anyone is interested in that, I've created a bot to automatically review moved and created pages (this is the bot that Wargo talks about above). It works in real time, based on EventStreams, so as to make an impression that this issue is no longer present. (Review log from plwiki).

In T379218#10304174, @binbot wrote:

For the time the issue will be corrected, I hacked a little scipt that reviews new pages that were edited only by trusted users. Please forward the information to the bot owners in your wiki.
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/huwiki/temp_review.py