Wikimedia Bugzilla is closed!

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.

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.

{{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.

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

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.

(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.

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.

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.

(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?

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.

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.

Templating has started getting merged into core, but we haven't settled on a markup language yet so currently it's limited to HTML.

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.