Last modified: 2009-11-26 03:23:16 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 5138 - HTML tags choke templates with parameters, because of a "=" (regardless of being masked by <nowiki>)
HTML tags choke templates with parameters, because of a "=" (regardless of be...
Status: RESOLVED DUPLICATE of bug 14235
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 16309 (view as bug list)
Depends on: 9522
  Show dependency treegraph
Reported: 2006-03-01 15:14 UTC by Daniel U. Thibault
Modified: 2009-11-26 03:23 UTC (History)
6 users (show)

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


Description Daniel U. Thibault 2006-03-01 15:14:07 UTC
This template works fine:
{{User language subcategory|
|language-name=French language
|description=Ces utilisateurs '''[[:Category:User fr-0|ne comprennent pas]]'''
le '''[[:Category:User fr|français]]''' (ou ne le comprennent pas sans grande
difficulté). [[Category:User fr|Français]]
(It is used in :en:Category:User_fr-0)

However, if we add a font tag to one parameter, the template renders incorrectly:
|description=Ces utilisateurs '''<font color="#FF0000">[[:Category:User fr-0|ne
comprennent pas]]</font>''' le '''[[:Category:User fr|français]]''' (ou ne le
comprennent pas sans grande difficulté). [[Category:User fr|Français]]
The description appears as "2" within triple curly brackets.
Comment 1 Daniel U. Thibault 2006-03-01 15:17:37 UTC
It does not matter where the font tag is inserted: outside the triple
apostrophes, or within the link pipe gives the same effect.
Comment 2 Melancholie 2006-03-01 16:38:44 UTC
Yes, the reason is the equal sign "=", so the parser thinks you are specifying
an parameter there!
Comment 3 Melancholie 2006-03-01 17:08:35 UTC
Because equals signs sometimes should not indicate that a value for a given
parameter will follow, there is the possibility to include equals signs by typing:

But paradoxically this does *not* work if an equal sign is inside a HTML tag
(although the following syntax would work outside of templates!):
<span style<nowiki>=</nowiki>"color: #00FF00;">blabla</span>
Comment 4 lɛʁi לערי ריינהארט 2006-04-05 23:53:42 UTC
Dear Daniel;

Please see the fix for your request at
I did not like to change the "live" template.

Please follow the links at [[user:Gangleri/tests/bugzilla/05138]].
In [[template:User_language_subcategory]] you will need to use
to achive what you like.

I thing this bug should be closed with resolution INVALID.

The safest way to use nested templates is to use named parameters only.

Example: The provided solution would break if you would call
[[template:User_language_subcategory]] with {{{language-code}}} containing a "="
character. Then you would probably need also
but I am not shure if "1" is a reserved parameter name or not.

best regards reinhardt [[user:gangleri]]
Comment 5 lɛʁi לערי ריינהארט 2006-04-06 09:52:35 UTC
Thing about a "real" parser who can identify *<font color="#FF0000">* as an HTML
tag the descibed behaviour is a bug.
Resolution LATER would be more apropriate.
This should be a "testcase", Brion do you agree?
Comment 6 Daniel U. Thibault 2006-04-06 11:57:35 UTC
Meanwhile, someone found a simpler solution. The color tag is written as « <span style="color: 
#FF0000;"> », which does not break rendering.
Comment 7 Daniel U. Thibault 2006-04-06 11:58:57 UTC
Hmmm...The question marks framing the quotes above are supposed to be guillemets : << >>. Another 
Comment 8 Melancholie 2006-04-06 12:30:05 UTC
No, there just has been done what Gangleri wrote in comment #4. 
The problem described in comment #3 is still there.
Comment 9 Melancholie 2006-04-06 12:35:20 UTC
But the problem of comment #3 only appears
when there is no ...|2={{{...
in [[Template:User_language_subcategory]]

Comment 10 Daniel U. Thibault 2006-04-07 19:55:00 UTC
Yup, Melancholie is right: the problem subsists.
Comment 12 Andreas J Schwab 2007-04-07 13:51:35 UTC
If an url containing a = is used in, it will only show if enclosed in <nowiki>...</nowiki>. 
However, it will not shown as a link (in blue with arrow), and one cannot double-click on it. Enclosing just the = sign does not work either.
Comment 13 ais523 2007-04-08 13:21:23 UTC
You need to quote the parameter with a number, like this: {{copyvio|1=(url=here)}}; if the template uses a named 
parameter, like copyvio on :w:en, you can use that instead: {{copyvio|url=(url=here)}}.
Comment 14 Omegatron 2007-06-04 18:38:15 UTC
Equals signs in URLs also break templates, forcing users to type |1=something|2=URL etc.  Equals signs inside URLs and HTML should not be interpreted as part of template parameters.
Comment 15 Nicolas Schudel 2007-06-05 09:08:48 UTC
A simple way around the URL problem would be to encode the equal signs like "%3D".
For example: url=here -> url%3Dhere
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-05 15:23:23 UTC
No, because escaping characters like '=' with special meanings in URLs changes the meaning of the URL.
Comment 17 Brett Hillebrand 2008-11-11 09:25:06 UTC
*** Bug 16309 has been marked as a duplicate of this bug. ***
Comment 18 Dave Roll 2009-01-15 04:41:13 UTC
I have a similar problem regarding the equal sign (=). See [[w:Template:Cite gvp]] for an example. I understand that the problem is that the parser interprets any string containing an equals sign as a parameter name. If there is no such parameter name then why should that assumption stand. It goes back to the mindless notion of using unnamed parameters. I sincerely wish you'all luck with this but I'm not to hopeful.
Comment 19 P.Copp 2009-11-26 03:23:16 UTC
Part of this bug, namely the not-working <nowiki>-tags has been fixed with the intoduction of the new preprocessor. The rest is a dupe of bug 14235.

*** This bug has been marked as a duplicate of bug 14235 ***

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