This is now the only remaining read from wgLang in Wikimedia production. The solution by Tacsipasci sounds reasonable to me, but ultimately I do not feel knowledgeable enough to make it happen.

@SomeRandomDeveloper It seems to me that it would be nice to make a push to have your open change land in MW 1.46, to get wgOut on track for deprecation in a few versions. What do you think?

Since extension code should not come into play in the installer, what do you think about trying to remove writing to wgLang there completely?

This is a good point.

In T423283#11820193, @Tacsipacsi wrote:

Also, GlobalCssJs uses the context to get the main config from it – this wouldn’t need a context at all.

Just to have a mark for future progress, on 12/04 codesearch showed 432 files using RequestContext::getMain outside phpunit.

I do not quite understand these Ingress things, but neither the maintenance script nor the Job should have a meaningful requests available anyway, so they could pass a trivial FauxRequest. LogPage::addEntry should just take a WebRequest as a parameter, for how to deal with ManualLogEntry I am not so sure.

• insertRecentChange
  • maintenance/importTextFiles.php script
  • ChangeTrackingEventIngress::updateRecentChangesAfterPageUpdated
  • CategoryMembershipChange::notifyCategorization
  • LogPage::saveContent
  • soft-deprecated RecentChange::save -> no callers

• createCategorizationRecentChange: 1 caller
  • CategoryMembershipChange::notifyCategorization -> CategoryMembershipChange::createRecentChangesEntry -> CategoryMembershipChange::triggerCategoryAddedNotification / CategoryMembershipChange::triggerCategoryRemovedNotification -> CategoryMembershipChangeJob::notifyUpdatesForRevision -> CategoryMembershipChangeJob::run

• createLogRecentChange: 2 callers
  • LogPage::saveContent -> LogPage::addEntry where some other extra context is floating around ->  a limited slightly obscure set of extensions which generally have a context available
  • ManualLogEntry::getRecentChange
    • [[ https://codesearch.wmcloud.org/search/?q=getRecentChange%5C%28&files=&excludeFiles=&repos= | some extensions which may or may not have a context available ]] and a bunch of false positives
    • ManualLogEntry::publish -> a lot
    • many instantiations of ManualLogEntry as well

In Collection and FlaggedRevs the context objects were not far away (even though in FlaggedRevs are some left over), in the other three extensions RequestContext was used exclusively to access the config.

Once a probable need of bigger refactorings is identified for certain callsites, an individual task should be created.

FYI

At the moment, I am referencing this task directly if we have just a single, rather simple isolated change, and create subtasks for things which involve multiple correlated changes.

The project would not be limited to that, but also encompass things like

• T418569: MediaWiki\Context\RequestContext::getTitle called with no title set.
• T307395: Enable `RequestContext` to be created via a factory method & inject other service objects into it
• T323187: Disallow cloning of RequestContext objects
• T341951: MediaWikiTest::testInvalidRedirectingOnSpecialPageWithPersonallyIdentifiableTarget leaks overrides in RequestContext::getMain
• T103653: "Invalid or virtual namespace -1 given" when submitting access request

with a project making it significantly easier to keep an eye on this area of code, which do not share any common tag otherwise.
One could complement this with a goal task, but not all IContextSource-related issues are about the removal of RequestContext.

Well. technically I wanted to leave this open for the final change after the 1.46 branch cut, dropping the unused stuff I deprecated in the last few weeks. But in the end it does not matter so much.

I have realized that ChangesList::userCan is a similar case: It optionally takes a performer, falling back to RequestContext, but is never called without one. So I added the deprecation to the change. Once these fallbacks are removed, ChangesList no longer depends on RequestContext.

Flow seems to heavily rely on the use of wgLang in its maintenance scripts. But accessing request context in maintenance scripts seems to more generally occur:
https://codesearch.wmcloud.org/search/?q=RequestContext%3A%3AgetMain%28%29&files=maintenance&excludeFiles=&repos=
I have no clue where these scripts actually would get a sensible language from. There does not seem the place where it could be set, so RequestContext::getLanguage should end up with $code = $wgLanguageCode as a fallback.

@SomeRandomDeveloper Do you happen to know whether there is any way to obtain a context in standard maintenance scripts?

With wgLang being on track for deprecation, this would need to be resolved, as we can not migrate to RequestContext here. Would it be possible that the users of this service specify the language instead?
Having no previous experience with Wikibase, I would like to avoid to get into this myself.

I fear you might have misread the discussion. The change is nigh-universally supported. However, a single one of the supporters is on a mission to establish a rule contrary to general RfC regulations, that any such change needs to be subject to a formal vote. Even after wide adverstisement of this point of view, this user has remained isolated with their perspective.

See task description for link of discussion.

I would appreciate a statement whether there are plans to keep a backup in place for a limited period of time. WMF employees have expressed different views here, and it is unclear to me who's qualified to make the call.

While this may be confusing, it reflects the current behavior for rights logs, which are neither carried to the new account on renaming.