Help talk:ParserFunctions/Archive 2

This is an archive, please don't add comments here. Copy the section to the main article (or link to it from the main article) for new comments.

Bugs

This is an archive, some bugs were no bugs, others are submitted, the following debates are old.

{{subst:}} does not support nested conditional's

• Halló! Please go to template talk:inline#rendering 09:45, 13 April 2006 (UTC):
• I would say that {{subst:}} fails. What is your opinion? Gangleri · Th · T 23:10, 16 April 2006 (UTC)

I also would expect that substing a template that contains calls to ParserFunctions would be best substed by replacing the calls to the ParserFunctions with the corresponding "plain" wiki source (the output from the ParserFunctions). However, I have no clue if the implementation supports this or if it would be a pain to implement. If it's the latter, then I'm the first one to say "forget it". Substing is not essential. It is nice to have. Tim has already done a bangup job doing ParserFunctions and we shouldn't be so picky about every little thing. Hey this is new stuff, and it is very helpful. Let's use what we have for now. A lot of things can be done later, if they prove to be needed and important enough (and of course not harmful). Please remember that until recently we even didn't have ParserFunctions! So don't expect that PF now solves every gimmick that we can think of (sorry if I exaggerate a bit :-). --Ligulem 23:42, 16 April 2006 (UTC)

Two weeks ago I was experimenting about

bugzilla:02177 – "Expanding sort order BEHIND the sort key"

at category:GENERICNS test but despite both template:NSSORTORDER and the syntax at help:GENERICNS_test looked simple they did not sort properly. Only after I used

[[Category:GENERICNS test|GENERICNS test {{subst:NSSORTORDER|{{NAMESPACE}}}}]]

they soreted properly at another wiki. Beleive me: Many people will start craying if they see "those" subst in the main namespace. Gangleri · Th · T 02:23, 17 April 2006 (UTC)

To go to the point: As long as it works and it is simple (it does not complicate the articles in the article namespace) nobody wold complain about implmentation (php code or template code). Once template code or fragments of it would be visible that will change dramatically. Gangleri · Th · T 02:58, 17 April 2006 (UTC)

Um. At least for the en:wiki – where I know that en:template:qif has acquainted some acclamation – There is no change for templates using #if instead of qif. qif also cannot be substed. And the substing of #if is even better (despite myself having noted that substing on PF can be improved). --Ligulem 08:40, 17 April 2006 (UTC)

