Last modified: 2012-09-14 23:23:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14034 - Add parser function #ifnumber or similar
Add parser function #ifnumber or similar
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://de.wikipedia.org/wiki/Vorlage:...
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-08 00:05 UTC by Tim Landscheidt
Modified: 2012-09-14 23:23 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch for #ifnumber against revision 34765. (2.15 KB, patch)
2008-05-14 01:24 UTC, Tim Landscheidt
Details

Description Tim Landscheidt 2008-05-08 00:05:56 UTC
There is much demand in templates to check if a given parameter is a number that can be used for calculations, cf. [[:de:Vorlage:IstZahl]]. Most template-only solutions have one or more weaknesses, and in the end, it should not be very performant either to do this check with templates.

  So I propose a function #ifnumber that tests whether its parameter is a number. Even more useful would be a bunch of shortcuts to this new function and #expr tests: #ifinteger, #ifposnum, #ifposint, etc.
Comment 1 Daniel Friesen 2008-05-08 00:26:54 UTC
I'm thinking a line of functions:

{{#ifnumber:}} - Would output the input if true, otherwise output nothing.
{{#ifnumber:|true|false}} - Would output true if true, otherwise false.

#ifinteger: would work in the same way as #ifnumber.

But rather than the if???int, I think an #ifpositive and #ifnegative, which work in the same way as the previous.

So you could actually combine them together:
{{#ifpositive:{{#ifinteger:{{{1|}}}}}}} - This would return things like +25, 25, etc... But if it gets 2.5, 2e10, or -2 it'll return empty.
Comment 2 Splarka 2008-05-08 00:31:15 UTC
Just a note: you can use something like {{#iferror:{{#expr:{{{1|}}} }}|not number|number}} for ifnumber. 

And the rest can be done with clever use of #ifeq, #ifexpr, and #expr, for example, ifinteger might be:

 {{#ifeq:1|{{#expr:({{{1}}} round 0) / {{{1}}}}}|true|false}}
Comment 3 Tim Landscheidt 2008-05-08 01:24:10 UTC
There are three considerations to be taken into account:

1. {{#iferror:{{#expr:{{{1|}}} }}| ... will not only accept numbers, but (any) expression. So, for example, if an editor has to state a (single) height in meters and he enters "100-150" (note the hyphen), your test will succeed but a subsequent conversion to feet will show very interesting results :-). While there may be use cases for editor provided expressions, most times they are simply errors. Your "{{#ifeq:1|{{#expr:({{{1}}} round 0) / {{{1}}}}}|" seems to be more stable, but I have not tested it thoroughly.
2. The semantics of "{{#iferror:{{#expr:{{{1|}}} }}|" are very hard to understand especially if you are new to template programming and/or it is embedded somewhere in other "{{#if:"s. This is a parser functions problem at large as well.
3. I haven't run any tests, but I think that a PHP implemented #ifnumber will ease the server load compared to the myriad of template-only solutions.
Comment 4 Splarka 2008-05-08 03:35:40 UTC
1) well, any valid expression is also a number of a sort(in that it expresses a number). That seems good enough... ish.

2) True enough, but they can be made into templates (that don't have to return 'true' and 'false' necessarily).

3) Probably, but there are many tricky implementations of parserfunctions that could be simplified, and yet aren't, because the demand for them is so low.

Comment 5 Tim Landscheidt 2008-05-08 12:24:42 UTC
Have a look at and feel free to edit http://www.mediawiki.org/wiki/User:Tim.Landscheidt/Template:IsNumber. If you can provide a template with no shortcomings, this bug can be closed as far as I'm concerned. But I see no way to solve the problem with templates alone.
Comment 6 Tim Landscheidt 2008-05-14 01:24:42 UTC
Created attachment 4900 [details]
Patch for #ifnumber against revision 34765.

Patch against revision 34765.
Comment 7 au 2012-06-17 18:40:58 UTC
Hi Tim, thank you for the patch!

As you may already know, MediaWiki is currently revamping its PHP-based parser
into a "Parsoid" prototype component, to support the rich-text Visual Editor
project:

   https://www.mediawiki.org/wiki/Parsoid
   https://www.mediawiki.org/wiki/Visual_editor

Folks interested in enhancing the parser's capabilities are very much welcome
to join the Parsoid project, and contribute patches as Git branches:

   https://www.mediawiki.org/wiki/Git/Tutorial#How_to_submit_a_patch

Compared to .diff attachments in Bugzilla tickets, Git branches are much easier
for us to review, refine and merge features together.

Each change set has a distinct URL generated by the "git review" tool, which
can be referenced in Bugzilla by pasting its gerrit.wikimedia.org URL as a
comment.

If you run into any issues with the patch process, please feel free to ask on
irc.freenode.net #wikimedia-dev and the wikitext-l mailing list. Thank you!
Comment 8 Tim Landscheidt 2012-09-14 23:23:24 UTC
As the original intent of the function was to check arguments in complex templates and this is/will easily be possible with Lua (http://test2.wikipedia.org/wiki/Module:IsNumber):

| local p = {}

| function p.IsNumber(frame)
|     return not(tonumber(frame.args [1]) == nil)
| end

| return p

I'm closing this bug as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links