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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l