Page MenuHomePhabricator

Provide a way to easily add external links to messages
Open, NormalPublic

Description

Currently there is no good way to embed external links to messages. There are two bad ways:

key1: "Please see $1"
key2: "your new messages"

Cons: lego, needs message documentation, can lead to mix of languages if only one is translated, translators might not read the documentation.

key1 "Please see <span class="plainlinks">[$1 your new messages]</span>"

Cons: lots of extra markup that translator can get wrong, needs the user full parser instead of just transforming.

What we need is some kind of light parser, that would take input like

key1: "Please see [$1 your userpage]
where $1 could be something like Linker::link( $target, '$1-linktext' );

And convert it to Please see <a ...>your user page</a>. Obviously the link itself should be outputted raw into the message while the link text and the rest of the message is escaped suitably. This should work for wfMessage()'s escaped, parse and parseAsBlock outputs, maybe text as well.


Version: 1.20.x
Severity: enhancement

Details

Reference
bz31032

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:54 PM
bzimport set Reference to bz31032.
bzimport added a subscriber: Unknown Object (MLST).

I've always wished that our i18n system would include metadata on the type of message for each message. eg: 'edit' would be marked as text while 'edittools' would be marked as wikitext. And 'sidebar' would be marked as content-language.

Then we'd only have ~2 commonly used message functions/methods. One for things like tag attributes that would force text and throw an error if you tried to force a wikitext message as text. And another that would return blocks of html. Knowing when something is wikitext and should be parsed.

If we had started with something like that, it would be fairly easy to force messages to not use full WikiText parsing. We could have an alternate lightweight parser for these things like links that we do want parsed... hell, we could completely ditch WikiText which isn't really necessary for i18n and have a special parser for a special syntax we use for most non-plaintext i18n messages that is really quick to parse, has much less worthless syntax, and is less forgiving of mistakes (making it more efficient).

Naturally it would still be possible to mark some messages as needing WikiText.