Page MenuHomePhabricator

For uselang=qqx, make each output of the message key also a link to the local MediaWiki: page for it
Open, Needs TriagePublic

Description

For easier over-riding.

Event Timeline

What if the message is used inside a link? Or inside an HTML attribute (like a title)? Is the code able to detect such usage as to not break the HTML?

This is probably doable for messages using ->escaped() or ->parse() (since these are expected to return HTML), and probably not for messages using ->text() or ->plain() (since these are expected to be just text).

An ->escaped() or ->parse() message that is used inside a link would probably indeed mess up the HTML a bit, but then that is already possible if someone edits that message to include a link.

Also, half the interface breaks on uselang=qqx anyway.

Winston_Sung subscribed.

I believe this would be completely broken in <a>{{msg}}</a> situations.

Self-plug: people interested in having the ability to go from uselang=qqx to individual pages can now use https://www.mediawiki.org/wiki/Translator_Buddy user script, which shows the tooltips with links to messages (local and on translatewiki.net) on right/left click.

Is it really that difficult to copy the message name and find it in the MediaWiki: namespace?

It isn't, but you can say the same thing about any sort of QoL feature.

…And for messages like (hidetoc) and (echo-badge-count) in most skins you cannot copy their name at all. (This is now solved by Translator Buddy, as well.)

I think doing this for ->parse() would be fine, but I'd be nervous about doing this for ->escaped(). If you are using the output of ->escaped() in an attribute, but instead it outputs <a href=.. that could lead to an xss.

…And for messages like (hidetoc) and (echo-badge-count) in most skins you cannot copy their name at all. (This is now solved by Translator Buddy, as well.)

In fairness if you can't copy the text, its probably not a clickable link target either.