TL;DR: we are looking for solution that can post messages to user talk pages on any WMF wiki.
We (l10n team) are working on TranslationNotifications extension [1], which allows translators to sign up and choose how they want notifications of new translation requests to be delivered to them. One of the available delivery methods is the user talk page on another wiki.
We have some plans how to implement this. But we are uncertain which solution we should use.
I request your feedback. Please let us know what in your opinion is the best solution, what are the possible problems in each solution or you can even propose another solution.
Here is what we came up with:
Solution 1: Use the LoadBalancer to open connection to the other wiki. * Does WikiPage support editing pages on another databases like this? * This way we culd bypass things like blocked user/protected page unless we check for those
Solution 2: Use the api.php to post to the user talk page. * Has lots of failure cases: ** Connection error/Timeout ** May need to create user account separately ** The account may be protected ** Talk page might be protected
Solution 3: ''Suggest another solution.''
The idea is that we will create a new job in the jobqueue for each user that has to be notified (translation administrator has a special page for sending out the translation requests) and that the job will notify the user by email or posting to his/her talk page depending on what the user wants.
[1] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/TranslationNoti...
-Niklas
Launch a pywikipediabot script? That's not too 'elegant', but avoids reinventing the wheel...
On Tue, Apr 10, 2012 at 7:24 AM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
Solution 1: Use the LoadBalancer to open connection to the other wiki.
- Does WikiPage support editing pages on another databases like this?
- This way we culd bypass things like blocked user/protected page
unless we check for those
No, you can't do this. There are lots of wiki-specific things going on at edit time, both from the database and from the configuration. You have to run the edit entirely within the context of the target wiki, or it might trigger false positives or false negatives for all sorts of things, like $wgGroupPermissions , $wgSpamRegex, etc. etc.
Solution 2: Use the api.php to post to the user talk page.
- Has lots of failure cases:
** Connection error/Timeout ** May need to create user account separately ** The account may be protected ** Talk page might be protected
This is a bit tedious, as you point out, but I think it's the best solution.
Solution 3: ''Suggest another solution.''
The idea is that we will create a new job in the jobqueue for each user that has to be notified (translation administrator has a special page for sending out the translation requests) and that the job will notify the user by email or posting to his/her talk page depending on what the user wants.
If all of your cross-wiki edits occur from within the job queue, maybe you could try doing the *job insertion* cross-wiki? I.e. if I do something on enwiki and that causes a notification to be sent to you on fiwiki, the code (running on enwiki) should insert a job into fiwiki's job queue, not enwiki's. Then the job itself will be doing local stuff. Of course this does require that the receiving wiki (fiwiki in this case) also have the extension installed.
Roan
Niklas Laxström wrote:
TL;DR: we are looking for solution that can post messages to user talk pages on any WMF wiki.
I wrote a solution to this problem a year or so ago: https://meta.wikimedia.org/wiki/Global_message_delivery. It's currently used by a few Wikimedia Foundation projects and a few wiki-related publications (most notably "The Signpost").
I also recently filed a related bug with thoughts about a better solution to this problem: https://bugzilla.wikimedia.org/show_bug.cgi?id=35306. If you come up with a better solution, you can resolve that bug! :-)
We (l10n team) are working on TranslationNotifications extension [1], which allows translators to sign up and choose how they want notifications of new translation requests to be delivered to them. One of the available delivery methods is the user talk page on another wiki.
Yes. I'm not really sure why people like this option so much, but they really do. The duplication/decentralization of the content is also kind of annoying, I've personally found. With ENotif, the talk page message usually triggers an e-mail notification for the user, but the e-mail doesn't contain the message content, so it's more of a "ping." Why people prefer this to an actual e-mail, I do not know.
Solution 2: Use the api.php to post to the user talk page.
- Has lots of failure cases:
** Connection error/Timeout ** May need to create user account separately ** The account may be protected ** Talk page might be protected
This is the solution I went with, as I only had client-side access. I'm not sure why most of your failure cases matter. Connection errors/timeouts with the API are very rare. I think they're most common if a talk page grows too large and new content can't be posted at all. Creating user accounts is irrelevant with unified login; the accounts are auto-created after first log in. I don't know what "the account may be protected" means. And if the talk page is protected, who cares? Just don't post there. It's easy enough to catch all of these cases in a try/except. You'll also need to ensure that you follow redirects (for user renames) and be mindful of subject line length, but those are minor details.
Now, whether for your purposes using the API is the best option, I don't know. But for my purposes, the API has been wonderful. The only major hiccup I hit was a few weeks ago when database lag spiked to a crazy level and the script couldn't get past it.
MZMcBride
On 10/04/12 23:52, MZMcBride wrote:
Now, whether for your purposes using the API is the best option, I don't know. But for my purposes, the API has been wonderful. The only major hiccup I hit was a few weeks ago when database lag spiked to a crazy level and the script couldn't get past it.
MZMcBride
Well, that's actually a *feature*. If the db lag mis so high, it makes sense that the bots defer editing until things get better. :)
Platonides wrote:
On 10/04/12 23:52, MZMcBride wrote:
Now, whether for your purposes using the API is the best option, I don't know. But for my purposes, the API has been wonderful. The only major hiccup I hit was a few weeks ago when database lag spiked to a crazy level and the script couldn't get past it.
Well, that's actually a *feature*. If the db lag mis so high, it makes sense that the bots defer editing until things get better. :)
That assumption of a correlation between the two isn't always true and/or relevant, though. I'm not sure a bug got filed about it, but I think the idea was to flag the lagged databases as being knowingly lagged during planned maintenance, essentially. And then change the maxlag output from the API accordingly. That seemed to be the theme of the thread, as I remember it.
MZMcBride
On 12 April 2012 00:00, Platonides Platonides@gmail.com wrote:
On 10/04/12 23:52, MZMcBride wrote:
Now, whether for your purposes using the API is the best option, I don't know. But for my purposes, the API has been wonderful. The only major hiccup I hit was a few weeks ago when database lag spiked to a crazy level and the script couldn't get past it.
MZMcBride
Well, that's actually a *feature*. If the db lag mis so high, it makes sense that the bots defer editing until things get better. :)
<small font> possible small optimization How is that api? Something like this could work with appending text to a page. appending text is much faster than retrieving a page, appending locally, then sending again the new text for saving. </small font>
Niklas,
On Apr 10, 2012, at 7:24 AM, Niklas Laxström wrote:
Solution 3: ''Suggest another solution.''
https://www.mediawiki.org/wiki/Echo_(Notifications)
Unfortunately, this won't see real headway until June/July timeframe: http://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals#Editor_Eng...
But we should sync up. A lot of the stuff you are doing should at least be a requirement for Echo, if not a possible use case.
Take care,
terry
On Wed, Apr 11, 2012 at 12:24 AM, Niklas Laxström <niklas.laxstrom@gmail.com
wrote:
Solution 2: Use the api.php to post to the user talk page.
- Has lots of failure cases:
** Connection error/Timeout
Try again.
** May need to create user account separately
Create a global account for the bot
** The account may be protected ** Talk page might be protected
… give the bot account some global privilege that lets it do so.
This. Nothing else will cover every case.
Andrew Garrett wrote:
On Wed, Apr 11, 2012 at 12:24 AM, Niklas Laxström <niklas.laxstrom@gmail.com
wrote:
Solution 2: Use the api.php to post to the user talk page.
- Has lots of failure cases:
** Connection error/Timeout
Try again.
** May need to create user account separately
Create a global account for the bot
** The account may be protected ** Talk page might be protected
give the bot account some global privilege that lets it do so.
This. Nothing else will cover every case.
What? I don't follow this at all. You think creating a super-bot is a good idea instead of handling edge cases gracefully? If the page is protected, don't post to it... it's protected.
This kind of message delivery is generally wiki-project newsletters and other quasi-spam, not S.O.S. signals from a sinking ship. If the tool skips a few pages due to them being protected, I think we'll be all right.
MZMcBride
wikitech-l@lists.wikimedia.org