Help talk:ParserFunctions

Archives
April 2006 – April 2006

Can we nest if-constructs?

For example like this:

{{if:: {{{title|}}}
  | {{if:: {{{author|}}}
      | {{{author}}}, {{{title}}}
      | {{{title}}}
    }}
  | no title was specified
}}

? --Ligulem 11:19, 11 April 2006 (UTC)

What about using ¦ instead of |?

Like this:

{{if:: <condition> ¦ <then text> ¦ <else text> }}

Could this help to prevent the parsing problems with table syntax? --Ligulem 11:24, 11 April 2006 (UTC)

I'd really prefer an US ASCII solution, typing raw UTF-8 on an OS and browser strongly believing in charsets with at most 256 characters would be a PITA. Or could I just say &brvbar; to get your UTF-8 proposal? -- Omniplex (w:t) 12:26, 11 April 2006 (UTC)

"&brvbar;" reminds me at escaping techniques. Please do not use "&brvbar;". Best regards Gangleri · Th · T 12:43, 11 April 2006 (UTC)

Well, it usually works on browsers supporting only Latin-1 or windows-1252. Actually it should work on any browser, it's a part of the HTML DTDs back to stoneage. Unfortunately that point is moot here, because the Mediawiki software destroys backwards compatibility by replacing UTF-8 for HTML 3.2 entities, except from &nbsp; or &#160; - otherwise I wouldn't be here, replacing nbsp entities would be too clueless. -- Omniplex (w:t) 18:46, 12 April 2006 (UTC)

Question

On the Wikipedia, why does this:

<u onmouseover="alert(document.cookie);">text</u>

Come out as:

Text (underlined)

