Last modified: 2014-11-18 07:20:38 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 T68746, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 66746 - Provide a parser function to create links to the wiki which don't look external
Provide a parser function to create links to the wiki which don't look external
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.24rc
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-06-17 21:51 UTC by Jon
Modified: 2014-11-18 07:20 UTC (History)
7 users (show)

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


Attachments

Description Jon 2014-06-17 21:51:40 UTC
Wikitext is very limiting for links.

When people want to create local urls with parameters they abuse wikitext by doing the following:
[http://thislookslikeanexternallink.com/butitisactuallylocal?action=foo link]

This has the side effect of rendering external links which then have to be hacked around. Sigh.

As suggested by Bartosz we should create a {{#link:}} parser function so that in message keys we can do {{#link:/my/localurl/Foo?action=edit}}

Talking to Brion Vibber he says this is a good idea.
Comment 1 Bartosz Dziewoński 2014-06-17 21:57:26 UTC
Note that this would be intended for localisation messages, which are currently full of <span class="plainlinks"> and {{fullurl:}} and "Click here to $1", and wouldn't be available elsewhere. We could possibly even limit it to specific messages with some Message class method if someone feels that it would be abused.
Comment 2 Nemo 2014-08-14 12:11:16 UTC
If you want a "parser function for creating arbitrary links", we already have three: https://www.mediawiki.org/wiki/Help:Magic_words#URL_data

Changing summary to reflect what seems to be the use case according to comment 0. It seems you just want something like $wgNoFollowDomainExceptions but for the "external" class, set by default for the wiki's domain?

For targets other than the current wikis, the most obvious way to make the links look internal (as they should if they're linked from the interface itself) is to use interwikis, which however were veto'ed by Brion, see bug 54835.
Comment 3 Jon 2014-08-14 17:50:57 UTC
{{localurl:Special:Userlogin|returnto=Hello world}}
ouputs /w/index.php?title=Special:Userlogin&returnto=Hello world

but I want to output
<a href="/w/index.php?title=Special:Userlogin&returnto=Hello world">Log in</a>
as part of an i18n message.

currently the way to do this is
[$1 log in] where $1 is an absolute URL e.g.
http://localhost/w/index.php?title=Special:Userlogin&returnto=Hello world

This is problematic in mobile for 2 reasons
1) Incorrectly styled and in markup as an external link
2) Clicking this link will take you to the desktop site which will redirect you to the mobile site, so it increases the time it takes to click a link on mobile.

Please update the summary in such a way that it better reflects this, the current summary does not look right to me.
Comment 4 Gerrit Notification Bot 2014-10-16 22:32:46 UTC
Change 167117 had a related patch set uploaded by EBernhardson:
Add {{#link:}} pf for creating arbitrary local links in i18n messages only

https://gerrit.wikimedia.org/r/167117
Comment 5 Brion Vibber 2014-10-16 23:17:51 UTC
I think I might recommend making the parameters compatible with localurl -- this would also allow for porting code between wikis that have different installation directories.

For example one wiki might have /w/index.php and /wiki/Foo and another might have /index.php and /index.php/Foo ...

So you'd do {{#link:Special:Userlogin|returnto=Hello world}} rather than {{#link:/w/index.php?Special:Userlogin&returnto=Hello%20world}} and have the link automatically generate for the correct site config.
Comment 6 Nemo 2014-10-16 23:29:44 UTC
(In reply to Brion Vibber from comment #5)
> I think I might recommend making the parameters compatible with localurl --
> this would also allow for porting code between wikis that have different
> installation directories.

Definitely a requirement. Plus points if this feature becomes a parameter of fullurl (or two), including the being bound to current domain rather than $wgCanonicalServer or whatever.
Comment 7 Erik Bernhardson 2014-10-16 23:44:11 UTC
as this is intended for messages, my intended use case was more like:

   {{#link:$1|$2}}

and

    $msg->params( $title->getLinkUrl( 'action=edit' ), 'edit' );

As suggested this becomes

    {{#link:$1|returnto=$2|$3}}

Which just moves some of the logic from the php into the message template.  I don't think its desirable for the programmer or the translator to move this logic into the message. Alternatively the programmer will use the first example but stick 'Main_page|action=edit' into $1 which is equally undesirable. It is quite likely the caller has a Title object and know how to use it.
Comment 8 Niklas Laxström 2014-10-17 08:09:06 UTC
I don't remember where this came up last time, but back then I argued with Bartosz that this is just a special case of more general problem: placing html into message so that it wraps some translated content.

Just think about wanting to do a button instead of a link. Or what about adding classes or other attributes to the link?  Are we going to add a new magic word for each special case? This solution might solve the issue for many cases, but I am not convinced it is flexible enough in the long run.

I even had proposed a syntax for this and some ideas how to implement it, but i cannot find them now.

I'm adding the missing i18n keyword which is the reason I didn't notice this bug earlier.
Comment 9 Matthew Flaschen 2014-11-07 04:34:05 UTC
(In reply to Niklas Laxström from comment #8)
> I even had proposed a syntax for this and some ideas how to implement it,
> but i cannot find them now.

Did you find this?
Comment 10 Niklas Laxström 2014-11-13 08:30:48 UTC
No, it might have been in IRC somewhere. The idea is that there is parser function, which takes the html[1] and the translated string(s) as parameters.

Message:
"login": "Please {{#foo:$1|login now}}"

Usage:
$button = Html::element( 'button', array( 'class' => 'foo' ), '$1' );
wfMessage( 'login', $button )->escaped();

The escaping of "login now" should be strong enough that it can be used 1) inside elements and 2) inside attributes, e.g. title="$1". Use of placeholders in other positions should be discouraged or even prevented.

[1] Message class would need to work with Parser class to make this safe. Possibly, instead of giving the html directly to the parser function, Message class generates an unique token. The token is given to the parser function and the html associated with the token is given out of band to parser. The parser function will then fetch this html and substitute escaped parameters to it.
Comment 11 Matthew Flaschen 2014-11-15 03:35:48 UTC
Hmm, that is a broader change.  It may not be necessary if we settle on a templating/widget approach (https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library) in a reasonable amount of time.
Comment 12 Matthew Flaschen 2014-11-15 03:36:54 UTC
Templating has started getting merged into core, but we haven't settled on a markup language yet so currently it's limited to HTML.
Comment 13 Niklas Laxström 2014-11-18 07:20:38 UTC
You will need a solution even with templating. The general problem of avoiding lego-messages by taking something in the translation string and putting it inside an html element, which is then put back into the translation string wont go away with templating.

As articulated above, #link might solve 90% of the cases, but I think with some extra effort we can reach a solution which solves 99%*.

* Numbers not based on data.

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


Navigation
Links