gerritbot added a comment.
Change 328632 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Use EntityTitleStoreLookup where necesarry
https://gerrit.wikimedia.org/r/328632TASK DETAILhttps://phabricator.wikimedia.org/T152498EMAIL
Esc3300 added a comment.
Good point. So that all links on http://ldfclient.wmflabs.org/ point to http:// is a different problem.TASK DETAILhttps://phabricator.wikimedia.org/T153563EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Lokal_Profil,
On 12/21/16 4:57 PM, Ruben Verborgh wrote:
> Hi Kingsley,
>
>> The Semantic Web community hasn't focused exclusively on query execution
>> speed.
> Let me clarify myself:
> the scientific SemWeb community mostly focused on speed,
> as is apparent from publications about SPARQL query execution
>
Smalyshev added a comment.
@Esc3300 no, that's completely different problem, actually a configuration bug having nothing to do with this one :) See the attached patch.TASK DETAILhttps://phabricator.wikimedia.org/T153563EMAIL
On 12/21/16 4:13 PM, Ruben Verborgh wrote:
> Federation is where I think public SPARQL endpoints will fail,
> so it will be worthwhile to see what happens.
Really, then you will ultimately be surprised on that front too!
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Esc3300 added a comment.
T153897 seems to illustrate the problem with not using http.TASK DETAILhttps://phabricator.wikimedia.org/T153563EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Lokal_Profil, DSGalaktos, MisterSynergy, Esc3300, Smalyshev,
Smalyshev added a comment.
@Gehel I imagine this is all done?TASK DETAILhttps://phabricator.wikimedia.org/T144380EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Gehel, SmalyshevCc: thcipriani, Stashbot, gerritbot, Gehel, Aklapper, Smalyshev, Th3d3v1ls,
Smalyshev created this task.Smalyshev added projects: Wikidata-Query-Service, Discovery-Wikidata-Query-Service-Sprint.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONIf the source wikibase repo updates rarely, it may happen that old edit appears on
Hi!
> That's all we can afford as researchers, unfortunately :-)
> I hope to build more (and lots was built in my spare time),
> but my currency as a researcher is publishable results,
> and sadly, not many SPARQL features are.
Understandable. And now since we have working TPF server and the
Hi Thad,
> Looks like Jena is doing most of your heavy lifting in the Java client ?
Absolutely, Jena is doing almost everything.
However, Jena is built with certain assumptions that don't hold for querying
over the public Web as with TPF, so it doesn't work as optimally as for other
Ruben,
Looks like Jena is doing most of your heavy lifting in the Java client ?
https://github.com/LinkedDataFragments/Client.Java/search?p=2=sparql=%E2%9C%93
or is there other code that I am missing somewhere in your repository ?
-Thad
___
Wikidata
Hi Stas,
> Also, I suspect this engine does not implement path
> queries right
It doesn't implement them at all;
it reads the first predicate and ignores the rest.
Right now, the engine implements:
– BGPs
– UNION
– OPTIONAL
– some FILTERs
Hi!
> In the queries I tried, no results were streaming in whatsoever. I have
I've tried the "antarctic rivers" query:
SELECT ?river ?riverLabel ?location
WHERE
{
?river wdt:P31/wdt:P279* wd:Q355304;
wdt:P30 wd:Q51.
OPTIONAL { ?river wdt:P625 ?location. }
}
and after waiting for a
Hi Markus,
>> Any query is possible (given a completely implemented engine),
>> but some of them just take a lot of time.
>
> Sorry, but this is really not what I am seeing. The queries I have tried all
> failed entirely. They were not slow, they completed computation with no
> results, time
Hi!
> Also, looks like I've underestimated the interest the demo endpoint has,
> so I'll do the following:
>
> 1. Create a separate VM for it so I won't break it unintentionally
> 2. Make it so it'd be easy to update it to latest code (right now it
> involves several manual steps and downtime)
Hi Ruben,
On 21.12.2016 23:20, Ruben Verborgh wrote:
Hi Markus,
It was clearly not built for interactive operation
On the contrary, it is:
imagine applications in the browser
that react when each result comes in.
Don't focus on the total time,
focus on the results streaming in.
In the
Hi Ruben.
On 21.12.2016 23:15, Ruben Verborgh wrote:
Hi Markus,
(I did read your paper ;-)
Awesome :-)
As editors, we have of course read all papers that have been published
in that issue (and some others).
...
This also show our departure from typical SemWeb ideas:
with TPF, we
Hi Markus,
> It was clearly not built for interactive operation
On the contrary, it is:
imagine applications in the browser
that react when each result comes in.
Don't focus on the total time,
focus on the results streaming in.
Web querying takes time, especially in a federated setting.
The
gerritbot added a comment.
Change 328582 had a related patch set uploaded (by Smalyshev):
Add configuration for query endpoint URL
https://gerrit.wikimedia.org/r/328582TASK DETAILhttps://phabricator.wikimedia.org/T153897EMAIL
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T153897EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, gerritbotCc: gerritbot, Aklapper, Smalyshev, Th3d3v1ls, Ramalepe, Liugev6, EBjune, mschwarzer, Avner,
Hi Markus,
> (I did read your paper ;-)
Awesome :-)
> Of course all the issues I observe might be due to implementation.
Or due to the kind of queries.
Some queries will always be hard;
with SPARQL endpoints, you pay the price in server cost;
with TPF, you pay the price in query time and
Hi!
> You will find that Wikidata, is doing the very same thing, but with much
> more hardware at their disposal, since they have more funding than
> DBpedia, at this point in time.
Well, we now are running on two servers (and getting another one
hopefully next Q), with mirror set on standby in
Dear Kingsley,
TL;DR: +1
On 21.12.2016 22:45, Kingsley Idehen wrote:
On 12/21/16 2:52 PM, Ruben Verborgh wrote:
For this, I'd like to point to the overall aim of the LDF project,
as documented on our website and papers.
Summarizing: the SemWeb community has almost exclusively
cared about
Hi!
> Regarding your guess that network connectivity could cause my problem: I
> got the 55sec time while in my office, connected via an Ethernet cable
> to the university network. This is more or less directly wired up to the
> backbone of the Internet, so bandwidth cannot be the issue here.
>
Hi Ruben,
I understand the theory and motivation behind LDF (I did read your paper
;-) but appealing ideas do not always turn out to work well in practice.
Of course all the issues I observe might be due to implementation. Maybe
the general idea could still be made to work somehow. All I am
Hi Markus,
> I got the 55sec time while in my office, connected via an Ethernet cable to
> the university network. This is more or less directly wired up to the
> backbone of the Internet, so bandwidth cannot be the issue here.
The latency is the main culprit, not bandwidth.
I also noted a
On 12/21/16 2:52 PM, Ruben Verborgh wrote:
> For this, I'd like to point to the overall aim of the LDF project,
> as documented on our website and papers.
> Summarizing: the SemWeb community has almost exclusively
> cared about speed so far concerning query execution.
> This has resulted in
Hi Stas,
Regarding your guess that network connectivity could cause my problem: I
got the 55sec time while in my office, connected via an Ethernet cable
to the university network. This is more or less directly wired up to the
backbone of the Internet, so bandwidth cannot be the issue here.
Hi!
> Also, there should be some way of doing queries that don't run on WDQS
> already, i.e., there must be something that times out now but can be
> done with ldf in a reasonable time [1]. Or are federated queries the
> main goal here? (that's still useful, but I hope that WDQS will also
>
Hi!
> I blame latency here; the server seems to be located in San Francisco.
WDQS servers are in Virginia, AFAIK:
https://wikitech.wikimedia.org/wiki/Eqiad_cluster
Also, looks like I've underestimated the interest the demo endpoint has,
so I'll do the following:
1. Create a separate VM for it
Hi Markus,
> The example query related to films returns 55 results, while on the official
> endpoint it returns 128.
This turned out to be due to an incomplete implementation of LANGMATCHES,
which I have now fixed in the query engine
Nikki created this task.Nikki added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONTo reproduce:
Copy a language code, e.g. "de", to the clipboard
Start editing a monolingual text statement, e.g. one of the ones on https://www.wikidata.org/wiki/Q4115189
Click into the
Smalyshev triaged this task as "High" priority.
TASK DETAILhttps://phabricator.wikimedia.org/T153513EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Esc3300, Harmonia_Amanda, Nikki, Gehel, Aklapper, Smalyshev, EBjune, mschwarzer, Avner, debt,
Nikki added a comment.
Oh, T124758 and T147839 seem to be the same thing.TASK DETAILhttps://phabricator.wikimedia.org/T153850EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Nikki, Micru, Aklapper, daniel, D3r1ck01, Izno, Wikidata-bugs, aude, Arrbee,
Smalyshev triaged this task as "Normal" priority.
TASK DETAILhttps://phabricator.wikimedia.org/T153897EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, EBjune, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer,
Smalyshev edited the task description. (Show Details)
EDIT DETAILSThe metadata in LDF endpoint requests use `http://query.wikidata.org/`, not `https://`. This leads to an extra hop for querying. Should be configured so it uses https from the start. TASK
Smalyshev created this task.Smalyshev added projects: Wikidata-Query-Service, Discovery-Wikidata-Query-Service-Sprint.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONThe metadata in LDF endpoint requests use http://query.wikidata.org/, not https://.
Smalyshev created this task.Smalyshev added projects: Wikidata, Wikidata-Query-Service, Discovery.
TASK DESCRIPTIONSometime in January, we want to make a poll to identify the initial list of federated SPARQL endpoints that we will allow WDQS to call out.TASK
Tgr added a comment.
In T153729#2893117, @daniel wrote:
wfWarn should fail phpunit tests, but it perhaps should not fail qunit tests. How is that failure triggered?
XDebug warnings show up (since last weekend or so) in pages which should contain _javascript_
Smalyshev created subtask T153896: Make a poll to identify the initial list of federated endpoints.
TASK DETAILhttps://phabricator.wikimedia.org/T153893EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, EBjune, mschwarzer,
Smalyshev triaged this task as "Normal" priority.
TASK DETAILhttps://phabricator.wikimedia.org/T153893EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, EBjune, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer,
Smalyshev created this task.Smalyshev added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONWe may want to support limited whitelist of federation endpoints that WDQS would allow to call out (using SERVICE) in
Hi!
> Wikidata seems to use the experimental Java server,
> not the default and more tested Node.js server.
Yes, it is built on top of Java ldf server, since it integrates with
Blazegraph which is of course Java.
> I reported it here:
>
Hi!
> Wikidata seems to use the experimental Java server,
> not the default and more tested Node.js server.
>
> I reported it here:
> https://github.com/LinkedDataFragments/Server.Java/issues/41
After thinking a bit about it I *think* I've found the logic behind it:
when it encounters first
Hi Lucas,
> I tried playing with it a bit and noticed an oddity in the JSON format: if
> the predicate and object are both left unspecified, "P_" keys will sometimes
> refer to full statement nodes and sometimes to truthy values. An example item
> with not too many statements where you can
Hi Markus,
Answering this as the LDF lead developer.
> (1) The results do not seem to be correct. The example query related to films
> returns 55 results, while on the official endpoint it returns 128. It seems
> that this is not because of missing data, but because of wrong multiplicities
>
Hi Stas,
Thanks for the info. Yes, all my comments apply to the ldf demo. I
understand that it is a demo, and what the motivation is on paper, but
if it returns incorrect results, then it is of little use. You can get
those without any load on server or client ;-).
Also, there should be
Smalyshev added a project: Discovery-Wikidata-Query-Service-Sprint.
TASK DETAILhttps://phabricator.wikimedia.org/T148923EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: gerritbot, Esc3300, Smalyshev, WikidataFacts, Aklapper, Base, Nikki,
ovasileva edited the task description. (Show Details)
EDIT DETAILS...# title and the toc stays un-language-converted even after a variant is specified: (eg. -{zh-cn:客车;zh-hk:客車;zh-tw:公車;}- in toc)
Create follow-up task with fixTASK DETAILhttps://phabricator.wikimedia.org/T114734EMAIL
ovasileva changed the title from "Title and TOC not converted for Wikidata page banner language variants" to "[Spike] Title and TOC not converted for Wikidata page banner language variants".
TASK DETAILhttps://phabricator.wikimedia.org/T114734EMAIL
Hi!
> (1) The results do not seem to be correct. The example query related to
> films returns 55 results, while on the official endpoint it returns 128.
> It seems that this is not because of missing data, but because of wrong
> multiplicities (the correct result has several rows repeated
gerritbot added a comment.
Change 326970 merged by jenkins-bot:
Make API wbgetentities skip entities from unknown repositories
https://gerrit.wikimedia.org/r/326970TASK DETAILhttps://phabricator.wikimedia.org/T153076EMAIL
Nikki edited the task description. (Show Details)
EDIT DETAILS...* mo: "Moldovan"
* moe: "Montagnais"
* nl-informal: "Dutch (informal address)"...TASK DETAILhttps://phabricator.wikimedia.org/T151269EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc:
matej_suchanek removed a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T71001EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: Ricordisamoa, Addshore, Jonas, Aklapper, gerritbot, Wikidata-bugs, Lydia_Pintscher,
Nikki added a comment.
It's not just those special codes which are missing, any code which is only available for monolingual text is not shown (the list seems to be defined here).
CLDR only has names for some of the codes but I already requested local English names for the ones which don't
daniel created this task.daniel added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONAt present, WikibaseRepo depends on WikibaseLib and WikibaseView, and WikibaseClient depends on WikibaseLib. All of these depend on other composer modules, which do not depend on
gerritbot added a comment.
Change 316977 merged by jenkins-bot:
Split EntityTitleLookup interface
https://gerrit.wikimedia.org/r/316977TASK DETAILhttps://phabricator.wikimedia.org/T152498EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde,
Hi,
I also found other cases where the results are not correct. For example,
if you try the example query "overall causes of death ranking", there is
no error and a long computation (eating up most of my CPU) and,
eventually, no results.
Cheers,
Markus
On 21.12.2016 11:11, Markus
gerritbot added a comment.
Change 328488 merged by jenkins-bot:
Skip invalid entity ids in PrefetchingWikiPageEntityMetaDataAccessor
https://gerrit.wikimedia.org/r/328488TASK DETAILhttps://phabricator.wikimedia.org/T153076EMAIL
matej_suchanek created this task.matej_suchanek added projects: MediaWiki-extensions-WikibaseRepository, Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTION#abusefilter uses this hook to insert revision id to the database, so that AbuseLog can show diff links (compare). Suppressing
Base added a comment.
I think both ways are desirable. Quarry-like interface for WDQS is already tasked at T104762. Quarry is exteremely useful in lots of ways. The easy typo fixing or code commenting without URL change as mentioned, being able to promise someone to write a query and provide a
hashar added a comment.
The sequence of CI for the mediawiki-extensions-qunit-jessie job (and for all others afaik):
clone all repos
run install.php
append to LocalSettings.php snippets from integration/jenkins.git mediawiki/conf.d which among others:
sets $wgWikimediaJenkinsCI = true;)
add
Jan_Dittrich edited the task description. (Show Details)
EDIT DETAILS//Meta: The Issue may be too vague or may not use the "right" terms. Feel free to improve it and/or ask"//...TASK DETAILhttps://phabricator.wikimedia.org/T153858EMAIL
johl created this task.johl added projects: WMDE-Tech-Communication-Data-Partnerships, WMDE-Tech-Communication, Wikidata.
TASK DESCRIPTIONTASK DETAILhttps://phabricator.wikimedia.org/T153861EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: johlCc: Aklapper,
johl created subtask T153861: Publish video on data partnerships.
TASK DETAILhttps://phabricator.wikimedia.org/T153860EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: johlCc: Aklapper, johl, D3r1ck01, Izno, Wikidata-bugs, aude, Lydia_Pintscher,
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T153793EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Aleksey_WMDE, Jakob_WMDE, WMDE-leszek, Aklapper, daniel, Th3d3v1ls, Ramalepe, Liugev6,
johl created subtask T153860: Publish blog post on UNESCO work.
TASK DETAILhttps://phabricator.wikimedia.org/T151636EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: johlCc: johl, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Lydia_Pintscher,
johl created this task.johl added projects: WMDE-Tech-Communication-Data-Partnerships, WMDE-Tech-Communication, Wikidata.
TASK DESCRIPTIONTASK DETAILhttps://phabricator.wikimedia.org/T153860EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: johlCc: Aklapper,
gerritbot added a comment.
Change 328513 had a related patch set uploaded (by WMDE-leszek):
Make DispatchingServiceFactory provided TermSearchInteractor
https://gerrit.wikimedia.org/r/328513TASK DETAILhttps://phabricator.wikimedia.org/T153793EMAIL
Jan_Dittrich created this task.Jan_Dittrich added projects: Wikidata, Wikibase-DataModel.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONMeta: The Issue may be too vague or may not use the "right" terms. Feel free to improve it and/or ask"
Need: It should be possible to identify which error
Jan_Dittrich created this task.Jan_Dittrich added projects: Wikidata, Wikibase-_javascript_-Api.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONMeta: The Issue may be too vague or may not use the "right" terms. Feel free to improve it and/or ask"
Need: It should be
possible to generate
gerritbot added a comment.
Change 328496 merged by jenkins-bot:
Use default wiki id in example settings.
https://gerrit.wikimedia.org/r/328496TASK DETAILhttps://phabricator.wikimedia.org/T153729EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr,
Micru added a comment.
Ok, I can imagine that it is not straight-forward. I hope that the same development for Lexicographical data can be reused for the monolingual text, because right now there are users selecting "mis" and not qualifying it with the corresponding language/dialect/variant.TASK
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T153854EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, TerraCodes, Jay8g, Aklapper, thiemowmde, Paladox, Tgr, daniel, Th3d3v1ls, Ramalepe,
gerritbot added a comment.
Change 328504 had a related patch set uploaded (by Daniel Kinzler):
[WIP] Revert "Remove warning about missing site ID"
https://gerrit.wikimedia.org/r/328504TASK DETAILhttps://phabricator.wikimedia.org/T153854EMAIL
daniel added a comment.
Achtually, client/config/WikibaseClient.jenkins.php defines $wgWBClientSettings['siteGroup'] = "mywikigroup"; to circumvent this problem (the localWikiId setting is primarily used to detect the wiki's own group). WikibaseClient.jenkins.php is used if Wikibase.php detects
gerritbot added a comment.
Change 328504 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
[WIP] Revert "Remove warning about missing site ID"
https://gerrit.wikimedia.org/r/328504TASK DETAILhttps://phabricator.wikimedia.org/T153729EMAIL
gerritbot added a comment.
Change 328501 had a related patch set uploaded (by Jakob):
[DRAFT][WIP] Add Lemma ChangeOp.
https://gerrit.wikimedia.org/r/328501TASK DETAILhttps://phabricator.wikimedia.org/T153677EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T153677EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDE, gerritbotCc: gerritbot, Ladsgroup, daniel, Aklapper, Jakob_WMDE, Th3d3v1ls, Ramalepe, Liugev6,
daniel added a comment.
@Micru that would be nice, but we currently don't have a place to put that information. We can "glue" it to the language code, e.g. mis-Q55. But that would not be a valid ISO code, we would need to strip the suffix before using the code in RDF, etc. We would also need
daniel added a project: Wikidata-Sprint-2016-11-15.daniel triaged this task as "Unbreak Now!" priority.Herald added subscribers: Jay8g, TerraCodes.
TASK DETAILhttps://phabricator.wikimedia.org/T153854EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc:
daniel created this task.daniel added projects: Wikidata, MediaWiki-extensions-WikibaseClient.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONThe localSiteID setting must refer to a site that is known to the SiteLookup service. If this is not the case, a warning should be raised - probably a
daniel reopened this task as "Open".daniel added a comment.
Reopening. Removing the warning may fix the symptom, but you are just shooting the messenger.
The warning is there for a reason, and needs to be put back. It should probably even be a production warning and use wfLogWarning(), since it
Micru added a comment.
It would be most useful if texts marked as "mis" would accept an item to specify the language used.TASK DETAILhttps://phabricator.wikimedia.org/T153850EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MicruCc: Micru, Aklapper, daniel,
gerritbot added a comment.
Change 328496 had a related patch set uploaded (by Daniel Kinzler):
Use default wiki id in example settings.
https://gerrit.wikimedia.org/r/328496TASK DETAILhttps://phabricator.wikimedia.org/T153729EMAIL
Esc3300 added a comment.
I think it would be good to see some metrics. How many people use these links? Is this already available on grafana?TASK DETAILhttps://phabricator.wikimedia.org/T153563EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc:
daniel created this task.daniel added projects: Wikidata, MediaWiki-extensions-WikibaseRepository, MediaWiki-extensions-CLDR.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONThe combobox selector shown when selecting a language for a monolingual text value does not list special languages like
thiemowmde edited the task description. (Show Details)
EDIT DETAILSOriginally these two patches where part of {T148626}:
* [ ] https://gerrit.wikimedia.org/r/316963
* [ ] https://gerrit.wikimedia.org/r/316977
Both patches have been removed from the chain, and T148626 got closed without ever
gerritbot added a comment.
Change 316977 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Split EntityTitleLookup interface
https://gerrit.wikimedia.org/r/316977TASK DETAILhttps://phabricator.wikimedia.org/T152498EMAIL
gerritbot added a comment.
Change 328490 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Remove misplaced namespace lookup method from EntityTitleStoreLookup
https://gerrit.wikimedia.org/r/328490TASK DETAILhttps://phabricator.wikimedia.org/T152498EMAIL
gerritbot added a comment.
Change 328488 had a related patch set uploaded (by WMDE-leszek):
Skip invalid entity ids in PrefetchingWikiPageEntityMetaDataAccessor
https://gerrit.wikimedia.org/r/328488TASK DETAILhttps://phabricator.wikimedia.org/T153076EMAIL
Aschroet added a comment.
Around a year ago i create T89703 according to the missing nearby feature. It is somehow a duplicate of this ticket. Just from experience i learnt that it is very hard to discuss and motivate local admins in the different wikis to work on required changes to that the
Aklapper added a project: Chinese-Sites.
TASK DETAILhttps://phabricator.wikimedia.org/T114734EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AklapperCc: gerritbot, Liuxinyu970226, Hkjacksonhk, liangent, Jdlrobson, Aklapper, zhuyifei1999, Winter, D3r1ck01,
gerritbot added a comment.
Change 321870 abandoned by Thiemo Mättig (WMDE):
Rename EntityTitleLookup to EntityTitleStoreLookup
Reason:
Continuing to work on I96889cd and I866457e instead.
https://gerrit.wikimedia.org/r/321870TASK DETAILhttps://phabricator.wikimedia.org/T148626EMAIL
daniel added a comment.
Awesome! I'm existed to see how this turns out!TASK DETAILhttps://phabricator.wikimedia.org/T136358EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, danielCc: Lucie, Micru, faidon, dpatrick, daniel, gerritbot, Aklapper, Zppix,
Hello all,
The SPARQL endpoint we are running at http://query.wikidata.org has several
measures in place in order to ensure it stays up and running and available
for everyone, for example the 30 sec query timeout. This is necessary but
also prevents some useful queries from being run. One way
WMDE-leszek added a comment.
Probably the setting could then be renamed to "repositories"?TASK DETAILhttps://phabricator.wikimedia.org/T153767EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: WMDE-leszekCc: WMDE-leszek, Jakob_WMDE, Lydia_Pintscher, Aklapper,
97 matches
Mail list logo
