Last modified: 2011-03-13 18:05:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3652 - PATCH: pseudo-language for scripts and bots that rely on parsing HTML output
PATCH: pseudo-language for scripts and bots that rely on parsing HTML output
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
  Show dependency treegraph
Reported: 2005-10-08 14:48 UTC by Daniel Kinzler
Modified: 2011-03-13 18:05 UTC (History)
0 users

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

patch for wfMsgReal in GlobalFunctions.php; intercepts message translation early. (702 bytes, patch)
2005-10-08 14:52 UTC, Daniel Kinzler

Description Daniel Kinzler 2005-10-08 14:48:46 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.
Comment 1 Daniel Kinzler 2005-10-08 14:52:01 UTC
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.
Comment 2 Daniel Kinzler 2005-10-08 14:59:19 UTC
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.
Comment 3 Brion Vibber 2005-10-09 00:42:13 UTC
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.
Comment 4 Brion Vibber 2005-10-09 00:47:48 UTC
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.
Comment 5 Daniel Kinzler 2005-10-09 11:53:40 UTC
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.
Comment 6 Daniel Kinzler 2005-10-11 22:27:14 UTC
note to self: if this should go into the code at some point, look at wfMsgHtml
and wfMsgWiki first.

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