Last modified: 2006-05-31 14:36:19 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 4966 - $n variables should render as inline links if Media Wiki messages supporting wiki syntax
$n variables should render as inline links if Media Wiki messages supporting ...
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: 4949
  Show dependency treegraph
Reported: 2006-02-12 02:08 UTC by lɛʁi לערי ריינהארט
Modified: 2006-05-31 14:36 UTC (History)
1 user (show)

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


Description lɛʁi לערי ריינהארט 2006-02-12 02:08:17 UTC

Bug 4949: Watching pages shows images
Is a report about a broken MediaWiki message which renders incorectly when it
relates to images or categories. The page should be refered with an inline link.

During the last year I have seen dozens of older MediaWiki messages variants
(propageted trough 'user:MediaWiki_default') which render incorrectly. Many of
these projects do not have sysops at all to fix this.

The most messages I have identified where *'1movedto2'*, *'Addedwatchtext'*,
*'Deletedarticle'*, 'Protect-text', 'Protect-viewtext', 'Protectedarticle',
*'Undeletedarticle'*, 'Undeletedtext', 'Uploadedimage'.

*feature request*
'$-variables' should render as inline links if Media Wiki messages supporting
wiki syntax

Whatever change requires fixing. It would be easier to fix the 600 wikies with
the change and let the sysops from the major wikies to fix some of the messages
if they are broken.

The request is a simple rule. Variables could be used always as [[$n]] and
nobody would need to care about [[:$n]] in MediaWiki messages.

If $n would be used in expressions inside full url's these will *not* break: – (has a heading colon) – OK – (has a heading colon) – OK


The code could be shared with the evaluation of {{FULLPAGENAME}}. The problem
there is that [[{{FULLPAGENAME}}]] behaves the same and does *not* generate
inline links. See
I will open another bug / request about this.

best regards reinhardt [[user:gangleri]]

Marking blocks bug 4949; not shure about 4956.
Comment 1 lɛʁi לערי ריינהארט 2006-02-12 02:11:49 UTC
For the second part I opened
Bug 4967: [[{{FULLPAGENAME}}]] should render as an inline link
Comment 2 lɛʁi לערי ריינהארט 2006-02-12 02:21:42 UTC
P.S. If $n would not be used for a wiki link a colon would apear before the
image / category name. This is ugly. However having colons for the other 14
namespaces is ugly too.

This request would obsolete colons before all namespaces except {{ns:image}} /
{{ns:category}}. In my opinion this would be a greather advantage.
Comment 3 Brion Vibber 2006-02-12 04:22:09 UTC
Use [[:$1]] for this behavior.
Comment 4 lɛʁi לערי ריינהארט 2006-04-12 15:14:59 UTC
This request was opened to solve issues like
Bug 3328: Nogomatch parameter $1 returns extraneous introductory colon

The basic idea was if there would be a *benefit* for the user interface and the
maintenance of the Mediawiki messages if the $ variables would contain the colon
already for pages from the image and category namespaces.

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