Odd behaviour: {{{1}}} in {{#if:}}

When calling {{{1}}} undefined as a result in {{#if:}}, it treats it as a parameter of {{#if:}} instead of the page containing the function. Given {{#if: {{{test}}} | This is the result with {{{1}}} }}, the expected output is "This is the result with {{{1}}}". However, the function treats {{{1}}} as the result parameter and outputs "This is the result with This is the result with {{{1}}}". This doesn't occur if a default value is set.

This seems logical in a program, but is not the expected result in a function intended to be used inline. The following table shows variations with the results. The results column is subst'd.

Code	Result	Notes
{{#if: {{{test}}} | This is the result with {{{1}}} }}	This is the result with This is the result with {{{1}}}	Odd.
{{#if: {{{test}}} | This is the result with {{{1|default}}} }}	This is the result with default	Normal (not subst'd, with default value).
{{subst:#if: {{{test}}} | This is the result with {{{1|default}}} }}	This is the result with This is the result with default	Odd (subst'd with default value).
{{#if: {{{test}}} | This is the result with {{{2}}} }}	This is the result with {{{2}}}	Normal (different parameter).

// Pathoschild (^talk/_map) 01:55, 18 April 2006 (UTC)

For relevance, this breaks templates in the form {{template|optional_unnamed_parameter}}. // Pathoschild (^talk/_map) 13:16, 18 April 2006 (UTC)

With a narrow legacy browser window I had serious difficulties to make sense of your table, here is a condensed variant. -- Omniplex (w:t) 16:41, 18 April 2006 (UTC)

For me it's only taking up half the width of my browser window. AzaToth 16:49, 18 April 2006 (UTC)

Probably your browser knows CSS. Back to the example: It's clearly {{{1}}} that's clobbered by anything before it in #if:'s first parameter. Testing that theory I should get two x if I try

{{#if: {{ns:0}} | n/a | x {{{2}}} }} in the else-part:

x {{{2}}}. Bingo... :-) -- Omniplex (w:t) 18:03, 18 April 2006 (UTC)

First observation: it works as expected with {{ifdef}}. I'm surprised that #if: is eaten  by subst: like an ordinary Qif or Ifdef template, is that the expected behaviour? It removes the conditional part, let's ignore case -3- as less relevant and focus on your case -1-. -- Omniplex (w:t) 16:57, 18 April 2006 (UTC)

JFTR the same else-test with {{ifndef | {{ns:0}} | x {{{2}}} }}:

x {{{2}}} . Works as expected. Somehow #if: should protect the internally used 2nd and 1st parameter. My PHP-knowledge is strictly limited to some programming language, sorry. How about two auxiliary internal variables x and y protecting {{{1}}} and {{{2}}}?

Fixing a bogus signature with five tildes, and of course for a real comparison I've to test {{{1}}} in {{ifndef}}, not {{{2}}}: x {{{1}}} . Okay, really no surprises here. -- Omniplex (w:t) 18:25, 18 April 2006 (UTC)

Yes, I think subst'ing is expected and indeed desired functionality. // Pathoschild (^talk/_map) 01:11, 19 April 2006 (UTC)

I believe this could be related with bugzilla:5678. --Ligulem 08:06, 24 April 2006 (UTC)

ACK, I've added a link, just in case. -- Omniplex (w:t) 06:05, 26 April 2006 (UTC)

New 5678 test results

mediazilla:5678 is less harmful than I thought, see my test page:

1. It can hit any parameter, even the third, if there's a (bogus) third parameter in #if:
2. As expected it also hits #ifexpr:, not only #if:
3. It only affects the "undefined literal" for undefined parameters.

In other words an undefined {{{1}}} isn't shown as {{{1}}}, but as the stuff between first and second vertical bar (pipe symbol) in the #if: or #ifexpr:. But it is still handled as undefined, and therefore {{{1|okay}}} results in okay. Demo:

{{#ifexpr: 0|err|a {{{1}}} b}} {{#ifexpr: 0|err|c {{{1|okay}}} d}}

The result is a {{{1}}} b c okay d. -- Omniplex (w:t) 10:48, 4 May 2006 (UTC)

Ok. I applied that knowledge to en:template:Harvard citation. I used {{{1|}}} instead of {{{1}}} everywhere for numbered params (not only in the test expressions). Seems to work this way. --Ligulem 12:25, 4 May 2006 (UTC)

Patrick found that the 5678-behaviour changes under substitution:

case	defined	default	undefined
subst'ed	okay	corrupted	corrupted
no subst	okay	okay	corrupted

See Help:Substitution#Corrupted_default_value. Bad, I'd be tempted to use ifdef where I can get away with it, it doesn't change its oddities if subst'ed (unlike ifndef and qif). -- Omniplex (w:t) 06:17, 16 May 2006 (UTC)

For Tim: semi-bug with undefined numbered parameters

I have this problem: I'm trying to convert en:template:Harvard citation from qif to #if. The original template page display (looking at the template page, not in edit mode) looks like this: [1].

Then I converted to #if: [2]. Now the template page looks awful like this: [3].

A simpler variant of this problem can be seen here [4]. I believe it works ok when actually used, but if one of the unnamed parameters (aka numbered parameters) is not specified, it looks really awful. I fear if I do the transformation to #if on templates like en:template:Harvard citation and it looks like this afterwards, editors will not believe that this is not an erroneous edit.

Tim, could you please have a look at this and see if it is terribly difficult to improve the display of this or somebody tell me what I did wrong? --Ligulem 08:58, 19 April 2006 (UTC)

Please note that this comment regards a glitch discussed and documented under "Odd behaviour: {{{1}}} in {{#if:}}". Any discussion related to the glitch, as opposed to fixing these particular templates, should be placed under that header. // Pathoschild (^talk/_map) 09:11, 19 April 2006 (UTC)

Now it gets even worser: I edited http://en.wikipedia.org/w/index.php?title=User:Ligulem/work/Harward_citation_1&oldid=49136046 and pasted this in the edit window:

({{#if:
  {{booleq
       |{{{Ref|}}}
       |none
     }}
  |{{#if:
       {{{5|}}}
       |{{{1}}} et al. {{{5}}}
       |{{#if:
          {{{4|}}}
          |{{{1}}}, {{{2}}} & {{{3}}} {{{4}}}
          |{{#if:
             {{{3|}}}
             |{{{1}}} & {{{2}}} {{{3}}}
             |{{{1}}} {{{2}}}
           }}
        }}
     }}
  |{{wikilink
     |1={{#if:
        {{{Ref|}}}
        |#{{{Ref}}}
        <!--|#CITEREF{{{1}}}{{{2}}}{{{3|}}}{{{4|}}}{{{5|}}}-->
      }}
     |2={{#if:
          {{{5|}}}
          |{{{1}}} et al. {{{5}}}
          |{{#if:
             {{{4|}}}
             |{{{1}}}, {{{2}}} & {{{3}}} {{{4}}}
             |{{#if:
                {{{3|}}}
                |{{{1}}} & {{{2}}} {{{3}}}
                |{{{1}}} {{{2}}}
              }}
           }}
        }}
   }}
}}{{#if:
  {{{loc|}}}
  |, {{{loc}}}
  |{{#if:
     {{{p|}}}
     |, p. {{{p}}}
     |{{#if:
        {{{pp|}}}
        |, pp. {{{pp}}}
      }}
   }}
}})<noinclude>
</noinclude>

Not the added html comments on the line #CITEREF. When I click on preview, after a unusal long time (a minute or so) I get this error message:

Fatal error: Allowed memory size of 83886080 bytes exhausted (tried to allocate 27082706 bytes) in /usr/local/apache/common-local/php-1.5/includes/Parser.php on line 2308
(10.0.5.3)

This is reproducible. Shall I submit a bug on bugzilla for this? Just wondering whether this talk page is not so well suited for bugs. --Ligulem 08:22, 24 April 2006 (UTC)

#ifeq: a bug

{{#ifeq: 03 | 3 | eq | ne}} gives eq. You see, if #ifeq compares strings, then this shouldn't appear. After looking into the ParserFunctions.php, the "==" of "if ( $left == $right )" should be a "===". Upssdr 09:45, 20 April 2006 (UTC)

See bugzilla:5693 --Ligulem 08:02, 24 April 2006 (UTC)

Installation Problems

ParserFunctions didn't work on my MediaWiki after installation, following ParserFunctions#Installation. After a while I figured out that the parser didn't recognize the "#" sign. So for me, {{expr: (100 - 32) / 9 * 5 round 0 }} worked! I changed my ParserFunctions.php e.g. from

$wgParser->setFunctionHook( 'expr', array( &$wgExtParserFunctions, 'expr' ) );

to

$wgParser->setFunctionHook( '#expr', array( &$wgExtParserFunctions, 'expr' ) );

and it works now. Is something broken with my MediaWiki, or why didn't it work as described? --Korbinian 16:03, 20 April 2006 (UTC)

The change to use # was made in MediaWiki 1.7 (currently only available from SVN in alpha form). —Locke Cole • t • c 17:10, 20 April 2006 (UTC)

Ah, OK. Thanks. --Korbinian 23:34, 20 April 2006 (UTC)

#if: doesn't work with wikilink open bracket

{{#if: true|[[}}foobar{{#if: true|]]}}

• expected: foobar
• result: {{#if: true|[[}}foobar]]

--cpro 10:05, 23 April 2006 (UTC)

You might want to try {{#if: true|[[barbar]]|barbar}} (which gives you barbar). Why do you expect that the syntax you quote would work that way: your bracketing is not balanced and would therefore appear doomed to failure. HTH HAND —Phil | Talk 09:25, 24 April 2006 (UTC)

I have also problems converting en:template:Civairtd. I guess due to this issue here. If anyone has a clue what to do, please let me know. Wikilink syntax has always been a difficult thing in templates because the parser seems to treat this with greedy top priority. See also good old en:template:wikilink, which was sometimes needed and helpful. --Ligulem 22:49, 24 April 2006 (UTC)

Hm, I don't understand the real result. What's it doing? It could treat }} with priority, then the result should be [[ from the first #if:, plus "foobar", plus ]] from the second #if, that's in fact foobar, but obviously not what happens.

Next possibility, finish [[ ... ]] first, [[}}foobar{{#if: true|]], but that's also not what we see. -- Omniplex (w:t) 13:06, 27 April 2006 (UTC)

Help please

Could someone help me please. My local wiki (1.7 r13859, php 5.1.2, (apache2handler), apache 2.0.55 windows, mysql 5.0.17-nt) failed to display the proper result when using {{#if:}} (see this (slow connection)) and compare it to same page on test.wikipedia.org Am I missing something? The template:

{| border="1"
|name||{{{name}}}
|-
|address||{{{address}}}
|-
|phone||{{{phone}}}
{{#if:{{{city|}}}|<tr><td>city</td><td>{{{city}}}</td></tr>}}
|}

The page:

{{tes|name=Robert|address=Street|phone=987665|city=Bangkok}}

The result:

wrong result at local

correct result at test.wikipedia

Thanks Borgx 04:29, 24 April 2006 (UTC)

No idea, and for what it's worth, I have the same problem on my local 1.7 installation (even after performing "svn up" and getting to MediaWiki: 1.7alpha (r13835)). —Locke Cole • t • c 06:37, 24 April 2006 (UTC)

Good news, after days of madness search and reinstalling, it appears that key to this problem is the missing parameter $wgUseTidy=true; (it has "false" as default value). Perhaps we shall propose this parameter to be "true" as default. Borgx 23:57, 27 April 2006 (UTC)

Tidy probably only hides the real problem, a missing |- after the last unconditional row resulting in </tr>. Mixing wiki and XHTML table syntax can be tricky, somebody (or was this also you?) reported a similar problem on w:WP:VP/T some days ago. -- Omniplex (w:t) 13:20, 7 May 2006 (UTC)

Substed and non substed #switch show contradicting results

Please try the two following codes here on this page. Do you know why the first one, with "subst:" gives "no" as a result, while the second one gives "yes" as a result ? Is there any way to use #switch with "subst:" so that it behaves exactly the same way as without "subst:" ? Note that the same problem arises with #ifeq. Teofilo 18:08, 24 April 2006 (UTC)

{{subst:#switch:{{PAGENAME}}
 |ParserFunctions=yes
 |no
 }}

{{#switch:{{PAGENAME}}
 |ParserFunctions=yes
 |no
 }}

If you subst: PAGENAME like this it seems to work:

{{subst:#switch:{{subst:PAGENAME}}
 |ParserFunctions=yes
 |no
 }}

If you also specify the literal value "ParserFunctions", the subst: works as well. So, FWIW, it appears to be a problem (if indeed it is a problem) with how PAGENAME is handled). At the very least, this should be a reasonable workaround. —Locke Cole • t • c 21:33, 24 April 2006 (UTC)

I made the same finding a while after I had written the above message. Thanks, Locke Cole, for looking into this problem. Teofilo 10:05, 25 April 2006 (UTC)

Help with #if

Trying to use #if is driving me mad - am I missing someting> I have a template called Test that looks like this:

{{#if: {{{param|}}} | value sent - {{{param}}} | No value sent }}

when I call it using various combinations I get the following:

{{Test}} produces value sent - {{{param}}}
{{Test|}} produces value sent - {{{param}}}
{{Test|param=}} produces value sent -
{{Test|param=AA}} produces value sent - AA

MartinGough 21:58, 24 April 2006 (UTC)

Seems to work fine (see User:Locke Cole/Test; same code as you provided above):

Code	Result
{{User:Locke Cole/Test}}	No value sent
{{User:Locke Cole/Test|}}	No value sent
{{User:Locke Cole/Test|param=}}	No value sent
{{User:Locke Cole/Test|param=AA}}	value sent - AA

Which version of MediaWiki are you using? —Locke Cole • t • c 22:37, 24 April 2006 (UTC)

MartinGough 11:09, 25 April 2006 (UTC)

• MediaWiki: 1.6.3
• PHP: 4.3.6 (cgi)
• MySQL: 4.1.11
• Extensions:
  • Parser hooks:
    • Cite, adds <ref[ name=id]> and <references/> tags, for citations, by Ævar Arnfjörð Bjarmason
    • Inputbox by Erik Moeller
  • Extension functions:
    • wfRssExtension, registerInputboxExtension, wfCite and wfSetupParserFunctions
  • Parser extension tags:
    • <rss>, <inputbox>, <ref> and <references>
• Hooks:
  • ParserClearState: (cite, clearState)

MartinGough 11:09, 25 April 2006 (UTC)

The Content Page says under Installation:1.6 that #if behaves differently in some way under 1.6, but the behavior is not described. It is also not apparent if that phrasing also refers to version 1.7. (SEWilco 05:34, 27 May 2006 (UTC))

According to this edit by User:Algorithm, #if does not work under 1.6. The edit comment does not mention 1.7 nor Bugzilla. (SEWilco 03:26, 28 May 2006 (UTC))

I didn't file a bug because ParserFunctions isn't designed to work in 1.6; it's just a fortunate happenstance that it functions at all. As for the glitch: In 1.6, #if always returns true no matter what you test for. This isn't the function's fault, just a consequence of how the 1.6 function parser works. It's possible to fix it most of the way by replacing !== with !=, but then it returns false for "0" as well. It isn't possible to fix it entirely. --Algorithm 06:20, 28 May 2006 (UTC)

So for 1.6 both "if:" and "#if:" fail. Does either work in 1.7? There is no mention of installation under 1.7 working. (SEWilco 12:54, 29 May 2006 (UTC))

Yes, #if works under 1.7, assuming you're not using an extremely early build. --Algorithm 01:38, 30 May 2006 (UTC)

Would you consider the #ifexpr: behaviour as bug? It returns the else-text for an empty expression like {{ns:0}} at the moment. -- Omniplex (w:t) 06:27, 30 May 2006 (UTC)

#if seems to work just fine in 1.6.6 if you change the line

if ( $test !== '' ) {

to

if ( (string)$test !== '' ) {

in the function ifHook

{{#if:}} now breaks wikiML table syntax

After a fix concerning another bug (see "Odd behaviour: {{{1}}} in {{#if:}}"), {{#if:}} now breaks wikiML (but not HTML) table syntax. For example, this bug affects {{ process header }} containing a conditional {{ shortcut }}:

Template code
{{process header}}
{| style="width:100%; margin-bottom:5px; border: 1px solid #006400; background:#DFD; text-align:center;" |- | style="width:20%; text-align:left; font-size:0.9em;" | {{{previous|}}} | style="width:60%;" | '''{{{title|{{SUBPAGENAME}}}}}''' {{{section|}}} | style="width:20%; text-align:right;font-size:0.9em;" | {{{next|}}} |} {| style="width:100%; border-bottom:1px solid #A88; background:#fAfAff;" |- | id="shortcut" class="noprint" style="border: 1px solid #999; background: #fff; margin: 0 0 .5em 1em; text-align: center; padding: 5px; float: {{{float|right}}}; clear: {{{clear|right}}}; font-size: smaller;" |- ! [[Meta:Shortcut|Shortcut]]:<br />{{{1}}} |- |} {{{notes|}}} |} <noinclude>[[Category:Template|Process header]]</noinclude> <br clear="all" />
{{shortcut}}
{| id="shortcut" class="noprint" style="border: 1px solid #999; background: #fff; margin: 0 0 .5em 1em; text-align: center; padding: 5px; float: {{{float|right}}}; clear: {{{clear|right}}}; font-size: smaller;" |- ! [[Meta:Shortcut|Shortcut]]:<br />{{{1}}} |- |}

The following indented and subst'd example shows the broken display. The output seems to indicate that {{#if:}} is swallowing the {| tag.

Example

This is the text of the notes parameter.

I'm currently unable to access the Test Wikipedia. However, the template is not yet fixed on Wikisource (s:Template:process header). It is hackishly fixed on Meta by converting {{ shortcut }} to HTML syntax. // [admin] Pathoschild (^talk/_map) 09:56, 27 April 2006 (UTC)

You could take w:Template:shortcut, it has built-in ifdef-functionality without using #if: or {{ifdef}} or {{qif}}. My last stand is that ifdef (direct or template) survives subst:, but {{ifndef}} / {{qif}} / #if: are peculiar about this - test cases derived from your original table collected here, (q)if(n)def docu and help updated. For #if: I hope that it will work sooner or later. For another example avoiding all kinds of if see w:Wikipedia talk:Qif conditionals. -- Omniplex (w:t) 12:17, 27 April 2006 (UTC)

I'm trying to understand what's going on here. The Template:Process header (this version) contains:

{| style="width:100%; margin-bottom:5px; border: 1px solid #006400; background:#DFD; text-align:center;"
|-
| style="width:20%; text-align:left; font-size:0.9em;" | {{{previous|}}}
| style="width:60%;" | '''{{{title|{{SUBPAGENAME}}}}}''' {{{section|}}}
| style="width:20%; text-align:right;font-size:0.9em;" | {{{next|}}}
|}
{| style="width:100%; border-bottom:1px solid #A88; background:#fAfAff;"
|- 
| {{#if:{{{shortcut|}}}|{{shortcut|{{{shortcut}}}}}}}{{{notes|}}}
|} <noinclude>[[Category:Template|Process header]]</noinclude>
<br clear="all" />

Now, let's dissect the line

| {{#if:{{{shortcut|}}}|{{shortcut|{{{shortcut}}}}}}}{{{notes|}}}

Now for analysis purpose, I replace triple { with "[" and triple } with "]" this gives:

| {{#if:"["shortcut|"]"|{{shortcut|"["shortcut"]"}}}}"["notes|"]"

This looks valid for me. A "border" case is that the template "Process header" uses a parameter "shurtcut" and calls another template named "shortcut" --Ligulem 08:01, 28 April 2006 (UTC)

This bug has been resolved. // [admin] Pathoschild (^talk/_map) 22:49, 28 April 2006 (UTC)

Odd behavior of round

• {{#expr: -4.5 round 0}}=-5
• {{#expr: -4.5 round 1}}=-4.5
• {{#expr: -4.5 round -323}}=0
• {{#expr: -4.5 round -324}}=0

What's "-0"? Why can similar conditions result in different results? This shows round is not an appropriate operator for #expr, thus int or floor could be the alternatives. Upssdr 12:22, 1 May 2006 (UTC)

round gives the number of digits after the decimal point, a non-negative whole number of decimal digits. Its behaviour for other values is undefined, you tested a negative number of decimal digits. Hard to guess what's going on:

{{#expr: -4.5 round 4294966973}}=-4.5
{{#expr: -4.5 round 4294966972}}=-4.5

Interpreting 4 bytes signed -323/-324 as unsigned 4294966973/4294966972 has the same effect. The limit is hex. FFFFFEBC dec. 4294966972 (or signed -324), for the next -323 / 4294966973 / FFFFFEBD it fails. I've no clue what that limit does, 322 numbers reserved for error messages maybe (?) -- Omniplex (w:t) 23:07, 1 May 2006 (UTC)

Round is fine. If you feed it incorrect (negative) values, expect undesired results. I do agree that a "floor" operator/function would be nice though (there's already a Floor template in EN, but having it built in would be better I think). —Locke Cole • t • c 07:18, 2 May 2006 (UTC)

It seems no solution for negative round. OK, just avoid negative rounding. But this way expr.php doesn't offer a perfect interface. Then how about this?

• {{#expr: 4.5 round 100000000000000000000}}=4.5

Regarding the en:Template:Floor, have you thought about "float inaccuracy"? Please have a look at the last sample of en:Template:Floor I add.

It was still incorrect, and I made the correct implementation, that works on all numbers, including negative ones, and small positive numbers. I also documented it with test cases.

Now the point is that round is not fundamental enough, and not simple enough, thus causing some problems. In this way I suggest round be replaced. Upssdr 11:23, 2 May 2006 (UTC)

You're feeding it invalid values again. If you looked at Expr.php, you'd see the parameter to round is converted to an integer with the intval function; it's then passed to the standard PHP round function. What is likely happening is that your extraordinarily large value is being converted to an integer with a negative value due to overflow.

Regarding the issue with Floor as implemented on EN, I'm sure the author will see that and fix it (if possible). As I said in my original response though, I support floor being added as a function (and PHP already has functionality built in, so we just need to expose it). Perhaps we should add {{#floor:<value>}} and {{#ceil:<value>}}? —Locke Cole • t • c 11:48, 2 May 2006 (UTC)

I'm just thinking the interface of Expr.php is not perfect. A warning must be mentioned in ParserFunctions for avoiding those odd behaviors. Otherwise, OK, if we can tolerate these tiny bugs, round is actually enough for normal use. Though floor or ceil also sounds good, Tim maybe won't look into it - there are too many requests. Upssdr 16:56, 2 May 2006 (UTC)

It's no #expr: issue, it's in the PHP (based on Locke's interpretation of the source). In theory #expr: could catch negative values, in theory it could also catch the "equivalent" huge positive integers. But actually that's a PHP bug, no #expr: bug.

A "floor" function should be the same as "x div 1" for an integer div. It's bad that div does the same as /, in all languages I care about div is the counterpart of mod. And "x - (x mod 1)" should be the same as "floor", but here it returns 0 for "3.21 mod 1". We could do:

{{#ifexpr: x = 0|0|{{#ifexpr: x > 0
|{{#expr: (x-0.5) round 0}}
|{{#expr: (x+0.5) round 0}}

For 3.21 that's 3, and for -4.56 that's -4. All ready for a template "floor", swap +/- to get "ceil". -- Omniplex (w:t) 09:06, 4 May 2006 (UTC)

I had the same odd behavior (with "-0" returned) using valid input, such as

• {{#expr: -0.0 round 0}} = -0 (OK)
• {{#expr: -0.1 round 0}} = -0 (BAD)
• {{#expr: -0.125 round 0}} = -0 (BAD)
• {{#expr: -0.2 round 0}} = -0 (BAD)
• {{#expr: -0.25 round 0}} = -0 (BAD)
• {{#expr: -0.3 round 0}} = -0 (BAD)
• {{#expr: -0.4 round 0}} = -0 (BAD)
• {{#expr: -0.5 round 0}} = -1 (is it OK?)
• {{#expr: -0.6 round 0}} = -1 (OK)
• {{#expr: -0.7 round 0}} = -1 (OK)
• {{#expr: -0.8 round 0}} = -1 (OK)
• {{#expr: -0.9 round 0}} = -1 (OK)

It affects the case where I want to perform a floor operation on small positive numbers:

• {{#expr: 0.0-0.5 round 0}} = -0 (BAD)
• {{#expr: 0.1-0.5 round 0}} = -0 (BAD)
• {{#expr: 0.125-0.5 round 0}} = -0 (BAD)
• {{#expr: 0.2-0.5 round 0}} = -0 (BAD)
• {{#expr: 0.25-0.5 round 0}} = -0 (BAD)
• {{#expr: 0.3-0.5 round 0}} = -0 (BAD)
• {{#expr: 0.4-0.5 round 0}} = -0 (BAD)
• {{#expr: 0.5-0.5 round 0}} = 0 (OK)
• {{#expr: 0.6-0.5 round 0}} = 0 (OK)
• {{#expr: 0.7-0.5 round 0}} = 0 (OK)
• {{#expr: 0.8-0.5 round 0}} = 0 (OK)
• {{#expr: 0.9-0.5 round 0}} = 0 (OK)

This extra minus sign for zero is very boring and most often undesirable (I know that this is a PHP feature which can't be changed in PHP itself for compatibility reasons), so it should better be fixed in the WikiMedia PHP source.

This oddity comes from PHP itself (whose built-in bogous round operator always outputs the sign of a negative number input before rounding the absolute value to the indicated precision), and this PHP bug is independant of the various IEEE rounding modes, and it is also independant of the inaccuracies of floating points (note that 0.5, 0.25, 0.125 have absolutely no inaccuracy in base-2 floating points handled by PHP, they are stored exactly). It should not transpire into Wiki itself (so it should be fixed in WikiMedia).

For this reason, the en:Template:Mod and en:Template:Floor have been created, taking into account the odd behavior with:

• negative numbers, for which it is even more hard to get a correct mathemetical rounding as negative numbers whose decimal is exactly 0.5 are rounded down (toward -infinite) instead of up (toward zero) like it is for positive numbers;
• and with small positive numbers near zero.

The round operator always gives wrong results for all numbers that are neither positive numbers larger than or equal to 0.5, or neither negative integers. The workaround is to make sure that all numbers are positive numbers >=0.5 before rounding. For example, a correct way to get the floor of all positive or null numbers is:

• {{#expr: (0.0+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.1+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.125+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.2+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.25+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.3+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.4+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.5+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.6+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.7+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.8+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (0.9+0.5 round 0)-1}} = 0 (OK)
• {{#expr: (1.0+0.5 round 0)-1}} = 1 (OK)
• {{#expr: (1.5+0.5 round 0)-1}} = 1 (OK)
• {{#expr: (2.0+0.5 round 0)-1}} = 2 (OK)
• and so on...

(Let's ignore the case where the right-hand operand is a overly large number, this is clearly an invalid use of this operator, which is not made to handle other cases than a few small positive or nul integers for the number of decimals).

86.207.229.152 05:23, 3 May 2006 (UTC)

-1 for -0.5 is fine. The -0 is a bug, the round result has to be normalized by adding 0 within "#expr:". But of course you can do it explicitly:

{{#expr: (-0.1 round 0)+0}} is 0. Unrelated to the -324 situation above. -- Omniplex (w:t) 09:29, 4 May 2006 (UTC)

Then are there any solutions??? Upssdr 15:14, 6 May 2006 (UTC)

Maybe submit a bug report with a proposed fix for Expr.php - or whatever the name is, see subject page. -- Omniplex (w:t) 13:04, 7 May 2006 (UTC)

Bug report: parsing numbers

1. In English "1.000 = one; 1,000 = a thousand"; in Polish "1,000 = one; 1.000 = a thousand". The parser must understand these differences.
2. In numbers, spaces and &nbsp;'s should be "invisible" to the parser.

tsca @ 13:41, 6 May 2006 (UTC)

The new R (raw) transformation for the NUMBEROF...variables is a better solution, otherwise mediazilla:5693 could get out of hand for #ifeq: and maybe also #switch: (if 5693 affects #switch:, I've not tested this). -- Omniplex (w:t) 13:11, 7 May 2006 (UTC)

JFTR, 5693 is a good feature also working for #switch:. -- Omniplex (w:t) 06:27, 16 May 2006 (UTC)

Requests and proposals

This is an archive, see above how to revive old debates, don't try it here please, nobody watches this page.

{{# <wikisyntax> }}

from [Wikitech-l] ParserFunctions trial

• {{# <wikisyntax> }} or {{#: <wikisyntax> }} (the last is using a colon) could be used as "grouping operator". I assume that it would not break template syntax and would be compatible with other functionality as {{subst:}}. Gangleri · Th · T 11:11, 14 April 2006 (UTC)

note:

{{#: <wikisyntax> }} would obsolete template:! T containing

<noinclude>{{Soft redirect|[[mw:Help:Magic words#Other]]}}</noinclude>

would improuve readability and would be / should be safe when {{subst:}} is used. Gangleri · Th · T 11:26, 14 April 2006 (UTC)

Trying to understand: For example I could then write in a hypothetical template X1:

{{#if: {{{a|}}} | this is a pipe: {{#:|}} }}

and {{X1|true}} would then yield "this is a pipe: |". Correct? (Sorry, for the silly example). --Ligulem 14:48, 14 April 2006 (UTC)

I did a simple example to make it simple for me to understand your proposal, which I feel might be worth to fully understand. So I am interested to understand your proposal. My example was not ment to demonstrate anything about the usefullness/non-usefullness of your proposal. I just do have problems to follow you into your realms. Which doesn't say anything about your proposal. A simple no or yes would have done it for my question. Sigh. --Ligulem 21:15, 14 April 2006 (UTC)

You are completely right and you provided a very good example. I did not work on the content for month waiting for a usefull syntax. It was an exercise and the / my code is not opimized. The examples also show that multiple pipe characters get involved when using wikitable syntax. Gangleri · Th · T 21:24, 14 April 2006 (UTC)

• Please look at the (broken) wikt:yi:טאָג (day) in the Yiddish Wiktionary. I assume that there are more people which can speak / read Yiddish transliteration then people who read Yiddish regulary in Hebrew script. I assume that the transcrtiption used by the Yiddish Scientific Institute is the most used in the "academic world". Beside the YIVO transliteration other transcrtiptions are used as well. (note: You will find also different aproaches regarding character encoding. This is based on hidtorical issues of operating systems, browsers etc.)
• The initial design of the pages in vikiverterbukh – ‎װיקיװערטערבוך‎ is a tabular one.
• For many word links to meta topics are quite usefull. At "day" you should find references to:

1. time divisions
2. divisions of the week
3. divisions of the day
4. derived terms
5. etc.

• Such divisions may or may not occur at all words in the dictionary. This is why they are "optional". If you look at tsayt - divisions, vokh - divisions, tog - divisions, tog - derived terms you will see that they contain a common part:

|-
| width="40%" align="right" valign="middle" style="background:#efefef; direction=rtl; font-size: 16px; font-family: Times New Roman;" | <Hebrew script>
| width="40%" align="left" valign="middle" style="background:#efefef; direction=ltr" | <Latin script>

• The idea of the "group operator" is to be able to include a block as

{{#:|-
| width="40%" align="right" valign="middle" style="background:#efefef; direction=rtl; font-size: 16px; font-family: Times New Roman;" | {{{Hebrew script}}}
| width="40%" align="left" valign="middle" style="background:#efefef; direction=ltr" | {{{Latin script}}}}}

• whereever you like / wherever you need it. The example with the two parameters is simplistic. You can find a conditional template at tog - derived terms which renderes differently depending on which page it is called. Best regards Gangleri · Th · T 20:49, 14 April 2006 (UTC)

I think this is a very interesting proposal that makes sense and could be helpful. --Ligulem 22:04, 14 April 2006 (UTC)

Agreed, this would be very helpful for mixing wiki-table syntax with conditionals/templates. —Locke Cole • t • c 23:48, 14 April 2006 (UTC)

What's the precise semantics? Guessing, protect all "|" at the top level of {{#: stuff }}, i.e. treat them literally like {{!}}. For templates and parser functions within {{#: stuff }} process "|" as alwyays separating parameters. So the only thing you can't directly write after #: would be }}. Sounds like a good idea if I understood it correctly. -- Omniplex (w:t) 00:44, 16 April 2006 (UTC)

Exactly! No need to embed / escape every pipe with {{!}}.

note: This is not the same syntax as

→ bugzilla:00826 – "feature request: "empty template" as {{|parameter1|parameter2}} should be ignored"

It would be nice to fix that too. Best regards Gangleri · Th · T 02:22, 16 April 2006 (UTC)

parameter handling

• I did not mention parameter handling for all syntax extensions handled here: I assume that all named parameters from the "parent level" and all unnamed parameters are also known inside the "{{#foo: }}" syntax extensions. This could be another argument in favor of "{{#: }}" because an additional call either in the <then> or <else> branche would require a syntax as "{{then_block|named_01={{{named_01}}}|named_02={{{named_02}}}|1={{{1}}}|1={{{2}}}}}" and the template:else_block counterpart. Gangleri · Th · T 23:42, 14 April 2006 (UTC)

{{ #source: <wikisyntax> }}

• Halló! Every child has a name. If it would make parsing easier why the "grouping operator" should not have its own name? The functionality is more important than anything else. Gangleri · Th · T 21:40, 15 April 2006 (UTC)

I'd prefer {{#: stuff }} because it will be a very popular construct, less typing, and in a certain way intuitive. -- Omniplex (w:t) 00:50, 16 April 2006 (UTC)

So do I. (I prefer the simpler {{#: <stuff> }}.) – Gangleri · Th · T 09:34, 16 April 2006 (UTC)

I prefer {{#: <stuff> }}. --Ligulem 08:38, 16 April 2006 (UTC)

Possible implementation

{{#: ... }} seems tricky to implement at first glance, since it can't behave like a normal parser function. If it's evaluated like any other function, what could it return? Additionally, the contents of {{#: ... }} shouldn't be exposed to other parser functions, since otherwise every function would have to include special code to handle the construct. Therefore, I propose a two-step process:

1. The contents of each {{#: ... }} construct are stored in an array, and replaced with {{#1}}, {{#2}}, etc.
2. After every parser function has run, these replacement constructs are replaced by their original contents.

This allows parser functions to run normally without worrying about complex code. Functions that expect numeric arguments would fail, but I don't think we'd want to allow {{#: ... }} constructs there either.

Thoughts? --Algorithm 23:32, 18 April 2006 (UTC)

Alternatively, the replacement constructs could contain an escaped version of the original content, so that the parser wouldn't need to store anything internally. One possibility would be to replace any non-alphanumeric character with #xx, where xx is that character's hexadecimal representation (e.g. {{#:|foo|bar}} would return {{##7Cfoo#7Cbar}} (assuming ASCII, though Unicode is more likely)). This approach has the added benefit of working inside {{#ifeq}} for complex comparisons. --Algorithm 02:27, 21 April 2006 (UTC)

Scratch the whole thing; urlencode() and urldecode() are far easier to implement and provide the same effect. --Algorithm 21:52, 23 April 2006 (UTC)

Ternary operator

I suspect Tim will want to stab me for suggesting it, but any chance of (or interest by others in) a ternary operator for use with #expr (preferably identical to C's ?: operator)? —Locke Cole • t • c 11:47, 14 April 2006 (UTC)

You can put an #ifexpr inside an #expr, no need to add new syntax. --193.86.75.124 14:44, 14 April 2006 (UTC)

Yeah, but the nesting can get ugly. =) But I take it that's a no to others interest. ;) —Locke Cole • t • c 20:47, 14 April 2006 (UTC)

localization of expressions

• At some point in time one should think about localization for the different numeral systems. I think about Indian, Arabic, Eastern Arabic, Thai numerals. I am shure all are happy with the provided functionality but the question about localization will arrive sooner or later. Best regards Gangleri · Th · T 21:09, 14 April 2006 (UTC)

The Thai and Arabic Wikipedias use the European numerals anyways, so I don't think it's an issue there. But at the Wikipedias that do use, for example, the Indian numerals, this extension should at least produce the localized numerals for code like {{#expr: 2+2}}. – Minh Nguyễn (talk, contribs) 02:06, 15 April 2006 (UTC)

• Thanks Minh Nguyễn for the feedback. Please see also the TOC at fa:اسپرانتو#toc and hi:विकिपीडिया:सहायता#toc. A list of wikies using similar scripts can be found at the end of hi:user:Gangleri. Gangleri · Th · T 02:29, 15 April 2006 (UTC)

• I found [[talk:WiktionaryZ#new magic words {{number:foo}} and {{value:bar}}]].
• If you like you can copy it as an subsection. Gangleri · Th · T 15:16, 16 April 2006 (UTC)

complete list of languages using function digitTransformTable()

• LanguageAr.php LanguageAr.php
• LanguageAs.php LanguageAs.php
• LanguageBn.php LanguageBn.php
• LanguageBo.php LanguageBo.php
• LanguageFa.php LanguageFa.php
• LanguageDz.php LanguageDz.php
• LanguageHi.php LanguageHi.php
• LanguageGu.php LanguageGu.php
• LanguageKm.php LanguageKm.php
• LanguageKn.php LanguageKn.php
• LanguageLo.php LanguageLo.php
• LanguageMl.php LanguageMl.php
• LanguagePa.php LanguagePa.php
• LanguageOr.php LanguageOr.php
• LanguageTe.php LanguageTe.php

• Thanks Nike! Gangleri · Th · T 21:06, 4 May 2006 (UTC)

Suggestions

First, as there is a ifeq construct, I think there also shouöd be an ifne construct. Second, as a complement to the expr construct, I suggest that there could ba some optional flags to be used to define how the result should be formated (like this {{#expr:1234|flags}}), so for example defined that the result should be in the form 1,234 or that it should be for exmaple 4 significant numbers, and the rest zeroes (1.234, 12,34, 123400 etc...) AzaToth 13:49, 16 April 2006 (UTC)

{{#ifne:param1|param2|True|False}} would be the same as {{#ifex:param1|param2|False|True}}, so #ifne isn't nessesary. For the second idea I think it's better to add something like {{#format:<number>|<format>}}</code> WebBoy 14:22, 16 April 2006 (UTC)

An other idea, for ifexpr, if there is more than two arguments given, then the second arguments is interpret as expressions to give an if else construct (for example {{#ifexpr:expr|then|expr|then|else}}) AzaToth 14:30, 16 April 2006 (UTC)

Math with Wikipedia-style numbers

Any chance of making #expr ignore commas in Wikipedia-style numbers (e.g. take 100,534 and do math with it as if it were 100534). Otherwise template-based output has to either use non-comma delimted numbers or not use math. Emt147 22:10, 16 April 2006 (UTC)

This could be done with "str_replace" (¿ "substr_replace" ?) from #Request for string functions. Please take a look also at en:template:CURRENTHOUR, en:template:CURRENTMINUTE. There are hundred more examples for "str_replace" (¿ "substr_replace" ?). Gangleri · Th · T 23:01, 16 April 2006 (UTC)

The templates you mention use a brute force hack to parse the times (I didn't see any str_replace in the source code). This approach obviously cannot be used for content templates unless ParserFunctions can accept regular expressions (i.e. (#+),(###) to $1$2). The issue is problematic because WP MoS prefers comma-delimited numbers so switching all articles to non-delimited digits is a crappy alternative. Emt147 23:57, 16 April 2006 (UTC)

Assuming you have a "{{#str_replace: | {{CURRENTTIME}} | : | }}" for "replace ":" with ''" (i. e. with the empty string) you can write for template:CURRENTHOUR:

{{
#ifexp: ({{#str_replace: | {{CURRENTTIME}} | : | }} / 100) = 0 | 00 | }}{{
#ifexp: ({{#str_replace: | {{CURRENTTIME}} | : | }} / 100) = 1 | 01 | }}{{
#ifexp: ({{#str_replace: | {{CURRENTTIME}} | : | }} / 100) = 2 | 02 | }}...{{
#ifexp: ({{#str_replace: | {{CURRENTTIME}} | : | }} | : | }} / 100) = 23 | 23 | }}

This only ilustrates that all defined string manipulating functions ("str_replace" alone will not do it) should be available both in the <expr>, in the <then> and in the <else> part. It would makes sense to use them also outside conditional template syntax. Gangleri · Th · T 01:20, 17 April 2006 (UTC)

Ok, now I see what you mean. Kinda moot point for now since it's not implemented yet but thanks for explaining it! Emt147 02:48, 17 April 2006 (UTC)

In the Dutch and many other languages we use a point instead of a comma for that purpose (100.534). So on nl.wikipedia we can simply use {{#expr: {{NUMBEROFARTICLES}} * 1000}} to get the plain number without the point.JePe 22:21, 17 April 2006 (UTC)

This is a recent unexpected change. that has affected French Wikipedia: before there was no thousand separator at all, but now the French thousand separator (space) is displayed in NUMEROFARTICLES, and it hurts in numeric expressions asthere's now an invalid syntax (the same will be true for English Wikipedia, now that a comma is displayed!).

My opinion is that NUMBEROFARTICLES should NOT be formated at all, in a format appropriate for numeric expressions and formatable through simple templates if needed, or there MUST first exist some parser functions to allow converting this format back to numeric, appropriate for the syntax of #expr expressions.

This change in NUMBEROFARTICLES has broken some maintenance pages of French Wikipedia.

I propose another solution than the brute-force string replace: define templates for formatting or reading numbers using localized conventions (see the long title at bottom of page for this NUMBEROFARTICLES bug)

verdy_p 15:57, 30 April 2006 (UTC)

number formating

Made this up in my memory, don't know if it's ok.

    function numFormat(&$parser, $value, $decimals = 0, $dec_point = '.', $thousands_sep = ','){
        $value = str2num($value);
        return number_format($value,$decimals, $dec_point, $thousands_sep);
        
    }

    function str2num(&$parser, $value){
        if(is_numeric($value)){ #If the value is already numerical
            return $value;
        }
        if(strpos($value, ' ')){ # Whitespaces is only used as 1000 delimiter
            $value = str_replace(' ', '', $value); 
            $value = str_replace(',','.',$value); # then if using comma, it should be a point
            return $value;
        }
        if(
            strpos($value, ',') &&
            strpos($value, '.') && 
            strpos($value, ',') > strpos($value, '.')
        ){ # 1.234,56
            return str_replace(array(',','.'),array('.',''),$value);
        }
        # Now we realy don't know if 1,234 or 1.234 is an integer of a float, we have to guess
        return str_replace(',','',$value); # 1,234.56
    }

    function round(&$parser, $value = 0, $sigdigits = 4){
        $sig = ceil(0 - log10($value)) + $sigdigits - 1;
        return number_format(round($value, $sig),$sig > 0 ? $sig: 0);
    }

AzaToth 16:49, 21 April 2006 (UTC)

operator

做为一非english为母语的维基人，我认为以下运算符应同时支持：

• 与“mod”对应的“%”
• 与“and”对应的“&”
• 与“or”对应的“|”(注：#expr并不需要|做参数分界)，或者另选“^”
• 与“not”对应的“!”

—自由主义者☎ 2006-04-23 02:53(UTC) local time10:53(UTC+8)

I have no clue what you are saying because I don't know your script/language. Could you write in English? --Ligulem 07:41, 23 April 2006 (UTC)

Hey, maybe he's saying:

As a wikipedian with a mother tongue of non-english [Chinese], I think the following operators should be implemented:

• "%" as "mod"
• "&" as "and"
• "or" as "|" or "^"(note that #expr doesn't need "|" as delimiter)
• "!" as "not"

His sign shows that he's a liberal. Upssdr 08:22, 23 April 2006 (UTC)

thanks, my english is very poor. i think meta not in english only.—自由主义者☎ 2006-04-25 12:52(UTC) local time20:52(UTC+8)

Feature request: #urlencode: and #urldecode:

Should behave just like the corresponding PHP functions. I'd provide a patch, but it's pretty much trivial anyway. en:Template:Vandal would particularly benefit from this. --Ilmari Karonen 12:23, 23 April 2006 (UTC)

Strongly agree, as this would also provide a method to include {|-style tables in #if functions. The names should probably be shortened significantly, however; perhaps to one of these options?

• #encode and #decode
• #enc and #dec
• #>> and #<<

--Algorithm 22:00, 23 April 2006 (UTC)

Actually, the request above at [[#{{# <wikisyntax> }}|{{# <wikisyntax> }}]] would allow us to use pipes/etc. as well (and be cleaner too; urlencoded pipes would be ugly probably). However, this does seem like it would be useful, and I support including it. —Locke Cole • t • c 23:06, 23 April 2006 (UTC)

Using pipes would be easy with this function, provided it is properly coded:

The code {{#decode: {{#if: true | {{#encode: {|- }} }} }}
 becomes {{#decode: {{#if: true | %7B%7C- }} }}
 becomes {{#decode: %7B%7C- }}
 becomes {|-
and you're done!

--Algorithm 00:16, 24 April 2006 (UTC)

As I was saying, URL encoded pipes would be ugly. And I was right, %7B%7C is ugly. Further, the problem with pipes right now is that the parser (at the MediaWiki level) is what separates things out; the proposed {{#: <stuff> }} would presumably be built in to MediaWiki (and not done via an extension). —Locke Cole • t • c 01:04, 24 April 2006 (UTC)

Feature request: #ifexists:

See en:Template:Exists. This would presumably be much cheaper (not to mention more reliable) to do as a parser function than by abusing transclusion. This would be useful in en:MediaWiki:Noarticletext, and likely elsewhere. Suggested syntax: {{#ifexists: pagename | then | else }}. --Ilmari Karonen 17:18, 26 April 2006 (UTC)

Nice idea, I'd suggest using a different (and more specific name) like #ifpageexists. —Locke Cole • t • c 20:43, 26 April 2006 (UTC)

How about just #ifpage? --Algorithm 06:58, 27 April 2006 (UTC)

This has been added (see bugzilla:6078). HTH HAND —Phil | Talk 08:17, 25 May 2006 (UTC)

dec2hex

The function should convert a decimal value to a 2 digit hexadecimal. Of course it is needed to generate HTML color codes from numerical decimal values.

This should be easy to implement, actually I am emulating it with a scary sequence of {{#ifexpr:{{{1|}}}=0|00}} ... {{#ifexpr:{{{1|}}}=255|FF}} and so on.(See it:Template:Termometro).

By, it:Paulatz. 23:05, 24 April 2006 (UTC)

Intrapage Variables, similar to REF and REFERENCES

This would be extremely useful and would probably save a whole load of server load. Sometimes in a template you need to do something with a given parameter, maybe switch it, and then use the result of the switch multiple times throughout the rest of the template. This means you have to switch the parameter in exactly the same way every time you want to use it. I suggest adding some kind of function that allows you to assign values to variables within template code, and then call the variables later. I notice that this is clearly possible as ref and references tags do this.

Example (template code):

You chose: {{#switch:{{{1}}}|1=foo|2=bar|3=baz}}! {{#switch:{{{1}}}|1=foo|2=bar|3=baz}} is a good choice. You can now use this code: <code>My name is: {{#switch:{{{1}}}|1=foo|2=bar|3=baz}}</code> to tell people your name, {{#switch:{{{1}}}|1=foo|2=bar|3=baz}}!

This shows how one function on one parameter do something quite simple has suddenly needed to involve 4 calls to ParserFunction #switch; i.e. 4 times the server load. Although the above example is simplistic, this kind of things happens a lot. I suggest that the above could be implemented with a new function to assign and call variables:

{{#var:name| {{#switch:{{{1}}}|1=foo|2=bar|3=baz}} }} <!-- assigns param2 to variable name given in param1 --> You chose: {{#var:name}}! {{#var:name}} is a good choice. You can now use this code: <code>My name is: {{#var:name}}</code> to tell people your name, {{#var:name}}!

When function #var is called without a 2nd parameter, it is taken to be a variable call; when called with a 2nd parameter, it is taken to be an assignment. As can be seen above, this makes things a lot neater, easier, and quicker. I think this function is very much needed. --Alfakim 16:43, 27 May 2006 (UTC)

Endnote: This could evem allow arrays based on variable-name string concatenation: {{#var:name[{{{arraynum}}}]|foo}} --Alfakim 16:43, 27 May 2006 (UTC)

Other

This is an archive, see above how to revibe old debates, better don't try it here.

Usage notes

I've applied #if: on a trial basis to the fairly high use en:template:cite web, which previously used en:template:qif. --Ligulem 20:28, 14 April 2006 (UTC)

Also, all known pages that contain ParserFunctions constructs at the Vietnamese Wikipedia are being listed at vi:Thảo luận Trợ giúp:Tính toán#Trial. I'm pushing for a guideline there to restrict the use of these functions, in case they get turned off in the future: "use the functions only when the arguments involve magic words; otherwise just pull out your trusty calculator and type in the result." Or something like that. – Minh Nguyễn (talk, contribs) 09:58, 15 April 2006 (UTC)

Woops. Usage of #if seems to spread fast. Ian Moody (never seen him before on that template!) has already applied that to the high used en:template:cite book ([5]) - gough. So much for the "trial" phase... :-). --Ligulem 20:53, 15 April 2006 (UTC)

Article utilising algebraic functionality

I choosed w:Boeing 747 to test automatic conversion of values. there are some conversion from miles, miles per hour, feets, machs etc... AzaToth 17:22, 16 April 2006 (UTC)

Isn't the whole idea of ParserFunctions to reduce the number of templates, not to add a hundred new ones? Emt147 22:08, 16 April 2006 (UTC)

Server load

How much of a sever load is imposed by doing calculations through this function? E.g. if I wanted to do on-the-fly imperial-to-metric unit conversions for specifications, say 25 calculations per page, would that be excessive?

What is the server load like compared using qif? Should I convert my templates from qif to this function to go easier on the servers? Emt147 19:58, 16 April 2006 (UTC)

The whole extension was made to avoid the server load produced by qif. Jon Harald Søby 20:00, 16 April 2006 (UTC)

To be clear, it was to reduce the database calls needed to render a page (as I understand it anyways). Qif, being a template page like mostly any other, incurred it's own DB hit whenever it was called. #if, OTOH, does nothing with the DB and implements the logic via PHP. Someone more knowledgable should correct any mis-statements on my part. =) —Locke Cole • t • c 20:16, 16 April 2006 (UTC)

Gotcha. I'll convert my templates to use this extension. What about calculations? Emt147 20:36, 16 April 2006 (UTC)

I'm pretty sure that page caching will make these almost entirely free. —Locke Cole • t • c 20:53, 16 April 2006 (UTC)

Nested functions

Does ParserFunctions support nested functions? E.g. {{ #if: <condition> | <then text> | {{ #if: <condition> | <then text> | <else text> }} }} Emt147 20:41, 16 April 2006 (UTC)

Yes it does. See en:template:cite book for an example. There is also the en:category:Templates using ParserFunctions. Please note that ParserFunctions is still in trial phase (per Tim [6]). So a broad application is not recommended for now. Use it on some pilot templates (or your sandbox) and keep a close eye on them and report your experience here. Be prepared that ParserFunctions is changed or even shut down (But I strongly hope the latter will not happen and I know of no reason why this should happen. Crossing fingers). --Ligulem 21:52, 16 April 2006 (UTC)

Very cool. I'm glad Wikipedia is finally getting some real scripting capacity rather than template-based hacks. Emt147 22:05, 16 April 2006 (UTC)

bat-shit insane

You people are bat-shit insane for turning on these functions. The only problem is that none of you will likely see the harm this will inflict on would-be editors who've never bothered to learn programming languages. -- Netoholic @ 14:09, 18 April 2006 (UTC)

No, that happened when {{foreach}} was coded up. :^) My advice is to push for a policy at individual projects, limiting the use of these constructs to places in which variables are involved. That would mostly prevent the parser functions from cropping up directly in articles. I know that at the Vietnamese Wikipedia we've limited the functions to the Main Page and a few supporting templates, templates that users probably won't need to use in articles. – Minh Nguyễn (talk, contribs) 21:16, 18 April 2006 (UTC)

We use the ParserFunctions extensively in WikiProject Aircraft specs templates. The templates are completely transpart to the vast majority of editors and the few problems we've had were with people who failed to read the directions written at the top of every page. If you can't read, you shouldn't be on the Internet anyway. I do agree with restricting the functions from general page text, e.g. w:Boeing 747 which calls a template using PF to convert feet to meters or something like that. Utterly pointless server abuse IMHO. Emt147 23:40, 18 April 2006 (UTC)

Yes, I have no problem with using the ParserFunctions in things like infoboxes, since that avoids the whole meta-templates controversy. As for unit conversion, that was my first thought when Tim enabled these functions, but seriously: take out a calculator (or a conversion website) and convert it once and for all; that way the server doesn't have to recalculate everything over and over again. – Minh Nguyễn (talk, contribs) 01:43, 20 April 2006 (UTC)

Actually, for people monitoring recent changes anyways, I sometimes see minor changes to conversions of distances/weights/whatever and wonder if they're being subtly vandalized. If we used a template to handle conversions, we'd see the single parameter being changed and know it was likely some form of vandalism (especially if it was the only change). —Locke Cole • t • c 05:28, 20 April 2006 (UTC)

Hm, maybe I should create a built-in unit converter for MediaWiki as a tiny little SoC project. :^P – Minh Nguyễn (talk, contribs) 09:17, 20 April 2006 (UTC)

I've been trying find the right channels to suggest that. Yes, please implement it! Along with that, submit a proposal to make metric the official standard of measurement of the mediawiki. Then a preference can be added for people that actually want feet/pounds/etc. Jeff Carr 02:42, 10 May 2006 (UTC)

Conversion templates can also be set up to only work when substituted. See w:Template:Conv-dist for instance. That way it is "converted once and for all". --CBDunkerson 23:52, 21 April 2006 (UTC)

Template:Ifdef

FYI as far as you're interested in Wikipedia, template:Ifdef (edit•talk•links•history) has been nominated for deletion on Wikipedia. It was discussed here before in conjunction with {{!}}. -- Omniplex (w:t) 14:26, 18 April 2006 (UTC)

#switch in action

For an example of the new #switch, see en:Template:Storm colour. (As a side note: if #switch is removed/changed, please fix this template. :P ) —Locke Cole • t • c 15:14, 18 April 2006 (UTC)

Switch is also being used a couple of times at en:Template:Airtemp. It's an extremely handy function! ericg ✈ 21:31, 21 April 2006 (UTC)

My first attempt: template:Allpages (edit•talk•links•history), copied to w:en:. -- Omniplex (w:t) 13:44, 7 May 2006 (UTC)

what's the use of preg_match_failure ?

In expr.php, I see "$this->error( 'preg_match_failure' )". It seems it's not used. Is this right ? Upssdr 08:05, 19 April 2006 (UTC)

Finding a method for reaching that branch is left as an exercise for the reader. Or you could find something more useful to do, like I don't know, writing some code of your own. -- Tim Starling 09:42, 19 April 2006 (UTC)

Order of Operations

Why is the table only "roughly in order of precedence"? Also, don't grouping operators actually come first? Ardric47 07:06, 24 April 2006 (UTC)

It's apparently in ascending order of precedence. :^) I'm guessing that the "roughly" part refers to the fact that multiplication and division actually have the same level of precedence, but are listed on separate rows, etc. – Minh Nguyễn (talk, contribs) 08:34, 24 April 2006 (UTC)

AND OR NOT

what do the and, or, and not funcutions in #expr:

It's boolean operators; 1 AND 1 is 1; 1 OR 1 is 1; NOT 1 is 0 etc.... AzaToth 16:58, 24 April 2006 (UTC)

Expressions don't work with strings?

{{#expr: x = x}} returns Expression error: unrecognised word "x", and likewise for {{#ifexpr}}. Is this intended? It seems to limit the utility of the functions (specifically I'd like to be able to check "a = b or c = d or e = f" without having to use a ton of {{#ifeq}}s). —Simetrical (talk • contribs) 05:28, 26 April 2006 (UTC)

1. expr does not and was never intended to work with strings. -- Tim Starling 15:35, 27 April 2006 (UTC)

Some points

Is there a way to convert decimal notation of geographic coordinates into minute notation with the available functions? I'm missing an abs function or a function returning the value right of the decimal point, but perhaps I'm only mathematical incompetent.

With Template:Rounddown you can separate the integer part and the fraction part of a decimal number of degrees. Multiply the latter by 60 to get minutes.--Patrick 00:44, 29 April 2006 (UTC)

Also I'm wondering whether there will be some kind of simple array handling. This would be useful for templates like the Commons:Template:Flag parameter maincolors, where up to now the different color values have to be encapsulated in extra templates to get the wanted behaviour.

And please make available a method of localizing number formatting. People need it. --::Slomox:: >< 17:28, 28 April 2006 (UTC)

question

I'm trying to write an extension but I'm not much of a pro yet. I'd like to know how to call an extension through this kind of wikitext: {{#sfs: }} as opposed to <this></kind>. Please reply here: wikipedia:User:Alfakim. Thanks. --131.111.8.102 23:45, 28 April 2006 (UTC)

NUMBEROFARTICLES bug, missing number formating/reading, missing floor operator, missing string expressions

It looks like something has changed last night in the implementation of the NUMBEROFARTICLES, nowit returns a localized formated number instead of a plain number asused in #expr expressions. This breaks some templates that compute values with #expr based on the current value of NUMBEROFARTICLES. For example now {{NUMBEROFARTICLES}} returns "149,738" with extra thousand separators (comma on English Wikipedia, space on French Wikipedia...)

I think this was a bad change that should be reverted. And the wrong way to do it. My opinion is that it's up to templates to format these numbers, if needed. But why not adding those two ParserFunctions:

1. {{#num:}}
   • {{#num:1,234.56|en}} returns "1234.56" using English formating rules (commas and spaces ignored, dot is the decimal separator)
   • {{#num:1.234,56|fr}} returns "1234.56" using French formating rules (dots and spaces ignored, comma is the decimal separator)
   • The language specifier for the decimal separator specifier is optional, its defaults is the local Wikipedia language code.
2. {{#fmtexpr:}}
   • {{#fmtexpr:1234.56|en}} returns "1,234.56" using English formating rules (commas and spaces ignored, dot is the decimal separator)
   • {{#fmtexpr:1234.56|fr}} returns "1 234,56" using French formating rules (dots and spaces ignored, comma is the decimal separator)
   • The language specifier for the thousand and decimal separator is optional, its defaults is the local Wikipedia language code.

And Finally, PLEASE, add

• 1. Support for the ternary operatoror some conditional operator, to simplify the syntax of expressions (to replace #ifexpr)

• 2. Support for the floor operator in expressions. Use exactly the same syntax as round, but it does NOT add 0.5 before converting:
  • the result will still be equal to it only if has no more decimals than given on the right;
  • however the absolute value of the result will be lower than the absolute value of the left operand only if the left operand is positive; otherwise the absolute value of the negative result will be higher for negative numbers with too many decimals.
  • it will convert the value to the nearest integer lower than the value (the absolute value will be higher for negative numbers). Many expressions are unnecessarily complex due to the limitations of the round operator (they substract 0.5 before using it, and have to test the sign using complex #if expressions outside of the main expression, so #expr expressions need to use an external template to perform the floor operation).

• 3. Support for intermediate named variables, also to get much simpler expressions. For example:

{{#var:
|a ={{#expr: 1 + 2 }}|
|b ={{#expr: {{{a}}} * {{{a}}} / 2 }}|
|{{#expr: {{{a}}} + {{{b}}} }}}}

• • (it assigns the result of numeric expression 1+2 to variable a, then the result of a*a/2 to variable b, then returns the value of a + b; the variables are just local to the current template only during the evaluation of the #var, it is not given implicitly to other templates, but can be given explicitly to subtemplates used in the expression, so the evaluation order is important: the first parameter MUST be evaluated before the next one, and the value of the last parameter is returned).
  • This is the generic version that will work with any text template. It avoids calling unnecessarily these templates multiple times. A simplified version, that will work only for numeric expressions could be:

{{#expr:
|a = 1 + 2
|b ={{{a}}} * {{{a}}} / 2
|   {{{a}}} + {{{b}}}
}}

• 4. Support for substrings. For example:
  • {{#len:some text}} just returns the length of the text in characters. "{{#len:ABC}}"="3"
  • Substrings counting characters from the start of text:
    • {{#first:some text|count}} just returns at most the count first characters of the text (count is optional and its default is 1): "{{#first:ABC}}"="A"
    • {{#after:some text|count|length}} returns at most length characters from the rest of the text, after dropping the first count characters (length is optional and defaults to the rest of the string up to its end; no error if count is longer than the actual text length, just return an empty string; count is also optional and defaults to 1 like for #first): "{{#after:ABC}}"="BC"
  • Substrings counting characters from the end of text:
    • {{#last:some text|count}} just returns at most the count last characters of the text (count is optional and its default is 1): "{{#last:ABC}}"="C"
    • {{#before:some text|count|length}} just returns at most length characters from the end of text after dropping the last count characters (length is optional and defaults to the rest of the string up to its start; no error if count is longer than the actual text length, just return an empty string; count is also optional and defaults to 1 like for #last) "{{#before:ABC}}"="AB"

verdy_p 15:58, 30 April 2006 (UTC)

Rob Church has added raw modifier to variables. See bugzilla:5768. Borgx 00:25, 1 May 2006 (UTC)

Thanks this solves the bug with a workaround for numeric variables. And allows proper formating of numbers according to locales used in each wiki (using templates with #expr to perform the formating however)

What about substrings? There are ugly and giant templates that just try to match many strings to find a reduced version of it. They could be much simpler with substrings.

For example see how we need to parse CURRENTTIME to just get the CURRENTHOUR and CURRENTMINUTE (the alternative is to predefine those templates in special variables, so we don't need any switch to get them.) The most commonuse of math templates is for calendar computing, needed in various places for site and content management. Well it works with templates butit's still ugly for current time values.

What about local named variables in #expr? This would reduce a lot the complexity of some #expr, because allexpressions need to be inlined. Sometimes with many repetitions of the same template parameter just because we can't have intermediate results. local named variables are easy to manage in PHP, using its associative arrays, butit could also avoid repeating many switches to assign somedefault values in template parameters. So the #var extension could be used to assign other template parameters, by overriding the value that is already stored in the existing template arguments associative array. Parsing #var like above would be really simple (the possibly ugly part is the evaluation order, because template parameters are all evaluated at once before the template is instanciated and replaced.

This change would mean that parameters must beevaluated only when they are used, so there would need to exist a flag to detect if the parameter has already been evaluated once when it is used. This change would benefit to #if* expressions, and to all templates in general, because we would instanciate and parse parameters only once to get their actual replacement value,instead of multiple times.If the parameter is not used (because of a #if or #switch, then noneed to parse it tocompute their replacement, as it won't be returned by the template. A #var assignment on the opposite would reset this evaluation flag. The principle is the lazy evaluation of all template parameters.

Finally the floor binary operator would be useful due to the ugly behavior of the round parameter in most cases (notably when computing modulos. See en:Template:Mod where modular artithmetic is really ugly to use, and it would be simpler with a floor operator instead of a round operator (I've seen various computation bugs caused by negative values, or by incorrect roundingwhere someone used +0.5 instead of -0.5 in the expression. This adds unnecessary operations to perform by the parser, or requires complexoptimization to "simplify" the expressions and save computation time.

86.207.229.152 18:55, 2 May 2006 (UTC)

Strange cache type behaviour

I've got the extension installed on my local machine and I've tried adding my own function hooks. As part of the process I added some logging code to help debugging. Everything works fine but the functions seem to be getting called much more than I would expect, even when I view pages with no templates or parser functions its still registering calls to my functions. It seems like some stored version of the last template is being called. I'm using MediaWiki: 1.6.3, with ParseFunctions, and no cache support. --Salix alba 17:11, 7 May 2006 (UTC)

Help Wanted again!!

I believe this is a known problem

I wrote a template called "From" as follows:

__NOEDITSECTION__

{{ #if: {{{1}}} |'''From ''' [[:Category:{{{1}}} | {{{1}}}]] [[Category:{{{1}}}]] }}

{{ #if: {{{2}}} |, [[:Category:{{{2}}} | {{{2}}}]] [[Category:{{{2}}}]] }}

{{ #if: {{{3}}} |, [[:Category:{{{3}}} | {{{3}}}]] [[Category:{{{3}}}]] }}

{{ #if: {{{4}}} |, [[:Category:{{{4}}} | {{{4}}}]] [[Category:{{{4}}}]] }}

{{ #if: {{{5}}} |, [[:Category:{{{5}}} | {{{5}}}]] [[Category:{{{5}}}]] }}

When I call it with 5 parameters it is all OK, but

When calling it with three parameters as follows:

{{From | Ángel Gregorio Villoldo | Angel Labruna | pepe soriano}}

I get

From Ángel Gregorio Villoldo , Angel Labruna , pepe soriano , [[:Category:{{{4}}} | {{{4}}}]] :[[Category:{{{4}}}]] , [[:Category:{{{5}}} | {{{5}}}]] [[Category:{{{5}}}]]

Which is wrong. I've tried many work arounds like adding an   as"else" in this way:

{{ #if: {{{2}}} |, [[:Category:{{{2}}} | {{{2}}}]] [[Category:{{{2}}}]] |  }}

but it didn't work. Seems to bw that this function has some problems with empty parameters.

I believe that using named parameters might be the solution but I need unnamed parameters.

If anybody knows how to cope this issue please, let me know.

Use #if: {{{1|}}} etc.--Patrick 18:22, 8 May 2006 (UTC)

I did it but the result is one and the same.

Did you try it or it was just a guess?

It works for w:Template:Tlx. -- Omniplex (w:t) 12:39, 9 May 2006 (UTC)

Unrelated, why does {{tiw|tlx}} fail, I'll check it.

Use {{tiw|en|tlx}}: w:en:Template:Tlx.--Patrick 13:10, 9 May 2006 (UTC)

Yes, now w:en:Template:Tiw should work again (see talk page, I broke it months ago). -- Omniplex (w:t) 06:53, 16 May 2006 (UTC)

Odd parameter bug

The {{en:before}} template used to work fine in en, but I noticed a problem today. I tried some workarounds and other ideas, but I think it's a (new) bug with the #ifexpr: function.

Please see the following templates:

• en:Template:before
• en:User:Ed Poor/bigger

I got {{{3}}} or {{{4}}} as a result, instead of the values of the parameters. What's going on? --Ed Poor 15:56, 15 May 2006 (UTC)

Unbalanced curly brackets (guessing):

{{#ifexpr: ({{date serial|{{{1|}}}|{{{2|}}}}} - {{ordinal date}}) > 0|{{{3|}}}|{{{4|}}}}}
12..........34............567..654.567..65432...34............32......345..432.345..43210

No, that's fine. My negative result won't help you, but maybe it helps others when they try to solve this puzzle. -- Omniplex (w:t) 07:11, 16 May 2006 (UTC)

Replace {{{ with [ and }}} with ] for thinking:

{{#ifexpr: ({{date serial|[1|]|[2|]}} - {{ordinal date}}) > 0|[3|]|[4|]}}

Patrick fixed the bug on en:Template:before --Ligulem 13:15, 16 May 2006 (UTC)