Last modified: 2011-03-13 18:06:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2248 - Wrong treating of the first line of a long template parameter
Wrong treating of the first line of a long template parameter
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Lowest trivial with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser, patch, patch-need-review
Depends on:
  Show dependency treegraph
Reported: 2005-05-26 01:28 UTC by Patrick Dreyer
Modified: 2011-03-13 18:06 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Patrick Dreyer 2005-05-26 01:28:12 UTC
As statet on '' under 'Parameters',
Spaces before or after a parameter value are normally ignored.
This is wrong, because all WHITESPACES are ignored.
Actually removing the whitespaces is done by calling trim() on both the
parameter name AND the value with the following two codelines in the method
Parser::braceSubstitution(), line 2158 in MediaWiki 1.4.4:

					$name = trim( substr( $arg, 0, $eqpos ) );
					$value = trim( substr( $arg, $eqpos+1 ) );

By replacing the trimming of the parameter value with

					$value = trim( substr( $arg, $eqpos+1 ), " \0" );

the functionality will match the docs. It doesn't make sense to remove the other
whitespaces ("\n", "\r", "\t", "\v"), as one can be sure they are not entered by
the user accidentally. The same goes for the newest CVS version in the HEAD branch.
This code change didn't generate any new bugs so far in my Intranet-Wiki.

Below an example for further explaining.

Wiki text
 # Settings:

Template 'File'
|File: {{{1}}}

File: filename

   1. -------------------------------------- 

# Settings:

Output as it should be
File: filename

# Settings:
Comment 1 lɛʁi לערי ריינהארט 2006-01-19 17:14:59 UTC
Dear Patrick!

As far as I can understand your request is diametrically opposed to the
requirement from
Bug 3983: BiDi: please assure a high degree of fexibility / maintainability of
the template syntax with respect to RTL

Please understand that the requirement from bug 3983 is a great help when
editing long template lists as
if they would contain both LTR and RTL characters. In such a case the browser
will reorder all characters according to the BiDi (bidirectional) algorithm. 

Having the posibility to use a syntax as used at
is a great help.

Please note that editing large source files with Firefox requires great patience
because every pasting into the textarea box jumps the view of the textarea box
at the beginning of the textarea box. This is one reason why contributors to
projects using a RTL textarea box give up after a few edits. (see bug 4011;
note: [[ar:]] and [[he:]] have found a workaround for bug 4011)

Just go and edit [[meta:BiDi_workgroup/bugzilla/02248#Without_bugzilla:02248]].
insert some characters, make some previews, resize your browser window, please
do *not* save.

Contributors using RTL editing have enough problems. I would be happy if you
would withdraw this request.

best regards reinhardt [[user:gangleri]]
Comment 2 Brion Vibber 2006-01-20 09:38:45 UTC
As noted above, this would break many templates, especially longer templates.
Comment 3 lɛʁi לערי ריינהארט 2006-01-20 09:50:42 UTC
Dear Patrick!

I must admit that I did neither understand the request of comment #0 nor all

A "how to?" obtain the result you want / describe can be found at

best regards reinhardt [[user:gangleri]]

Note You need to log in before you can comment on or make changes to this bug.