Page MenuHomePhabricator

Trigger category from Lua code or as parser function
Closed, DuplicatePublicFeature

Description

Problem

Consider:

  • {{#expr: 3.1416 * {{#invoke:Math|compute|{{{d}}}}}}}
  • {{#if: {{#invoke:Wikidata|retrieve|{{{p}}}}} | ...}}

If there is any error with those parameters {{{d}}} or {{{p}}}, there is no way to complain via error message nor maintenance category.

  • The one and only hack is to transclude or query for a (perhaps not existing) page and trace back Whatlinkshere for such page. This is no reasonable approach in eternity.
  • I want
    • Category:Maintenance, compute@Module:Math, invalid number
    • Category:Maintenance, retrieve@Module:Wikidata, bad property

Those are visible for editors at least if hidden categories are shown, trigger warnings by evaluating PAGESINCATEGORY, and category description may explain causes and remedies. In list of maintenance categories I am told which are not empty.

Solutions

Lua library

Something like

mw.category( title [, sortkey] )

may be introduced.

  • Lua modules could trigger such category.
  • By wrapping such auxilary module a template could categorize as well.

Parser function

Introduce

{{#category:title|optional sortkey}}

That may be used within templates.

  • Lua modules can issue any parser function within frame.

The name of the parser function can be localized easily by re-using the well known 14 namespace names.

  • No clash with other function name is expected.
  • Localized function names have high acceptance among authors.

This approach offers the solution of a two decades old mystery:

  • There are internal links like [[Category:Things]] but they vanish in rendered text and there are strange hints to insert a : somewhere for a clickable link towards description page.
  • By slow migration towards parser function within a decade, inserting when touched by VisualEditor, and whereever source code is generated or manipulated by software, common understanding of wikisyntax may change.
  • AWB etc. need to learn the additional syntax.
  • {{#category:Things}} is not a link but a function call which says Categorize me!
  • The link format will need maintenance in eternity.
  • Invention of category link format is older than parser function format and, from current viewpoint, a quite confusing idea.

XML tag

A third approach could be

<category title="Things" sort="Key" />

L10N is less obvious, and keywords would need translation as well.

  • Both Lua and templates could use this.

Event Timeline

Please correct me if I'm misunderstanding your use-case.

Consider:

  • {{#expr: 3.1416 * {{#invoke:Math|compute|{{{d}}}}}}}
  • {{#if: {{#invoke:Wikidata|retrieve|{{{p}}}}} | ...}}

If the problem is that the #expr and #if parser functions are swallowing the error messages generated by your modules, why wouldn't you just do the math or conditional logic in Lua itself?

If the problem is that the #expr and #if parser functions are swallowing the error messages generated by your modules

Indeed, this is the primary problem. However, this task has a wider view and is heading for a long-term replacement of square bracketed link syntax for categorizaton.

why wouldn't you just do the math or conditional logic in Lua itself?

Why wouldn’t you – well, if you assign you to me personally, this wouldn’t be a big deal.

  • However, German Wikipedia has less Lua programmers and maintainers for all modules as fingers on your hand.
  • But there are hundreds of authors with advanced skills in template programming, and thousands who could carry out simple template maintenance as well.
  • Therefore we have a guideline that programming should be done on lowest level, in template language, if suitable. There are a few libraries with general functions on basic level to support templates, but content specific templates are written and maintained by authors without Scribunto.

You might consider figure@Expr which may be used to convert tricky local number formats into {{#expr:}} terms (better than {{formatnum:}} does).

You could make use of #iferror for your case. It catches any element (namely strong, span, p, div) that has a class "error". This includes errors generated by Scribunto.

On a related note, see also T137584.

You could make use of #iferror for your case. It catches any element (namely strong, span, p, div) that has a class "error". This includes errors generated by Scribunto.

This does not help.

It would require that everybody ever using such a template transclusion has to change the transcluding template and distinguish all possible cases first.

  • {{#expr: 3.1416 * {{#invoke:Math|compute|{{{d}}}}}}}

First you have to analyze the result of {{#invoke:||}} and analyze whether error occurred, throw category if any, otherwise proceed with computation and transclude once again.

  • The {{#invoke:||}} has knowledge which kind of error and caused by which circumstances (missing number of inhabitants on Wikidata) and possible remedies.
  • The {{#iferror:}} only knows that any error occurred in computation for any reason, but not the specifc reason (invalid ISBN).