Wikipedia talk:Lua

Archives (Index)

1 2 3 4 5 6 7 8 9 10 11 12

This page is archived by ClueBot III.

Module:Fake object

If you ever find yourself doing testing with title objects, you might be interested in Module:Fake object. It puts a metatable wrapper round another object and allows you to overwrite its fields without generating errors. I'm using it in Module:Protection banner/testcases, where it is saving me from having to find actual pages with the namespaces and protection levels I need, and from having to fix the test cases when someone changes a protection level somewhere. Also, if anyone can see any ways to improve it, suggestions would be very welcome. — Mr. Stradivarius ^{♪ talk ♪} 02:57, 17 July 2014 (UTC)

@Mr. Stradivarius: What does that module let you do that rawset doesn't? Jackmcbarn (talk) 03:01, 17 July 2014 (UTC)

Now that's a good question. I can't think of anything - it looks like I just wrote that module for nothing. And if you use rawset, methods using a check self function still work. Well, it was good practice at writing metamethods, at least... — Mr. Stradivarius ^{♪ talk ♪} 03:08, 17 July 2014 (UTC)

I've gone ahead and deleted the module, as rawset seems to be generally superior. — Mr. Stradivarius ^{♪ talk ♪} 23:40, 18 July 2014 (UTC)

mw.log output is now visible

A change was deployed a few hours ago that makes mw.log output from pages visible. It will now show up in the parser profiling data when previewing. To see a useful example of this, look at the log output of one of the pages in Category:Location maps with possible errors - it will contain details about the problem that caused the page to be placed in the tracking category. Jackmcbarn (talk) 01:18, 18 July 2014 (UTC)

That's very useful, thanks. Johnuniq (talk) 01:34, 18 July 2014 (UTC)

