Re: [Wikidata] Communicating corrections back to data source

I do this actually for the institute I work for: I take a moment to check the property violations for P396 and then advice the proper office to merge the codes (which they double-check once noticed). It sometimes ended also with me learning a couple of things on how work goes. :) L. Il 10 giu

Re: [Wikidata] Possibility of data lock

Il 10 giu 2016 17:53, "Benjamin Good" ha scritto: > We could have argued that because of our PhDs or whatever, we should 'own' these claims that are "clearly facts...", but that would have been a huge mistake. I'd like to take a moment to thank you for your job, and

[Wikidata-bugs] [Maniphest] [Edited] T134723: Project Weekly Reports for Automated Testing and Integration of IFTTT support to Wikidata

D3r1ck01 edited the task description.TASK DETAILhttps://phabricator.wikimedia.org/T134723EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: D3r1ck01Cc: Zppix, Bene, Samtar, hoo, Lydia_Pintscher, Slaporte, Aklapper, Sumit, D3r1ck01, Lethexie, Izno, Wikidata-bugs,

[Wikidata-bugs] [Maniphest] [Updated] T135957: Wikidata don't recognize the Chinese title conversion

Cosine02 removed a blocked task: T125033: Chinese Wikimedia projects tracking.TASK DETAILhttps://phabricator.wikimedia.org/T135957EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Cosine02Cc: Mbch331, Aklapper, YFdyh000, Zppix, D3r1ck01, Izno, Wikidata-bugs,

[Wikidata-bugs] [Maniphest] [Changed Project Column] T127250: Prepare Wikidata descriptions to roll out to stable

jhobs moved this task from Doing to Code Review on the Reading-Web-Sprint-74-Page-views-page-views-PAGE-VIEWS board.TASK DETAILhttps://phabricator.wikimedia.org/T127250WORKBOARDhttps://phabricator.wikimedia.org/project/board/2000/EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T127250: Prepare Wikidata descriptions to roll out to stable

gerritbot added a comment.Change 293883 had a related patch set uploaded (by Jhobs): Prepare Wikidata descriptions on mobile for production rollout https://gerrit.wikimedia.org/r/293883TASK DETAILhttps://phabricator.wikimedia.org/T127250EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T127250: Prepare Wikidata descriptions to roll out to stable

gerritbot added a comment.Change 293882 had a related patch set uploaded (by Jhobs): Prepare Wikidata descriptions for rollout to stable https://gerrit.wikimedia.org/r/293882TASK DETAILhttps://phabricator.wikimedia.org/T127250EMAIL

[Wikidata-bugs] [Maniphest] [Updated] T127250: Prepare Wikidata descriptions to roll out to stable

gerritbot added a project: Patch-For-Review.TASK DETAILhttps://phabricator.wikimedia.org/T127250EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: jhobs, gerritbotCc: gerritbot, Dbrant, Oliv0, Jhernandez, bmansurov, phuedx, Lydia_Pintscher, Moushira, dr0ptp4kt,

[Wikidata-bugs] [Maniphest] [Merged] T137591: page should include a link to Wikidata

Lydia_Pintscher closed this task as a duplicate of T126873: Links to Wikidata items from Placeholders.TASK DETAILhttps://phabricator.wikimedia.org/T137591EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_PintscherCc: Aklapper, Ijon, Zppix, D3r1ck01, Izno,

[Wikidata-bugs] [Maniphest] [Merged] T126873: Links to Wikidata items from Placeholders

Lydia_Pintscher added subscribers: Ijon, Zppix.Lydia_Pintscher merged a task: T137591: page should include a link to Wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T126873EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_PintscherCc: Zppix, Ijon,

[Wikidata-bugs] [Maniphest] [Commented On] T126873: Links to Wikidata items from Placeholders

jeblad added a comment."Should probably" or simply "shall"? Those evil words…TASK DETAILhttps://phabricator.wikimedia.org/T126873EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: jebladCc: jeblad, Lydia_Pintscher, Aklapper, StudiesWorld, Bugreporter, D3r1ck01,

[Wikidata-bugs] [Maniphest] [Created] T137591: page should include a link to Wikidata

Ijon created this task.Ijon added a project: ArticlePlaceholder.Herald added subscribers: Zppix, Aklapper.Herald added a project: Wikidata.TASK DESCRIPTIONI couldn't find one, e.g. here: https://eo.wikipedia.org/wiki/Speciala%C4%B5o:AboutTopic/Q15160TASK

