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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
