Last modified: 2011-11-22 00:26:18 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 11477 - Don't mark external links to the current wiki as external
Don't mark external links to the current wiki as external
Status: NEW
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
unspecified
All All
: Low enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 11124 17331 19249 30883 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-27 23:18 UTC by Waldir
Modified: 2011-11-22 00:26 UTC (History)
15 users (show)

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


Attachments

Description Waldir 2007-09-27 23:18:24 UTC
If we link a page using the full url instead of the internal link syntax, the external link arrow appears next to it. However, in some cases you don't have the choice, like a link to a diff, which has parameters and is tipically something like http://xx.wikipedia.org/w/index.php?param=value&param?value

I think that a choice should be provided by automatically marking links created with {{fullurl}} and similar templates as plainlinks. Also, if that template allowed a parameter for an alias, that would be good . But this probably would be another bug...
Comment 1 Chad H. 2009-02-07 15:21:06 UTC
*** Bug 17331 has been marked as a duplicate of this bug. ***
Comment 2 Subfader 2009-02-07 15:24:55 UTC
{{fullurl}} and similar shouldn't be handles as plainlinks but as normal
internal a so the color is the same as internal ones (.plainlinks uses the
a.external color).

Furthermore links posted like http://mywiki.com or [http://mywiki.com... should
be handled the same.
Comment 3 Waldir 2009-02-07 15:29:40 UTC
Forgive my naiveness :P -- I don't think I was clear enough back when I originally reported this (and made some mistakes, like assuming that {{fullurl:}} was a template).

What I believe should be done is to avoid marking full urls as external links (i.e. add the external arrow) if the domain is the same as {{SERVER}}.

It makes sense that the color should be the same as internal links, too.
Comment 4 Chad H. 2009-02-07 15:34:32 UTC
cf bug 16659, prettify permalinks. Kinda tangentially related.
Comment 5 Subfader 2009-02-07 15:52:45 UTC
The title of this bug is confusing (can it be changed?). As posted {{fullurl..., http://mywiki.com or [http://mywiki.com...  should be recognized / handled as internal links. Class plainlinks can be removed from the css after this was fixed.
Comment 6 Platonides 2009-02-07 16:17:09 UTC
It can be done from Monobook.css but better to do it from the skin to take advantage of $wgServer. It just needs to add:
#bodyContent a.external[href ^="{$wgServer}"] { background: none ; padding-right: 0; }

(properly escaping $wgServer)

Comment 7 Chad H. 2009-02-07 16:31:01 UTC
Thinking about this some more, what if we went the following route:

1) Format external links that point internally as internal links (no class, no icons)
2) Leave normal external links as-is
3) Leave .plainlinks in place, it has uses beyond just the external links to internal targets.

How does that sound?
Comment 8 Subfader 2009-02-08 01:29:22 UTC
1) yeah
2) yeah
3) can't think of any but I'm not that experienced.
Comment 9 p858snake 2009-02-08 01:36:25 UTC
3) the current block/ban templates and ip contrib footers use it for whois links and ect
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-08 01:41:36 UTC
(In reply to comment #7)
> Thinking about this some more, what if we went the following route:
> 
> 1) Format external links that point internally as internal links (no class, no
> icons)
> 2) Leave normal external links as-is
> 3) Leave .plainlinks in place, it has uses beyond just the external links to
> internal targets.

This sounds best.  The place to make this decision is during link rendering, before HTML output, *not* in CSS.  class="external" but display like an internal link isn't right.
Comment 11 Subfader 2009-02-08 02:04:20 UTC
Do we only talk about {{fullurl.. links or is it also possible to recognize "lazy links" like http://mywiki.com or [http://mywiki.com as internal links? Cos most users a too lazy to format a {{fullurl... just to point to some special page using parameters in the URL. It would still be correct for special pages to do so and no need to use {{fullurl... cos no "what links here" etc.
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-08 02:21:02 UTC
We're talking about anything that uses [http://mywiki.com ...], whether that's generated from {{fullurl}} or typed out by hand or assembled by voodoo magic.  The external link processor doesn't know or care about templates or magic words, it runs after those have all been substituted to wikitext.  It could also apply to bare links like just "http://mywiki.com".
Comment 13 Chad H. 2009-02-17 22:39:38 UTC
*** Bug 11124 has been marked as a duplicate of this bug. ***
Comment 14 Splarka 2009-07-10 23:29:51 UTC
*** Bug 19249 has been marked as a duplicate of this bug. ***
Comment 15 badon 2011-09-15 23:05:00 UTC
This bug is related:

https://bugzilla.wikimedia.org/show_bug.cgi?id=30883
Comment 16 badon 2011-09-15 23:14:38 UTC
*** Bug 30883 has been marked as a duplicate of this bug. ***

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


Navigation
Links