Last modified: 2012-03-20 16:32:50 UTC
This stems from a discussion at [[en:WP:VPT#Strange categories due to .7B.7Bfact.7D.7D tags]]. It seems from the code comments that the formatnum parser function is only supposed to apply to numeric input, but as written it will happily reformat any number anywhere in the text input. This easily mangles strip markers (see the URL above), and also causes issues if someone winds up with a wikilink in the formatnum input (e.g. "Category:Foo in 2009" becomes "Category:Foo in 2,009", possibly from something like "1234{{fact|date=April 2008}}" being passed into a template parameter that is formatnummed). Possible fixes off the top of my head: 1. formatnum could insist on its input being numeric, and either return the input unchanged or return an error if not. 2. formatnum could pull off the leading numeric text, and return anything after the first non-numeric unaltered. E.g. "1234 foo bar 5678" => "1,234 foo bar 5678". 3. The documentation and comments could be updated to define this as the expected behavior. In either the first or third cases, a workaround for the enwiki templates would be to supply both a numeric and a postscript parameter (e.g. instead of "{{infobox|pop=1234{{fact}}}}", it could be "{{infobox|pop=1234|pop ref={{fact}}}}").
Scary parser internals... assigning to Tim. :)
I would go for at least 3., and 1. if possible.
*** Bug 21178 has been marked as a duplicate of this bug. ***
I'd think (1) or (2) would break things, no? Probably users are depending someplace on $1234.56 becoming $1,234.56, or who knows what.
I fixed the strip tag breakage in r114231. I don't think formatnum should skip links, so I'm marking the bug fixed on the basis that what can be done here has been done.