[00:04:27] New patchset: Addshore; "use EntityIdParser in api/getclaims" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72532 [00:13:30] New review: Hoo man; "(1 comment)" [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/72641 [00:26:36] New patchset: Addshore; "changeopaliases use fix use MWException" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72670 [02:46:19] New patchset: Daniel Werner; "Added Wikibase\EntityContent::testGetParserOutput" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/66971 [02:47:37] New patchset: Daniel Werner; "Introduction of $.wikibase.claimgrouplabelscroll" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/69632 [04:45:18] addshore: lazyktm says I should talk to you about opening large items causing the browser to freeze [04:49:25] wctaiwan: on Wikidata? [04:49:33] items shouldn't be freezing your browser... [04:49:43] yes. [04:49:44] [12:43:04 AM] so, loading http://www.wikidata.org/w/index.php?title=Q865&curid=1185&diff=54963407&oldid=54870230 just made my browser freeze briefly [04:49:44] [12:43:19 AM] on my laptop, it's enough to make firefox do the "are you sure you want to keep running this script" thing [04:49:46] try opening the one for Republic of China. [04:49:51] lazyktm: no leaking :v [04:50:04] wctaiwan: no complaining :^ [04:50:44] also to be clear it's not because it's a diff page. [04:50:51] the main item does that as well [04:51:13] though I do think it may be a good idea to make &diffonly=1 default? [04:51:21] ...can't understand why it isn't, really [04:51:23] wctaiwan: Maybe you're just loading too much JS? [04:51:25] even for wikipedia [04:51:41] I don't think I have any user js. [04:51:42] * wctaiwan checks [04:51:45] Hazard-SJ: he hasnt set up user.js yet [04:52:24] that page doesn't freeze for any of you? o_O [04:52:33] I'm using firefox 22 on windows 7, fwiw. [04:53:33] it froze for me for 2 seconds [04:53:35] i saw the beachball [04:53:50] Firefox is known to choke on JS [04:53:56] yeah, that's what happens on this computer. On my laptop it triggers the warning. [04:53:58] isn't Chrome supposed to have the best JS engine? [04:54:26] granted my laptop is throttled to 800MHz because I take the battery out. But even then... you shouldn't need a super fast computer just to view an item. [04:54:40] worksforme on Chrome [04:54:43] also not a solution, given firefox's market share >>< [04:54:44] * Jasper_Deng tries firefox [04:54:44] >.< [04:55:11] yeah Firefox freezes very briefly for me [04:55:16] but I have like 40 tabs open. [04:56:52] probably a CPU thing rather than a memory thing [04:57:07] (so not necessarily correlated with how many tabs you have open) [04:57:11] no, i think its network [04:57:18] you have to make a few api requests to get all the info [04:57:18] but yeah. ...can't you guys cut down on the js? [04:57:32] well, or make it non-blocking [04:57:40] if you think it's the network. [04:58:36] lazyktm: I don't really think so, b/c Chrome doesn't choke on it, even if it takes a bit of time to load. [04:58:46] hm. weird then. [04:58:59] maybe chrome is smarter about handing the CPU back if js blocks? [05:23:29] Change merged: jenkins-bot; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72670 [05:35:33] DanielK_WMDE: It's okay if I use composer for the PHP client right? It has a dependency on Guzzle, so.. [05:38:14] Or is there any other method to manage dependencies that MediaWiki generally prefers...like git submodules (God no :( ) [05:38:22] aude^ [06:21:19] nileshc: use composer. we may use submodules to manage deployment, but don't worry about it. [06:56:41] Wctaiwan I'll take a look in a sec :-) [06:57:25] addie :D [07:36:25] DanielK_WMDE: ok, cool. [07:41:38] New patchset: Addshore; "Changing summary for wbeditentity clear" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72641 [07:42:32] mhhm, thats diff works fine for me :P [07:42:32] DanielK_WMDE: The prototype is almost up, but I've hit a strange snag...ingesting (upload the training csv file to Myrrix and Myrrix builds the model) the data.csv (~250MB) file via EntitySuggesterService->ingestFile isn't working on the server...No errors, just "Killed" on the command line. No errors given. I tried grepping the whole PHP code for the php client (including guzzle code etc) for "Killed" to no avail. This is a stran [07:42:33] ge one. [07:45:35] I tried fiddling with memory and script execution times in php.ini, no effect.. I think PHP error reporting is Off, I'll check that. [08:02:47] addshore: hello! I have whitelisted you on Jenkins, test should now run for you ( aka https://gerrit.wikimedia.org/r/#/c/72531/ got deployed ) [08:03:18] Why thankyou :) [08:03:53] all the merits go to aude who wrote the Zuul configuration patch :) [08:03:57] I just clicked some buttons hehe [08:05:28] nileshc: "killed" means the process got killed by the OS using SIGKILL [08:05:35] hashar: clicking the buttons is normally the fun part ;p [08:05:38] nileshc: the question is really: what killed it, and why? [08:06:32] nileshc: on some systems, process that use too much memory or cpu get killed automatically... i can't think of a good way to find out how or why, though [08:06:41] please ask the labs folks [08:06:43] nileshc: also look at dmesg on the server, maybe the script consumed all memory and got killed by the kernel [08:06:46] oh, and check your ulimit [08:06:53] DanielK_WMDE: SIGKILL - I see...but exactly - the question is how do I find what kills it? I've tried 3 times already. No logs, no error output. [08:07:07] nileshc: what hashar said: check dmesg [08:07:25] ah...okay, right away. dmesg and ulimit. [08:08:46] Thanks guys. It was "Out of memory: Kill process 8633 (php) score 851 or sacrifice child" [08:08:50] nileshc: anyway - you are importing via a web service? that is not going to work for large amounts of data i'm afraid. especially not with php [08:09:10] or are you calling this from the command line? [08:10:03] DanielK_WMDE: Nope, I'm calling this from the cli [08:10:14] maybe the csv could be split in smaller batches [08:10:48] the split command is a lovely tool for that, split -l 1000 foobar.csv , would create files which are 100 lines long [08:11:18] Yes, I'll do that. When I was testing this at home, the data size was almost half of what it is now, maybe splitting will help, unless it's a bug. [08:13:55] New patchset: Henning Snater; "Implemented wikibase toolbarlabel and toolbarbutton widget" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71633 [08:20:12] New patchset: Henning Snater; "Implemented toolbar and toolbareditgroup jQuery widgets" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72247 [08:22:37] New patchset: Henning Snater; "Limiting number of registered event handlers in toolbar button widget" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72529 [08:25:14] nileshc: it'S strange that the client gets killed, right? it should not really collect massive amounts of data in RAM... that's for the actual engine to do. [08:25:34] the client and servlet should both really just pass data through, without storing it. [08:26:04] nileshc: is there any state that needs to be kept in the client? anything large? [08:26:24] hm, this is a PHP client getting killed, yes? [08:26:39] make sure php has gc enabled in cli mode [08:26:50] other than that: just don't use php for anything long running or memory intensive [08:26:57] php sucks at that [08:28:24] nileshc: btw, jeroen has been working on a java implementation of the wikibase data model. [08:28:46] you wouldn't have to interpret the json yourself any more, but could rely on a standard lib. [08:30:01] New patchset: Henning Snater; "Removed toolbarlabel's get/setContent method" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72692 [08:34:24] DanielK_WMDE: Oh...ok, could you give me a link to the code or docs? I already finished the Python parsers at last; I'll have a look at the Java implementation later too. On the wikidata-suggester instance, the hadoop job took around 15 mins to parse a 1.2G dump... [08:35:59] nileshc: https://github.com/JeroenDeDauw/WikibaseDataModelJava/ [08:36:15] i don't know whether it's complete. ask jeroen about it. [08:36:29] nileshc: no requirement to use that. if you have a working solution, stick to it. [08:36:34] this is just for reference [08:36:59] DanielK_WMDE: ok, yes. [08:37:40] nileshc: not that this code is GPL, so yopu can't use it in an MIT licensed app. [08:37:53] maybe the two of you can meet in the middle an make everything LGPL :) [08:39:58] nileshc: btw - are you using an IDE for development? [08:40:01] Yes...I might not need it at the moment, given that the python parser just works. About the license - do you think I should change my code license (unrelated to WikibaseDataModelJava, just asking) [08:40:32] DanielK_WMDE: Yes, for Java and PHP I use Netbeans [08:41:03] And good ol' vim or a configured gedit works for Python. :) [08:41:16] ok, good. [08:41:47] re licensing: MIT should be fine for now, just keep in mind that most of mediawiki is GPL. [08:42:21] so any code "linking" to the core (whatever that means for php) must be GPL. Anythign else can be under any OSI compliant license. [08:43:01] DanielK_WMDE: Exactly...hmm..we'll have to be on the look-out for this...if code have to be mixed, I'll change those parts to GPL. [08:47:47] New patchset: Henning Snater; "Removed toolbarlabel's set/removeFocus" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72698 [08:48:04] nileshc: i just replied to your mail. most importantly: never mind authentication, and don't worry about the UI/JS stuff for now. [08:48:25] Alrighty. [08:50:46] New patchset: Daniel Kinzler; "Factor string normalization functions out of Utils." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72078 [08:50:57] New review: Daniel Kinzler; "rebased" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72078 [08:50:59] DanielK_WMDE: Thanks! I'm reading it... We can choose not to make the REST API public...I opened port 8080 on labs to make it public to help me while I code. All servlets can be internal. [08:51:11] New patchset: Daniel Kinzler; "(bug 46867) trim bad utf-8 sequences before normalizing." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/70139 [08:51:17] New patchset: Daniel Kinzler; "Move search key generation to TermSqlIndex." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72079 [08:54:05] New review: Daniel Kinzler; "@aude: please make all of them look." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/68002 [08:58:02] New review: Daniel Kinzler; "(1 comment)" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/66271 [08:58:33] New review: Daniel Kinzler; "needs rebase." [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/66271 [08:58:48] New patchset: Daniel Kinzler; "Added Wikibase\EntityContent::testGetParserOutput" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/66971 [08:59:57] * DanielK_WMDE looks around [09:00:00] daily delay? [09:12:34] New review: Henning Snater; "I would like getting around adding that specific template which is invoked in the back-end exclusive..." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72090 [09:19:12] aude: i see ba nunch of failing tests locally, in LanguageWithConversionTest and LanguageFallbackChainFactoryTest [09:19:33] this is on master... [09:19:39] anyone else having this problem? [09:19:48] New patchset: Henning Snater; "Limiting number of registered event handlers in toolbar button widget" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72529 [09:19:57] New patchset: Henning Snater; "Removed toolbarlabel's get/setContent method" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72692 [09:20:01] New patchset: Henning Snater; "Removed toolbarlabel's set/removeFocus" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72698 [09:21:48] they worked for me [09:21:52] DanielK_WMDE: those worked for me [09:22:09] hm... [09:23:12] i'm seeing: [09:23:15] -'de' [09:23:17] +'de-formal' [09:23:28] oh, wait. [09:24:29] silly me. forgot to remove a local hack [09:25:55] DanielK_WMDE: repo or client? [09:25:58] oh, ok :) [09:28:00] DanielK_WMDE: are you reviewing liangent's patches now? [09:28:06] New patchset: Jeroen De Dauw; "Added SelectionRequestDeserializer" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72619 [09:30:00] New patchset: Jeroen De Dauw; "Introduction of $.wikibase.claimgrouplabelscroll" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/69632 [09:30:49] Jeroen De Dauw: hi [09:31:21] ye ye ye [09:31:27] JeroenDeDauw: you here? [09:32:05] lazowik: physically yes, mentally perhaps less so :) [09:32:10] ok [09:32:29] shouldn't take much thinking [09:32:37] :) [09:33:07] regarding SimpleSiteLink [09:33:16] is it better to add array pageBadges [09:33:29] or create page array [09:33:37] with name string and badges array? [09:33:55] New review: Jeroen De Dauw; "(1 comment)" [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/66971 [09:34:06] JeroenDeDauw: ^ [09:35:54] lazowik: I do not understand your second suggestion. What I was thinking off is having a $badges field that is an array of string [09:37:06] the second would be { site: 'en'; page: { name: 'Title'; badges: {} } } [09:39:33] that kind of structure will be needed nevertheless in Item [09:40:22] bacause of data['links'][$siteId] which now contains pageName [09:41:08] JeroenDeDauw: I'll stop pinging you now, just take a look sometimes here [09:41:13] if you can of course :) [09:50:40] New patchset: Jeroen De Dauw; "Tweaks to entry point file" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72705 [09:51:03] New patchset: Jeroen De Dauw; "Rename source folder to src" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72706 [09:56:05] Denny_WMDE: can you review https://gerrit.wikimedia.org/r/#/c/70433/ for DanielK_WMDE ? [09:56:14] and then there's a big pile of patches that depend on it [09:56:20] about the bad value stuff [10:00:37] New review: Denny Vrandecic; "(1 comment)" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72547 [10:05:01] New review: Daniel Kinzler; "(1 comment)" [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/66971 [10:05:09] DanielK_WMDE: Il going to slowly go through the whole api and its error calls now :) try and align each module with each other and then also with core [10:05:26] addshore: yay! [10:06:32] just watch this keep changing ;p https://docs.google.com/spreadsheet/pub?key=0ArUN7tgsOZ8qdFpnTWlTbW1sZ2ZvMl9MbWkyNTdINlE&output=html [10:07:35] New patchset: Daniel Kinzler; "Fix some bad @group annotations" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72707 [10:07:50] easy chocolate enyone? ----^ [10:09:36] Change merged: Addshore; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72707 [10:10:57] New patchset: Henning Snater; "Removed toolbarlabel's get/setContent method" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72692 [10:11:10] New patchset: Henning Snater; "Removed toolbarlabel's set/removeFocus" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72698 [10:12:57] New review: Aude; "(1 comment)" [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/72316 [10:16:35] lazowik: the format of our serialization should not affect the way we represent the things in the PHP object all that much [10:17:01] lazowik: also keep in mind we cannot just change the serialization format - people would go mad as this would break things [10:18:13] lazowik: I don't think there is reason to put both title and badges in a page field - they all fit on the top level [10:18:32] The site is as much part of the page info as the title is [10:19:07] Though one can take a different view on that [10:19:19] Denny_WMDE: what do you think? [10:19:36] Any OS around? [10:20:07] Denny_WMDE: Can I use traits? Ran into a place where this would be rather useful :) [10:20:37] Wikidata has no local OS? [10:21:19] Okay. I will ask a steward then [10:22:16] ok, will do badges [10:22:26] * $badges [10:22:51] JeroenDeDauw: I agree with you on the badge being on the top level, i.e. { site: 'enwiki', title : 'Wikidata', badge: 'awesome' } -> lazowik [10:22:57] what is an OS? [10:23:08] badges: ['awesome'] [10:23:35] We are creating Wikidata OS? Cool [10:23:38] :D [10:23:50] In Haskell right? [10:23:56] in an array [10:24:05] (just lost connection for a moment, sorry) [10:24:11] JeroenDeDauw: I meant oversight not operating system :p [10:24:13] JeroenDeDauw: when where traits introduced to PHP? [10:24:39] Denny_WMDE: 5.4 [10:24:53] i think that means unfortunately no [10:25:20] but then again, you knew that before :) [10:26:28] Not sure how to avoid some duplication in the Ask deserialization code then [10:27:17] aude: >> Uncaught TypeError: Cannot call method 'getGlobalSiteId' of null [10:27:54] load.phpln791 ;p [10:28:26] JeroenDeDauw: with a comment to the effect that this is duplcated, that we can get rid of it using traits, and that should be refactored when we bump to 5.4 [10:29:17] New review: Aude; "running all the api tests again, I did not get the fatal. But got some test failures:" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72316 [10:31:52] Denny_WMDE1: we'll lose the comment due to proton decay before that happens [10:32:40] addshore: can you reproduce with debug=true [10:32:47] * aude cannot reproduce [10:32:52] * addshore looks* [10:33:02] in chrome or firefox [10:34:59] chrome debug=true all looks fine :) [10:34:59] JeroenDeDauw: as usual, i am slightly more optimistic :) [10:36:06] Denny_WMDE1: I'm quite sure I won't be off by more then 200 orders of magnitude [10:37:33] yes, that is likely. decimal base, i assume. [10:41:56] Change merged: Denny Vrandecic; [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72547 [10:45:17] Change merged: Denny Vrandecic; [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72548 [10:48:12] New patchset: Daniel Kinzler; "Allow rendering of entities without an ID." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/72711 [10:50:29] New review: Daniel Kinzler; "...alternatively to setting an ID (see comment), you can also just approve I3c7eec765 and rebase onc..." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/66971 [10:50:47] DanielK_WMDE: core doesnt really localise the message content of errors, do we want to? [10:50:56] Denny_WMDE1: hard to imagine the difference between 2^200 and 10^200, they are both somewhat big [10:51:25] :) aye [10:51:41] and longer than time as we currently expect it [10:52:08] addshore: in the api no [10:52:15] in the ui, yes i think so [10:52:35] mhhm, the ui doesnt use the wikibase-api-* error keys does it? [10:52:48] is there an language code for non-geek speak? :) [10:53:07] that's what the users should see and localised.... in the js [10:53:18] addshore: ask henning [10:53:36] Henning_WMDE, im aware im sat next to you but ^^ [10:53:51] addshore: or you can look in resources.php [10:53:58] in lib and repo [10:54:13] aude: i thought en-xnongeek [10:54:44] if i remove all of the wikibase-api-* keys from i18n on repo will I break any UI stuff? :P [10:54:56] quite possibly [10:56:17] addshore: tough question. generally, no. but in some cases, the actual underlying error comes from a Status object or some such. in that case, the localized error message should be used. [10:56:45] addshore: basically, anything that is a logic error (that is, the client misbehaving) doesn't need localizing [10:57:17] Denny_WMDE1: huh? The lifetime of Wikidata is expected to be under 10^200 years? :( [10:57:33] addshore: anything that can be caused by the user, or depends on the system's state, should be localized. E.g. edit conflicts. [10:57:58] DanielK_WMDE: okay :) *i think* :) [10:58:44] New review: Daniel Kinzler; "you need to rebase on something else. if rebase is tricky, make a new branch on top of whatever and ..." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71280 [10:58:50] JeroenDeDauw: we have a chance if this turns out to be what we are working on… http://www.wikidata.org/wiki/Q979311 [10:59:30] JeroenDeDauw: https://gerrit.wikimedia.org/r/71543 Could you think about your -1 again? [11:04:11] New review: Daniel Kinzler; "This will work, but it seems the wrong approach. Mentioning the concrete kind of entity in the copyr..." [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/71613 [11:08:02] Change merged: Denny Vrandecic; [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72619 [11:08:32] New review: Daniel Kinzler; "(1 comment)" [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/72321 [11:09:21] New review: Jeroen De Dauw; "@DanielK: The web API is part of the presentation layer. Domain logic does not belong there. This ha..." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71543 [11:09:37] New review: Denny Vrandecic; "why this? I though that includes is the usual place for MediaWiki extensions and libraries?" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72706 [11:15:04] Denny_WMDE1: looks like an interesting, though dated, story. Reminds me of https://www.wikidata.org/wiki/Q74378 [11:16:10] DanielK_WMDE: could you take a look at https://bugzilla.wikimedia.org/show_bug.cgi?id=50983 ? :) [11:21:44] New review: Daniel Kinzler; "@Jeroen: I really don't understand the problem. We have an interface that takes a page title. We can..." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71543 [11:22:39] addshore: can you reproduce 50983? [11:22:45] yup [11:23:24] addshore: with JS involved, or directly on the API? [11:23:41] is js, havnt tried directly on the api [11:23:50] please put steps to reproduce on the bug report [11:26:12] DanielK_WMDE: done [11:29:17] wikidata.org is broken [11:29:27] can someone confirm? [11:30:05] Abraham_WMDE: Define broken? [11:30:14] DanielK_WMDE: regarding serialization of fallback chain: 1) construction of fallback chain "claims" to be depending on the context, without telling what is used in the context (currently, language and user) it would be better not to touch or guess its internals in external code 2) if we pass back babel info (or even use babel info from user page), it's still open to dos attack [11:30:17] Seems to work for me [11:30:25] upload.wikimedia and bits.wikimedia dont appear to be responding from here :P [11:31:14] hoo: does not load at all here [11:31:16] 3) it won't be so difficult to be change the serialize to use another serialization format later (eg. just include construction source info and implement construction in ->unserialize() [11:31:43] Worksforme [11:31:48] hoo http://grab.by/oirO [11:32:38] mh [11:32:46] works for me with debug true and false [11:32:57] they are all back :> [11:33:01] Abraham_WMDE: ^^ [11:33:09] liangent: it still makes me very uneasy. the fallback chain is nothing the client should get to decide. it should be determiend by the server only. [11:33:30] liangent: in our case, it would *normally* come from the server, but we accept it as input, so there is no way to be sure [11:33:40] if we go that route, we have to be very restrictive about it. [11:38:15] DanielK_WMDE: only to avoid dos? might be a tricky way: to concatenate the fallback chain with wgSecretKey (or whatever) then hash it, and include the hash as a part of serialized form too :p [11:38:28] but it's still open to dos by defining a big label [11:38:30] *babel [11:42:45] Denny_WMDE1: should api provide way to search sitelinks by badges? [11:43:02] I'm looking for a best way to store then in database [11:44:04] *the best [11:47:36] Sk1d: if you don't CC anyone on a bug, bugzilla is just acting as a blackhole of bugs and ideas :D [11:48:27] Sk1d: ops, sorry, wanted to send to addshore [11:49:04] liangent: i don't like the idea in principle. as i said, fallback chains should never come from the client. I'm not convinced we need this. I think looping the current language through should be sufficient. [11:50:36] ebraminio: every component has a default asignee, which is typically a mailing list [11:50:41] so no, no black hole. [11:51:00] DanielK_WMDE: didn't know, thanks [11:51:00] DanielK_WMDE: what's "looping the current language"? [11:51:12] &languages=**|** in api calls? [11:51:31] liangent: passing it from the backend to the client, and back to the api. [11:51:32] then this param affects both qqc and other labels [11:52:30] liangent: sorry, i must be missing something... how does it influence anything? [11:53:22] i'm not sure about the qqc stuff either... we are losing the information which language qqc is referring to for each string. we'd need that fordirectionality etc, right? [11:54:12] we've already been using 'en':{'value':'something','language':'en'} in serialized form [11:54:30] and I add another 'qqc':{'value':'something','language':'en'} [11:54:32] ah, right, that's good. [11:54:45] with the second 'en' untouched, which indicate the "real" language [11:54:49] so we'd have 'qqc':{'value':'something','language':'en'} [11:54:55] yea, that's good [11:54:57] yeah [11:55:36] * DanielK_WMDE would probably have used something like '(preferred)' instead of qqc# [11:55:41] then in api calls, do we use &languages=en|qqc to get {'labels':{'en':{'value':'something','language':'en'},'qqc':{'value':'something','language':'en'}}} ? [11:56:05] we could do that, yes [11:56:33] if so, it can't be sure that we can always find the original context (thus the fallback chain) back [11:56:46] that's the initial motivation to serialize the chain [11:57:00] (passing the original context back somehow should be fine too [11:57:02] liangent: right. i don't think it'SA very important to be 100% sure that you get the original context. [11:57:21] it's going to be the same 99.99% of the cases, and when it's not, I can't think of a case where that would be a problem [11:57:32] DanielK_WMDE: can you assign this to a suitable mailing list? https://bugzilla.wikimedia.org/show_bug.cgi?id=40258 [11:57:34] on the other hand, i can see plenty of problems with fallback chains coming from the client [11:57:59] DanielK_WMDE: I am not very familiar with mediawiki groups and ... [11:58:19] ebraminio: it already is: "Assigned To: Wikidata bugs " [11:58:26] DanielK_WMDE: besides dos? [11:58:51] hoo: are you around? [11:59:05] Abraham_WMDE: Sure :) [11:59:17] DanielK_WMDE: hmm, but after one year... nobody cares... [11:59:45] liangent: besides DoS, mostly on principle: keep the input minimal and restrictive. don't leak internal info. don't pollute interfaces with internal cruft. [12:00:40] ebraminio: hm? the bug i was looking at ios from yesterday. which one do you mean? [12:00:56] DanielK_WMDE: https://bugzilla.wikimedia.org/show_bug.cgi?id=40258 [12:01:11] ebraminio: bugs *can* get lost, if they arn't urgent enough to be handled right away. so it helps to poke every now and then. [12:01:29] DanielK_WMDE: hmm, right [12:02:19] DanielK_WMDE: specifically any &uselang= param info will be lost [12:02:38] which is used by some site script on wikidata.org to enable localized view for anons [12:03:00] see [[d:MediaWiki:Common.js]] [12:03:00] [6] 10https://www.wikidata.org/wiki/MediaWiki:Common%2Ejs [12:03:16] ebraminio: ah. not m,uch i can do about that one. poke Aharoni about it? [12:03:33] DanielK_WMDE: would be nice, please [12:03:54] liangent: no, that's not lost because the current language should indeed be passed to the client. that's what i meant with "loop the current language". [12:04:27] ebraminio: i can cc him on the bug, but you have as much a chance of poking him on irc as i do. [12:06:14] DanielK_WMDE: If you have him email, please cc him but I don't have him in my joined channels [12:06:25] DanielK_WMDE: and I mangle the (or create a new / derivative) context to add the language into it somehow, then construct the fallback chain with that context? [12:06:46] ebraminio: done already. he's in here quite often, later in the day [12:06:55] DanielK_WMDE: thanks [12:07:00] lazowik: no search by badge [12:07:12] so I can just add one column [12:07:12] for now, maybe later if the use case is clear [12:07:16] and serialize in php? [12:07:26] a column where? [12:07:31] to database [12:07:36] for badges [12:07:43] New patchset: Jeroen De Dauw; "Optimized imports" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72714 [12:07:43] New patchset: Jeroen De Dauw; "Refactor code re-use by inheritance to using the strategy pattern" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72715 [12:07:43] where in the db? [12:07:44] and serialize( $badges ) in php [12:08:02] DanielK_WMDE: there's no newFromContextAndLanguage and I don't really want to add one, which looks not so clean [12:08:05] in wb_items_per_site [12:08:12] liangent: yes. though i'm starting to feel that it's not good that the fallback depends on "anything in the context". COntext is a kitchen sink, a kludge to get rid of some globals without massive refactoring. there's no coherence in what it contains. [12:08:30] I have to store these badges somewhere... [12:08:37] liangent: so depending on contaxt means introducing a bag of dependencies . which is annoying precisely in cases like this. [12:08:50] New patchset: Jeroen De Dauw; "Refactor code re-use by inheritance to using the strategy pattern" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72715 [12:09:30] in the item [12:09:52] Denny_WMDE1: https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/Ask,n,z [12:10:27] lazowik: the badges would primarily be in the json blob. that might be sufficient, though it means the client has to load the full entity in order to show sitelinks. that's probably not good in the long run. [12:10:29] lazowik: Denny_WMDE1 i think it would be icky to load the entire entities to get the badge info [12:10:40] DanielK_WMDE: but if one day I want to add, for example, the functionality to extract info from Accept-Language: header, I don't need to change a bunch of chain creation lins [12:10:47] lazowik: so, i suppose wb_items_per_site is the right place. in a blob field, as json. [12:10:51] we could do like the wb_property_info or maybe it could be in the site link table [12:11:02] ah, ok, not as primary i assume? [12:11:09] the primary is in the item blob [12:11:12] lazowik: or do we need to query by badge? and have multiple batches per target page? then we need a separate table. [12:11:13] a blob field in items per site is fine [12:11:17] we are talking about secondary, right? [12:11:18] Denny_WMDE1: yes [12:11:24] DanielK_WMDE: no querying of badges [12:11:26] it's a lookup table [12:11:52] so blob field of json-serialized? [12:11:55] liangent: that's why it'S good to avoid inline object creation, and push object creation up the stack. that way, there are fewer places to change when dependencies change. [12:12:28] liangent: https://en.wikipedia.org/wiki/Law_Of_Demeter [12:12:29] DanielK_WMDE: then there's still one per class.. [12:12:44] liangent: not if you inject the chain into the class [12:12:54] ideally, there is exactly one [12:13:21] now, if you anticipate that you will have *different* contexts to deal with during the same request, you can't do that [12:13:24] but when would that happen? [12:13:55] well technically context is not tied to requests [12:14:40] maybe I would setContext in the context source [12:14:43] then call it cgain [12:15:01] New patchset: Jeroen De Dauw; "Rename source folder to src" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72706 [12:15:05] New patchset: Jeroen De Dauw; "Optimized imports" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72714 [12:15:08] New patchset: Jeroen De Dauw; "Refactor code re-use by inheritance to using the strategy pattern" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72715 [12:15:33] so I sometimes I want to delay chain creation and cache factory instead [12:15:47] so I may override setContext and create a new chain when needed [12:17:07] liangent: i see no use case for that. but yes, if you want to support that, you have to locally create the chain. which means you have to update all these places when dependencies change [12:17:43] delaying chain creation is a good thing, i supose, because languages are so heavy... [12:17:55] still one per class if I use a getLanguageFallbackChain() method, right? [12:17:57] * DanielK_WMDE is pondering about creating a LanguageInfo class without all the cruft. [12:18:14] if you do that in every class, yes [12:18:24] honestly, i do not see the use [12:18:41] ok [12:18:43] context is not designed to be replaced or changed on the fly. [12:18:57] lots of stuff gets confused if you do that [12:21:40] New review: Denny Vrandecic; "(1 comment)" [mediawiki/extensions/Ask] (master) C: 2; - https://gerrit.wikimedia.org/r/72705 [12:21:40] Change merged: Denny Vrandecic; [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72705 [12:22:46] New review: Daniel Kinzler; "(1 comment)" [mediawiki/extensions/Wikibase] (master) C: 2; - https://gerrit.wikimedia.org/r/71845 [12:24:03] Change merged: jenkins-bot; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71845 [12:25:03] some visualization of wikidata geographical data: https://dl.dropboxusercontent.com/u/172199972/map/index.html [12:26:24] DanielK_WMDE: btw regarding https://gerrit.wikimedia.org/r/#/c/71845/11/repo/includes/actions/ViewEntityAction.php : you can always inject with the setter [12:27:28] creates a wrapper of parent::__construct requires one more place to change if the function definition ever changes [12:27:59] liangent: no, that's no in addition to the linitialization in the getter, but *instead*. so it'S the same number of places. [12:28:26] but lazy initialization is good in case of the language cruft, so let's keep it for now. [12:29:14] yes, injecting with a setter works, though it's not very pretty. [12:30:05] New patchset: Jeroen De Dauw; "Remove Serializer from SerializationException" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72717 [12:30:06] New patchset: Jeroen De Dauw; "Added attributeValue to InvalidAttributeException" [mediawiki/extensions/Ask] (master) - https://gerrit.wikimedia.org/r/72718 [12:30:30] DanielK_WMDE: "no, that's no in addition to the linitialization in the getter, but *instead*. so it'S the same number of places." I mean, if you add a param to the constructor in its base class in the future, you'll have to change this class too [12:30:43]