Aryeh, this reaction of “We do not want to create a new parser
function for every presentational template people come up with” is
understandable. However, I understand that a character-counting parser
function in another form has been in the works for a long time but
hasn’t proven to be reliable enough to be released into the wild.
If someone could finally develop a bullet-proof character-counting
parser function, I’m quite certain that a number of valuable uses
could be found for it. That is why I encourage the writing of a parser
function over the effort of writing a developer’s version of a
template that doesn’t work very well. The only reason {val} doesn’t
work well is because it must rely upon math-based parser functions
that produce rounding errors. Having said that…
The MOS and MOSNUM community has waited seven months for a version of
{val} that works well for all numbers—even ones that are really big.
Any developer who is willing to tackle this issue, regardless of
whether it is a parser function or a revised version of {val}, would
be most welcome. However, both Jimbo Wales (in particular) as well as
Erik seemed to think the best way to leverage developer effort would
be to produce the character-counting parser function as this would
enable the production of template tools we haven’t even conceived of
yet.
On Jan 31, 2009, at 5:30 PM, Platonides wrote:
Aryeh Gregor wrote:
On Sat, Jan 31, 2009 at 7:12 PM, Platonides wrote:
{{val}} is just a presentational template.
It's trivial to create an
equivalent, fixed, parserfunction.
We do not want to create a new parser function for every
presentational template people come up with.
I know, that's the problem of such approach.
Although it could be worth to parserify a set of stable core templates.
Not only would they be faster, they would be more readable.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l