date:20180220

gerritbot added a comment.
Change 412664 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable x-kill feature everywhere

https://gerrit.wikimedia.org/r/412664TASK DETAILhttps://phabricator.wikimedia.org/T184322EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, gerritbotCc: Agabi10, RP88, IKhitron, Joe, hoo, Doc_James, PokestarFan, eranroz, Izno, Oliv0, Ltrlg, Scott_WUaS, CennoxX, Liuxinyu970226, aude, Lydia_Pintscher, daniel, Aklapper, Halfak, gerritbot, thiemowmde, Bawolff, Stashbot, Marostegui, jcrespo, Ladsgroup, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T186714: enable x-kill feature on Commons

gerritbot added a comment.
Change 412664 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable x-kill feature everywhere

https://gerrit.wikimedia.org/r/412664TASK DETAILhttps://phabricator.wikimedia.org/T186714EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, gerritbotCc: gerritbot, Mike_Peel, Aklapper, Lydia_Pintscher, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T184000: Magic word on English WP to override display of Wikidata short description

2018-02-20 Thread Tgr

Tgr added a comment.

In T184000#3987414, @Addshore wrote:
So, again overriding the current wikidata description here is a breaking change.
 We should not do that.
 If we want to add something new, such as an article description, lets add it under a new key called "article-description" instead of redefining something that already exists and has a clear definition.


Is it actually breaking anything, though? Clients want a description, they get one. (A better one, if we do this whole override thing on account of considering the local description superior.) In what possible scenario would that cause a problem?
The only one I can think of is when a client feeds this information back to Wikidata, e.g. by showing editable article descriptions, and I'm not aware of anything doing that (there was work on it for the official apps in T90765 and T145813 but not enabled yet).TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: TheDJ, Fjalapeno, Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T127470: Deploy item quality classification model for Wikidata

2018-02-20 Thread awight

awight added a parent task: T187836: [Epic] Audit of pending ORES GUI deployments.
TASK DETAILhttps://phabricator.wikimedia.org/T127470EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_WD, awightCc: Glorian_WD, Ladsgroup, Halfak, Glorian_Yapinus, Sumit, Ricordisamoa, Aklapper, StudiesWorld, Lydia_Pintscher, samuwmde, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 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] T184000: Magic word on English WP to override display of Wikidata short description

2018-02-20 Thread Addshore

Addshore added a comment.

In T184000#3984789, @Tgr wrote:

The parser function hook stores the argument of the parserfunction in the ParserOutput's page properties with a wikibase-description-override key.

So, this doesn't really have anything to do with wikibase, what we are adding here is a parser function to register an article description, that we want to be accessible via an API.
I agree with what @Alsee says that the description of the wikidata item and the description of the article can be and probably should be two distinct things.

In PageTerms::execute go through the returned terms, and replace the descriptions with overrides when available. Rely on the PageProps class to do the caching.

Maybe keep the Wikidata description and add it to the API result under a different name (wikibaseDescription? originalDescription?) so that old clients will automatically use the overrides while clients aware of what's going on can decide for themselves.

So, again overriding the current wikidata description here is a breaking change.
We should not do that.
If we want to add something new, such as an article description, lets add it under a new key called "article-description" instead of redefining something that already exists and has a clear definition.

Modify the API help messages (only if overrides are enabled) to make clear what's happening. Not considered an API B/C break since clients still get a description, just from a slightly different source.

Again, changing what is under the description key is a break in compatibility in my eyes, the description key should remain the wikidata description for the item linked to the article. If we want to add other stuff, then sure.

In T184000#3986504, @daniel wrote:
@Tgr Sounds like a decent plan. In an ideal world, the "short description" functionality would be factored out of wikidata, so it could be backed by *just* the magic word or *just* wikidata or both combined or something else. But that would of course break B/C. So I suppose modifying PageTerms is an OK solution. I agree that making TermSqlIndex aware of the override wouldn't be a good choice.

We could factor out the page terms stuff and not break B/C, just leaving the wikidata stuff where it is now and adding new keys for extra stuff. 'description' and 'article-description' could live side by side. One backed by wikidata and one backed by a magic word / parser function.

Instead of making the "original" description available in addition (which one is "original" anyway?) or indicating whether the description returned was overwritten, perhaps add a parameter for suppressing the override, forcing the use of the description from wikidata: disable-description-override or force-shared-description or something.

A param could be another route, something that would allow selecting of the source of the terms. options could be 'wikibase', or 'parser-overrides' or 'wikibase-fallback' etc with varying behaviours.

In T184000#3987276, @Tgr wrote:

In T184000#3987260, @Alsee wrote:
The Wikidata label is a description of the Wikidata item.

