Last modified: 2011-03-13 18:05:05 UTC
I implemented a small hack that handles a pseudo-language called "bot" or "none", by outputting system messages in the form {@[key]@} instead of trying to translate them. This would greatly help scripts and bots that rely on parsing system messages (apper's check-usage springs to mind, but there are many others). The main problem is that a) those bots need to know *all* languages, abd b) messages change frequently. A few remarks about my patch: * I'm aware that a "real" bot API would be preferrable. But there seems to be no real solution for that in sight, so a quick-and-dirty hack would be an improvement for now. * Existing bots and scripts could be adopted to use this pseudo-language in a matter of minutes. They'd become more reliable and stable that way. * This patch is rather unintrusive: it just ads 5 lines. It would be cleaner to do this by implementing a Language class, but that would mean more code, and would also be slower. Patch to follow in a minute.
Created attachment 954 [details] 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.
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.
