In response to a campaign by users of the English Wikipedia to harrass developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions. There are two conditional functions and a mathematical expression function. The expression function should support uses such as time and date deltas, as well as floating point applications such as unit conversion. The conditional functions should replace most uses of {{qif}}, and improve the efficiency of similar templates.
Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
I would like to hear comments about the syntax, before we put them live. Syntax is guided by consistency with existing functions such as {{localurl:}}, but if it looks too unwieldy then we can probably change it.
Don't blame me. I've always been against turning wikitext into a programming language. I'm just weaker than the other developers. How can I stand by and watch this sort of thing be inflicted on our articles:
http://en.wikipedia.org/w/index.php?title=User:Ed_Poor/subtract&action=e...
I had a choice between going on a deletion rampage or answering the persistent calls on the wiki for this kind of thing to be implemented.
Templates, that's where it all went wrong. Or custom messages, as we called them back then. If only I understood what a Pandora's box I was opening when I implemented {{MSG:}}.
http://mail.wikipedia.org/pipermail/wikitech-l/2003-September/018536.html
-- Tim Starling
On 05/04/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
In response to a campaign by users of the English Wikipedia to harrass developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions.
Where are we going, and what's with the handbasket?
Rob Church
On Wed, Apr 05, 2006 at 04:14:31PM +0100, Rob Church wrote:
On 05/04/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
In response to a campaign by users of the English Wikipedia to harrass developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions.
Where are we going, and what's with the handbasket?
Hee.
Cheers, -- jra
On 4/5/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Don't blame me. I've always been against turning wikitext into a programming language.
Why?
Steve
On 05/04/06, Steve Bennett stevage@gmail.com wrote:
On 4/5/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Don't blame me. I've always been against turning wikitext into a programming language.
Why?
Because the idea of wikitext is to make editing as simple as possible for Joe User who clicks Edit. Joe User who, perhaps, doesn't know what HTML is.
Rob Church
And he shouldn't know - but the wikitext as programming language is used only in the templates, not in the pages. (Should be used only there, at least.)
Rob Church wrote:
On 05/04/06, Steve Bennett stevage@gmail.com wrote:
On 4/5/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Don't blame me. I've always been against turning wikitext into a programming language.
Why?
Because the idea of wikitext is to make editing as simple as possible for Joe User who clicks Edit. Joe User who, perhaps, doesn't know what HTML is.
Rob Church _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Rotem Liss wrote:
And he shouldn't know - but the wikitext as programming language is used only in the templates, not in the pages. (Should be used only there, at least.)
It might therefore be a good idea to only evaluate formulae and conditional expressions to work within templates, and to simply treat them as plain text anywhere else. Templates using these programming features can then be treated by most users as "magic spells" that work automagically, without needing to learn these advanced features.
-- Neil
Neil Harris wrote:
It might therefore be a good idea to only evaluate formulae and conditional expressions to work within templates, and to simply treat them as plain text anywhere else. Templates using these programming features can then be treated by most users as "magic spells" that work automagically, without needing to learn these advanced features.
Most of the 'template coders' I know go to pains to use the existing conditional kludges that way and I can't imagine built-in functionality will be treated any differently. The goal is always to make the 'end product' in the article itself as simple as possible.
While people complain about the complexity which templates have taken on it is worth noting that there is a direct correlation between increasing template complexity/functionality and decreasing article complexity. Tables no longer have to be convoluted HTML or wiki-markup blocks in the article themselves... they've been replaced by a short template call. And conditional logic has made it so that the average user can insert one of those templates into an article and fill out the parameters to produce a perfect table without needing to understand the underlying table code at all. That wasn't possible previously... they ''had'' to know table markup (or HTML) in order to edit tables.
Yes, templates, parameters, and the 'parameter default' have been expanded out into a 'programming language' of sorts... greatly simplifying and enriching things for the average Wikipedian in the process. Yes, the various 'date math' features are painfully convoluted... but they have made it possible to automatically display tomorrow's or next month's 'of the day' material... thereby aiding in efforts to verify that it will display properly when the official day comes. They have added the ability to go to dated content for the 'next day' or 'prior day'... creating improved browsing capabilities. Et cetera.
Complexity and increased functionality are GOOD. Yes, they require 'programmers' to understand / implement them... but they can be used by those programmers to make complicated / previously impossible things simple for everyone to use.
On 4/5/06, Conrad Dunkerson conrad.dunkerson@worldnet.att.net wrote:
While people complain about the complexity which templates have taken on it is worth noting that there is a direct correlation between increasing template complexity/functionality and decreasing article complexity. Tables no longer have to be convoluted HTML or wiki-markup blocks in the article themselves... they've been replaced by a short template call. And conditional logic has made it so that the average user can insert one of those templates into an article and fill out the parameters to produce a perfect table without needing to understand the underlying table code at all. That wasn't possible previously... they ''had'' to know table markup (or HTML) in order to edit tables.
I think this is the most important thing people need to understand about template complexity: by making the *template* complex, we're making the articles *simpler* and easier to maintain.
-L
Moin,
On Thursday 06 April 2006 00:52, Locke Cole wrote:
On 4/5/06, Conrad Dunkerson conrad.dunkerson@worldnet.att.net wrote:
While people complain about the complexity which templates have taken on it is worth noting that there is a direct correlation between increasing template complexity/functionality and decreasing article complexity. Tables no longer have to be convoluted HTML or wiki-markup blocks in the article themselves... they've been replaced by a short template call. And conditional logic has made it so that the average user can insert one of those templates into an article and fill out the parameters to produce a perfect table without needing to understand the underlying table code at all. That wasn't possible previously... they ''had'' to know table markup (or HTML) in order to edit tables.
I think this is the most important thing people need to understand about template complexity: by making the *template* complex, we're making the articles *simpler* and easier to maintain.
And it also changes the "you can edit anything" to "you can edit articles. For most templates, please study computer science and a real programming language for a year and then come back".
Best wishes,
Tels
On Thu, Apr 06, 2006 at 06:47:32PM +0200, Tels wrote:
I think this is the most important thing people need to understand about template complexity: by making the *template* complex, we're making the articles *simpler* and easier to maintain.
And it also changes the "you can edit anything" to "you can edit articles. For most templates, please study computer science and a real programming language for a year and then come back".
I believe you think that's a valid argument.
Please see my comments yesterday concerning penalizing the smart people in favor of the stupid.
Cheers, -- jra
On 4/6/06, Tels nospam-abuse@bloodgate.com wrote:
And it also changes the "you can edit anything" to "you can edit articles. For most templates, please study computer science and a real programming language for a year and then come back".
That would be ok. Some of the more complex existing templates (notably, that babel one that lists all languages and their language codes or something) require you to have spent 6 months meditating in a Tibetan monastery and achieving inner peace.
Seriously, I don't understand the argument against a more advanced template language. 1. We currently have evilly complex templates that no one in their right mind would go poking at. These would become simpler. 2. Anyone who wants to write a userbox template is not going to be discouraged by the existence of more advanced commands (ok, that's an argument against it). 3. Anyone who has the misfortune to see the inner workings of a complex template may actually survive the experience if it uses sane code with real expressions, rather than ways of tricking the parser into doing things it really, really doesn't want to do. And that person may actually be able to maintain or improve that template!
Steve
Rotem Liss wrote:
And he shouldn't know - but the wikitext as programming language is used only in the templates, not in the pages. (Should be used only there, at least.)
Rob Church wrote:
On 05/04/06, Steve Bennett stevage@gmail.com wrote:
On 4/5/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Don't blame me. I've always been against turning wikitext into a programming language.
Why?
Because the idea of wikitext is to make editing as simple as possible for Joe User who clicks Edit. Joe User who, perhaps, doesn't know what HTML is.
But Joe User still needs to plug information into the template. Or in the course of ordinary editing he runs into a template which is not suitable to his subject, but it's beyond his technical capacity to trace the problem. It's easy to say that he should ask someone more experienced in thee things, but that detracts from his editing experience and the genuine value that he has as a content provider.
I can understand how techies can sit back and narcissistically admire their own creations or clever tricks to develop a uniform or standardized image of everything that fits or can fit. To be sure, there is something aesthetically pleasing about that uniformity and order, but that does shut out a broad range of people who would prefer not to deal with such minutiae. Joe Editor is comfortable with what he knows. He accepts that he must learn a minimum range of wiki markup to do his work effectively. Beyond that any announcement of improvements is a serious cause for concern.
This is difficult enough for Jou Users who work primarily in developed languages where a high degree of educational skill is the norm. Many of those editors have already adapted to some of those changes over time. It is difficult to see how we can progress in less developed societies and languages where technical experience is not the norm unless we make big allowances for non-technical approaches.
Ec
On Wed, Apr 05, 2006 at 06:32:01PM -0700, Ray Saintonge wrote:
Date: Wed, 05 Apr 2006 18:32:01 -0700 But Joe User still needs to plug information into the template. Or in the course of ordinary editing he runs into a template which is not suitable to his subject, but it's beyond his technical capacity to trace the problem. It's easy to say that he should ask someone more experienced in thee things, but that detracts from his editing experience and the genuine value that he has as a content provider.
That sounds like an argument in favor of penalizing smart users at the expense of stupid users -- worse, making it harder for the smart users to *help* the stupid users.
That way lies madness, and sweaty palms.
Cheers, -- jra
Jay R. Ashworth wrote:
On Wed, Apr 05, 2006 at 06:32:01PM -0700, Ray Saintonge wrote:
Date: Wed, 05 Apr 2006 18:32:01 -0700 But Joe User still needs to plug information into the template. Or in the course of ordinary editing he runs into a template which is not suitable to his subject, but it's beyond his technical capacity to trace the problem. It's easy to say that he should ask someone more experienced in thee things, but that detracts from his editing experience and the genuine value that he has as a content provider.
That sounds like an argument in favor of penalizing smart users at the expense of stupid users -- worse, making it harder for the smart users to *help* the stupid users.
That way lies madness, and sweaty palms.
The word that describes that attitude is "arrogance". It's on a par with a politician saying, "Trust me."
As you stated elsewhere you may very well 25 years of experience in computer systems; I don't dispute that.
Others may have spent 25 years developing their experience in other areas of knowledge, with only negligible experience in computer systems. That does not make them "stupid", and should not qualify them for such insults. Without the content, the Wikipedia that you envision would be nothing more than an empty shell.
Ec
On Sun, Apr 09, 2006 at 11:58:41AM -0700, Ray Saintonge wrote:
Date: Wed, 05 Apr 2006 18:32:01 -0700 But Joe User still needs to plug information into the template. Or in the course of ordinary editing he runs into a template which is not suitable to his subject, but it's beyond his technical capacity to trace the problem. It's easy to say that he should ask someone more experienced in thee things, but that detracts from his editing experience and the genuine value that he has as a content provider.
That sounds like an argument in favor of penalizing smart users at the expense of stupid users -- worse, making it harder for the smart users to *help* the stupid users.
That way lies madness, and sweaty palms.
The word that describes that attitude is "arrogance". It's on a par with a politician saying, "Trust me."
Excuse me?
You're suggesting that *assuming users are smart enough to cope with more power in their wiki environment* is *arrogant*?
It seems to *me* that being all paternal and saying "don't put that power in there; people aren't smart enough to cope with it" is what's arrogant.
Others may have spent 25 years developing their experience in other areas of knowledge, with only negligible experience in computer systems. That does not make them "stupid", and should not qualify them for such insults. Without the content, the Wikipedia that you envision would be nothing more than an empty shell.
I made no insults.
I characterized my perception of the argument being made, and evinced my opinion on it.
If you think that's arrogance, I think you're projecting.
Cheers, -- jra
Ray Saintonge wrote:
But Joe User still needs to plug information into the template.
Yes, the ability to type is still required. We haven't simplified things THAT much. :]
Or in the course of ordinary editing he runs into a template which is not suitable to his subject, but it's beyond his technical capacity to trace the problem.
In which case they ALSO wouldn't have been able to figure out the markup which the template has replaced/simplified. No, we can't anticipate everything that every user might want to do and have a nice simple pre-packaged way of making that happen all ready for them.... but that strikes me as an illogical reason for not setting up utility templates at all.
I'll never understand the 'it might be too complex so let's not do it' argument... setting aside that this just ISN'T complicated stuff, even if it WERE it doesn't TAKE AWAY anything. All the older methods of doing things are still there. Just now there are additional ways of getting things done - and if not everyone understands those, so what? It isn't hurting the people who don't. Indeed, it helps even those who don't understand the logic because all they need to know is the name of the template to call... not how it works. You don't need to know how to build an automobile in order to drive one.
The 'we are building an encyclopedia not programming' argument is equally unmoving to me. Ok then... get rid of all HTML font settings, colors, tables, CSS, templates, et cetera. Oh, those are USEFUL for building an encyclopedia? Hmmm.... imagine that. I wonder if automatic distance conversions in articles would be useful... given that some of our readers (and editors) use imperial and some use metric? Temperature scales? Weights? The idea that people will turn this into an excuse to write full fledged programs having nothing to do with an encyclopedia seems to me silly on it's face... but suppose they would... for some unknowable reason... how many nanoseconds do you suppose something like that would last on 'templates for deletion'?
Moin,
On Thursday 06 April 2006 23:49, Conrad Dunkerson wrote:
Ray Saintonge wrote:
But Joe User still needs to plug information into the template.
Yes, the ability to type is still required. We haven't simplified things THAT much. :]
Or in the course of ordinary editing he runs into a template which is not suitable to his subject, but it's beyond his technical capacity to trace the problem.
In which case they ALSO wouldn't have been able to figure out the markup which the template has replaced/simplified. No, we can't anticipate everything that every user might want to do and have a nice simple pre-packaged way of making that happen all ready for them.... but that strikes me as an illogical reason for not setting up utility templates at all.
I'll never understand the 'it might be too complex so let's not do it' argument... setting aside that this just ISN'T complicated stuff, even if it WERE it doesn't TAKE AWAY anything. All the older methods of doing things are still there. Just now there are additional ways of getting things done - and if not everyone understands those, so what? It isn't hurting the people who don't. Indeed, it helps even those who don't understand the logic because all they need to know is the name of the template to call... not how it works.
You don't need to know how to build an automobile in order to drive one.
Software is not an automobile. That confusion is why we have so many broken and buggy programs, invalid webpages etc.
The 'we are building an encyclopedia not programming' argument is equally unmoving to me. Ok then... get rid of all HTML font settings, colors, tables, CSS, templates, et cetera. Oh, those are USEFUL for building an encyclopedia? Hmmm.... imagine that. I wonder if automatic distance conversions in articles would be useful... given that some of our readers (and editors) use imperial and some use metric? Temperature scales? Weights?
But do you really need to:
* invent yet-another-language, poorly * create yet-another-interpreter for it * create yet-another-lets-mix-data-and-code environemnt (think PHP, think javasript) for it?
I am not that against these functions. I just don't want horder of unexperienced people who think they can program because they know how to add two numbers up inject hundred or thousands little "programs" into the wikipedia. Wikipedia is a data collection. Do not turn it into a code repository.
Now I think I have said everything there is to say on that topic, about three times. So I shut up now. You have been warned :D
Best wishes,
Tels
In which case they ALSO wouldn't have been able to figure out the markup which the template has replaced/simplified.
I don't think so.
A user sees an article that contains a nice little infobox, edits the article and sees {{Infobox Foobar|maintitle=Foo|subtitle=Bar}} The user wants to have a similar infobox in another article, only with an added subsubtitle.
Remark: If the user knows nothing about templates, he has a problem already. This was one of the reasons why the "templates used on this page" list was added.
So, the user goes to Template:Infobox Foobar.
Option A: The template is a plain-old simple template containing something like {| align=right ! {{maintitle}} |- | {{subtitle}} |} The user just copies the template into [[Template:Infobox Foobar extended]] and copy&pastes a single line in the table. Only the knowledge of table syntax is required.
Option B: The template is extremely powerful, general, using complex logic with many qifs, switches, etc. and comes with a two-page usage guide. In this case, the user is lost. He might once or twice try to copy a line containing subtitle, only to find out it does not work (maybe because it was in an if branch that is used only on even Tuesdays, or he forgot to wrap that line to another template so it ended in an invisible div, or whatever).
Note that I admit there are uses to complex templates, but they _do_ add complexity and raise the bar for (novice?) users.
-- [[cs:User:Mormegil | Petr Kadlec]]
On 4/7/06, Petr Kadlec petr.kadlec@gmail.com wrote:
Option B: The template is extremely powerful, general, using complex logic with many qifs, switches, etc. and comes with a two-page usage guide. In this case, the user is lost. He might once or twice try to copy a line containing subtitle, only to find out it does not work (maybe because it was in an if branch that is used only on even Tuesdays, or he forgot to wrap that line to another template so it ended in an invisible div, or whatever).
Can you give an example of Option B? Seems to me that someone would wrapper an Option B with an Option A.
Steve
Conrad Dunkerson wrote:
Ray Saintonge wrote:
Or in the course of ordinary editing he runs into a template which is not suitable to his subject, but it's beyond his technical capacity to trace the problem.
In which case they ALSO wouldn't have been able to figure out the markup which the template has replaced/simplified. No, we can't anticipate everything that every user might want to do and have a nice simple pre-packaged way of making that happen all ready for them.... but that strikes me as an illogical reason for not setting up utility templates at all.
In many places typing in the plain text would be much simpler. Many people use templates to impose some kind of uniformity. In these situations it takes considerable effort to root out the desired template, and determine how to disagregate the content to make it fit the template.
I'll never understand the 'it might be too complex so let's not do it' argument... setting aside that this just ISN'T complicated stuff, even if it WERE it doesn't TAKE AWAY anything. All the older methods of doing things are still there. Just now there are additional ways of getting things done - and if not everyone understands those, so what? It isn't hurting the people who don't.
Fine, then nobody should bitch when someone uses plain text. It's an "older method" that remains just as valid.
The 'we are building an encyclopedia not programming' argument is equally unmoving to me. Ok then... get rid of all HTML font settings, colors, tables, CSS, templates, et cetera.
I agree there are several of those that we could easily get rid of.
Ec
On 4/5/06, Steve Bennett stevage@gmail.com wrote:
On 4/5/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Don't blame me. I've always been against turning wikitext into a programming language.
Why?
Aside from the issue of simplicity which has already been mentioned, there's the issue that as the language gets bigger, user-contributed bugs become more numerous and subtle.
Steve
Moin,
On Thursday 06 April 2006 14:40, Stephen Forrest wrote:
On 4/5/06, Steve Bennett stevage@gmail.com wrote:
On 4/5/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Don't blame me. I've always been against turning wikitext into a programming language.
Why?
Aside from the issue of simplicity which has already been mentioned, there's the issue that as the language gets bigger, user-contributed bugs become more numerous and subtle.
Exactly, Wikipedia is an encyclopedia, not a distributed programming contest, whose ouput accidentily looks like an encyclopedia :)
Best wishes,
Tels
On Thu, Apr 06, 2006 at 06:42:51PM +0200, Tels wrote:
Exactly, Wikipedia is an encyclopedia, not a distributed programming contest, whose ouput accidentily looks like an encyclopedia :)
But, as is frequently pointed out, Mediawiki is not *only* wikipedia, even if you only take WMF projects into account.
Cheers, -- jra
Moin,
On Friday 07 April 2006 04:27, Jay R. Ashworth wrote:
On Thu, Apr 06, 2006 at 06:42:51PM +0200, Tels wrote:
Exactly, Wikipedia is an encyclopedia, not a distributed programming contest, whose ouput accidentily looks like an encyclopedia :)
But, as is frequently pointed out, Mediawiki is not *only* wikipedia, even if you only take WMF projects into account.
Yes, that was my point, too. How do you intent to distribute all the wonderfull little "code-snippets" written on wikipedia to other wikis?
Best wishes,
Tels
On 4/7/06, Tels nospam-abuse@bloodgate.com wrote:
Yes, that was my point, too. How do you intent to distribute all the wonderfull little "code-snippets" written on wikipedia to other wikis?
If they're working from a database dump, they'll be in the dump. If you meant more generally, I suppose they could be copied to meta and categorized if really useful.
-L
Moin,
On Friday 07 April 2006 10:59, Locke Cole wrote:
On 4/7/06, Tels nospam-abuse@bloodgate.com wrote:
Yes, that was my point, too. How do you intent to distribute all the wonderfull little "code-snippets" written on wikipedia to other wikis?
If they're working from a database dump, they'll be in the dump.
That would be only usefull for people who want to replicate the entire wikipedia, e.g. almost none. I was speaking about the thousand other wikis that run mediawiki.
If you meant more generally, I suppose they could be copied to meta and categorized if really useful.
So you need to re-invent software distribution for them (which was my point).
And you also need:
* testing framework * versioning * debugging * profiling * security reports, updates and packaging
If the feature is really so usefull as claimed, than we will see thousand little usefull computing templates littered all over the place. That will be messy and I don't want neither to maintain it, nor take blame when it blows up (e.g. becomes unmanageble).
I place dibs on the first Template:Virus in late 2007 :-D
Best wishes,
Tels
On Fri, Apr 07, 2006 at 11:12:22AM +0200, Tels wrote:
If the feature is really so usefull as claimed, than we will see thousand little usefull computing templates littered all over the place. That will be messy and I don't want neither to maintain it, nor take blame when it blows up (e.g. becomes unmanageble).
Luckily, you won't be responsible for that.
Not that it's actually an issue in the first place.
Cheers, -- jra
On Fri, Apr 07, 2006 at 10:43:33AM +0200, Tels wrote:
Moin,
Huh? Excuse me: "Moin is the name of another wiki software, occasionally considered to be competitive with MediaWiki. Are you using it's name here repeatedly as a form of address to be provocative?"
On Friday 07 April 2006 04:27, Jay R. Ashworth wrote:
On Thu, Apr 06, 2006 at 06:42:51PM +0200, Tels wrote:
Exactly, Wikipedia is an encyclopedia, not a distributed programming contest, whose ouput accidentily looks like an encyclopedia :)
But, as is frequently pointed out, Mediawiki is not *only* wikipedia, even if you only take WMF projects into account.
Yes, that was my point, too. How do you intent to distribute all the wonderfull little "code-snippets" written on wikipedia to other wikis?
I'm becoming more and more certain that you're merely trolling; this question is completely orthogonal to the issue at hand, and appears to be merely intended to be provocative as well.
Cheers, -- jra
Moin,
On Friday 07 April 2006 16:02, Jay R. Ashworth wrote:
On Fri, Apr 07, 2006 at 10:43:33AM +0200, Tels wrote:
Moin,
Huh? Excuse me: "Moin is the name of another wiki software, occasionally considered to be competitive with MediaWiki. Are you using it's name here repeatedly as a form of address to be provocative?"
No, I use it as a form of greeting since like, oh, a decade.
On Friday 07 April 2006 04:27, Jay R. Ashworth wrote:
On Thu, Apr 06, 2006 at 06:42:51PM +0200, Tels wrote:
Exactly, Wikipedia is an encyclopedia, not a distributed programming contest, whose ouput accidentily looks like an encyclopedia :)
But, as is frequently pointed out, Mediawiki is not *only* wikipedia, even if you only take WMF projects into account.
Yes, that was my point, too. How do you intent to distribute all the wonderfull little "code-snippets" written on wikipedia to other wikis?
I'm becoming more and more certain that you're merely trolling;
I hope not. :-( I am writing about these issues because I see problems arise and want them to be avoided before it's to late. Handwaving and "I dont see this as a problem" will not make problems go away, and I'd rather have a discussion about potential designs and solutions _before_ they are implemented.
this question is completely orthogonal to the issue at hand, and appears to be merely intended to be provocative as well.
No, it is an issue I consider very important. There is a difference between adding something like {{yesterday}} as a feature to the mediawiki software, or creating a template for it. In the later case you get all sorts of issues, like I described earlier.
As I said before, these requested features should be added to the software side, and not be created by creating a new template-language with all the problems that arise from that.
I hope that clears it up.
Best wishes,
Tels
On Fri, Apr 07, 2006 at 04:13:05PM +0200, Tels wrote:
Moin,
Huh? Excuse me: "Moin is the name of another wiki software, occasionally considered to be competitive with MediaWiki. Are you using it's name here repeatedly as a form of address to be provocative?"
No, I use it as a form of greeting since like, oh, a decade.
Does it mean something, in one of the 25000 or so languages I don't speak?
On Friday 07 April 2006 04:27, Jay R. Ashworth wrote:
On Thu, Apr 06, 2006 at 06:42:51PM +0200, Tels wrote:
Exactly, Wikipedia is an encyclopedia, not a distributed programming contest, whose ouput accidentily looks like an encyclopedia :)
But, as is frequently pointed out, Mediawiki is not *only* wikipedia, even if you only take WMF projects into account.
Yes, that was my point, too. How do you intent to distribute all the wonderfull little "code-snippets" written on wikipedia to other wikis?
I'm becoming more and more certain that you're merely trolling;
I hope not. :-( I am writing about these issues because I see problems arise and want them to be avoided before it's to late. Handwaving and "I dont see this as a problem" will not make problems go away, and I'd rather have a discussion about potential designs and solutions _before_ they are implemented.
Ok, that's fine. But the things you say you see as potential problems just... well, I can't see how they *could* be problems -- to the people potentiall implementing the extensions *or* the people running wikis -- and I say that with almost 25 years of systems analysis and design as a background.
People will take advantage of any tool you provide them to accomplish their own work -- but there is no *global* problem of managing *those templates* (the ones which take advantage of the proposed new extensions), because they are all effectively private.
Someone may choose to *start* a repository of such scripts/templates, orthogonally to the people who create them, and subject to licensing, and that would potentially be a neat idea (though it might merely be another branch on meta), but it's not necessary to justify *adding* the extensions in any fashion that I can perceive.
this question is completely orthogonal to the issue at hand, and appears to be merely intended to be provocative as well.
No, it is an issue I consider very important. There is a difference between adding something like {{yesterday}} as a feature to the mediawiki software, or creating a template for it. In the later case you get all sorts of issues, like I described earlier.
And yet, AFAIK, {{yesterday}} *is* a template. If it isn't now, it certainly started as one, and that's the old cycle: you implement the feature you need with what you have, and if it's useful and inefficient, you then push it down into the core.
As I said before, these requested features should be added to the software side, and not be created by creating a new template-language with all the problems that arise from that.
I hope that clears it up.
It does, but I disagree with you. Your suggested approach ("everything people want should be implemented in the core, immediately") does not scale well at all, and therefore will pinch off useful development by people who *are* equipped to build complex templates, but are *not* equipped to write PHP code.
That is obviously a Bad Thing to me.
Again: it's penalising the smart people.
You haven't, as far as I can see, provided a cogent argument as to why it's good. Hopefully, I have clarified both my point of view and my perception of yours, and some other folks will also jump back on this bandwagon, that we may hear theirs as well.
Cheers, -- jra
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Jay R. Ashworth wrote:
And yet, AFAIK, {{yesterday}} *is* a template. If it isn't now, it certainly started as one, and that's the old cycle: you implement the feature you need with what you have, and if it's useful and inefficient, you then push it down into the core.
You haven't, as far as I can see, provided a cogent argument as to why it's good. Hopefully, I have clarified both my point of view and my perception of yours, and some other folks will also jump back on this bandwagon, that we may hear theirs as well.
As the person who wrote that {{yesterday}} template allow me just to say a big "ditto".
I agree that alot of this 'stuff' would be better handled in the MediaWiki software... but I'm not going to hassle the developers to implement this feature and that feature and the other feature. I take whatever they give me and use it to the limits of it's applicability. At some point, if they are useful, those implementations become widespread enough that their inefficiency is a notable issue and they are replaced with a new capability in the base system. That is happening right now for 'qif', 'calcadd', and various unit conversion templates.
Yes, we could put {{yesterday}} and {{tomorrow}} and {{leapday}} and {{NextMonth}} and {{switch}} and {{if defined call}} and all the rest of them directly into MediaWiki, but we aren't there yet... adding just Tim's proposed 'if:' and 'expr:' will vastly simplify and improve the efficiency of all these existing applications. It isn't neccessary to replace each of them with a MediaWiki equivalent right now. Maybe somewhere down the line on or more of those will become as widespread as 'qif' and warrant direct implementation, but they are fine the way they work currently and would be improved by Tim's changes.
On Fri, Apr 07, 2006 at 01:15:48PM -0400, Conrad Dunkerson wrote:
Jay R. Ashworth wrote:
And yet, AFAIK, {{yesterday}} *is* a template. If it isn't now, it certainly started as one, and that's the old cycle: you implement the feature you need with what you have, and if it's useful and inefficient, you then push it down into the core.
You haven't, as far as I can see, provided a cogent argument as to why it's good. Hopefully, I have clarified both my point of view and my perception of yours, and some other folks will also jump back on this bandwagon, that we may hear theirs as well.
As the person who wrote that {{yesterday}} template allow me just to say a big "ditto".
Glad to know I'm not a *total* moron this week. Thanks.
I agree that alot of this 'stuff' would be better handled in the MediaWiki software... but I'm not going to hassle the developers to implement this feature and that feature and the other feature. I take whatever they give me and use it to the limits of it's applicability. At some point, if they are useful, those implementations become widespread enough that their inefficiency is a notable issue and they are replaced with a new capability in the base system. That is happening right now for 'qif', 'calcadd', and various unit conversion templates.
And that capsulizes my argument: there's no scalable way to determine what extension functionality is *useful* and *desired* if there's no lighterweight way to implement it than by writing extensions directly in PHP.
That's a bug, in my estimation.
Cheers, -- jra
On Fri, 7 Apr 2006 10:02:55 -0400 "Jay R. Ashworth" jra@baylink.com wrote:
On Fri, Apr 07, 2006 at 10:43:33AM +0200, Tels wrote:
Moin,
Huh? Excuse me: "Moin is the name of another wiki software, occasionally considered to be competitive with MediaWiki. Are you using it's name here repeatedly as a form of address to be provocative?"
http://en.wikipedia.org/wiki/Moin "Moin is a Frisian language greeting from East Frisia, the eastern Netherlands, North Frisia and Flensburg, meaning hello. ..."
reinhardt [[user:gangleri]]
On Fri, Apr 07, 2006 at 02:17:01PM +0000, Reinhardt WIEWE @ torg.is wrote:
On Fri, 7 Apr 2006 10:02:55 -0400 "Jay R. Ashworth" jra@baylink.com wrote:
On Fri, Apr 07, 2006 at 10:43:33AM +0200, Tels wrote:
Moin,
Huh? Excuse me: "Moin is the name of another wiki software, occasionally considered to be competitive with MediaWiki. Are you using it's name here repeatedly as a form of address to be provocative?"
http://en.wikipedia.org/wiki/Moin "Moin is a Frisian language greeting from East Frisia, the eastern Netherlands, North Frisia and Flensburg, meaning hello. ..."
Ah.
Thanks.
Cheers, -- jra
A replacement for http://en.wikipedia.org/wiki/Template:Switch would be great.
Tim Starling wrote:
In response to a campaign by users of the English Wikipedia to harrass developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions. There are two conditional functions and a mathematical expression function. The expression function should support uses such as time and date deltas, as well as floating point applications such as unit conversion. The conditional functions should replace most uses of {{qif}}, and improve the efficiency of similar templates.
Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
I would like to hear comments about the syntax, before we put them live. Syntax is guided by consistency with existing functions such as {{localurl:}}, but if it looks too unwieldy then we can probably change it.
Don't blame me. I've always been against turning wikitext into a programming language. I'm just weaker than the other developers. How can I stand by and watch this sort of thing be inflicted on our articles:
http://en.wikipedia.org/w/index.php?title=User:Ed_Poor/subtract&action=e...
I had a choice between going on a deletion rampage or answering the persistent calls on the wiki for this kind of thing to be implemented.
Templates, that's where it all went wrong. Or custom messages, as we called them back then. If only I understood what a Pandora's box I was opening when I implemented {{MSG:}}.
http://mail.wikipedia.org/pipermail/wikitech-l/2003-September/018536.html
-- Tim Starling
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Rotem Liss wrote:
A replacement for http://en.wikipedia.org/wiki/Template:Switch would be great.
There's a number of uses of {{switch}} that I'd rather not encourage. For example, implementing a mini-database of different texts within a single template:
http://en.wikipedia.org/w/index.php?title=Template:Lorem_Ipsum&action=ed...
This would be much better handled by splitting it into 5 different templates, from a server resource viewpoint. This is true regardless of the implementation of switch. Another example:
http://en.wikipedia.org/w/index.php?title=Template:Mod_24&action=edit
This can thankfully be replaced by a mathematical expression, which is many, many times faster than any conceivable switch implementation. Generally speaking, {{switch}} is often used to implement functions which can now be better dealt with by writing PHP extensions. I didn't just introduce 3 new functions, I also introduced an extension mechanism allowing people to write more.
This one: http://en.wikipedia.org/w/index.php?title=Template:Db-meta&action=edit
could be replaced with something involving {{expr:{{NAMESPACEINDEX}}%2}} if someone just created the variable {{NAMESPACEINDEX}}.
Same with this, more or less http://en.wikipedia.org/w/index.php?title=Template:TALKSPACE&action=edit
I'm willing to hear a case for the use of switch, but I'm not convinced of its utility based what I've seen.
-- Tim Starling
On Thu, 06 Apr 2006 02:02:04 +1000 Tim Starling t.starling@physics.unimelb.edu.au wrote:
I'm willing to hear a case for the use of switch, but I'm not convinced of its utility based what I've seen.
-- Tim Starling
http://epov.org/wd-gemet/index.php/Template_talk:user_native_speaker_level#s... Is about *(re-)designing* the Babel templates.
It is *not* intended to use the templates http://epov.org/wd-gemet/index.php/Template_talk:user_lang#step_by_step on *every* user page.
As soon as the texts are available and Bug 2777: request for a {{substall:foo}} beside {{subst:bar}} is a vailable a bot can regenerate all Babel templates.
Unfortunatelly I can not show you the 120 hour work done on Rob's previous test wiki "Dev-HEAD". In order to identify the font-family, font-size parameters for about 80 languages using scripts other then 10pt I used {{switch}} at all levels: direction font-family font-size sample-text-short sample-text-long
One could see acceptable fonts for the 80 language codes.
Onece the requirements for displaying multiscript / multilanguage text on *one* page one can start the discussion what markup is required for simple users.
reinhardt [[user:gangleri]]
Tim Starling wrote:
I'm willing to hear a case for the use of switch, but I'm not convinced of its utility based what I've seen.
It's syntactic sugar for a series of conditionals. I used to recommend {{switch}} over {{qif}} for performance reasons, since multiple calls to qif can often be replaced with one switch, but I doubt it makes as much difference in the new implementation. Still, switch is often more readable, and having it would make converting existing templates easier.
Tim Starling wrote:
Rotem Liss wrote:
A replacement for http://en.wikipedia.org/wiki/Template:Switch would be great.
There's a number of uses of {{switch}} that I'd rather not encourage. [snip]
Same with this, more or less http://en.wikipedia.org/w/index.php?title=Template:TALKSPACE&action=edit
I'm willing to hear a case for the use of switch, but I'm not convinced of its utility based what I've seen.
I created {{TALKSPACE}} and its counterpart {{ARTICLESPACE}} after requesting the equivalent variables several times on this list.
I would be more than happy to see them replaced with the equivalent variables now that they seem to have proven their utility.
HTH HAND
On Thu, 6 Apr 2006 04:28:09 -0700 (PDT) Phil Boswell phil.boswell@gmail.com wrote:
I created {{TALKSPACE}} and its counterpart {{ARTICLESPACE}} after requesting the equivalent variables several times on this list.
I would be more than happy to see them replaced with the equivalent variables now that they seem to have proven their utility.
HTH HAND
Phil
This (additional magic variables) is another story. If you start thinking how wiki knowledge propagates trough language communities how the distance between large and startup communities gets greather and greather you may ask yourself if this (core MediaWiki) is discrimantory or not. As a result functionality / infrastructure is unavailable at the majority of the projects. What I never understand is that oposition comes (mainly) from persons belonging to communities having the most benefit because "workarounds" are (already) available there, because they do not face particular problems (related to characters, fonts, scripts etc.).
The patterns about aproaching this is the same here: - "Is it good for me?" counts more then "Is it good for all?" - "If I do not need this why others should need / have it?".
reinhardt [[user:gangleri]]
On Thu, Apr 06, 2006 at 04:28:09AM -0700, Phil Boswell wrote:
I created {{TALKSPACE}} and its counterpart {{ARTICLESPACE}} after requesting the equivalent variables several times on this list.
I would be more than happy to see them replaced with the equivalent variables now that they seem to have proven their utility.
I had gathered, Phil, that those were being avoided because they were going to conflict with a planned extension and generalization of namespaces that would make Talk less special -- if I correctly understood what I read.
Cheers, -- jra
On 06/04/06, Phil Boswell phil.boswell@gmail.com wrote:
I created {{TALKSPACE}} and its counterpart {{ARTICLESPACE}} after requesting the equivalent variables several times on this list.
I would be more than happy to see them replaced with the equivalent variables now that they seem to have proven their utility.
I'm quite willing to add these magic words, but there is one question which needs answering before this happens; what should be done with a {{TALKSPACE}} or similar tag if the current namespace doesn't *have* a talk namespace?
Rob Church
Principle of least surprise: point to it anyway?
In User namespace, {{TALKSPACE}} gives "User talk:" In Magic namespace, {{TALKSPACE}} gives "Magic talk:" ?
Would it break things any worse than would be expected for that situation?
Steve
On 4/6/06, Rob Church robchur@gmail.com wrote:
On 06/04/06, Phil Boswell phil.boswell@gmail.com wrote:
I created {{TALKSPACE}} and its counterpart {{ARTICLESPACE}} after requesting the equivalent variables several times on this list.
I would be more than happy to see them replaced with the equivalent variables now that they seem to have proven their utility.
I'm quite willing to add these magic words, but there is one question which needs answering before this happens; what should be done with a {{TALKSPACE}} or similar tag if the current namespace doesn't *have* a talk namespace?
Rob Church _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 06/04/06, Steve Bennett stevage@gmail.com wrote:
Principle of least surprise: point to it anyway?
In User namespace, {{TALKSPACE}} gives "User talk:" In Magic namespace, {{TALKSPACE}} gives "Magic talk:" ?
Would it break things any worse than would be expected for that situation?
Well, I was thinking more along the lines of providing {{TALKPAGE}} and {{SUBJECTPAGE}} (and the corresponding "encoded" form) magic words.
I'd be inclined to point them back to the same namespace, for cases where the opposing namespace doesn't exist; so things *don't* break and become confused...but herein lies the whole users-get-confused problem.
Rob Church
On 4/6/06, Rob Church robchur@gmail.com wrote:
I'd be inclined to point them back to the same namespace, for cases where the opposing namespace doesn't exist; so things *don't* break and become confused...but herein lies the whole users-get-confused problem.
Ok, so what are some real world examples where this template would be used? What's an example of using that example in a template which doesn't have an accompanying talkspace? Who is likely to be see the end result first?
Steve
Rob Church wrote:
I'm quite willing to add these magic words, but there is one question which needs answering before this happens; what should be done with a {{TALKSPACE}} or similar tag if the current namespace doesn't *have* a talk namespace?
There's an internal MediaWiki function called Namespace::getTalk() that does this. It's used quite a lot, so I'd expect it'll continue to be maintained in some form. Given that, I see no reason not to expose the same behavior to users.
By the way, now that there's apparently an easy way to add "parser functions", how about that {{urlencode:}} function I've been asking for? Among other things, having it would mean we'd no longer have to create two versions of each variable, one with an "E" suffix and one without.
On Wed, 05 Apr 2006 18:27:24 +0300 Rotem Liss mail@rotemliss.com wrote:
A replacement for http://en.wikipedia.org/wiki/Template:Switch would be great.
*strong* support
zay gezunt / kveðja / gruß / salutas / best regards
reinhardt [[user:gangleri]]
Reinhardt WIEWE @ torg.is wrote:
On Wed, 05 Apr 2006 18:27:24 +0300 Rotem Liss mail@rotemliss.com wrote:
A replacement for http://en.wikipedia.org/wiki/Template:Switch would be great.
*strong* support
What would you use it for?
-- Tim Starling
Tim Starling t.starling@physics.unimelb.edu.au wrote:
Reinhardt WIEWE @ torg.is wrote:
On Wed, 05 Apr 2006 18:27:24 +0300 Rotem Liss mail@rotemliss.com wrote:
A replacement for http://en.wikipedia.org/wiki/Template:Switch would be great.
*strong* support
What would you use it for?
-- Tim Starling
For application development and template design. Please note that there are different "layers" of working with a wiki. Neither all registered users are developers nor are they providing patches.
On the other side you will find a lot of functionality not available today when you reach 20,000, 50,000, 70,000 edits in a wiki work on categorization or "travel" trough hundereds of wikies.
You will see what is efficient and what not, how fast you can implement changes in a growing wiki, find information, restructure it etc. Contributors are working in different areas, have different preferences, working methods and complementary goals.
reinhardt [[user:gangleri]]
Tim Starling wrote:
In response to a campaign by users of the English Wikipedia to harrass developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions. There are two conditional functions and a mathematical expression function. The expression function should support uses such as time and date deltas, as well as floating point applications such as unit conversion. The conditional functions should replace most uses of {{qif}}, and improve the efficiency of similar templates.
Of course, the moment I get my XML converter working reasonably well, you have to go ahead and extend the syntax! ;-)
OTOH, why not think this through till the bitter end? Let's implement a whole programming language! What about WikiScript? Or a Perl implementation: Wiki + Perl = Wirl! It would be slow, but you could use wiki markup & HTML for the comments.
Sorry.
Magnus
Moin,
On Wednesday 05 April 2006 22:57, Magnus Manske wrote:
Tim Starling wrote:
In response to a campaign by users of the English Wikipedia to harrass developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions. There are two conditional functions and a mathematical expression function. The expression function should support uses such as time and date deltas, as well as floating point applications such as unit conversion. The conditional functions should replace most uses of {{qif}}, and improve the efficiency of similar templates.
Of course, the moment I get my XML converter working reasonably well, you have to go ahead and extend the syntax! ;-)
OTOH, why not think this through till the bitter end? Let's implement a whole programming language! What about WikiScript? Or a Perl implementation: Wiki + Perl = Wirl! It would be slow, but you could use wiki markup & HTML for the comments.
Sorry.
A wiki can already viewed as a collection of large programs:
* artikle = program with input (the wiki text) and output (the HTML) * executed by running it in the browser, output is cached as to not "run" the program if the output wouldn't change (clever!) * template = subroutine, takes input, outputs something different * params to subroutines (templates) * default params to subroutines (templates) * recursion (template includes itself, is that already possible?)
You can then view a wiki as a collection of programs (artikles) and subroutines (templates, some of them are used in multiple programs).
Now add conditional templates, and you got suddenly conditional subroutine execution.
I guess adding loops is not far away, and at that point it would be turing complete.
10 print "Hello World!" 20 goto 10
isn't that much different from:
Hello World! {{ {{{ARTICLENAME}}} }}
(No idea if that actually works, but one might imagine it)
:-)
Best wishes,
Tels
On Wed, 5 Apr 2006 23:28:16 +0200 Tels nospam-abuse@bloodgate.com wrote:
Moin, ...
- recursion (template includes itself, is that already possible?)
... Tels
MediaWiki has a build in recursion detection. This should not be touched because of vulnerability due to infinite loops. The last occurence I noticed was reported to Brion in spring / summer 2005.
reinhardt [[user:gangleri]]
Tim Starling wrote:
Don't blame me. I've always been against turning wikitext into a programming language. I'm just weaker than the other developers. How can I stand by and watch this sort of thing be inflicted on our articles:
http://en.wikipedia.org/w/index.php?title=User:Ed_Poor/subtract&action=e...
Oh my god! Is there no common sense in the English Wikipedia? Don't you have no community procedures to stop people from doing this?
I must admit that I am guilty of introducing the if-template into the German Wikipedia. There are some useful applications but the number of complex applications that don't improve the quality of Wikipedia content nor the the readability (and writability!) of Wikimarkup a tiny bit is growing. At least you can (more or less) catch the weed with Special:Whatlinkshere. In most cases someone just translates a cool-looking template from the English Wikipedia and you have to remove it afterwards. I don't complain about this "pollution" but *please* don't encourage people to create complex templates. I know they do it with good intent but that does not make it better. If there is a feature, solutions will be created for problems we actually don't have.
My comments/wishes if you activate ParserFunctions:
* Make it usable in the template namespace only
* Give a way to get a list of templates using ParserFunctions so you can tidy up brain-dead-templates
* Only activate the if-construct. You can use it for optional parameters in templates. This is the only useful application that I can think of. We don't have calculating Templates in German Wikipedia and we don't need it. Of course you /could/ find an application but It does not balance out the growth in complexity.
* pray that your local wiki community will establish rules where to use templates and where not to use them. Quick suggestion:
"Templates should be easy to understand and easy to use. They should make creation of qualitative content easier. If you use a template just to get a smart design or a amazing logic then something is wrong. Not everything possible makes sense. If you cannot describe the purpose and usage of your template in three sentences then something ist wrong. In doubt just don't create the template. Wikipedia is not a playground for template-designers."
Greetings, Jakob
On 4/6/06, Jakob Voss jakob.voss@nichtich.de wrote:
- Make it usable in the template namespace only
I think that could be a reasonable restriction. Template code already tends to be messy, and these new functions might actually make it cleaner in a few cases. But I'd rather not see calculation functions and such used in the article namespace.
As for the syntax, might it make sense to use a double colon instead of a single colon, e.g. {{if:: <condition> | <then text> | <else text> }}? I'm not a big fan of the semantic overload we have with single colon prefixes.
Erik
On 4/5/06, Erik Moeller eloquence@gmail.com wrote:
On 4/6/06, Jakob Voss jakob.voss@nichtich.de wrote:
- Make it usable in the template namespace only
I think that could be a reasonable restriction. Template code already tends to be messy, and these new functions might actually make it cleaner in a few cases. But I'd rather not see calculation functions and such used in the article namespace.
This would be a bad idea, specifically, because it wouldn't allow people to make tests in their userspace sandbox(es). Better to allow it to be used anywhere, and let individual projects develop policies to limit or restrict it's use.
-L
Locke Cole wrote:
On 4/5/06, Erik Moeller eloquence@gmail.com wrote:
On 4/6/06, Jakob Voss jakob.voss@nichtich.de wrote:
- Make it usable in the template namespace only
I think that could be a reasonable restriction. Template code already tends to be messy, and these new functions might actually make it cleaner in a few cases. But I'd rather not see calculation functions and such used in the article namespace.
This would be a bad idea, specifically, because it wouldn't allow people to make tests in their userspace sandbox(es). Better to allow it to be used anywhere, and let individual projects develop policies to limit or restrict it's use.
-L
Okay then: support its use in template, MediaWiki and user namespaces: just not in any other namespaces. Problem solved.
It _has_ to be a programmatic restriction, or people will inevitably ignore it, and present a fait accompli through usage.
-- Neil
Neil Harris wrote:
Okay then: support its use in template, MediaWiki and user namespaces: just not in any other namespaces. Problem solved.
It _has_ to be a programmatic restriction, or people will inevitably ignore it, and present a fait accompli through usage.
Why?
Seriously. I can't think of a single case of 'qif' being used directly in an article. Why would people use Tim's 'if' replacement differently?
Mind you - I agree that we wouldn't want people to be using these capabilities directly on most pages. I just don't think they would... because they don't currently.
On 4/5/06, Neil Harris neil@tonal.clara.co.uk wrote:
Okay then: support its use in template, MediaWiki and user namespaces: just not in any other namespaces. Problem solved.
It _has_ to be a programmatic restriction, or people will inevitably ignore it, and present a fait accompli through usage.
Again, I think we should defer to individual projects and not impose it as developer mandate. If individual projects want it turned off in specific namespaces, let them decide. The decision shouldn't be made arbitrarily here on a mailing list.
-L
On Thu, 6 Apr 2006 02:14:30 +0200 "Erik Moeller" eloquence@gmail.com wrote:
On 4/6/06, Jakob Voss jakob.voss@nichtich.de wrote:
As for the syntax, might it make sense to use a double colon instead of a single colon, e.g. {{if:: <condition> | <then text> | <else text> }}? I'm not a big fan of the semantic overload we have with single colon prefixes.
Erik
I assume that "|" would create a lot of problems because it is restricting the use of "if" in tables and templates and lots of follow up requests would arive.
"includeonly" / "noinclude" allow inclusion of whatever wikicode. This would not be the case with "|" as "delimitor".
reinhardt [[user:gangleri]]
On Thu, Apr 06, 2006 at 02:14:30AM +0200, Erik Moeller wrote:
As for the syntax, might it make sense to use a double colon instead of a single colon, e.g. {{if:: <condition> | <then text> | <else text> }}? I'm not a big fan of the semantic overload we have with single colon prefixes.
I like that a lot; is there any reason why that would make the parser's head explode?
Cheers, -- jra
Jay R. Ashworth wrote:
On Thu, Apr 06, 2006 at 02:14:30AM +0200, Erik Moeller wrote:
As for the syntax, might it make sense to use a double colon instead of a single colon, e.g. {{if:: <condition> | <then text> | <else text> }}? I'm not a big fan of the semantic overload we have with single colon prefixes.
I like that a lot; is there any reason why that would make the parser's head explode?
It would be easy enough to require a double colon for extension functions. A single colon would still be required for older parser functions such as {{ns:}}, for backwards compatibility.
I've set up a vote on meta:
http://meta.wikimedia.org/wiki/Talk:ParserFunctions#Double_colons.3F
-- Tim Starling
Erik Moeller-3 wrote:
On 4/6/06, Jakob Voss jakob.voss@nichtich.de wrote:
- Make it usable in the template namespace only
I think that could be a reasonable restriction. Template code already tends to be messy, and these new functions might actually make it cleaner in a few cases. But I'd rather not see calculation functions and such used in the article namespace.
Is this actually workable? If a template is transcluded into an mainspace article, is the function not then being used in the main namespace?
As for the syntax, might it make sense to use a double colon instead of a single colon, e.g. {{if:: <condition> | <then text> | <else text> }}? I'm not a big fan of the semantic overload we have with single colon prefixes.
I suggested at some point using {{#if:…}} which AFAICT conflicts with nothing.
What I don't know yet is whether it is a simple matter to tell the parser to allow that, or very complicated...
I have added this suggestion to Tim's vote.
HTH HAND -- View this message in context: http://www.nabble.com/Mathematical-expressions-and-conditional-constructs%2C... Sent from the Wikipedia Developers forum at Nabble.com.
Jakob Voss wrote:
Oh my god! Is there no common sense in the English Wikipedia? Don't you have no community procedures to stop people from doing this?
- Only activate the if-construct. You can use it for optional parameters
in templates. This is the only useful application that I can think of.
I don't understand. You are (understandably) horrified by the massive 'subtract' template, but also then suggest to NOT implement Tim's 'expr' feature which would replace (and improve upon) it with a single line? Why?
I agree that the current add/subtract templates are overboard, but there are viable uses for mathematical functions. See;
http://en.wikipedia.org/w/index.php?title=Template:Yesterday&action=edit
Now, that is about as efficient as currently possible for what it does (generate yesterday's date - including month/year changeovers and leap-days), but with mathematic evaluation it could be reduced to just a few lines. More complex capabilities = less complex pages.
That kind of 'yesterday' and 'tomorrow' logic was first introduced on English Wikipedia only a couple of weeks ago, but is already used on hundreds of pages for a variety of effects (previewing 'daily' content in advance to verify that it is formatted correctly, going back to 'yesterday's main page' to find something you saw before, browsing forward and backward through pages arranged in date order, et cetera). Heavy use is fairly good indicator of 'usefullness'.
Moin,
On Thursday 06 April 2006 02:20, Conrad Dunkerson wrote:
Jakob Voss wrote:
Oh my god! Is there no common sense in the English Wikipedia? Don't you have no community procedures to stop people from doing this?
- Only activate the if-construct. You can use it for optional
parameters in templates. This is the only useful application that I can think of.
I don't understand. You are (understandably) horrified by the massive 'subtract' template, but also then suggest to NOT implement Tim's 'expr' feature which would replace (and improve upon) it with a single line? Why?
I agree that the current add/subtract templates are overboard, but there are viable uses for mathematical functions. See;
http://en.wikipedia.org/w/index.php?title=Template:Yesterday&action=edi t
Now, that is about as efficient as currently possible for what it does (generate yesterday's date - including month/year changeovers and leap-days), but with mathematic evaluation it could be reduced to just a few lines. More complex capabilities = less complex pages.
That kind of 'yesterday' and 'tomorrow' logic was first introduced on English Wikipedia only a couple of weeks ago, but is already used on hundreds of pages for a variety of effects (previewing 'daily' content in advance to verify that it is formatted correctly, going back to 'yesterday's main page' to find something you saw before, browsing forward and backward through pages arranged in date order, et cetera). Heavy use is fairly good indicator of 'usefullness'.
Just because someone needs yesterday's or tomorrow's date doesn't mean you have to introduce full mathematical expressions and function logic into templates.
Wikipedia is for content, Mediawiki for the programming logic to make it happen. Seperation of code and data! I repeat it here for you:
SEPERATE THE CODE AND DATA!
There, you made me finally yell.
One of the (more practical) reasons I can give is that other wikis might want to have the same functionality (yesterday), but do not know about the template and thus will re-invent it.
Best wishes,
Tels
Tels wrote:
Wikipedia is for content, Mediawiki for the programming logic to make it happen. Seperation of code and data! I repeat it here for you:
SEPERATE THE CODE AND DATA!
I see no problem here: the code is in the template namespace, the data is in the main namespace. Problem solved. :-)
Seriously, you seem to be advocating MediaWiki extensions (or patches) for nontrivial templates. This is all very well, except that it means anyone who wants to develop such an extension must first figure out how to set up a local MediaWiki installation, including installing MySQL and a webserver (usually Apache). And configuring those to be secure, since the default configuration for webservers tends to expose them to any hacker or spammer that happens by. And it means they must learn, even for the simplest of things, a significant subset of the MediaWiki internals, which are even worse documented than template syntax. And it means they must be much more careful, since a MediaWiki extension can screw up the system in lots of ways that a template can't.
And, once they have their fancy new extension developed, they must lobby a Wikimedia developer into installing it. Not to mention that this has to be repeated every time any new feature is added or a bug is fixed.
We have probably thousands of editors working on complex templates, such as infoboxes and the like. Only a few percent of those could develop a MediaWiki extension if they had to. And any extensions they did develop would have to be approved by the handful of Wikimedia devs. The process simply does not scale well. Templates do.
Moin,
On Thursday 06 April 2006 21:35, Ilmari Karonen wrote:
Tels wrote:
Wikipedia is for content, Mediawiki for the programming logic to make it happen. Seperation of code and data! I repeat it here for you:
SEPERATE THE CODE AND DATA!
I see no problem here: the code is in the template namespace, the data is in the main namespace. Problem solved. :-)
That still means yo do put the code in the data (aka the article space) and keep it out of the code (aka the CVS).
This totally reverses what we have learnt about software development in the past decades.
Putting software into a repository means you can cheack it out, test it, patch it, etc etc. You can also secure it. Well, you can even syntax check it.
Put the code in to the template system, and you suddenly loose all that.
Plus anybody who wants to use the same features also has to copy the code (aka the templates).
You seem still to think that if the template switch (f.i.) is added to Wikipedia, than thats enough. What about other people who also want to use that? How do you "install" the template switch into other wikis? Upgrade them? Even version them? Or compare them? What if there is a security problem? How do you notify "users" of the code you create?
I say it again: Code to code, data to data. You do no mix them, or you will have to clean up the mess you create today.
gee, I sound so old now :-(
Seriously, you seem to be advocating MediaWiki extensions (or patches) for nontrivial templates.
But wasn't the consens that the ideas behin this are trivial, but the templates are non-trivial because they are no proper code but hacks?
And yes, I advocate putting up extensions or patches for often requested features.
Either the people hacking on these templates have enough knowledge and time to work with real code, then they can create proper patches. Or they don't, and then they shouldn't maintain code. (or neither create code that has to be maintained in the future by somebody else).
This is all very well, except that it means anyone who wants to develop such an extension must first figure out how to set up a local MediaWiki installation, including installing MySQL and a webserver (usually Apache). And configuring those to be secure, since the default configuration for webservers tends to expose them to any hacker or spammer that happens by.
Nonsense, to hack or develop for wikipedia you do not need a public wiki. (my test wiki isn't public and yet I created an extension)
And it means they must learn, even for the simplest of things, a significant subset of the MediaWiki internals, which are even worse documented than template syntax.
Or they could ask a developer.
And it means they must be much more careful, since a MediaWiki extension can screw up the system in lots of ways that a template can't.
I do think you are in for a surprise here, because templates that "compute" can be far more dangerous than you think.
In addition, other people who want then to use the same feature could just download the newest mediawiki, which includes a feature they want.
Or in your scenary, they could go to wikipedia, hunt down all the little templates, and input them into their own wiki.
And, once they have their fancy new extension developed, they must lobby a Wikimedia developer into installing it. Not to mention that this has to be repeated every time any new feature is added or a bug is fixed.
We have probably thousands of editors working on complex templates, such as infoboxes and the like. Only a few percent of those could develop a MediaWiki extension if they had to. And any extensions they did develop would have to be approved by the handful of Wikimedia devs. The process simply does not scale well. Templates do.
But there are only a few really usefull features, like you said, infoboxes. You can put the co,mon ones into an extension or mediawiki feature, and real software developers will care for them, they will write testcases for them, they will be secured etc etc, e.g. everything that is done with code today.
Or you can create a big mess of little templates, all intermingled and mixed and have numerous users edit them, and easily break them.
Best wishes,
Tels
Tels wrote:
On Thursday 06 April 2006 21:35, Ilmari Karonen wrote:
This is all very well, except that it means anyone who wants to develop such an extension must first figure out how to set up a local MediaWiki installation, including installing MySQL and a webserver (usually Apache). And configuring those to be secure, since the default configuration for webservers tends to expose them to any hacker or spammer that happens by.
Nonsense, to hack or develop for wikipedia you do not need a public wiki. (my test wiki isn't public and yet I created an extension)
Neither is mine, but if I didn't have a firewall in place, the default Apache config would've been open to anyone who knew or guessed my IP.
I know about such things, of course, and so do you, but most people who would just like to create a new infobox on Wikipedia don't.
And it means they must learn, even for the simplest of things, a significant subset of the MediaWiki internals, which are even worse documented than template syntax.
Or they could ask a developer.
We don't have enough devs.
And it means they must be much more careful, since a MediaWiki extension can screw up the system in lots of ways that a template can't.
I do think you are in for a surprise here, because templates that "compute" can be far more dangerous than you think.
Are you actually arguing against Tim's new syntax here, or against some hypothetical straw-man scenario? Tim's proposal includes conditionals and simple arithmetic expressions -- it does not allow loops nor recursion. MediaWiki syntax isn't Turing-complete, and I believe there is a rather firm consensus to keep it that way.
But there are only a few really usefull features, like you said, infoboxes. You can put the common ones into an extension or mediawiki feature, and real software developers will care for them, they will write testcases for them, they will be secured etc etc, e.g. everything that is done with code today.
I don't think there's enough common logic in the various infobox templates to usefully refactor into a generic extension. Or are you proposing separate MediaWiki extensions for every single infobox, from {{taxobox}} all the way down to {{Harry Potter character}}?
And what exactly are those security risks that you think an infobox might have, with or without Tim's new syntax?
Tim Starling wrote:
Don't blame me. I've always been against turning wikitext into a programming language.
Perhaps the advanced functions should only be available in template pages, and not in ordinary articles? This would make it one programming language for semi-developers (writers of templates) and another non-programming language for articles.
Tim Starling wrote:
I would like to hear comments about the syntax, before we put them live. Syntax is guided by consistency with existing functions such as {{localurl:}}, but if it looks too unwieldy then we can probably change it.
I suppose an extension is easier to read and write and you more likely do clean programming instead of hacking around with WikiSyntax:
<conditional> <if test="">...</if> <else>...</else> </conditional>
or
<conditional> <case test="">...</case> <case test="">...</case> ... <otherwise>...</otherwise> </conditional>
and
<expr>...</expr>
Conditional constructs and mathematical expressions should not confuse the normal Wiki Syntax - we also include TeX with <math>...</math> and not with {{math:...}} or something else. <noinclude> and <includeonly> are special cases of conditional content.
Greetings, Jakob
Moin,
On Thursday 06 April 2006 16:33, Jakob Voss wrote:
Tim Starling wrote:
I would like to hear comments about the syntax, before we put them live. Syntax is guided by consistency with existing functions such as {{localurl:}}, but if it looks too unwieldy then we can probably change it.
I suppose an extension is easier to read and write and you more likely do clean programming instead of hacking around with WikiSyntax:
<conditional> <if test="">...</if> <else>...</else> </conditional>
I am going to write:
<perl> print "Hello World!\n"; </perl>
if nobody beats me to it. :D
Best wishes,
Tels
On Thu, Apr 06, 2006 at 06:44:43PM +0200, Tels wrote:
I am going to write:
<perl> print "Hello World!\n"; </perl>
if nobody beats me to it. :D
I thought someone already had, but I can't find it.
Cheers, -- jra
A time ago I made an implementation for a simlar thing for mediawiki, see http://meta.wikimedia.org/wiki/User:AzaToth/Logic
The syntax I choosed was {#[$]func$param$param#} where [$] defined $ as delimiter.
On 4/5/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
In response to a campaign by users of the English Wikipedia to harrass developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions. There are two conditional functions and a mathematical expression function. The expression function should support uses such as time and date deltas, as well as floating point applications such as unit conversion. The conditional functions should replace most uses of {{qif}}, and improve the efficiency of similar templates.
Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
I would like to hear comments about the syntax, before we put them live. Syntax is guided by consistency with existing functions such as {{localurl:}}, but if it looks too unwieldy then we can probably change it.
Don't blame me. I've always been against turning wikitext into a programming language. I'm just weaker than the other developers. How can I stand by and watch this sort of thing be inflicted on our articles:
http://en.wikipedia.org/w/index.php?title=User:Ed_Poor/subtract&action=e...
I had a choice between going on a deletion rampage or answering the persistent calls on the wiki for this kind of thing to be implemented.
Templates, that's where it all went wrong. Or custom messages, as we called them back then. If only I understood what a Pandora's box I was opening when I implemented {{MSG:}}.
http://mail.wikipedia.org/pipermail/wikitech-l/2003-September/018536.html
-- Tim Starling
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
'''Support'''. These will have many uses! I would support the idea of restricting them to template: space if needed. xaosflux
----- Original Message ----- From: "Tim Starling" t.starling@physics.unimelb.edu.au To: wikitech-l@wikimedia.org Sent: Wednesday, April 05, 2006 11:09 AM Subject: [Wikitech-l] Mathematical expressions and conditional constructs,now implemented
In response to a campaign by users of the English Wikipedia to harrass developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions. There are two conditional functions and a mathematical expression function. The expression function should support uses such as time and date deltas, as well as floating point applications such as unit conversion. The conditional functions should replace most uses of {{qif}}, and improve the efficiency of similar templates.
Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
I would like to hear comments about the syntax, before we put them live. Syntax is guided by consistency with existing functions such as {{localurl:}}, but if it looks too unwieldy then we can probably change it.
Don't blame me. I've always been against turning wikitext into a programming language. I'm just weaker than the other developers. How can I stand by and watch this sort of thing be inflicted on our articles:
http://en.wikipedia.org/w/index.php?title=User:Ed_Poor/subtract&action=e...
I had a choice between going on a deletion rampage or answering the persistent calls on the wiki for this kind of thing to be implemented.
Templates, that's where it all went wrong. Or custom messages, as we called them back then. If only I understood what a Pandora's box I was opening when I implemented {{MSG:}}.
http://mail.wikipedia.org/pipermail/wikitech-l/2003-September/018536.html
-- Tim Starling
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org