[Wikidata-bugs] [Maniphest] [Updated] T136479: Allow cancelling / aborting queries

Smalyshev added a blocking task: T112151: Support POST for SPARQL query endpoint.TASK DETAILhttps://phabricator.wikimedia.org/T136479EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Jonas, Deskana, Smalyshev, Nikki, Aklapper, Zppix, WikidataFacts,

[Wikidata-bugs] [Maniphest] [Updated] T112151: Support POST for SPARQL query endpoint

Smalyshev added a blocked task: T136479: Allow cancelling / aborting queries.TASK DETAILhttps://phabricator.wikimedia.org/T112151EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Jonas, chasemp, JanZerebecki, BBlack, Andrew, Deskana, Joe,

[Wikidata-bugs] [Maniphest] [Changed Project Column] T137589: Query example preview very hard to use

Smalyshev moved this task from All WDQS-related tasks to GUI on the Wikidata-Query-Service board.TASK DETAILhttps://phabricator.wikimedia.org/T137589WORKBOARDhttps://phabricator.wikimedia.org/project/board/891/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:

[Wikidata-bugs] [Maniphest] [Created] T137589: Query example preview very hard to use

Smalyshev created this task.Smalyshev added a project: Wikidata-Query-Service.Herald added subscribers: Zppix, Aklapper.Herald added projects: Wikidata, Discovery.TASK DESCRIPTIONQuery example dialog has "preview" on each item, which allows to see the query. However, it is hard to use due to the

Re: [Wikidata] Communicating corrections back to data source

Hi Julie, We've thought a lot about this, but not done anything formally yet. There is an example of this happening to improve the disease ontology presented in this paper [1]. Mechanically, parties interested in a particular swath of data linked to their resource could set up repeated SPARQL

[Wikidata-bugs] [Maniphest] [Changed Project Column] T137585: [bug] Map not enabled on query with coordinates

Jonas moved this task from Proposed to Done on the Wikidata-Sprint-2016-05-24 board.TASK DETAILhttps://phabricator.wikimedia.org/T137585WORKBOARDhttps://phabricator.wikimedia.org/project/board/1990/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc:

[Wikidata-bugs] [Maniphest] [Closed] T137585: [bug] Map not enabled on query with coordinates

Jonas closed this task as "Resolved".Jonas added a project: Wikidata-Sprint-2016-05-24.TASK DETAILhttps://phabricator.wikimedia.org/T137585EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: gerritbot, Aklapper, Zppix, Smalyshev, Avner, Lewizho99,

[Wikidata-bugs] [Maniphest] [Commented On] T137585: [bug] Map not enabled on query with coordinates

gerritbot added a comment.Change 293480 merged by jenkins-bot: ResultBrowser improvements https://gerrit.wikimedia.org/r/293480TASK DETAILhttps://phabricator.wikimedia.org/T137585EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jonas, gerritbotCc: gerritbot,

Re: [Wikidata] Possibility of data lock

Hi! > More concretely: While the item about Barack Obama as a whole will > probably change ever and ever again, the value of his birthday statement > should never change: The current value is proven to be true and can't > change by its nature. What would be the problem about protecting this >

[Wikidata-bugs] [Maniphest] [Updated] T137585: [bug] Map not enabled on query with coordinates

gerritbot added a project: Patch-For-Review.TASK DETAILhttps://phabricator.wikimedia.org/T137585EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jonas, gerritbotCc: gerritbot, Aklapper, Zppix, Smalyshev, Avner, Lewizho99, Maathavan, debt, Gehel, D3r1ck01,

[Wikidata-bugs] [Maniphest] [Commented On] T137585: [bug] Map not enabled on query with coordinates

gerritbot added a comment.Change 293480 had a related patch set uploaded (by Jonas Kress (WMDE)): ResultBrowser improvements https://gerrit.wikimedia.org/r/293480TASK DETAILhttps://phabricator.wikimedia.org/T137585EMAIL

[Wikidata] Communicating corrections back to data source

It is great that WikiData provides a way for data to be curated in a crowd-sourced way. It would be even better if changes (especially corrections) could be communicated back to the original source so that all could benefit. Has this been discussed previously? Considered? Julie

Re: [Wikidata] Possibility of data lock

Hi! > (1) Statement- and property-level watching for changes (seeing > problematic changes should come before disallowing them) This might be harder to do as it's not really possible - internally - to edit just one statement. It looks like editing one statement, but the data for the whole entity

