Page MenuHomePhabricator

Parser renders UI messages with up to one newline different from more
Open, MediumPublic

Description

If there is more than one newline in a message that is rendered, the parser will render line 1 and the last line separately, and the middle part in a 'para'. If more lines are used, the behaviour stays the same.

Steps to reproduce:

  1. Create [[MediaWiki:Newarticletext]] for the following cases:

a. "1 2 3\n4 5 6"
b. "1\n2\n3\n4\n5\n6"

  1. Check the way this works out when editing a non-existing page

Observations:

  • step 2 for a:

<*div class="mw-newarticletext">1 2 3
4 5 6<*/div>

  • step 3 for b:

<*div class="mw-newarticletext">1
<*p>2
3
4
5
<*/p>
6<*/div>

Expected behaviour: In a normal content page these 2 cases will render the same (<*p>1 2 3 4 5 6<*/p>
). I expect the UI messages to render the same way.


Version: 1.20.x
Severity: normal

Details

Reference
bz19226

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:38 PM
bzimport set Reference to bz19226.
bzimport added a subscriber: Unknown Object (MLST).
siebrand created this task.Jun 15 2009, 9:27 PM

Add newlines before $1 to wrapWikiMsgs of <div>s

I have seen it before for other messages.
There should be a new line after opening the <div>
Many messages also add a new line after closing.

The underlying cause is that <div>s aren't handled properly in wikitext
(as shown by case b).
Wikitext is very sensitive to newlines.

Attached:

Fixed on r61055.

Reopening. The following case still gives an unexpected result:

Message is: "1\n2\n3\n\n4\n\n5\n6"

wfMsg result is: <div>\n<p>1\n2\n3\n</p><p>4\n</p><p>5\n</p>\n6</div>

Expected result: <div><p>1\n2\n3</p>\n<p>4</p>\n<p>5\n6</p>\n</div> (location of the newlines isn't that important, the grouping of the sections going into a para *is*.

Additional information:

  • In a regular wiki page, this renders as "<p>1 2 3</p>\n<p>4</p>\n<p>5 6</p>"

In a wiki page it renders as <p>1\n2\n3\n</p><p>4\n</p><p>5\n</p>\n6</div> if surrounded by <divs>. Looks like something to fix on the parser.

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

When using wrapWikiMsg() - this suggested Nikerabbit - in example

$wgOut->wrapWikiMsg( "OpenID $1", array( 'usermerge-userdeleted', $username, $userID ) );

this is rendered into <p>...</p> which I do not want in my output, because when it is executed repeatedly, the output looks ugly due to different bigger line spacing.

Please can you explain how I can avoid this?

I want to have output as follows

line1<br/>
line2<br/>
line3<br/>
...

But using wrapWikiMsg() I can only get

<p>line1
</p>line2<p>
</p>line3<p>
</p>

Please can you assist? A plain output appears to be impossible using the suggested wrapWikiMsg() method.

set to 1.19-svn

I just noticed comment #6
I don't see why would you get some lines inside <p> but not others. You have new lines inside the username??

no, you see this also on arbitrary other pages. When I have the time, I will add more examples here.

Can we add a unit test for this?

(In reply to comment #10)

Can we add a unit test for this?

see comment #6 https://bugzilla.wikimedia.org/show_bug.cgi?id=19226#c6 as a proposal for such a test (Sorry - I am not experienced enough to write a unit test.)

sumanah wrote:

+reviewed since the patch was applied.

(In reply to comment #12)

+reviewed since the patch was applied.

When was the patch applied ? (revision number ?)

Look at comment #2 :)

(In reply to comment #14)

Look at comment #2 :)

The problem was mentioned in comment #6 https://bugzilla.wikimedia.org/show_bug.cgi?id=19226#c6

But the tag reviewed was only related to the patch of comment #1.