Created attachment 954
patch for wfMsgReal in GlobalFunctions.php; intercepts message translation early.

Something I forgot to mention above: this patch does *not* effect messages
resolved via wfMsgForContent - those are handeled normally. As this is mainly
used for URLs, supressing translation would break links.

Attached:

Avar pointed me to bug #208 - wich has a much larger scope, and many more
implications. My current patch would allow existing bots and scrips to improve,
with only minimal changes, as opposed to a major rewrite needed for supporting
SOAP or such.

This patch only adresses a single issue, it's not intendet as a replacement for
a full featured API. But the issue at hand is one that breaks existing bots and
scripts on a regular basis. I feel implementing this ould improve the situation.

This is completely the wrong thing to try to do. Useful bot activity needs a machine-
friendly interface, not a hack on top of the UI.

Note that SOAP is not required; good clean REST stuff is perfectly fine, but the human
UI is not intended for machine interaction and is likely to get less and less friendly
to machine interaction due to continued antispam and antivandal efforts.

This would actually be very useful for humans, too: It often happens that some
bit of the user interface is not yet translated, and appears in english. It's
quite annoying to go through Apecial:Allemessages to find the one you have to
translate. It would be much nicer to be able to have shust show the names of the
messages in some way - maybe even as link to the respective MediaWiki: page.

Anyway, I hope you will re-think the wontfix - I belive ther's quite a bit of
demand for this in the bot-writing community.

note to self: if this should go into the code at some point, look at wfMsgHtml
and wfMsgWiki first.