Flow was supplying an empty string as a parameter to a message, due to a bug 59198. What surprised me is the rendered HTML turned into a preformatted (typewriter-style) block. This happens because the 'flow-topic-participants' message goes through parse(), and in wikitext a leading blank formats the text as a <pre> tag. You can see this using eval.php:
echo wfMessage( 'flow-topic-participants', 2, 2, '', 'second person'
)->parse(); (note the empty string for first participant); this prints
<pre>and second person </pre>
1) Is there a way to turn off this over-aggressive parsing? It's unwanted for an i18n string you know should just be a span.
2) Is there an idiom to guard against this unintended <pre> tag generation, without making the message[1] even more complicated? E.g. we could put some zero-width Unicode character at the start.
Thanks as always in advance,
[1] 'flow-topic-participants' => '{{PLURAL:$1|$3 started this topic|{{GENDER:$3|$3}}, {{GENDER:$4|$4}}, {{GENDER:$5|$5}} and $2 {{PLURAL:$2|other|others}}|0=No participation yet|2={{GENDER:$3|$3}} and {{GENDER:$4|$4}}|3={{GENDER:$3|$3}}, {{GENDER:$4|$4}} and {{GENDER:$5|$5}}}}
S Page, 03/01/2014 03:11:
[...] This happens because the 'flow-topic-participants' message goes through parse(), and in wikitext a leading blank formats the text as a <pre> tag. [...] 2) Is there an idiom to guard against this unintended <pre> tag generation, without making the message[1] even more complicated? E.g. we could put some zero-width Unicode character at the start.
You should not have a leading space. If for some reason you need to assemble various things and the space needs to be in the message, you'll need to use the HTML entity for it.
Nemo
2014/1/3 S Page spage@wikimedia.org
Flow was supplying an empty string as a parameter to a message, due to a bug 59198. What surprised me is the rendered HTML turned into a preformatted (typewriter-style) block. This happens because the 'flow-topic-participants' message goes through parse(), and in wikitext a leading blank formats the text as a <pre> tag. You can see this using eval.php:
Is there any other wikitext besides the magic words? You could just use ->text() instead of ->parse().
I fail to see importance of this problem if it is only triggered by other bugs. Isn't it a good thing to fail in visible way so that issues are easy to detect and get fixed? -Niklas
On Fri, Jan 3, 2014 at 12:37 AM, Niklas Laxström niklas.laxstrom@gmail.comwrote:
Is there any other wikitext besides the magic words? You could just use ->text() instead of ->parse().
Great! and it's about 25% faster on my simple test. I mis-remembered that GENDER and PLURAL require parse().
Yes, the <pre> tag made the needed fix even more obvious. Garbage In, Unexpected Behavior Out :)
Thanks,
mediawiki-i18n@lists.wikimedia.org