[07:34:23] Thiemo_WMDE: T125073 [07:34:24] T125073: [Story] Replace bad, but currently necessary language codes - https://phabricator.wikimedia.org/T125073 [08:48:55] anyone with some SPARQL knowledge willing to lend a hand? [08:49:28] https://en.wikipedia.org/wiki/User%3AGerardM%2FWikimedia_chapters I want this sorted by label (and do not know how) [08:50:22] sort=label [08:51:46] Thanks :) [08:54:41] Thiemo_WMDE: I believe this should not have happened as it did: https://gerrit.wikimedia.org/r/#/c/296889/4/repo/i18n/en.json [09:03:23] I can't remember where is described the property proposal process (https://www.wikidata.org/wiki/Wikidata:Property_proposal) ? [09:07:45] A week has passed since https://www.wikidata.org/wiki/Wikidata:Property_proposal/Software_quality_assurance was proposed and IIRC it is recommended to ping a property creator for attention after this delay ( https://www.wikidata.org/wiki/Special:ListUsers/propertycreator ) [09:15:12] matej_suchanek: http://ultimategerardm.blogspot.nl/2016/07/wikimedia-chapters.html the use of the same lists in different languages [09:24:28] MichaelSchoenitz: would you have time to review https://www.wikidata.org/wiki/Wikidata:Property_proposal/Software_quality_assurance ? [09:24:28] and good morning :-) [10:06:12] Lydia_WMDE: https://stackoverflow.com/questions/7097307/selecting-using-sparql-based-on-triple-does-not-exist [12:02:01] DanielK_WMDE: https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual does not explicitly states that it's SPARQL 1.1 but it is, right ? [12:06:33] dachary I'll take a look when I'm at home... [12:20:52] dachary: i'm not an expert on WDQS, but it seems so, yet: https://wiki.blazegraph.com/wiki/index.php/SPARQL_Update [12:21:10] if you need details, ask SMalyshev [12:26:27] DanielK_WMDE: thanks for the link :-) [12:29:58] dachary: Blazegraph is supposed to support the SPARQL 1.1 Query spec [12:30:06] if not, it's a bug [12:38:38] Tpt: :-) [13:22:37] glad to see we're getting less property proposal pages [13:35:36] * aude waves [14:58:14] Ugh. :( https://www.wikidata.org/w/index.php?title=Wikidata:Database_reports/Constraint_violations/Mandatory_constraints/Violations&curid=19873654&action=history [16:37:17] hey [16:37:22] hi [16:38:16] SMalyshev: i went through a few of your patches and gave some feedback. probably won't have time for more this week. [16:38:38] DanielK_WMDE: ok, let me see [16:38:57] so with sql verification - don't unit tests already do it? [16:39:53] namely, SearchEngineTest [16:39:58] SMalyshev: what do you mean? what verification? [16:40:05] i very much doubt it [16:40:11] test coverage in core is abysmal [16:40:13] DanielK_WMDE: it indexes and searches stuff, as far as I can see [16:40:30] DanielK_WMDE: in general it's true but in particular this one seems to be covered [16:40:39] ok, will check [16:41:00] actually, to the point that these tests fail when you have CirrusSearch installed :) [16:41:05] we've recently fixed it [16:41:50] so now it checks sql search regardless of the default one [16:42:08] SMalyshev: one thing I didn't quite see from the patch: will the default search engine use the new infrastructure at all? or will it keep on using getTextForSearchIndex? [16:42:26] DanielK_WMDE: sql one probably won't [16:42:44] SMalyshev: the first patch only adds infrastructure for defining fields, not for actually supplying structured data for individual pages, right? [16:43:03] DanielK_WMDE: right, first one defines fields, second one fills data [16:43:26] and with just this patch, nothing uses the new functionality, right? [16:43:38] in general, you *could* put data there without defining fields, though Elastic would probably not like it [16:44:05] DanielK_WMDE: well, with first patch and it's Cirrus companion CirrusSearch would use it [16:44:38] yea, but if we don't merge the cirrus patch, nothing uses it [16:44:44] thus we can use Cirrus browser tests to ensure it works (and we did :) [16:44:45] it does not impact any existing functionality [16:45:04] DanielK_WMDE: right, it shouldn't then change anything if you don't call the new methods [16:48:17] SMalyshev: so SearchEngine::getSearchIndexFields is unused in core. Fine. [16:49:06] DanielK_WMDE: yes, except for the tests of course [16:49:42] SMalyshev: there you go, then :) [16:49:56] DanielK_WMDE: cool, thanks :) [16:51:22] DanielK_WMDE: now what about the second one? [16:58:20] DanielK_WMDE: about units - what do you think about the idea of having normalized value as separate value connected to the original one? I think it's the easiest solution and doesn't require introducing tons of new predicates (at least not yet) [17:02:12] SMalyshev: yes, that's exactly how we plan to do it in json. https://phabricator.wikimedia.org/T112548 [17:02:50] oh, coolio [17:02:57] SMalyshev: i'm not sure if we need this for the full mapping though. might be enough to have it for the direct statements [17:03:04] will it be stored or only for export? [17:03:09] export only [17:03:14] aha, ok [17:03:54] well, with direct statements I still have very vague idea how to represent unit-ed values... with full mapping at least I know how to do it:) [17:04:44] so I decided to start with full ones and then think how to do direct ones. because if you need to query, you can always do full ones [17:05:08] it's a bit more verbose, but at least possible [17:09:31] SMalyshev: for direct statements, we may need a second relationship (direct-normalized) or use only the normalized value. [17:09:40] SMalyshev: on a related note, please have a look at https://gerrit.wikimedia.org/r/#/c/258519 [17:10:17] it'S a small patch, but with it merged, we will finally stop being a deadend in the web of linked data [17:10:45] DanielK_WMDE: I'd be happier if it also added something to generated tests. [17:10:55] so it'd be easy to see the end result [17:11:04] I mean tests that produce .nt [17:12:06] SMalyshev: not trivial, won't do that today. but feel free to give a -1 with that comment. [17:12:17] DanielK_WMDE: ohh, we have a deeper problem there [17:12:22] i prefer -1 over 0, because it's an obvious todo on my dashboard [17:12:43] well, maybe solvable but definitely we need to work on it [17:12:57] if it's URL, it's ObjectProperty, if it's value it's DataProperty [17:12:57] btw, this is an old patch that i just revived. i don't have all the context swapped into my neocortex ;) [17:13:25] but we probably don't cover that in the code and declare it as DataProperty... anyway, I'll write long comment on it [17:13:30] SMalyshev: ok, add a comment. we may need to change the ontology then. [17:13:33] it definitely needs some adjustment [17:13:37] yes [17:13:46] it may be doable, but it's a bit more tricky [17:14:30] DanielK_WMDE: so did you have time to look into https://gerrit.wikimedia.org/r/#/c/289021/ too? [17:15:03] not since my last comment there, no [17:15:12] probably wont have time before next week [17:15:20] but I added a test case to https://gerrit.wikimedia.org/r/#/c/297787/ :) [17:15:42] and https://gerrit.wikimedia.org/r/#/c/296059/ is passing tests now :) [17:16:07] DanielK_WMDE: ok, so please do when you have the next window :) [17:18:26] DanielK_WMDE: I'll test https://gerrit.wikimedia.org/r/#/c/297787/ on my setup and see if it unbreaks it [17:18:32] if yes, I'm fine with it [17:19:18] an will test 296059 too [17:23:57] thanks! [17:24:24] SMalyshev: with the two patches, it should be possible to view and to delete the page. editing isn't possible, moving needs a fix. [17:24:57] DanielK_WMDE: I wonder why editing isn't possible if we have right content model? [17:26:41] SMalyshev: becaus we don't want to allow pages with other content models to be created in the namespace. So we prevent editing. I guess that could be changed to only prevent creation. Not sure. [17:27:25] DanielK_WMDE: I think if the page is already there the ship has sailed... so we should allow editing. [17:27:28] but anyway, why allow editing? we don't really want to support other kinds of pages in this namespace. we take shortcuts for performance, so we can assume all pages in the ns are entities, without looking at the database. [17:27:33] those shortcuts break... [17:27:55] SMalyshev: i'd prefer to allow moving, not editing [17:28:01] well, if we allow different content handler in a namespace, it's weird that we can't edit them [17:28:12] ContentHandler allows this [17:28:17] Wikibase does *not* allow this [17:28:28] well, but it's not only wikibase code, it's core code [17:28:36] or the edit prohibition is wikibase? [17:28:42] if so then it's fine [17:28:56] the edit prohibition is done by wikibase, yes [17:29:06] the move prohibition is also done by wikibase [17:29:10] ah, ok then, wikibase can put additional limits [17:29:17] exactly [19:33:28] * aude waves :) [20:21:12] hey aude [20:21:17] made it home? [20:22:12] Lydia_WMDE: on the airplane :) [20:22:33] aude: woah! it's the future! :D [20:22:35] waiting for mukunda to deploy [20:22:40] :D [22:22:52] Could I please have https://www.wikidata.org/wiki/Q25631053 deleted? already exists at https://www.wikidata.org/wiki/Q20966579 but didnt show up in search. sorry. [22:23:01] anybody knows what's the language "aln espaniol"? [22:23:10] it breaks RDF dump :( [22:25:19] SMalyshev: https://phabricator.wikimedia.org/T138725 [22:25:40] omg [22:25:44] that's messed up [22:25:58] Not sure what the actual status is. [22:26:00] ok, how I check that the language is a real language? Do we have a list? [22:27:14] I see something about "isKnownLanguageTag" [22:27:56] aha, cool, thanks... should work for me [22:37:13] SMalyshev: Is it correct that not everything of WQS is translatable atm? [22:37:32] sjoerddebruin: which parts you mean? GUI? [22:37:37] Yep! [22:38:02] yeah not all strings there are translatable right now. Some are but some aren't AFAIR [22:38:19] most new stuff isn't :P [22:38:38] I'd ping Jonas on that - maybe file a phabricator issue for him