"Label" in Wikidata terminology is the article title (e.g. Q663375 has the English label "hatmaking" and English description "manufacture and design of hats and headwear"; there's a separate item for hatmaker).

This sentence is a bit misleading. "Label" in Wikidata terminology is nothing to do with 'article title'.
As written in the wikidata glossary "Label (also name) is the main name given to identify an entity".
So it is the term used to describe the concept of the item, but let's avoid the word article there to avoid any confusion.

In T184000#3985054, @TheDJ wrote:
@Tgr I'm assuming no markup (like in wikidata). What about text length restrictions ? (I remember space in pageprops was limited??)

Markup should be removed, probably just by stripping HTML tags. page_props.pp_value is a blob (65K) but page terms are VARCHAR(255) so probably best limit it to that. (Not sure if there should be some kind of error message if it has to be truncated.)

The length of a wikidata description is actually currently 250 rather than 255 (as is in the db).
This can be found in Wikibase.default.php in Wikibase/repo/config

// Define constraints for multilingual terms (such as labels, descriptions and aliases).
'multilang-limits' => [
'length' => 250, // length constraint
],TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AddshoreCc: TheDJ, Fjalapeno, Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T187793: Inject IContextSource into ViolationMessageRenderer

Ladsgroup added a subscriber: daniel.Ladsgroup added a comment.
So the reason I made MessageLocalizer is that we wanted to inject RequestContext somewhere just to use the msg method and @daniel pointed out that this class is a huge kitchen sink that are dragging around. That interface is an attempt to decouple RequestContext and message localization. In my ideal world, core would implement a proper RequestBasedMessageLocalizer and we would only inject that but for now I think injecting RequestContext instance using MessageLocalizer typehint (so we can easily mock it in tests, etc.) would be enough for me.TASK DETAILhttps://phabricator.wikimedia.org/T187793EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: daniel, Lucas_Werkmeister_WMDE, Aklapper, Ladsgroup, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] [Changed Subscribers] T187767: Choose a service name for the new internal WDQS cluster and configure LVS

2018-02-20 Thread Smalyshev

Smalyshev added subscribers: Lydia_Pintscher, daniel, Smalyshev.Smalyshev added a comment.
I'd go with wdqs-internal. Not sure what the suffix would be - it should probably only be accessible from production machines, but we need to also be able to test it somehow I think - i.e. to make sure the endpoint works - not sure whether it needs also external address. If we need one then probably query-internal.wikidata.org.TASK DETAILhttps://phabricator.wikimedia.org/T187767EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, daniel, Lydia_Pintscher, Gehel, Aklapper, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Jonas, FloNight, 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] [Commented On] T187296: Increase kafka event retention to 14 or 21 days

2018-02-20 Thread Smalyshev

Smalyshev added a comment.
I need it only on jumbo I think, that's where I'll be connecting.TASK DETAILhttps://phabricator.wikimedia.org/T187296EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: elukey, Ottomata, Aklapper, Nuria, Ladsgroup, Pchelolo, JAllemandou, Smalyshev, Lahi, Gq86, Vacio, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, Jonas, FloNight, Xmlizer, Nirmos, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, Krenair, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

Ladsgroup added a comment.
Our idea would be to have it as memcached.TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, LadsgroupCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T184322: Enable fine grained lua tracking gradually in client wikis

Ladsgroup added a subtask: T186714: enable x-kill feature on Commons.
TASK DETAILhttps://phabricator.wikimedia.org/T184322EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: Agabi10, RP88, IKhitron, Joe, hoo, Doc_James, PokestarFan, eranroz, Izno, Oliv0, Ltrlg, Scott_WUaS, CennoxX, Liuxinyu970226, aude, Lydia_Pintscher, daniel, Aklapper, Halfak, gerritbot, thiemowmde, Bawolff, Stashbot, Marostegui, jcrespo, Ladsgroup, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T186714: enable x-kill feature on Commons

Ladsgroup added a parent task: T184322: Enable fine grained lua tracking gradually in client wikis.
TASK DETAILhttps://phabricator.wikimedia.org/T186714EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: gerritbot, Mike_Peel, Aklapper, Lydia_Pintscher, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, 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] T184322: Enable fine grained lua tracking gradually in client wikis

gerritbot added a comment.
Change 412664 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[operations/mediawiki-config@master] Enable x-kill feature everywhere

https://gerrit.wikimedia.org/r/412664TASK DETAILhttps://phabricator.wikimedia.org/T184322EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, gerritbotCc: Agabi10, RP88, IKhitron, Joe, hoo, Doc_James, PokestarFan, eranroz, Izno, Oliv0, Ltrlg, Scott_WUaS, CennoxX, Liuxinyu970226, aude, Lydia_Pintscher, daniel, Aklapper, Halfak, gerritbot, thiemowmde, Bawolff, Stashbot, Marostegui, jcrespo, Ladsgroup, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T184000: Magic word on English WP to override display of Wikidata short description

2018-02-20 Thread Tgr

Tgr added a subscriber: TheDJ.Tgr added a comment.

In T184000#3987260, @Alsee wrote:
The Wikidata label is a description of the Wikidata item.


"Label" in Wikidata terminology is the article title (e.g. Q663375 has the English label "hatmaking" and English description "manufacture and design of hats and headwear"; there's a separate item for hatmaker).


In T184000#3985054, @TheDJ wrote:
This raises an interesting point... what about label ? Where is that used ? What should it do in this mode ? Reflect the page title ? automatically strip the (disambig) postfix if there is a description ?


I don't see any reason to touch label handling.


In T184000#3985054, @TheDJ wrote:
@Tgr I'm assuming no markup (like in wikidata). What about text length restrictions ? (I remember space in pageprops was limited??)


Markup should be removed, probably just by stripping HTML tags. page_props.pp_value is a blob (65K) but page terms are VARCHAR(255) so probably best limit it to that. (Not sure if there should be some kind of error message if it has to be truncated.)

Which reminds me, the override should be exposed in page information.


In T184000#3986504, @daniel wrote:
Instead of making the "original" description available in addition (which one is "original" anyway?) or indicating whether the description returned was overwritten, perhaps add a parameter for suppressing the override, forcing the use of the description from wikidata: disable-description-override or force-shared-description or something.


source=shared vs local maybe?TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: TheDJ, Fjalapeno, Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T184000: Magic word on English WP to override display of Wikidata short description

2018-02-20 Thread Alsee

Alsee added a comment.
I'm not familiar with all of the API issues, but if this helps:
The magicword Shortdesc: is actually a description of the article. The Wikidata label is a description of the Wikidata item. Someone thought Wikidata labels could conveniently be re-used as if they were an article description. But they aren't article descriptions.

For example, some Wikipedia languages have an article on "Hatmaking", other languages may have an article on "Hatmakers". They are all linked to the same Wikidata item, and it's pretty much random whether the Wikidata item is "Hatmaker" or "Hatmaking". Another example, Wikidata has items for "Seesaw" and "swing". However the Czech language has a single word that covers both, and Czech Wikipedia has a single article that covers both. (The Czech article is linked to one of those two Wikidata items at random, because of a Wikidata design flaw that can't handle the correct dual-linkage.)

So aside from the issue that the EnWiki community wants local control of what is functionally EnWiki content, the Wikidata label is not, and never was, a description of an article.TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, AlseeCc: Fjalapeno, Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T141622: Delete/undelete the MediaInfo page automatically when delete/undelete the file

2018-02-20 Thread Ramsey-WMF

Ramsey-WMF moved this task from Untriaged to Desired epics on the Multimedia board.Ramsey-WMF triaged this task as "Normal" priority.
TASK DETAILhttps://phabricator.wikimedia.org/T141622WORKBOARDhttps://phabricator.wikimedia.org/project/board/48/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ramsey-WMFCc: Aklapper, Bugreporter, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, V4switch, LawExplorer, Susannaanas, Wong128hk, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Bawolff, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Matanya, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T184000: Magic word on English WP to override display of Wikidata short description

2018-02-20 Thread daniel

daniel added a comment.
...as to registering the description as used: this should be governed by a separate setting. It really has nothing to do with the magic word.

I think the setting should be generic, not limited to descriptions. E.g.:

$wgWBClientSettings['impliciteUsageAspects'] = [ 'D', 'L' ];

...that would track implicite description and label usage for the "connected" item. Actually, this should be restricted to the content language (unless the wiki is multi-lingual):

$wgWBClientSettings['impliciteUsageAspects'] = [ 'D.en', 'L.en' ];

Actually, there already is one implicit usage being tracked: 'S' for the sitelink itself. This is done in lientParserOutputDataUpdater::updateItemIdProperty(). Other implicite usages should also be tracked there. That method is indeed triggered by the ContentAlterParserOutput hook, via ParserOutputUpdateHookHandlers::doContentAlterParserOutput.

The more I think about this, the I believe we should have a separate ticket for that feature. It's conceptually related, but technically completely unrelated to the magic word. I originally thought it would touch the same code, but looking at it now, I don't think it does.TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, danielCc: Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187061: Don’t cache constraint check results involving current time whose validity will change soon

Lucas_Werkmeister_WMDE added a comment.
I think this should be working now, but I’ll try a manual test, just to make sure.TASK DETAILhttps://phabricator.wikimedia.org/T187061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] [Changed Project Column] T187061: Don’t cache constraint check results involving current time whose validity will change soon

WMDE-leszek moved this task from Review to Done on the Wikidata-Sprint-2018-02-14 board.WMDE-leszek removed a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T187061WORKBOARDhttps://phabricator.wikimedia.org/project/board/3247/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, WMDE-leszekCc: gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, abian, Wikidata-bugs, aude, Mbch331, Giuliamocci, Adrian1985, Cpaulf30, Baloch007, Darkminds3113, Lordiis, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T187061: Don’t cache constraint check results involving current time whose validity will change soon

WMDE-leszek updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...- [x] [small helper function](https://gerrit.wikimedia.org/r/411252)
- [ - [x] [`RangeChecker`](https://gerrit.wikimedia.org/r/411041)
- [ - [x] [`CachingResultsBuilder`](https://gerrit.wikimedia.org/r/411248)TASK DETAILhttps://phabricator.wikimedia.org/T187061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, WMDE-leszekCc: gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] [Commented On] T185332: Investigation: How to make it possible to format a Lexeme used in a statement

gerritbot added a comment.
Change 406608 abandoned by WMDE-leszek:
[DNM] Move the lexeme "displaying" logic to the LexemePresenter

https://gerrit.wikimedia.org/r/406608TASK DETAILhttps://phabricator.wikimedia.org/T185332EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: WMDE-leszek, gerritbotCc: He7d3r, thiemowmde, gerritbot, Aklapper, WMDE-leszek, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T185332: Investigation: How to make it possible to format a Lexeme used in a statement

gerritbot added a comment.
Change 406306 abandoned by WMDE-leszek:
[DNM] Display lexemes in statements

https://gerrit.wikimedia.org/r/406306TASK DETAILhttps://phabricator.wikimedia.org/T185332EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: WMDE-leszek, gerritbotCc: He7d3r, thiemowmde, gerritbot, Aklapper, WMDE-leszek, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T186606: Investigation: How to format lexeme to be display in a statement value efficiently

gerritbot added a comment.
Change 409830 abandoned by WMDE-leszek:
[DNM] Add SQL-index-based LexemePresenter

https://gerrit.wikimedia.org/r/409830TASK DETAILhttps://phabricator.wikimedia.org/T186606EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: WMDE-leszek, gerritbotCc: thiemowmde, Lucas_Werkmeister_WMDE, gerritbot, Aklapper, WMDE-leszek, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

thiemowmde added a comment.
Personally, I'm totally fine with using any kind of cache, might it be an in-memory one or something else. My worst-case scenario is as follows: Let's say we have 10 million Lexemes, 2 lemmas per Lexeme, 20 bytes per lemma. The cache would need to hold about 0.4 gigabytes. What kind of cache would be ok with such a size?TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T185712: Make Context serializable

Lucas_Werkmeister_WMDE added a comment.
I admit I’m tempted to go with the much simpler … fake EntityDocument …

Hm, though if we do go with a temporary solution, an alternative approach would be a new Context implementation, which only supports storeCheckResultInArray (because that’s all we need for the caching use-case), and throws LogicExceptions on all other getters. (I think it could be a single implementation supporting all three context types – statement, qualifier, reference – since they’re pretty similar anyways: see the shared code in ApiV2Context.)TASK DETAILhttps://phabricator.wikimedia.org/T185712EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Ladsgroup, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] [Changed Subscribers] T185712: Make Context serializable

Lucas_Werkmeister_WMDE added a subscriber: Ladsgroup.Lucas_Werkmeister_WMDE added a comment.
what do we do?

So here are the things that you need in order to check constraints on a Context:


type (e. g. “used as qualifier” constraints)
snak (e. g. “one of” constraints)
snak rank (many constraint types are disabled on deprecated statements – although that is the only use of getSnakRank(), and we might want to turn that into a declarative solution instead, similar to the supported context types)
entity ID (e. g. “symmetric”, “inverse” constraints)
entity statements (e. g. “item requires statement” constraints)
snak group (e. g. “single value” constraints)


And here are the things that you need in order to store a CheckResult into the right place according to its Context:


type
entity ID serialization
statement property ID serialization
statement GUID
snak hash
snak property ID serialization (qualifier, reference only)
reference hash (reference only)


The two sets are almost completely disjoint, though the second one can be mostly derived from the first one. So perhaps we should split them up? The checkers get the first set of data in something called, dunno, a ContextData container. A CheckResult contains the second  set of data in, uh, a ContextCursor. And we only need to deserialize ContextCursors (which, you’ll observe, exclusively consist of strings), not ContextData. The separation between the two isn’t entirely clean because the checkers need some way to get a ContextCursor from the ContextData (so that they can instantiate a CheckResult – unless the cursor is only attached at the DelegatingConstraintChecker level? hmm), but since a ContextCursor can be mostly derived from ContextData (except that ContextData doesn’t explicitly contain the statement), that shouldn’t be a huge problem.

@Ladsgroup since IIRC you were unhappy with the old Context interface… any thoughts on this? (I’m afraid it’s still more than one method per interface, though.)



On the other hand – that separation is a lot more work than I assumed for this task, so I admit I’m tempted to go with the much simpler

Return some fake EntityDocument that only holds the ID and nothing else

at least temporarily… in fact such a FakeEntityDocument implementation already exists (though only in the tests of data-model-services).TASK DETAILhttps://phabricator.wikimedia.org/T185712EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Ladsgroup, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] [Claimed] T178303: Fill SPARQL query template for the domain of interest in the primary sources filter

2018-02-20 Thread Hjfocs

Hjfocs claimed this task.Hjfocs added a subscriber: Afnecors.Hjfocs moved this task from Upcoming to Doing on the Wikidata-primary-sources board.
TASK DETAILhttps://phabricator.wikimedia.org/T178303WORKBOARDhttps://phabricator.wikimedia.org/project/board/2788/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: HjfocsCc: Afnecors, Aklapper, Hjfocs, Lahi, Gq86, GoranSMilovanovic, Kiailandi, QZanden, dachary, LawExplorer, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Tpt, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187186: Use ViolationMessage in ConstraintParameterException

gerritbot added a comment.
Change 411307 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Use ViolationMessageRenderer in CheckConstraintParameters

https://gerrit.wikimedia.org/r/411307TASK DETAILhttps://phabricator.wikimedia.org/T187186EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, gerritbotCc: Lucas_Werkmeister_WMDE, Aklapper, gerritbot, WMDE-leszek, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, 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] [Commented On] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

WMDE-leszek added a comment.
I just had a chat with @Ladsgroup and he suggested regarding wbl_lemmas table the following: what about not putting this stuff in the database table but storing all lemmas for display in the cache (or cache them when they're used). I am bit ignorant, but as wbl_lemmas is made for display only (which is my understanding), this seems like a plausible thought. Of course as long as the amount of data is something which is fine for caching.

I am not aware of all constraints, so any thoughts on this @thiemowmde and @daniel?TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, WMDE-leszekCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187296: Increase kafka event retention to 14 or 21 days

2018-02-20 Thread Ottomata

Ottomata added a comment.
Is there a reason we want to do this on main instead of jumbo?  Stas will be consuming from jumbo, since it has timestamp offset support.TASK DETAILhttps://phabricator.wikimedia.org/T187296EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: OttomataCc: elukey, Ottomata, Aklapper, Nuria, Ladsgroup, Pchelolo, JAllemandou, Smalyshev, Lahi, Gq86, Vacio, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, Jonas, FloNight, Xmlizer, Nirmos, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, Krenair, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

thiemowmde updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...Suggestion is to go with VARCHAR(20) for both columns.

Suggestion is to //not// reserve space for repository prefixes. Even on a multi-repository setting the Item references used for lexical categories and languages should always come from a single repository.

== Lemma column length...TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T187793: Inject IContextSource into ViolationMessageRenderer

Lucas_Werkmeister_WMDE created this task.Lucas_Werkmeister_WMDE added projects: Wikidata, Wikibase-Quality, Wikibase-Quality-Constraints.Herald added a subscriber: Aklapper.
TASK DESCRIPTION@Ladsgroup pointed out in a comment on I154d9cdebe that ConstraintParameterRenderer and ViolationMessageRenderer could get an IContextSource injected (or, more generically, any MessageLocalizer?) and use its msg function instead of using new Message() and wfMessage() directly. I’m not sure if that has any concrete advantages, but it sounds good to me.TASK DETAILhttps://phabricator.wikimedia.org/T187793EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Lucas_Werkmeister_WMDE, Aklapper, Ladsgroup, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] [Edited] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

thiemowmde updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...* The numbers of rows in the proposed wbl_item_references tables is going to be identical to the total number of Lexemes. There is only one lemma per Lexeme (in only one language),According https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/Data_Model there is only one Item reference for the lexical category, and only one Item reference for the language. This makes the two database tables proposed hereable significantly different from wb_terms, where each Item can have labels and descriptions in 300+ languages, and users are able to enter as many aliases as they want.
* A Lexeme can have multiple lemmas, one per language code. (Note: The exact set of language codes is currently unspecified, but is most probably going to be limited to a configured set of a few hundred.) While similar, lemmas are still distinctively different from Item labels. For Item labels users are expected to enter as many as they can, while for lemmas users will only enter multiple lemmas if the Lexeme requires it. Example: The American "color" and British "colour" are supposed to be modeled as lemmas on a single Lexeme. A best-case approximation are two lemmas per Lexeme, and users are able to enter as many aliases as they wanta worst-case approximation are ten lemmas per Lexeme* In contract to Item labels, the lemma of a Lexeme is (by definition) as are (mostly, but not exclusively) single words only.
* One of the longest words in an English dictionary is "Supercalifragilisticexpialidocious" (34 characters). Some other candidates for a longest word in other languages are about 70 characters long, see http://mentalfloss.com/article/50611/longest-word-in-the-worldI talked to PM (@Lydia_Pintscher) and we established the limit should **not** be 255 bytes, but 768.TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

WMDE-leszek added a comment.
Regarding number of lemmas per lexeme, @Lucas_Werkmeister_WMDE makes a good point. As far as I remember, @thiemowmde and I talked IRL last week about the number there, and we said something like that the security guesstimate would be to say the total number of lemmas would be 10*N, where N is a number of lexemes.
While I think this is a fairly reasonable guess, it is still the guess. We might be able to collect more data on this topic if this seems necessary. I personally think it is not :)TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, WMDE-leszekCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

thiemowmde added a comment.
We should fix https://commons.wikimedia.org/wiki/File:Lexeme_data_model.png then, because it very prominently says there is only "one" lemma. It could be this is meant to be interpreted as "one" value that can somehow contain multiple values. I wonder what the benefit of phrasing it like this is.TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

WMDE-leszek added a comment.
One of the longest words in an English dictionary is "Supercalifragilisticexpialidocious" (34 characters).

General note: English is probably not the best language to look for in the context of long words (even German beats it easily).

In contract to Item labels, the lemma of a Lexeme is (by definition) a single word only.

I am not entirely sure to what conclusion this remark would lead us, but "single word" is pretty relative here. I imagine people might want to model things like idioms as lexemes, meaning there will be e.g. multi-word lemmas etc. That said, I guess 250 characters (i.e. Unicode characters, not bytes) seems like a good initial length limit. So your conclusion here seems reasonable to me.
If we feel like it should be investigated further though, it seems like we could fairly easily get some data from wiktionaries, and I would risk saying that data would give us a pretty good estimation of sizes of things people are going to put in as lexemes and lemmas.

A "word" is also not the most clear term from the linguistic point of view, BTW.TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, WMDE-leszekCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T185712: Make Context serializable

Lucas_Werkmeister_WMDE added a comment.
I’m not sure how this would look – non-static serialize and static deserialize methods on Context and its subclasses? Or should it be a separate kind of ContextSerialization service? I think my colleagues know more about this than me, there’s a lot of serialization going on in Wikibase ;)

Separate ContextSerializer and ContextDeserializer is probably the way to go, in analogy to some other (de)serializers we already have in WBQC and also in Wikibase.

Different question: a Context currently holds an EntityDocument, which many checkers also assume is a StatementListProvider. Obviously, we don’t want to serialize the full entity… what do we do? Return some fake EntityDocument that only holds the ID and nothing else, and document that deserialized contexts cannot be used to actually check the constraint? Or return some kind of EntityDocument that lazily loads the real underlying object (using an underlying EntityLookup)? Or restructure Context into a more convenient form?TASK DETAILhttps://phabricator.wikimedia.org/T185712EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] [Commented On] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

2018-02-20 Thread daniel

daniel added a comment.
Am 20.02.2018 um 15:44 schrieb Lucas_Werkmeister_WMDE:

Lucas_Werkmeister_WMDE added a comment.

There is only one lemma per Lexeme (in only one language)

Don’t we have something to support e. g. “color” and “colour” for the same
lexeme? I’m not sure if that’s two lemmas or one lemma (multilingual text) with
two spellings, but there seems to be some need for multiple texts and languages
per lexeme (though the average number of texts per lexeme will probably only be
slightly above one).

Yes, that's one of the standard examples of a Lexeme with multiple lemma
variants. The representations of Forms of that lexeme can then also have
multiple variants (plural: colors/colors).

Variants are used to cover different spellings or alphabets. It's till one Lemma
(and one Form).

Other examples include stopp vs stopp, Tal vs Thal, etc.

Since we know we are exclusively dealing with Item references, but no other
entity types, we could store the references as integers.

What about federation? I guess it could still work, at least with the way
federation currently works (configured per entity type), where we know that all
items reside in one repository.

Federation is indeed currently limited to one repo per entity type. That
limitation is however not an assumption spread throughout the code, but is a
imposed by the implementation details of one or two classes. So it's (in theory)
easy to change. We should be very careful not to rely on this assumption anywhere.

But yes, for now, we rely on all items to reside in a single repo: Wikidata.
That should be sufficient for our use case.TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, danielCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

Lucas_Werkmeister_WMDE added a comment.
There is only one lemma per Lexeme (in only one language)

Don’t we have something to support e. g. “color” and “colour” for the same lexeme? I’m not sure if that’s two lemmas or one lemma (multilingual text) with two spellings, but there seems to be some need for multiple texts and languages per lexeme (though the average number of texts per lexeme will probably only be slightly above one).

Since we know we are exclusively dealing with Item references, but no other entity types, we could store the references as integers.

What about federation? I guess it could still work, at least with the way federation currently works (configured per entity type), where we know that all items reside in one repository.TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, Lucas_Werkmeister_WMDECc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T57783: Factor out FormatAutocomments hook code, improve and add tests

thiemowmde added a project: Technical-Debt.
TASK DETAILhttps://phabricator.wikimedia.org/T57783EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: samuwmde, Ricordisamoa, Aklapper, Wikidata-bugs, thiemowmde, JanZerebecki, aude, Lydia_Pintscher, hoo, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, Zoranzoki21, LawExplorer, TheDJ, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T187344: Add language codes for Arabic languages for use in labels, aliases and descriptions to Wikidata

thiemowmde added a project: Community-consensus-needed.thiemowmde triaged this task as "Low" priority.thiemowmde added a comment.
As for the code, it is currently not possible and not planned to support additional languages for labels and descriptions that are not supported by MediaWiki core. Adding code for this is certainly possibly, but I can not predict how much work this is going to be.

Setting priority to "low" for the moment as long as there is no approval by the committee.TASK DETAILhttps://phabricator.wikimedia.org/T187344EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: thiemowmde, Arrbee, KartikMistry, Jsahleen, jhsoby, Petar.petkovic, santhosh, Mbch331, Bassem, Ibrahim.ID, Helmoony, FShbib, ASammour, Jar, Meno25, TerraCodes, Jay8g, Liuxinyu970226, Nikerabbit, Amire80, GerardM, satdeep_gill, millosh, Baba_Tabita, Aklapper, alanajjar, Csisc, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, Soum213, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, Luke081515, Wikidata-bugs, Snowolf, aude, Gryllida, Shizhao___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T187652: exportEntityMapping does not work with $wgDBprefix

2018-02-20 Thread ReleaseTaggerBot

ReleaseTaggerBot added a project: MW-1.31-release-notes (WMF-deploy-2018-02-20 (1.31.0-wmf.22)).
TASK DETAILhttps://phabricator.wikimedia.org/T187652EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: abian, ReleaseTaggerBotCc: gerritbot, Lucas_Werkmeister_WMDE, abian, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T187755: Double quotes in title are displayed as HTML entity in comments

thiemowmde triaged this task as "Normal" priority.thiemowmde added projects: MediaWiki-extensions-WikibaseRepository, Regression, Easy.thiemowmde moved this task from incoming to ready to go on the Wikidata board.
TASK DETAILhttps://phabricator.wikimedia.org/T187755WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: thiemowmde, Aklapper, Bugreporter, Asad_Ali_Palijo, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, RazeSoldier, Jayprakash12345, Jrbranaa, JakeTheDeveloper, QZanden, Zoranzoki21, LawExplorer, TerraCodes, MuhammadShuaib, Wong128hk, SimmeD, 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] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

thiemowmde updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTIONTwo new secondary database tables are proposed:
* wbl_lemmas stores the lemma (a text value) for each Lexeme.
* wbl_item_references (or similar) stores two Item references (lexical category and language) for each Lexeme.

== Indexes
* For the current use case both tables need a primary index on the Lexeme ID.
* A fulltext index on the Lemma column is not needed for the current use case, but it is suggested to design the table so one can be added any time later.
* Indexes on the two Item reference columns are probably never needed. Backreferences from the Items to Lexemes that use these Items will be done via MediaWiki core's link table, and Wikibase usage tracking.

== Table size
* WIPThe numbers of rows in the proposed tables is going to be identical to the total number of Lexemes. There is only one lemma per Lexeme (in only one language), only one Item reference for the lexical category, and only one Item reference for the language. This makes the two database tables proposed here significantly different from wb_terms, where each Item can have labels and descriptions in 300+ languages, and users are able to enter as many aliases as they want.

== Item references
* Item IDs are currently limited to 32 bits (signed). The maximum ID is Q2147483647, which is 11 characters.
* Some day we might need to switch to 64 bits (still signed). The maximum is then Q9223372036854775807. That's 20 characters.
* WIPSince we know we are exclusively dealing with Item references, but no other entity types, we could store the references as integers. Is this worth it with regards to performance? Or is an indexed VARCHAR column as efficient as an indexed INT column?

== Lemma column length
* The numbers of rows in the proposed tables is going to be identical to the total number of Lexemes. There is only one lemma per Lexeme (in only one language), only one Item reference for the lexical category, and only one Item reference for the language. This makes the two database tables proposed here significantly different from wb_terms, where each Item can have labels and descriptions in 300+ languages, and users are able to enter as many aliases as they want.Suggestion is to go with VARCHAR(20) for both columns.

== Lemma column length
* In contract to Item labels, the lemma of a Lexeme is (by definition) a single word onlyI talked to PM (@Lydia_Pintscher) and we established the limit should **not** be 255, but 768.TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T187652: exportEntityMapping does not work with $wgDBprefix

2018-02-20 Thread abian

abian closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T187652EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: abianCc: gerritbot, Lucas_Werkmeister_WMDE, abian, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] T187652: exportEntityMapping does not work with $wgDBprefix

gerritbot added a comment.
Change 412644 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Script exportEntityMapping: Support prefix for table names in database

https://gerrit.wikimedia.org/r/412644TASK DETAILhttps://phabricator.wikimedia.org/T187652EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: abian, gerritbotCc: gerritbot, Lucas_Werkmeister_WMDE, abian, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] T187775: Investigation: Constraints for a database schema to store representations of a Lexeme

thiemowmde created this task.thiemowmde triaged this task as "Normal" priority.thiemowmde added projects: Wikidata, Lexicographical data, Wikidata-Sprint-2018-02-14.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONTable size

WIP

Item references

WIP

Lemma column length

The numbers of rows in the proposed tables is going to be identical to the total number of Lexemes. There is only one lemma per Lexeme (in only one language), only one Item reference for the lexical category, and only one Item reference for the language. This makes the two database tables proposed here significantly different from wb_terms, where each Item can have labels and descriptions in 300+ languages, and users are able to enter as many aliases as they want.
In contract to Item labels, the lemma of a Lexeme is (by definition) a single word only.
One of the longest words in an English dictionary is "Supercalifragilisticexpialidocious" (34 characters).
Some chemicals have names with tens of thousands, even hundreds of thousands of characters. What such extreme examples basically mean is: Whatever limit we choose, it will be arbitrary. There will always be exceptions. We must always think about truncation.
Rendering lemmas with thousands of characters untruncated in contexts that reference the Lexeme (but are not meant to represent the Lexeme like the Lexeme page itself does) certainly does not make sense. When a lemma is used in the visible text or tooltip of a link, some truncation must happen. Otherwise a single link would span multiple lines or even paragraphs. A trivial truncation algorithm that prooved to be sufficent many times (e.g. in TwoColConflict) is to hard truncate via the database, and apply a CSS ellipsis to hide the hard truncation.
If we want to make sure MySQL can index all characters in a VARCHAR column, we should not go beyond VARCHAR(768). See https://phabricator.wikimedia.org/T154660#2936497 for a very closely related discussion.
Labels, descriptions, and aliases are currently limited in two ways: to 250 Unicode characters via a setting "multilang-limits", as well as 255 bytes via a VARCHAR(255) in the wb_terms table.
If we make sure we are able to expand the table structure later, we could start with VARCHAR(255), and later expand to VARCHAR(768) or further if needed.

I talked to PM (@Lydia_Pintscher) and we established the limit should not be 255, but 768.TASK DETAILhttps://phabricator.wikimedia.org/T187775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: daniel, Lucas_Werkmeister_WMDE, Ladsgroup, WMDE-leszek, thiemowmde, Aklapper, Lydia_Pintscher, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T185711: Make Constraint serializable

2018-02-20 Thread ReleaseTaggerBot

ReleaseTaggerBot added a project: MW-1.31-release-notes (WMF-deploy-2018-02-20 (1.31.0-wmf.22)).
TASK DETAILhttps://phabricator.wikimedia.org/T185711EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, ReleaseTaggerBotCc: gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, 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] [Closed] T185711: Make Constraint serializable

Lucas_Werkmeister_WMDE closed this task as "Resolved".Lucas_Werkmeister_WMDE moved this task from Review to Done on the Wikidata-Sprint-2018-02-14 board.
TASK DETAILhttps://phabricator.wikimedia.org/T185711WORKBOARDhttps://phabricator.wikimedia.org/project/board/3247/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, 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] [Unblock] T185709: Cache CheckResult serializations per-entity in ObjectCache

Lucas_Werkmeister_WMDE closed subtask T185711: Make Constraint serializable as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T185709EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, 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] [Commented On] T185711: Make Constraint serializable

gerritbot added a comment.
Change 412741 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Make Constraint serializable

https://gerrit.wikimedia.org/r/412741TASK DETAILhttps://phabricator.wikimedia.org/T185711EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, gerritbotCc: gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, 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] [Commented On] T187061: Don’t cache constraint check results involving current time whose validity will change soon

gerritbot added a comment.
Change 411041 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Add DependencyMetadata to RangeChecker results

https://gerrit.wikimedia.org/r/411041TASK DETAILhttps://phabricator.wikimedia.org/T187061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, gerritbotCc: gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, 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] [Unblock] T176638: Implement Primary Sources filter

2018-02-20 Thread Hjfocs

Hjfocs closed subtask T178306: Add SPARQL box in the primary sources filter as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T176638EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Afnecors, HjfocsCc: Aklapper, Afnecors, Lahi, Gq86, GoranSMilovanovic, Kiailandi, QZanden, dachary, LawExplorer, Hjfocs, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Tpt, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T178306: Add SPARQL box in the primary sources filter

2018-02-20 Thread Hjfocs

Hjfocs closed this task as "Resolved".Hjfocs moved this task from Doing to Done on the Wikidata-primary-sources board.Hjfocs added a comment.
Working in the gadget version: https://github.com/Wikidata/primarysources/tree/betaTASK DETAILhttps://phabricator.wikimedia.org/T178306WORKBOARDhttps://phabricator.wikimedia.org/project/board/2788/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: HjfocsCc: Afnecors, Aklapper, Hjfocs, Lahi, Gq86, GoranSMilovanovic, Kiailandi, QZanden, dachary, LawExplorer, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Tpt, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T185951: Create kafka-based recent change poller

gerritbot added a comment.
Change 412873 had a related patch set uploaded (by Gehel; owner: Gehel):
[operations/puppet@production] wdqs: allow configuration of kafka based updates

https://gerrit.wikimedia.org/r/412873TASK DETAILhttps://phabricator.wikimedia.org/T185951EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, gerritbotCc: gerritbot, Aklapper, Smalyshev, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, LawExplorer, Avner, Lewizho99, Maathavan, Gehel, Jonas, FloNight, 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] [Edited] T187061: Don’t cache constraint check results involving current time whose validity will change soon

Lucas_Werkmeister_WMDE updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...- [x] [`NowValue` additions](https://gerrit.wikimedia.org/r/411237)
- [ - [x] [future time in `DependencyMetadata`](https://gerrit.wikimedia.org/r/411038)
- [ - [x] [small helper function](https://gerrit.wikimedia.org/r/411252)...TASK DETAILhttps://phabricator.wikimedia.org/T187061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, 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] T184000: Magic word on English WP to override display of Wikidata short description

2018-02-20 Thread TheDJ

TheDJ added a comment.
@Tgr I'm assuming no markup (like in wikidata). What about text length restrictions ?

Regarding reflecting the wiki base value, i think it's best to indeed have that as an additional value within terms, but probably not by default. I'do think we would need some sort of marker in the API output, to reflect the source of the description

{
"batchcomplete": true,
"query": {
"pages": [
{
"pageid": 1973585,
"ns": 0,
"title": "STS-118",
"terms": {
"label": [
"STS-118"
],
"description": [
"human spaceflight"
],
"shared description": [ "original" ]
"datarepository": "local | wikidata | shared" (for Commons we have: "imagerepository": "shared")
}
}
]
}
}

This raises an interesting point... what about label ? Where is that used ? What should it do in this mode ? Reflect the page title ? automatically strip the (disambig) postfix if there is a description ?TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, TheDJCc: Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T174345: Restrict merging rights to autoconfirmed users

gerritbot added a comment.
Change 374328 abandoned by Urbanecm:
Restrict merging rights to autoconfirmed users on wikidatawiki

Reason:
Some concerns were raised, feel free to restore if this will be needed again.

https://gerrit.wikimedia.org/r/374328TASK DETAILhttps://phabricator.wikimedia.org/T174345EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Urbanecm, gerritbotCc: Liuxinyu970226, Esc3300, Bugreporter, matej_suchanek, Sjoerddebruin, gerritbot, Ash_Crow, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Zoranzoki21, LawExplorer, Lewizho99, Maathavan, DatGuy, Devwaker, Urbanecm, JEumerus, Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, biplabanand, Wikidata-bugs, Snowolf, aude, Dcljr, Jdforrester-WMF, Matanya, Mbch331, Rxy, Jay8g, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T174345: Restrict merging rights to autoconfirmed users

2018-02-20 Thread Urbanecm

Urbanecm removed projects: Patch-For-Review, User-Urbanecm.Urbanecm added a comment.
Removing from my radar.TASK DETAILhttps://phabricator.wikimedia.org/T174345EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: UrbanecmCc: Liuxinyu970226, Esc3300, Bugreporter, matej_suchanek, Sjoerddebruin, gerritbot, Ash_Crow, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, Zoranzoki21, LawExplorer, DatGuy, Devwaker, Urbanecm, JEumerus, Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, biplabanand, Wikidata-bugs, Snowolf, aude, Dcljr, Jdforrester-WMF, Matanya, Mbch331, Rxy, Jay8g, Krenair, Giuliamocci, Adrian1985, Cpaulf30, Baloch007, Darkminds3113, Lordiis, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T178492: Create a more controlled WDQS cluster

Gehel added a project: Epic.
TASK DETAILhttps://phabricator.wikimedia.org/T178492EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: Daniel_Mietchen, BBlack, Lydia_Pintscher, Volans, mobrovac, Jonas, Aklapper, debt, Smalyshev, Gehel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, SandraF_WMF, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Tramullas, Acer, merbst, LawExplorer, Avner, FloNight, Xmlizer, Susannaanas, Eevans, Aschroet, Jane023, jkroll, Hardikj, Wikidata-bugs, Jdouglas, PKM, Base, matthiasmullie, aude, Tobias1984, Manybubbles, Ricordisamoa, Fabrice_Florin, Raymond, Steinsplitter, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T187767: Choose a service name for the new internal WDQS cluster and configure LVS

Gehel created this task.Gehel triaged this task as "High" priority.Gehel added projects: Wikidata-Query-Service, Discovery-Wikidata-Query-Service-Sprint, Discovery.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONTASK DETAILhttps://phabricator.wikimedia.org/T187767EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: Gehel, Aklapper, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Jonas, FloNight, 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] [Created] T187766: Install / configure new WDQS servers

Gehel created this task.Gehel triaged this task as "High" priority.Gehel added projects: Wikidata-Query-Service, Discovery-Wikidata-Query-Service-Sprint, Discovery.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONTASK DETAILhttps://phabricator.wikimedia.org/T187766EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: Aklapper, Gehel, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Jonas, FloNight, 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] [Updated] T182991: New WDQS clusters eqiad + codfw

Gehel added a subtask: Unknown Object (Task).
TASK DETAILhttps://phabricator.wikimedia.org/T182991EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: RobH, GehelCc: Lucas_Werkmeister_WMDE, RobH, Gehel, EBjune, Davinaclare77, Qtn1293, Lahi, Gq86, Darkminds3113, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, merbst, LawExplorer, Avner, Zppix, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, 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] [Unblock] T178492: Create a more controlled WDQS cluster

Gehel closed subtask T178548: Cost estimate for a new WDQS cluster as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T178492EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: Daniel_Mietchen, BBlack, Lydia_Pintscher, Volans, mobrovac, Jonas, Aklapper, debt, Smalyshev, Gehel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, SandraF_WMF, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Tramullas, Acer, merbst, LawExplorer, Avner, FloNight, Xmlizer, Susannaanas, Eevans, Aschroet, Jane023, jkroll, Hardikj, Wikidata-bugs, Jdouglas, PKM, Base, matthiasmullie, aude, Tobias1984, Manybubbles, Ricordisamoa, Fabrice_Florin, Raymond, Steinsplitter, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Unassigned] T187316: Create a formatter for displaying a Lexeme as a statement value