In T379205#10346390, @Pcoombe wrote:

One request: can we change the links to use wmf_ as a prefix instead of utm_? We've been gradually shifting donation links to use this since an increasing number of clients strip any utm_ parameters from urls (T367361) So https://donate.wikimedia.org/?wmf_source=donate&wmf_medium=sidebar&wmf_campaign={{SERVERNAME}}&uselang={{USERLANGUAGE}}

I saw this just now at https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php74/41077/console

I mostly need someone from fundraising to sign off on the change to utm_campaign or to express an opinion on the correct value of that parameter. Other than that, it should be uncontroversial and reviewable by anyone.

Fix released.

I guess the main error in patch is assuming that renameIndex() conditionally runs a patch file. That's what it does in DatabaseUpdater, but it's overridden by PostgresUpdater to do its own special query. The patch file parameter is ignored.

Note that index names in PG have schema scope, so even if PRIMARY were a valid name, you could only have one such index across all MW tables. It needs to be globally unique name. I think the name as installed would be searchindex_pkey, and manually renaming to that does seem to work.

It would be good to have this in the next week or two for T352113. Otherwise there will be some kind of awkward workaround.

It starts with E_DEPRECATED from ScopedCallback.php:57, emitted while loading that file.

I generated overrides.php locally and confirmed that it has the same MD5 hash as Scott's paste. The character tables are in the PHP source tree, so any local installation should be sufficient to generate these tables.

Simplest fix is to just create the table.

Works for me.

The slow request was

The MW installer has a feature allowing the user to check a box to subscribe to mediawiki-announce. I tried to test it, since I'm doing maintenance on the client code. It timed out in the client, but the Apache logs on lists1004 show it completing successfully after 56 seconds. I got the confirmation email. I did another two requests with the same email and they each took about 57 seconds.

I couldn't reproduce it with the old form. With codex enabled, and I had to revert 1080830 due to an exception "can't convert null to object", then I could reproduce it. Client-side code made an API request with the parameter allowusertalk=1, which is obviously not correct.

In T4085#10235030, @Quiddity wrote:

Please could someone suggest wording for this proposed Tech News entry, including what documentation it should link to. Thanks.

In T223772#10210207, @IKhitron wrote:

I just saw it in the Tech News. Thank you. Could you please write a manual?

In T374591#10143325, @Joe wrote:

I think that when you have a list of tasks to execute that have side effects like creating databases and tables, you want the task to be idempotent, or - alternatively - to have a rollback mechanism in case of failure.

I don't think this is feasible. MediaWiki has an internal concept of a qualified table name with dot-separated components. SQLPlatform::qualifiedTableComponents() is complicated enough as it is without adding such special cases.

It's only been marked stable to override since 2022 and it seems that it was never actually overridden by anything.

In T223772#10037953, @PerfektesChaos wrote:

