[00:10:46] !log payments cluster updated from fa2e2 to a06a03f05 wheee! [00:10:53] Logged the message, Master [00:37:52] !log payments cluster updated from 4862fb8eef to f295d851c [00:37:59] Logged the message, Master [01:47:52] mwalker: BRD doesn't apply to software interface changes. [01:51:35] Susan: it should :) [01:51:59] especially when there are long standing problems that have been ignored [01:52:32] I am obviously biased though -- fundraising needed the bug fixed to support some stuff in banners [01:53:50] but at the same time; I don't believe we should revert the changeset in question because it does improve something -- I am fully willing to fix what this broke rapidly; but I do need to know exactly how it should be fixed [01:54:24] If we revert -- it's likely going to languish in perpetuity [01:54:32] How are you weighing your interests against those who your change affects? [01:54:50] I imagine it'll languish until there's a proper fix. [01:55:56] my weighting is 'display good content to readers' vs 'display annoying, but fixable, content to editors' [01:56:05] actually -- that's not a good vs [01:56:13] Having seen what the CentralNotice extension has done to the MediaWiki namespace on Meta-Wiki... will your change fix that? [01:56:36] this has nothing to do with CentralNotice -- but yes; I have plans to fix that problem [01:58:07] I skimmed https://bugzilla.wikimedia.org/show_bug.cgi?id=1495 a few times and I'm still not sure what the bug is/was. [01:58:25] https://bugzilla.wikimedia.org/show_bug.cgi?id=46579 on the other hand seems really straightforward. [01:58:52] I mentioned CentralNotice because you mentioned fundraising and banners. [01:59:00] ah; the issue in 1495 is that on wiki locales were not taken into account when computing language fallbacks [01:59:48] 46579 of course is that the on-wiki fallback chain is given precedence over the standard translations [02:00:46] the reason I fixed 1495 is because I attempted to fix this issue only in CentralNotice and decided that was dumb; I should just solve it for everywhere [02:00:55] Heh. [02:01:08] I'm not sure it counts as a fallback chain if it just shows English when MediaWiki:Foo/lang doesn't exist, which seems to be what bug 45679 is saying. [02:01:33] yes and no; it is in fact falling back, english just so happens to be the first thing it encounters in the chain [02:01:48] if someone put in MW:Foo/lang it would take that as a preference [02:03:20] as I stated in my comments to 46579 -- is it more important to present the customized text that the community wants; or is it more important to always give the correct language with possibly incorrect text [02:03:35] I see valid arguments either way [02:06:36] there are actually three valid solutions to the problem if you take a look at the original patch https://gerrit.wikimedia.org/r/#/c/44224/13 -- the comments I made at patch set 4; [02:06:36] Jan 17 15:29 [02:17:49] I had a SMTP error something when submitting a gerrit change [02:18:07] and I'm not receiving gerrit mail, it seems [02:19:15] mwalker: Incorrect? [02:19:44] incorrect? [02:28:23] as I stated in my comments to 46579 -- is it more important to present the customized text that the community wants; or is it more important to always give the correct language with possibly incorrect text [02:28:32] Is this an actual problem or a theoretical problem? [02:28:55] I feel like if I set "Russian" as my interface language, the interface should be in Russian. [02:29:33] It doesn't really matter if the Russian interface isn't as great as the English interface. [02:29:44] I agree -- but by changing a local message the community on wiki has, to a certain extent, asserted that it's message is more valid than the stock translation; why would that assumption not hold for other languages [02:29:52] I understand the general rule re: "no documentation is better than bad documentation." [02:30:03] But I'm not sure that applies here. [02:30:31] mwalker: It does hold, but only if the community has also translated that message locally. [02:31:03] I don't think there's an issue with a customized English message and a stock Russian message. [02:31:19] Surely having the interface in Russian is going to be closer to what's expected and desired than having the interface in English. [02:32:48] I actually agree; I am simply parroting what the argument was for the change in the fashion we made it in [02:32:56] I took the i18n teams recommendation [02:33:17] however; I'm not trying to throw them under the bus here [02:33:43] obviously they persuaded me enough to say "ok" at the time [02:34:13] are enough users annoyed by this change though; that outweigh all the possible benefits of it? [02:36:07] you would however help me; and the rest of this discussion greatly if you put your comments into the bug [02:36:14] I suspect the i18n team will decide to revert the patch [02:36:28] but whilst it's live and people are annoyed I'd like to collect as much feedback as possible [02:37:38] because this is in fact a problem we do need to solve [02:45:49] I copied and pasted some comments. [02:46:09] Thanks :) [02:46:25] I feel like a mail server is broken. [02:46:34] wikibugs seems to have gone quiet. [02:46:40] now that I can't help you with -- I suggest complaining over at ops [02:46:48] but yes; I noticed the same thing [02:48:00] Nemo_bis: You there? [03:17:32] * Jasper_Deng pokes Betacommand [08:03:07] hey all, anyone online that knows how commons handle the job queue? i want to know if jobs are run per wiki visit or in a background process. tia [08:09:59] dan-nl: should be a background process [08:10:19] dan-nl: we have servers knowns as "job runners" which have MediaWiki installed but do nothing else than processing jobs [08:10:45] there is something like: while true; do php maintenance/runJobs.php --wiki=; sleep 5; done; [08:11:03] hashar: thanks, that's what i was hoping for [08:11:28] dan-nl: we also have statistics about the jobqueue [08:11:54] hashar: ah, that's good to know, how do you access them? [08:16:56] dan-nl: can't remember :-]  I will look on the servers [08:17:18] e.g. https://ganglia.wikimedia.org/latest/graph.php?r=month&z=xlarge&c=Miscellaneous+pmtpa&h=spence.wikimedia.org&v=506&m=enwiki_JobQueue_length [08:17:25] hashar: np, thanks [08:17:42] dan-nl: ah we also have http://gdash.wikimedia.org/dashboards/jobq/ [08:18:41] $ mwscript showJobs.php --wiki=commonswiki [08:18:41] 36 [08:18:45] quite idle :-] [08:19:16] nice :) [08:21:48] hashar: do you happen to know of a recommended way to leave a message on a user's talk page? [08:26:09] i noticed that the User::leaveUserMessage() was deprecated and wondered what should be used instead [08:32:11] dan-nl: I have no idea sorry :( [08:32:58] hashar: ok, will try and find out later today if anyone may know. for now we don't plan to implement it for some time, so there's no rush to figure it out [08:36:37] dan-nl: looks like the method has been removed entirely :) [08:37:06] hashar: yes, i downloaded a version of it from 1.17 to at least see what it was doing [08:37:34] in 1.18 [08:38:24] dan-nl: http://www.mediawiki.org/wiki/Manual:Hooks/SetupUserMessageArticle :-D [08:38:30] the "goal" is to be able to target one message on a user's talk page and update it as their job queue completes [08:38:31] the related hook documentation says it :-] [08:40:30] right, so i was wondering why was it removed? is there a new process that should replace it? etc, but couldn't find anything yet [08:43:18] the method is still hanging out in /core/includes/job/jobs/UploadFromUrlJob.php::leaveMessage(), don't know if that's a problem or not [08:43:25] that's how i found it [08:46:03] I guess that job is broken :) [08:47:07] :) [08:49:53] you can fill a bug about it! [08:50:41] ja, was just looking at how to do that ... haven't entered one yet [08:50:59] bugzilla.wikimedia.org [08:51:19] looking at http://www.mediawiki.org/wiki/How_to_report_a_bug right now ;) [09:18:59] hope this was clear enough ... https://bugzilla.wikimedia.org/show_bug.cgi?id=46592 [10:21:42] Hi, was there any effort made at a global preferences tool before? [10:22:09] (so users can set some settings (i.e. signature, date and time, others) globally on all wikis their account is merged to) [10:27:20] yes [10:27:43] search bugzilla, mediawiki.org and wikitech, there's floods and floods of discussion on the topic [10:28:28] Gryllida: https://www.mediawiki.org/wiki/Wikimedia_technical_search may help for that [10:36:17] sorry, I fail to pick search keywords; results for "global settings merged accounts" are not relevant [11:05:14] andre__: if you move https://bugzilla.wikimedia.org/show_bug.cgi?id=43815 beware that there are more (closed) in the same component [11:13:44] Nemo_bis, I just didn't understand how this is "Tools" :) [11:14:07] "Various tools written for the MediaWiki software in general or for Wikimedia specific purposes. Stored in SVN at /trunk/tools/." [11:14:13] uhm. that's... wrong too. [11:15:21] * andre__ adds it to the backlog in https://www.mediawiki.org/wiki/Bug_management/Task_list#Backlog [12:10:47] * Gryllida pokes Nemo_bis [13:55:35] Reedy: https://bugzilla.wikimedia.org/show_bug.cgi?id=46005 panic [13:58:52] wizardist, it says "Fatal exception of type MWException". It does not say "panic". [13:59:16] where in the world would MediaWiki say "panic" at all? :) [14:03:36] andre__: grepping through core tells me that we will panic if jsmin encounters some syntax errors [14:08:05] I wonder what it would take to get more than some vague rather useless one-liner output that's more helpful than [12345678] 2013-03-27 13:58:16: Fatal exception of type MWException [14:10:55] andre__: perhaps you can find some data in logs by the exception ID. otherwise detailed exception info may expose some goodies not for public, who knows [14:11:19] well, we also show stacktraces in other places. [14:11:35] couldn't see one. where? [14:13:55] heh, I admit that I don't have an example handy, but I've seen enough bug reports linking to some. Of course not "MWExceptions" though [14:14:28] Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. [14:14:38] that is what the page itself says in the comment [14:14:44] :) [14:15:35] hmm. I see. Thanks. Now I just need to find the bug report about this and add that piece of info :) [14:43:42] * Cyberpower678 is back (gone 00:07:06) [15:22:49] Cyberpower678: please turn that script off [15:23:52] andre__: i think just about any shell person can look them up [15:25:24] jeremyb_: yes, but that's one more step between a user reporting it and a developer fixing it. I can understand though that there might be security issues. [15:25:52] For some there are [15:25:56] andre__: well the point was that it's not so hard to get if there's a particular one you want to look up right now [15:25:57] As we list cookies and other bits of stuff [15:26:10] jeremyb_: You're also 26 minutes late ;) [15:26:16] https://bugzilla.wikimedia.org/show_bug.cgi?id=46005#c5 [15:26:21] heh [15:28:16] * jeremyb_ is often late [15:28:33] are we using MariaDB already? [15:29:04] On some slaves, yes [15:30:41] Reedy: was that collision a conflict with wmf11? [15:30:48] No [15:31:04] A line of code that was present in wmf12 was needed [15:31:16] Apparently half of the code will work fine without it [15:31:23] Then in use it gives up and dies [15:32:17] is it common for the collation fix in other projects? or is it just be-tarask? maybe we should wait before wmf12 is deployed everywhere [15:33:06] Other projects are being moved over slowly too [15:33:27] Some of the code for other projects was already in, ie huwiki [15:33:56] And wmf12 will deployed everywhere in 2 and a half hours [15:34:30] a-ha. its March 27 [15:34:36] it's* [15:37:14] Reedy: everything seems fine now, you can resolve fixed that ticket :) [16:49:44] Reedy: question: do you think branching the next wmfXX branch on the Friday before the first Monday deploy would be possible AND not screw up people? My thoughts are that we should encourage people to do last minute merges into master over the weekend (but, the weekend is also when non-staff have time to devote to a project....). [16:50:24] Reedy: reason I ask is so I could get an hour or so of time Monday morning to do the review of commits/pull out interesting looking ones *before* the deploy. Just a thought. :) [17:27:31] greg-g: Have you by any chance had a look if there is a high number of commit merges on the weekend before the current branching mondays? [17:27:46] no, will look [17:28:34] I can't imagine that it's going to be actually higher [17:33:09] Reedy: from my unscientific look through the wmf12 branch long (via gitweb) it looks like sat/sun before the monday branching has the same(-ish) number of commits as a normal weekday [17:33:16] s/long/log/ [17:36:14] Sounds alright to me to change.. Would ideally need to give people notice first ;) [17:36:16] I guess it would be a case of doing towards the end of the SF working day then [17:39:47] is there any schedule deployment for pt.wp in the next days? [17:40:55] Alchimista: i think there's one today [17:41:20] in 20ish mins from now [17:41:25] Reedy: ^ [17:41:31] greg-g: ^ [17:41:34] Reedy: yeah, that's what I was thinking. Thanks for being a sounding board on that ;) [17:41:35] jeremyb_: is it possible to deploy Guided tour? It's already translated [17:41:47] yeah [17:41:48] no clue [17:42:13] Alchimista: Yes, if the feature that owns it (E2?) says it's fine to be deployed [17:42:17] by the way, is it possible to install it on another lang wp, with the pt version? [17:42:24] s/feature/feature team/ [17:45:09] I *think* guided tour is E3 [17:45:55] https://www.mediawiki.org/wiki/Extension:GuidedTour [17:46:15] https://www.mediawiki.org/wiki/Guided_tours [17:46:24] Seriously, it doesn't say it on EITHER of those pages? [17:46:38] Third click [17:46:38] https://www.mediawiki.org/wiki/Editor_engagement_experiments [17:46:40] E3, yup [17:46:45] haha [17:46:46] * Reedy blames ori-l [17:47:21] Reedy: you just have to know who's on what team, which man, that part is taking me a bit to pin down [17:47:34] Team: Matt Flaschen, Dario Taraborelli, Ryan Faulkner, Ori Livneh, Munaf Assaf, Steven Walling, Kirsten Menger-Anderson [17:47:48] Editor engagement experiments (E3) [17:47:56] on the third link [17:47:56] I think ori is the only one who uses a bouncer [17:48:34] Alchimista: If you ask greg-g nicely, he might go find them and throw something at a random member for you [17:48:41] :) [17:48:52] lool [17:48:59] indeed I could, but you have to ask really nicely, it involves getting in an elevator [17:49:37] well, what if i pay you a coffe durin some hacathon? Is it enough greg-g? [17:49:48] Alchimista: definitely :) brb [17:51:27] so, checking translatewiki, there is only one message to translate, and seems that the en version is provably the best, translating it will loose the meaning [17:52:02] At least with ptwiki, we haven't RTL issues to worry about [17:53:04] It's mostly a case of making sure the team is aware it gets deployed elsewhere, and sign off on it [17:54:32] Alchimista: they weren't up there [17:54:49] and would it be possible to deploy it on mwl.wikipedia.org with the pt translation, while there isn't a native mwl one? [17:55:06] Alchimista: do you know Steven Walling's email? if you do, email him, cc greg@wikimedia.org (me) and reedy@ (obvious) [17:55:07] Alchimista: is that fallback chain already in place for the mwl language? [17:55:12] * Reedy tries #wikimedia-e3 [17:55:18] oh right [17:57:05] Reedy: sorry, i didn't understood. you mean if there are other cases where pt is used instead of mwl? [17:57:21] * Reedy looks it up for himself [17:57:43] $fallback = 'pt'; [17:58:01] Alchimista: If the community want it deployed untranslated, with the pt fallback (which is there by default for mwl), it is fine if e3 agree [18:01:16] Alchimista: 18:00 < superm401> Reedy, sure, we should be able to do it tomorrow. [18:01:45] tomorrow E3 (team owners of GT) have a window at 20:00 UTC [18:01:51] deployment window, that is [18:03:58] greg-g: \o/ [18:04:05] Reedy: ok, i'll poke them so. [18:05:15] Reedy, robla, AaronSchulz: Would any of you mind if I do an extension sync-dir? [18:05:25] Feel free [18:05:29] I've not started doing anything yet [18:05:38] cool, should only take a minute [18:06:00] kaldari: is that for the css change? (it's cool, btw) [18:06:58] no, looks like there may have been another feature that got accidently rolled back, and I didn't sync all of Echo yesterday, just one subdir. [18:07:15] * greg-g nods [18:07:30] So I think I just need to sync-dir the whole thing to get everything back up to date [18:09:26] Reedy: all done [18:31:59] greg-g, Alchimista, Reedy: hey, what's up? [18:32:13] superm401 is also here, fwiw. [18:32:19] ori-l: Sorted now. You were the first person I could find to ping in e3 ;) [18:32:38] ori-l: now that I know who superm401 is... :) thanks! [18:32:49] :D [18:47:50] Nemo_bis: thx for the email about 55807 [18:55:24] StevenW: oh, I'm glad it was of interest... "no news, good news" is always valid I guess [19:03:30] Nemo_bis: it is. In this case, that stat is something we are relying on potentially for a feature, so it was a relief to hear it's not going away... [19:16:25] hi, on hr.wikipedia Kafić link (Village pump) in navigation portlet just became Village pump, any info how to fix that? [19:17:16] navigation portlet? [19:18:44] Reedy: navigation toolbox? [19:19:20] Looks like it's hard coded to t he english.. [19:19:27] (mainpage) [19:19:27] Village pump [19:19:27] (currentevents) [19:19:27] (recentchanges) [19:21:10] Yet ** Wikipedija:Kafić|Kafić [19:22:16] it showed as Kafić for years [19:22:28] Did it change within the last hour or so? [19:22:29] just 10 mins age switched to Village pump [19:22:37] yup [19:22:43] Sounds deployment related then.. [19:23:04] where to report a bug? [19:23:12] Bugzilla would be great [19:23:12] greg-g: ^ [19:23:20] thanks [19:23:55] I just updated https://www.mediawiki.org/wiki/MediaWiki_1.21/wmf12/Changelog too [19:24:22] UnlesI'm guessing it isn't l10n update related.. [19:25:48] ugh [19:26:37] siebrand: ^^ [19:28:05] Reedy: any ideas on that issue? [19:28:24] https://hr.wikipedia.org/wiki/MediaWiki:Sidebar hasn't changed and looks sensible [19:31:10] Astemd: did you report the bug already, perchance? [19:31:37] * greg-g wishes #mediawiki-feed messages were colorized so he could scan it more quickly [19:31:50] me too [19:32:26] sumanah: do you know who manages wm-bot? [19:32:31] greg-g: petan [19:32:53] greg-g: not, just made workaround [19:33:11] Astemd: gotcha, good deal I guess :) [19:33:59] StevenW: to be frank I'd think Special:ActiveUsers could have been kept for small wikis where it gives a selected and meaningful information [19:34:51] greg-g: so-so, I would like it would work as it is supposed to, but it's not high priority [19:36:46] there's this, too https://bugzilla.wikimedia.org/show_bug.cgi?id=46613 [19:39:52] That one is half fixed already [19:43:12] bsitu: https://wikitech.wikimedia.org/wiki/Server_admin_log [19:45:37] Reedy: that's what you just sync'd, the fix for that? (I'll assume yes) [19:51:43] Running scap now too... [19:51:47] awesome, thanks [20:16:30] MatmaRex: what kind of sanity check do you mean? https://bugzilla.wikimedia.org/show_bug.cgi?id=46615 [20:17:20] wizardist: hold on, i'm implementing it :) [20:17:32] I'm just asking :) [20:18:14] wizardist: basically, updateCollation didn't actually check if chosen collation is supported by both the underlying ICU library and MediaWiki's lirt of first-letters for this language [20:18:43] wizardist: i submitted the config change for review, but didn't realize that the code necessary for it to work was not yet deployed on be-x-old.wiki [20:18:50] and Reedy missed this when deploying as well [20:18:56] and updateCollation didn't complain [20:19:10] everything is/was lolfine! [20:19:11] i chatted with Reedy and we agreed this would be reasonable :) [20:19:26] Reedy: (talking about https://bugzilla.wikimedia.org/show_bug.cgi?id=46615 and its patch) [20:19:26] aha, that was the one-liner that Reedy was talking about? [20:19:36] [18:31:05] A line of code that was present in wmf12 was needed [20:19:52] wizardist: yeah, that patch that added support for be-tarask [20:19:56] your patch, actually, i think ;) [20:20:14] whatever) [20:20:34] what is be-x-old.? [20:21:22] * wizardist blushes [20:21:25] Belarusian Wikipedia [20:21:35] But using a different orthography [20:21:35] greg-g: https://be-x-old.wikipedia.org/ [20:21:46] wizardist: I got there, just.... [20:21:47] written in this: http://en.wikipedia.org/wiki/Tara%C5%A1kievica [20:22:13] interesting [20:32:23] Reedy: so, the hebrew parser function issue, resolved for now? [20:32:52] RESOLVED SHALOM [20:32:57] For now? Shouldn't be anything else need doing as the source on translatewiki has been fixed [20:33:11] There's still the translate bug that let it happen, but that's a different issue [20:33:30] Reedy: ok, thanks [20:34:05] greg-g: https://bugzilla.wikimedia.org/show_bug.cgi?id=46615 doesn't need such a high priority, the issue itself was mostly caused by me forgetting about the deployment schedule :) [20:34:19] (i think.) [20:34:57] MatmaRex: scaptrap? :-) [20:35:04] at least [20:35:09] Not really... [20:35:42] so, I don't know all the implications, but it seems like fixing the issue with better logic would be better than counting on a specific set of deployment windows [20:36:03] greg-g: the patch i posted would be more like a smoke alarm [20:36:10] indeed [20:36:12] ok [20:36:17] greg-g: if it blows up, you alreayd have some trouble [20:36:29] it won't prevent it, at best it would reveal it more quickly [20:36:34] If I was to do the same again, I would know quickly to rollback deploying the updated config change that comes before running the script [20:37:55] set to high, as it is more than normal, just because it is breaking things :) [22:59:14] where the fuck is tim starling [23:00:11] wow, did someone wake up on the wrong side of the bed ? [23:00:29] No, i wanna bitchslap him hard not to enable webm on wikipedia [23:00:49] ie users on ipad aren't able to play those ogg videos [23:01:23] might want to start a discussion on wikitech-l with your reasons stated and less inflammatory wording [23:01:44] LeslieCarr, O.O [23:01:48] wow [23:01:57] talk about an entrance [23:02:05] hehe yeah :) [23:02:23] hahaha [23:02:47] Backing Leslie up on this one. [23:03:36] * harej had no idea gyoung used IRC [23:04:18] :) [23:04:30] iPad? We care about those? [23:04:45] Reedy, I do at least. [23:04:57] Seems there's 2 of you then! [23:05:05] I use it for music in the shower. :p [23:05:12] not sure what I have to do with WebM [23:05:39] * Cyberpower678 gives TimStarling a slap guard. [23:06:05] * AaronSchulz never saw a cross-continental bitch-slap anyway [23:06:24] my mom has an ipad - it's perfect for her -- just web browsing and playing music and videos [23:06:29] WikiCritic: we are internally discussing the legal implications of side-by-side MP4 support. thanks for your vote in favor. [23:06:35] brion: he's gone [23:06:38] oh poo, he fell off [23:06:49] troll & run [23:06:55] wow, MissGayle on irc. /me is thinking that's rare. but not certain [23:06:58] like the good old days [23:07:00] except for the run part [23:07:18] I'm trying to spend more time on IRC :) [23:07:19] well, that surely was effective. two lines, five people comment on them :P [23:07:27] MissGayle: good :) [23:08:01] LeslieCarr, I have my iPad waterproofed. [23:08:21] ooo - is it an external case or is there a place that does a coating ? [23:08:23] So whenever I spill something on it, I can just wash it of [23:08:24] : [23:08:26] :D [23:09:01] LeslieCarr, external [23:09:03] LifeProof [23:12:40] LeslieCarr, www.lifeproof.com/en/ipad/?path=TopNav [23:13:17] If there's something to import (as in A), someone will do so following the process described at MetaWikipedia:incubator:Incubator:Importing from Incubator (logged at MetaWikipedia:incubator:Incubator:Site creation log). [23:13:48] So i heard you liek icubator? [23:16:16] cool [23:16:57] Reedy / Susan: any opinion re: https://bugzilla.wikimedia.org/show_bug.cgi?id=46591 ?