I tried this; it is indeed useful. (For the uninitiated, you don't actually need to enable scripts to use this, but you do have to preview the page with the error on it) Though tracking and fixing these errors is still no picnic... Wnt (talk) 19:43, 18 July 2014 (UTC)

mw.math library error checking

Would anyone mind taking a look at gerrit:143678? We're in the process of adding a mw.math library to Scribunto to fill in the gaps from Lua's standard math library, but Jackmcbarn and I are disagreeing over whether to add type checking or not. The argument for type checking is that it will make debugging easier and that the other Scribunto libraries do it; and the argument against is that type checking would make it impossible to use mw.math to do advanced things involving metatables, etc. I don't want this disagreement to hold up the deployment of mw.math altogether, so some outside opinions would be very welcome. You can comment here if you want, or you can comment over at Gerrit if you make yourself a Wikitech account. We also need more reviewers in general, so feel free to look at the other submissions in the open changes queue. — Mr. Stradivarius ^{♪ talk ♪} 06:22, 19 July 2014 (UTC)

I haven't looked at this nearly hard enough to settle anything, but just thinking out loud: I see there's a suggestion to require at least one argument, but the unit tests list ideas like sum() = 0, product() = 1. I think there's some merit to having convenient behavior for the empty set, especially if it can be passed in as a table. Question: is there going to be a conflict if you're using custom numbers (tables with metatables) and you also accept that a table as the first argument indicates that the fields of the table are the arguments? I'm thinking that you could differentiate between the two if you check whether a metatable exists in that case, but it seems a bit odd. Wnt (talk) 11:58, 19 July 2014 (UTC)

Indeed, that is an issue. As the code is written now, the solution is that if you use tables-with-metatables-as-numbers, then you have to use the table form of the function call as well. Jackmcbarn (talk) 14:50, 19 July 2014 (UTC)

Hmmmm... personally I'm not a great fan of almost-but-not-quite synonyms. If there's not a way to make a(x,y,z) precisely equal to a{x,y,z}, would it be better just to have the second way? Wnt (talk) 20:43, 19 July 2014 (UTC)

That was my original idea. Jackmcbarn (talk) 02:14, 20 July 2014 (UTC)

FYI, the general pattern for a{x,y,z} = a(x,y,z) is:

function a(x, y, z)
  if type(x) == "table" then
    x, y, z = unpack(x)
  end
end

--darklama 15:15, 25 July 2014 (UTC)

That's a nice trick, but I think the idea behind passing a table was to avoid the overhead of unpacking a table (on the assumption that the caller already had the numbers to be summed in a table). My opinion is that library functions should behave like Lua does, and a{x,y,z} means a({x,y,z}), so the table should not be unpacked as if that were standard behavior. If that were wanted, have a separate function to sum values in a table. Johnuniq (talk) 00:37, 26 July 2014 (UTC)

Let's get rid of the Lua/todo page

About Wikipedia:Lua/To do. It has little activity. And rightly so: we at wikipedia do not list one another jobs 'to do'. There is very little activity since its creation on November 2013. Also, and relevant to wiki, there is the danger of mis-communication: editors talking on page A, while on page B the same issue proceeds. (Links may be preserved).

For these two reasons, I propose to delete: Wikipedia:Lua/To do. -DePiep (talk) 01:40, 23 July 2014 (UTC)

I suppose as its creator I would say this, but I think it has a useful role to play in identifying templates that need to be converted. I admit that it hasn't had a very high level of activity, but that doesn't mean that it isn't serving its purpose. I've removed a couple of stale entries, but the others are all tasks that still need doing. — Mr. Stradivarius ^{♪ talk ♪} 03:04, 23 July 2014 (UTC)

After WT:Lua and WP:Lua/Request this is a third (fourth, ...) coordiantion place. That means sooner of later, but surely, information & communications will be lost. A Todo list could be in top of the Lua talkpage? -DePiep (talk) 19:42, 16 August 2014 (UTC)

How to use template parameter names as Lua variables.

For example, in a template: {{#invoke:Sandbox|function|{{{1|}}}|{{{2|}}}|...|{{{42|}}}|...}}, I need to define each template parameters one by one. Is there any way I just need to define template as "{{#invoke:Sandbox|function|{{{1}}}}}}", input "a|b|..." just as a normal template, then Lua recognize "1=" "2=" ... also as variables?--JamesQQ5 (talk) 06:07, 7 August 2014 (UTC)

Yes, that's easy.

local pframe = frame:getParent()
local config = frame.args  -- arguments from the template definition
local args = pframe.args   -- arguments from the page calling the template

If a page contains {{example|abc|def}} and Template:Example contains {{#invoke:example|main|hello}}, and after the above code, config[1] is 'hello' and args[1] is 'abc' while args[2] is 'def'. Johnuniq (talk) 06:27, 7 August 2014 (UTC)

Wow, I successed as you said, thanks for your help!--JamesQQ5 (talk) 16:08, 7 August 2014 (UTC)

Detect call context

Sorry if already answered or way too obvious. Are there ways and what is the best (if there are) to detect the call context?

Say for Module:B with function doB() to detect if it is

• called sraight from a wiki-page like {{#invoke:B|doB}}
• called from a template like {{doB}} from where {{#invoke:B|doB}}
• called from Template:doB specifically and not from any other template
• called from another module using require() in that module
• called from Module:A using require() in that module and not from any other module

If possible at all I am not expecting all answers, a common general hint would be great as well. --NeoLexx (talk) 14:45, 21 August 2014 (UTC)

@Neolexx: That question sort of reminds me of the X-Y problem. What are you doing that needs to know the call context? The one use case I can think of is to allow arguments to be passed in different ways, but using Module:Arguments is a much better solution for that than attempting to write context-sensitive functions. Jackmcbarn (talk) 21:09, 21 August 2014 (UTC)

Neolexx: I think for some of these things you can just use : local parent = frame:getParent(frame)

And then get the parent's name as a string using : parent:getTitle()

For other cases (such as if the module is being invoked from a template which is within an article page, and you want to know the article page), you'd need to get the 'grandparent', which doesn't seem to work. If I try the following code, 'parent' and 'grandparent' are always the same no matter the circumstances: local parent = frame:getParent(frame) local grandparent = frame:getParent(parent)

But maybe I'm doing something wrong. Hopefully one of the more experienced editors can show us how to get the grandparent. BigGreenCahuna (talk) 22:43, 21 August 2014 (UTC)

You currently can't get the grandparent. Jackmcbarn (talk) 23:12, 21 August 2014 (UTC)

Is there any other way to get the page that's using the template which is invoking a module? I can think of a lot of uses for this, such as allowing the template to automagically add some customization based on the page, without the need to tediously add a new argument on every single page that already uses the template. BigGreenCahuna (talk) 23:20, 21 August 2014 (UTC)

You can get the "root" page with mw.title.getCurrentTitle(), but if you have A -> Template:B -> Template:C -> Template:D -> Module:E, you'll get A. There's no way to get Template:B or Template:C. Jackmcbarn (talk) 23:51, 21 August 2014 (UTC)

• Thank you all for answering, and it may indeed help to explain my reasons. It is helpful(?) to keep an OP-like paradigm with small modules to do one exact task each but doing it right - rather than having all-in-one. And then depending on the task to collect needed sets by require() chains. The problem is that even small fully internal (by its purpose) module might be seem useful for someone's purpose as it is: straight from the page or from its own template. And things gets sometimes populated very quickly on wiki. So a month later one adjusts that module and suddently crashes thousands of pages around (s)he had no idea about. There are real cases I would like to not enumerate right now.

So instead of different spooky DON'T USE DIRECTLY or ONLY WITHIN... on the module page I was thinking of some more programmatical way of doing things. Like in Javascript we don't write PLEASE DO NOT CALL THIS CONSTRUCTOR AS A FUNCTION, there is this for this. Similarly I was thinking to distinguish a correct call context (from a given template or from a given parent module) from an incorrect one (straight from the page or as a stay-alone module). --NeoLexx (talk) 09:54, 22 August 2014 (UTC)

Doing that would be a bad idea. If you only want code to get called from one particular module, put the code in that module as a local function. Don't put it elsewhere and then try to detect what the caller is. Don't let "good" OOP trick you into writing bad code. Jackmcbarn (talk) 15:27, 22 August 2014 (UTC)

We may have very different ideas about "good" and good programming patterns. But I do respect your opinion and thank you for answering. --NeoLexx (talk) 09:00, 23 August 2014 (UTC)

Although it won't prevent someone from using your helper modules if they choose to ignore your documentation, you can make them subpages of your main module. This way you can document your main module as providing the external interface to templates or other modules, and all subpages below being conceptually private. isaacl (talk) 22:16, 1 September 2014 (UTC)

HtmlBuilder

See #mw.html library nil behaviour. Many modules still use the HtmlBuilder instead of the mw.html library. Once they are converted on this wiki, many other projects will benefit from them. --Ricordisamoa 06:05, 1 September 2014 (UTC)

Bug in mw.language.fetchLanguageName()?

Module:Citation/CS1 supports ISO639-1 language codes in its |language= parameter. It currently does this with a table of codes and names that is in Module:Citation/CS1/Configuration. Earlier this year I did a quick experiment with mw.language.fetchLanguageName() that showed me that it might be possible to replace the translation table with calls mw.language.fetchLanguageName()

Just getting around to more complete experiments. It appears that mw.language.fetchLanguageName() is producing incorrect results for the ISO639-1 code for the Norwegian language, no. This simple citation uses the sandbox version of Module:Citation/CS1 (should produce Norwegian):

{{cite book/new |title=Norwegian |language=no}}

Norwegian (in Norwegian). – see code no

ISO639-1 code km should produce Central Khmer

{{cite book/new |title=Central Khmer |language=km}}

Central Khmer (in Khmer). – see code km

ISO639-1 code to should produce Tonga (Tonga Island)

{{cite book/new |title=Tonga (Tonga Island) |language=to}}

Tonga (Tonga Island) (in Tongan). – see code to

I presume, not having read the standard, that when there is more than one approved language name for a specific code, the first listed name would be the preferred name. There are several codes where this is the case: dv, ii, ki, kl, and os.

How to get this fixed?

—Trappist the monk (talk) 23:45, 1 September 2014 (UTC)

@Trappist the monk: To clarify, exactly what parameters are you passing to mw.language.fetchLanguageName()? Are you passing 'no' as the first one and omitting the second one? Also, exactly what output do you expect, and what output do you get? Jackmcbarn (talk) 00:08, 2 September 2014 (UTC)

local name = mw.language.fetchLanguageName( Language:lower(), "en" );

where Language is the value assigned to CS1 parameter |language=. So, in this case |language=no

When the citation is rendered, it should contain (in Norwegian).

Norwegian (in Norwegian). – current live (correct) version of the CS1 module using the table in Module:Citation/CS1/Configuration

Norwegian (in Norwegian). – sandbox (wrong) version of CS1 using mw.language.fetchLanguageName()

Norwegian (in Norwegian Bokmål). – sandbox with code nb produces correct response

I think that I expect each of the two-character ISO639-1 codes to produce the preferred (first listed?) language name according to the Library of Congress.

Related? {{#language:no|en}} produces Norwegian which is the same wrong language name produced in the Norwegian language test above, and {{#language:km|en}} produces Khmer and {{#language:to|en}} produces Tongan, also both wrong according to LOC. More evidence that these issues are related: {{#language:nb|en}} produces Norwegian Bokmål which is correct and the same as the mw.language.fetchLanguageName() result above.

Have I answered your questions?

—Trappist the monk (talk) 00:56, 2 September 2014 (UTC)

@Trappist the monk: Almost. You're saying that mw.language.fetchLanguageName( 'no', 'en' ) produces Norwegian (bokmål). Do you want it to produce Norwegian or Norwegian Bokmål? Jackmcbarn (talk) 01:03, 2 September 2014 (UTC)

Yes, I am saying that mw.language.fetchLanguageName( 'no', 'en' ) produces Norwegian (bokmål) and I am saying that it is the wrong language name for code no. The correct language name and the one that I'm looking for is Norwegian because that is the language name associated with no in the list of codes at the Library of Congress website.

I am most concerned with no because it is most clearly wrong but it would be nice, barring any reasons unknown to me, if we could make sure that for all of the ISO639-1 two-character codes, mw.language.fetchLanguageName() (and {{#language:}} for that matter) returns the preferred name.

More clear?

—Trappist the monk (talk) 01:25, 2 September 2014 (UTC)

@Trappist the monk: I've figured it out. mw:Extension:CLDR has a specific override in place for that language, which you can see at [1]. It was added by Siebrand in mw:Special:Code/MediaWiki/31280. Jackmcbarn (talk) 01:37, 2 September 2014 (UTC)

Thanks for that. I'll drop a line to Siebrand.

—Trappist the monk (talk) 10:05, 2 September 2014 (UTC)

I guess it's not relevant here, but searching List of Wikipedias for "Norwegian" shows "Norwegian (Bokmål)" for nowiki and "Norwegian (Nynorsk)" for nnwiki (see Norwegian Wikipedia), so adding "(Bokmål)" is done in other places. Johnuniq (talk) 04:33, 2 September 2014 (UTC)

List of Wikipedias doesn't use mw.language.fetchLanguageName() or {{#language:}}. There are three Norwegian language ISO639-1 codes: no, nb, and nn. no is the 'non-specific' or generic code that includes both nb and nn. mw.language.fetchLanguageName() produces correct results when nb and nn are specified:

Norwegian Bokmål (in Norwegian Bokmål).

Norwegian Nynorsk (in Norwegian Nynorsk).

—Trappist the monk (talk) 10:05, 2 September 2014 (UTC)

Sure, but the point I was making is that for whatever reason, "Norwegian (Bokmål)" is associated with "no" in more places than mw.language. Another example is Wikidata which uses nowiki as can be seen at d:Q14033926. Johnuniq (talk) 10:53, 2 September 2014 (UTC)

Understood. I don't know how that wikidata page got its language name but its form (norsk bokmål) is different from either {{#language:no|en}} → Norwegian or {{#language:nb|en}} → Norwegian Bokmål which implies that it was not taken from mw:Extension:CLDR.

—Trappist the monk (talk) 11:37, 2 September 2014 (UTC)

@Trappist the monk: That would be from {{#language:no}} (or the basically-equivalent {{#language:no|no}}), which yields norsk. Wikidata displays languages in themselves. Jackmcbarn (talk) 12:39, 2 September 2014 (UTC)

It occurred to me to wonder in my message to Siebrand how no, nb, and nn are handled when Dutch (nl) is the specified output language:

• {{#language:no|nl}} → Noors
• {{#language:nb|nl}} → Noors - Bokmål
• {{#language:nn|nl}} → Noors - Nynorsk

You can see that we get the correct results. It's the same if you do the experiment specifying other common language codes for the output language, for example de, es, fr, it, ru, and even yi all produce output equivalent to Norwegian, Norwegian Bokmål and Norwegian Nynorsk. This is the limit of my current experimentation but it seems that output for no with output language specified as code en and code no are wrong, or at the least completely inconsistent with output for other output language specifiers.

—Trappist the monk (talk) 14:41, 2 September 2014 (UTC)

While the language codes used by methods such as mw.language.fetchLanguageName() are similar to IETF language tags (which draw from ISO 639 codes, among other sources), not all MediaWiki language codes are valid IETF tags or vice versa. See mw:Extension:Scribunto/Lua reference manual#Language library for more. Anomie⚔ 11:50, 2 September 2014 (UTC)

From this:

language codes: "...(mostly in accordance with ISO 639-3, except two-letter codes from ISO 639-1 for "established" locales)..."

can I infer that the two-letter language code no should be in compliance with ISO639-1? See code no.

RFC 5646, interestingly enough, specifically mentions no, nb, and nn as Norwegian, Norwegian Bokmal, and Norwegian Nynorsk respectively. From IANA language subtag registry (oft mentioned in RFC 5646) this for code no:

%%

Type: language

Subtag: no

Description: Norwegian

Added: 2005-10-16

Suppress-Script: Latn

Scope: macrolanguage

%%

All of this suggests to me that mw.language.fetchLanguageName() and {{#language:}} should not be returning Norwegian (Bokmål), Norwegian Bokmål, or norsk bokmål when the input is specified as code no regardless of output language code.

Am I missing something?

—Trappist the monk (talk) 14:41, 2 September 2014 (UTC)

Hmm. I see someone added "except two-letter codes from ISO 639-1 for 'established' locales" since last I read through that, which totally changes the meaning of the sentence. At any rate, the issue here is that the English name for MediaWiki language code "no" is currently "Norwegian (bokmål)", and if that should be changed to match ISO 639-1 then it needs to be changed in mw:Extension:CLDR. Anomie⚔ 23:20, 2 September 2014 (UTC)

Right. So how do we get that done?

—Trappist the monk (talk) 10:50, 3 September 2014 (UTC)

Well, you said you already tried talking to Siebrand. Next step would be to file a bug, and even submit a patch if you can. Anomie⚔ 12:56, 3 September 2014 (UTC)

It's been over a week and no response from Siebrand. Alas, I value my privacy so I'll not be filing any bug reports until bugzilla joins the 21st century. Wikipedia is already too much of a timesink and I fear that if I start making patches it will only become worse.

For the time being, I can craft a workaround in Module:Citation/CS1 so that rendered citations display the correct language name when |language=no

—Trappist the monk (talk) 14:05, 10 September 2014 (UTC)

As a Norwegian I can elaborate on this. One problem is that 'Norwegian' ('no') is not a written language, it's only referring to "some variant of Norwegian; either Norwegian Bokmål (nb) or Norwegian Nynorsk (nn)". Historically 'no' has been used for Bokmål, while 'nn' has always been used for Nynorsk, so even today one can generally assume that 'no' means 'Norwegian Bokmål'. But following ISO 639-1 strictly one should not, so the situation is a bit messy. The best solution is generally to deprecate 'no' where possible. We're unfortunately stuck with the 'no' prefix at no.wikipedia.org, but we use 'nb' as our content language. 'no' has also been removed from translatewiki. – Danmichaelo (talk) 20:12, 14 September 2014 (UTC)

Function names containing equals signs

In WT:Lua/Archive 2#Metatables will now work on export tables, Wnt pointed out that a function name containing an equals sign would cause later arguments to be misnumbered. I've submitted gerrit:158890 to fix this problem, which is now merged. Beginning September 18th, we'll have the ability to use the function name as a "free" parameter that users can use without worrying about escaping equals signs in it, which isn't currently doable in any other way. Jackmcbarn (talk) 19:46, 6 September 2014 (UTC)

I don't like the sound of that "'free' parameter" idea. That sounds like it'll be confusing. Anomie⚔ 00:47, 9 September 2014 (UTC)

Why not just forbid the equal sign in function names? Chillum 00:52, 9 September 2014 (UTC)

It has its uses, even if it's confusing. (Just like half of the parser's other obscure features, like msgnw and the reverse pipe trick, to name a few). Also, it's exactly the same as any other positional parameter now, just like all other parser functions (except #switch, sort of) take. Jackmcbarn (talk) 00:56, 9 September 2014 (UTC)

Proposal to disable "Allow saving code with errors"

The "Allow saving code with errors" lets users save code even if it contains a syntax error that would prevent it from working anywhere. The reason that this feature was added was to let users of some wiki (not sure which) more easily save work-in-progress code. I've never had to use this checkbox, and as far as I know, no other Lua scripter here has either. Every time I've seen it used here, it was someone who didn't understand Lua screwing something up. Since it's easy enough to save WIP code by simply commenting it out, I propose that we disable that checkbox here. Are there any objections? Jackmcbarn (talk) 21:12, 8 September 2014 (UTC)

Yes I object. Didn't even know it existed, but I could have used it many times, e.g., when I wanted to save the page for the night, & more tomorrow. If commenting out for a single line would solve it, that would be great but that is not to be expected. Are there any damages known from saving bad code modules? -DePiep (talk) 20:41, 27 September 2014 (UTC)

Yes, there's damage. Clueless users have a way of finding modules with a good number of transclusions (but not enough to protect) and breaking them. Also, I talked to Tim about this, and he suggested that rather than even make it a config option, to just remove it altogether. (And the fact that you didn't know it existed shows how useful it is to legitimate users.) By the way, if you have multiple lines in progress, putting --[=[ at the beginning of your code and ]=] at the end will make a multiline comment and comment it all out. Jackmcbarn (talk) 20:44, 27 September 2014 (UTC)

(And the fact that you didn't know it existed shows how useful it is to legitimate users.) Bull shit. It caused me damage. And for logic, I wouldn't trust you programming for me.

Who's Tim? Anyway, if Holy Tim says so, why did you ask it here in the first place? You already decided the outcome. -DePiep (talk) 20:52, 27 September 2014 (UTC)

Tim is Tim Starling. I asked here in the first place because my original idea was to make having the checkbox be a config option, which we'd turn off here, but if we remove it altogether from the software, then it's not a config change anymore and doesn't need local consensus anymore. Also, I fail to see how a feature that you didn't know about, and only does anything if you know about it, caused damage to you, and why the fact that something caused damage to you is a reason to keep it. Jackmcbarn (talk) 21:50, 27 September 2014 (UTC)

While serious coders should not generally check the box, removing it wouldn't prevent anyone from damaging modules by causing a runtime error. --Ricordisamoa 03:32, 17 October 2014 (UTC)

Detecting when the edit link goes to a redirect page

would it be possible to track this problem? either through checking to see if 'name' matches the template name, or by checking to see if the value of 'name' is a redirect page. I am guessing that the first one isn't possible, since it requires going to a grand child ('module:navbox' → 'template:navbox' → 'template:international volleyball')? and, that checking to see if 'the value used for name is a redirect' is expensive? Frietjes (talk) 13:56, 9 October 2014 (UTC)

The proper fix for that problem is to make navbox templates call Module:Navbox directly, since the name parameter is unnecessary when doing so. Jackmcbarn (talk) 14:33, 9 October 2014 (UTC)

(edit conflict) @Frietjes: Your first option isn't possible with the current way the templates are set up, as Scribunto can't access grandparent frames. (Note that in Lua-speak Module:Navbox is the grandchild and Template:International volleyball is the grandparent.) So we can tell that we are being called by Template:Navbox, but we can't go any higher than that. However, you could do it if you used {{#invoke:Navbox|main|...}} directly on Template:International volleyball, as then it would be the parent, not the grandparent. In fact, if you did that you could just get rid of the name parameter altogether, as Lua would always return the correct name. Your second option is also possible, and you're right that it is expensive. You need to make a title object for that page and then the isRedirect property of the title object will tell you whether or not it's a redirect (see the manual here). It's the making of the title object that is the expensive part, so you can call mw.title.new with pcall if you have to avoid script errors (probably a good idea on Module:Navbox). — Mr. Stradivarius ^{♪ talk ♪} 14:43, 9 October 2014 (UTC)

Cleaning up Category:Pages with script errors

I found myself browsing Category:Pages with script errors earlier today, and I noticed it was full of sandboxes and talk archives that are distracting from the pages that really need fixing. However, when I started clearing the category out, Anomie pointed out that I shouldn't just go editing other people's sandboxes. He's probably right. So, how can we find the script errors that need attention without getting distracted by test pages? Off the top of my head, I have two ideas: 1) add a new category for script errors in the main namespace only, and 2) add a category for script errors that filters pages by regex to exclude "/sandbox" and "/Archive n" etc. Do these sound like good suggestions? Or perhaps someone has a better one? — Mr. Stradivarius ^{♪ talk ♪} 15:34, 16 October 2014 (UTC)

I'd say categorize by mainspace. Subpage name patterns are more volatile, and require more maintenance thinking. (WP:FLOW will change any talkspace beyond recognition). Mainspace script errors are the only ones you want to check (cat space, wp space, ...?). -DePiep (talk) 16:05, 16 October 2014 (UTC)

(edit conflict)

I support this. But, it would seem to me that it would be beneficial to construct a category set from the top down. For example:

Category:Lua

Category:Lua errors

Category:Lua errors in namespace

Category:Lua errors in namespace

...

Category:Lua errors in namespace

Category:Lua ...

And no Category:Pages with ... titles. We all know that categories contain pages, files, and other categories. It seems pointless to me to state that in the category title. Yeah, personal peeve.

I'm not sure that I see much need categorize errors the User namespace, or in /sandbox, /testcases, and /archive subpages. Perhaps none of the various talk namespaces should be categorized either. Probably no need to categorize pages in Module:Sandbox.

—Trappist the monk (talk) 16:29, 16 October 2014 (UTC)

I haven't been paying attention—what magic is putting pages in the category? I agree with Trappist's remarks about there being no need for "Pages with" and no need to have a sandboxes et al in a tracking category. I frequently patrol Category:Convert error categories and it's much better now that the convert module only outputs a tracking category for articles—there were too many false alarms even on template pages. Johnuniq (talk) 00:37, 17 October 2014 (UTC)

I wouldn't like to see this category split up. I especially find it useful to see errors in sandboxes, talk pages, etc., as that allows me to spot errors in modules before they become a big problem. Note that it's already possible to filter by namespace if you want. For example, [2] will show you just articles that have errors. Also, to help clean out the category, I often look at [3] which shows me the newest errors first. Jackmcbarn (talk) 03:23, 17 October 2014 (UTC)