But this:

 {{#if: 1=1|<|}}{{#if: 1=1|u onmouseover="alert(document.cookie);"|}}{{#if: 1=1|>|}}{{#if: 1=1|text|}}{{#if: 1=1|</u>|}}

Come out as:

 <u onmouseover="alert(document.cookie);">text  (not underlined, no "</u>")

?

All the best,
Nick.

A bit above, you can see my tries of implementing a replacement for qif. i came across teh same problem you do have now. As soon as you use html inside the if statements, it breaks. It simply displays the html special codes instead. --Simon Moon 06:53, 12 April 2006 (UTC)

Actually HTML is fixed now and seems to work. However, it appears the person above was wondering why he couldn't get an exploit to work? My guess would be that the lone < is translated into <, so the HTML never properly forms. The </u> is likely removed by HTML Tidy (or MW's internal sanitizer) because of the lack of an opening <u>. This is a good thing. —Locke Cole • t • c 06:57, 12 April 2006 (UTC)

FYI, I wanted to confirm that the exploit did not work. Also, I don't think HTML is fixed now - see below - because if it were fixed, then both should give the same output, because they are logically equivalent, whereas currently they do not. -- All the best, Nick.

---

text

text

---

Wrong result?

result of {{#if: 3+9-10|3+9 is 10|3+9 is not 10}}: 3+9 is 10

According to documentation, if the condition is 0 then it is considered false, and the else text is returned. But the according to expression above, the result returned is the then section although the condition is not 0. Borgx 08:37, 12 April 2006 (UTC)

You're using it wrong. =) Try {{#if: {{#expr:((3 + 9) = 10)}}|3+9 is 10|3+9 is not 10}}. Also, read the documentation for #if more closely. —Locke Cole • t • c 08:42, 12 April 2006 (UTC)

) sorry, forgot the {{#expr}}. Borgx 08:44, 12 April 2006 (UTC)

Or do:

{{#ifeq:{{#expr:3+9}}|10|3+9 is 10|3+9 is not 10}}

which gives:

3+9 is not 10

...but ...

3+7 is 10

-- All the best, Nick.

You can also use {{#if: {{#expr:3+7=10}} | 3+7 is 10 | 3+7 is not 10}} -- Tim Starling 09:41, 12 April 2006 (UTC)

Server or client?

Sorry for asking stupid question: does the computation done by Wikimedia server or by the client computer (my computer, for example) ? 134.157.5.208 08:19, 12 April 2006 (UTC)

Server. 218.215.2.197 08:42, 12 April 2006 (UTC)

Thanks, so it come to the server-client philosophy. Why we pay more for the computation on our server, when we could give the user the work load? I notice that MediaWiki have been constantly/consistently applying the rule of server computation, there must be good reasons. But I guess for simple math calculation, client computer may do it well, saving us the load on server? 134.157.5.208 08:56, 12 April 2006 (UTC)

The server needs to know the targets of links so it can register them in the database. And some clients can't do even the simplest of mathematical calculations. -- Tim Starling 09:46, 12 April 2006 (UTC)

some functions

How to implement this simple pseudocode:

if the month is April then write This is April else write This is not April

Since we can not use:

{{#if: {{CURRENTMONTHNAME}}=April|This is April|This is not April}}

Because

{{#if: {{CURRENTMONTHNAME}}=Aprils|This is April|This is not April}}

also return This is April

The only way i can think of is:

{{#if: {{#ifeq: {{CURRENTMONTHNAME}}|April|somestring|}}|This is April|This is not April}}
{{#if: {{#ifeq: {{CURRENTMONTHNAME}}|Aprils|somestring|}}|This is April|This is not April}}

How about make simple function {{#is:}} with same function as {{#ifeq:}} but returns non-empty string (character 'a' for ex) for equal condition and returns empty string for not equal condition.

So:

{{#if: {{#is: {{CURRENTMONTHNAME}}|April}}|This is April|This is not April}} will return "This is April"
{{#if: {{#is: {{CURRENTMONTHNAME}}|Aprils}}|This is April|This is not April}} will return "This is not April"

{{#if: {{#isnot: {{CURRENTMONTHNAME}}|April}}|This is not April|This is April}} will return "This is April"
{{#if: {{#isnot: {{CURRENTMONTHNAME}}|Aprils}}|This is not April|This is April}} will return "This is not April"

Borgx 09:05, 12 April 2006 (UTC)

{{#if:{{#expr:({{CURRENTMONTH}} = 4)}}|This is April|This is not April}} which produces This is April. —Locke Cole • t • c 09:18, 12 April 2006 (UTC)

Locke Cole, thanks for the answer, but I was refered to string comparison in general. Borgx 09:24, 12 April 2006 (UTC)

Okay, if you want to do the string compare, try {{#if:{{#ifeq:{{CURRENTMONTHNAME}}|April|1}}|This is April|This is not April}}

• {{#if:{{#ifeq:{{CURRENTMONTHNAME}}|April|1}}|This is April|This is not April}} produces This is not April
• {{#if:{{#ifeq:{{CURRENTMONTHNAME}}|Aprils|1}}|This is April|This is not April}} produces This is not April

We return "1" on a match so #if will equate it to "true". —Locke Cole • t • c 09:31, 12 April 2006 (UTC)

What's wrong with {{#ifeq: {{CURRENTMONTHNAME}}|April|This is April|This is not April}}? -- Tim Starling 09:33, 12 April 2006 (UTC)

Nothing actually, I assumed from the complexity of the examples that Borgx was looking for something.. complicated. :P I was probably wrong. =) —Locke Cole • t • c 12:39, 12 April 2006 (UTC)

Trial implementations

I've been rewriting the hideously complex logic code behind the Vietnamese Wikipedia's front page to use this extension's syntax instead, wherever possible. You can clearly see the difference at some of the transcluded templates, and it's working like a charm. [1] [2] I've also started to port some of the more generic logic templates to the new syntax. [3]

Someday I'll try and tackle that notorious language infobox. *shakes head in utter amazement*

 – Minh Nguyễn (talk, contribs) 09:31, 12 April 2006 (UTC)

In [4], instead of {{#if: {{{1|{{CURRENTWEEK}}}}} + 52 - 1 > 52 |{{#expr: ({{{1|{{CURRENTWEEK}}}}} + 52 - 1) mod 52}}|{{#expr: {{{1|{{CURRENTWEEK}}}}} + 52 - 1 }}}}, can't you just use {{#expr: ({{{1|{{CURRENTWEEK}}}}} + 51) mod 52}}? -- Tim Starling 10:00, 12 April 2006 (UTC)

I don't think so, because this segment of the code is used to determine which week's featured article to link to. During Week 1, the template is supposed to link to the articles for Weeks 50, 51, and 52. Simply modding the week number will make it link to Week 0, which doesn't exist. Then again, I'm horrible at math, particularly with mods, so I probably did miss several ways to make it more efficient. – Minh Nguyễn (talk, contribs) 10:31, 12 April 2006 (UTC)

I think should work:

1 week before

{{#expr: ({{{1|{{CURRENTWEEK}}}}} + 50) mod 52 + 1}} (28)

2 weeks before

{{#expr: ({{{1|{{CURRENTWEEK}}}}} + 49) mod 52 + 1}} (27)

3 weeks before

{{#expr: ({{{1|{{CURRENTWEEK}}}}} + 48) mod 52 + 1}} (26)

-- Tim Starling 10:58, 12 April 2006 (UTC)

Alright, thanks a lot! – Minh Nguyễn (talk, contribs) 11:28, 12 April 2006 (UTC)

whitespace handling

User:Ligulem/if-test-1 contains:

{{#if: {{{a|}}}|param a has value {{{a}}}}}

User:Ligulem/if-test-2 contains:

{{#if: {{{a|}}}
  | param a has value {{{a}}}
}}

(1) *-{{User:Ligulem/if-test-1|a=val_a}}- produces:

• -param a has value val_a-

which is fine, but

(2) *-{{User:Ligulem/if-test-2|a=val_a}}- produces:

• -param a has value val_a-

this is different behaviour as in en:template:qif, which ignores whitespace (general template param behaviour). How can I achieve the same as with qif, without having to write the whole template code on a single line? Writing the the whole m:template:cite book on a single line is a bit tough. --Ligulem 12:45, 12 April 2006 (UTC)

Ok. I can use comments:

User:Ligulem/if-test-3 contains:

{{#if: {{{a|}}}
  |param a has value {{{a}}}<!--
-->}}

*-{{User:Ligulem/if-test-3|a=val_a}}- then produces

• -param a has value val_a-

--Ligulem 12:51, 12 April 2006 (UTC)

I can have it trim whitespace, but are you sure that's what you want? It means you won't be able to use #if to insert spaces or line breaks. -- Tim Starling 12:58, 12 April 2006 (UTC)

For spaces, they could use   (or if it's hex, I always mix it up, ) couldn't they? Linespaces with BR? (not optimal, I agree). —Locke Cole • t • c 13:00, 12 April 2006 (UTC)

Tim, you are right. Leave it as it is. It can well be that this is better than with qif. With qif we had to do &32; for example to insert a space (as Locke writes above). --Ligulem 13:08, 12 April 2006 (UTC)

Please trim the whitespace as offered. Substituting this new function for {{qif}} without having the whitespace trimmed in the same way as for template parameters will make it much more difficult to produce legible wikitext. Also there should be no real reason why anybody should need to use this function to introduce line-breaks: if a simple space using is not suffucient then use <br />. HTH HAND —Phil | Talk 13:34, 12 April 2006 (UTC)

There's also some interaction with "*" lists; see w:User:Phil Boswell/cite book regression tests where I have simply substituted {{qif|test=…|then=…|then=…}} with {{#if:…|…|…}} and the white-space suddenly introduced has thoroughly broken the template. HTH HAND —Phil | Talk 13:39, 12 April 2006 (UTC)

Tim has done the trimming [5]. Thanks to Tim! --Ligulem 14:31, 13 April 2006 (UTC)

#ifexpr

This was something I suggested on IRC, and just wanted to document here. #ifexpr is a proposal to wrap together a call to #if and #expr in one single call. So instead of--

{{#if: {{#expr:((10 + 1) = 11)}} | 10 + 1 is 11 | 10 + 1 is not 11}}

you'd do this

{{#ifexpr: ((10 + 1) = 11) | 10 + 1 is 11 | 10 + 1 is not 11}}

The syntax would be this--

{{#ifexpr: <expression to be tested> | <true text> | <false text>}}

Your expression in #ifexpr would need to result in zero (or blank) to be considered false, and result in non-zero to be considered true. This would help reduce the complexity (and nesting) of these calls.

Thoughts? —Locke Cole • t • c 13:04, 12 April 2006 (UTC)

Yes, seems like a good idea to me. In fact, it's actually what I originally thought the new #if construct did, and it was only after reading the docs, because I was not able to get it to work that way, that I realised it was different. So yes, I'd support this. -- All the best, Nickj. 02:22, 13 April 2006 (UTC)

I'm not sure, folks would try expressions not always resulting in 1, 0, or void. -- Omniplex (w:t) 19:49, 13 April 2006 (UTC)

Anything non-zero would be true (just as the case is now with #if). —Locke Cole • t • c 20:36, 13 April 2006 (UTC)

That would be neither zero nor void, not the same logic as {{qif}} and other Parameter default tricks, but no problem for me. Further down somebody's unhappy with a defined 0, our mixture of ideas adapted from LISP, C, and what else can be explosive. -- Omniplex (w:t) 22:09, 13 April 2006 (UTC)

#switch

The #if function seems to work a treat. Could we possibly also have #switch as per {{en:template:switch}}? Currently usage is as follows:

{{switch
 |VALUE-TO-BE-TESTED
 | case: foo=hello
 | case: bar=world
 | default=Neither ''foo'' nor ''bar''
}}

where VALUE-TO-BE-TESTED is a parameter or a variable

Constraints

• The variable to switch have some constraints because the value must be able to be used as a parameter name.
  • Characters known not to work are: =|
  • There mustn't be any space between the pipe character and the first character.
• There is no fall-through (if you look at the code, you know why).
• If default is not defined, the result if no value matches will be blank.

The same constraints would apply with any luck, making it easy to convert. You might want to consider obviating the "case:" construct. HTH HAND —Phil | Talk 14:52, 12 April 2006 (UTC)

Suggested syntax

 {{#switch: ''VALUE-TO-BE-TESTED''
  | foo=hello
  | bar=world
  | Neither ''foo'' nor ''bar''
 }}

I'm having some difficulty deciding how to specify the default condition: any suggestions? HTH HAND —Phil | Talk 15:29, 12 April 2006 (UTC)

Personally I think we should keep the "case:" bit (which would also make it easier to come up with that "default" condition). Syntax would be:

 {{#switch: ''VALUE-TO-BE-TESTED''
  | case: foo=hello
  | case: bar=world
  | default: Neither ''foo'' nor ''bar''
 }}

Only the first colon would be significant as a delimeter/separator, so you'd still be able to use colons in the return value for example (same for the equal sign; only the first equal sign would be significant). For the default case, there would be no equal/test value. I do absolutely believe a switch construct is necessary though, otherwise we'll end up with nested #if's (assuming we want to ditch the switch template). —Locke Cole • t • c 22:19, 12 April 2006 (UTC)

Actually, let's expand this a bit. One of the things that bugged me about the Switch template was that there was no way to do fall-through. So how about, if there's NO equal sign, it "falls through" until it finds a case with an equal sign? Here's an updated syntax:

 {{#switch: ''VALUE-TO-BE-TESTED''
  | case: foo
  | case: bar=hello
  | case: baz=world
  | default: Neither ''foo'' nor ''bar'' nor even ''baz''
 }}

Note here that if "foo" is a match to VALUE-TO-BE-TESTED, it falls through to "case: bar=hello". Note also that you should be able to fall-through to the "default:" case as well. —Locke Cole • t • c 00:59, 13 April 2006 (UTC)

"Fallthrough" in an inherently functional (i.e. non-procedural) language seems counter-intuitive to me. What you're implementing here is a general function on a finite domain, not a procedure. I'm voting for Phil's original suggestion. -- Tim Starling 10:59, 13 April 2006 (UTC)

I wonder if what LC actually wants is to be able to specify the same outcome for two or more values without duplicating the result? So in the above, the desired result is "hello" when the input value is "foo" OR "bar", "world" if it is "baz" and the extended message otherwise. This interpretation is more appropriate to a functional language and would seem to be useful. HTH HAND —Phil | Talk 11:16, 13 April 2006 (UTC)

Exactly. —Locke Cole • t • c 11:35, 13 April 2006 (UTC)

The two concepts are equivalent, yes. But the syntax Locke Cole suggested seems to be guided by the procedural concept, not the functional one. -- Tim Starling 03:59, 14 April 2006 (UTC)

Personally, I've never understood the purpose of the : after case; it seems superfluous. How about:

 {{#switch: ''VALUE-TO-BE-TESTED''
  | case foo=hello
  | case bar=world
  | default=Neither ''foo'' nor ''bar''
 }}

Using this syntax, fallthrough would be more intuitive to express:

 {{#switch: ''VALUE-TO-BE-TESTED''
  | case foo|case bar=hello
  | case baz=world
  | default=Neither ''foo'' nor ''bar'' nor even ''baz''
 }}

Or, simplified even more:

 {{#switch: ''VALUE-TO-BE-TESTED''
  | case foo|bar=hello
  | case baz=world
  | default=Neither ''foo'' nor ''bar'' nor even ''baz''
 }}

--Algorithm 23:13, 13 April 2006 (UTC)

Locke's proposed syntax

Actually, the more I think about it, the more I like Phil's proposal, but with two minor modifications--

 {{#switch: ''VALUE-TO-BE-TESTED''
  | foo
  | bar=hello
  | baz=world
  | =Neither ''foo'' nor ''bar'' nor even ''baz''
 }}

The modifications are: 1) Change to how the default case is reached (the "=" (equal sign) at the beginning of the line). 2) Fallthrough support (detected by the lack of an equal sign). This also has the advantage of being consistant with #if (which, unlike qif, doesn't have "test", "then", or "else"). Thoughts? —Locke Cole • t • c 23:47, 13 April 2006 (UTC)

Only problem I can see is that you can't set "" as any value other than the default. Very clean, though. --Algorithm 01:07, 14 April 2006 (UTC)

Sounds quite reasonable to me, although I'll be maintaining that it's really a method for giving the same result for two different inputs rather than "fallthrough", formatting my #switch statements like this to make the point:

 {{#switch: ''VALUE-TO-BE-TESTED''
  | foo|bar = hello
  | baz = world
  | = Neither ''foo'' nor ''bar'' nor even ''baz''
 }}

I'm not sure about the default syntax but I guess if nobody can think of a better idea then I'll implement it. -- Tim Starling 04:35, 14 April 2006 (UTC)

from [Wikitech-l] ParserFunctions trial

{{#switch: VALUE-TO-BE-TESTED
 | foo|bar|bla|more = hello
 | baz = {{# world }}
 | = Neither ''foo'' nor ''bar'' nor ''bla'' nor ''more'' nor even ''baz''
}}

More details at section [[#{{# <wikisyntax> }}|{{# <wikisyntax> }}]]. Gangleri · Th · T 11:07, 14 April 2006 (UTC)

Default construct

Ok, we take Locke's syntax, and change it a bit:

{{#switch: VALUE-TO-BE-TESTED
 | foo|bar|bla|more = hello
 | baz = world
 | Neither ''foo'' nor ''bar'' nor ''bla'' nor ''more'' nor even ''baz''
}}

What I have done is that I removed the equal sign for the default construct. The idea is this: If the last section doesn't constain an equal sign, than that's a default construct. This I assume is totally disambigious, because the last section can not fall throught to a next section. This will enable for examples with a check for an empty parameter. AzaToth 22:47, 15 April 2006 (UTC)

Perhaps this would work as a switch hook (I havn't tested it, I just wrote it on the fly):

    function switchHook(&$parser){
        $args = array_slice(func_get_args(),1);
        $test = trim(array_shift($args));
        $default = "";
        $fallthrough = false;
        if(!strpos($args[-1],"="))
            $default = trim($args[-1]);
        while($arg = array_shift($args)){
            if(strpos($arg,"=")){
                list($key,$value) = explode($arg,"=",1);
                if($test == trim($key) || $fallthrough)
                    return trim($value);
            }
            elseif(trim($arg) == $test)
                $fallthrough = true;
        }
        return $default;
    }

AzaToth 16:00, 16 April 2006 (UTC)

A comment of the code to Tim, why is there a $&parser passed to the functions? no functions seems to used it. AzaToth 17:44, 16 April 2006 (UTC)

No functions use it yet. Experience has taught us that if we don't pass that parameter, extension writers will use globals instead of the current context object, thus breaking all sorts of things. -- Tim Starling 11:05, 17 April 2006 (UTC)

Question: could we make sure that we do not use newlines as a syntax element (as in the Manske tables)? So now: are the proposed syntaxes for switch such that switch constructs can theoretically be written on a single line (or all tokens on a separate line for the other extreme)? I think this would be good (I haven't checked that myself, I'm asking the inventors). --Ligulem 17:44, 16 April 2006 (UTC)

Personally, I think it's a bad idea in general to exclude any ASCII character that doesn't have to be. "|" is already lost, but there's no reason to exclude "=" or newlines. AzaToth, your example is very clean, but it requires that the default argment NEVER contain an "=", which rules out putting HTML in the default position. I think that we either need to go with Locke's idea, or keep the "case/default" structure we had earlier; e.g.:

 {{#switch: ''VALUE-TO-BE-TESTED''
  | case foo|bar=hello
  | case baz=world
  | default=Neither ''foo'' nor ''bar'' nor even ''baz''
 }}

--Algorithm 20:00, 17 April 2006 (UTC)

Yes, this is why I kept the = for the default case. Only the first equal sign is significant, others are ignored. While I dislike the problem with never being able to "switch" against an empty parameter, that can be handled easily enough with a #ifeq before the switch (and I suspect matching against empty will be fairly rare). —Locke Cole • t • c 07:43, 18 April 2006 (UTC)

testing for string non-emptyness

I am trying to do something like:

{{#if: {{#expr: {{{a|}}} or {{{b|}}} }} |a or b is not empty}}

which I mean to be that the then-string ("a or b is not empty") should be emitted if a or b are not empty (of course it doesn't work like that). How can I achieve that? Do we need a new operator for #expr to achieve this? For example "nonempty"?

{{#if: {{#expr: nonempty({{{a|}}}) or nonempty({{{b|}}}) }} |a or b is not empty}}

please consider also the "and" example:

{{#if: {{#expr: nonempty({{{a|}}}) and nonempty({{{b|}}}) }} |a and b is not empty}}

Things like that are quite common. See for example en:template:booland of en:Category:Boolean templates. --Ligulem 16:51, 12 April 2006 (UTC)

You do it like this: {{#if: {{{a|}}}{{{b|}}} || a or b is not empty}} -- Tim Starling 18:42, 12 April 2006 (UTC)

Yes, I know this transformation (we have done this with the weeble) trick. This is for the "or" case. BTW, it must be like this: {{#if: {{{a|}}}{{{b|}}} |a or b is not empty}}. The 'and' case can be done by nesting. --Ligulem 21:15, 12 April 2006 (UTC)

But how would you do that: I need a template that has two parameters a and b. if a or b or both are empty, the template should emit the string "a and b must both be nonempty" and the empty string in all other cases. The pseudo-code would be:

if (not(nonempty(a) and nonempty(b))) {
  return "a and b must both be nonempty"
}

--Ligulem 21:15, 12 April 2006 (UTC)

I guess I found a solution. User:Ligulem/if-test-5 contains:

{{#if: {{#if: {{{a|}}} | {{#if: {{{b|}}} |1}}}} ||a and b must both be nonempty}}

*-{{User:Ligulem/if-test-5}}- gives

• -a and b must both be nonempty-

*-{{User:Ligulem/if-test-5|a=xx}}- gives

• -a and b must both be nonempty-

*-{{User:Ligulem/if-test-5|b=yy}}- gives

• -a and b must both be nonempty-

*-{{User:Ligulem/if-test-5|a=xx|b=yy}}- gives

• --

Anyone a better idea? --Ligulem 21:42, 12 April 2006 (UTC)

Not a better idea (currently anyways), but this might be a bit cleaner if #ifexpr were available:

{{#ifexpr:({{#if:{{{a|}}}|1|0}} and {{#if:{{{b|}}}|1|0}})||a and b must both be nonempty}}

—Locke Cole • t • c 22:26, 12 April 2006 (UTC)

Ah. Looks nicer yes. This strongly smells like another m**a-template {{nonempty|{{{a|}}}}} containing {{#if:{{{1|}}}|1|0}}. I can already hear the hooting...:-) --Ligulem 23:24, 12 April 2006 (UTC)

OH NOES, NOT META-TEMPLATES! ;) But yes, barring an extension function, it seems like a reasonable meta-template to me. —Locke Cole • t • c 03:01, 13 April 2006 (UTC)

Notes on syntax

• Why is the "trailer" "deprected" in the sixth example?

# "{{#if: always | yes is yes | no is no }}"
# "{{#if: always |  yes is yes  |  no is no  }}"
# "{{#if: | yes is yes | no is no }}"
# "{{#if: |  yes is yes  |  no is no  }}"
# "{{#if: ||  no is no  }}"
# "{{#if: ||  no is no  | trailer as table code}}"
# "{{#if: ||  no is no
multi line text<br />
...
}}"
# "[[{{#if: always | yes is yes | no is no }}]]"
# "[[talk:{{#if: always | yes is yes | no is no }}|{{#if: always | yes is yes | no is no }}]]"
# "[[{{#if:
always
| yes is yes
| no is no
}}]]"
# "[[user:{{#if:
always
| yes is yes
| no is no
}}|{{#if:
always
| yes is yes
| no is no
}}]]"

generates:‎

1. "yes is yes"
2. "yes is yes"
3. "no is no"
4. "no is no"
5. "no is no"
6. "no is no"
7. "no is no

multi line text
..."

1. "yes is yes"
2. "yes is yes"
3. "yes is yes"
4. "yes is yes"

• Gangleri · Th · T 18:14, 12 April 2006 (UTC)

I would say the result of {{#if: || no is no | trailer as table code}} is not specified (erroneous use). As such the implementation may emit what it pleases. And what it does is fairly reasonable. But I fear I have not understood what you want to tell with that testcase. --Ligulem 22:04, 12 April 2006 (UTC)

The example is using an empty <then text>. If you look carefully at the syntax, the start, the expression, the delimiters and the fields inbetween and compare with the result you may see that you will not be able to generate "reasonable table code" with the <else text>. It is simply "blocked". Gangleri · Th · T 23:39, 12 April 2006 (UTC)

Yes. I believe I have understood that there is an empty "then-text" in {{#if: || no is no | trailer as table code}}, due to the "||". Because ParserFunctions uses "|" as a syntax element, ParserFunctions cannot be used for Manske tables (tables using the "|" as a syntax element). This is by design. This has already been said. --Ligulem 07:30, 13 April 2006 (UTC)

Here's a working example (I hope, actually a test):

	# "{{#if: always | yes is yes {{!}} no is no }}"
	# "{{ifdef | 0 | empty is empty {{!}} 0 is 0 }}"
	# "{{#if: || no is no }}"
	# "{{ifdef || isn't ifndef }}"
	# "{{#if: || no is no {{!}} trailer as table code }}"

1. "yes is yes | no is no"
2. " empty is empty | 0 is 0 "
3. "no is no"
4. ""
5. "no is no | trailer as table code"

Not pretty, but does the trick. For an #if: without else {{ifdef|test|then}} is very similar (for a void test, not for 0), and probably not slower than #if:, so maybe check out ifdef for your purposes if you want to avoid the layer violation. -- Omniplex (w:t) 04:57, 13 April 2006 (UTC)

• Thanks Omniplex for your suggestion! However I feel that a clean implementation should be implemented correctly and should not require "workarounds" of any kinds.
• If you take a look at Parser.php?revision=13540 and search for "# Split template arguments" you will find

"function getTemplateArgs( $argsString )"

• There you will see also the

"$args = explode( '|', substr( $argsString, 1 ) );"

• However "$args" is smart enough to handle the "|" pipe character(s) if it is / they are inside "[[" and "]]". Remember that "|" is used also in image syntax.
• What seems to be odd (compare with ParserFunctions.php) is that only a part of the code is transfered to

"function ifHook( &$parser, $test = '', $then = '', $else = '' )"

"function ifeq( &$parser, $left = '', $right = '', $then = '', $else = '' )"

• Whatever code exists after the first "|" character in the <else> part is lost. With other words {{#if: ...}} and {{#ifeq: ...}} are processing only a part of the code. Best regards Gangleri · Th · T 08:57, 13 April 2006 (UTC)

We can probably quibble over this for ages, but the #if: as is with three arguments test + then + else behaves consistently with ordinary templates taking three parameters: A fourth or later parameter is ignored. Allowing extraneous vbar only in else but (of course) not in then would be confusing - this stuff is supposed to work for cluelesss users.

I'd support a kludge if we split it in a hypothetical #idef: and #ifndef:, both with two arguments test + then, the latter supporting extraneous vbars. Your proposal to support it in else and not then is against my basic design instincts. -- Omniplex (w:t) 19:34, 13 April 2006 (UTC)

re: "Allowing extraneous vbar only in else but (of course) not in then would be confusing - this stuff is supposed to work for cluelesss users."

I agree that it is not symmetrical. The proper solution would be a selfexplanatory then and a selfexplanatory else. Gangleri · Th · T 23:37, 13 April 2006 (UTC)

Your later (see below) proposal {{#: what|ever}} is better than anything we discussed here. -- Omniplex (w:t) 01:05, 16 April 2006 (UTC)

minimal multiline RTL compatibility test

• looks OK

׳{{#if:
שטענדיק
| יאָ יז יאָ
| נײן יז נײן
}}׳
----
׳{{#if:
|| נײן יז נײן
}}׳

generates:‎
׳יאָ יז יאָ׳

---

׳נײן יז נײן׳

• Gangleri · Th · T 19:45, 12 April 2006 (UTC)

What means "RTL"? --Ligulem 22:08, 12 April 2006 (UTC)

"right to left" script see RTL: "Right-to-left writing, as applied in Arabic and Hebrew. See Bi-directional text and Writing system." Gangleri · Th · T 23:44, 12 April 2006 (UTC)

subst variant 19:48, 12 April 2006 (UTC)

• looks OK

׳{{subst:#if:
שטענדיק
| יאָ יז יאָ
| נײן יז נײן
}}׳
----
׳{{subst:#if:
|| נײן יז נײן
}}׳

generates:‎
׳יאָ יז יאָ׳

---

׳נײן יז נײן׳

• Gangleri · Th · T 19:48, 12 April 2006 (UTC)

asymmetry between expression parts and result parts

• If you look closer at the syntax you might discover the asymmetry between expression parts and the result parts. The expression parts may contain the "( )" "Grouping operators" but the result parts lack such "meta" constructs ("begin" / "end, "{" / "}" etc.). The "result parts" end at the "hardwired" pipe chacater; as shown above this aplies also for the "<else text>" without any need.
• My objections are not theoretical. The actual syntax can not be used to generate conditional wikitable syntax as optional table lines, variable table subdivisions etc. Gangleri · Th · T 20:11, 12 April 2006 (UTC)

I'm wondering if it might be better to use the HTML syntax for tables in these cases, anyhow. As the wikitable syntax and the ParserFunctions syntax use a similar set of characters (not to mention the template syntax), the HTML table syntax might serve to create less confusion and make the templates easier to manage. Some of the code I've written at Wikipedia has an uncanny resemblance to Lisp, as it uses a very limited set of characters for everything under the Sun, except that it's all written on one line.

I know that using the HTML syntax isn't really an answer to the objections you've brought up, but it might be more useful, since it'd be a lot easier to spot the HTML syntax in en:Template:Infobox Language, for example.

 – Minh Nguyễn (talk, contribs) 03:09, 13 April 2006 (UTC)

FWIW, I prefer pure XHTML for the most part as well. It's, IMO, easier to pick out the conditionals (and other template calls) in XHTML than it is to pick it out in table syntax. —Locke Cole • t • c 03:32, 13 April 2006 (UTC)

Plus, I've also seen a lot of infoboxes that use meta-templates just because no one thought to use XHTML. Since you can actually mix XHTML table syntax with wikitable syntax, it's just inexcusable in some of these cases. – Minh Nguyễn (talk, contribs) 07:08, 13 April 2006 (UTC)

Mediawiki is trying to promote its own table syntax. For myself I can tell that it took a while to get familiar with it. When working on an issues I would like to focus an that topic without taking care of all the "workarounds" required to implement what I was intended to do. This is why it should be still possible that anybody could use the table syntax of his / her choice. Gangleri · Th · T 10:54, 13 April 2006 (UTC)

• It should be fair to say that "{{" ... "}}" can be used as "Grouping operators". However I feel that this complicates issues and "nesting" makes the syntax less legible as it could be. For every instance of "{{#if: ...}}" / "{{#ifeq: ...}}" one or two additional templates would be required 'template:.../then' and / or 'template:.../else'. Personaly I see no simplification using these. Gangleri · Th · T 10:54, 13 April 2006 (UTC)

I just remembered

bugzilla:02777 – "Request for a {{substall:foo}} beside {{subst:bar}}"

which would conflict with "{{" ... "}}" as substitute for "Grouping operators". Gangleri · Th · T 01:01, 14 April 2006 (UTC)

AND, OR, and XOR

Why are And and OR just logical ops instead of binary ops? Like "111 AND 101 == 101" in C++ or PHP, here they should be implemented in C++ standard. Furthermore, XOR is also a needed op for completeness sake. 67.15.34.251 05:26, 13 April 2006 (UTC)Upssdr 04:45, 15 April 2006 (UTC)

XOR is proposed further up on this page (and I suspect Tim will add it soon). Regarding binary ops, the way it's implemented, I don't even know if that'd be (easily) possible. It'd be (sort of) nice to have, but I don't know if it'd be worth the effort. —Locke Cole • t • c 05:39, 13 April 2006 (UTC)

I mean those bit operators. It just take a few changes in expr.php. Like:

case EXPR_AND:
  if ( count( $stack ) < 2 ) return 'missing_operand';
  $right = array_pop( $stack );
  $left = array_pop( $stack );
  $stack[] = ( $left && $right ) ? 1 : 0;

Changing the "( $left && $right ) ? 1 : 0" into "$left & $right" is just okay. 67.15.34.251 05:26, 13 April 2006 (UTC)Upssdr 04:45, 15 April 2006 (UTC)

Why does everyone seem to think that adding XOR will make it complete? What about NAND and NOR? Logical XOR isn't implemented in C, probably because it's equivalent to conversion to boolean followed by inequality, i.e. A xor B := (A=0) != (B=0). So it's rather redundant. Bitwise operators are useful in programming, e.g. for manipulation of bitfields, but I fail to see any application in the context of writing articles. There are thousands of mathematical functions that I haven't implemented in this package, I don't understand why you would think the bitwise operators are the most significant omission. Why aren't you suggesting functions that actually have an application on Wikipedia, such as time and date functions? -- Tim Starling 10:41, 13 April 2006 (UTC)

IIRC you'd only need NAND, anything else can be built using it. XOR doesn't have this propoerty. We'd need BITXOR when we get bit operators. After some minor obstacles like Wikimedia world dominance... :-) -- Omniplex (w:t) 20:12, 13 April 2006 (UTC)

xor

I posted this on Wikipedia:Village pump, but wanted to mention it here as well. While I can't see any use for it right now, for completeness sake, it would be nice if xor were added to the logical operators. In keeping with and, or and not, I would also propose it use the word xor (as opposed to ^ if we were to use the C syntax). —Locke Cole • t • c 09:15, 8 April 2006 (UTC)

Second that, it actually does have its uses. Shouldn't be to haard to add anyways, looking at the code. --Simon Moon 09:27, 8 April 2006 (UTC)

Logical xor is equivalent to inequality, see above. -- Tim Starling 04:38, 14 April 2006 (UTC)

No. With logical xor one condition may be true (one true, one false; one false, one true), but not both (false, false; true, true). See exclusive or (specifically, see the truth table under the TOC). And FWIW, PHP does have an "xor" operator you can use for this purpose. —Locke Cole • t • c 05:24, 14 April 2006 (UTC)

Let me spell it out for you.

A	B	A equals B	A xor B
0	0	1	0
0	1	0	1
1	0	0	1
1	1	1	0

Notice any similarities between the third and fourth columns? -- Tim Starling 09:20, 14 April 2006 (UTC)

You're right. Don't know why I didn't catch that the first time. —Locke Cole • t • c 09:30, 14 April 2006 (UTC)

XOR is always useful and pre-defined operator in any programming language. Also NAND or NOR will not appear in any programming language. But I think Tim tells something fundamental to Wikipedia: any new features must help to Wikipedia. I'm just someone desiring Tim to develop a C++ compiler with PHP. :) Upssdr 04:45, 15 April 2006 (UTC)

Give a few more infomation in error message

I suppose if the position of error occurring is given, debugging will be much more conveniet especially in some long expressions, or it's better to return the source with error in bold. This is also easy to implement. Just add "$p" in expr.php after returning error message. Like:

case EXPR_AND:
  if ( count( $stack ) < 2 ) return 'missing_operand';

return 'missing_operand' to 'missing_operand "$p"' and add a few handling functions in ExprParser->error() or ExtParserFunctions->expr(). 67.15.34.251 05:59, 13 April 2006 (UTC)Upssdr 04:55, 15 April 2006 (UTC)

The position within the string isn't known at the time doOperation() is called because it isn't stored in the stack. In an expression like "2*2+3", $p points to the 3 when the multiplication is evaluated. -- Tim Starling 10:12, 13 April 2006 (UTC)

I made a terrible mistake. But the technical detail doesn't matter. It's just nice to reveal the error position for developer. You can add new lines after those 'Expression error': <br/>Error in bold: strtr( $expr, '$expr[$p]', '<b>$expr[$p]</b>') ). Upssdr 04:55, 15 April 2006 (UTC)

#nowiki:

I was thinking about something that would strip [[Wiki Markup]] out of a variable (resulting in Wiki Markup), so I decided to go ahead and try it: {{#nowiki:[[This is a random snippet]] of Wikimarkup.}} Results in: This is a random snippet of Wikimarkup.

It'll strip:

[[Links]] (as Links)
[[Piped|Links]] (as Piped)
{{Templates}} (as Templates)
{{Templates|With pipes}} (as Templates)
[www.external.com Links] (as Links)
__NOEDITSECTION__ (as null)
''Italic'' (as Italic)
'''Bold''' (as Bold)
'''''Bold italic''''' (as Bold italic)
<!-- Comments --> (as Comments)

This is the code. Thoughts? There's still an issue with table markup that I haven't sorted out. Jude(talk,contribs) 09:39, 13 April 2006 (UTC)

I can see how this might well be useful in several places. Just a couple of points:

• should [[Link|Title]] be rendered as Link or as Title?
• Should the comments be stripped out entirely, rather than simply removing the tags?

HTH HAND Phil | Talk 12:13, 13 April 2006 (UTC)

Hm. Both matters of personal preference, I think, though I agree that comments are likely not meant to be seen, it would probably be better to just strip them out entirely. I'll update the code. :-) Jude(talk,contribs) 12:25, 13 April 2006 (UTC)

Something like msgnw: skipping <noinclude> sections would be very interesting. Just in case if you're looking for new ideas, msgnw: is nice for a template docu, but not if the template has long parts which are never included. -- Omniplex (w:t) 22:21, 13 April 2006 (UTC)

usage restrictions because of other bugs

• template:inline T contains

{{#ifeq: {{lc:{{{namespace}}}}} | || {{#ifeq: {{lc:{{{namespace}}}}} | image |:image: | {{#ifeq: {{lc:{{{namespace}}}}} | category |:category: | {{lc:{{{namespace}}}}}: }} }} }}

[[{{inline|namespace=category}}foo]]
----
[[{{subst:inline|namespace=category}}foo]]

generates:‎
[[

category:foo]]

---

[[

category:foo]]

• More examples can be found at template talk:inline. Gangleri · Th · T 10:05, 13 April 2006 (UTC)

bugzilla:05121

→ bugzilla:05121 – "Facilitate bidirectional editing / readability via a trailing escape character (as "\") at the end of line"

• The bidirectional example at #using "e" as syntax delimiter should read

{{#ifeq: {{PAGENAME}} |ערשטע זײַט | הײַנט | {{א||b= demo only}}{{{mode|פּרוּװ}}} }} א

generates:‎
אפּרוּװ א

• For better readybility it would be helpfull to write this as

{{#ifeq:\
{{PAGENAME}}\
|ערשטע זײַט\
|הײַנט\
|\
{{\
א\
|\
|b= demo only\
}}\
פּרוּװ\
}}\
 א

• Note that the last line starts with a "heading" space which displays here at the right.
• When you want to edit this go to the "end of lines" (trust your browser: position the cursor in a line and press the <end of line>-key; you will be at the the right position regardless where you will "see" the cursor) and delete both the "\" and the "end of lines". Then you get this:

{{#ifeq:{{PAGENAME}}|ערשטע זײַט|הײַנט|{{א||b= demo only}}פּרוּװ}} א

generating:‎
אפּרוּװ א

• The examples are equivalent (the second is trimed); there is no practic use of this particular example; it is hard to trace hard to understand and silly. But keep in mind that "debugging" means dealing with objects "unknown" to you. Best regards Gangleri · Th · T 12:38, 13 April 2006 (UTC)

P.S. For a meaningfull example see template:inline/yi|diff=328827&oldid=328826. 12:52, 13 April 2006 (UTC)

Possible problem with value 0 for #if

Hmm. I suspect there might be a problem with #if when the condition string is "0".

Consider User:Ligulem/if-test-6 containing

{{#if: {{{a|}}} | a was specified and was set to "{{{a}}}" | a was not specified }}

And the following test cases:

*{{User:Ligulem/if-test-6}}

• a was not specified

*{{User:Ligulem/if-test-6 | a=1 }}

• a was specified and was set to "1"

*{{User:Ligulem/if-test-6 | a=0 }}

• a was specified and was set to "0"

The last test case might be a bit a surprise (and possibly a problem).

I would say, the template User:Ligulem/if-test-6 does not work as I would (intuitively) expect it, if param a has the value "0".

In User:Ligulem/work/cite web 1 I wrote an attempt to rewrite en:template:cite web using the new #if:. But I believe as I wrote it, it doesn't work if one or more of the params are set to "0" when including. I admit this is a boundary case. But en:template:qif does not have this problem, I believe.

Any ideas? Am I wrong? Can this be "fixed" by another use pattern? --Ligulem 21:21, 13 April 2006 (UTC)

You should be able to do a test with #ifeq against blank and then use the "else" space as necessary. If #ifexpr is implemented, I think #if should be turned into a simple blank/non-blank test. —Locke Cole • t • c 21:33, 13 April 2006 (UTC)

Or, as an alternative to "fixing" #if, we could add #ifdef and #ifndef which would check for the presence (or absence) of a value at all. —Locke Cole • t • c 21:35, 13 April 2006 (UTC)

I'm still puzzleing. I fear the spec (and thus the implementation) of #if should be changed to:

"If the condition is 0 or an the empty string (ignoring leading and trailing space), then it is considered false, and the else text is returned. Otherwise, the then text is returned."

But then the spec of #expr should also be changed (or there is something missing). Hrmm...

--Ligulem 21:45, 13 April 2006 (UTC)

Why would #expr need to be changed? =) It would still return 0 or 1 for conditional results; and for math functions (conversions from kilometres to miles or vice versa) it would still return integer values. For conditionals, you'd just use #ifeq and compare against 0 or 1 (as desired). —Locke Cole • t • c 22:29, 13 April 2006 (UTC)

Ok. This has nothing to do with #expr. You are right. #expr should not be changed. But #if should be changed as I wrote. Currently, it is not a handy replacement for qif. #if should be turned into a simple blank/non-blank test. --Ligulem 22:41, 13 April 2006 (UTC)

At the moment, there are several ways to circumvent this issue:

{{#if: 0{{{a|}}} | a was specified and was set to "{{{a}}}" | a was not specified }}

or

{{#ifeq: {{{a|}}} || a was not specified | a was specified and was set to "{{{a}}}"}}

--Algorithm 23:45, 13 April 2006 (UTC)

Ah. Yes. Thanks. I admit I had totally neglected that #ifeq. Apologies. --Ligulem 09:17, 14 April 2006 (UTC)

The only reason I made it so that #if treats 0 as false was to allow it to branch on the result of a #expr function. That need will be removed if I implement #ifexpr. I'll implement both changes simultaneously unless there are any objections. If any burning need remains to branch on the result of #expr (for example if the result is returned via a meta-template), then you can use #ifeq 0. -- Tim Starling 03:50, 14 April 2006 (UTC)

Cool. Thanks! No objections from me. --Ligulem 09:17, 14 April 2006 (UTC)

Wow. Tim has already implemented that: [6]. --Ligulem 09:45, 14 April 2006 (UTC)

#var

Would it be possible to provide functionality to set variables? This would be very useful when dealing with unreliable values (such as those generated by #rand). I was thinking something along the lines of {{#var:foo=bar}} which could then be referenced by {{{foo}}}. Too procedural? --Algorithm 01:17, 14 April 2006 (UTC)

Variables would be a pain to implement, since there's currently no well-defined evaluation order and keeping it that way is good for efficiency and flexibility of implementation. I think it would be more sensible to make #rand return the same result every time, for a given revision. This would hide the confusing nature of the parser cache from the user. -- Tim Starling 04:21, 14 April 2006 (UTC)

expression – additional notes

• Halló! I was wondering what sort of "mathematics" is implemented, what addional notes should be added. What is revision (php etc.) dependend and what not. Sorry if I missed somthing in the discussion.
• What types are used, are allowed and what ranges? I assume that "floating" would be an inapropriate type.
• Might there be overflows?

see: http://test.wikipedia.org/wiki/ParserFunctions

• best regards Gangleri · Th · T 10:25, 14 April 2006 (UTC)

The function uses the same mathematical behaviour as PHP. Integers are used if the input is integral, but are automatically converted to double-precision floating point numbers on overflow. Divison always produces floating-point numbers. Division by zero produces a warning in PHP, so I check for it explicitly. Floating-point overflow silently produces INF or 1.#INF depending on the system (here INF). Floating-point underflow silently rounds to zero. There is no way to specify numbers in scientific notation at present, so these situations should be rare. -- Tim Starling 10:49, 14 April 2006 (UTC)

Thanks a lot for the clarifications. Gangleri · Th · T 10:55, 14 April 2006 (UTC)

{{# <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)

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)

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 ([7]) - gough. So much for the "trial" phase... :-). --Ligulem 20:53, 15 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)

Why requesting bugzilla:05121 ?

→ bugzilla:05121 – "Facilitate bidirectional editing / readability via a trailing escape character (as "\") at the end of line"

• At the end of the section /Archive 1#Working example of if, to replace qif, using wiki pipe you can read: "There is a big drawback in this, when you have a lot of lines. In the above example, if you add like 10 lines with the if constructs and they are all empty, the result will be a lot of <br> and <p> tags. This can only be gotten around by putting them together on basically the same line. So right after the closing brackets of one if, the next opening brackets of the other. This looks ugly as hell in the template code, but will make the template work exactly as planed."

To demonstrate this see what

a{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}z

generates:‎
a

z

a{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}\
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}\
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}\
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}\
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}\
{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}z

should generate:‎
az

• This is just a "side effect" but I assume it is good style. I requested this for long list items and / or long (page) source code with mixed right to left and left to right script. However when you handle conditional content you must keep in mind that every new line is parsed and multiple newlines generate this output. Gangleri · Th · T 01:04, 15 April 2006 (UTC)

a​ ​ ​ ​ ​ ​z

foo

notes:

UTF-8 characters &amp:#8203; ZERO WIDTH SPACE - U 200B have been used here

bugzilla:02920 – "Empty templates should generate nothing instead of <p><br /></p>" is INVALID Gangleri · Th · T 03:45, 15 April 2006 (UTC)

MediaWiki rendering versus Tidy

• Below an exploit is used. It may solve Simon Moon's problem (see diff=327848&oldid=327845) but it is no "general clean solution".
• It depends / exploits Tidy; see compare with FiverAlpha:template:View
• sorry: A different template was used there. Now this is corrected and behaviour is the same. Gangleri · Th · T 18:29, 15 April 2006 (UTC)

a‎ ‎ ‎ ‎ ‎ ‎z

Gangleri · Th · T 04:19, 15 April 2006 (UTC)

Gangleri, I know this behaviour very well. This has nothing to do with ParserFunctions. This is current general behaviour of template inclusion. I've been circumventing the resulting newline by arranging it like this:

a{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{ 
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}z

I write this just to report how I solve that problem in my everyday wikiwork.

Another very common problem that has occured quite often ist that when people add a <noinclude> to templates like en:template:cite web they tend do add that on a new line, which produces a new line in the output of the inclusion. This happens a lot when people add interwiki links to templates. This is especially a pain when done wrong on a high use template. And an even greater pain when such a template is protected and this fault is done by an admin and I can't fix it due to the protection of the template (but that is a wiki-politics question which has nothing to do with the dev side of the wiki world). However, I'm not sure if the adding of the \ will significantly improve the situation as this is another construct from the "programmers" world and sure difficult to understand for the non-programmer editors.

I just write here about my experience. And I am not sure about what to do to improve the situation. As for the \ if there are no solid arguments against it, it might be help.

However, I even suspect that part of the fear that editors feel when they start editing these kind of themplates is caused by this "surprising" newline behaviour. I have already asked myself if this shouldn't simply trimmed away from the output. But before doing this, some thorough thinking and investigation would be in order. But it might help lower the barrier for editing templates containing conditional code significantly. If anybody can point me to a case were trimming away the newlines would hurt, please let me know. --Ligulem 08:04, 15 April 2006 (UTC)

Thanks Ligulem! It looks quite practical in LTR and a simple RTL example looks like this:

א{{ #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}ת

א{{ #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}{{
    #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}{{
    #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}{{
    #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}ת

The longer the statements are the more time you need to write / read / understand it. Gangleri · Th · T 12:10, 15 April 2006 (UTC)

about 'noinclude' and 'includeonly': Again it is a metter of practice. Personaly I feel that

<noinclude>wikitext noinclude_1
wikitext noinclude_1_continued</noinclude>wikitext common_part
wikitext common_part_continued<includeonly>wikitext includeonly
wikitext includeonly_continued</includeonly><noinclude>wikitext noinclude_2
wikitext noinclude_2_continued</noinclude>

could be / should be written as

<noinclude>\
wikitext noinclude_1
wikitext noinclude_1_continued\
</noinclude>\
wikitext common_part
wikitext common_part_continued\
<includeonly>\
wikitext includeonly
wikitext includeonly_continued\
</includeonly>\
<noinclude>\
wikitext noinclude_2
wikitext noinclude_2_continued\
</noinclude>

It is easier to read, mark / copy the blocks and would be much easier to edit if both LTR and RTL characters are used. Gangleri · Th · T 11:51, 15 April 2006 (UTC)

You can always use blockquote-tag, inside such tag, newlines are ignored (but then you have to add newlines by your self and hange thew margin to inherit etc.... 81.235.249.75 20:29, 15 April 2006 (UTC)

Request for string functions

Despite the great #expr function, I think string handling functions are also important and helpful to Wikipedia's editors. After looking into those PHP string functions which are really helpful, I suppose maybe the following are some:

1. chr
2. count_chars
3. ltrim
4. number_format
5. ord
6. rtrim
7. str_ireplace
8. str_pad
9. str_repeat
10. str_replace
11. str_shuffle
12. str_split
13. str_word_count
14. strcasecmp
15. strchr
16. strcmp
17. strcoll
18. strcspn
19. strip_tags
20. stripos
21. stristr
22. strlen
23. strpbrk
24. strpos
25. strrchr
26. strrev
27. strripos
28. strrpos
29. strspn
30. strstr
31. strtok
32. strtr
33. substr_compare
34. substr_count
35. substr_replace
36. substr
37. trim
38. ucfirst (implemented)
39. ucwords
40. wordwrap

I suppose this won't be a hard job, but just a normal form of function in ParserFunctions.php. If Tim thinks this is too difficult to implement, I just advise Tim to implement a few of them. Only a few will give much convenience for editors. Upssdr 05:47, 15 April 2006 (UTC)

If this is done, I strongly suggest using the ANSI C function names rather than PHPs bastardized names. :P Some of these use ANSI C names, some of them, like strcasecmp, use new names (strcasecmp appears to be identical to ANSI C's stricmp). —Locke Cole • t • c 06:56, 15 April 2006 (UTC)

Ternary operator, C names, string operators, etc.: If we really want slang let's add it, not reinvent it. -- Omniplex (w:t) 00:12, 16 April 2006 (UTC)

I don't follow: we're not reinventing anything, just suggesting functionality be exposed. —Locke Cole • t • c 02:04, 16 April 2006 (UTC)

Why I suggest these PHP functions is because they are easy to develop. No matter whether they're bastardized or ugly or disliked by you, they're always easy for Tim. Upssdr 03:40, 16 April 2006 (UTC) Also MediaWiki is not ANSI C++ compiler. Upssdr

That's nice. That has absolutely nothing to do with what I said. —Locke Cole • t • c 09:07, 16 April 2006 (UTC)

I don't intend on implementing any functions which have a worst-case performance of O(N^2) or worse in the input size. Any such function would constitute a DoS vulnerability. This rules out str_replace and friends, str_pad, str_repeat, strspn and friends, and probably others, unless their time and memory usage can be appropriately limited. Since there's no array type, I can't see the point in implementing functions which act on or return arrays, such as count_chars and str_split. -- Tim Starling 10:57, 17 April 2006 (UTC)

Request: function to convert from arabic to roman

At es: we are already using these functions to create a single {{Year}} template for navigation in the years' articles. We would like to have a function to convert arabic numbers into roman to do the links to the centuries' articles. --84.42.146.44 12:59, 16 April 2006 (UTC)

I've done the same for 960–2010 on no:; it's not much work to fill in the Roman number for each year. You do it almost automatically after a while. Jon Harald Søby 15:01, 16 April 2006 (UTC)

See also note about [[talk:WiktionaryZ#new magic words {{number:foo}} and {{value:bar}}]] at the section #localization of expressions above. 15:17, 16 April 2006 (UTC)

Solved by brute force -> es:Plantilla:Romano. --84.42.146.44 18:57, 16 April 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)

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 [8]). 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)

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)

{{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)

Rand removed?

I saw that Tim Starling has removed the random-function. So {{#rand:1|10}} will now be displayed as normal text. Is this permanent removed from the parserfunctions? I did some testing with it to display random images, and it was working fine. It was just a function I have waited for since a long time, so I was happy that it was included in the parserfunctions. JePe 12:24, 18 April 2006 (UTC)

I understand that this function was being abused and has therefore been removed; it would seem that this is likely to be permanent, which is unfortunate but apparently necessary. HTH HAND —Phil | Talk 12:41, 18 April 2006 (UTC)

I think this is unfortunate as well, and would like to see #rand brought back. Apparently there was some concern about it being used for creative vandalism (pages that randomly display a penis picture or whatever), but as most Recent Changes patrollers work via diffs, they'd see any attempt to insert a penis picture, even if it was only displayed randomly. —Locke Cole • t • c 13:28, 18 April 2006 (UTC)

Anyone smart enough to do this could easily obfuscate that. You assume every RC patroller can read understand this crap enough to recognize vandalism. -- Netoholic @ 14:09, 18 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)