[Wikidata-bugs] [Maniphest] [Commented On] T137366: RDF dump for week of 20160606 seems to be missing

Smalyshev added a comment.Looks like we don't have any alert when the dump fails?TASK DETAILhttps://phabricator.wikimedia.org/T137366EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, SmalyshevCc: hoo, aude, Aklapper, Zppix, Smalyshev, D3r1ck01, Izno,

Re: [Wikidata] Possibility of data lock

Hi Gerard, > There is another aspect that is not considered. When you lock an item or > a property how is a label in a language added that is still missing? so who exactly talks about locking a whole item or property prophylactically? Wasn't pointed out several times that this discussion is

[Wikidata-bugs] [Maniphest] [Updated] T134131: Watch for exceptions in Wikidata dumper logs

Smalyshev added a comment.From T137366 it seems that while we do not generate bad dump, also nobody was alerted when the dump failed. We should probably improve that.TASK DETAILhttps://phabricator.wikimedia.org/T134131EMAIL

[Wikidata-bugs] [Maniphest] [Triaged] T137585: [bug] Map not enabled on query with coordinates

Smalyshev triaged this task as "Normal" priority.TASK DETAILhttps://phabricator.wikimedia.org/T137585EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jonas, SmalyshevCc: Aklapper, Zppix, Smalyshev, Avner, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll,

[Wikidata-bugs] [Maniphest] [Changed Project Column] T137585: [bug] Map not enabled on query with coordinates

Smalyshev moved this task from All WDQS-related tasks to GUI on the Wikidata-Query-Service board.TASK DETAILhttps://phabricator.wikimedia.org/T137585WORKBOARDhttps://phabricator.wikimedia.org/project/board/891/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:

[Wikidata-bugs] [Maniphest] [Retitled] T137585: [bug] Map not enabled on query with coordinates

Smalyshev changed the title from "Map not enabled on query with coordinates" to "[bug] Map not enabled on query with coordinates".Smalyshev added a project: Wikidata-Query-Service.Herald added projects: Wikidata, Discovery.TASK DETAILhttps://phabricator.wikimedia.org/T137585EMAIL

Re: [Wikidata] Possibility of data lock

On the merging point in particular, a problem here is that preemptively saying "don't merge things from this upload" is inevitably going to lead to a different kind of problem - unmerged duplicate items with inconsistent data. Merging is one of our key tools, after all! There is a technical way

Re: [Wikidata] WikiProjects Languages in Indonesia (Was: Re: Possibility of data lock)

Hoi, When a language cannot be matched to an ISO-639-3 code, it is necessary to ask for permission from the Language Committee first. Thanks, GerardM On 10 June 2016 at 07:34, Biyanto Rebin wrote: > ​I use the code that is made by ​Statistics Indonesia >

Re: [Wikidata] Possibility of data lock

I concur both with Markus K and with Ben. What sets Wikipedia apart is its democratic approach. Exerting too much control, especially if in the hands of a "trusted few", is at cross-purposes with the Wiki way and moreover not scaleable. The question regarding edit drift and notifications raises

[Wikidata-bugs] [Maniphest] [Unblock] T136598: Wikidata master database connection issue

hoo closed blocking task T116404: EntityUsageTable::getUsedEntityIdStrings query on wbc_entity_usage table is sometimes fast, sometimes slow as "Declined".TASK DETAILhttps://phabricator.wikimedia.org/T136598EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:

[Wikidata-bugs] [Maniphest] [Declined] T116404: EntityUsageTable::getUsedEntityIdStrings query on wbc_entity_usage table is sometimes fast, sometimes slow

hoo closed this task as "Declined".hoo added a comment.We'll do T137539: Use individual select queries to determin which Entities are in the wbc_entity_usage table instead.TASK DETAILhttps://phabricator.wikimedia.org/T116404EMAIL

[Wikidata-bugs] [Maniphest] [Edited] T70567: Make EntityView UI aware of redirects

matej_suchanek edited the task description.TASK DETAILhttps://phabricator.wikimedia.org/T70567EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: thiemowmde, adrianheine, aude, Snaterlicious, Lydia_Pintscher, daniel, JohnLewis, D3r1ck01, Izno,

[Wikidata-bugs] [Maniphest] [Updated] T87316: [Story] Redesign statement section

matej_suchanek added a blocking task: T70567: Make EntityView UI aware of redirects.TASK DETAILhttps://phabricator.wikimedia.org/T87316EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: Ricordisamoa, MGChecker, Bene, Liuxinyu970226,

