In T68051#3041085, @Multichill wrote:

What you're saying is that we should only display Wikimedia Commons in English.

IMO, it was a bad idea for {{int:}} to ever work on user language instead of on content/page/site language. I don't think we should extend that mistake.

I understand what @Rical is saying. @Anomie is right that MediaWiki already does everything it has to for it to be feasible. All of the rest of the work has to be done on JEdit's side, and as such, this isn't our issue.

In T154769#2928736, @Rical wrote:

But I continue to ask the same description for all runtime errors in modules : module name, line, function and details.

That already all exists. You get it when an error makes it back to the console or wikitext without (x)pcall catching it.

@Rical A cursory look at that module reveals that you're using "select" as a variable name in it. That's a bad idea, since it's the name of a built-in global function. It wouldn't surprise me if that were the root of the problem.

In T154346#2909529, @MZMcBride wrote:

Do you dislike the {{#ifexist:Page name}} ParserFunction parser function?

No, since the output of the parser can't change whether or not a page exists. Basically, I don't like things that could cause paradoxes if called on themselves, or on other pages in a loop. (See also my response to T71441).

I dislike the idea of exposing through the parser any properties that can be set via the parser.

Instead of splitting discussion, if you still think this should happen, please reopen the old issue.

I still don't really like the idea. When is this even useful? (And my point wasn't that it's not possible at all, but that it will necessarily give the wrong answer sometimes.)

Passing the same dataWrapper result more than once would introduce another way that T67258 could happen.

In T146616#2670000, @PerfektesChaos wrote:

The concept of local config modules is understood, as you might see here or here or here.

However, local configs require local people and even sysops to maintain a software configuration theirselves. I know many wiks that are not able to do this with local software experts, asking e.g. German Wikipedia for support. They would have to adapt each new feature locally.

A config scenario might be shared on a larger number of wikis, with exceptions for only a few ones, like e.g. Commons. Then global maintenance of a few standard groups of different profiles provides a more robust behaviour and will share all updates, and adaptions are performed by some global experts. Might be combined and overruled by local config modules anyway.

This seems like a non sequitur. None of this is improved by being able to automatically switch by wiki ID, since the different configurations for different wiki IDs would have to be written anyway (just in a different place). And centralized modules are also totally orthogonal to this.

I tend to agree with Anomie on this. I'm not sure this should be done.

Done. (You do "Merge Duplicates In" from the other task.)

In T137900#2386640, @aaron wrote:

In T137900#2384230, @Legoktm wrote:

We already have a show-only-on-preview warning system through ParserOutput::addWarning() and ParserOutput::getWarnings(), I would be in favor of exposing that via Scribunto/Lua and allowing module authors to take advantage of showing real errors upon preview instead of the current hacks.

These don't have locational context, but I'd agree that they'd be useful for some things. Errors like "invalid param 'foo'" would just mean the user has to cntrl-f for 'foo' to find that parameter.

I'm pretty sure that the lack of locational context would keep enwiki from switching to this.

Hmm, apparently this was intentionally done by @ori in rETBLa05d0abed95481de9009050c0e0a759900708d4a. Adding him for comment.

In T137369#2366324, @BethNaught wrote:

I don't see the utility in having a warning when the page is restricted to autoconfirmed only

In T136515#2337442, @Base wrote:

{{ {{PAGENAME}} }} seems to work. {{ {{PAGENAME}}}} and {{{{PAGENAME}} }} work too.

IMO, the second method here is the right way to do this, and this isn't a bug but rather intentional behavior.

@ssastry I think I fixed this with this edit. Let me know if there's anything else I have to do.

I still don't see anything to do here. Please give a clear, specific description of what functionality you want to be added.

@Rical, you still haven't given a specific example of what you'd like to be done in Scribunto.

Rical, please don't do that.

Closing since T28546, now fixed, was a better solution.

My patchset was merged. I'm not sure why gerritbot didn't post here about it.

I see no reason that this has anything to do with Lua. I think my patch at https://gerrit.wikimedia.org/r/#/c/158098/ is a much better solution.

@Urbanecm Support for that is requested in T120794.

As legoktm said, this happens because it's currently impossible to create a module redirect. Rest assured that this will never allow unauthorized users to access the block or delete buttons. (Also, my personal opinion is that suppressredirect should not be required to move modules, etc.)

CAPTCHA isn't meant to be "Are you sure". It's meant to be "Are you a human". If you want a bigger confirmation step, please ask for something different (like typing the username of the user to nuke again).

Looking at everything that uses $wgSemiprotectedRestrictionLevels, it does look like exactly what we want. Let's do that.

In T131911#2183976, @Legoktm wrote:

In T131911#2183910, @Jackmcbarn wrote:

I really don't like all of these recent ideas to let Lua fetch information about pages that isn't known until the page is parsed.

MZ and I discussed on IRC that we could only allow lookups of *other* pages so you'd never run into the issue of trying to depend on something that is determined in the current parse.

That feels clunky, though, and it doesn't completely fix the problem. If page A referenced page B and page B referenced page A, you'd still get the same issue.

I really don't like all of these recent ideas to let Lua fetch information about pages that isn't known until the page is parsed.

The problem with listing all pages transcluded on a given page is that it can't be accurate on a given page. Imagine if it were, and someone created a template called "IsTranscluded", that returned whether a given template was transcluded on a given page. Then suppose a page called {{#if:{{IsTranscluded|{{FULLPAGENAME}}|Template:Foobar}}||{{Foobar}}}}. Now the result of that will never be accurate.

In core, the formatnum and plural parser functions use it.

All parseFormattedNumber does is call Language::parseFormattedNumber in core, so this isn't Scribunto-related at all.

Can you make it clearer what you're asking for? I'm not sure if you want all pages that transclude a page, or all pages that are transcluded by a page.

No problem, I already have it taken care of.

FYI, I didn't realize that this was taking parsoid-prod.wmflabs.org down until it happened, so a lot of the requests from it were probably from my https://en.wikipedia.org/wiki/WP:EPH script.

This can't be done, since the number of sections in a page isn't known until after parser functions get evaluated. Imagine a page that contained {{#ifeq:{{NUMBEROFSECTIONS:{{FULLPAGENAME}}}}|0|== Section ==}}. This would cause a paradox.

https://en.wikipedia.org/wiki/User:Anomie/linkclassifier.js can add the class "self-redirect" to such links (which can then be styled with CSS), though I agree this would be nice to have in core.

I proposed exposing this information from Lua in https://gerrit.wikimedia.org/r/#/c/188503/ and Tim didn't like it because changes to user groups don't have a practical way to invalidate caches of pages that use the information.

No, for all the same reasons as T6196.

Closing then, as there's nothing to do. It doesn't make sense to make a task a blocking task if there's no work to do for it.

Are there any features that you still need then, or can this be closed? Also, I encourage you to use callParserFunction rather than preprocess.

For relatively-named submodules, do this:

local submodule = require(mw.getCurrentFrame():getTitle() .. '/submodule')

For versioning, either keep a version constant in the code, or use frame:callParserFunction with REVISIONTIMESTAMP. For ISO 8601 dates, call mw.getContentLanguage():formatDate('c', theDate).

I remain unconvinced that the old situation is better than it is now. It shouldn't be that hard to add the ability to filter this data if it's wanted that badly.

EDIT: Anomie beat me to it.

When you performed your undo, you only undid one of two pending changes, so your revision wasn't automatically accepted. (The second pending change was this one.) As a reviewer, you could have accepted it yourself anyway by checking the "Accept this version (includes ## pending change(s))" box before saving, or just like any other pending change after saving. Unless I'm missing something else, there doesn't seem to be anything wrong here.

I don't really see a need to add a built-in for something that it's trivial to write a module for.

In T114200#1688670, @Billinghurst wrote:

please have it able to be set and displayed/filtered with desired namespaces so that communities like the Wikisources can target their needs.

I like this idea a lot. Making it work like Special:WhatLinksHere (for example) is probably the best way to go here.

There's no 500-page limit as far as I can see, and on both en.wikisource and www.wikisource, I wouldn't exactly say it's "flooded" until you start getting into occurrences with only 1 or 2 transclusions. (The one thing I would like to fix is that transclusions of stock messages really shouldn't count.)

In T32282#1668693, @Ricordisamoa wrote:

https://gerrit.wikimedia.org/r/136274 makes file page count, width and height available to wiki pages via the Scribunto extension.

For clarification, that change was merged a while ago, so this is already possible.

I think {{ns:0}} is good enough.