Last modified: 2013-08-27 13:01:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T51850, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 49850 - Page view parses text within square brackets as external links
Page view parses text within square brackets as external links
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Translate (Other open bugs)
unspecified
All All
: Unprioritized minor (vote)
: ---
Assigned To: Niklas Laxström
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-20 01:27 UTC by T. H. Kelly (Pink&)
Modified: 2013-08-27 13:01 UTC (History)
8 users (show)

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


Attachments

Description T. H. Kelly (Pink&) 2013-06-20 01:27:40 UTC
See http://www.wikidata.org/w/index.php?title=Special:Translate&language=fr&group=page-Wikidata%3ANews&filter=&action=page: The text "edit [in English]" is rendered as "edit English", with "English" linking to http://www.wikidata.org/w/in. No actual issue on the rendered page, which is why I'm marking this as minor, but obviously MW should be consistent with what it parses as exlinks.
Comment 1 Nemo 2013-06-20 07:12:21 UTC
Clarified the summary, it's only page view/page mode.

(In reply to comment #0)
> but obviously MW should be consistent
> with what it parses as exlinks.

Not obvious at all, e.g. edit summaries don't parse in the same way as pages and system messages all have different kind of parsing.
Comment 2 T. H. Kelly (Pink&) 2013-06-20 07:20:44 UTC
Fair enough, I was overly broad. :P What I was getting at is that IMHO page view should parse potential exlinks the same way that normal wiki markup does. I.e. show it as an exlink if it starts with //, http://, https://, mailto:, irc://, etc., and don't show it as one if it starts with anything other than one of those predefined prefixes. Seems like the only surefire way to avoid false positives like this one.
Comment 3 Niklas Laxström 2013-06-20 09:42:34 UTC
This is easy to fix.
Comment 4 Gerrit Notification Bot 2013-06-20 09:43:25 UTC
Related URL: https://gerrit.wikimedia.org/r/69634 (Gerrit Change If7337cb1a9b729c511adb32d8a2326ea17a8160c)
Comment 5 Gerrit Notification Bot 2013-08-06 02:45:34 UTC
Change 69634 merged by jenkins-bot:
Stricter parsing for external links in JavaScript

https://gerrit.wikimedia.org/r/69634

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


Navigation
Links