[Wikidata-bugs] [Maniphest] [Updated] T70567: Make EntityView UI aware of redirects

matej_suchanek added a blocked task: T87316: [Story] Redesign statement section.TASK DETAILhttps://phabricator.wikimedia.org/T70567EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: thiemowmde, adrianheine, aude, Snaterlicious, Lydia_Pintscher,

[Wikidata-bugs] [Maniphest] [Commented On] T136188: qunit jobs have karma stall when chromium disconnect

gerritbot added a comment.Change 291034 abandoned by Chad: Revert "build: Bump grunt-karma and related tools to 1.0.x" Reason: 1.27.0-wmf.3 isn't used anymore https://gerrit.wikimedia.org/r/291034TASK DETAILhttps://phabricator.wikimedia.org/T136188EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T122019: Make it possible to enter URLs (not only QIDs) when using Merge and Move gadgets on Wikidata

agray added a comment.See also https://phabricator.wikimedia.org/T117763 - suggesting allowing (Q123) as a valid entry as well as Q123.TASK DETAILhttps://phabricator.wikimedia.org/T122019EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: agrayCc: agray, Movses,

Re: [Wikidata] Possibility of data lock

+1000 to Markus K's main arguments above. Yes noise will be introduced as different people come in to make edits. Administrators locking them out isn't the best way to solve that problem in an open system. There are other options, as he raised - both technical and social. Our group maintains

[Wikidata-bugs] [Maniphest] [Commented On] T137539: Use individual select queries to determin which Entities are in the wbc_entity_usage table

gerritbot added a comment.Change 293745 had a related patch set uploaded (by Hoo man): EntityUsageTable: Run all subqueries at once with UNION on MySQL https://gerrit.wikimedia.org/r/293745TASK DETAILhttps://phabricator.wikimedia.org/T137539EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T137539: Use individual select queries to determin which Entities are in the wbc_entity_usage table

hoo added a comment.Short test: hoo@terbium:~$ mwscript eval.php --wiki=zhwiki >

[Wikidata-bugs] [Maniphest] [Commented On] T137539: Use individual select queries to determin which Entities are in the wbc_entity_usage table

gerritbot added a comment.Change 293736 had a related patch set uploaded (by Hoo man): WIP: Use one (sub)query per entity id in getUsedEntityIdStrings https://gerrit.wikimedia.org/r/293736TASK DETAILhttps://phabricator.wikimedia.org/T137539EMAIL

[Wikidata-bugs] [Maniphest] [Updated] T137539: Use individual select queries to determin which Entities are in the wbc_entity_usage table

gerritbot added a project: Patch-For-Review.TASK DETAILhttps://phabricator.wikimedia.org/T137539EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, gerritbotCc: gerritbot, Zppix, Aklapper, hoo, aude, aaron, daniel, jcrespo, Vali.matei, Lewizho99, Maathavan,

[Wikidata-bugs] [Maniphest] [Edited] T105638: RFC: Streamlining Composer usage

JanZerebecki edited the task description.TASK DETAILhttps://phabricator.wikimedia.org/T105638EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JanZerebeckiCc: adrianheine, Ricordisamoa, MoritzMuehlenhoff, dduvall, Tgr, mobrovac, GWicke, Addshore, Spage, greg,

[Wikidata-bugs] [Maniphest] [Claimed] T137539: Use individual select queries to determin which Entities are in the wbc_entity_usage table

hoo claimed this task.TASK DETAILhttps://phabricator.wikimedia.org/T137539EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Zppix, Aklapper, hoo, aude, aaron, daniel, jcrespo, Vali.matei, D3r1ck01, Izno, Wikidata-bugs, GWicke, Mbch331

[Wikidata-bugs] [Maniphest] [Commented On] T137238: Tune WDQS caching headers

gerritbot added a comment.Change 293492 merged by Gehel: Don't publish etags for WDQS https://gerrit.wikimedia.org/r/293492TASK DETAILhttps://phabricator.wikimedia.org/T137238EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Smalyshev,

Re: [Wikidata] ArticlePlaceholder rolled out to next wikis

On Fri, Jun 10, 2016 at 3:01 PM John Erling Blad wrote: > The page is missing a link back to the item, it is now a dead end unless > you want to create an article. > I guess that isn't quite obvious… > We have https://phabricator.wikimedia.org/T126873 for that. Cheers Lydia

Re: [Wikidata] ArticlePlaceholder rolled out to next wikis

