Template talk:Error

Category, anchor and merge

{{FormattingError}} also adds pages with errors to a category, so it is easy to find pages that have formatting errors. It also adds an anchor to the page where the error occurs (#FormattingError). I'd like to put similar functionality for {{Error}} and use {{Error}} in {{FormattingError}}, so the layout and such of both can be modified in one place.     — SkyLined (talk) 08:41, 13 November 2009 (UTC)

I wouldn't mind. I initially created this simply the way we output errors in a centralized place, in case the way the MediaWiki parser function extension ever changes how it evaluates errors. Categorizing them (probably overridable via a {{{categories}}} template) certainly makes sense, although I expect that there'll be lots of false positives at first with various uses on template doc pages.
What do you mean by modifying the layout though? Error tags should be styled in the skin css files, I'd think. Amalthea 11:51, 13 November 2009 (UTC)

Re: false positives: {{FormattingError}} has an optional nocategory=true argument that can be used to prevent the category from being added. Any template that uses it should also implement this argument and pass it on, so that pages that create errors on purpose (such as doc pages) will not end up in a "pages with errors" category.

Re: modifying layout: No matter how they are styled, they should be styled in the same way. Currently, if we should decide to make a change to the layout that requires a change to the HTML, we would have to modifyin both {{Error}} and {{FormattingError}}. If we make {{FormattingError}} into a wrapper for {{Error}}, we would only need to update one template.

    — SkyLined (talk) 16:08, 13 November 2009 (UTC)

I wish this was more widely known

As on occasional writer of templates (and long-time software engineer) I like to make them "fail gracefully" when given bad input. (Of course that's not always possible given the limitations of the template language, but at least one can try rather than produce incomprehensible output.) So this template is really great! But I wish I had known about it before. It seems to me, there are a lot of good templates out there that are very hard to find: a problem with Wikipedia generally actually; one tends to be able to find something if one knows what one is looking for, which rather defeats the point.

So, thanks for this, now I know it exists I will use it! (And I know any reply would probably start "er, it's called error, it's pretty obvious", but that's not the problem which is not "what does {{error}} do?" but "what do I do to produce error output?"). Si Trew (talk) 10:33, 29 June 2010 (UTC)

I know what you mean. I wrote this template to try and generalize all errors. As afar as I can tell not too many others have started using it, unfortunately. Another similar problem is that I frequently stumble upon multiple templates that do essentially the same thing.

I think the best way to solve this, would be to have an up-to-date list of templates by category that includes name and a short description. I do not believe it will be easy to find somebody to create it and I think it will be even harder to maintain.

One contributing factor to this wild growth of templates is that people copy templates from other languages and translate the names in various ways. So, you could end up with multiple copies of the same template (for example: "sizeof_string", "string_size", "char_count" and "string_length").

Anyway, glad you like it :D     — SkyLined (talk) 14:07, 29 June 2010 (UTC)

Yeah, it's not so much a question of my saying "how do I get it in red and so on", like I can do ... and all that, but I always have this feeling that somewhere, probably more than once, someone must have done this already, leading either to searching (usually with futility) a load of existing templates that appear to do something similar but are not coded to be reused. And the search does just seem inadequate at finding these things.

For example, I've just created {{Ety}} which wants to output a list of stuff, like "Tom, Dick and Harry". Surely somewhere there is a kinda {{englist}} or something that will separate its parameters with commas or " and "? Not that I can find. So I end up writing {{Ety/List}} in the full knowledge I am reinventing the wheel. I had a similar feeling with {{Cardinal to word}} and its brethren.

I think it would be much improved if there were a Good Template Review kinda process that asked questions: is it documented? does it do what it says it does? Does it fail gracefully on bad input? (Not many do.) And so on. That way, the kinda "library" you envisaged could at least be started on with kinda "templates we like and trust". A lot seen to have been put together by people who know how to write templates but don't bother to document them, so that they end up almost impossible to reuse (there's a greater tendency to make breaking changes, too). Si Trew (talk) 14:59, 29 June 2010 (UTC)

FWIW, I always categorize my meta templates in Category:Wikipedia metatemplates or below, which has a number of interesting templates. But the categorization could sure be improved, it's still quite a mishmash to keep {{ROOTPAGENAME}}, {{Navbox}}, and {{Television in Europe templates}} in the same category. :\
Amalthea 16:04, 29 June 2010 (UTC)

I don't really know what you mean by a metatemplate. If you mean just a template that is used by other templates, I don't know that that is always appropriate. I can see that "Television in Europe templates" is, indeed, a metatemplate in that it a template that describes templates, but Navbox seems more a "base class" and ROOTPAGENAME well, who knows? Just seems like a normal template to me. Si Trew (talk) 16:30, 29 June 2010 (UTC)

Converted a few of mine

You might be pleased to hear I've converted the error output in {{Time of day in words}} and {{Number to word}} (and their various subtemplates) to use this. It's a start. Si Trew (talk) 13:23, 1 July 2010 (UTC)

How to do a "not-strong"?

Could the /doc describe how to get a not-strong output? -DePiep (talk) 20:13, 1 September 2010 (UTC)

It does. Amalthea 20:21, 1 September 2010 (UTC)

No it does not. It does show that tag=p, div, span gives a not-strong output (in my browser). But these are a different thing. They do not define "strong/not-strong". And anyway, showing is not describing, which was my question. -DePiep (talk) 20:33, 1 September 2010 (UTC)

You need to wrap it in one of those tags, otherwise it is not going to be recognized as a parser function error. Wrap it in a span and you get, for all intents and purposes, a "non-strong" text. Amalthea 20:49, 1 September 2010 (UTC)

Is what I put in the /doc now. Not everyone familiar with CSS is familiar with error-handling, and more so. I hope to have helped these. -DePiep (talk) 21:24, 1 September 2010 (UTC)

Template:FormattingError

{{FormattingError}} is a similar template that I created to allow other templates to report errors. This template also adds the page to Category:Pages with incorrect formatting templates use, so editors that want to make sure there are no errors on any pages can easily find those pages that have errors. Secondly, it adds id="FormattingError" to the tag it creates for the error message, which means you can scroll down to the first error on a page easily by adding "#FormattingError" to the url of the page. It may be useful to compare both templates and copy useful features from one to the other. It might even be possible to have one use the other to display errors, or even merge them into one template. Unfortunately, I haven't as much time as I used to, so unless somebody else can have a look, this message serves as a "note to self" in case I ever find myself less busy with other things.     — SkyLined (talk) 14:51, 2 September 2010 (UTC)

Error message style (guidelines) available?

Are there guidelines, styles or good examples for the message-text? Friendly, clear & to the point altogether, shouldn't we provide a link to a help- or /doc page. . -DePiep (talk) 08:26, 7 September 2010 (UTC)

Some tests

I have edited Module:Error/testcases [1] and Template:Error/sandbox [2]. If these edits are not helpful, feel free to revert. My self comments:

• Adding |tag={{{tag}}} to the /sandbox looks obvious, since we want to pass that parameter.
• /sandbox: Merging params into {{{message|{{{1}}}}}} in the /sandbox is done to copy the behaviour of the existing template. Since handling spaces and priorities in parameter handling will remain, we would like to copy that behaviour, whatever the implications for Module. Now it looks like the template {{Error/sandbox}} passes all its template-space {{Error/testcases}} (which is just a limited set).
• In Module:Error/testcases, I have added more tests (and grouped them). Also, all current tests are repeated for {{Error/sandbox}} because there seems to be an effect between UnitTest and /sandbox mode. UnitTest failed:
• input "0" and "false" (probably the t/f logic is tricked) No, my typo in the testcases ;-) -DePiep (talk) 13:37, 4 April 2013 (UTC)
• Input like {{Error}} (that is, no param1 at all) produces testcases: {{{1}}} (vs.) Script error. I guess this is because of the added check: or error('no message specified', 2) in the module. The old template does not have this check. If this is not for debugging, that one could go? It should return {{{1}}} I'd say. (See also the nowiki return texts: class "scribunto-error" was added).

Adding: This could imply that there is only message = arg[1] to consider (plus a nil-check on that), since the message will only enter through param1. Template param Message is not the same asmodule param message. -DePiep (talk) 13:37, 4 April 2013 (UTC)

More fails I did not see. Hope I did help. -DePiep (talk) 13:27, 4 April 2013 (UTC)

Some addings. -DePiep (talk) 13:37, 4 April 2013 (UTC)

Thanks for your help here. The script errors in the module unit tests are fine, as the template will not trigger them (it will either show {{{1}}} or whitespace, depending on whether 1 is specified). They might be helpful for other modules that use this module, though, so I'm going to avoid actually programming in {{{1}}} to the module code. :) It seemed like everything else was working, so I've updated the template. — Mr. Stradivarius ^{♪ talk ♪} 13:54, 4 April 2013 (UTC)

The error text stays hidden (instead, another error text is shown. ~btw, are errors listed (categorised) somewhere? -DePiep (talk) 14:57, 4 April 2013 (UTC)

Note: again, the module still checks for these two arguments: message = args.message or args[1] ... while only one (unnamed param 1) exists. At the moment, there is no named parameter "message", so the module should not check for that one. -DePiep (talk) 14:02, 4 April 2013 (UTC)

Hmm, good point. Now that we've changed the invocation from Template:Error the message parameter isn't needed any more. I don't think having it there causes any harm though. Errors aren't tracked anywhere, no. Traditionally templates that want to track errors will include a tracking category straight after the {{error}} invocation, and the {{error}} template itself doesn't have anything to do with it. — Mr. Stradivarius ^{♪ talk ♪} 15:18, 4 April 2013 (UTC)

I must say, when called from another module (not from a template) both options could be available as a feature (so that module has both options "module=" or "arg[1]=" open to use). Documentation should be clear on this. I don't know if such a feature is good programming basics. But "no harm" is not a good reason to keep idle code.

About the internal error: then what is that code doing there? The text is invisible (hidden behind "Script error" error), it is a change from old template behaviour (because that one did not produce an internal error), and it changes possible current usage depending on the "{{{1}}}" showing. I do agree coding that return text is undesired; at least is could be a blank.

As a minor point: why not move the "message = nil" setting to the _error function, together with its next arg logic? -DePiep (talk) 20:37, 4 April 2013 (UTC)

Since I cannot prove my point in the sandboxes, I rest my case. -DePiep (talk) 21:07, 4 April 2013 (UTC)

I pity the foo...

Foo might not be the best example for an unrecognized word in the usage section. 50.64.119.38 (talk) 19:52, 20 September 2017 (UTC)

There are only a few words that are recognized in mathematical expressions. See mw:Help:Extension:ParserFunctions##expr. The recognized words are:

not ceil trunc floor abs exp ln sin cos tan acos asin atan div mod round and or

– wbm1058 (talk) 22:02, 20 September 2017 (UTC)

Just trying to be helpful. But wouldn't a near miss better match a real life error. (ie. flor, ciel, rounb, etc.) 50.64.119.38 (talk) 22:36, 20 September 2017 (UTC) As an aside, it doesn't recognize hyperbola functions? sinh,