Change 146608 had a related patch set uploaded (by Jackmcbarn):
Add redirect support to modules

https://gerrit.wikimedia.org/r/146608

Is there any update on the status of this task? This would enable renaming a deployed module seamlessly, without having to resort to a copy-and-paste move to the new module name, followed by redirecting the old module to the new one.

See https://en.wikipedia.org/wiki/Wikipedia_talk:Lua/Archive_3#Proposal_to_restrict_page_moves_in_the_%22Module%3A%22_namespace_to_administrators for background on the request.

Change 574086 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/Scribunto@master] Add redirects for modules

https://gerrit.wikimedia.org/r/574086

Tagging editing team for code review per https://www.mediawiki.org/wiki/Developers/Maintainers

Any updates?

As the task hasn't been updated, no.

Change 146608 abandoned by Legoktm:

[mediawiki/extensions/Scribunto@master] Add redirect support to modules

Reason:

In favor of I405e7953d00af8a34d5e8addc61a245732c71e8e.

https://gerrit.wikimedia.org/r/146608

I left feedback on the patch, the main question I have is whether we want a preceding --[[ #REDIRECT ]] comment like we do for JS/CSS redirects.

It is completely fine to add (after empty line) such comment after statement as an explanation for such stupid one line modules.

Might be followed by timestamp, if possible, to make automatic generation more obvious and to find the event faster in version history of target page.

When all the usages and links to the old page have been updated, the redirect could be deleted, and migration process has worked without any interrupt.

In T120794#8274692, @PerfektesChaos wrote:

It is completely fine to add (after empty line) such comment after statement as an explanation for such stupid one line modules.

Ack.

Might be followed by timestamp, if possible, to make automatic generation more obvious and to find the event faster in version history of target page.

Interesting idea, I would like to hear others' opinions on this idea and would prefer to leave it out of the initial patch.

My current thinking is that we want it to look like:

-- #REDIRECT
return require( "Module:Target" )

Yes/no?

(If we don't hear from Danny in the next few days I'll update the patch)

In T120794#8277530, @Legoktm wrote:

My current thinking is that we want it to look like:

-- #REDIRECT
return require( "Module:Target" )

I would prefer this format.

Also, would we like to support localized #REDIRECT or keep it in English?

In T120794#8277562, @Winston_Sung wrote:

Also, would we like to support localized #REDIRECT or keep it in English?

English is sufficient, since the audience are Lua programmers rather than encyclopedic authors. Lua is English.

My major concern is that someone encounters the module link and asks which bloody fool wrote a module of one silly line.

-- #REDIRECT (page move)

The idea is to detect all occurrencies even in currently inactive paths, then deleting that redirect.

In T120794#8277562, @Winston_Sung wrote:

Also, would we like to support localized #REDIRECT or keep it in English?

Currently module pages are forced to English because as PerfektesChaos notes, Lua is English. I don't think this is the ideal behavior (see e.g. T126308, T299279 as problems caused by this), but it is probably too much to take on here. If we do fix that, we could add localization for #REDIRECT afterwards, as I do disagree that "English is sufficient".

In T120794#8277692, @PerfektesChaos wrote:

My major concern is that someone encounters the module link and asks which bloody fool wrote a module of one silly line.

People can use the page history and figure it out pretty easily.

In T120794#8277692, @PerfektesChaos wrote:

In T120794#8277562, @Winston_Sung wrote:

Also, would we like to support localized #REDIRECT or keep it in English?

English is sufficient, since the audience are Lua programmers rather than encyclopedic authors. Lua is English.

My major concern is that someone encounters the module link and asks which bloody fool wrote a module of one silly line.

Given that the audience is programmers, I feel they will recognize that the module is delegating to another for its implementation.

I ended up removing -- #REDIRECT after reading Anomie's earlier code review on the patch which pointed out that it wasn't necessary (like in JS/CSS) because there's no confusion with a legitimate module.

Using something simplistic like the proposed return require( "Module:Target" ) can easily be detected by the target module, perhaps even affecting its functionality. Specifically, ... will have a value during the module initialization because the module is required and not directly #invoked and mw.getCurrentFrame():getTitle() will refer to the #invoked title and not the redirection target. Also reported script errors will list the #invoked module in the call stack because the target module is not truly treated as the Lua "main" module.

A more complete, albeit more complex, solution would be to catch the #invoke function name by using an __index metamethod and then calling mw.getCurrentFrame():getParent():callParserFunction('#invoke', {[[TargetModuleName]], funcname, ...}), providing the function name and the frame args. The tricky part would be massaging the args to include the TargetModuleName and the function name caught by the __index metamethod as well as the frame args from mw.getCurrentFrame().args.

Something along these lines:

return setmetatable({}, {
	__index = function(pkg, funcname)
		return function(frame)
			local pfargs = {[[TargetModuleName]], funcname}
			-- repack sequential args; implication: numeric parameter keys will be altered
			for i, v in ipairs(frame.args) do
				pfargs[1 + #pfargs] = v
			end
			-- copy other args; implication: accessing all the args means all their values will be expanded
			for k, v in pairs(frame.args) do
				if 'string' == type(k) then
					pfargs[k] = v
				end
			end
			return frame:getParent():callParserFunction('#invoke', pfargs)
		end
	end
})

Perhaps the best solution would be to add something to the Scribunto Lua API and just call that for the redirection then it could have PHP counter parts like many other parts of the Scribunto Lua API and could easily implement a #invoke redirection functionality which would always work and could not really be detected by any Scribunto Lua module (and thus cannot affect their functionality).

Maybe something similar to frame:extensionTag, which is essentially a specialized wrapper for callParserFunction with #tag, could be developed for #invoke allowing for the function name to be passed through in fashion like content is for frame:extensionTag. The up side of such a thing would be not needing to play with the args (which cause them to be expanded).

Another issue to consider is parsing to determine what constitutes a redirect module. There are many different Lua syntaxes that can accomplish the same thing and I imagine they would not all be detected as redirects even thought they accomplished effectively the same thing. For example even if we stick with the flawed return require( "Module:Target" ) , I could add variable to the mix to hold the interim require return value. I could change the literal string format to single quotes or one of the many possible long string literal formats. I could leave out the parentheses in the require functional call using the single literal string functional call syntax. There are many ways such a module redirect could be modified and we need to ensure that they are still detected as a valid redirect module (in much the same way as there are many ways to modify #REDIRECT wikitext redirects while they are still considered redirects).

For these reasons, I believe a dedicated Scribunto API change is much preferred for introducing module redirects (e.g., providing the funcname in the frame would go a long ways but it should be possible to cause Scribunto to just punt to another module with same funcname and frame args, possibly by just having Lua run another "main" module).

Contributors-Team is currently an archived project.

@DannyS712 You have an open Gerrit change on this, it’d be easier if you could finish it. If you can’t or don’t want to, maybe you should also abandon the change (it can always be restored), not only unassign the task.

Change 574086 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@master] Add redirects for modules

https://gerrit.wikimedia.org/r/574086

Re: Tech News - it looks like this is ready to be announced in next week's edition.
What wording and links (documentation?) would you suggest as the content? My best-guess is something like:

Changes later this week

• It will be possible to redirect pages in the Module namespace, and moving a Module will leave a redirect behind.

But I'm uncertain about the wording, and can't see any existing documentation about it on mediawiki-wiki. Thanks!

The first part of the sentence is not entirely correct: the construct used for redirecting modules is standard Lua code, which could always be used to “redirect” modules, but they haven’t previously been recognized as such (weren’t italic on special pages, weren’t hidden from Special:UnconnectedPages etc.), so the new thing is that one particular syntax to “redirect” modules is now recognized as a redirect (plus that moving modules will leave redirects behind).

Specific suggestions for how to word it, and what to link to, would be greatly appreciated!

In T120794#9407752, @Quiddity wrote:

Re: Tech News - it looks like this is ready to be announced in next week's edition.
But I'm uncertain about the wording, and can't see any existing documentation about it on mediawiki-wiki. Thanks!

Added documentation at https://www.mediawiki.org/w/index.php?title=Extension%3AScribunto%2FLua_reference_manual&diff=6267770&oldid=6228438

Suggested wording:

"Full support for redirects in the Module namespace was added: the "Move Page" functionality in the sidebar will now leave an appropriate redirect behind, and such redirects are appropriately recognized (italic on special pages, hidden from Special:UnconnectedPages etc.)."

Two questions:

1. Should the redirect page use design similar to a general redirect indicating that this is a redirect instead of continuing to use scribunto-doc-page-does-not-exist/scribunto-doc-page-show?
2. Does not support any syntax that is different from return require [[Module:Target]] (even if the number of spaces is different return require[[Module:Target]], or quote return require "Module:Target", etc.) is a "feature" of this new functionality?

In T120794#9413572, @SunAfterRain wrote:

2. Does not support any syntax that is different from return require [[Module:Target]] (even if the number of spaces is different return require[[Module:Target]], or quote return require "Module:Target", etc.) is a "feature" of this new functionality?

In https://gerrit.wikimedia.org/r/574086 :

• we might as well keep it a strict check, we can loosen it later if we feel it's best.
• making it lenient in a future patch is okay

Only local namespace name is supported like "Modul" on huwiki. Please allow canonical namespace name too, like "Module".

In T120794#9511173, @Bean49 wrote:

Only local namespace name is supported like "Modul" on huwiki. Please allow canonical namespace name too, like "Module".

Could you provide an example URL?

Oh, this one?

https://hu.wikipedia.org/wiki/Modul:Adjacent_stations/LIRR?redirect=no

Caused by

if ( $content->equals( $this->makeRedirectContent( $title ) ) ) {

which require an exact match.

In T120794#9511825, @Winston_Sung wrote:

Oh, this one?

https://hu.wikipedia.org/wiki/Modul:Adjacent_stations/LIRR?redirect=no

Yes. Should I create a new task?

In T120794#9511906, @Bean49 wrote:

Yes. Should I create a new task?

Yeah. File a Software Feature task.

https://phabricator.wikimedia.org/maniphest/task/edit/form/102/

It seems to me a superior solution would just be to use the existing wikitext redirects (necessitating a change in the content model upon rename/moves) and have Scribunto fetch the targets of such things before it #invokes, requires, etc.

Of course there is still the issue to potentially moving across namespaces but I am sure that could be restricted somehow.