The page is missing a link back to the item, it is now a dead end unless you want to create an article. I guess that isn't quite obvious… On Fri, Jun 10, 2016 at 2:23 PM, Magnus Manske wrote: > -- Forwarded message - > From: Lydia Pintscher

[Wikidata] Wikidata activities at Wikimania

Hey folks :) Wikimania is coming up and quite a few Wikidata things will happen there. I tried to summarize them all here: https://wikimania2016.wikimedia.org/wiki/Wikidata. If you know of more please add them. Hope to see many of you at the meetup! Cheers Lydia -- Lydia Pintscher -

Re: [Wikidata] ArticlePlaceholder rolled out to next wikis

-- Forwarded message - From: Lydia Pintscher * Gujarati ( https://gu.wikipedia.org/wiki/%E0%AA%B5%E0%AA%BF%E0%AA%B6%E0%AB%87%E0%AA%B7:AboutTopic/Q13520818 ) Honoured to be a test item, even if I have never heard about that language before... :-)

[Wikidata-bugs] [Maniphest] [Changed Project Column] T122996: Limit the resources ArticlePlaceholders can use further (compared to normal pages)

Lucie moved this task from Incoming to To Do Next on the ArticlePlaceholder board.TASK DETAILhttps://phabricator.wikimedia.org/T122996WORKBOARDhttps://phabricator.wikimedia.org/project/board/1416/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LucieCc: Lucie,

[Wikidata-bugs] [Maniphest] [Changed Project Column] T137500: MWException: DatabaseBase::makeList: empty input for field page_title

Lucie moved this task from Incoming to Done on the ArticlePlaceholder board.TASK DETAILhttps://phabricator.wikimedia.org/T137500WORKBOARDhttps://phabricator.wikimedia.org/project/board/1416/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: aude, LucieCc:

[Wikidata-bugs] [Maniphest] [Changed Project Column] T135624: Second round of the ArticlePlaceholder rollout (tracking)

Lucie moved this task from Broader tickets to Done on the ArticlePlaceholder board.TASK DETAILhttps://phabricator.wikimedia.org/T135624WORKBOARDhttps://phabricator.wikimedia.org/project/board/1416/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:

[Wikidata-bugs] [Maniphest] [Changed Project Column] T137473: [Bug] Don't add article placeholder links to search results if the Item has an article

Lucie moved this task from Incoming to To Do Next on the ArticlePlaceholder board.TASK DETAILhttps://phabricator.wikimedia.org/T137473WORKBOARDhttps://phabricator.wikimedia.org/project/board/1416/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LucieCc:

[Wikidata-bugs] [Maniphest] [Changed Project Column] T117683: [Tracking] Finish minimal loveable product as beta feature

Lucie moved this task from Broader tickets to Done on the ArticlePlaceholder board.TASK DETAILhttps://phabricator.wikimedia.org/T117683WORKBOARDhttps://phabricator.wikimedia.org/project/board/1416/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LucieCc:

[Wikidata-bugs] [Maniphest] [Changed Project Column] T136517: Enable ArticlePlaceholder extension in guwiki

Lucie moved this task from Doing to Done on the ArticlePlaceholder board.TASK DETAILhttps://phabricator.wikimedia.org/T136517WORKBOARDhttps://phabricator.wikimedia.org/project/board/1416/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, LucieCc: Stashbot,

[Wikidata-bugs] [Maniphest] [Changed Project Column] T130997: [Task] Configure ArticlePlaceholder for nnwiki

Lucie moved this task from Doing to Done on the ArticlePlaceholder board.TASK DETAILhttps://phabricator.wikimedia.org/T130997WORKBOARDhttps://phabricator.wikimedia.org/project/board/1416/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, LucieCc: Stashbot,

[Wikidata-bugs] [Maniphest] [Changed Project Column] T136100: Enable ArticlePlaceholder on lvwiki

Lucie moved this task from Doing to Done on the ArticlePlaceholder board.TASK DETAILhttps://phabricator.wikimedia.org/T136100WORKBOARDhttps://phabricator.wikimedia.org/project/board/1416/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, LucieCc: Stashbot,

[Wikidata-bugs] [Maniphest] [Retitled] T137539: Use individual select queries to determin which Entities are in the wbc_entity_usage table

Aklapper changed the title from "Use inidividual select queries to determin which Entities are in the wbc_entity_usage table" to "Use individual select queries to determin which Entities are in the wbc_entity_usage table".TASK DETAILhttps://phabricator.wikimedia.org/T137539EMAIL

Re: [Wikidata] Possibility of data lock

On 10.06.2016 12:53, Sandra Fauconnier wrote: On 10 Jun 2016, at 12:39, Yellowcard wrote: However, there are single statements (!) that are proven to be correct (possibly in connection with qualifiers) and are no subject to being changed in future. Locking these

[Wikidata-bugs] [Maniphest] [Commented On] T137539: Use inidividual select queries to determin which Entities are in the wbc_entity_usage table

jcrespo added a comment.A slight comment here: I know the second query is way better than the the first one- there could be an even better solution; but just doing this change would be a huge improvement (at least 100x faster).TASK DETAILhttps://phabricator.wikimedia.org/T137539EMAIL

[Wikidata-bugs] [Maniphest] [Updated] T136598: Wikidata master database connection issue

daniel added a comment. In T136598#2369366, @hoo wrote: The fix for this triggered T116404: EntityUsageTable::getUsedEntityIdStrings query on wbc_entity_usage table is sometimes fast, sometimes slow, not sure how to continue from here. We could potentially work around that, but all ideas I have

[Wikidata-bugs] [Maniphest] [Updated] T137539: Use inidividual select queries to determin which Entities are in the wbc_entity_usage table

daniel added a blocked task: T136598: Wikidata master database connection issue.TASK DETAILhttps://phabricator.wikimedia.org/T137539EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Zppix, Aklapper, hoo, aude, aaron, daniel, jcrespo, Vali.matei,

[Wikidata-bugs] [Maniphest] [Updated] T136598: Wikidata master database connection issue

daniel added a blocking task: T137539: Use inidividual select queries to determin which Entities are in the wbc_entity_usage table.TASK DETAILhttps://phabricator.wikimedia.org/T136598EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: Stashbot,

[Wikidata-bugs] [Maniphest] [Created] T137539: Use inidividual select queries to determin which Entities are in the wbc_entity_usage table

daniel created this task.daniel added projects: Performance, Wikidata, Wikidata-Sprint-2016-05-24.Herald added a subscriber: Zppix.TASK DESCRIPTIONIn EntityUsageTable::getUsedEntityIdStrings, we currently use a bulk query to see which Entity ID from a given set are actually present in the

[Wikidata-bugs] [Maniphest] [Block] T116404: EntityUsageTable::getUsedEntityIdStrings query on wbc_entity_usage table is sometimes fast, sometimes slow

daniel created blocking task T137539: Use inidividual select queries to determin which Entities are in the wbc_entity_usage table.TASK DETAILhttps://phabricator.wikimedia.org/T116404EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: aaron, aude,

Re: [Wikidata] Possibility of data lock

On 10.06.2016 12:49, jay...@gmail.com wrote: Wikis also have auto patrolled rights. The fundamental issue here is that modification of a well qualified / sourced statement should be extremely rare as facts rarely change. This is a level of granularity that Wikidata promises to make fundamental

Re: [Wikidata] Possibility of data lock

On 10.06.2016 12:20, Jane Darnell wrote: Yes I agree, so I guess I disagree with the idea of a "data lock". I do however, recognize the desire for a "data lock" which arises out of a personal frustration with good-faith Wikidata editor behavior. Many of these unnecessary edits & subsequent

[Wikidata-bugs] [Maniphest] [Commented On] T116404: EntityUsageTable::getUsedEntityIdStrings query on wbc_entity_usage table is sometimes fast, sometimes slow

daniel added a comment.@jcrespo so we should do one query per ID, with limit 1? ok!TASK DETAILhttps://phabricator.wikimedia.org/T116404EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: aaron, aude, daniel, hoo, Aklapper, jcrespo, Vali.matei,

[Wikidata-bugs] [Maniphest] [Edited] T137538: Use interwiki code from Sites facility to create language links.

daniel edited the task description.TASK DETAILhttps://phabricator.wikimedia.org/T137538EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Zppix, Aklapper, daniel, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Krenair

[Wikidata-bugs] [Maniphest] [Edited] T137537: Ensure correct information about Wikimedia sites in the Sites facility on the Wikimedia cluster.

daniel edited the task description.TASK DETAILhttps://phabricator.wikimedia.org/T137537EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Zppix, Aklapper, daniel, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Krenair

[Wikidata-bugs] [Maniphest] [Updated] T66649: 'Add link' function in Wikipedia creates items with wrong language code

daniel added a project: Wikidata-Sprint-2016-06-07.TASK DETAILhttps://phabricator.wikimedia.org/T66649EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: jhsoby, Ricordisamoa, Aklapper, Danmichaelo, Wikidata-bugs, Nemo_bis, SPQRobin, He7d3r, aude,

[Wikidata-bugs] [Maniphest] [Updated] T66649: 'Add link' function in Wikipedia creates items with wrong language code

daniel removed a project: Need-volunteer.TASK DETAILhttps://phabricator.wikimedia.org/T66649EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: jhsoby, Ricordisamoa, Aklapper, Danmichaelo, Wikidata-bugs, Nemo_bis, SPQRobin, He7d3r, aude, Liuxinyu970226,

[Wikidata-bugs] [Maniphest] [Updated] T66649: 'Add link' function in Wikipedia creates items with wrong language code

daniel added a blocking task: T137536: Use correct term language when creating items from the client.TASK DETAILhttps://phabricator.wikimedia.org/T66649EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: jhsoby, Ricordisamoa, Aklapper, Danmichaelo,

[Wikidata-bugs] [Maniphest] [Updated] T137536: Use correct term language when creating items from the client

daniel added a blocked task: T66649: 'Add link' function in Wikipedia creates items with wrong language code.TASK DETAILhttps://phabricator.wikimedia.org/T137536EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper, Zppix, daniel, D3r1ck01, Izno,

[Wikidata-bugs] [Maniphest] [Updated] T137536: Use correct term language when creating items from the client

daniel added a blocked task: T39459: [Task] Don't try to add labels in non-existing languages: restrict to Language::isKnownLanguageTag.TASK DETAILhttps://phabricator.wikimedia.org/T137536EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper,

[Wikidata-bugs] [Maniphest] [Retitled] T137536: Use correct term language when creating items from the client

daniel changed the title from "Ensure use of correct term language when creating items from the client." to "Use correct term language when creating items from the client".TASK DETAILhttps://phabricator.wikimedia.org/T137536EMAIL

[Wikidata-bugs] [Maniphest] [Updated] T39459: [Task] Don't try to add labels in non-existing languages: restrict to Language::isKnownLanguageTag

daniel added a blocking task: T137536: Use correct term language when creating items from the client.TASK DETAILhttps://phabricator.wikimedia.org/T39459EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: adrianheine, danielCc: gerritbot, Ricordisamoa,

Re: [Wikidata] Possibility of data lock

> On 10 Jun 2016, at 12:39, Yellowcard wrote: > However, there are single statements (!) that > are proven to be correct (possibly in connection with qualifiers) and > are no subject to being changed in future. Locking these statements > would make them much less risky

[Wikidata-bugs] [Maniphest] [Triaged] T137536: Ensure use of correct term language when creating items from the client.

daniel triaged this task as "High" priority.daniel added a comment.Setting prio to "high", since using language codes like "simple" for terms is incorrect. This is a form of data corruption.TASK DETAILhttps://phabricator.wikimedia.org/T137536EMAIL

[Wikidata-bugs] [Maniphest] [Created] T137538: Use interwiki code from Sites facility to create language links.

daniel created this task.daniel added projects: Wikidata-Sprint-2016-05-24, MediaWiki-Sites, MediaWiki-extensions-WikibaseClient.Herald added a project: Wikidata.TASK DESCRIPTIONCurrently, we (ab)use the content language field from the Site object as the prefix for creating language links. This

[Wikidata-bugs] [Maniphest] [Updated] T137538: Use interwiki code from Sites facility to create language links.

daniel added a blocking task: T137537: Ensure correct information about Wikimedia sites in the Sites facility on the Wikimedia cluster..TASK DETAILhttps://phabricator.wikimedia.org/T137538EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Zppix,

Re: [Wikidata] Possibility of data lock

Wikis also have auto patrolled rights. The fundamental issue here is that modification of a well qualified / sourced statement should be extremely rare as facts rarely change. This is a level of granularity that Wikidata promises to make fundamental differences to how content grows and how editing

[Wikidata-bugs] [Maniphest] [Updated] T137537: Ensure correct information about Wikimedia sites in the Sites facility on the Wikimedia cluster.

daniel added a blocked task: T137538: Use interwiki code from Sites facility to create language links..TASK DETAILhttps://phabricator.wikimedia.org/T137537EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Zppix, Aklapper, daniel, D3r1ck01, Izno,

[Wikidata-bugs] [Maniphest] [Updated] T137536: Ensure use of correct term language when creating items from the client.

daniel edited projects, added MediaWiki-extensions-WikibaseClient; removed MediaWiki-extensions-WikibaseRepository.TASK DETAILhttps://phabricator.wikimedia.org/T137536EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper, Zppix, daniel, D3r1ck01,

[Wikidata-bugs] [Maniphest] [Updated] T137537: Ensure correct information about Wikimedia sites in the Sites facility on the Wikimedia cluster.

daniel removed a project: MediaWiki-extensions-WikibaseRepository.TASK DETAILhttps://phabricator.wikimedia.org/T137537EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Zppix, Aklapper, daniel, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Krenair

[Wikidata-bugs] [Maniphest] [Updated] T137537: Ensure correct information about Wikimedia sites in the Sites facility on the Wikimedia cluster.

daniel added a project: MediaWiki-Sites.TASK DETAILhttps://phabricator.wikimedia.org/T137537EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Zppix, Aklapper, daniel, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Krenair

[Wikidata] ArticlePlaceholder rolled out to next wikis

Hey folks :) Just a quick heads-up that for the second round 3 more Wikipedias (Gujarati, Latvian, Nynorsk) requested the ArticlePlaceholder be enabled. We have done this last night. This means it is now live on the following Wikipedias: * Napolitan * Esperanto * Odia * Haitian Creole * Gujarati

