Last modified: 2014-05-05 05:00:44 UTC
Current the IRC RC feed outputted the name of Special:Log half localized. Only the namespace is localised but the rest is the canonical form. Please make it full localized by using, for example, SpecialPage::getTitleFor() RecentChanges.php: (untested) if( $this->mAttribs['rc_type'] == RC_LOG ) { - $titleObj = Title::newFromText( 'Log/' . $this->mAttribs['rc_log_type'], NS_SPECIAL ); + $titleObj = SpecialPage::getTitleFor( 'Log', $this->mAttribs['rc_log_type'] ); } else { Thanks.
Created attachment 8893 [details] use SpecialPage::getTitleFor patch added
Created attachment 8894 [details] use SpecialPage::getTitleFor new patched added, first upload was the wrong patch
Recommending WONTFIX. The IRC feed is highly fragile and used in a gazillion places. There are already plans to create a new system that is more push-oriented and not limited to cleartext (ie. XML or JSON push notification through something with Jabber, WebSocket and/or PubSubHubBub. Atleast for the foundation feed I think changing this would unnecessarily break a many bots that sadly are not in very active development. (ie. there's a few bots that monitor all wikis for log events such as Block, to warn users if that blocked user edits another wiki. If the bot would have to resolve localized SpecialPage names in addition to namespaces that could get tricky, not sure if that's wanted. Calling the API for each edit on all wikis ? Or get them in advance from the API. Not sure, but either way I'm not the one who build those bots.) In general this is a valid bug and has a valid fix. But I think it's best to not touch it and instead let the existing bots work and fight the high vandalism load. There's imho way too few development eyes pointed on the vandalism problem, existing solutions are dirty at best but is highly depend on. In the mean time concentrate on the better system with push notifications with JSON or XML that are much easier to parse, much more flexible to change contents to add more info. No need to 'fix' a deprecated system. A script could be written fairly easily to read from this new feed and format an IRC message.
> In the mean time concentrate on the better system with push notifications with > JSON or XML that are much easier to parse, much more flexible to change > contents to add more info. No need to 'fix' a deprecated system. A script could > be written fairly easily to read from this new feed and format an IRC message. Could you point out where to this work on a new system is documented? I'd be happy to close this WONTFIX if you can.
(In reply to comment #4) > > In the mean time concentrate on the better system with push notifications with > > JSON or XML that are much easier to parse, much more flexible to change > > contents to add more info. No need to 'fix' a deprecated system. A script could > > be written fairly easily to read from this new feed and format an IRC message. > Could you point out where to this work on a new system is documented? Sounds like [[mw:Extension:XMLRC]] (or another XMPP Extension). (In reply to comment #3) > The IRC feed is highly fragile and used in a gazillion places. There are > already plans to create a new system that is more push-oriented and not limited > to cleartext (ie. XML or JSON push notification through something with Jabber, > WebSocket and/or PubSubHubBub. > Atleast for the foundation feed I think changing this would unnecessarily break > a many bots that sadly are not in very active development. (ie. there's a few > bots that monitor all wikis for log events such as Block, to warn users if that > blocked user edits another wiki. If the bot would have to resolve localized > SpecialPage names in addition to namespaces that could get tricky, not sure if > that's wanted. Calling the API for each edit on all wikis ? Or get them in > advance from the API. Not sure, but either way I'm not the one who build those > bots.) > In general this is a valid bug and has a valid fix. But I think it's best to > not touch it and instead let the existing bots work and fight the high > vandalism load. There's imho way too few development eyes pointed on the > vandalism problem, existing solutions are dirty at best but is highly depend > on. > In the mean time concentrate on the better system with push notifications with > JSON or XML that are much easier to parse, much more flexible to change > contents to add more info. No need to 'fix' a deprecated system. A script could > be written fairly easily to read from this new feed and format an IRC message. I am knowing nothing over that bots, and I cannot tell, if this change will break one of that bots. The IRC line has at least one other criteria, which a bot can detect a log entry. Caching the special page aliases once per language and per day/week should not be a high problem. There are sometimes changes, which breaks things, and without that you cannot make your software better. The IRC RC Feed is not official deprecated, please document that in the code, so nobody would waste time for that in the near future.
FWIW, I'd like to say that parsing the IRC feed is really unreliable, and always will be unreliable. We need a better push-interface for recent changes notifications. I have written the XMLRC extension for this purpose. It uses XMPP (aka Jabber) to send RC notifications as XML, formastted in the same way the MediaWiki API returns them. XMLRC is not ready for full scale production use yet, but with a little love, it could get there. But this will only happen if the WMF makes it a priority to have a decent push interface for recent changes.
r97711.
Ahm, some discussion beforehand would've been nice. I recommended WONTFIX in comment 3 because; 1) This system is going to be replaced in a not too far away future with push notifications. 2) Is almost only used by bots, which don't care about i18n 3) Changing this will break an insane amount of bots that have to be fixed by making an API to resolve this localized names into what they really are (making an API request may seem easy, but for some of the applications that use this, it would require lot of work to get an http request going at all). We're not talking about breaking extensions that we can easily fix in subversion or can give instructions to developers via a mailing lists. This would break many counter-vandalism workflows that imho would hurt the foundation projects. Many of these tools, sadly, are unmaintained and fragile. It's not a very good excuse, sure blame the users, but this is the current reality and until it gets better we shouldn't ignore it. As an example, the color encoding of the IRC log line (ie. orange for pagename, green for username etc.) has a few bugs in it (iiirc, it closes a color that wasn't opened somewhere and leaves one unclosed). That bug wasn't fixed either because there is no gain (it just looks better when looking at the source code) and many tools depend on how this string is currently built up, it's a very wide-spread regex. I get that i18n is importnat, but the gain here is very little and the amount of effort required to fix the 100s of tools all over the place is just not worth it, if at all possible. There is already too few time invested in proper uniform and centralized patrolling, let's not make it worse for something minor like this. The on-wiki things on SpecialRecentChanges are localized already.
making an API request*
I'd consider the IRC feed to be an API. Not a very good one, but nonetheless. This would be a breaking change, and I agree with Krinkle that it seems to be way more cost than benefit.
(In reply to comment #8) > Ahm, some discussion beforehand would've been nice. I recommended WONTFIX in > comment 3 because; > > 1) This system is going to be replaced in a not too far away future with push > notifications. It's been coming for years now, with no visible progress. > 2) Is almost only used by bots, which don't care about i18n Yes they do, see your point 3) > 3) Changing this will break an insane amount of bots that have to be fixed by > making an API to resolve this localized names into what they really are The namespaces where already localized, so I doubt that this problem is as severe as you say. It may be used primarily by bots in WMF side, but lots of smaller wikis it's just for humans.
I think we can make this change, but the bot authors should be notified as far in advance of deployment as possible.
(In reply to comment #12) > I think we can make this change, but the bot authors should be notified as far > in advance of deployment as possible. That sounds good. But what the best ways to get information to the bot authors? * Village pump (technical) on en.wp? * Breaking change note in the Release-Notes? * Maillingslists? * techblog?
(In reply to comment #13) > (In reply to comment #12) > > I think we can make this change, but the bot authors should be notified as far > > in advance of deployment as possible. > > That sounds good. But what the best ways to get information to the bot authors? > > * Village pump (technical) on en.wp? > * Breaking change note in the Release-Notes? > * Maillingslists? > * techblog? Since there is no central way (at least not one that bot authors actually commonly follow) I suggest at least all of the above (mailing lists: mediawiki-l, wikitech-l, commons-l, .. )
Marking patch reviewed because, per Rusty Burchfield's automated testing, it no longer applies cleanly to trunk. Updating is needed.
The patch was applied in r97711 and I marked it OK, no updating is necessary.
(In reply to comment #16) > The patch was applied in r97711 and I marked it OK, no updating is necessary. Reclosing. Re-open if I misunderstood.
FYI: reverted with r111006 for 1.19
possible revert with Gerrit change #4960
(In reply to comment #19) > possible revert with Gerrit change #4960 Re-opening this bug for now.
Now reverted in master as well: 5d0dae240b1cea3858d8cae332bae24134a02a4a The front-end is kept as is (i18n), the IRC API output keeps Log hardcoded.
