I've read https://www.mediawiki.org/wiki/Object_cache and the code documentation for WANObjectCache and I think following changes should be done:

• Interim Cache should be changed to use https://www.mediawiki.org/wiki/Object_cache#Main_stash given it's the only one that is replicated across datacenters.
• The removal of touchKey was incorrect and should be restored. WANObjectCache only replicates deletes and purges across datacenters.

I ran MessageGroups::singleton()->clearCache(); via shell.php and load the page from codfw and I think that fixed the problem.

Got to read the logs better now with another example. I see everything going fine:

• Interim cache is added
• On next rebuild interim cache is removed

Is there any appetite for generic wikitext mechanism of having content that is not part of the rendered page, apart from the html-like comments that cannot be nested?

https://translatewiki.net/w/i.php?title=Special:Translations&message=Phabricator%3Aarcanist-core-96e8155732e8324a
https://translatewiki.net/wiki/Special:Translations?message=Phabricator%3Aarcanist-core-80d305c58f97edfa&namespace=1274

CXServer may be a better place for caching to keep MinT itself simple(r). One could even go one step further and make a caching proxy API in MediaWiki, given MediaWiki has easy to use caching options.

Anything on any URL. E.g. this query fails for me https://phabricator.wikimedia.org/search/query/m03cFmqV18Sl/#R while logged in. I typed anything on the box on this page.

That another bug already exists: T277652: No markers for summary elements

FWIW I had tried this with action=login but did not get an exception, so I'm not sure which modules are affected.

It should not be an uncaught exception that appears in logs.

@cscott you added the warning in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/971981 so I'm wondering if you could explain what could cause it at https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-mediawiki-1-7.0.0-1-2024.04.19?id=Stu6844BX0U9mJhKtae3

Page marked for translation: 2024-04-19T03:21:22 Quiddity (WMF) talk contribs marked Tech/News/2024/17 for translation (UTC+3)

These are not the default configuration settings for MediaWiki or PHP (to my knowledge at least) so your wiki has been explicitly configured to exhibit this behavior. You should just get that fixed. Please see https://www.mediawiki.org/wiki/Manual:How_to_debug and for most parts do NOT do what it says.

Please keep it on topic. This task isn't about the deprecation, it's about fixing the deprecation warning in the Variables extension. In order to have situation you describe, I believe your wiki has to be configured both with https://www.mediawiki.org/wiki/Manual:$wgDevelopmentWarnings set to true and PHP to print notices during web requests. This is definitely not a configuration a production wiki should use. Notices should be directed to a log file.

https://translatewiki.net/wiki/FAQ#!!FUZZY!! seems correct. I was actually not aware of https://translatewiki.net/wiki/Quick_guide_to_editing_translatewiki.net but it's definitely incorrect.

Unfortunately there is no way to skip export without deleting the translation from translatewiki.net. We could use FUZZY with the English source text which would give translators easy access to the previous translations.

Ack. We're handling Phonos tasks in the Phonos board until we pick them up for sprints.

We are actively disabling VE on translation namespaces. Can't do much about people who will use VE on them anyway.

Considering resolved for now. In case this still appears in the future, we have some more logging now.

Done from our side.

We are planning to mark the values on the global mw object as internal and leave the hooks to be public.

DIfferent bug: This is caused by padding-bottom added by the Vector skin and also affects Template:Anchor on mediawiki.org. See e.g. T360917: [Spike 3hrs] Unintended vertical spacing behaviour .

There is potential for further improvements (trying to reduce even more articles / common terms matching in middle of language names, potentially automatically with a threshold), but that would require more effort for diminishing benefits.

I pinged again in GitHub.

The captcha config for production is https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/28b7f18fb5047102e4276d2f3e2abf48d047974a/wmf-config/CommonSettings.php#1814

Thanks for the feedback. I've updated the task description based on your suggestion.

I'm inclined to say that is solving a different issue and thus I would consider it out of scope for this task.

As @jhsoby pointed out https://www.mediawiki.org/wiki/Extension:VisualEditor#Changing_active_namespaces says we should use namespace names instead of ids (why? everything else uses ids). Maybe we didn't test this change properly.

These are not edit notices. They are legacy UI that we have kept around.

It wont.

@Tsevener Commits to review https://github.com/wikimedia/wikipedia-ios/commits/twn/

Big thanks @GLima-WMF! I'm marking this one as resolved. We will start implementing these designs this sprint.

This is how it looks to me:

Didn't reappear during recheck.

Seems not properly fixed? https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php81-docker/20433/console

If I remember correctly, this group name is missing from repoconfig.yaml.