Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
Hi! > data on Commons. I also think that I understand your statement above. > What I'm not understanding is how Daniel's proposal to "start using the > ontology as an ontology on wikimedia projects, and thus expose the fact > that the ontology is broken." isn't a proposal to add poor quality > information from Wikidata onto Wikipedia and, in the process, give > Wikipedians more problems to fix. Can you or Daniel explain this? While I can not pretend to have expert knowledge and do not purport to interpret what Daniel meant, I think here we must remember that Wikipedia, while being of course of huge importance, is not the only Wikimedia project, so "start using it on Wikimedia projects" does not necessarily mean "start using it on Wikipedia", yet less "start adding bad information to Wikipedia" (there are other ways to use the data, including imperfect ontologies - e.g. for search, for bot guidance, for quality assurance and editor support, and many other ways) I am not prescribing a specific scenario here, just reminding that "using the ontology on wikimedia projects" can mean a wide variety of things. > Separately, someone wrote to me off list to make the point that > Wikipedians who are active in non-English Wikipedias also wouldn't > appreciate having their workloads increased by having a large quantity > poor-quality information added to their edition of Wikipedia. I think I am sure that would be a bad thing. But I don't think anything we are discussing here would lead to that happening. -- Stas Malyshev smalys...@wikimedia.org ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
On Fri, Oct 19, 2018 at 9:47 AM Markus Kroetzsch < markus.kroetz...@tu-dresden.de> wrote: > On 19/10/2018 07:09, Pine W wrote: > > I would appreciate clarification what is proposed with regard to > > exposing problematic Wikidata ontology on Wikipedia. If the idea > > involves inserting poor-quality information onto English Wikipedia in > > order to spur us to fix problems with Wikidata, then I am likely to > > oppose it. English Wikipedia is not an endless resource for free labor, > > and we have too few skilled and good-faith volunteers to handle our > > already enormous scope of work. > > You are right, and thankfully this is not what is proposed. The proposal > was to offer people who search for Commons media the (maybe optional) > possibility to find more results by letting the search engine traverse > the "more-general-than" links stored in Wikidata. People have discovered > cases where some of these links are not correct (surprise! it's a wiki > ;-), and the suggestion was that such glitches would be fixed with > higher priority if there would be an application relying on it. But even > with some wrong links, the results a searcher would get would still > include mostly useful hits. Also, at least half of the currently > observed problems with this approach would lead to fewer results (e.g., > dogs would be hard to include automatically to a search for all > mammals), but in such cases the proposed extension would simply do what > the baseline approach (ignoring the links) would do anyway, so service > would not get any worse. Also, the manual workarounds suggested by some > (adding "mammal" to all pictures of some "dog") would be compatible with > this, so one could do both to improve search experience on both ends. > > Best regards, > > Markus > > Hi Markus, I seem to be missing something. Daniel said, "And I think the best way to achieve this is to start using the ontology as an ontology on wikimedia projects, and thus expose the fact that the ontology is broken. This gives incentive to fix it, and examples as to what things should be possible using that ontology (namely, some level of basic inference)." I think that I understand the basic idea behind structured data on Commons. I also think that I understand your statement above. What I'm not understanding is how Daniel's proposal to "start using the ontology as an ontology on wikimedia projects, and thus expose the fact that the ontology is broken." isn't a proposal to add poor quality information from Wikidata onto Wikipedia and, in the process, give Wikipedians more problems to fix. Can you or Daniel explain this? Separately, someone wrote to me off list to make the point that Wikipedians who are active in non-English Wikipedias also wouldn't appreciate having their workloads increased by having a large quantity poor-quality information added to their edition of Wikipedia. I think that one of the person's concerns is that my statement could have been interpreted as implying something like "it's okay to insert poor-quality information on non-English Wikipedias because their standards are lower". I apologize if I gave the impression that I would approve of a non-English language edition of Wikipedia being on the receiving end of an unwelcome large addition of information that requires significant effort to clean up. Hopefully my response here will address the concerns that I heard off list, and if not then I welcome additional feedback. Thanks, Pine ( https://meta.wikimedia.org/wiki/User:Pine ) ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
On 20/10/2018 00:41, Stas Malyshev wrote: Hi! Cparle wants to make sure that people searching for "clarinet" also get shown images of "piccolo clarinet" etc. To make this possible, where an image has been tagged "basset horn" he is therefore looking to add "clarinet" as an additional keyword, so that if somebody types "clarinet" into the search box, one of the images retrieved by ElasticSearch will be the basset horn one. Generally if the image is tagged with "basset horn" and the user query is "clarinet", we can do one of the following: 1. Index all upstream-hierarchy for "basset horn" (presumably we would have to cut off when it gets too deep or too abstract) and then match directly when searching. 2. Expand hierarchy down-stream from "clarinet" and then match against search index. 3. Have some manual or automatic process that ensures that both "clarinet" and "basset horn" are indexed (not necessarily at once) and rely on it to discover the matches. The problem with (1) is that if hierarchy changes, we will have to do huge number of updates which might overwhelm the system, and most of these updates would be not even for things people search for, but we have no way to know that. The problem with (2) is that downstream hierarchies explode very fast, and if you search for "clarinet" and there are 1 descendants in these hierarchies, we can't search for all of them, so you may never get a chance to find the basset horn. Also, of course, querying big downstream hierarchies takes time too, which means performance hit. Is this such a problem? It is what people now commonly do with P31/P279* queries. For example, finding 10K instances of (some subclass of) building takes 9 secs: http://tinyurl.com/y7e5j5sd (I think this is one of the more complex hierarchies; maybe you know larger downstream hierarchies one could try?) If you omit the labels, it takes 650ms. That's maybe not quite autocompletion speed yet, but seems acceptable for a media search. Cheers, Markus smime.p7s Description: S/MIME Cryptographic Signature ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
Hi! > Cparle wants to make sure that people searching for "clarinet" also get > shown images of "piccolo clarinet" etc. > > To make this possible, where an image has been tagged "basset horn" he > is therefore looking to add "clarinet" as an additional keyword, so that > if somebody types "clarinet" into the search box, one of the images > retrieved by ElasticSearch will be the basset horn one. Generally if the image is tagged with "basset horn" and the user query is "clarinet", we can do one of the following: 1. Index all upstream-hierarchy for "basset horn" (presumably we would have to cut off when it gets too deep or too abstract) and then match directly when searching. 2. Expand hierarchy down-stream from "clarinet" and then match against search index. 3. Have some manual or automatic process that ensures that both "clarinet" and "basset horn" are indexed (not necessarily at once) and rely on it to discover the matches. The problem with (1) is that if hierarchy changes, we will have to do huge number of updates which might overwhelm the system, and most of these updates would be not even for things people search for, but we have no way to know that. The problem with (2) is that downstream hierarchies explode very fast, and if you search for "clarinet" and there are 1 descendants in these hierarchies, we can't search for all of them, so you may never get a chance to find the basset horn. Also, of course, querying big downstream hierarchies takes time too, which means performance hit. -- Stas Malyshev smalys...@wikimedia.org ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
Hi! > possibility to find more results by letting the search engine traverse > the "more-general-than" links stored in Wikidata. People have discovered > cases where some of these links are not correct (surprise! it's a wiki > ;-), and the suggestion was that such glitches would be fixed with > higher priority if there would be an application relying on it. But even The main problem I see here is not that some links are incorrect - which may have bad effects, but it's not the most important issue. The most important one, IMHO, that there's no way to figure out in any scalable and scriptable way what "more-general-than" means for any particular case. It's different for each type of objects and often inconsistent within the same class (e.g. see confusion between whether "dog" is an animal, a name of the animal, name of the taxon, etc.) It's not that navigating the hierarchy would lead as astray - we're not even there yet to have this problem, because we don't even have a good way to navigate it. Using instance-of/subclass-of only seems to not be that useful, because a lot of interesting things are not represented in this way - e.g. finding out that Donna Strickland (Q56855591) is a woman (Q467) is impossible using only this hierarchy. We could special-case a bunch of those but given how diverse Wikidata is, I don't think this will ever cover any significant part of the hierarchy unless we find a non-ad-hoc method of doing this. This also makes it particularly hard to do something like "let's start using it and fix the issues as we discover them", because the main issue here is that we don't have a way to start with anything useful beyond a tiny subset of classes that we can special-case manually. We can't launch a rocket and figure how to build the engine later - having a working engine is a prerequisite to launching the rocket! There are also significant technical challenges in this - indexing dynamically changing hierarchy is very problematic, and with our approach to ontology anything can be a class, so we'd have to constantly update the hierarchy. But this is more of a technical challenge, which will come after we have some solution for the above. -- Stas Malyshev smalys...@wikimedia.org ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Commented On] T158430: [Spike] Use suggested properties to get signal for completeness
Halfak added a comment. I just implemented https://github.com/wikimedia/revscoring/pull/414 which will give us a datasource on top of which to build the feature @hoo has been working on.TASK DETAILhttps://phabricator.wikimedia.org/T158430EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: HalfakCc: hoo, PokestarFan, daniel, Sjoerddebruin, Ladsgroup, Glorian_Yapinus, Sumit, Ricordisamoa, Aklapper, StudiesWorld, Lydia_Pintscher, samuwmde, Glorian_WD, Halfak, Nandana, Lahi, Gq86, Vacio, Capankajsmilyo, GoranSMilovanovic, Fz-29, QZanden, LawExplorer, notconfusing, Wikidata-bugs, aude, Alchimista, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193691: As a user of the Wikipedia app, I would like to be able to add or edit title descriptions from the app (eg. Wikidata descriptions)
ABorbaWMF added a comment. F26638528: IMG_0075.PNG F26638529: IMG_0076.PNG F26638519: IMG_2356.PNGTASK DETAILhttps://phabricator.wikimedia.org/T193691EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mhurd, ABorbaWMFCc: ABorbaWMF, Sjoerddebruin, JMinor, PDrouin-WMF, Aklapper, Mhurd, cmadeo, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Taquo, LawExplorer, catalandres, Karthik_sripal, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T193691: As a user of the Wikipedia app, I would like to be able to add or edit title descriptions from the app (eg. Wikidata descriptions)
ABorbaWMF moved this task from Ready for PM Signoff to Needs QA on the iOS-app-v6.1-Narwhal-On-A-Bumper-Car board.ABorbaWMF added a comment. Moving back to QA. Need additional language testing.TASK DETAILhttps://phabricator.wikimedia.org/T193691WORKBOARDhttps://phabricator.wikimedia.org/project/board/3519/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mhurd, ABorbaWMFCc: ABorbaWMF, Sjoerddebruin, JMinor, PDrouin-WMF, Aklapper, Mhurd, cmadeo, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Taquo, LawExplorer, catalandres, Karthik_sripal, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T193691: As a user of the Wikipedia app, I would like to be able to add or edit title descriptions from the app (eg. Wikidata descriptions)
ABorbaWMF moved this task from Needs QA to Ready for PM Signoff on the iOS-app-v6.1-Narwhal-On-A-Bumper-Car board.ABorbaWMF added a comment. Initially tested on 6.1.0 (1502) and I did not see the revert notification, but I just installed 6.1.0 (1503) and saw the notifications. LGTMTASK DETAILhttps://phabricator.wikimedia.org/T193691WORKBOARDhttps://phabricator.wikimedia.org/project/board/3519/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mhurd, ABorbaWMFCc: ABorbaWMF, Sjoerddebruin, JMinor, PDrouin-WMF, Aklapper, Mhurd, cmadeo, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Taquo, LawExplorer, catalandres, Karthik_sripal, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
cscott added a comment. OK, two patches to fix the issue: belt and suspenders. Both of them are potential candidates for cherry-picking to 1.32, but let's get them merged on 1.33 first.TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: gerritbot, Nikerabbit, cscott, Aklapper, Fomafix, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
gerritbot added a comment. Change 468630 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian): [mediawiki/core@master] Make Language::hasVariant() more strict https://gerrit.wikimedia.org/r/468630TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Nikerabbit, cscott, Aklapper, Fomafix, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
gerritbot added a project: Patch-For-Review. TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Nikerabbit, cscott, Aklapper, Fomafix, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
gerritbot added a comment. Change 468589 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian): [mediawiki/core@master] Include BCP 47 codes in $wgDummyLanguageCodes, but deprecate it https://gerrit.wikimedia.org/r/468589TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Nikerabbit, cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207133: SPARQL service returns entities with broken URLs
Jkbr added a comment. We have been having the same issues on ScienceSource this week. We now have a working Query Service. (We have definitely found we need a large VM instance to run the current stack if we want any memory left to start a process for docker ps.) To get rid of the com.bigdata.rdf.vocab.BaseVocabulary$VocabularyVersioningException I had to ensure that the Blazegraph data store was recreated. I tried deleting data/data.jnl and it successfully recreated the data now including the correct URLs (not wikibase,svc). This is our docker-compose.yml -- most of the instances of 'wikibase.svc' have been replaced by the URL for our site: https://github.com/ContentMine/wikibase-docker/blob/master/docker-compose.ymlTASK DETAILhttps://phabricator.wikimedia.org/T207133EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, JkbrCc: Jkbr, Jneubert, TerraCodes, Liuxinyu970226, Addshore, Magnus, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T50047: client watchlist shows more than just the last change on the item
stjn added a comment. Since my report I’ve disabled Wikidata edits entirely because having frequently edited items in your watchlist with Wikidata edits enabled is a massive pain for users in default configuration.TASK DETAILhttps://phabricator.wikimedia.org/T50047EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, stjnCc: stjn, Aklapper, Legoktm, Denny, Snaterlicious, wctaiwan, Lydia_Pintscher, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T199121: RFC: Spec for representing multiple content objects per revision (MCR) in XML dumps
kchapman added a comment. TechCom has moved Last Call to end Wednesday 31 October 2pm PST (21:00 UTC, 22:00 CET). This is due to no TechCom meeting next week to vote on final approval.TASK DETAILhttps://phabricator.wikimedia.org/T199121EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ArielGlenn, kchapmanCc: mako, FaFlo, Halfak, vrandezo, Denny, kchapman, tstarling, awight, JAllemandou, hoo, pmiazga, Nemo_bis, brion, Tgr, Aklapper, Fjalapeno, ArielGlenn, daniel, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, JJMC89, Agabi10, D3r1ck01, SBisson, gnosygnu, Wikidata-bugs, aude, GWicke, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T206863: Enable mobile-specific html to be rendered within Wikibase
gerritbot added a project: Patch-For-Review. TASK DETAILhttps://phabricator.wikimedia.org/T206863EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDE, gerritbotCc: gerritbot, Aklapper, Jakob_WMDE, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T206863: Enable mobile-specific html to be rendered within Wikibase
gerritbot added a comment. Change 468329 had a related patch set uploaded (by Jakob; owner: Jakob): [mediawiki/extensions/Wikibase@master] Render different EntityTermsView for mobile devices https://gerrit.wikimedia.org/r/468329TASK DETAILhttps://phabricator.wikimedia.org/T206863EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDE, gerritbotCc: gerritbot, Aklapper, Jakob_WMDE, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T207484: API to efficiently format large numbers of entity IDs
LucasWerkmeister created this task.LucasWerkmeister added a project: Wikidata.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTIONAs a Wikidata tool author, I often need to render a lot of entity ID references to the user, in a readable form (e. g. using their labels). Problem: Currently, I have two options for this, each with advantages and drawbacks. I can use the wbgetentities API to fetch the relevant information for all the entities I need. The big advantage of this API is that it lets me retrieve information for up to 50 entities at once, which cuts down on a lot of network requests. But all I get is raw entity data, nothing I can directly show to the user: this is bad enough if I’m just interested in items and properties (it means I have to go through the labels and implement language fallbacks myself) and even worse if I want to support all entity types (which means I need to rebuild Wikibase’ logic to render lexemes using their lemmas, forms using their representations, senses using their glosses and their lexeme’s lemmas (did I even download these?), etc.). I can use the wbformatvalue API to render a single datavalue into wikitext or HTML. Here, Wikibase does all the work for me – I just have to deal with the slightly baroque input format (provide a full datavalue instead of a plain entity ID), and I still need to know which entity type the ID refers to in order to provide the datatype argument. But the big problem with this is that I can only render one entity ID per API call: if I want to render 100 entity IDs, I need to make 100 network requests. I think a combination of these – an API that accepts a list of entity IDs and formats them like entity ID data values – would be useful to a lot of tools. (wb_terms is another option for server-side Toolforge-based tools, but we’re migrating away from that anyways, see T198866.) Example: Tools that I think could benefit from this include: QuickStatements (batch view) Wikidata Graph Builder (graph node labels) Wikidata Recent Changes (“title” of changed pages) Wikidata Vandalism Dashboard (ditto) Wikidata Reconciliation / OpenRefine (reconciliation results) TABernacle (entity ID cells) possibly some other tools that currently use wb_terms for this, see T197161 Open questions: Should this API also support mass-rendering other types of datavalues (quantities, dates, etc.)? But I don’t see how to accommodate that with a simple API. TASK DETAILhttps://phabricator.wikimedia.org/T207484EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LucasWerkmeisterCc: Aklapper, LucasWerkmeister, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207479: InvalidArgumentException in LexemeIdHtmlFormatter when passing form or sense ID
Lucas_Werkmeister_WMDE added a comment.
The similar mistake of attempting to format a form ID value as a sense datatype results in a PHP Fatal Error:
PHP Fatal Error: Argument 1 passed to Wikibase\Lexeme\DataModel\Lexeme::getSense() must be an instance of Wikibase\Lexeme\DataModel\SenseId, Wikibase\Lexeme\DataModel\FormId given
#0 /srv/mediawiki/php-1.32.0-wmf.26/extensions/WikibaseLexeme/src/Formatters/SenseIdHtmlFormatter.php(85): NO_FUNCTION_GIVEN()
#1 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/Formatters/EntityIdValueFormatter.php(44): Wikibase\Lexeme\Formatters\SenseIdHtmlFormatter->formatEntityId(Wikibase\Lexeme\DataModel\FormId)
#2 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/Formatters/DispatchingValueFormatter.php(75): Wikibase\Lib\EntityIdValueFormatter->format(Wikibase\DataModel\Entity\EntityIdValue)
#3 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/repo/includes/Api/FormatSnakValue.php(104): Wikibase\Lib\Formatters\DispatchingValueFormatter->formatValue(Wikibase\DataModel\Entity\EntityIdValue, string)
#4 /srv/mediawiki/php-1.32.0-wmf.26/includes/api/ApiMain.php(1570): Wikibase\Repo\Api\FormatSnakValue->execute()
#5 /srv/mediawiki/php-1.32.0-wmf.26/includes/api/ApiMain.php(531): ApiMain->executeAction()
#6 /srv/mediawiki/php-1.32.0-wmf.26/includes/api/ApiMain.php(502): ApiMain->executeActionWithErrorHandling()
#7 /srv/mediawiki/php-1.32.0-wmf.26/api.php(87): ApiMain->execute()
#8 /srv/mediawiki/w/api.php(3): include(string)
#9 {main}TASK DETAILhttps://phabricator.wikimedia.org/T207479EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Lucas_Werkmeister_WMDE, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Jdforrester-WMF, Mbch331, Jay8g, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T207479: InvalidArgumentException in LexemeIdHtmlFormatter when passing form or sense ID
Lucas_Werkmeister_WMDE created this task.Lucas_Werkmeister_WMDE added projects: Wikidata, Lexicographical data, Wikimedia-production-error.
TASK DESCRIPTIONI accidentally made the following API request:
action="">
i. e., attempting to format a form ID value ({"type":"wikibase-entityid", "value": {"id":"L10-F3"}}) as a lexeme datatype.
It results in the following log error:
InvalidArgumentException: Not a lexeme ID: L10-F3
/srv/mediawiki/php-1.32.0-wmf.26/extensions/WikibaseLexeme/src/Formatters/LexemeIdHtmlFormatter.php:58
#0 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/Formatters/EntityIdValueFormatter.php(44): Wikibase\Lexeme\Formatters\LexemeIdHtmlFormatter->formatEntityId(Wikibase\Lexeme\DataModel\FormId)
#1 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/Formatters/DispatchingValueFormatter.php(75): Wikibase\Lib\EntityIdValueFormatter->format(Wikibase\DataModel\Entity\EntityIdValue)
#2 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/repo/includes/Api/FormatSnakValue.php(104): Wikibase\Lib\Formatters\DispatchingValueFormatter->formatValue(Wikibase\DataModel\Entity\EntityIdValue, string)
#3 /srv/mediawiki/php-1.32.0-wmf.26/includes/api/ApiMain.php(1570): Wikibase\Repo\Api\FormatSnakValue->execute()
#4 /srv/mediawiki/php-1.32.0-wmf.26/includes/api/ApiMain.php(531): ApiMain->executeAction()
#5 /srv/mediawiki/php-1.32.0-wmf.26/includes/api/ApiMain.php(502): ApiMain->executeActionWithErrorHandling()
#6 /srv/mediawiki/php-1.32.0-wmf.26/api.php(87): ApiMain->execute()
#7 /srv/mediawiki/w/api.php(3): include(string)
#8 {main}
I suppose we need to guard against this somewhere, since API usage errors shouldn’t result in uncaught exceptions.TASK DETAILhttps://phabricator.wikimedia.org/T207479EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Lucas_Werkmeister_WMDE, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Jdforrester-WMF, Mbch331, Jay8g, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
cscott added a comment. Ah, ok, thanks! That means I don't have to worry about this being an "unbreak now" sort of bug. https://gerrit.wikimedia.org/r/468589 is a stopgap at fixing the issue, but there's a deeper confusion between BCP 47 and mediawiki internal codes which is causing the BCP 47 codes to make it into Wikibase's LanguageFallbackChain. Still working on that...TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Nikerabbit, cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T206597: Refactor 'use_git_deploy' in wdqs puppet module to cater for scap3 and autodeployment modes
debt closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T206597EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mathew.onipe, debtCc: gerritbot, Aklapper, Smalyshev, Gehel, Mathew.onipe, CucyNoiD, Nandana, NebulousIris, thifranc, AndyTan, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Davinaclare77, Adrian1985, Qtn1293, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, EBjune, merbst, LawExplorer, Avner, Lewizho99, Zppix, Maathavan, Jonas, FloNight, Xmlizer, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, faidon, Mbch331, Jay8g, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
Fomafix added a comment. I generated the URLs containing uselang=sr-cyrl myself. They are not generated by a link.TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: FomafixCc: Nikerabbit, cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T206518: Add wikibase-termbox to Wikibase
gerritbot added a comment. Change 466933 abandoned by Jakob: Load the dist files from wikibase-termbox Reason: Done as part of Id127dc87348d30ff011a32760038fbc74335da1e https://gerrit.wikimedia.org/r/466933TASK DETAILhttps://phabricator.wikimedia.org/T206518EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Aklapper, Jakob_WMDE, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
cscott added a comment. Agh. WikiBase/lib/includes/LanguageWithConversion.php contains code cut-and-pasted from mediawiki-core. Anyone want to guess the odds that it wasn't updated when the code from core was updated?TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Nikerabbit, cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
cscott added a comment. Ok, merged T207447: uselang=zh-hant-hk causes fatal exception of type "BadMethodCallException" into this one, because the stack trace is pretty much identical: This bug T207433, request ID W8llMwpAMEsAACb4rOcW: 0 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/LanguageWithConversion.php(260): SrConverter->translate(string, string) #1 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/LanguageWithConversion.php(225): Wikibase\LanguageWithConversion->executeTranslate() #2 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/LanguageFallbackChain.php(88): Wikibase\LanguageWithConversion->translate(string) #3 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/Store/LanguageFallbackLabelDescriptionLookup.php(81): Wikibase\LanguageFallbackChain->extractPreferredValue(array) #4 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/lib/includes/Store/LanguageFallbackLabelDescriptionLookup.php(53): Wikibase\Lib\Store\LanguageFallbackLabelDescriptionLookup->getTermFallback(array, array) #5 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/client/includes/Usage/UsageTrackingLanguageFallbackLabelDescriptionLookup.php(72): Wikibase\Lib\Store\LanguageFallbackLabelDescriptionLookup->getLabel(Wikibase\DataModel\Entity\PropertyId) #6 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/client/includes/DataAccess/Scribunto/WikibaseLanguageDependentLuaBindings.php(60): Wikibase\Client\Usage\UsageTrackingLanguageFallbackLabelDescriptionLookup->getLabel(Wikibase\DataModel\Entity\PropertyId) #7 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Wikibase/client/includes/DataAccess/Scribunto/Scribunto_LuaWikibaseLibrary.php(546): Wikibase\Client\DataAccess\Scribunto\WikibaseLanguageDependentLuaBindings->getLabel(string) #8 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Scribunto/includes/engines/LuaSandbox/Engine.php(393): Wikibase\Client\DataAccess\Scribunto\Scribunto_LuaWikibaseLibrary->getLabel(string) #9 [internal function]: Scribunto_LuaSandboxCallback->__call(string, array) #10 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Scribunto/includes/engines/LuaSandbox/Engine.php(316): LuaSandboxFunction->call(LuaSandboxFunction) #11 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Scribunto/includes/engines/LuaCommon/LuaCommon.php(295): Scribunto_LuaSandboxInterpreter->callFunction(LuaSandboxFunction, LuaSandboxFunction) #12 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Scribunto/includes/engines/LuaCommon/LuaCommon.php(967): Scribunto_LuaEngine->executeFunctionChunk(LuaSandboxFunction, PPTemplateFrame_Hash) #13 /srv/mediawiki/php-1.32.0-wmf.26/extensions/Scribunto/includes/common/Hooks.php(128): Scribunto_LuaModule->invoke(string, PPTemplateFrame_Hash) #14 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(3493): ScribuntoHooks::invokeHook(Parser, PPTemplateFrame_Hash, array) #15 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(3200): Parser->callParserFunction(PPTemplateFrame_Hash, string, array) #16 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Preprocessor_Hash.php(1114): Parser->braceSubstitution(array, PPTemplateFrame_Hash) #17 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(3374): PPFrame_Hash->expand(PPNode_Hash_Tree) #18 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Preprocessor_Hash.php(1114): Parser->braceSubstitution(array, PPTemplateFrame_Hash) #19 /srv/mediawiki/php-1.32.0-wmf.26/extensions/ParserFunctions/includes/ExtParserFunctions.php(127): PPFrame_Hash->expand(PPNode_Hash_Tree) #20 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(3493): ExtParserFunctions::ifeqObj(Parser, PPTemplateFrame_Hash, array) #21 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(3200): Parser->callParserFunction(PPTemplateFrame_Hash, string, array) #22 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Preprocessor_Hash.php(1114): Parser->braceSubstitution(array, PPTemplateFrame_Hash) #23 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(3374): PPFrame_Hash->expand(PPNode_Hash_Tree) #24 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Preprocessor_Hash.php(1114): Parser->braceSubstitution(array, PPFrame_Hash) #25 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(3014): PPFrame_Hash->expand(PPNode_Hash_Tree, integer) #26 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(1350): Parser->replaceVariables(string) #27 /srv/mediawiki/php-1.32.0-wmf.26/includes/parser/Parser.php(476): Parser->internalParse(string) #28 /srv/mediawiki/php-1.32.0-wmf.26/includes/content/WikitextContent.php(341): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer) #29 /srv/mediawiki/php-1.32.0-wmf.26/includes/content/AbstractContent.php(517): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput) #30 /srv/mediawiki/php-1.32.0-wmf.26/includes/Revision/RenderedRevision.php(243): AbstractContent->getParserOutput(Title, integer, ParserOptions, boolean) #31
[Wikidata-bugs] [Maniphest] [Updated] T207447: uselang=zh-hant-hk causes fatal exception of type "BadMethodCallException"
cscott closed this task as a duplicate of T207433: uselang=sr-cyrl causes fatal exception of type "MWException". TASK DETAILhttps://phabricator.wikimedia.org/T207447EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Nikerabbit, Aklapper, cscott, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Merged] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
cscott merged a task: T207447: uselang=zh-hant-hk causes fatal exception of type "BadMethodCallException". TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Nikerabbit, cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reopened] T205063: Merge WikibaseQuality and WikibaseQualityConstraints
Tarrow reopened this task as "Open".Tarrow added a comment. Looks like at least some of the HTML classes weren't changed over: see e.g. WikibaseQuality\Html\HtmlTableBuilder still present on extensions/WikibaseQualityConstraints/src/Specials/SpecialConstraintReport.php#38 This should have been caught by the tests but apparently not. I'm looking into that as part of T206205TASK DETAILhttps://phabricator.wikimedia.org/T205063EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JeroenDeDauw, TarrowCc: Tarrow, gerritbot, Aklapper, Addshore, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, merbst, LawExplorer, Lewizho99, Maathavan, Agabi10, Scott_WUaS, abian, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Block] T205062: Reorganizing Wikibase Quality extensions
Tarrow reopened subtask T205063: Merge WikibaseQuality and WikibaseQualityConstraints as "Open". TASK DETAILhttps://phabricator.wikimedia.org/T205062EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TarrowCc: abian, Aklapper, Addshore, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, merbst, LawExplorer, Agabi10, Scott_WUaS, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Block] T205064: Undeploy WikibaseQuality extension from the WMF
Tarrow reopened subtask T205063: Merge WikibaseQuality and WikibaseQualityConstraints as "Open". TASK DETAILhttps://phabricator.wikimedia.org/T205064EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TarrowCc: Aklapper, Addshore, Nandana, NebulousIris, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, merbst, LawExplorer, Agabi10, Liudvikas, Scott_WUaS, Jonas, Luke081515, abian, Wikidata-bugs, aude, Lydia_Pintscher, zeljkofilipin, Mbch331, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207133: SPARQL service returns entities with broken URLs
Magnus added a comment. Can I give you (or can you just get) access to my VM? mixnmatch in the mix-n-match project.TASK DETAILhttps://phabricator.wikimedia.org/T207133EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, MagnusCc: Jneubert, TerraCodes, Liuxinyu970226, Addshore, Magnus, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T206560: [Epic] Evaluate alternatives to Blazegraph
Gehel added a comment. A few wishes I have from an operations point of view for any replacement. Those are not necessarily mandatory, but we should evaluate them at some point: ability to scale both read and write load across multiple nodes ability to limit resource consumption to fail gracefully TASK DETAILhttps://phabricator.wikimedia.org/T206560EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: Gehel, Lucas_Werkmeister_WMDE, Aklapper, Smalyshev, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T120847: Use BCP 47 conform language codes for the HTML attribute lang
Fomafix closed this task as "Resolved".Fomafix added a comment. https://validator.w3.org/nu/?doc=https://www.wikidata.org/wiki/Q5296 reports no problem anymore.TASK DETAILhttps://phabricator.wikimedia.org/T120847EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscott, FomafixCc: Jdforrester-WMF, gerritbot, cscott, Lydia_Pintscher, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T207469: Apply styles and markup according to the visual mockups
Jakob_WMDE created this task.Jakob_WMDE triaged this task as "Normal" priority.Jakob_WMDE added projects: Wikidata, Wikidata Mobile, Wikidata-Termbox-Iteration-2.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTIONTASK DETAILhttps://phabricator.wikimedia.org/T207469EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDECc: Aklapper, Jakob_WMDE, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T207467: Server: pass entity terms data
Jakob_WMDE created this task.Jakob_WMDE triaged this task as "Normal" priority.Jakob_WMDE added projects: Wikidata, Wikidata Mobile, Wikidata-Termbox-Iteration-2.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION labels, aliases and descriptions should be part of the http request client and SSR need a common interface to provision the app with entity terms data (likely through the vuex store in order to make it future-proof) TASK DETAILhttps://phabricator.wikimedia.org/T207467EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDECc: Aklapper, Jakob_WMDE, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata] Query example: What other relationships do people have with their spouses?
Sharing a little query example that I just created when looking for interesting cases in the data. In case you are asked "what's your relationship with your spouse" here is a list of most common answers: http://tinyurl.com/ycm8fllo Possibly useful and/or entertaining for other properties as well. Finding all cases where a particular double relationship holds should be an easy exercise. Cheers, Markus -- Prof. Dr. Markus Kroetzsch Knowledge-Based Systems Group Center for Advancing Electronics Dresden (cfaed) Faculty of Computer Science TU Dresden +49 351 463 38486 https://kbs.inf.tu-dresden.de/ smime.p7s Description: S/MIME Cryptographic Signature ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Created] T207465: Add necessary assets as termbox dependencies
Jakob_WMDE created this task.Jakob_WMDE triaged this task as "Normal" priority.Jakob_WMDE added projects: Wikidata, Wikidata Mobile, Wikidata-Termbox-Iteration-2.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION likely only the rtl "edit" pen needs to be specified either in Wikibase in a resources.php or the termbox repo gets its own resources.php that is references from within wikibase Pointers to rtl stuff: https://www.mediawiki.org/wiki/Extension:RevisionSlider/Developing_a_RTL-accessible_feature_in_MediaWiki_-_what_we%27ve_learned_while_creating_the_RevisionSlider https://github.com/wikimedia/mediawiki-extensions-RevisionSlider/blob/master/extension.json TASK DETAILhttps://phabricator.wikimedia.org/T207465EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDECc: Aklapper, Jakob_WMDE, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T206214: Basic data on Wikidata use: Edit counts, frequency
GoranSMilovanovic added a comment. @Jan_Dittrich Thank you for your comments. I will provide all necessary explanations later in the evening.TASK DETAILhttps://phabricator.wikimedia.org/T206214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GoranSMilovanovicCc: Lydia_Pintscher, GoranSMilovanovic, WMDE-leszek, Aklapper, Jan_Dittrich, Nandana, Lahi, Gq86, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T207462: Client: pass entity data to the Termbox component
Jakob_WMDE updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION* access entity object available on the page, either by
** accessing the JSON blob directly or through the global mw services through `mw.config.get('wbEntity')`
* provide some way to pass in mock data for development without a mediawiki/wikibase environmentTASK DETAILhttps://phabricator.wikimedia.org/T207462EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDECc: Aklapper, Jakob_WMDE, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T207462: Client: pass entity data to the Termbox component
Jakob_WMDE created this task.Jakob_WMDE triaged this task as "Normal" priority.Jakob_WMDE added projects: Wikidata, Wikidata Mobile, Wikidata-Termbox-Iteration-2.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION access entity object available on the page, either by accessing the JSON blob directly or through the global mw services provide some way to pass in mock data for development without a mediawiki/wikibase environment TASK DETAILhttps://phabricator.wikimedia.org/T207462EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDECc: Aklapper, Jakob_WMDE, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207133: SPARQL service returns entities with broken URLs
Addshore added a comment.
I just tried running this (see below) which just has elastic search commented out to free up some memory and the updater appears to work fine:
version: '3'
services:
wikibase:
image: wikibase/wikibase:1.30-bundle
links:
- mysql
ports:
# CONFIG - Change the 8181 here to expose Wikibase & MediaWiki on a different port
- "8181:80"
volumes:
- mediawiki-images-data:/var/www/html/images
- ../mixnmatch_wb/interface:/var/www/html/interface
depends_on:
- mysql
#- elasticsearch
networks:
default:
aliases:
- wikibase.svc
- mixnmatch.wmflabs.org
# CONFIG - Add your real wikibase hostname here, for example wikibase-registry.wmflabs.org
environment:
- DB_SERVER=mysql.svc:3306
- MW_ELASTIC_HOST=elasticsearch.svc
- MW_ELASTIC_PORT=9200
# CONFIG - Change the default values below
- MW_ADMIN_NAME=admin
- MW_ADMIN_PASS=*
- MW_WG_SECRET_KEY=*
# CONFIG - Change the default values below (should match mysql values in this file)
- DB_USER=wikiuser
- DB_PASS=*
- DB_NAME=my_wiki
mysql:
image: mariadb:10.3
restart: always
volumes:
- mediawiki-mysql-data:/var/lib/mysql
environment:
MYSQL_RANDOM_ROOT_PASSWORD: 'yes'
# CONFIG - Change the default values below (should match values passed to wikibase)
MYSQL_DATABASE: 'my_wiki'
MYSQL_USER: 'wikiuser'
MYSQL_PASSWORD: '*'
networks:
default:
aliases:
- mysql.svc
wdqs-frontend:
image: wikibase/wdqs-frontend:latest
ports:
# CONFIG - Change the 8282 here to expose the Query Service UI on a different port
- "8282:80"
depends_on:
- wdqs-proxy
networks:
default:
aliases:
- wdqs-frontend.svc
environment:
- WIKIBASE_HOST=mixnmatch.wmflabs.org
- WDQS_HOST=wdqs-proxy.svc
wdqs:
image: wikibase/wdqs:0.3.0
volumes:
- query-service-data:/wdqs/data
command: /runBlazegraph.sh
networks:
default:
aliases:
- wdqs.svc
environment:
- WIKIBASE_HOST=mixnmatch.wmflabs.org
- WDQS_HOST=wdqs.svc
- WDQS_PORT=
expose:
-
wdqs-proxy:
image: wikibase/wdqs-proxy
environment:
- PROXY_PASS_HOST=wdqs.svc:
ports:
- "8989:80"
depends_on:
- wdqs
networks:
default:
aliases:
- wdqs-proxy.svc
wdqs-updater:
image: wikibase/wdqs:0.3.0
command: /runUpdate.sh
depends_on:
- wdqs
- wikibase
networks:
default:
aliases:
- wdqs-updater.svc
environment:
- WIKIBASE_HOST=mixnmatch.wmflabs.org
- WDQS_HOST=wdqs.svc
- WDQS_PORT=
# elasticsearch:
#image: elasticsearch@sha256:f1dbf2019dc9a4ca5dd458635bfb31f9a601e4905e1d6ca1d65a3958d428f497
#networks:
# default:
#aliases:
# - elasticsearch.svc
#environment:
# discovery.type: single-node
# # CONFING, in order to not load quickstatements then remove this entire section
# quickstatements:
#image: wikibase/quickstatements:latest
#ports:
# - "9191:80"
#depends_on:
#- wikibase
#networks:
# default:
#aliases:
# - quickstatements.svc
#environment:
# # CONFIG, you have to config this if you want quickstatements
# - OAUTH_CONSUMER_KEY=*
# - OAUTH_CONSUMER_SECRET=*
# - QS_PUBLIC_SCHEME_HOST_AND_PORT=https://mixnmatch-qs.wmflabs.org
# - WB_PUBLIC_SCHEME_HOST_AND_PORT=https://mixnmatch.wmflabs.org
# - WIKIBASE_SCHEME_AND_HOST=http://wikibase.svc
# - WB_PROPERTY_NAMESPACE=122
# - "WB_PROPERTY_PREFIX=Property:"
# - WB_ITEM_NAMESPACE=120
# - "WB_ITEM_PREFIX=Item:"
volumes:
mediawiki-mysql-data:
mediawiki-images-data:
query-service-data:
Updater logs:
wdqs-updater_1 | wait-for-it.sh: mixnmatch.wmflabs.org:80 is available after 73 seconds
wdqs-updater_1 | wait-for-it.sh: waiting 120 seconds for wdqs.svc:
wdqs-updater_1 | wait-for-it.sh: wdqs.svc: is available after 0 seconds
wdqs-updater_1 | Updating via http://wdqs.svc:/bigdata/namespace/wdq/sparql
wdqs-updater_1 | OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid8.log due to No such file or directory
wdqs-updater_1 |
wdqs-updater_1 | I> No access restrictor found, access to any MBean is allowed
wdqs-updater_1 | Jolokia: Agent started with URL http://127.0.0.1:8778/jolokia/
wdqs-updater_1 | #logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
wdqs-updater_1 | 12:37:14.115 [main] INFO org.wikidata.query.rdf.tool.Update - Checking where we left off
wdqs-updater_1 | 12:37:14.131 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - Checking for left off time from the updater
wdqs-updater_1 | 12:37:15.449 [main]
[Wikidata-bugs] [Maniphest] [Commented On] T207133: SPARQL service returns entities with broken URLs
Addshore added a comment. Looks like I can't actually run that exact docker-compose file locally as I apparently don't have enough memory with everything else running on my laptop. Let me try and grab a labs VM to test onTASK DETAILhttps://phabricator.wikimedia.org/T207133EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Jneubert, TerraCodes, Liuxinyu970226, Addshore, Magnus, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T206205: WBQC_ResultsSource ConstraintsServices not tested in CI for WikibaseQualityConstraints
Lucas_Werkmeister_WMDE added a comment. So we copied over the Html classes from WikibaseQuality into WikibaseQualityConstraints, but didn’t update the imports to refer to the WBQC versions? Sounds like T205063: Merge WikibaseQuality and WikibaseQualityConstraints isn’t done yet, then (or at least we can’t proceed with T205064: Undeploy WikibaseQuality extension from the WMF yet).TASK DETAILhttps://phabricator.wikimedia.org/T206205EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tarrow, Lucas_Werkmeister_WMDECc: Tarrow, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Claimed] T206205: WBQC_ResultsSource ConstraintsServices not tested in CI for WikibaseQualityConstraints
Tarrow claimed this task.Tarrow added a comment.
Looks like other things may also not being being properly run:
Locally I get failures like this:
1) WikibaseQuality\ConstraintReport\Tests\Specials\SpecialConstraintReportTest::testExecute with data set "valid input - existing item" ('$id', array(), 'qqx', array(Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), WMDE\HamcrestHtml\ComplexTagMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...), Hamcrest\Core\CombinableMatcher Object (...)))
Error: Class 'WikibaseQuality\Html\HtmlTableBuilder' not found
/var/www/mediawiki/extensions/WikibaseQualityConstraints/src/Specials/SpecialConstraintReport.php:362
/var/www/mediawiki/extensions/WikibaseQualityConstraints/src/Specials/SpecialConstraintReport.php:269
/var/www/mediawiki/tests/phpunit/includes/specials/SpecialPageExecutor.php:108
/var/www/mediawiki/tests/phpunit/includes/specials/SpecialPageExecutor.php:36
/var/www/mediawiki/tests/phpunit/includes/specials/SpecialPageTestBase.php:70
/var/www/mediawiki/extensions/WikibaseQualityConstraints/tests/phpunit/Specials/SpecialConstraintReportTest.php:153
/var/www/mediawiki/tests/phpunit/MediaWikiTestCase.php:424
/var/www/mediawiki/maintenance/doMaintenance.php:94
which are not occurring on CI.TASK DETAILhttps://phabricator.wikimedia.org/T206205EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TarrowCc: Tarrow, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207395: Return CTRL-Space hint text to Wikidata Query Tool
Lucas_Werkmeister_WMDE added a comment. The text still appears any time you press : as a “toast” in the lower right screen corner: F26633368: Screen Shot 2018-10-19 at 14.04.15.png It only stops appearing if you actively close the toast by clicking its “close” button before it vanishes on its own after a few seconds.TASK DETAILhttps://phabricator.wikimedia.org/T207395EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Lucas_Werkmeister_WMDE, Sadads, Fuzheado, Gamaliel, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T206214: Basic data on Wikidata use: Edit counts, frequency
Jan_Dittrich added a comment. @GoranSMilovanovic thanks! Some questions for understanding it right: – 1 – 1.1. "Q1.1 Checking for power-law behavior" has two log scaled axis, if I read it correctly. I do not get what the numerical labels on the y axis mean – is this number of users, but after log transformation, so 1 users becomes 9.21… on the log scale? The log is a natural logarithm, correct? (2.718281828459…) F26633276: image.png – 1.2. Q1.2 and Q1.3 show the same data as Q1.1, but in natural numbers without transformations, F26633280: image.png – 1.3. The diagrams tell "We have many accounts that edited a few times and a small amount of accounts which edit(ed) a lot" – 1.4. To clarify, this is how many revisions a specific account has created until the data was acquired? (I call "revisions" "edits", it seems then) – 2.1 Q2.x are like 1.x, but only for september 2018. – 2.2 The diagrams tell "recent edit counts by user follow the same pattern (log) as the general edit count distribution" – 3. Q3 The diagrams are indeed tricky to read. I would read the crosstabular one like a scatterplot, however, in this case, it would need jitter, would it? Maybe a "heatmap" like approach might also be OK: A 2-D-bin would be darker if more edit/discussion counts fall into it. – 4. Q4.2 is again a diagram I am unable to read well. Could it be that the labels are off? X seems to show dates, but y seems to show dates (year-month), too, but log scaled? So I could not make sense of it.TASK DETAILhttps://phabricator.wikimedia.org/T206214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GoranSMilovanovic, Jan_DittrichCc: Lydia_Pintscher, GoranSMilovanovic, WMDE-leszek, Aklapper, Jan_Dittrich, Nandana, Lahi, Gq86, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
cscott added a comment. Also -- sr-cyrl, zh-hans-tw, etc are not actually the mediawiki-internal names for these languages. https://gerrit.wikimedia.org/r/460039 would have added support for using the standard names, but I'm a little bit surprised that anything is generating links to these "non-mediawiki" (but BCP 47 standard) codes. I mean, it's good -- we *should* be trying to move to using the proper BCP 47 codes -- but it's worth trying to track down where these links are coming from, since they wouldn't have worked prior to 460039.TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Lowered Priority] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Addshore lowered the priority of this task from "Unbreak Now!" to "High".Addshore moved this task from Doing to Needs Announcement on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.Addshore added a subscriber: Lea_Lacroix_WMDE.Addshore added a comment. All of the example pages linked in the description now load again. Changing prio to High to avoid this being listed in the lists of UBNs Moving to announce now as T207313#4680020 may need announcing?TASK DETAILhttps://phabricator.wikimedia.org/T207313WORKBOARDhttps://phabricator.wikimedia.org/project/board/3539/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Lea_Lacroix_WMDE, Stashbot, Ladsgroup, gerritbot, TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Stashbot added a comment. Mentioned in SAL (#wikimedia-operations) [2018-10-19T11:33:09Z] Synchronized wmf-config/InitialiseSettings.php: T207313 UBN - Revert back wikidata for change_tag backend (duration: 00m 59s)TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, StashbotCc: Stashbot, Ladsgroup, gerritbot, TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
gerritbot added a comment. Change 468547 merged by jenkins-bot: [operations/mediawiki-config@master] Revert back wikidata for change_tag backend https://gerrit.wikimedia.org/r/468547TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, gerritbotCc: Ladsgroup, gerritbot, TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
cscott added a comment. Given that uselang processing is involved, perhaps Ica89d9547c58967747ab0fa15d4e83be5378796d is the proximate cause. Can we get a stack trace for that exception?TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Ladsgroup added a comment. The very likely cause is T194164: Start reading from change_tag_def in production. We are going to roll this back for wikidata which means tags made between Wed, Oct 17, 1:40 PM until the time of deploy won't be usable after the rollback, but it's temporarily measure until we fix the underlying issue and turn reading from the new column back on, no data is lost, it's just stored in a new format. If such cases is happening for other wikis, feel free to revert them too.TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, LadsgroupCc: Ladsgroup, gerritbot, TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
gerritbot added a project: Patch-For-Review. TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, gerritbotCc: gerritbot, TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
gerritbot added a comment. Change 468547 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup): [operations/mediawiki-config@master] Revert back wikidata for change_tag backend https://gerrit.wikimedia.org/r/468547TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, gerritbotCc: gerritbot, TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T186006: References aren't readable to logged-out users on Wikidata when an item is protected
Lea_Lacroix_WMDE added a comment. The issue was mentioned again here.TASK DETAILhttps://phabricator.wikimedia.org/T186006EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lea_Lacroix_WMDECc: Lea_Lacroix_WMDE, Nikki, Pablo-WMDE, matej_suchanek, Lydia_Pintscher, Aklapper, Mike_Peel, Nandana, tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, Jrbranaa, JakeTheDeveloper, QZanden, merbst, LawExplorer, Wong128hk, Wikidata-bugs, aude, TheDJ, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
On 19/10/2018 12:32, Luca Martinelli wrote: Il giorno ven 19 ott 2018 alle ore 01:09 James Heald ha scritto: But the taxo project has become such a walled garden, answerable only to itself, that people with comments may need to be quite forceful to get their message through, if we are to deal eg with some of the difficulties Cparle describes in the ticket [...] Me and other admins are unfortunately aware of this and this is exactly what I was referring to in my previous e-mail. I do agree with you the situation there is frankly unbearable, and IMHO it will likely be ended also through "removals" of some users who think they should be the only one in charge of deciding what's good and what's not. You might easily understand why this situation deteriorated like this, but I acknowledge this is no excuse for it to continue. Re this tricky situation, it might be good that the taxonomy part of Wikidata avoid the use of "subclass of" altogether. Doesn't this open up a path for compromise? Wikidata could intentionally "overload" taxons to also refer to sets of organisms (in some cases). The taxonomic model would not be affected by this in any way, since it ignores "subclass of". Some (historic or debated) taxons could be ignored for this "colloquial" subclass hierarchy, while other merely colloquially defined classes of animals could be put in relation to proper species. I think such overloading is acceptable as long as there cannot be confusion between which statement refers to which facet of the concept. Then no use of either facet will be impaired by the presence of the "irrelevant" extra data. The only alternative seems to build a "mirror taxonomy" that consists not of taxon names but of animal classes (and that would include "dog" somewhere in its hierarchy [1]). But then we will need a community-wide decision on which of the two (class of organisms vs. scientific name) is the subject of actual Wikipedia articles, which might be a difficult topic to discuss. Alternatively, if the taxons are mostly considered as "names" (syntax) rather than classes of individual organism, then it seems we are actually building a kind of scientific dictionary here that might rather belong into the lexeme space. Whatever happens, this problem needs some solution. Cheers, Markus [1] It seems that the strange position of "dog" is mostly due to the fact that two taxons are associated with it. In general, this seems an important issue (many common names are not clearly specifying a taxon), but in the case of dog it seems that the two taxons are synonyms of one another, i.e., the taxon for dog simply changed names over time. smime.p7s Description: S/MIME Cryptographic Signature ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Commented On] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Addshore added a comment. I don't think this actually relates to T204871, other than the fact that it is about requests timing out.TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Addshore added a comment. Could be related to change tags work T185355TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
Il giorno ven 19 ott 2018 alle ore 01:09 James Heald ha scritto: > But the taxo project has become such a walled garden, answerable only to > itself, that people with comments may need to be quite forceful to get > their message through, if we are to deal eg with some of the > difficulties Cparle describes in the ticket [...] Me and other admins are unfortunately aware of this and this is exactly what I was referring to in my previous e-mail. I do agree with you the situation there is frankly unbearable, and IMHO it will likely be ended also through "removals" of some users who think they should be the only one in charge of deciding what's good and what's not. You might easily understand why this situation deteriorated like this, but I acknowledge this is no excuse for it to continue. L. ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Commented On] T206743: S8 replication issues leading to rows missing during eqiad -> codfw switch (Was: "A few lexemes disappeared")
Marostegui added a comment. Update: pagelinks is now being re-imported on labs (this table is around 136G) so it will take a whileTASK DETAILhttps://phabricator.wikimedia.org/T206743EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MarosteguiCc: ArielGlenn, Banyek, Pigsonthewing, Nikerabbit, gerritbot, WMDE-leszek, jcrespo, mark, Stashbot, Nikki, Marostegui, daniel, TerraCodes, Liuxinyu970226, Addshore, Ladsgroup, Lea_Lacroix_WMDE, Lexicographical data, KaMan, CucyNoiD, Nandana, NebulousIris, jijiki, Mringgaard, AndyTan, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Imarlier, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Minhnv-2809, Volans, Maathavan, Jonas, Johan, Wong128hk, Luke081515, Wikidata-bugs, aude, Lydia_Pintscher, Darkdadaah, He7d3r, TheDJ, Jdforrester-WMF, Mbch331, Jay8g, Krenair, akosiaris, greg, Aklapper___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Addshore added a comment.
All of the links provided seem to result in:
PHP Fatal Error from line 46 of /srv/mediawiki/php-1.32.0-wmf.26/includes/libs/rdbms/database/DatabaseMysqli.php: entire web request took longer than 60 seconds and timed out
They also all seem to have some relation to the log table and the IndexPager and LogPager classes in core.
For example this request https://www.wikidata.org/wiki/Special:Log/addshore result in this sctack:
#0 /srv/mediawiki/php-1.32.0-wmf.26/includes/libs/rdbms/database/DatabaseMysqli.php(46): mysqli::query()
#1 /srv/mediawiki/php-1.32.0-wmf.26/includes/libs/rdbms/database/Database.php(1260): Wikimedia\Rdbms\DatabaseMysqli->doQuery(string)
#2 /srv/mediawiki/php-1.32.0-wmf.26/includes/libs/rdbms/database/Database.php(1183): Wikimedia\Rdbms\Database->doProfiledQuery(string, string, boolean, string)
#3 /srv/mediawiki/php-1.32.0-wmf.26/includes/libs/rdbms/database/Database.php(1693): Wikimedia\Rdbms\Database->query(string, string)
#4 /srv/mediawiki/php-1.32.0-wmf.26/includes/pager/IndexPager.php(369): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)
#5 /srv/mediawiki/php-1.32.0-wmf.26/includes/pager/IndexPager.php(226): IndexPager->reallyDoQuery(string, integer, boolean)
#6 /srv/mediawiki/php-1.32.0-wmf.26/includes/logging/LogPager.php(442): IndexPager->doQuery()
#7 /srv/mediawiki/php-1.32.0-wmf.26/includes/pager/IndexPager.php(423): LogPager->doQuery()
#8 /srv/mediawiki/php-1.32.0-wmf.26/includes/specials/SpecialLog.php(248): IndexPager->getBody()
#9 /srv/mediawiki/php-1.32.0-wmf.26/includes/specials/SpecialLog.php(137): SpecialLog->show(FormOptions, array)
#10 /srv/mediawiki/php-1.32.0-wmf.26/includes/specialpage/SpecialPage.php(569): SpecialLog->execute(string)
#11 /srv/mediawiki/php-1.32.0-wmf.26/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(string)
#12 /srv/mediawiki/php-1.32.0-wmf.26/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#13 /srv/mediawiki/php-1.32.0-wmf.26/includes/MediaWiki.php(860): MediaWiki->performRequest()
#14 /srv/mediawiki/php-1.32.0-wmf.26/includes/MediaWiki.php(517): MediaWiki->main()
#15 /srv/mediawiki/php-1.32.0-wmf.26/index.php(42): MediaWiki->run()
#16 /srv/mediawiki/w/index.php(3): include(string)
#17 {main}
It seems running the request with profiling turned on never reports anything to https://performance.wikimedia.org/xhgui/, perhaps because the request stops? :(TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Addshore added a comment. In T207313#4678604, @Mahir256 wrote: Not sure if this is related, but this page reports a nearly 7-hour replag (as of this comment) for Wikidata's shard (which strangely is not what Special:DispatchStats is reporting). This is fine and likely relates to T206743#4677827TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Addshore edited projects, added Wikidata-Campsite (Wikidata-Campsite-Iteration-∞); removed Wikidata-Campsite. TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Claimed] T207313: Some administrative and log actions on Wikidata take longer than 60 seconds and time out
Addshore claimed this task.Restricted Application added a project: User-Addshore. TASK DETAILhttps://phabricator.wikimedia.org/T207313EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: TerraCodes, Liuxinyu970226, Lydia_Pintscher, Addshore, WMDE-leszek, Sjoerddebruin, Nikki, Krinkle, HakanIST, ValterVB, Pamputt, Mahir256, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Jonas, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T207433: uselang=sr-cyrl causes fatal exception of type "MWException"
Fomafix renamed this task from "uselang=sr-cyrl and uselang=sr-latn causes fatal exception of type "MWException"" to "uselang=sr-cyrl causes fatal exception of type "MWException"".Fomafix updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...* https://www.wikidata.org/w/index.php?title=Wikidata:Glossary="" />
Affected language codes:
* `sr-cyrl`
* `sr-latn`
=== Notes ===
Probably caused by rMW21ead7a98d1a (https://gerrit.wikimedia.org/r/460038).
Related to {T207447}.TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: FomafixCc: cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T207447: uselang=zh-hant-hk causes fatal exception of type "BadMethodCallException"
Fomafix updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...* https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese="" />
Affected language codes:
* `zh-hans-cn`
* `zh-hans-sg`
* `zh-hans-my`
* `zh-hant-tw`
* `zh-hant-hk`
* `zh-hant-mo`
=== Notes ===
Probably caused by rMW21ead7a98d1a (https://gerrit.wikimedia.org/r/460038).
Related to {T207433}.TASK DETAILhttps://phabricator.wikimedia.org/T207447EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: FomafixCc: Aklapper, cscott, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
On 19/10/2018 07:09, Pine W wrote: I would appreciate clarification what is proposed with regard to exposing problematic Wikidata ontology on Wikipedia. If the idea involves inserting poor-quality information onto English Wikipedia in order to spur us to fix problems with Wikidata, then I am likely to oppose it. English Wikipedia is not an endless resource for free labor, and we have too few skilled and good-faith volunteers to handle our already enormous scope of work. You are right, and thankfully this is not what is proposed. The proposal was to offer people who search for Commons media the (maybe optional) possibility to find more results by letting the search engine traverse the "more-general-than" links stored in Wikidata. People have discovered cases where some of these links are not correct (surprise! it's a wiki ;-), and the suggestion was that such glitches would be fixed with higher priority if there would be an application relying on it. But even with some wrong links, the results a searcher would get would still include mostly useful hits. Also, at least half of the currently observed problems with this approach would lead to fewer results (e.g., dogs would be hard to include automatically to a search for all mammals), but in such cases the proposed extension would simply do what the baseline approach (ignoring the links) would do anyway, so service would not get any worse. Also, the manual workarounds suggested by some (adding "mammal" to all pictures of some "dog") would be compatible with this, so one could do both to improve search experience on both ends. Best regards, Markus smime.p7s Description: S/MIME Cryptographic Signature ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
Hi James, On 19/10/2018 01:09, James Heald wrote: On 18/10/2018 22:33, Markus Kroetzsch wrote: And, on another note, there is also a huge misunderstanding exposed in the discussion on th search-related tracker item [1]: Cparle there speaks about "traversing the subclass hierarchy" but is actually looking at *super*classes of, e.g., "Clarinet", which he mostly finds irrelevant to users who care about clarinets. But surely that's the wrong direction! You have to look for *sub*classes to find special cases of what you are looking for. Looking downwards will often lead to much saner ontologies than when turning your head towards the dizzy heights of upper ontology. Yes, the few of us looking for instances of "logical consequence" will still get clarinets, but those who look for instances of clarinet merely will see instances of alto clarinet, piccolo clarinet, basset horn, Saxonette, and so on [2]. So instead of trying to suggest to Commons editors meaningful "upper concepts", one could simply enable the use of lower concepts in search. It does not work in all cases yet, but it many. Not really. Cparle wants to make sure that people searching for "clarinet" also get shown images of "piccolo clarinet" etc. To make this possible, where an image has been tagged "basset horn" he is therefore looking to add "clarinet" as an additional keyword, so that if somebody types "clarinet" into the search box, one of the images retrieved by ElasticSearch will be the basset horn one. I imagine there are pluses and minuses both ways, whether you try to make sure one search returns more hits, or try to run multiple searches each returning fewer hits. Your suggestion of the latter approach may not involve so much pre-investigation of the top of the tree, which may be terms that people are less likely to search for; but on the other hand, the actual searching may be less efficient than a single indexed search. True, but with the Wikidata Query Service we already have infrastructure that completes millions of search requests of this kind (involving path queries), so that seems doable for Commons as well. WDQS already has Wikimedia API bindings that allow it to use Lucene-based results in addition, if needed (though this would only make sense if the search should use some content that for some reason cannot be imported into a query service as graph data, mostly free-text search over longer texts). I think the approach of completing tags towards the upper classes is not a good idea in general, since it creates extra work for editors that requires a million times the resources needed in the other approach: if the subclass hierarchy is wrong, you only need to fix it once to improve search for all existing Commons content; if you rely on manual extra tags, you'd have to add them to every file on Commons and keep it up-to-date with changes in the concepts -- an enormous, redundant effort that will invariably lead to a very non-uniform search experience across otherwise similar media. This seems like a huge waste of editors' time even if it would work (i.e., if we would live in a world where the superclasses of a class would be easy to understand and closely related to the topic that an editor is working on -- which will never happen for Wikidata or Commons, since both cover such a breadth of topics that their upper ontology necessarily has to be very general even if modelled in a clean and fully correct way). Cheers, Markus There are still problems (such as the biological taxonomy being modelled as a hierarchy of names rather than animal classes, placing dog far away from mammal), but it is still always much easier to come up with a sane organisation for the *sub*classes of a concrete class. For what it's worth, there's currently quite a lively discussion on Project Chat about issues with the current modelling of biological taxonomies, https://www.wikidata.org/wiki/Wikidata:Project_chat#Taxonomy:_concept_centric_vs_name_centric People on this thread might like to comment on some of the less fortunate elements of current practice, and the appropriateness of some of the thoughts that have been suggested. But the taxo project has become such a walled garden, answerable only to itself, that people with comments may need to be quite forceful to get their message through, if we are to deal eg with some of the difficulties Cparle describes in the ticket at https://phabricator.wikimedia.org/T199119 -- James. --- This email has been checked for viruses by AVG. https://www.avg.com ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata smime.p7s Description: S/MIME Cryptographic Signature ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Retitled] T207433: uselang=sr-cyrl and uselang=sr-latn causes fatal exception of type "MWException"
Fomafix renamed this task from "Fatal exception when using uselang=sr-cyrl or uselang=sr-latn on Wikidata" to "uselang=sr-cyrl and uselang=sr-latn causes fatal exception of type "MWException"".Fomafix added a subscriber: cscott.Fomafix updated the task description. (Show Details) CHANGES TO TASK DESCRIPTIONhttps://www.wikidata.org/wiki/Wikidata:Glossary?uselang=sr-cyrl leads to=== Error === Request ID: `W8llMwpAMEsAACb4rOcW` >Internal error```name=message [W8llMwpAMEsAACb4rOcW] 2018-10-19 05:01:39: Fatal exception of type "MWException" ``` > [W8llMwpAMEsAACb4rOcW] 2018-10-19 05:01:39: Fatal exception of type "MWException"```name=trace,lines=10 ``` === Impact === Affected:ed pages: * https://www.wikidata.org/wiki/Wikidata:Glossary?uselang=sr-cyrl * https://www.wikidata.org/wiki/Wikidata:Main_Page?uselang=sr-cyrl...Not affected pages:...* https://www.wikidata.org/w/index.php?title=Wikidata:Glossary="" style="padding: 0 2px; color: #33; background: rgba(151, 234, 151, .6);"> === Notes === Probably caused by rMW21ead7a98d1a (https://gerrit.wikimedia.org/r/460038).TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: FomafixCc: cscott, Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T207447: uselang=zh-hant-hk causes fatal exception of type "BadMethodCallException"
Fomafix created this task.Fomafix added projects: Wikimedia-production-error, Wikidata.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTIONError Request ID: W8mX4QpAME8AAHLuf4oAAACK message[W8mX4QpAME8AAHLuf4oAAACK] 2018-10-19 08:37:53: Fatal exception of type "BadMethodCallException" trace Impact Affected pages: https://www.wikidata.org/wiki/Wikidata:Main_Page?uselang=zh-hant-hk https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese=""> Notes Probably caused by rMW21ead7a98d1a (https://gerrit.wikimedia.org/r/460038).TASK DETAILhttps://phabricator.wikimedia.org/T207447EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: FomafixCc: Aklapper, cscott, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T207133: SPARQL service returns entities with broken URLs
Magnus added a comment. As a sidenote, this may also contain the solution to T207132 ...TASK DETAILhttps://phabricator.wikimedia.org/T207133EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, MagnusCc: Jneubert, TerraCodes, Liuxinyu970226, Addshore, Magnus, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207133: SPARQL service returns entities with broken URLs
Magnus added a comment. docker-compose.yml: # Wikibase with Query Service # # This docker-compose example can be used to pull the images from docker hub. # # Examples: # # Access Wikibase via "http://localhost:8181" # (or "http://$(docker-machine ip):8181" if using docker-machine) # # Access Query Service via "http://localhost:8282" # (or "http://$(docker-machine ip):8282" if using docker-machine) version: '3' services: wikibase: image: wikibase/wikibase:1.30-bundle links: - mysql ports: # CONFIG - Change the 8181 here to expose Wikibase & MediaWiki on a different port - "8181:80" volumes: - mediawiki-images-data:/var/www/html/images - ../mixnmatch_wb/interface:/var/www/html/interface depends_on: - mysql - elasticsearch networks: default: aliases: - wikibase.svc - mixnmatch.wmflabs.org # CONFIG - Add your real wikibase hostname here, for example wikibase-registry.wmflabs.org environment: - DB_SERVER=mysql.svc:3306 - MW_ELASTIC_HOST=elasticsearch.svc - MW_ELASTIC_PORT=9200 # CONFIG - Change the default values below - MW_ADMIN_NAME=admin - MW_ADMIN_PASS=* - MW_WG_SECRET_KEY=* # CONFIG - Change the default values below (should match mysql values in this file) - DB_USER=wikiuser - DB_PASS=* - DB_NAME=my_wiki mysql: image: mariadb:10.3 restart: always volumes: - mediawiki-mysql-data:/var/lib/mysql environment: MYSQL_RANDOM_ROOT_PASSWORD: 'yes' # CONFIG - Change the default values below (should match values passed to wikibase) MYSQL_DATABASE: 'my_wiki' MYSQL_USER: 'wikiuser' MYSQL_PASSWORD: '*' networks: default: aliases: - mysql.svc wdqs-frontend: image: wikibase/wdqs-frontend:latest ports: # CONFIG - Change the 8282 here to expose the Query Service UI on a different port - "8282:80" depends_on: - wdqs-proxy networks: default: aliases: - wdqs-frontend.svc environment: - WIKIBASE_HOST=mixnmatch.wmflabs.org - WDQS_HOST=wdqs-proxy.svc wdqs: image: wikibase/wdqs:0.3.0 volumes: - query-service-data:/wdqs/data command: /runBlazegraph.sh networks: default: aliases: - wdqs.svc environment: - WIKIBASE_HOST=mixnmatch.wmflabs.org - WDQS_HOST=wdqs.svc - WDQS_PORT= expose: - wdqs-proxy: image: wikibase/wdqs-proxy environment: - PROXY_PASS_HOST=wdqs.svc: ports: - "8989:80" depends_on: - wdqs networks: default: aliases: - wdqs-proxy.svc wdqs-updater: image: wikibase/wdqs:0.3.0 command: /runUpdate.sh depends_on: - wdqs - wikibase networks: default: aliases: - wdqs-updater.svc environment: - WIKIBASE_HOST=mixnmatch.wmflabs.org - WDQS_HOST=wdqs.svc - WDQS_PORT= elasticsearch: image: elasticsearch@sha256:f1dbf2019dc9a4ca5dd458635bfb31f9a601e4905e1d6ca1d65a3958d428f497 networks: default: aliases: - elasticsearch.svc environment: discovery.type: single-node # CONFING, in order to not load quickstatements then remove this entire section quickstatements: image: wikibase/quickstatements:latest ports: - "9191:80" depends_on: - wikibase networks: default: aliases: - quickstatements.svc environment: # CONFIG, you have to config this if you want quickstatements - OAUTH_CONSUMER_KEY=* - OAUTH_CONSUMER_SECRET=* - QS_PUBLIC_SCHEME_HOST_AND_PORT=https://mixnmatch-qs.wmflabs.org - WB_PUBLIC_SCHEME_HOST_AND_PORT=https://mixnmatch.wmflabs.org - WIKIBASE_SCHEME_AND_HOST=http://wikibase.svc - WB_PROPERTY_NAMESPACE=122 - "WB_PROPERTY_PREFIX=Property:" - WB_ITEM_NAMESPACE=120 - "WB_ITEM_PREFIX=Item:" volumes: mediawiki-mysql-data: mediawiki-images-data: query-service-data:TASK DETAILhttps://phabricator.wikimedia.org/T207133EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, MagnusCc: Jneubert, TerraCodes, Liuxinyu970226, Addshore, Magnus, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207133: SPARQL service returns entities with broken URLs
Magnus added a comment.
wdqs log (last "entry"):
wdqs_1 | 08:20:16.620 [qtp1747585824-18] ERROR c.b.r.sail.webapp.BigdataRDFServlet IP:wikibase-docker_wdqs-proxy_1.wikibase-docker_default UA:Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:63.0) Gecko/20100101 Firefox/63.0 - cause=java.util.concurrent.ExecutionException: java.lang.RuntimeException: off=0, len=558::namespace=wdq, timestamp=readOnly(1539937216616), readTime=readOnly(1539701290285), query=SPARQL-QUERY: queryStr=prefix schema: SELECT * WHERE { schema:dateModified ?y}
wdqs_1 | java.util.concurrent.ExecutionException: java.lang.RuntimeException: off=0, len=558::namespace=wdq, timestamp=readOnly(1539937216616), readTime=readOnly(1539701290285)
wdqs_1 | at java.util.concurrent.FutureTask.report(FutureTask.java:122)
wdqs_1 | at java.util.concurrent.FutureTask.get(FutureTask.java:206)
wdqs_1 | at com.bigdata.rdf.sail.webapp.BigdataServlet.submitApiTask(BigdataServlet.java:293)
wdqs_1 | at com.bigdata.rdf.sail.webapp.QueryServlet.doSparqlQuery(QueryServlet.java:654)
wdqs_1 | at com.bigdata.rdf.sail.webapp.QueryServlet.doGet(QueryServlet.java:288)
wdqs_1 | at com.bigdata.rdf.sail.webapp.RESTServlet.doGet(RESTServlet.java:240)
wdqs_1 | at com.bigdata.rdf.sail.webapp.MultiTenancyServlet.doGet(MultiTenancyServlet.java:271)
wdqs_1 | at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
wdqs_1 | at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
wdqs_1 | at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:769)
wdqs_1 | at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1667)
wdqs_1 | at org.wikidata.query.rdf.blazegraph.throttling.ThrottlingFilter.doFilter(ThrottlingFilter.java:304)
wdqs_1 | at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
wdqs_1 | at ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCInsertingServletFilter.java:49)
wdqs_1 | at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
wdqs_1 | at org.wikidata.query.rdf.blazegraph.filters.ClientIPFilter.doFilter(ClientIPFilter.java:43)
wdqs_1 | at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
wdqs_1 | at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
wdqs_1 | at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
wdqs_1 | at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
wdqs_1 | at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
wdqs_1 | at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1125)
wdqs_1 | at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
wdqs_1 | at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
wdqs_1 | at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1059)
wdqs_1 | at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
wdqs_1 | at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
wdqs_1 | at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
wdqs_1 | at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
wdqs_1 | at org.eclipse.jetty.server.Server.handle(Server.java:497)
wdqs_1 | at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
wdqs_1 | at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:248)
wdqs_1 | at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
wdqs_1 | at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:610)
wdqs_1 | at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:539)
wdqs_1 | at java.lang.Thread.run(Thread.java:748)
wdqs_1 | Caused by: java.lang.RuntimeException: off=0, len=558::namespace=wdq, timestamp=readOnly(1539937216616), readTime=readOnly(1539701290285)
wdqs_1 | at com.bigdata.relation.locator.DefaultResourceLocator.locateResourceOn(DefaultResourceLocator.java:817)
wdqs_1 | at com.bigdata.relation.locator.DefaultResourceLocator.locateResource(DefaultResourceLocator.java:586)
wdqs_1 | at com.bigdata.relation.locator.DefaultResourceLocator.cacheMiss(DefaultResourceLocator.java:395)
wdqs_1 | at
Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons
Hoi Pine, The ontology of Wikidata has nothing to do with English Wikipedia. The notion that English Wikipedia is the only endless resource of free labour is pathetic. Its dismissive attitude prevents functional contributions that will benefit the users of Wikimedia projects. For authors of "scholarly articles" we have an increasing amount of information that is impossible for Wikipedia to include. It does not take much to have a template that show them (standard collapsed) and links to "Scholia" information for the paper. For authors of books we could have a similar template. They could link to *your local library* where you can check if it is available for reading. Alternatively we could link to the "Open Library". What it would do is provide a SERVICE to our readers that is easy enough to provide, that leverages the data in Wikidata and is of a high quality. The issue about the ontology has everything to do with the discovery of images in Commons. It cannot get worse as it is, it is disfunctional. It only works for English and I understand that is something you do not really notice. Yes, I do recognise Wikidata is a wiki. It is a work in progress and as such the quality and quantity steadily improves.. Just like English Wikipedia. Thanks, Gerard On Fri, 19 Oct 2018 at 07:10, Pine W wrote: > I would appreciate clarification what is proposed with regard to exposing > problematic Wikidata ontology on Wikipedia. If the idea involves inserting > poor-quality information onto English Wikipedia in order to spur us to fix > problems with Wikidata, then I am likely to oppose it. English Wikipedia is > not an endless resource for free labor, and we have too few skilled and > good-faith volunteers to handle our already enormous scope of work. > > > Pine > ( https://meta.wikimedia.org/wiki/User:Pine ) > ___ > Wikidata mailing list > Wikidata@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata > ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Commented On] T207433: Fatal exception when using uselang=sr-cyrl or uselang=sr-latn on Wikidata
Fomafix added a comment. https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese=""> is also affected. It seams to happen when values from Wikidata are included in the page.TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: FomafixCc: Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T207395: Return CTRL-Space hint text to Wikidata Query Tool
matej_suchanek renamed this task from "Return CTRL-Space text to Wikidata Query Tool" to "Return CTRL-Space hint text to Wikidata Query Tool".matej_suchanek added a project: Wikidata-Query-Service. TASK DETAILhttps://phabricator.wikimedia.org/T207395EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: Sadads, Fuzheado, Gamaliel, Aklapper, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207370: Statistics of number of Wikidata edits with Magnus Manske's tools
Pintoch added a comment. Some of the OpenRefine edits were not tagged during development but all edits done with a released version should be. Some of the OpenRefine batches are uploaded via QuickStatements, in which case they are tagged as such. (The main benefits of using QS with OpenRefine is to run batches in the background or to have a statement matching rules when updating existing claims).TASK DETAILhttps://phabricator.wikimedia.org/T207370EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SandraF_WMF, PintochCc: Daniel_Mietchen, Pintoch, Samwalton9, Addshore, Aklapper, SandraF_WMF, Magnus, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T207433: Fatal exception when using uselang=sr-cyrl or uselang=sr-latn on Wikidata
Fomafix updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...> [W8llMwpAMEsAACb4rOcW] 2018-10-19 05:01:39: Fatal exception of type "MWException" Affected: * https://www.wikidata.org/wiki/Wikidata:Main_Page?uselang=sr-cyrl * https://www.wikidata.org/wiki/Q64?uselang=sr-cyrl * https://www.wikidata.org/wiki/Talk:Q64?uselang=sr-cyrl * https://www.wikidata.org/w/index.php?title=Wikidata_talk:Glossary=sr-cyrl * https://www.wikidata.org/w/index.php?title=Wikidata:Glossary="" /> Not affected: * https://www.wikidata.org/wiki/Wikidata_talk:Main_Page?uselang=sr-cyrl * https://www.wikidata.org/w/index.php?title=Q64="" /> * https://www.wikidata.org/wiki/MediaWiki:brackets?uselang=sr-cyrl * https://www.wikidata.org/w/index.php?title=Wikidata:Glossary="">TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: FomafixCc: Aklapper, Fomafix, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T207370: Statistics of number of Wikidata edits with Magnus Manske's tools
SandraF_WMF updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...Having graphs of these stats over time would be nice too, but for now I want to focus on some simpler numbers. Please add notable statistics for other Magnus tools in the comments below as well.TASK DETAILhttps://phabricator.wikimedia.org/T207370EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SandraF_WMFCc: Daniel_Mietchen, Pintoch, Samwalton9, Addshore, Aklapper, SandraF_WMF, Magnus, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207370: Statistics of number of Wikidata edits with Magnus Manske's tools
SandraF_WMF added a comment. Please help by adding more statistics for other Magnus tools in this ticket's comments.TASK DETAILhttps://phabricator.wikimedia.org/T207370EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SandraF_WMFCc: Daniel_Mietchen, Pintoch, Samwalton9, Addshore, Aklapper, SandraF_WMF, Magnus, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