[Wikidata-bugs] [Maniphest] [Created] T137537: Ensure currect information about Wikimedia sites in the Sites facility on the Wikimedia cluster.

daniel created this task.daniel added projects: Wikidata, MediaWiki-extensions-WikibaseRepository, Wikidata-Sprint-2016-06-07.TASK DESCRIPTIONCurrently, SiteLookup is backed by the information in the sites table. The information in this table is incorrect for many wikis in the Wikimedia cluster.

[Wikidata-bugs] [Maniphest] [Block] T137536: Ensure use of correct term language when creating items from the client.

daniel created blocking task T137537: Ensure currect information about Wikimedia sites in the Sites facility on the Wikimedia cluster..TASK DETAILhttps://phabricator.wikimedia.org/T137536EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper,

[Wikidata-bugs] [Maniphest] [Updated] T137537: Ensure currect information about Wikimedia sites in the Sites facility on the Wikimedia cluster.

daniel added a blocking task: T135149: Implement a SiteLookup based on a nested array structure..TASK DETAILhttps://phabricator.wikimedia.org/T137537EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Zppix, Aklapper, daniel, D3r1ck01, Izno,

Re: [Wikidata] Possibility of data lock

Hi! john cummings: > I guess the issue may be different for Wikipedia and Wikidata in that the > size of the community to number of items/articles is very different. That's correct, so flagged revisions wouldn't work on Wikidata, but we need different approaches. I believe that the approach of