• pretty does not fully react on language.
• Apparently it is always English day number (digits) plus adapted full month name: 2 August
• That does not follow project/page language, as date both do.
• Germans would expect 2. August with a dot after day number.
• Month name is following supposed language.
• Same story for Portuguese:
  • {{#timef:now|date|pt}} → 2 de agosto de 2024
  • {{#timef:now|pretty|pt}} → 2 agosto
  • Expecting a de after day number (digits).
• Not pretty.

In T258852#10120147, @tstarling wrote:

I'm considering whether this is a subtask of T352113: Move the addWiki.php maintenance script from WikimediaMaintenance into MediaWiki core which I'm working on now.

I'm considering whether this is a subtask of T352113: Move the addWiki.php maintenance script from WikimediaMaintenance into MediaWiki core which I'm working on now.

I'm going to work on T352113, which I think is basically the same as this task for third party purposes, except that it uses a new maintenance script, and so has fewer backwards compatibility issues.

For configuration propagation, it turns out to be better to have the Command act as a factory, so we will have:

In T292322#9614342, @Joe wrote:

@tstarling I think we determined that the expensive part of handling large files in shellbox was mostly the download/hash verification of the file received, I don't even think we strictly need PUT support.

Since the bug I found is not reproducible in 8.2 or 8.3, it's probably not the same as the one reported above. Further discussion on it will be on the PHP bug tracker at https://github.com/php/php-src/issues/15502

After spending a bit more than a day on this, I'm going to file a separate task for the bug I found, since it's affecting a specific line of code in MediaWiki and is relatively easy to reproduce.

I tried running MediaWiki on PHP git master (8.4-dev), compiled with AddressSanitizer, with Excimer profiling at a high rate (1ms). I hit a dangling pointer bug pretty quickly which does seem to depend on Excimer although Excimer is never in the stack. I'm working on isolating it. Maybe it will be that simple.

@Warxcell OK thanks, I found the calling code.

How are you using Excimer? This sort of thing is more likely to happen if it's actually called.

I think it's feature-complete now.

@TheDJ try that ^

In T363885#10051120, @TheDJ wrote:

Any ideas ?

In T364221#9787869, @MusikAnimal wrote:

Amazing! Would it make sense for the long-term repo to be on GitLab? Just wanted to make you aware of https://gitlab.wikimedia.org/repos/commtech/ which I just added you to :)

In T370610#10010516, @dcaro wrote:

Or to tell it that the size limit is unlimited (it just sets it to 0), @tstarling any preference on what big numbers to use to overwrite the limits?

In T370610#10010264, @dcaro wrote:

@tstarling I have a patch that implements the fix mentioned in the link above, do you have an image I can play with/test to make sure it works?

Bot updated. Template diff after editing "last updated" vs "created"

@aborrero tells me that the Debian maintainer is willing to remove the resource limits from policy.xml in the Debian package. That would be great to see, and will eventually help us to avoid production issues like T344233. It will also carry weight with Heroku if we decide to open a pull request there.

In T370230#9989106, @Samwilson wrote:

This might be true, but the main issue is that none of the fallbacks are applied, isn't it?

Fallback to zh is not ideal given the mutual intelligibility gap between Simplified and Traditional Chinese.

I can reproduce this with breakpoints set. onUpdateProject() is called first from the cdx-card @click handler, and then second from the cdx-checkbox @update:model-value handler.

In T369554#9975664, @GMikesell-WMF wrote:

@tstarling Please review issue below, thanks!
The title "Lorem ipsum" is below the "Last updated" title in the table, even though "Lorem ipsum" has a more recent date

In T223772#9975603, @Bugreporter wrote:

{{int:lang}} is a hack, and requires wikis creating some MediaWiki messages. See T4085: Add a {{USERLANGUAGE}} magic word

#time allows the user to specify an arbitrary language code, so I may as well extend that feature to the new function. The target keyword is not really necessary, since omitting the parameter would have the same effect. I can split the user keyword out to a separate commit.

Goals:

• Reasonably compact
• Encourage the use of the page language
• Give access to the user language, for the convenience of Commons where user and content language are conflated
• Give access to date, time and "both" formats

I installed AbuseFilter: https://wishlist-test.toolforge.org/wiki/Special:AbuseFilter

In T235397#9959778, @Tacsipacsi wrote:

What about creating a first version that doesn’t allow overriding any defaults (no changes to fuzzy units, no changes to priority languages, no toggling of page title translation, no toggling of translation-aware transclusion, no syntax version updates)? If I understand correctly, neither Community Tech nor @DannyS712’s bot needs the ability to override anything.

We need it for the community wishlist. The idea is to mark wishes for translation in a semi-automated way, with a gadget that runs as a translation admin (T365558). I don't think we need to override the defaults for the nofuzzy checkboxes.

Or there can be a nofuzzyunits parameter and a fuzzyunits parameter, the latter subtracting from the default set.

For API usability, I think an API request with action=markfortranslation & title=Foo should be equivalent to loading the form for that title and submitting it without changing any defaults. There's a couple of things in TranslatablePageMarker that make this inconvenient, like its need to overwrite the priority languages unconditionally. But it can be done.

The POST branch of PageTranslationSpecialPage::onActionMark() seems simple enough, but I assume a query API similar to showPage() will also be needed, and that looks a bit bigger. Unless it's enough to expect the client to guess the unit IDs for $noFuzzyUnits.