Last modified: 2012-07-28 17:40:41 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 T33032, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31032 - Provide a way to easily add external links to messages
Provide a way to easily add external links to messages
Status: NEW
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: 18521 19104
  Show dependency treegraph
Reported: 2011-09-20 10:00 UTC by Niklas Laxström
Modified: 2012-07-28 17:40 UTC (History)
4 users (show)

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


Description Niklas Laxström 2011-09-20 10:00:51 UTC
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.
Comment 1 Daniel Friesen 2011-09-20 15:22:19 UTC
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.

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