[Wikidata-bugs] [Maniphest] [Created] T137536: Ensure use of correct term language when creating items from the client.

daniel created this task.daniel added projects: MediaWiki-extensions-WikibaseRepository, Wikidata-Sprint-2016-06-07.Herald added subscribers: Zppix, Aklapper.Herald added a project: Wikidata.TASK DESCRIPTIONWhen we create an items on the fly to allow pages on two client wikis to be connected via

[Wikidata-bugs] [Maniphest] [Updated] T137536: Ensure use of correct term language when creating items from the client.

daniel added a blocking task: T137534: Map dummy language codes in sites.TASK DETAILhttps://phabricator.wikimedia.org/T137536EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper, Zppix, daniel, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331

Re: [Wikidata] Possibility of data lock

Hi Markus, Markus Kroetzsch schrieb: > I have read > several people expressing that "only trustworthy" or "experienced" > editors should be allowed to edit certain things. In my view, this is > fundamentally against the way in which Wikipedia is working. Protections > in Wikipedia are used in

Re: [Wikidata] Possibility of data lock

Yes I agree, so I guess I disagree with the idea of a "data lock". I do however, recognize the desire for a "data lock" which arises out of a personal frustration with good-faith Wikidata editor behavior. Many of these unnecessary edits & subsequent reversions on Wikidata could be avoided when a

[Wikidata-bugs] [Maniphest] [Commented On] T116404: EntityUsageTable::getUsedEntityIdStrings query on wbc_entity_usage table is sometimes fast, sometimes slow

jcrespo added a comment.@daniel I think this is a case of prematurely optimizing. It is true that things like: foreach ... { 'SELECT' } Are usually considered bad practices, but for trying to minimize "round-trip time", we are actually doing a way worse query. Your query cannot know that with

  1   2   >